Le mardi 10 mai 2016 13:08:07, Rahkonen Jukka (MML) a écrit : > Hi, > > Geoserver breaking GML 3.2.1 schema is even documented in > http://docs.geoserver.org/2.8.3/user/data/app-schema/supported-gml-version > s.html, section GML 3.2.1 geometries require gml:id, including an > application schema example about how to make it GML 3.2.1 compliant. > > So Mapserver WFS 2.0 does not return a FeatureCollection with members with > GetFeatureByID but only a feature. The gml:id "states.1" is in the very > beginning of the GML and it is the gml:id of the feature. In the geometry > there is gml:id "states.1.1" and it means roughly "first geometry of the > feature states.1". However, with GeoJSON as an outputformat the geometry > is wrapped into a FeatureCollection probably because GeoJSON required it > to be so. But would it be wrong to wrap also the GML 3.2.1 output of > GetFeatureByID into a FeatureCollection?
GML output and OGR output in MapServer take very different roads. For GML, MapServer is right to return the result of GetFeatureById as a single feature since this is mandated by the WFS 2.0 spec (an horrible exception that was painful to implement AFAIR since normally GetFeaturebyId should be just a normal GetFeature once the stored query is resolved) : """ 11.3.5 GetFeatureById response Executing a GetFeature operation containing the GetFeatureById stored query (see 7.9.3.6) shall generate a response composed of a single feature encoded according to the values of the outputFormat parameter (see 7.6.3.7). The response shall only contain the feature XML without any of the normal containing elements generated as a result of executing a GetFeature operation (see 11.3.3.4, 11.3.3.5, 11.3.3.6). """ For other output formats, I'm not sure what the WFS spec mandates, but anyway the OGR GeoJSON driver only exports features in a GeoJSON FeatureCollection. > > -Jukka- > > -----Alkuperäinen viesti----- > Even Rouault wrote: > > Le mardi 10 mai 2016 12:32:17, Rahkonen Jukka (MML) a écrit : > > Hi, > > > > Do you mean that the output from GeoServer WFS 2.0 is not valid > > because it does not seem to have gml:id for the collection, nor for > > the geometries, but it does have gml:id for the members? > > > > <wfs:FeatureCollection numberMatched="49" numberReturned="49" > > timeStamp="2016-05-10T10:23:29.813Z" > > xsi:schemaLocation="http://www.opengis.net/wfs/2.0 > > http://localhost:8080/geoserver/schemas/wfs/2.0/wfs.xsd > > http://www.openplans.org/topp > > http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request= > > Desc ribeFeatureType&typeName=topp%3Astates > > http://www.opengis.net/gml/3.2 > > http://localhost:8080/geoserver/schemas/gml/3.2.1/gml.xsd";><wfs:member > > > > ><to pp:states gml:id="states.1"><topp:the_geom><gml:MultiSurface > > > > srsName="urn:ogc:def:crs:EPSG::4326" > > srsDimension="2"><gml:surfaceMember><gml:Polygon><gml:exterior><gml:Li > > near > > Ring><gml:posList> > > Yes, this will not validate the gml 3.2.1 schema. See for example > http://www.datypic.com/sc/niem21/e-gml32_MultiSurface.html gml:id being > compulsory on geometries is one of the main difference between gml 3.2 and > 3.1 > > > -Jukka Rahkonen- > > > > Even Rouault wrote: > > > Le mardi 10 mai 2016 12:08:07, Rahkonen Jukka (MML) a écrit : > > >> Hi, > > >> > > >> WFS output from Mapserver 7.0 in GML contain gml:id > > >> <ms:msGeometry><gml:Polygon gml:id="states.1" > > >> srsName="urn:ogc:def:crs:EPSG::4326"> > > > > > > It looks like you must use WFS 2.0 and/or GML 3.2 output. In that > > > case the GML > > > > 3.2 schemas require each geometry to have a gml:id. So this is a > > geometry id, not a feature id ( in case of geometry collections, > > you'll have one id for the collection and as many ids as members) To > > address that technical requirement, MapServer generates it in a > > sequential way for the output of each request. Not completely sure it > > matches the uniqueness intended but at least it validates schemas. So > > this particular one is not a good candidate to be exported to other > > formats, but I see Thomas has just replied for the feature id. > > > > >> However, with GeoJSON as outputformat the id is missing: > > >> { > > >> "type": "FeatureCollection", > > >> "crs": { "type": "name", "properties": { "name": > > >> "urn:ogc:def:crs:OGC:1.3:CRS84" } }, "features": [ { "type": > > >> "Feature", "properties": { "PK_UID": 1, "STATE_NAME": "Illinois", > > >> > > >> > > >> GeoJSON specification says in > > >> http://geojson.org/geojson-spec.html#feature-objects: "If a feature > > >> has a commonly used identifier, that identifier should be included > > >> as a member of the feature object with the name "id"." > > >> > > >> GeoJSON from Geoserver WFS does contain the id: > > >> > > >> {"type":"FeatureCollection","totalFeatures":49,"features":[{"type": > > >> "Fe ature ","id":"states.1","geometry":{"type":"MultiPolygon" > > >> > > >> Should this be classified as a bug or a candidate for a featere > > >> request? > > >> > > >> -Jukka Rahkonen- > > > > -- > > Spatialys - Geospatial professional services http://www.spatialys.com > > -- > Spatialys - Geospatial professional services http://www.spatialys.com > _______________________________________________ > mapserver-users mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
