[mapserver-dev] RE: INSPIRE compliancy - A request for comments on a possible RFC

[tellett]

Hi Yewondwossen,

Thanks for getting back to us. We're absolutely happy to look at any
solution so long as it meets our requirements and more importantly the
INSPIRE requirements. I'll try and answer your questions inline:


>> - if the goal is to affect the wms  part of MapSever, would it be better
>> to use wms related mechanism >>and metadata to address this?  I am
>> thinking for example of mechanisms used for grouping layers by >>setting
>> the  wms_layer_group metadata.  
>>It obviously does not do all that is needed but I like the fact that It
does not introduce new concepts >>of hierarchy and keywords in MapServer
core and development is  constrained to the wms module.  Can >>similar
approach make sense or can the wms_layer_group be extended to address the
problem? 

Problem with wms_layer_group is that it is not a named layer and therefore
cannot be called in a getmap of featureinfo request and in addition is only
constructed in the capabilities document through the kvp name and keywords
from the sublayers. We need more metadata attached to this layer (same
amount and options as for a 'normal' mapserver layer) and need it to be a
named layer. Have found this ticket, don't think anything happened to it,
but what Bart describes might deliver what we're looking for as well.
http://trac.osgeo.org/mapserver/ticket/1632  

>>- assuming that we have the possibility to virtually combine layers, would
you see a need to have a >>new layer type?  From what I can see the layer
type is not used much except in DescribeLayer to allow >>the service to
advertise either a wfs or wcs link to the wms layer.

The advantage of a new layer type is that you can add metadata, which is
required, and control the draw order of the different layers. in addition it
can be used to aggregate some of the information from sublayers such as
bounding boxes for use in the capabilities file. It would also be used to
aggregate data for getfeatureinfo and getlegend requests. 

>>- there is also something that is a bit unclear to me is how we should
address attributes for these >>combined (grouped) layers: if I have several
low level (MapServer level) layers with different schemas, >>how would a
user effectively describe the layer and do things like GetMap request with
an SLD that has >>a filter encoding (attributes)? Should we assume a common
set of attributes?

Hmm, must admit I'm not sure about this one. Would it not be possible to get
a list of the featuretypes using the ....describefeaturetype call before
then getting individual featuretype specific info through the
describefeaturetype&typename=featuretype call? If this info is possible to
get then I presume its possible to use an SLD?
 
>>- Related to the issue above,   would you expect the DescribeLayer
operation to provide one feature >>type or several feature types for
combined layer?   Would wfs module need to be aware of the
>>grouping/hierarchy?

Several feature types as noted above.I'm not exactly an expert in this area
though!!
 
>> - Note that I agree with you that a key component is to be able to
>> address the hiding/layers in OGC >>need mentioned in your document
>> regardless of the approach taken to build hierarchy

Yes, this is important. If multi-geometry layers were possible maybe this
option would be ok, but I still fear we may trip up due to generalisation
(nested group layers?)

Hope these answers clear things up a little, just let me know if things are
still not clear!

Cheers

Tom


-- 
View this message in context: http://osgeo-org.1803224.n2.nabble.com/INSPIRE-compliancy-A-request-for-comments-on-a-possible-RFC-tp5661761p5720689.html
Sent from the Mapserver - Dev mailing list archive at Nabble.com.