[mapserver-dev] RFC: GMaps API for mapserv

[Christopher Schmidt]

On Fri, Apr 11, 2008 at 09:48:05AM -0500, Steve Lime wrote:
> 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.

Really? That's not been my experience. (I don't know if I've actually
implemented them as annotation layers.) I've found that I have to
actually push the label cache edge buffer 5-10px from the edge, because
cases where the marker extends past the edge of the tile, but the label
itself doesn't, aren't protected...

In any case, the annotation problem is the same with shields as it is
with any other non-zero width annotation layer: if the annotation size
is wide enough that: 
 
 * a feature is not selected by the geographic data query
 * the annotation for that feature extends out into an adjoining tile

Then PARTIALS TRUE, even with the processing option, will hurt, rather
than help, those particular features.   

If there was a EDGE_BUFFER option which said "only do this for linear or
polygon features, not for point or annotation features", that would
likely solve all the common cases such that you could then have a 5px
buffer on anything that *wasn't* those cases, to protect them but not
affect your tile too significantly... 

(Maybe?)

I don't know, I'm just tossing out the things that come to mind: I've
been using metaTiles since we added support to TileCache, so I haven't
put any effort into solving the issues without metaTiling recently.

Regards,
-- 
Christopher Schmidt
MetaCarta