[mapserver-users] .map

[Ed McNierney]

John -

I would simply add to Steve's note that it is possible - depending upon
the application - to construct your tile index so you do NOT have to
rebuild it each time.  The tile index file contains a rectangular
bounding box for each of the set of shapefiles it indexes.  In general
you want those bounding boxes to be as tight as possible so you don't
open any more shapefiles than you have to in order to render a specific
map request.

But the tile index could simply represent a geographic segmentation of
the data set.  For example, you might have a tile index file that
consists of nothing but one-degree by one-degree rectangles covering
your region of interest.  Let's say you were tracking West Nile virus
infections across the US.  You create a tile index that consists of
these one-degree-square rectangles each pointing to a single point
shapefile.  So there would be one point shapefile named 43N072W, for
example, that contained all the WNV incidents in the one-degree square
with 43 N latitude 72 W longitude at its southeast corner.  If that
particular shapefile were updated or added to on a periodic basis,
there's no need to ever change the tile index shapefile.

If the individual data sets are going to get to any noticeable size, you
should use shptree to create internal spatial indexes for each
shapefile.

It is also a good idea to design your tile index so it does a good job
of partitioning the data.  The one-degree scheme would not be a good
choice if the dataset were cities with populations greater than 100,000;
many of the tiles would point to empty shapefiles.  The goal is to
never, ever have to look inside a shapefile if you will find nothing of
interest in it.

	- Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
(978) 251-4242
ed at topozone.com


-----Original Message-----
From: woodbri at swoodbridge.com [mailto:woodbri at swoodbridge.com] 
Sent: Thursday, September 19, 2002 9:07 PM
To: John Bennett; Mapserver-Users
Subject: Re: [mapserver-users] .map


John,

There are a few of ways to look at this problem.

One is think of every shape file as a layer and have a bazillion 
layers  -  this may be the right way, but there may be a better way.

An other way is to think of the data as a smaller number of sets of 
common objects where each set represents a layer in the map file.

Let say you have a set of telephone poles and every day another city 
or region reports on with their telephone poles in their own shape 
file. So now you have to include that new shapefile in the map. Bang! 
need another layer - right?  ... Wrong!

I have a Tiger/Line Mapserver running. The Tiger data is organized by 
counties, about 3300 of them in the US, every county has about 10 
different shapefiles, that would make about 33,000 shapefiles, but I 
only have 10 layers to define the 10 types of data in the mapfile. If 
I added another county and its 10 new shapefiles, I would not need to 
add any new layers.

The trick is to make a tileindex for each layer that points to the 
the 3300 files that represent a single layer. If I add a new shape 
file to the map, I update the tileindex to include a reference to the 
new file and I never touch the mapfile. This can easily be automated 
with a little scripting. In example above of telephone poles it would 
work the same way. You copy the new shape files to the map data 
directory and run a utility to add its record to the tileindex.

I hope this makes sense,
  -Stephen Woodbridge
   http://iMapTools.com

On 19 Sep 2002 at 16:17, John Bennett wrote:

> I'm new to this, therefore a simple question.
> 
> I have a large dataset that is being added to daily, full of 
> shapefiles and Gifs. For displaying these files using Mapserver is the

> protocol to update the .map file every time the database is updated 
> (one big .map file, I don't think so, too big eh!) or make a new .map 
> dynamically for each user depending on their request? Thanks for the 
> past help. John
> 
> 
>