2010/11/23 Dominic Lowe <[email protected]> > > > So each and every layer would have a unique position attribute. > > Which I should add, may change each time you hit the capabilities document > as there is no requirement on the server to be consistent in the ordering. > > (And sorry for all the typos in the last email!) > > Dom > > > > > > On 23/11/10 14:02, Dominic Lowe wrote: > >> Hi Ivan, >> >> I'm don't mean to give the impression I'm totally against such a patch >> by any means, I'm just not sure ordering is even there as a concept in >> WMS. All the spec says is that you have zero to many layer elements. It >> doesn't say that the ordering of these is significant (respecting any >> hierarchies they may be in). >> >> And I'm not an expert on WMS, but my understanding was that the >> hierarchical layers were just there for grouping and inheritance of >> attributes (e.g. the Bounding box). I wasn't even aware that you should >> be able to requests an ordered group of layers by requesting the topmost >> layer of a hierarchy - and I can't see anywhere in the WMS where it says >> you should be able to do this. >> >> However I'm not denying that's these aren't nice/useful features - just >> not sure they are part of the WMS standard or that layer order matters >> (apart from the hierarchical relationships). >> >> But being a bit more pragmatic, if capturing order is truly useful then >> we should consider of course consider the patch. Maybe an alternative >> approach though might be to capture absolute position like this: >> >> 1 >> 1.1 >> 1.2 >> 1.3 >> 1.3.1 >> 1.3.1 >> 2 >> 2.1 >> 2.2 >> 2.2.1 >> 2.2.2 >> 2.2.2.1 >> etc. >> >> So each and every layer would have a unique position attribute. >> >> Cheers, >> >> Dom >> >> Hi Dominic,
Yes, You are right about using nested layers for inheritance of attributes. But in WMS specification there are some notes about layer categories (groups). Take a look at section about layer's properties, especially the Name: 7.1.4.5.2 Name If, and only if, a layer has a <Name>, then it is a map layer that can be requested by using that Name in the LAYERS parameter of a GetMap request. If the layer has a Title but no Name, then that layer is only a category title for all the layers nested within. A Map Server that advertises a Layer containing a Name element shall be able to accept that Name as the value of LAYERS argument in a GetMap request and return the corresponding map. A Client shall not attempt to request a layer that has a Title but no Name. A server shall throw an exception (code="LayerNotDefined") if an invalid layer is requested. A containing category itself may include a Name by which all of the nested layers can be requested at once. For example, a parent layer "Roads" may have children "Interstates" and "State Highways" and allow the user to request either child individually or both together. The Name is not inherited by child Layers. [ http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf(page 37/25)] So the specification allow using nested layers in two ways - for inheritance properties and for creating categories of layers. And it seems that current version of OWSLib doesn't support second use case very well. The biggest problem is setting constant name "unnamed_layer" for every category layer, cause it will be also used as key in WebMapService.contents dictionary and therefore multiple layer categories will be always replaced by the last one. Although order of the children layers in their category is not mentioned and it may be questionable, but we would appreciate it. Marcel
_______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
