[mapserver-dev] RFC-86: scale dependant DATA substitutions
Smith, Michael ERDC-CRREL-NH
Michael.Smith at usace.army.mil
Mon Dec 10 16:11:35 PST 2012
+1
Mike
--
Michael Smith
US Army Corps
Remote Sensing GIS/Center
From: thomas bonfort <thomas.bonfort at gmail.com<mailto:thomas.bonfort at gmail.com>>
Date: Monday, December 10, 2012 11:15 AM
To: "Lime, Steve D (DNR)" <Steve.Lime at state.mn.us<mailto:Steve.Lime at state.mn.us>>
Cc: "mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>" <mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>>, Michael Smith <michael.smith at erdc.dren.mil<mailto:michael.smith at erdc.dren.mil>>
Subject: Re: [mapserver-dev] RFC-86: scale dependant DATA substitutions
All,
I've updated the RFC at [1] to take into account the syntactical remarks that were made.
A test mapfile showing the proposed syntax can be seen at [2]. I've settled on the syntax that doesn't require explicitly setting a DEFAULT substitution value, i.e.:
scaletoken
name "%myvariable%"
values
0: "foo"
1000: "bar"
2500: "baz"
end
end
which would translate to:
[0-1000[ : "foo"
[1000,2500[: "bar"
[2500-infinity[: "baz"
This implies that the first VALUES entry must be 0 (checked for by the parser), and that the last entry's implicit maxscale is infinity.
In addition to the original RFC, substitutions are also applied for TILEINDEX, TILEITEM, FILTER and FILTERITEM.
I'll call for a vote on this one soon, unless there's any more discussion around this in the coming days.
cheers,
thomas
[1]: http://mapserver.org/trunk/development/rfc/ms-rfc-86.html . Might take a few hours to propagate, http://ci.mapserver.org/job/docs62/lastBuild/artifact/build/html/en/development/rfc/ms-rfc-86.html is uptodate.
[2]: https://github.com/tbonfort/msautotest/blob/fb4c6ac5229a6c4ac7fe7039c218bed26b1273a4/misc/scaletoken.map
On Tue, Oct 16, 2012 at 7:28 PM, Lime, Steve D (DNR) <Steve.Lime at state.mn.us<mailto:Steve.Lime at state.mn.us>> wrote:
Nuts, missed this. I'm just thinking that attributes are used all over the place so users that change data sources will need to ensure that the same attributes are common across all of them. It's more a documentation thing. Won't be an issue when just altering the where clause in a select statement.
Steve
-----Original Message-----
From: thomas bonfort [mailto:thomas.bonfort at gmail.com<mailto:thomas.bonfort at gmail.com>]
Sent: Tuesday, October 09, 2012 11:53 AM
To: Lime, Steve D (DNR)
Cc: Smith, Michael ERDC-RDE-CRREL-NH; mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
Subject: Re: [mapserver-dev] RFC-86: scale dependant DATA substitutions
> Which brings me to another potential issue. Often items are going to be different for different data sources for labeling, classification and output (templates). This shared data means the underlying layers will have to have the exact same naming conventions.
I'm sorry Steve, gonna need some clarifications here as the data drivers are new for me, I really don't understand what you mean.
--
thomas
>
> Steve
>
> -----Original Message-----
> From: thomas bonfort [mailto:thomas.bonfort at gmail.com<mailto:thomas.bonfort at gmail.com>]
> Sent: Tuesday, October 09, 2012 9:38 AM
> To: Lime, Steve D (DNR)
> Cc: Smith, Michael ERDC-RDE-CRREL-NH; mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
> Subject: Re: [mapserver-dev] RFC-86: scale dependant DATA
> substitutions
>
> On Tue, Oct 9, 2012 at 4:32 AM, Lime, Steve D (DNR) <Steve.Lime at state.mn.us<mailto:Steve.Lime at state.mn.us>> wrote:
>> 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
> I can live with that, although I don't really like the DEFAULT part, seems awkward...
>
>>
>> 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.
>
> I didn't initially want to touch FILTER, and no having looked at the code, even less. The problem with FILTER is that at the time msLayerOpen is called, filter is an expressionObj that I have no idea how to replace/augment. Any idea if this can be easily done?
>
> I've started working on the implementation, you can see it here:
> https://github.com/tbonfort/mapserver/compare/mapserver:master...tbonf
> ort:rfc86
>
> --
> thomas
>
>>
>> Steve
>>
>> ________________________________________
>> From: mapserver-dev-bounces at lists.osgeo.org<mailto:mapserver-dev-bounces at lists.osgeo.org>
>> [mapserver-dev-bounces at lists.osgeo.org<mailto:mapserver-dev-bounces at lists.osgeo.org>] on behalf of thomas bonfort
>> [thomas.bonfort at gmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<tel: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<mailto:mapserver-dev at lists.osgeo.org>
>>>>http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20121211/a36dff64/attachment-0001.html>
More information about the mapserver-dev
mailing list