[mapserver-dev] RFC-86: scale dependant DATA substitutions
Stephen Woodbridge
woodbri at swoodbridge.com
Mon Oct 8 14:02:21 PDT 2012
On 10/8/2012 4:26 PM, thomas bonfort wrote:
> (in case this wasn't clear, this still is the commenting/discussion
> phase, I'm not clutching onto my initial proposal)
>
> that said:
>
> - the need for consistency between our already established
> minscale/maxscale is important
>
> - I dislike the proposal to need to specify minscale *and* maxscale
> inside a scaletoken block, as it implies that the user must make sure
> that the provided intervals are contiguous, which in turn leads to a
> repetition of bounds, i.e:
> min1/max1: "foo"
> max1==min2/max2: "bar"
> max2==min3/max3: "baz"
> etc...
>
> the mapfile syntax and/or parser intelligence to define these would
> also be clunky.
>
> - I like Mike's proposal of only defining the max scale, although I'd
> put it the other way around as we know the minscale is always 0, but
> we never know the maxscale. The key=>value entries would be
> minscale=>value, eg:
>
> 0: "foo"
> 1000: "bar"
> 2500: "baz"
>
> which would translate to:
> [0-1000[ : "foo"
> [1000,2500[: "bar"
> [2500-infinity[: "baz"
>
> would that work?
Yes this would work for me. I was trying to say this but with maxscale
instead of the minscale values. I don't like the idea of putting both
min and max as a range in the scale column because of all the reasons
you site above. This last scheme keeps it consistent with existing
mapfile behavior. A very acceptable compromise.
Thanks,
-Steve W
> --
> thomas
>
>
> On Mon, Oct 8, 2012 at 10:06 PM, Smith, Michael ERDC-RDE-CRREL-NH
> <Michael.Smith at erdc.dren.mil> wrote:
>> I have to say that I read it more like Steve W did, I thought those values
>> would be MAXSCALEDENOM values that moved it from one DATA substitution to
>> another.
>>
>> Since that is already an accepted keyword and its meaning well understood,
>> is there a good reason to not use the listed value(s) as MAXSCALEs?
>>
>> Mike
>>
>> --
>> Michael Smith
>>
>> US Army Corps
>> Remote Sensing GIS/Center
>>
>>
>>
>> On 10/8/12 3:40 PM, "thomas bonfort" <thomas.bonfort at gmail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
More information about the mapserver-dev
mailing list