WktWriter api design

[TimPigden]

I've just spent a few hours trying to track down a non-bug in my code which resulted from the fact that lineString.toString method always prints out a linestring xy - even when the linestring is wrapping a coordinate sequence with an M dimension.
This is extremely counter-intuitive and took me reading through the source to figure out what was happening.

For an architectural point of view, the jts structures allow manipulation and transformation of geometry structur3es into other geometry structures.
The "principle of least surprise" would dictate that WktWriter just wrote out whatever structure you put into it. If it's a linestring with an M dimension it should be a linestring M and so on.

But that's not what it is. WktWriter is effectively also a data structure transformer. You put one sort of linestring in, and unless you juggle around WktWriter dimensions and Ordinate sets you end up with a transformed linestring output as wkt. It's a universal downgrader - simplifying away those extra dimensions unless you work at it.

And if you have multiple dimensions of geometries mixed and matched, then you need to create a new WktWriter per dimension setup.

And you have no control over the behaviour of toString - which strips out those additional dimensions leading you to do extra work for your traces to have meaningful information.

Why is all this necessary?

If I want to turn my linestringM or ZM into a 2d linestring, I can use the geometry operations to do so. But I find it hard to imagine many people go to the effort of creating higher dimension geometries and actually wanting them degraded by default in wkt.

So my proposal is that WKTWriter is replaced and/or supplemented by a version that creates WKT using the maximal dimensions present in the geometries being written out. This would match what you get from postgis, for example.

If, for reasons of backward compatibility you think it's best to leave it as is, then creating a new SimpleWKTWriter that did as I suggest and was used in the geometry.toString method would be a reasonable alternative.

Having looked at the code, it's a pretty simple change and I'd be happy to do it sometime in the next couple of months and submit a PR

What do you think?

[TimPigden]

PS - the postgis jts binary writer is an even bigger problem. It doesn't know about M dimensions at all

[dr-jts]

Note that the class is WKTWriter. Code submissions should adhere to project naming.

[dr-jts]

The reason for the current WKTWriter behaviour is that the design predates having dimensioned Coordinate subclasses.

Also, a lot of JTS code (internal and client) uses plain ol Coordinate to hold XY data. This should not suddenly start being emitted as XYZ (often with a missing Z value).

The safest route for now is to create a new class (perhaps WKTWriterEx) with the new suggested behaviour. Once that has been rolled out and the bugs and kinks worked out, perhaps it can replace the current class.