Opened 3 years ago
Closed 15 months ago
#1089 closed enhancement (fixed)
Support for geometry with M value
| Reported by: | jfbourdon | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 3.11.0 |
| Component: | Default | Version: | main |
| Severity: | Unassigned | Keywords: | |
| Cc: |
Description
I'm not sure if my feature request is still valid considering the resolution of #460 but if not, I would like to request the support of M value inside geometries. Currently (at least in 3.8.1), if a geometry containing M values is given, the resulting geometry will have lost those.
Change History (5)
comment:1 by , 3 years ago
| Milestone: | 3.8.2 → 3.10.0 |
|---|---|
| Version: | 3.8.0 → master |
comment:2 by , 3 years ago
The way the JTS implements the M values is not suitable?
The Coordinate class declares just a dummy getM() accessor without allocating any space and deferring the implementation to its descendants like CoordinateXYM or CoordinateXYZM.
comment:4 by , 16 months ago
Support for reading and writing WKT and WKB with M values was added in 60edf0e5f040e065193bd5beb79f7fa8febb1cd5/git
PR for M interpolation in overlay at https://github.com/libgeos/geos/pull/802
comment:5 by , 15 months ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Overlay support added in 4292b127ec4a9657fee07efdd8f5bf957fc521d5/git
Well, it's not valid for 3.8, but I'll bump it into 3.10. It's a source of ongoing discussion, on how to implement without adding a 33% extra storage penalty on all geometry (of course we already took the 50% penalty when adding Z, but maybe we can reverse that).