different tiling methods

Ed McNierney ed at TOPOZONE.COM
Wed Apr 27 09:01:03 EDT 2005


Jeff -
 
No, actually, those tools don't work that way at all <g>.
 
tile4ms creates a new, separate tile index shapefile.  It does not
combine shapefiles into one shapefile.  Each input shapefile has its
bounding box retrieved, and a rectangular polygon is created in the new
tile index shapefile.  If you started with N shapefiles you now have N+1
shapefiles - all the originals and the index file.
 
Let's say each original shapefile contained data for a particular
country.  If you wanted to create a map showing every country, you would
have to create a few hundred separate layers then group them together.
By creating a tile index layer, you can take a large number (or small
number) of separate shapefiles and treat them AS IF they were one single
large shapefile - but they're not.
 
This is the primary benefit of a tile index.  IF your data in the
separate files are relatively constrained to rectangular regions, then
the tile index also will offer you a performance improvement.  It's like
a new top-level index for your data.  If you're looking at a large-scale
map of Europe, the tile index file will immediately discard any of those
input country files whose rectangular bounding boxes do not overlap the
output map area.  Most of the input country files will never be opened -
only the few files that might possibly contribute to the output map are
opened and read.  For large data sets this improves performance.
 
Steve's shp2tile utility helps to create such an appropriate set of
input files, by taking a single large input shapefile and chopping it up
into rectangular pieces.
 
shptree creates a spatial quadtree index for a shapefile that makes it
quicker to locate objects inside that file.  This is virtually always a
good idea, and easy to do.
 
You may have to tune your data set sizes to get the right balance.  The
goal is to use the tile index file to quickly discard data that cannot
possibly be needed for an output map request.  If you end up rendering
all the data, or opening all the files, it will do you no good at all.
 
     - Ed
 
Ed McNierney
TopoZone.com 

________________________________

From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of Jeff Portwine
Sent: Wednesday, April 27, 2005 8:30 AM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: [UMN_MAPSERVER-USERS] different tiling methods


 
Hi Everybody,
 
I have a general question for my own education, it doesn't directly
pertain to anything I'm working on right now.    I was just wondering if
anybody could explain to me the difference in different ways of tiling
map images?     In my current project, I had several large layers such
as road layers and water layers that I tiled in order to make them
faster and more resource friendly... The method I used was:
 
-tile4ms <data.txt> <tile name>   
(where data.txt is a list of all the shapefiles being included in the
tiling, since tiger data comes in about a zillion files)
-shptree <tile name>
-cat <data.txt> | xargs -n 1 shptree
 
The way I understand it, this combines all the pieces into one
shapefile, tiles them, and spatially indexes them...  is that correct?

 
In a recent post I also saw a pointer to Steve Woodbridge's shp2tile
utility which it seems does much the same thing... the main difference
being from the sounds of it that it doesn't put a lot of shapefiles
together, but rather splits a single large shapefile into tiles and then
indexes them.   How is this different from the first method, and how
does it affect resources and rendering speed?   Or is the only real
difference the one I noted where you are sticking multiple shapefiles
together one way and only using one original shapefile the other way?
 
Are there other methods of tiling that behave differently or that you
might use for different situations?
 
Thanks everybody,
Jeff
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20050427/9548cd1e/attachment.html


More information about the mapserver-users mailing list