Marcel, I've now added the patch you sent me (offline) for unnamed layers.
Much appreciated! Dom On 24/11/10 13:04, Marcel Dancak wrote:
2010/11/24 Dominic Lowe <[email protected] <mailto:[email protected]>> Marcel, Thanks - I obviously haven't read the spec closely enough! Selecting a group is a nice feature. > 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. > Yes, that's a problem and needs fixing asap. > Although order of the children layers in their category is not mentioned > and it may be questionable, > but we would appreciate it. Okay, I will plan to add that in too. By the way are you happy about the proposal for: > 1 > 1.1 > 1.2 > 1.3 etc. Yes I do, your proposal looks good to me Also, I don't get much time to spend on OWSlib so if you are happy to contribute a patch for either of these then please do so and I'll merge them in. Okay, I will do it Cheers, Dom On 24/11/10 11:14, Marcel Dancak wrote: 2010/11/23 Dominic Lowe <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[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 <http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf> <http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf <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] <mailto:[email protected]> http://lists.gispython.org/mailman/listinfo/community _______________________________________________ Community mailing list [email protected] <mailto:[email protected]> http://lists.gispython.org/mailman/listinfo/community _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
_______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
