RFC 26 - MapServer Terminology Cleanup

[Steve Lime]

I agree with you on the scale change, but that's probably because I am so
used to it. I have seen other projects, I believe OpenLayers is one, that use
a similar approach. Anything that helps learning the software is a good thing
so...

Steve 

>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM> 05/04/07 12:14 PM >>>
I hate the SCALE -> SCALEDENOM chage, but I can live with it.
I also like the parser error that is constructive.

Another problem with the 1: is that it implies that other numerators 
might also be valid. Maybe not as a GIS standard, but certainly from a 
math point of view.

-Steve

Daniel Morissette wrote:
> Not sure about the "1:..." prefix. Sounds cool but just adds complexity 
> to the code and docs and doesn't bring any functional benefit so I would 
> say we stick to scale denominators.
> 
> I reviewed the RFC and I like what you propose for both scale and 
> opacity. Sounds like a neat solution to this termiology problem.
> 
> Perhaps one little change: since we're breaking compatibility anyway, we 
> might as well force users to align to the correct terminology and NOT 
> keep the deprecated TRANSPARENCY and SCALE in the parser. Instead, make 
> those keyword issue a fatal parsing error saying something like:
> 
> "Keyword TRANSPARENCY has been renamed OPACITY in MapServer 5.0. Please 
> update your mapfile."
> 
> Same for the other keywords, we could keep that error message around for 
> a few releases. This way even users that don't read the migration guide 
> would know right away what's going on.
> 
> Finally, I agree with the need for a Migration Guide for 5.0 to document 
> this kind of changes (like we had for 4.0 and 4.10). I have started a 
> 5.0 migration guide doc in the "Development/Release Plans" area of the 
> website:
> 
> http://mapserver.gis.umn.edu/development/release_plans/migration_guide_410_50 
> 
> 
> Daniel
> 
> 
> Steve Lime wrote:
>> We talked about the proceeding 1: option. That would work fine from a 
>> mapfile but
>> not as easily from mapscript. You'd want to parse once and store the 
>> denominator for use. In mapscript you'd need to use "settter" 
>> functions that would do the parsing
>> and storage of the denominator. I don't know which is better. Changing 
>> the parameter
>> is basically a search and replace exercise and would be faster.
>>
>> I'm fine with breaking some backwards compatibility at the mapfile 
>> level if folks feel it
>> is warranted. Now is the time.
>>
>> I agree on the documentation issue...
>>
>> Steve
>>
>>>>> On 4/27/2007 at 10:33 AM, in message
>> <f3b73b7d0704270833h7912ed02y677fd3a4370ad595 at mail.gmail.com>, Tamas 
>> Szekeres
>> <szekerest at GMAIL.COM> wrote:
>>> Steve,
>>>
>>> In general, I think the upcoming 5.0 is the right place to break the
>>> backward compatibility if it is really needed. However we should make
>>> clear the steps of the transition of the existing projects in a
>>> migration guide documentation.
>>>
>>> Upon introducing the OPACITY parameter I would not retain the existing
>>> TRANSPARENCY parameter as it stands now. I would not allow the user to
>>> keep and get used to the unconvenient practice. If we would eventually
>>> keep TRANSPARENCY side by side we should alter the value
>>> interpretation to 100-OPACITY or so.
>>>
>>> I could accept the introduction of the SCALEDENOM parameter. However
>>> I'm not totally sure whether it's widely used in the GIS terminology
>>> or not. Anyway, I would also keep the current parameter names by
>>> parsing a preceding "1:" as described at
>>> http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Setting_the_ma 
>>> p_scale
>>>
>>> Best regards,
>>>
>>> Tamas
>>>
>>>
>>>
>>> 2007/4/27, Steve Lime <Steve.Lime at dnr.state.mn.us>:
>>>> Hi all: Another 5.0 RFC. This one involves fixing some terminology 
>>>> issues 
>>> that have tended to confuse folks learning the software over the years.
>>>>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-26
>>>> In a nutshell we are proposing altering several mapfile and C 
>>> representations of confusing parameters (e.g. ...SCALE and 
>>> TRANSPARENCY). Mapfile level backwards compatability would be 
>>> preserved (e.g. TRANSPARENCY 75 and OPACITY 75 would produce the same 
>>> result). However, C/MapScript API compatability would be broken at 
>>> 5.0 for these parameters (e.g. $layer->{transparency} would break and 
>>> would need to be changed to $map->{opacity} = 75.
>>>> Comments welcome.
>>>>
>>>> Steve
>>>>
> 
>