OGRGeometry::exportToWkt generates 'old-style' 3D WKT.

[ftrastour]

The WKT string generated by the exportToWkt functions family doesn't follow the recent WKT specifications for 3D geometries.

The ' Z' string should be appended to the geometry name when a 2.5D/3D geometry is exported.

The attached example should generate :

LINESTRING Z(10 20 30,11 21 31,12 22 32)

instead of :

LINESTRING (10 20 30,11 21 31,12 22 32)

[ftrastour]

Sample python file showing the problem

[warmerdam]

I believe it could be dangerous to change the behavior of these existing functions. But I think what should be done is:

1) modify importFromWkt() to support old style, and ISO SQL-MM / SF-SQL 1.2 style WKT transparently.

2) add an exportToSF12Wkt() method (or perhaps there is a better description of the new format).

[Even Rouault]

Point 1) implemented.

r18913 : OGRGeometry::importFromWkt() : allow importing SF-SQL 1.2 style WKT while preserving compatibility with previously recognized non conformant WKT (#3431)

r18914 /trunk/autotest/ogr/ogr_wkbwkt_geom.py: Test importing SF-SQL 1.2 style WKT and robustness to broken WKT (#3431)

Restrictions :

• even if 'POINT M (x y m)' is recognized, the measure value is still ignored.
• WKT such as 'MULTILINESTRING(EMPTY,(a b,c d))' can now be imported to conform to the spec, but when exporting to WKT(), the EMPTY parts are skipped (the exportToWkt() has not been modified at all)

No plan for now to implement exportToSF12Wkt() method

[Even Rouault]

r19208 /trunk/gdal/ogr/ogrmultipolygon.cpp: OGRMultiPolygon::importFromWkt() : more SF 1.2 compliante to support empty linestring text, such as 'MULTIPOLYGON (((0 1,2 3,4 5,0 1),EMPTY))' (#3431)

r19209 /trunk/autotest/ogr/ogr_wkbwkt_geom.py: More tests for importFromWkt() (#3431)

[Even Rouault]

Since GDAL 2 or perhaps even 1.11, we have a OGR_G_ExportToIsoWkt()