RFC 26 - MapServer Terminology Cleanup

[Tamas Szekeres]

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