RFC 26 - MapServer Terminology Cleanup

[Steve Lime]

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