RFC 26 - MapServer Terminology Cleanup

[Daniel Morissette]

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
>>>


-- 
Daniel Morissette
http://www.mapgears.com/