[mapserver-users] Indexing Shape files

[Armando Scalise]

Hi Steve.

Thanks for your help.  We are still experimenting with this feature.

We do, indeed, want to create a single Tile file for hanlding GDT data.

We can see that one single file provides a lot of advantages from a
manteinance and administrative standpoint.
However, are there any performance trade-offs in having a very large Tile
file for the whole US, as compared to inidividual tile fiels for each state?


Armando Scalise
geoVue
200 Lincoln Street  5th Floor
Boston, Massachusetts  02111  USA
p  617.451.2520 x122
f  617.486.3066
www.geoVue.com
LOCATION INTELLIGENCE
ascalise@geovue.com



-----Original Message-----
From: owner-mapserver-users@lists.gis.umn.edu
[mailto:owner-mapserver-users@lists.gis.umn.edu]On Behalf Of Steve Lime
Sent: Tuesday, October 29, 2002 2:26 PM
To: Chip.Hankley@GASAI.Com; mapserver-users@lists.gis.umn.edu
Subject: RE: [mapserver-users] Indexing Shape files


As an aside, actually sometimes you might use the DATA line. MapServer
tiles can be used to store:

  1) tiles with totally unique files names or
  2) tiles with identical shapefile names but different directories

In the latter case you might store just the directory name in TILEITEM
and the shapefile name in DATA. The two then get merged to create a full
file name. This allows you to get away with a single TILEITEM for
multiple layers which can be a big deal with datasets like GDT roads...

Steve

>>> "Hankley, Chip" <Chip.Hankley@GASAI.Com> 10/29/02 10:58AM >>>
Armando -

When you're using a TILEINDEX, you don't need a DATA line... the
TILEINDEX
line IS the data line. Here's an example -

LAYER
  NAME "LANDCOVER"
  MAXSCALE 500000
  MAXSCALE 500000
  STATUS OFF
  TILEINDEX "Raster\lc_tile"
  TILEITEM "Location"
  TYPE RASTER
  OFFSITE 0
END

In this case, TILEINDEX is the path (relative to the mapfile's
SHAPEPATH) to
the indexing shapefile, and TILEITEM is the field name in the index
shapefile that points to the individual tile data sources (in this
case
images).

HTH.

Chip