RFC 26 - MapServer Terminology Cleanup

[Stephen Woodbridge]

Daniel,

+1 on this, it is an excellent suggestion.

-Steve

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