TileIndexes and paths - a proposal

[Brent Fraser]

Ahh yes, now I remember why the path construction rules were set up that
way.

In your scenario, you've got "tiles-by-theme":

tile1 /    (eg Madison county)
    theme1.shp (eg roads.shp)
    theme2.shp
tile2 /    ( eg another county)
    theme1.shp
    theme2.shp

and you would not store the theme-name/file-name in the tileindex location
column.  You'd set the filename in the DATA variable and have one LAYER for
each theme (and could point to one tileindex).


In scenario mine, I've got "tiles-by-geography":

theme1 /    (eg 1:250k topos)
    tile1.tif  (eg c370.tif)
    tile2.tif
theme2 /    (eg 1:24k topos)
    tile1.tif  (eg o370.tif)
    tile2.tif

My filenames are in the  tileindex location column (and in the above example
I would have two tileindex files).  If I have another layer with the same
tiling scheme but different content (say terrain-shaded topos) I would
simply copy the tileindex or create a new one using gdaltindex.  Hmm, maybe
that's not very efficient...

Well, I guess we could swap the  "LAYER (tiles): DATA" and "LAYER: TILEITEM
contents" in my rules.  That would make it somewhat backward compatible too.
So now the proposal is

1. [Location of the map file]
2. SHAPEPATH
3. LAYER (tileindex):DATA (minus the tileindex filename portion)
4. LAYER:TILEITEM contents
5. LAYER (tiles):DATA

Proposed rules (V2):
=============
1. The path to a tile is constructed using the values of the above variables
in order:

[Location of the map file]  /  SHAPEPATH  /  LAYER (tileindex):DATA  /
LAYER:TILEITEM contents  /  LAYER (tiles):DATA

2. An absolute path in any of the variables would cause those to the left of
that variable in Rule 1 not to be used in the path construction. (As in the
original proposal).
===============

The above change requires that the tileindex is in the same location as the
tile dir (which I think is not too bad).

And maybe I can convince Frank W. to add an option to gdaltindex/ogrtindex
to not add the actual filename (only the path as given on the command line)
to the location value.

A couple of more questions...
======================
1.  What if the tileindex is a database?
2.  What if the tileindex is in a different coordinate system than the
tiles?


Brent


----- Original Message -----
From: "Stephen Woodbridge" <woodbri at SWOODBRIDGE.COM>
To: <MAPSERVER-USERS at LISTS.UMN.EDU>
Sent: Friday, October 22, 2004 11:23 AM
Subject: Re: [UMN_MAPSERVER-USERS] TileIndexes and paths - a proposal


> Brent,
>
> I have one variant on my example:
>
> Brent Fraser wrote:
>
> > Some examples:
> > =============
> > A.  The Steve Woodbridge senario:
> > -----------------------------------------
> > 1. [Location of the map file]  = /u/mapfiles/
> > 2. SHAPEPATH = "/u/data"
> > 3. LAYER (tileIndex) : DATA =  "tiger-maps/roads-tile"
> > 4. LAYER (tiles): DATA = ""
> > 5. LAYER: TILEITEM contents = "./data/01/001/roads.shp"
> >
> > would result in a tile path of
> >      /u/data/tiger-maps/./data/01/001/roads.shp
>
> 1. [Location of the map file]  = /u/mapfiles/
> 2. SHAPEPATH = "/u/data"
> 3. LAYER (tileIndex) : DATA =  "tiger-maps/county-tile"
> 4. LAYER (tiles): DATA = "roads"
> 5. LAYER: TILEITEM contents = "./data/01/001"
>
> would result in a tile path of
>       /u/data/tiger-maps/./data/01/001/roads[.shp]
>
> I have found that often a spatial area (like a county) has many layers
> in it and they can all share the the same tileindex and then I use the
> DATA to select the specific file for the layer. ie. the tile represents
> the extents of the data in the directory and then you can have multiple
> layers in the directory.
>
> I think you description implies this would happen anyway, but I just
> wanted to make sure.
>
> Thank you for taking the lead on this.
>
> -Steve W.