Closed stevanpa closed 3 years ago
The reason for this approach is that the WKT format in the past was severely limited. It was limited to 2D, and had no encoding of coordinate reference system. Consequently, most real-life usage I encountered was with some form of "extension" to the original WKT standard of 1999. Mostly these extensions were very close to the Postgis extension.
But you're right. I checked the current standards, and there is much improvement. So I'll add a strict WKT (based on https://www.ogc.org/standards/sfa version 1.2.1)
This is now resolved in master. Added SFA 1.1.1 and SFA 1.2.1 WKT/WKB dialects
According to Wikipedia https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry
A WKT is represented by a geometry type and a number of coordinates e.g.: POINT(5.123 12.234) So I would expect to be able to request a WKT string from any geometry object in this form. But instead I get the EWKT format which according to the PostGIS 1.5 manual https://postgis.net/docs/ST_GeomFromEWKT.html it clearly says its not an OGC standard. I suppose there must be some reasoning behind this choice? I can live with that.
The thing as a software developer that really gets my blood pumping is this bit of logic:
ALL these dialects extend the PostGIS dialect. Which means it is not possible to get a WKT representation of a Geometry. The reason being that all dialects are based on the PostGIS dialect which only implements the non-OGC compliant EWKT format.
How can I get an OGC compliant WKT representation from a Geometry object in geolatte? This used to be a very trivial operation in the Java Topology Suit...