question about shp2tile

[Zhonghai Wang]

Hi Bob, Steve,

thank you very much for all these helpful clues, now I think I've got the
points of the shp2tile command, it's really a good tool to slice shapefile.

zhonghai

On 5/18/06, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
>
> Zhonghai Wang wrote:
> > Hi folks,
> >
> > I have a large shapefile, now I am trying to use shp2tile command to
> > slice it into pieces, with -r and -c is ok, but I do not fully
> > understand the -q parameter, what does it actually mean? and what number
> > should a use for this parameter normally?
> >
> > or something like this? -- >shp2tile -q 10000 input_shapefile
> > output_shapefile
>
> Hi Zhonghai,
>
> The -r -c option breaks the extents of your shapefile into R x C rows
> and columns and then tries to fit the objects into the best tile. I any
> tile crosses a tile boundary by 5-10% then it is put into a "supertile"
> the could be the same extents as the original shape file. So typically
> you will end up with r X c + 1 tiles.
>
> The -q N option splits the extents in half either vertically or
> horizontally and then sorts the objects into the 2 halves or put them in
> a supertile. Then if the either of the two halves has more than N
> objects it is again split in half and this continues until all files
> have less than N objects. This can cause some strange effects like tiles
> with 1 or a small number of objects and most tiles will have less than N
> objects in them. Since this algorithm tends to spatially cluster objects
> in a file, there is a good chance that if you need the file that all or
> most objects in the file will be used.
>
> I recommend trying numbers like 10,000 and 20,000 as you initial tries.
> I think you should probably not use numbers less then 8000, but it is
> really up to you to try and measure the results to find what works best
> for your data.
>
> -Steve W.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20060518/e1d4d8c2/attachment.html