Opened 22 years ago
Closed 16 years ago
#204 closed defect (duplicate)
tileindex path problems
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | normal | Milestone: | 5.2 release |
Component: | MapServer CGI | Version: | 4.1 |
Severity: | normal | Keywords: | raster tileindex |
Cc: | jdoyon@…, bfraser@… |
Description (last modified by )
I'm on 3.6.2, and what I had set up was SHAPEPATH = /raid1/nima/vmap0 TILEINDEX = /raid1/nima/vmap0/placenames/placenames-tile Tileindex entries were like ./row/aa where the file was located at /raid1/nima/vmap0/placenames/row/aa This generated the error: > Warning: MapServer Error in msTiledSHPOpenFile(): Unable to open a > single tile to use as a template. in > /home/httpd/html/maplab-2.0rc3/htdocs/common/wrapper/drawmap.php on > line 292 I changed it to: SHAPEPATH = /raid1/nima/vmap0 TILEINDEX = placenames-tile Tileindex entries were like ./placenames/row/aa where the file was located at /raid1/nima/vmap0/placenames/row/aa and I moved the tileindex up to the /raid1/nima/vmap0 dir. The second seems to be working, but not the first. I have had other problems with tileindex layers working in the past, which I think are now related to this problem. It is not intuitive as to what works and what doesn't. -Steve
Change History (10)
comment:2 by , 21 years ago
I think being consistent is important and having ALL data relative to SHAPEPATH makes sense to me. Personally I'd leave it alone and fix the documentation.
comment:3 by , 21 years ago
Cc: | added |
---|
I'm adding JF Doyon to the CC of this bug. JF, could you please add a note to the TILEINDEX doc in the mapfile-reference document to make it clear that if the location value in the tileindex file is a relative path then it is going to be evaluated relative to the SHAPEPATH and NOT relative to the TILEINDEX path.
comment:4 by , 19 years ago
Cc: | added |
---|---|
Owner: | changed from | to
I seem to bang my head against this on a regular basis. Has this been changed and I'm just stupidly working on an old version (4.01) and should upgrade? Relative paths in Tileindexes NEED to be relative to the location of the Tileindex! Why? because it is needed to modularize your deployment of data. I create a directory that has a bunch of data in a sub tree and then create the tileindexes in that directory. If I want to reference that directory in a lot of other map configs using symlinks it can get linked into a different levels in the overall directory structure. If the paths are relative to the DATAPATH or the mapfile location then is almost always breaks. I typically have All mapfiles are in a common directory like "/u/mapfiles/" DATAPATH "/u/data/" TILEINDEX "tiger-maps/roads-tile" and paths in "roads-tile.shp" are like: ./data/01/001/roads.shp ./data/01/003/roads.shp and /u/data/tiger-maps/data/01/... BUT mapserver seems to look for files in: /u/mapfiles/./data/01/001/roads.shp /u/data/./data/01/001/roads.shp tiger-maps might also get referenced in another map like: /u/data/world/us/tiger-maps -> /u/data/tiger-maps DATAPATH "/u/data/world/" TILEINDEX "us/tiger-maps/roads-tile" This is a natural thing to do with making data and tileindexes reusable, but it requires the relative paths in tileindexes to be relative to the tileindex location.
comment:5 by , 19 years ago
That's how it used to be, but once the functions showed up to manage paths in 4.0 (?) that changed. The ammount of code that needs to change is very small, one spot in the mapshape.c and one in the raster file but getting the base path of the tile index will be a pain. Steve
comment:6 by , 19 years ago
The tileindex should be located at DATAPATH + TILEINDEX so strip off the tileindex name and you have the base path.
comment:7 by , 19 years ago
Cc: | added |
---|
I toyed with the problem some time ago (v4.0). I didn't want to break any existing sites, so I added code to check for the existence of the file under the "old" style path. If it existed, fine, but if not, try a different combination of the path. I added the following line 1511 in mapraster.c (just after "filename = tilename;": ------------------------------------- /* Use alternate form: DATA/LOCATION (then tack on SHAPEPATH) */ f = fopen(msBuildPath3(szPath, map->mappath, map->shapepath, filename),"rb"); if(!f) { sprintf(tilename,"%s/%s", layer->data,msDBFReadStringAttribute (tilefile.hDBF, t, tileitemindex)); filename = tilename; } else fclose(f); ------------------------------------- Of course, it will need to be tweaked now that we have raster layers pointing to tileindex layers. - Brent
comment:8 by , 19 years ago
Milestone: | → 4.4 release |
---|
In reply to Steve Lime's comment #5: I don't think this is a new behavior since 4.0. I just did a quick check in the 3.6 source and it seems that the LOCATION field value in the tileindex has always (at least in 3.6) been evaluated relative to shapepath and not relative to the tileindex location (contrary to what we would intuitively expect). This is confirmed by Steve W's initial comment in this bug where he says that he was on 3.6.2 and noticed this behavior. If we wanted to evaluate LOCATION relative to the tileindex's directory we should be able to do it using the msBuildPath3() function. My only concern is that this would break backwards compatibility for existing tileindex files and should be very well documented.
comment:9 by , 17 years ago
Description: | modified (diff) |
---|---|
Keywords: | raster tileindex added |
Milestone: | 5.0 release → 5.2 release |
Priority: | high → normal |
I'm afraid I did not get to addressing this. Pushing it off to 5.2 since it is potentially too disruptive to attach in a bug fix release.
comment:10 by , 16 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
This should be fixed with the patches in #2369. I hope to commit that by 5.2-beta3 pending clarification by the patch author... Marking this as a duplicate and closing...
Steve
Note:
See TracTickets
for help on using tickets.