Opened 3 years ago
Closed 3 years ago
#1079 closed defect (fixed)
Inconsistent dimensionality change
| Reported by: | Mike Taves | Owned by: | pramsey |
|---|---|---|---|
| Priority: | minor | Milestone: | 3.9.0 |
| Component: | Default | Version: | main |
| Severity: | Annoyance | Keywords: | |
| Cc: |
Description
Over in Shapely, there is a test suite test_create_inconsistent_dimensionality.py that checks WKT with inconsistent dimensionality. For most instances, a geometry with at least one 3D coordinate is promoted with a Z dimension, assuming Z=0 for other XY coordinates. There are a few isolated cases where the geometry remains as a 2D geometry if the 3D coordinate is not the first.
Of these inconsistencies, one new inconsistency stands out as new and unusual.
GEOS 3.8.1 and earlier:
# preserve 3rd dimension LINESTRING (1 1 1, 2 2) -> LINESTRING Z (1 1 1, 2 2 0) # drop 3rd dimension LINESTRING (1 1, 2 2 2) -> LINESTRING (1 1, 2 2)
Since GEOS 3.9.0beta1:
# drop 3rd dimension LINESTRING (1 1 1, 2 2) -> LINESTRING (1 1, 2 2) # preserve 3rd dimension LINESTRING (1 1, 2 2 2) -> LINESTRING Z (1 1 0, 2 2 2)
why is this the only geometry type scenario that swaps behaviour? Ideally any geometry with at lest one 3D coordinate would be promoted with a Z dimension.
Change History (6)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
Reading through WKTReader, it seems like the general goal is to promote the dimensionality of a given CoordinateSequence to the highest dimensionality encountered in the sequence. That doesn't seem to match the behaviour of the polygon case though, nor the new behaviour of the linestring case. In any event, the current model sort of sucks since it's possible to make a POLYGON with mixed dimension rings, or a multilinestring with mixed dimension members. Also you can make a linestringz with 2d coordinates, because the dimensionality tag is mostly ignored. (Not always).
comment:4 by , 3 years ago
| Owner: | changed from to |
|---|
It seems inconsistent all around, to me. What is the consistent rule supposed to be? My guess would have been "preserve the dimensionality of the first coordinate)" but this test belies that:
('MULTIPOINT (1 1, 2 2 2)', 'MULTIPOINT Z (1 1 0, 2 2 2)'),I suppose not changing behaviour is the highest good, I hate to see that version switch there when we haven't got consistent behaviour. I guess it's too late to be as strict as the PostGIS parser (dimensional mixing == error).