Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#4910 closed defect (fixed)

Conversion from Postgis geometry to GML 3.1.1 and back fails

Reported by: tomassejkora Owned by: pramsey
Priority: high Milestone: PostGIS 3.1.4
Component: postgis Version: 3.1.x
Keywords: GML 3.1.1 Cc:

Description

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

Change History (8)

comment:1 by pramsey, 3 years ago

Milestone: PostGIS 3.1.23.1.3

comment:2 by pramsey, 3 years ago

Milestone: 3.1.3PostGIS 3.1.3

Milestone renamed

comment:3 by robe, 3 years ago

Milestone: PostGIS 3.1.3PostGIS 3.1.4

In prep for 3.1.3 release

comment:4 by pramsey, 3 years ago

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 so hard, for example:

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, 14, 0, 'gml', NULL)
      ,5514)
FROM g;
Last edited 3 years ago by pramsey (previous) (diff)

comment:5 by pramsey, 3 years ago

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.

comment:6 by pramsey, 3 years ago

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.

comment:7 by Paul Ramsey <pramsey@…>, 3 years ago

Resolution: fixed
Status: newclosed

In 434494e/git:

Allow repeated points in GML poslist inputs, closes #4910

comment:8 by Paul Ramsey <pramsey@…>, 3 years ago

In 320a7b5/git:

Allow repeated points in GML poslist inputs, references #4910

Note: See TracTickets for help on using tickets.