MS RFC 22a: Feature cache for long running processes and query processing (update)

[Tamas Szekeres]

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.
>

Steve,

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
subsequent addition.

> 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.

Best regards,

Tamas