[Python/OGR] Geometry Conversion GML -> WKT -> GML returns invalid Geometry about gdal HOT 12 CLOSED

My bad! Similar use case in #7294 I guess ;)

from gdal.

Would you mind attaching the gml as GML file that can be studied with ogrinfo and ogr2ogr?
I wonder if it is too much to trust that things like <gml:Arc interpolation="circularArc3Points" numArc="1"> convert nicely into WKT.

from gdal.

Sure: test1.zip
I'm aware that Arcs won't be converted 1:1, but the resulting geometry should imho be valid nevertheless.

from gdal.

GDAL seems to find the following WKT. PostGIS says that the geometry is valid and it looks the same in QGIS as the source GML.

CURVEPOLYGON ((567462.07 5937698.959,567446.882 5937692.583,567390.995 5937669.124,567386.293 5937667.145,567389.479 5937654.684,567404.151 5937595.479,567474.996 5937628.152,567465.27 5937684.42,567462.07 5937698.959),COMPOUNDCURVE (CIRCULARSTRING (567410.377 5937607.7,567407.834857796 5937607.72206805,567406.223 5937609.688),(567406.223 5937609.688,567403.316 5937621.126),(567403.316 5937621.126,567394.606 5937655.401),(567394.606 5937655.401,567393.37 5937660.265),(567393.37 5937660.265,567395.687 5937664.07),(567395.687 5937664.07,567403.0 5937667.139),(567403.0 5937667.139,567415.353 5937672.325),(567415.353 5937672.325,567433.538 5937679.955),(567433.538 5937679.955,567432.779 5937681.762),(567432.779 5937681.762,567443.507 5937686.264),(567443.507 5937686.264,567445.762 5937685.099),(567445.762 5937685.099,567448.434 5937683.72),(567448.434 5937683.72,567451.021 5937668.836),(567451.021 5937668.836,567450.952 5937668.824),(567450.952 5937668.824,567452.176 5937661.63),(567452.176 5937661.63,567453.455 5937654.108),(567453.455 5937654.108,567442.758 5937634.17),(567442.758 5937634.17,567434.477 5937618.73),(567434.477 5937618.73,567428.223 5937615.867),(567428.223 5937615.867,567410.377 5937607.7)))

Now I wonder how I could convert the WKT into GML3 with the GDAL command line tools because I have only those in my toolbox.

So I made PostGIS to read the WKT

ogr2ogr -f GML gdalgml32.gml PG:"host=localhost port=5432 dbname=db user=user password=pw" -sql "select st_geomfromtext('CURVEPOLYGON...

The resulting gml can be opened with QGIS and the geometry looks the same than before. I had to delete the .gfs file first but maybe it remained from some earlier experiment.

gdalgml32.zip

I do not know how valid my tests are and what they prove, if anything.

from gdal.

gdalgml32.zip has the gml:Ring element as well as the gml:id attribute on sub-geometries and seems to be valid:

          <gml:interior>
            <gml:Ring>
              <gml:curveMember>
                <gml:Curve gml:id="gmltest.geom.0.interior.0.0">

The WKT string seems to be the same in both cases (geom.ExportToWkt() and st_geomfromtext('CURVEPOLYGON...), the resulting GML geometry, however, differs with geom.ExportToGML().

On a side note, I get an error when using ST_AsGML inside the DB on the geometry: SQL Error [XX000]: FEHLER: lwgeom_to_gml2: 'CompoundCurve' geometry type not supported I just realized that the default GML version for this function is 2. So ST_AsGML(3, geom) results in an apparently valid GML geometry with

          <gml:interior>
            <gml:Ring>

albeit no gml:id, but these aren't mandatory for GML 3.2.2.

from gdal.

@pathmapper maybe have a look

from gdal.

Please notice that in my test the curvepolygon WKT was first turned into a PostGIS geometry by the PostGIS database with -sql "select st_geomfromtext('CURVEPOLYGON... while in the original case GDAL did the conversion into GDAL geometry with geom = ogr.CreateGeometryFromWkt(geom).

So the next step might be to test if GDAL could have some bug in CreateGeometryFromWkt by checking the content of geom and is it somehow different than the one that comes through PostGIS. I paste the geometry from the PostGIS ST_GeomFromText if it happens to help someone.

010A000000020000000102000000090000003D0AD7234C512141894160BD88A65641068195C32D5121413BDF4F2587A65641D7A370FDBD502141B29DEF4781A6564193180496B450214114AE47C980A65641EE7C3FF5BA502141F0A7C6AB7DA656413BDF4F4DD85021419EEFA7DE6EA6564146B6F3FD65512141355EBA0977A65641A4703D8A52512141AE47E11A85A656413D0AD7234C512141894160BD88A65641010900000014000000010800000003000000DD2406C1E4502141CDCCCCEC71A65641257B72ABDF502141E95C36EE71A65641560E2D72DC5021412731086C72A65641010200000002000000560E2D72DC5021412731086C72A6564183C0CAA1D65021414E62104875A6564101020000000200000083C0CAA1D65021414E62104875A65641CBA14536C5502141E7FBA9D97DA65641010200000002000000CBA14536C5502141E7FBA9D97DA65641D7A370BDC25021418FC2F5107FA65641010200000002000000D7A370BDC25021418FC2F5107FA65641C976BE5FC750214148E17A0480A65641010200000002000000C976BE5FC750214148E17A0480A6564100000000D65021414260E5C880A6564101020000000200000000000000D65021414260E5C880A656417F6ABCB4EE502141CDCCCC1482A656410102000000020000007F6ABCB4EE502141CDCCCC1482A656416ABC74131351214152B81EFD83A656410102000000020000006ABC74131351214152B81EFD83A656418716D98E11512141A69BC47084A656410102000000020000008716D98E11512141A69BC47084A6564106819503275121414260E59085A6564101020000000200000006819503275121414260E59085A656412FDD24862B5121411904564685A656410102000000020000002FDD24862B5121411904564685A656417D3F35DE30512141E17A14EE84A656410102000000020000007D3F35DE30512141E17A14EE84A656411283C00A365121412506813581A656410102000000020000001283C00A365121412506813581A65641448B6CE7355121417F6ABC3481A65641010200000002000000448B6CE7355121417F6ABC3481A6564108AC1C5A3851214185EB51687FA6564101020000000200000008AC1C5A3851214185EB51687FA656418FC2F5E83A512141D578E9867DA656410102000000020000008FC2F5E83A512141D578E9867DA656417593188425512141AE47E18A78A656410102000000020000007593188425512141AE47E18A78A65641105839F414512141EC51B8AE74A65641010200000002000000105839F414512141EC51B8AE74A65641560E2D720851214191ED7CF773A65641010200000002000000560E2D720851214191ED7CF773A65641DD2406C1E4502141CDCCCCEC71A65641

from gdal.

With GDAL 3.9.0dev-d7aed6e0b0, released 2024/02/09 (debug build) and the original approach in #9238 (comment) there is a valid geometry as result:

out_geometry.zip (created not with recent GDAL)

from gdal.

@kraftto maybe the issue is that your result is missing the namespace declaration?

If xmlns:gml="http://www.opengis.net/gml/3.2" is added to the Polygon element of your result and the GML is opened via drag'n'drop in QGIS it loads just fine and passes validity checks with the Check validity tool (QGIS and GEOS).

from gdal.

OK, I see now why you are saying the result is invalid :-)

from gdal.

Yeah I should have mentioned that I'm talking about XML Schema validity :) I added this to the original issue description. The GML geometry should look like the one in gdalgml32.zip.

from gdal.

Turns out that this has been reported before in #7294 and was fixed in #7296.

You need minimum GDAL 3.6.3 and then you will get

<gml:interior>
    <gml:Ring>
        <gml:curveMember>

From https://github.com/OSGeo/gdal/blob/v3.6.3/NEWS.md

GML driver:
fix CurvePolygon export of CompoundCurve and CircularString child elements (#7294)

from gdal.