[geos-devel] M-coordinate support

[Martin Davis]

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?

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.

On 7/10/2012 5:47 AM, Sandro Santilli wrote:
> Luca: I confirm you need to modify the library in order to get M support.
> I guess it would increase memory requirements of operations by about 30%
> (from XYZ to XYZM) -- I think Martin Davis would be the one in the best
> position to answer this, GEOS being a port of his JTS.
>
> --strk;
>
> On Tue, Jul 10, 2012 at 02:37:42PM +0200, luca paganotti wrote:
>> Hi Mike,
>>
>> I agree with you about the M-coordinate support in geos, there are some
>> cases in which this support is a must.
>>
>> For example I'm using geos to represent 3D points changing their position
>> in time so to have M seems really necessary, but I can be wrong, this
>> support is already built in.
>>
>> To be able to use geos with ZM points I've lightly modified and rebuilt
>> geos tailoring it only to my needs. I've not done any kind of analisys or
>> deep thinking about it so it's only a very raw support for M, but that was
>> I needed.
>>
>> P.S. I made also a little post to this list some time ago saying that, but
>> I received no answer, maybe it was not so interesnting or I was missing
>> something that could give me M-support without rebuilding the modified
>> library.
>>
>> Best regards
>>
>> lp
>>
>>
>>
>> On Tue, Jul 10, 2012 at 1:41 PM, Mike Toews <mwtoews at gmail.com> wrote:
>>
>>> Hi devs,
>>>
>>> I'd like to know if "measure" or M-coordinate support is somewhere on
>>> the development horizon for GEOS. I could see the benefit of opening
>>> client software to support ISO 19125 compliant geometries, such as in
>>> OGR or Shapely.
>>>
>>> Possibly the first widespread use of M-coordinates started in the
>>> 1990s with the Shapefile file format, as detailed in the 1998 ESRI
>>> technical specs. With open source software, Shapelib and PostGIS has
>>> supported M-coordinates for quite some time (possibly close to a
>>> decade?). More recently, Simple Features Access Standards published by
>>> OGC and later ISO 19125, detail the use and storage of of
>>> M-coordinates in various geometry types.
>>>
>>> Are there any limitations to adopting M-coordinate support for GEOS?
>>> Potential performance loss? Other limitations or incompatibilities?
>>> I'm curious, as I often run into instances where this dimension is
>>> useful, but am a bit stumped at it's lack of support in some software.
>>> Thanks.
>>>
>>> -Mike
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2179 / Virus Database: 2437/5122 - Release Date: 07/09/12
>
>