Opened 22 years ago

Closed 16 years ago

#204 closed defect (duplicate)

tileindex path problems

Reported by: woodbri@… 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 warmerdam)

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:1 by dmorissette, 21 years ago

Cc: morissette@… added
Version: 3.64.1
Basically it seems that the LOCATION inside the tileindex file are interpreted 
relative to the SHAPEPATH, but you would expect the LOCATION to be interpreted 
relative to the location of the tileindex file.

I noticed the same thing and just got used to it.  I'm scared that changing this 
at this point would just confuse users that have datasets that assume that 
LOCATION is relative to SHAPEPATH.  Would also make mapfiles with tileindex 
files not compatible between 3.6 and 4.0.

Not sure what to do... but we're running out of time for 4.0, so how about we 
revisit this in 4.1?  Maybe we just need to make this behavior very clear in the 
documentation?

comment:2 by sdlime, 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 dmorissette, 21 years ago

Cc: jdoyon@… 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 woodbri@…, 19 years ago

Cc: warmerdam@… added
Owner: changed from sdlime to fwarmerdam
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 sdlime, 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 woodbri@…, 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 bfraser@…, 19 years ago

Cc: bfraser@… 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 dmorissette, 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 warmerdam, 17 years ago

Description: modified (diff)
Keywords: raster tileindex added
Milestone: 5.0 release5.2 release
Priority: highnormal

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 sdlime, 16 years ago

Resolution: duplicate
Status: newclosed

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.