[mapserver-dev] RFC-86: scale dependant DATA substitutions
Smith, Michael ERDC-CRREL-NH
Michael.Smith at usace.army.mil
Mon Oct 8 13:08:18 PDT 2012
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