RFC 26 - MapServer Terminology Cleanup

Steve Lime Steve.Lime at DNR.STATE.MN.US
Mon May 7 10:08:56 EDT 2007


Is there a way we could do this in the code without adding a new parameter? I'm
thinking probably not since you can use layers with WxS service parameters defined
with the CGI or MapScript... So, I would propose recognizing the template or a queryable
parameter. Since we have a function like msIsLayerQueryable that should be easy
enough.

Steve

>>> Daniel Morissette <dmorissette at MAPGEARS.COM> 05/04/07 11:13 AM >>>
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
>>>>
> 
> 


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



More information about the mapserver-dev mailing list