Writing and reading WKB loses M dimension

[kaiwinter]

When using WKBWriter to write a Geometry which has XYM coordinates and afterwards using WKBReader for reading the result. The Geometry has XYZ coordinates instead of XYM coordinates.

Here is small example:

    String wkt = "MULTILINESTRING M((1 1 1, 2 2 2))";
    WKTReader wktReader = new WKTReader();
    Geometry geometryBefore = wktReader.read(wkt);

    WKBWriter wkbWriter = new WKBWriter(3);
    byte[] write = wkbWriter.write(geometryBefore);

    WKBReader wkbReader = new WKBReader();
    Geometry geometryAfter = wkbReader.read(write);

    System.out.println(Arrays.asList(geometryBefore.getCoordinates()));
    System.out.println(Arrays.asList(geometryAfter.getCoordinates()));

When running this you get the following output:

[(1.0, 1.0 m=1.0), (2.0, 2.0 m=2.0)]
[(1.0, 1.0, 1.0), (2.0, 2.0, 2.0)]

The geometryBefore has XYM coordinates. The geometryAfter has XYZ coordinates.
In WKBReader.readGeometry are two variables evaluated hasZ and hasM. In the above example hasZ is true and hasM is false. I think this is because WKBWriter.writeGeometryType always writes 0x80000000 regardless of the coordinate type. Debugging WKBReader.readGeometry makes me think 0x40000000 should be used for M coordinates in WKBWriter.writeGeometryType.

What do you think? Can this be improved or did I just misunderstood how this should work.

[jnh5y]

I think you've identified a bug here. Any interest in working on it?

The Contributing guide has some info about that here: https://github.com/locationtech/jts/blob/master/CONTRIBUTING.md

[kaiwinter]

Yes sure. Currently I'm using a workaround with a GeometryFactory but I would love to get rid of it as it most probably impacts performance.

When thinking of a fix my first thought was to do an instanceof check of the result of g.getCoordinate() in writeGeometry. But that would be pretty ugly. Is there a better way to get the subtype of the Coordinate (whether it is CoordinateXYM)?

When looking at the WKTWriter there is the method setOutputOrdinates() . I was using this method to correctly write XYM coordinates as text, so I think this pattern may be applied to the WTBWriter as well. Do you have other ideas?

[TimPigden]

what's the situation. is this live? What do I need to do to get this to work? Modify the source locally? I see there's a pull request but it seems to have been lost in some stuff about copyright notices.

[TimPigden]

ok, i can get round it with
val wktWriter = new WKTWriter(3)
wktWriter.setOutputOrdinates(Ordinate.createXYM()) // Include M dimension in

but clearly that's not an optimal solution - there's no reason for the M to require the dimensions to be set in the first place, surely. You're just making hurdles unnecessarily - if i want to createXYM then obviously i want 3 dimensions at that point
(and why does it really need it at all? It took digging around in the source to find all this. asText should just recognise I've got M in my dimensions and coordinates. Writing ought to be the default position I'd have thought - who wants an m and not wants to see it? Suppressing it should be the active decision)

[jodygarnett]

I have not seen a PR but would like to see this addressed. There is some utility methods to determine hasZ or hasM.

[kaiwinter]

There was a PR (#734) which has already been merged. The change should have been released with 1.20.0. This issue could be closed as resolved, IMHO.

[TimPigden]

Hi Kai, so what is the expected behaviour? I'm on 1.20.0 and I have to specify both a dimension and the XYM from the api docs: Creates a writer that writes Geometry <https://locationtech.github.io/jts/javadoc/org/locationtech/jts/geom/Geometry.html>s with the given output dimension (2 to 4). The output follows the following rules: - If the specified *output dimension is 3* and the *z is measure flag is set to false*, the Measure value of coordinates will be written if it is present (i.e. if it is not Double.NaN) but it doesn't say what the z is measure flag is (there's no isMeasure in the source that I can see) or indeed say anything about M measures. And one would have thought seting XYM as the ordinates would be sufficient to tell the system that we actually wanted all three in the output. Instead there's a check that says that even you've just asked for XYM but failed to set dimensions to 3, it's going to (silently) ignore that request. But more importantly, the "principle of least suprise" would be that the linestring.toString method would select the most suitable output format from the get-go. Is the current behaviour really the behaviour you want? Or is it pehaps what we really want but rocking the boat could cause too many problems for too many people? In which case how about a WktWriter.createWithAutoFormat that did the most sensible thing (display all dimensions if they exist)? Tim

…

On Mon, 27 Jan 2025 at 20:05, Kai Winter ***@***.***> wrote: There was a PR (#734 <#734>) which has already been merged. The change should have been released with 1.20.0. This issue could be closed as resolved, IMHO. — Reply to this email directly, view it on GitHub <#733 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJWHJ7XFLECCHBT2CF7UXL2M2GPTAVCNFSM6AAAAABV6MWW6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJWG43TQOJTGY> . You are receiving this because you commented.Message ID: ***@***.***>

-- Tim Pigden Optrak Distribution Software Limited +44 (0)1992 517100 http://www.linkedin.com/in/timpigden http://optrak.com Optrak Distribution Software Ltd is a limited company registered in England and Wales. Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

[kaiwinter]

This library has its rough edges, without question. But keep in mind this is open source software and we can all contribute to make it continuously better.

I'm not the right person to answer your question, I'm afraid. Maybe you should start a discussion or, if you have a good solution to your specific problem, describe it in an issue or a PR.