[geos-devel] M-coordinate support

[Sandro Santilli]

On Tue, Jul 10, 2012 at 09:18:47AM -0700, Martin Davis wrote:
> This has come up a few times for JTS as well.  Unfortunately it
> would be a big breaking change and a fair bit of work to add M to
> the current JTS Coordinate object (at least, the way I would prefer
> to do this is to turn Coordinate into an interface and allow 2D, 3D
> and 4D subclasses, so as not to penalize people who only want 2D).
> 
> So short story is no plans for this at the moment.  It would require
> quite a bit of time, which equals money...
> 
> In GEOS the situation might be easier, if Coordinate is already an
> interface?

Nope, it's a concrete class, as in JTS.

In GEOS any "interface" became a virtual class, it'd be also time
in GEOS to stop that and use more templates instead, but it's the
same "long time == lots money" issue. Turning a Coordinate into
a _virtual_ class would cost a lot in terms of performance.

> As for Sean's question about algorithm support, this of course would
> be ideal, but it's not strictly necessary.  Some uses just require
> that M is able to be stored.  The obvious algorithms to enhance are
> the linear referencing ones, which can make use of measure directly.
> I don't know of any other current JTS algorithms which would
> naturally extend to use a M value.  Then there's the question of
> preserving M through operations such as overlay, which seems a bit
> problematic.  My inclination would be to avoid trying to implement
> this.

Another option, if you don't need Z, is to _use_ Z for M...

--strk;