[mapserver-dev] RFC: GMaps API for mapserv

[Steve Lime]

I've not done any explicit performance testing with the PROCESSING option (note
that I only consulted on the implementation). It doesn't seem to add much overhead
though. I'm using the option with non-tiled apps and everything is still very snappy.
The process requires running through more coordinates than the post clipping but
that shouldn't cost too much. I can run some timings if you are interested.

Note that shields are protected by the label_cache_edge_buffer metadata since they
are typically implemented as annotation layers and as such the marker is considered
part of a label.

Steve

>>> On 4/11/2008 at 5:47 AM, in message <20080411104700.GB31967 at metacarta.com>,
Christopher Schmidt <crschmidt at metacarta.com> wrote:
> On Thu, Apr 10, 2008 at 09:48:27PM -0700, Paul Ramsey wrote:
>> * If PARTIALS is not set in labeling directives, it will be turned on 
> automatically.
> 
> This *only* makes sense with the PROCESSING=DONT_CLIP_ME_BABY or
> whatever the option is: 'partials true' will only cause problems if you
> turn it on without this. (PARTIALS defaults to TRUE: The processing
> option does not.)
> 
> Is there a significant performance cost to the PROCESSING option?
> 
> I'm almost wanting to say that rather than do thsi (if it's not goign to
> incldue the next step in this phase) it would be better to explicitly
> set it to off. The reason is that any 'annotation' or point layers are
> *not* going to be properly labeled across tiles with PARTIALS TRUE
> without extra data being requested (I don't think?) because the data
> that they're in will not be included in the spatial data requested from
> the database. That is:
> 
> 
>       ----------
>       |        |
>    *  |        |  
> Chicag|o       | 
>       |        |
>       ----------
> 
> The point here will not be rendered in the right hand tile, so the label
> will be missing an 'o'.
> 
> If we turn partials *off*, then all these cases 'go away' (at the cost
> of fewer labels per tile in total.)
> 
> My suggestion is to actually reverse the state of the proposal: set
> PARTIALS FALSE by default, and in the future, when more 'metatile like'
> features are added, toss in PARTIALS TRUE and the PROCESSING option and
> maybe a shield_cache_edge_buffer -5 metadata (to protect shields:
> doesn't exist yet, same vein as label_cache_edge_buffer).
> 
> In the meantime, 'partials off' is likely to give you a better
> experience (fewer clipped labels) in my experience, with the net result
> being fewer labels in total... but usually in a way that works out for
> the best in the end.
> 
> I think this API is the better way to go, and I'm now more in favor of
> it.
> 
> I will also write OpenLayers documentation on how to pull these tiles
> in, and update the 'spherical mercator howto' mapserver section that I
> am currently maintaining for OpenLayers documentation purposes.
> 
> Regards,