Bug report #15086
Inconsistency between layernames in WMS and WFS
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | QGIS Server | ||
Affected QGIS version: | 2.14.0 | Regression?: | No |
Operating System: | Ubuntu | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 23028 |
Description
There is inconsistency between WMS and WFS layer names when calling a layer with a space in the name. This makes it difficult programmatically to use a combination of WMS and WFS.
Case:
I have a qgis-project which contains a layer with a space in the name, e.g. 'Skov fra fot'. The qgis-project is published as a WMS and WFS with QGIS Server (ubuntu).
In the WMS GetCapabilities-call, the name contains the space:
However in the WFS GetCapabilities-call, the space is replaced with '_' in the name.
According to the WFS-specification, the name needs to be a QName which does not allow spaces (https://en.wikipedia.org/wiki/QName). However, it seems there is no name-restriction in the WMS-specification.
Idea for solutions 1:
To ease programming, it would be good if the WMS and WFS followed the same rule when a layer contained a space (and other special characters). Since the WFS specification does not allow spaces, the same rule could be applied to the WMS. However, this will impact existing services.
Idea for solution 2:
If Idea 1 is not durable, then it should be possible to use the setting 'Use layer ids as names'. This works on WMS but not on WFS - where the layername is not changed to layerid (see #15085)
Related issues
History
#1 Updated by Mie Winstrup over 8 years ago
- File WFS_call.png added
- File WMS_call.png added
- File WMS_use_layernames_as_ids.png added
- File WFS_use_layernames_as_ids_001.png added
#2 Updated by Jukka Rahkonen over 8 years ago
For comparison I add some links to an implementation proposal and the discussion that followed in the Geoserver project:
https://github.com/geoserver/geoserver/wiki/GSIP-127
http://osgeo-org.1560.x6.nabble.com/Regression-in-2-7-x-valid-coverage-names-are-rejected-because-not-valid-xml-names-tt5183102.html
I believe that the best that can be done would be to inform user: This layer name is invalid as a WFS typename, reason:[] Do you want to:
a) Rename the the layer so that it is valid for both WMS and WFS
b) Keep the name for WMS and let QGIS to convert the name into valid typename for WFS
#3 Updated by Mie Winstrup over 8 years ago
Jukka Rahkonen wrote:
For comparison I add some links to an implementation proposal and the discussion that followed in the Geoserver project:
https://github.com/geoserver/geoserver/wiki/GSIP-127
http://osgeo-org.1560.x6.nabble.com/Regression-in-2-7-x-valid-coverage-names-are-rejected-because-not-valid-xml-names-tt5183102.htmlI believe that the best that can be done would be to inform user: This layer name is invalid as a WFS typename, reason:[] Do you want to:
a) Rename the the layer so that it is valid for both WMS and WFS
b) Keep the name for WMS and let QGIS to convert the name into valid typename for WFS
Maybe it would be best if QGIS convert spaces in names to '_' for WMS, since the WFS specification does not allow spaces?
#4 Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#5 Updated by René-Luc ReLuc about 7 years ago
- Description updated (diff)
The layer name in WFS has to be compatible with an XML element tag name. It is not only used in URL has apram, it is also used to defined the Feature XML element tag name.
#6 Updated by René-Luc ReLuc about 7 years ago
Used the shortname to avoid this difference.
#7 Updated by Giovanni Manghi about 7 years ago
- Status changed from Open to Closed
René-Luc ReLuc wrote:
Used the shortname to avoid this difference.
so this can be closed?