Conversion from Postgis geometry to GML 3.1.1 and back fails

[tomassejkora]

Conversion of Postgis geometry to GML 3.1.1 is failing with error message "invalid GML representation" in some cases. I have a lot of tiny geometries which I'm trying to convert to GML 3.1.1 and later back to Postgis and only for some of them it's failing.

I tried to isolate the problem into a simple SQL command which fails with the latest Postgis 3.1.x and Postgres 12

SELECT

ST_GeomFromGML(ST_AsGML(3, ST_GeomFromText('MULTIPOLYGON(((-804030.88 -988533.6,-804027.84 -988531.12,-804026.14 -988528.6900000001,-804020.6013588897 -988532.5649898029,-804012.6923943197 -988538.1028127444,-804014.75 -988540.52,-804026.29 -988539.96,-804030.88 -988533.6)),((-804030.52 -988525.62,-804026.137267668 -988528.6887703099,-804026.14 -988528.6900000001,-804030.52 -988525.62)))', 5514), 2, 0, 'gml', null), 5514);

If the GML version in fuction ST_AsGML is changed from version 3 to 2 then the SQL statemnt runs successfuly. I tried to play with ST_AsGML options but without any success.

Could you please help us with conversion?

Thank you very much! Tomas

[pramsey]

Milestone renamed

[robe]

In prep for 3.1.3 release

[pramsey]

Huh, I assumed this would be some quirk of GML output, but it seems tied to the second element of the multipolygon which is a degenerate collapsed polygon. This reduced example also generates the error

WITH g(geom) AS (
   SELECT 'POLYGON((0 0, 10 0, 10 0.000001, 0 0.000001, 0 0))'::geometry
)
SELECT 
ST_GeomFromGML(
      ST_AsGML(3, geom, 2, 0, 'gml', NULL)
      ,5514)
FROM g;

The ST_AsGML call is rounding off the coordinates and creating an invalid collapsed polygon. The problem can be averted by not rounding coordinates.

[pramsey]

An open question here is whether the "round trip" counts when you're rounding off the coordinates. Because what you are getting back will definitively not be what you feed in, even if ST_GeomFromGML() is relaxed enough to accept highly invalid polygonal inputs.

[pramsey]

Oh, this is interesting... gml_parse_poslist() drops repeated points, while gml_parse_coordinates retains them. So even inside the GML handler we have inconsistent behaviour. I think I will see if relaxing poslist fixes this problem and doesn't introduce new regressions.

[Paul Ramsey <pramsey@…>]

In 434494e/git:

Allow repeated points in GML poslist inputs, closes #4910

[Paul Ramsey <pramsey@…>]

In 320a7b5/git:

Allow repeated points in GML poslist inputs, references #4910