Contours again.

[Ed McNierney]

Frank -

Thanks for chiming in!  You're right, of course; Bob made the comment earlier:

"I actually started out with something like that in the AutoCAD world.
Each tile (1/2 sq. mile) was brought together into a single coverage. I
didn't do any joins on the linework, I just let them be seperate
entities. I figured that was better than joining them anyway."

from which I concluded that these were a lot of small, independent objects.  But I'm now not sure that's really the case, so, Bob, can you confirm the arrangement of your data?

I ran into a similar situation a few years ago with US street map data, which was originally organized as one shapefile per layer type per state.  I was surprised at how noticeable the improvement was when I switched to one shapefile per layer type per COUNTY, as it helped prune large objects (interstates, rivers).

     - Ed

----- Original Message -----
From: Frank Warmerdam <warmerdam at pobox.com>
To: Ed McNierney <ed at TOPOZONE.COM>
Cc: MAPSERVER-USERS at LISTS.UMN.EDU
Sent: Fri, 15 Oct 2004 12:45:34 -0400
Subject: Re: [UMN_MAPSERVER-USERS] Contours again.


> Ed McNierney wrote:
> > Bob -
> > 
> > If things got 25% faster, the index is being used - you don't need to do
> anything other than create it.  Do you have a feel for what level of bandwidth
> you're getting from the NAS server?  Roughly what percentage of the vectors in
> the shapefile are being used to draw your test image?
> > 
> > Don't mess around with different values yet - just use the default.  It sounds
> like you're suffering from either excessively-detailed data (needs
> simplification for the scales you're using), a test that draws a large
> percentage of the vectors in the file, and/or poor throughput to the file
> server.  A simple test would be to copy the shapefile to the local disk just to
> see if there's a difference.
> 
> 
> Guys,
> 
> I haven't followed this discussion very closely, so I may have missed
> something.  But one issue I have encountered with contours is that they
> often end up being very large polygons.  For instance, a "zero elevation"
> coastal contour might well be continental sized.  Really big "rings" get
> pushed way up the the spatial index tree and will have to be read from
> disk and rendered even if the current map view is just somewhere inside
> the contour ring such that the contour won't actually be visible, but
> the bounding rectangles of the contour and the view area will overlap.
> 
> If this is Bob's problem, he will really be much better off to split the
> contours into shortish line segments instead of keeping as massive single
> geometries as this would allow the spatial index to localize things
> much better.
> 
> I didn't speak up about this before because it wasn't clear if this has
> already been done.
> 
> Best regards,
> -- 
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
> 
>