[mapserver-dev] RFC-86: scale dependant DATA substitutions
Lime, Steve D (DNR)
Steve.Lime at state.mn.us
Mon Oct 8 19:32:14 PDT 2012
Interesting... I like it. I think I'd consider defining a default value for the top level, kinda like class expressions work so you'd
SCALETOKEN
NAME "ex1"
VALUES
1000 "foo"
5000 "bar"
10000 "baz"
END
DEFAULT "baf"
END
Using integers for simplification this would translate to:
0-1000 => foo
1001-5000 => bar
5001-10000 => baz
10001 and up => baf
Basically the values always define a range. I need to dig out some layer snippets where I use this approach and see if this covers them. I have a feeling it doesn't, at least for shapefiles. Consider your example 3. With non-RDBMS sources maybe you'd want to replace/augment FILTERs and leave the DATA element alone.
Steve
________________________________________
From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] on behalf of thomas bonfort [thomas.bonfort at gmail.com]
Sent: Monday, October 08, 2012 3:26 PM
To: Smith, Michael ERDC-RDE-CRREL-NH
Cc: mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] RFC-86: scale dependant DATA substitutions
(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?
--
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
>
_______________________________________________
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