[mapserver-dev] RFC: GMaps API for mapserv

Paul Spencer pspencer at dmsolutions.ca
Fri Apr 11 08:09:26 EDT 2008


On 11-Apr-08, at 6:47 AM, Christopher Schmidt 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?

Perhaps Steve can address the expected performance cost?  I believe  
that mapserver already requests all features that intersect the extent  
to be drawn, it just clips them before calculating label position.   
The processing option allows it to calculate the label position before  
the features are clipped.  I don't think any extra data is requested.

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

In the specific case of point features, you are right because if the  
point lies outside of the extent being drawn then it won't be included  
in the pre-clip calculations even if the resulting label would have  
fallen inside the requested extent.

Lines and polygons often stretch across multiple tiles, though, and  
will be labeled in every tile so it would be nice to change this  
behaviour for lines and polygons.

Lines and polygons could suffer label rendering issues in specific  
cases where the label lies outside the bounds of the line, although I  
would expect a small buffer would take care of those problems.

So maybe it would be a reasonable choice to turn off partials for  
points if not specified and turn on the processing option for any  
labels that have partials true?

> My suggestion is to actually reverse the state of the proposal: set
> PARTIALS FALSE by default,

I'm not strongly biased either way on this, but this specific  
situation came up for us where polygons where being labeled twice in a  
relatively small area even with large meta tiles because the polygon  
existed in both metatiles.  We will be using the processing option to  
solve that particular problem.

Thinking a little more about this, if you are going to the trouble of  
setting up a new mapserv with this feature, you can probably follow  
recommendations for map file settings that are most likely to help  
tiled requests.  Forcing things like this maybe is the wrong way to  
go.  Okay, I'm convinced :)



__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/



More information about the mapserver-dev mailing list