[Geoserver-users] WFS-T: Strange problems with QGIS as a client, data are not saved but SUCCESS is returned

Hi All,

I’m testing the official geoserver 2.8.2 on Linux, I’ve enabled WFS-T transactional on all workspaces.

I’m doing some insert tests using topp: roads, state_boundaries and cities as test layers for linestrings, polygons and points.

Using QGIS as a client, this works:

  • insert on cities

This doesn’t:

  • insert on roads and state_boundaries

First issue: geoserver returns wfs:SUCCESS/ (no errors and no warnings in the logs) but data are not inserted in the shapefiles.

By comparing example XML I’ve tracked down the problem (at least for linestrings) to the simple GML used by QGIS, compared with the multi geometry GML used in the geoserver demo requests (which works):

QGIS (silently fails):
<the_geom xmlns=“http://www.openplans.org/topp”>
<gml:LineString srsName=“EPSG:4326”>
<gml:coordinates cs=“,” ts=" ">146.1911…

GeoServer Demo Requests (works):
topp:the_geom
<gml:MultiLineString srsName=“http://www.opengis.net/gml/srs/epsg.xml#4326”>
gml:lineStringMember
gml:LineString
<gml:coordinates decimal=“.” cs=“,” ts=" ">146.1911…

I believe that geoserver should not return wfs:SUCCESS/ if data are not saved (should I file a ticket?) but I’m unsure about the (multi)geometry issue: is that a requirement from the specs that simple geometries (in this case LineString) are encoded as Multi?

···

Alessandro Pasotti
w3: www.itopen.it

On Wed, Mar 30, 2016 at 12:58 PM, Alessandro Pasotti <apasotti@anonymised.com>
wrote:

Hi All,

I'm testing the official geoserver 2.8.2 on Linux, I've enabled WFS-T
transactional on all workspaces.
I'm doing some insert tests using topp: roads, state_boundaries and cities
as test layers for linestrings, polygons and points.

Using QGIS as a client, this works:
- insert on cities

This doesn't:
- insert on roads and state_boundaries

First issue: geoserver returns <wfs:SUCCESS/> (no errors and no warnings
in the logs) but data are not inserted in the shapefiles.

By comparing example XML I've tracked down the problem (at least for
linestrings) to the simple GML used by QGIS, compared with the multi
geometry GML used in the geoserver demo requests (which works):

QGIS (silently fails):
<the_geom xmlns="http://www.openplans.org/topp&quot;&gt;
        <gml:LineString srsName="EPSG:4326">
                    <gml:coordinates cs="," ts=" ">146.1911....

GeoServer Demo Requests (works):
<topp:the_geom>
<gml:MultiLineString srsName="http://www.opengis.net/gml/srs/epsg.xml#4326
">
          <gml:lineStringMember>
            <gml:LineString>
              <gml:coordinates decimal="." cs="," ts=" ">146.1911....

What geometry type is GeoServer declaring in DescribeFeatureType? If they
do not match you'll
get the result you are describing.

As far as I know the original developer of the WFS-T subsystem said we
cannot xml validate the
request for some reason, but at the same time the parser is unfortunately
schema driven,
meaning that it will only look for the elements it expects to find,
ignoring the others.
So if it's looking for a attribute that's not mandatory, and does not find
it because it's mis-encoded,
the transaction will succeeded ignoring the unexpected attributes.

We have had a number of reports due to this issue over the years, with a
few variants (e.g., people encoding
geometries in gml 2 in wfs 1.1 transactions), and I agree it would be best
if the
system validated the input xml against the expected schema and threw an
error,
but apparently it's not an easy thing to fix (meaning, not a spare time
deal),
and one that nobody has gathered funds to use working hours to fix so far.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

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.

-------------------------------------------------------

2016-03-30 14:00 GMT+02:00 Andrea Aime <andrea.aime@anonymised.com>:

On Wed, Mar 30, 2016 at 12:58 PM, Alessandro Pasotti <apasotti@anonymised.com>
wrote:

Hi All,

I'm testing the official geoserver 2.8.2 on Linux, I've enabled WFS-T
transactional on all workspaces.
I'm doing some insert tests using topp: roads, state_boundaries and
cities as test layers for linestrings, polygons and points.

Using QGIS as a client, this works:
- insert on cities

This doesn't:
- insert on roads and state_boundaries

First issue: geoserver returns <wfs:SUCCESS/> (no errors and no warnings
in the logs) but data are not inserted in the shapefiles.

By comparing example XML I've tracked down the problem (at least for
linestrings) to the simple GML used by QGIS, compared with the multi
geometry GML used in the geoserver demo requests (which works):

QGIS (silently fails):
<the_geom xmlns="http://www.openplans.org/topp&quot;&gt;
        <gml:LineString srsName="EPSG:4326">
                    <gml:coordinates cs="," ts=" ">146.1911....

GeoServer Demo Requests (works):
<topp:the_geom>
<gml:MultiLineString srsName="
http://www.opengis.net/gml/srs/epsg.xml#4326&quot;&gt;
          <gml:lineStringMember>
            <gml:LineString>
              <gml:coordinates decimal="." cs="," ts=" ">146.1911....

What geometry type is GeoServer declaring in DescribeFeatureType? If they
do not match you'll
get the result you are describing.

As far as I know the original developer of the WFS-T subsystem said we
cannot xml validate the
request for some reason, but at the same time the parser is unfortunately
schema driven,
meaning that it will only look for the elements it expects to find,
ignoring the others.
So if it's looking for a attribute that's not mandatory, and does not find
it because it's mis-encoded,
the transaction will succeeded ignoring the unexpected attributes.

We have had a number of reports due to this issue over the years, with a
few variants (e.g., people encoding
geometries in gml 2 in wfs 1.1 transactions), and I agree it would be best
if the
system validated the input xml against the expected schema and threw an
error,
but apparently it's not an easy thing to fix (meaning, not a spare time
deal),
and one that nobody has gathered funds to use working hours to fix so far.

Cheers
Andrea

Thank you Andrea,

I have clear picture now, and you are right, the problem is in that
DescribeFeatureType returns type="gml:MultiLineStringPropertyType" while
QGIS thinks that is a simple geometry.

I'll have a look into QGIS if we can do something to fix this.

--
Alessandro Pasotti
w3: www.itopen.it