[mapserver-dev] Support for the MapInfo style zoom layering option.

[Tamas Szekeres]

2008/6/23 Steve Lime <Steve.Lime at dnr.state.mn.us>:
> Ok, I see, zoom really means width. Why not just use that term instead of zoom?
>

I`ve only taken over the MapInfo terminology, however I don`t care
about the name.

> I guess I'm not seeing the advantage of using this method then. MapServer scale is based
> on the width as well but applies a constant multiplier to that value. I would expect zoom to
> track linearly with scaledenom.
>

Not exactly. That constant (between the scale and the map width)
depends on the image width in pixels. Therefore different images sizes
(at the same map extent) may provide different layers to be switched
on and off. With this approach my client cannot do an equivalent map
file like their existing mapInfo (MapXTreme) workspaces without
adjusting the minscaledenom and maxscaledenom values depending on the
image pixelwidths.
Since the MapInfo side provides both of these options (scale and zoom)
I would like to have both in mapserver as well (switched by a separate
parameter like DISPLAYMETHOD)

>
> or perhaps we should be using the REQUIRES functionality. Traditionally that is used to look
> at other layer state but there's no reason we couldn't look at extent properties as well. For
> example (pick your favorite parameter names):
>
>  REQUIRES ([width] > 1500 AND [width] < 2500)
>  REQUIRES ([scaledenom] < 100000)
>
> That way we'd have no new parameters and we could depricate MINSCALEDENOM and
> MAXSCALEDENOM. I kinda like that.
>

I think it would be reasonable though it may drive the implementation
(and the mapping between the Mapinfo workspaces and the mapfiles)
beyond to my original plans. Is this syntax conform with the original
approach (layer names in braces) or it would also be deprecated? I
wonder if we could switch to something like [layer.name] = `mylayer`
instead.

I would also rely on some custom (and optimized) evaluator instead of
using the parser with global locks around that. This portion of the
code should be fast enough to be preferred over the scaledenom
comparisons.


Best regards,

Tamas