I'm using GeoServer's and App-Schema-Plugin's current stable version 2.8.2
for complex feature mappings. In general this is working fine. While doing
some WFS requests I noticed a difference between the output of a gml polygon
property with WFS version 1.1.0 (GML 3.1.1) and the same property with WFS
version 2.0.0 (GML 3.2.1).
this is the WFS 1.1.0 output for the geometry property of my feature type:
<iso19112:geographicExtentPolygon>
<gml:Polygon gml:id="polygon.dog_hauskoordinaten.2395723" srsDimension="2"
srsName="urn:x-ogc:def:crs:EPSG:25832">
<gml:exterior>
<gml:LinearRing srsDimension="2">
<gml:posList>695559.9950007958 5762290.559994311 695559.9950007958
5762291.559994311 695560.9950007958 5762291.559994311 695560.9950007958
5762290.559994311 695559.9950007958 5762290.559994311</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</iso19112:geographicExtentPolygon>
this is the WFS 2.0.0 output of the same property of the feature type:
<iso19112:geographicExtentPolygon>POLYGON ((695559.9950007958
5762290.559994311, 695559.9950007958 5762291.559994311, 695560.9950007958
5762291.559994311, 695560.9950007958 5762290.559994311, 695559.9950007958
5762290.559994311))</iso19112:geographicExtentPolygon>
The underlying database is a postgis database and the column used for this
property mapping is a geometry column. This is the corresponding property
mapping of the feature type:
<AttributeMapping>
<targetAttribute>iso19112:geographicExtentPolygon</targetAttribute>
<idExpression><OCQL>strConcat('polygon.', getId())</OCQL></idExpression>
<sourceExpression><OCQL>geographicextent</OCQL></sourceExpression>
</AttributeMapping>
The schema definition for the property is the following:
<xsd:element name="geographicExtentPolygon" type="gml:SurfacePropertyType"
minOccurs="0"></xsd:element>
I'm a bit confused why the WFS 2.0.0 output shows the WKT of the geometry
column instead of a gml geometry representation. I'm not sure if this is the
intended behaviour or if I have a flaw in my configuration.
If I change the outputFormat to "GML3" for the WFS 2.0.0 request I receive
the same response as if I requested the WFS in version 1.1.0.
I’m using GeoServer’s and App-Schema-Plugin’s current stable version 2.8.2
for complex feature mappings. In general this is working fine. While doing
some WFS requests I noticed a difference between the output of a gml polygon
property with WFS version 1.1.0 (GML 3.1.1) and the same property with WFS
version 2.0.0 (GML 3.2.1).
this is the WFS 1.1.0 output for the geometry property of my feature type: iso19112:geographicExtentPolygon
<gml:Polygon gml:id=“polygon.dog_hauskoordinaten.2395723” srsDimension=“2”
srsName=“urn:x-ogc:def:crs:EPSG:25832”> gml:exterior
<gml:LinearRing srsDimension=“2”> gml:posList695559.9950007958 5762290.559994311 695559.9950007958
5762291.559994311 695560.9950007958 5762291.559994311 695560.9950007958
5762290.559994311 695559.9950007958 5762290.559994311</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</iso19112:geographicExtentPolygon>
this is the WFS 2.0.0 output of the same property of the feature type: iso19112:geographicExtentPolygonPOLYGON ((695559.9950007958
5762290.559994311, 695559.9950007958 5762291.559994311, 695560.9950007958
5762291.559994311, 695560.9950007958 5762290.559994311, 695559.9950007958
5762290.559994311))</iso19112:geographicExtentPolygon>
The underlying database is a postgis database and the column used for this
property mapping is a geometry column. This is the corresponding property
mapping of the feature type:
The schema definition for the property is the following:
<xsd:element name=“geographicExtentPolygon” type=“gml:SurfacePropertyType”
minOccurs=“0”></xsd:element>
I’m a bit confused why the WFS 2.0.0 output shows the WKT of the geometry
column instead of a gml geometry representation. I’m not sure if this is the
intended behaviour or if I have a flaw in my configuration.
If I change the outputFormat to “GML3” for the WFS 2.0.0 request I receive
the same response as if I requested the WFS in version 1.1.0.
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
I'm not sure app-schema can "invent" a new schema on the fly, one that
is based on GML 3.2 instead of GML 3.1
It cannot. Andrea, I am sure your diagnosis and solution are correct.
TRD, a WFS 2.0.0 request is required to default to a GML 3.2.1 response. Because a GML 3.1.1 application schema cannot encode the GML 3.2.1 geometries that app-schema prepares for you (different geometry types in different namespaces), the encoder falls back to encoding the bare WKT.
When using a WFS 2.0.0, try outputformat=gml3 to request a GML 3.1.1 response.
Kind regards,
--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
Setting explicit output format of "GML3" then the WFS response is properly
encoded. That's what I meant when I wrote that by switching to this output
format the response is the same as requesting the WFS in version 1.1.0.
I just wanted to make sure that I'm not missing a mapping specific option.
So, thank you for your explanation why this doesn't work.