[mapserver-users] Status on ticket 2582?

Martin Kofahl m.kofahl at gmx.net
Sun Feb 22 09:02:39 EST 2009


Hi,
I did add a patch for ms540-b1 to ticket #1952 
[http://trac.osgeo.org/mapserver/ticket/1952]. It uses a 
ows_hidden_layer metadata and does also solve ticket #2582. It does also 
work for layers grouped by using the wms_layer_group metadata and does 
otherwise work as described i my last post.

Martin

paalkr wrote:
> Hi all!
> 
> See my comments in italic below
> 
> 
> Martin Kofahl wrote:
>> Hi,
>> I think the second patch for ticket 1952 already covers some of these
>> issues for the wms service (one can easily change ows_service to 
>> ows_hidden_layer -- I think 'hidden' makes even more sense than 'ignore'):
>>
>> I agree, and I have actually used your patch with great success in many
>> cases.
>>
>>> 1) The hiding mechanism must not interfere with which layers that 
>>> actually are rendered (turned on).
>> ... only suppresses the capabilities output.
>>
>> Perfect
>>
>>> 2) What will happen if the hidden layer is inside a GROUP?
>> ... the single layer is hidden
>>
>> As expected
>>
>>> 3) What will happen if all layers inside a GROUP is hidden?
>> ... as far I remember, the mentioned patch currently hides the whole
>> group and its layers. In order to support grouped layers for different
>> resolutions, my workaround was to hide any layer in this group (hence no
>> capabilities) and to have a single not-grouped, not-hidden layer with
>> the name identical to the group name.
>> When all grouped layers are hidden and we decide to expose it as a sigle
>> layer as Pål suggests, the question is which metadata to use.
>>
>> I did not think of the opportunity to have single layer with the same name
>> as the group, but this sounds like a more sensible solution then
>> transforming a group layer to a single layer. Specially when it comes to
>> decide which metadata to expose.
>>
>>> 4) What will happen if the hidden layer is part of a group defined 
>>> with the wms_layer_group metadata tag?
>> ... should work similar to 2 und 3. But currently I have no idea what 
>> the patch does with wms_layer_group layers.
>>
>> Me neither :-)
>>
>> Regards,
>> Pål Kristensen
>>
>> paalkr wrote:
>>> Hi All!
>>>
>>> I glad this issue got some focus, and I must say that I was kind of 
>>> surprised realizing that ticket 2582 only addressed the MapScript 
>>> part. Anyway, I'm very glad that Jeff now proposes a final solution 
>>> for this issue, that of course should be fixed in both cgi and 
>>> MapScript, and for every service type.
>>>
>>> Jeffs proposal for a boolean metadata keyword, like ignore_layer 
>>> sound OK, but maybe ows_ignore_layer is more appropriate as the layer
>>>  obviously shall not be ignored, only the exposure in the 
>>> GetCapabilities document. I think the following aspects are important
>>>  to have in mind when resolving the issue:
>>>
>>> 1) The hiding mechanism must not interfere with which layers that 
>>> actually are rendered (turned on) . This has to be controlled as 
>>> before by the STATUS, SCALE and DEPENDENCIES keywords. 2) What will 
>>> happen if the hidden layer is inside a GROUP? 3) What will happen if
>>>  all layers inside a GROUP is hidden? I would suggest that the group
>>>  layer is exposed as a single layer, in this way you could have 
>>> different resolution layers inside a GROUP and expose this as a 
>>> single layer to the end user. Often the different resolution layers 
>>> are only present to optimize rendering speed, and are not intended 
>>> for the end user. 4) What will happen if the hidden layer is part of
>>>  a group defined with the wms_layer_group metadata tag?
>>>
>>> Regards, Pål Kristensen
>>>
>>>
>>> Jeff McKenna wrote:
>>>> Alan Boudreault wrote:
>>>>> It could. By the fact that a status MS_DELETE can only be set 
>>>>> through Mapscript, i've only added this part. I think the ticket
>>>>>  have been open for that ? You could add a comment in the ticket
>>>>>  to propose a specific mapfile setting.
>>>>>
>>>>> Alan
>>>> I've made a comment in that ticket, and I am proposing we finally 
>>>> fix this through an old existing ticket 
>>>> (http://trac.osgeo.org/mapserver/ticket/337).
>>>>
>>>> -jeff
>>>>
>>>>
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
>>
> 


More information about the mapserver-users mailing list