Requesting __all__ layers vs. wms_name
Closed this issue · 4 comments
Hi there,
currently there may be two concurrent names that designate 'getting all layers' from OGCServer; one is 'all' and the other one may be what was configured for wms_name under the [map] section in the config file. The latter defaults to 'all', so if no other name was specified, the root layer node in the capabilities document, which actually is a group in WMS terms, is named 'all'. According to WMS specs, requesting a named group layer should actually return all its child layers in the order as they appear in the caps document. So, if wms_name is left to its default name 'all' (the name of the root layer node), everything works as expected and satisfies WMS standards and also allows clients to get the whole map "as seen by Mapnik", that is something like the "real" Mapnik map.
However, since in _buildMap the token 'all' is still hard-coded, things get odd if someone configures a different name for wms_name. The configured name is not valid in the LAYERS parameter and throws a 'LayerNotDefined' exception. Still one has to request for 'all'.
One obvious solution is to replace the hard-coded 'all' token in _buildMap with the name configured for wms_name. Easy as that. However, since this is closely related to WMS groups, things may be more complicated.
In code, the comments at the 'all' branch in _buildMap state, that this is intended to provide a map like plain Mapnik does. Call it the "real" Mapnik map. Since all layers under the root layer node (group) are actually in Mapnik order, this "real" Mapnik view of the map exactly matches the root layer group according to WMS. However, I we add support for additional WMS groups, these two maps may be different.
Also the currently implemented meta layers, that expose all named rules of a style as separate layers in the form <layer_name>:<named_rule_1>-<named_rule_2> breaks this concept and makes the WMS root layer group define a map different from the "real" Mapnik map.
BTW, the meta layers based on named rules feature is poorly implemented; since a layer's abstract text is preferred over its name (which is mostly an empty string), most of these meta layers are actually named :<named_rule_1>-<named_rule_2> (with no layer name). Is this a permanent feature or is it just a quick hack like the Haiti stuff?
So, how to deal with the problems of wms_name and 'all' highly depends on what other WMS features we plan to implement, notably meta layers for named rules and WMS groups.
If we agree to guarantee, that there will always be only one root layer group that only contains the "real" Mapnik layers (that is, no WMS groups and removing the mete layers based on named rules), we should actually replace the hard-coded 'all' in _buildMap with wms_name. Additionally, we should provide a better integration of this single (and only) root layer group. Notably we should support requests like LAYERS=buildings,streets,all,rivers etc. That's easy to achieve.
If we agree to support arbitrary WMS layer groups and like to keep the meta layers based to named rules, we must keep wms_name and 'all' separated. We'll likely need a new configuration file type for WMS groups. Most suitable will be a hierarchical format, like XML or JSON. Maybe we still keep a key/value base config file and go for an additional hierarchical groups.conf file. Then, we should treat the root layer group as a regular group and so replace wms_name by the new regular group definition syntax. However, since I want to get rid of the term 'all' (some commercial clients have problems with these double underscores), I'd like to make this extra non-WMS backdoor for getting plain Mapnik maps configurable as well.
Carsten
Hi Carsten,
About the meta-layers, I've never used them, not played with that code.
The idea is to create a wms.json file, and include different sections in it. One of this sections would be "layers" which should be an hierarchical structure, with groups and layers as in the WMS spec. The layers must reference a valid layer in the mapnik's style file. We will be able to specify the layer title, a feature that was removed from Mapnik as it was too WMS oriented. Also, we might have a "type=mapnik" parameter, so we can have "type=wms" and other values and turn OGCServer into a full wms server :)
The root layer in this config file should have a name property, which:
- defaults to
__all__if it is omitted - can have a name, thus you can request it using that name. Maybe we should still allow for
__all__in this scenario, for backwards compatibility in case someone uses a name and still expects the__all__thing to work - can be None, in that case it is explicity disabled and you cannot request the root layer
The wms.conf should also include some configuration that is currently handled in ogcserver.conf. Most noticeable the wms_* configuration.
What do you think?
Hi Manel,
ok, a JSON file seems the best solution here. Shall this file replace the current config file? Maybe that is also an option, since you can always have a section like 'server' or 'service' or whatever.
Your idea of "type=wms" or "type=mapnik" is a config option, right? (either in ogcserver.conf or in wms.json) What if "type=mapnik"? Will you then ignore all layers from wms.json and still build all Mapnik layers in a single root layer group (as doing currently)?
I'm thinking about a way to combine both types WMS and Mapnik in one server and in one capabilities document... Assuming, that "type=mapnik" shall provide the "real" Mapnik map, both types have their use-cases and are important.
I will think about this some more time and will come back with a list of requirements and recommendations for this feature.
Carsten
Hi Carsten,
Yes, the wms.json file can replace the current config file. We need to create a simple migration script though.
type="mapnik/wms" is a Layer option, if it is a mapnik layer you fetch it from the styles document and render it. If the type is "wms", we use requests or owslib to fetch it.
This way mapnik layers can be mixed with other layers, say a base aerial layer from a wms service.
Hi Manel,
ok. I understand, "type=wms" makes OGCServer a cascading WMS server. However, since, for my mind, is a VERY optional feature for a WMS server, I recommend to focus on basic group support in the first place. However, for the following specifications I will keep in mind, that there may be other, external layers (likely coming from other WMS servers), that need special configuration.
I decided to close this issue right now and open a new one, dedicated to WMS Layer Group Support.