2010/11/24 Dominic Lowe <[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]>> >> >> >> >> > 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 >> > >> (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 >> > > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community >
_______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
