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.
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.
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
