MS RFC 22a: Feature cache for long running processes and
query processing (update)
szekerest at GMAIL.COM
Thu Jun 28 10:50:18 EDT 2007
2007/6/28, Stephen Woodbridge <woodbri at swoodbridge.com>:
> Shape ordering is a problem!
> This is a good point as I do use ordered data. I primarily use ordered
> shapefiles to control the rendering and labeling of data. It would be a
> little disconcerting to render an image and then when it is rendered out
> of the cache all the labels would change because the object ordering has
> changed. I think this would be very bad. At Where2getit we serve 500-750
> Million map draws a year and I would hate to have to deal with questions
> and issues from those users and clients. I suppose I do not need to use
> the cache in which case I would get the old behavior which might be OK.
I agree that this is a problem. And it can surely be handled when only
one extent is cached using a linked list in addition. If we want to
cache up multiple extents, then we should find out how the provider
denotes the ordering to follow by the caching provider.
> 1) Would it make sense or be possible to construct a cache provider that
> also maintained a spatial index for its cache items?
That was one of my former conception. However this effort might only
be a subject of a
> 2) On a zoom in, I assume that the cache will be used exclusively since
> the extents will be in side the previous extents, or does the new scale
> invalidate the cache and require it to be rebuilt. Would it make sense
> for the cache to be "aware" of the zoom scales it can support?
The proposed solution does exactly this. However we might have to
provide an additional option when the cache is rebuilt even if the
extent falls inside of a previous.
More information about the mapserver-dev