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

[Steve Lime]

If we went the way of using "REQUIRES" as a long term goal then I don't think it's worth adding parameters
with the intent of pulling them shortly. I think generalizing REQUIRES, with a custom parser as you mention
is the best solution. I think there is some leeway in syntax and we can talk about maintaining backwards 
compatibility with respect to [layername]. 

If your contract doesn't afford time to pursue the REQUIRES approach right now then perhaps a more
hackish, temporary solution would be to hijack minscaledenom and maxscaledenom and use a processing
directive to trigger the different interpretation.

Steve

>>> On 6/23/2008 at 4:18 PM, in message
<f3b73b7d0806231418v2e687888o5d7dda65b79f48d4 at mail.gmail.com>, "Tamas Szekeres"
<szekerest at gmail.com> wrote:
> 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