Opened 15 years ago
Closed 14 years ago
#2989 closed enhancement (fixed)
WMS GetFeatureInfo: provide an option to output geometry
Reported by: | bartvde | Owned by: | dmorissette |
---|---|---|---|
Priority: | normal | Milestone: | 5.6 release |
Component: | WMS Server | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | richard@…, dmorissette, assefa, tomkralidis, sdlime |
Description
There has been a lot of discussion in the past about whether or not WMS GetFeatureInfo should output the geometry or not. Currently Mapserver does not do this by default, but there are situations in which users want to output the geometry for WMS GetFeatureInfo. So the proposal is to make this configurable using METADATA and to keep the default as is (output no geometry).
A related discussion can be found in ticket:300
I'll attach a patch done by a colleague of mine.
Attachments (1)
Change History (26)
by , 15 years ago
Attachment: | mapserver-5.2.0-geomInFeatureinfo.patch added |
---|
comment:1 by , 15 years ago
Cc: | added |
---|
comment:2 by , 15 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Bart: thanks.
Before we go ahead, I think this is a viable temporary solution until the ticket:300 issues get ironed out. I'm not sure how long that will take, however.
danmo/assefa: are there any objections to applying this patch?
comment:3 by , 15 years ago
Hold on... I thought there was already a way to return the geometry in a GML WMS GetFeatureInfo response. I'll have to check and get back to you.
comment:5 by , 15 years ago
Cc: | added |
---|
I had another look at the code, and there is indeed currently no way to include the geometry in GetFeatureInfo results, and passing the geometryList argument to gmlWriteGeometry() instead of NULL as suggested in the patch would solve this.
However what bugs me is the new WMS/OWS_GEOMETRY_IN_FEATUREINFO metadata. Instead of adding another metadata, could we not find a way to manage this with the existing metadata? WE've already got the gml_include_items, and gml_geometries mechanisms to control some of the stuff... we don't need a third mechanism that doesn't integrate with them.
Perhaps gml_include_items "item1, item2, msGeometry" could do it? Unless we think that some people might want geometries for a given layer in WFS GetFeature only and not in WMS GetFeatureInfo, which would be the only reason to require different settings for WMS and WFS.
comment:6 by , 15 years ago
FYI I'm working on a patch that will (hopefully) allow controlling the geometry settings separately for WMS and WFS with the existing metadata, just by taking advantage of the namespaces prefix in metadata (WMS_*, WFS_*, OWS_*), let's hope it won't break something else.
comment:7 by , 15 years ago
Dan: any update on this per comment:6? Should I pass this to you/your patch?
comment:8 by , 15 years ago
Milestone: | 6.0 release → 5.6 release |
---|---|
Owner: | changed from | to
I was about halfway when I got interrupted and then it got shifted down by other priorities as happens too often unfortunately. I'll try to finish it ASAP.
comment:9 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I have committed a fix in r9405 that allows one to enable output of geometry in GML2 WMS GetFeatureInfo if the wms_geometries and wms_geom_type metadata are specified. (ows_* and gml_* metadata prefixes also work for this).
By default, WMS GetFeatureInfo in GML2 format does not include the geometry. To enable it, add those metadata to your layer(s). e.g. for a point layer
LAYER TYPE POINT ... METADATA "ows_geometries" "mygeom" "ows_mygeom_type" "point" END ... END
See the docs for gml_geometries and gml_[name]_type in http://mapserver.org/ogc/wfs_server.html. The same rules apply here except that there is no default geometry if *_geometries is not specified.
comment:11 by , 15 years ago
Daniel: looking at this further, earlier behaviour was to output a bounding box of the feature (see msautotest/wxs/expected/wms_get_feature_info_vector.gml
). At this point, either no geometry at all is output, or full geometry is output if metadata is set.
I think it is still valuable to output the bounding coordinates, in either case. What do you think?
comment:12 by , 15 years ago
Um. Thanks for testing and reporting this issue. I didn't realize the value of the boundingbox by itself, but since it was there before I have no good reason to take it out. I have restored the bbox as the default behavior in r9419, so now we have the following behavior for WMS GetFeatureInfo in GML2 format:
- by default, no geometry output, only the bounding box of the feature (<gml:boundedBy>)
- geometry output can be enabled using gml_geometries and gml_[name]_type metadata as explained earlier
- the bounding box (and geometry) can be disabled using the "gml_geometries" "none" metadata
comment:13 by , 15 years ago
Daniel: thanks for this. Now I get both the bounding box _and_ the geometry output as default. Tested against msautotest/wxs/wms_simple.map. You'll see a failure on wms_getfeatureinfo130.xml
comment:14 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Argh! Not sure how I managed to miss that mistake! Anyway, I fixed things in r9426 so that we really get only the bbox by default.
Upon further testing Tom pointed out that the SRS and coordinates in the output don't match. I see that this is a deeper issue in the pre-existing code, so I'll look at it after beta3. Reopening ticket.
comment:15 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I have committed a fix in r9455 for the coordinate reprojection problem. msGMLWriteQuery() was not properly keeping track of its output SRS.
comment:18 by , 14 years ago
A question on this one, how would I go about disabling output of geometries for WMS GetFeatureInfo, but explicitly getting WFS to always output multipolygons?
I used to have:
"GML_GEOMETRY_TYPE" "multipolygon" "GML_GEOMETRIES" "geometry"
I tried changing to:
"WFS_GEOMETRY_TYPE" "multipolygon" "WFS_GEOMETRIES" "geometry"
which gives me no geometry in WMS GetFeatureInfo, which is okay, but gives me a polygon instead of a multipolygon in WFS output.
comment:19 by , 14 years ago
I think the following patch should fix the issue raised byBart. I do not see any side effect. Could some one confirm it:
Index: mapgml.c =================================================================== --- mapgml.c (revision 9594) +++ mapgml.c (working copy) @@ -1502,7 +1502,7 @@
itemList = msGMLGetItems(lp, "G"); constantList = msGMLGetConstants(lp, "G"); groupList = msGMLGetGroups(lp, "G");
- geometryList = msGMLGetGeometries(lp, "G");
+ geometryList = msGMLGetGeometries(lp, "GFO");
if (namespace_prefix) {
layerName = (char *) malloc(strlen(namespace_prefix)+strlen(lp->name)+2);
comment:20 by , 14 years ago
Index: mapgml.c =================================================================== --- mapgml.c (revision 9594) +++ mapgml.c (working copy) @@ -1502,7 +1502,7 @@ itemList = msGMLGetItems(lp, "G"); constantList = msGMLGetConstants(lp, "G"); groupList = msGMLGetGroups(lp, "G"); - geometryList = msGMLGetGeometries(lp, "G"); + geometryList = msGMLGetGeometries(lp, "GFO"); if (namespace_prefix) { layerName = (char *) malloc(strlen(namespace_prefix)+strlen(lp->name)+2);
comment:21 by , 14 years ago
committed last patch in trunk r9619. Bart, can you confirm that it works for you?
comment:22 by , 14 years ago
There is another related issue with this approach, also the WFS DescribeFeatureType does not listen to WFS_ metadata, so this is returned:
<element name="msGeometry" type="gml:GeometryPropertyType" minOccurs="0" maxOccurs="1"/>
instead of:
<element name="geometry" type="gml:MultiPolygonPropertyType" minOccurs="0" maxOccurs="1"/>
comment:23 by , 14 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:25 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Thanks, all seems fine now.
Patch implementing optional GetFeatureInfo geometry