[mapserver-dev] RFC-86: scale dependant DATA substitutions

[thomas bonfort]

Steve,
I understand the confusion, but it depends on how you look at it :)
Typically in a tiling scenario, you have a fixed list of
resolutions/zoom-levels (directly translatable to scales), and you
want to define which table/column/filter to use for a given zoom
level.

if, as how you suggest, the token replacement works with
minscale/maxscale, then you have two steps to get this working:
 - make sure that your defined min/max scales are contiguous, i.e. you
are not leaving any scale out
 - from the fixed resolutions, calculate the intermediate min/max scales

to illustrate, supposing you are tiling at scales
500,1000,2500,5000,10000,25000,50000,100000, ....

with my proposed syntax, you'd use:

values
  "500" "foo"
  "1000" "baz"
  "2500" "bar"
  etc..
end

with min/max scales, this would end up as

values
  "0/750" "foo"
  "750/1750" "bar"
  "1750/3750" "baz"
  etc...
end

makes sense?

--
thomas


On Mon, Oct 8, 2012 at 9:22 PM, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> Thomas,
>
> OK, got it, but this is not intuitive because one has to do math to figure
> out where the breaks will happen. And it is even harder to figure out what
> numbers I should use if a want a break at X scale, because the number I use
> in the VALUES affects BOTH the scale above and below the number I change.
> This also does not follow how the usage of MINSCALEDENOM/MAXSCALEDENOM in
> the rest of the mapfile.
>
> I think you have to make the ranges explicit and break on the scale numbers
> not between them. This means you have to have an extra case in the values
> like I suggested, which you were probably trying to avoid.
>
> I think it would be a good idea to get additional input from others on this.
> I suspect other users will be just as confused but the proposed scheme as I
> was.
>
> Thanks,
>   -Steve W
>
>
> On 10/8/2012 2:08 PM, thomas bonfort wrote:
>>
>> Steve,
>>
>> starting from
>>
>> VALUES
>>        "1000" "1000"
>>        "10000" "10000"
>>        "1000000" "1000000"
>> END
>>
>> let's change this to:
>>
>> VALUES
>>        "1000" "foo"
>>        "10000" "bar"
>>        "1000000" "baz"
>> END
>>
>> to avoid confusion between keys and values. Now, this should be read as:
>> - for scale 1000, use "foo"
>> - for scale 10000, use "bar"
>> - for scale 1000000, use "baz"
>>
>> at rendering time, with a current map scale "s", find which is the
>> closest configured scale to s,
>> i.e.:
>>
>> - if s < 1000 use "foo"
>> - else if 1000<s<10000: if s closer to 1000 than 10000 use "foo", else
>> use "bar". i.e. the test for s<5500
>> - etc...
>>
>> wrapping it all up you get:
>>
>> 0 ... foo ... 5500 ... bar ... 505000 ... baz ....
>>
>> hope this clarifies things :)
>>
>> --
>> thomas
>>
>> On Mon, Oct 8, 2012 at 7:51 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com> wrote:
>>>
>>> On 10/8/2012 11:32 AM, thomas bonfort wrote:
>>>>
>>>>
>>>> On Mon, Oct 8, 2012 at 4:41 PM, Stephen Woodbridge
>>>> <woodbri at swoodbridge.com> wrote:
>>>>>
>>>>>
>>>>> On 10/8/2012 9:02 AM, thomas bonfort wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Devs,
>>>>>>
>>>>>> Please take a look and comment on
>>>>>>
>>>>>> http://mapserver.org/trunk/development/rfc/ms-rfc-86.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Thomas,
>>>>>
>>>>> Thanks, this looks like an excellent implementation to address the need
>>>>> I
>>>>> identified in bug #3150.
>>>>>
>>>>> I'm a little confused with your first example in the RFC, you have:
>>>>>
>>>>>     SCALETOKEN
>>>>>       NAME "foobar"
>>>>>       VALUES
>>>>>         "1000" "1000"
>>>>>         "10000" "10000"
>>>>>         "1000000" "1000000"
>>>>>       END
>>>>>     END
>>>>>
>>>>> But the discussion reference 5500, 505000. So that should be cleared up
>>>>> so
>>>>> it is more understandable.
>>>>
>>>>
>>>> Steve,
>>>> what this meant is that given the current requested scale, mapserver
>>>> will select the closest defined scaletoken. In the example here,
>>>> 0=>5500 uses the 1000 value
>>>> 5500=>505000 uses 10000
>>>> 505000 and up uses 1000000
>>>>
>>>> I agree, not very clear... you should only consider the first entry,
>>>> the second one isn't interpreted and is just used as the replacement
>>>> for the token
>>>
>>>
>>>
>>> My confusion is how to determine the ranges. For example, if:
>>>
>>>        0 < scale <=   1000 use    1000
>>>     1000 < scale <=  10000 use   10000
>>> 1000000 < scale           use 1000000
>>>            scale > 1000000 use      ??
>>>
>>> So, you define three points in the scale range (ie: 1000, 10000, 1000000)
>>> so
>>> it is not clear what happens above or below these points, especially
>>> above
>>> and below the top and bottom ones. If this is better defined, then maybe
>>> there is no need for a default case.
>>>
>>> You might do something like:
>>>
>>>
>>> VALUES
>>>       "1000"    "1000"
>>>      "10000"   "10000"
>>>     "100000"  "100000"
>>>    ">100000" "1000000"
>>> END
>>>
>>> So this would interpret the first column as the maxscaledenom to apply
>>> the
>>> token to, with the last one being the default case. I would consider
>>> removing the number after ">" to make it less ambiguous if someone edited
>>> the mapfile and you had something like:
>>>
>>>
>>> VALUES
>>>       "1000"    "1000"
>>>      "10000"   "10000"
>>>     "100000"  "100000"
>>>     "200000"  "200000"  # added this line
>>>    ">100000" "1000000"  # this is confusing at best, conflicts w "200000"
>>>          ">" "1000000"  # this is more clear and does not depend
>>>                         # on the user editing two lines
>>> END
>>>
>>> Do the scales need to be in ascending or descending order or will you
>>> sort
>>> them if they need to be ordered.
>>>
>>> Then again, I might be over thinking this.
>>>
>>> Thanks,
>>>    -Steve
>
>