RFC 26 - MapServer Terminology Cleanup

Sean Gillies sgillies at FRII.COM
Fri May 4 13:15:13 EDT 2007


I've been whining about transparency forever, and am all for the 
changes. Should the project provide mapfile migration tools? A script, a 
new option for shp2img or mapserv? Or could it be called "expanding the 
market for commercial support"? ;)

Sean

Daniel Morissette wrote:
> Oh, while we're at it, should we fix another long term inconsistency: 
> the requirement for a dummy TEMPLATE value to make layers queryable? 
> This is confusing for all non-mapserv users (MapScript, WMS, etc.).
> 
> An option might be to add a QUERYABLE TRUE/FALSE keyword to the layer 
> and class objects, that would determine whether a layer/class is 
> queryable or not. Then to query through the CGI you'd also need to 
> provide a template (or otherwise mapserv would issue an error saying 
> that TEMPLATE was not provided). The big benefit is that MapScript apps 
> (and WMS services) would no longer need to provide dummy templates.
> 
> Daniel
> 
> 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
>>>>>
>>
> 
> 



More information about the mapserver-dev mailing list