Re: [Jts-topo-suite-user] mgeom package

[Karel M. <ka...@ge...>]

Martin,

Having used MGeometries for some time now, I also think that keeping measures orthogonal to the current design is preferable. I think we need getM() and hasM() methods on interface CoordinateSequence, and add M-values to the Coordinate (field + constructor arguments). That should suffice, I think. 

It would be possible to introduce the MCoordinateSequence and MCoordinateSequenceFactory classes alongside the already existing implementations. This is certainly not ideal, since algorithms would need to check on the class of the CoordinateSequence to determine whether the geometry carries measures, plus it would feel "bolted on". 

For practical applications we need to be able to modify individual measures and interpolate measures between start and end vertices. Additionally we need to have the functionality of EventLocator - which constitutes the core LRS operations. We can use the same model as with LenghtIndexedLine: create a class MeasuredLine (or some such) that has an interface along the lines of MGeometry, and add EventLocator (perhaps called LinearReferenceLocator) as is now, but taking a Linear Geometry.

To review LRS support in spatial databases I would recommend Postgis (of course) and SQL Server 2008. Both have added measures in a natural way to a geometry model based on the Simple Features Spec.

Regards,

Karel Maesen

On 28 Sep 2010, at 17:50, Martin Davis wrote:

>  Karel,
> 
> I realize that support for measures would be a nice thing to have in JTS 
> (both for storage purposes and for computation).
> 
> My goal for the design is to build in measures in a way that is 
> orthogonal to the current JTS Geometry and Coordinate design.  In other 
> words, continue to use the same Geometry classes, but make use of the 
> ability to extend CoordinateSequences to carry measure values.  The 
> presence of a measure would be detectable by algorithms, which could 
> then compute new measures appropriately (this would obviously apply to 
> linear referencing, but could be extended to other algorithms if use 
> cases appeared).
> 
> Unfortunately this would be a bit of a breaking change, I suspect, since 
> it would require new methods on the CoordinateSequence interface.  The 
> effort required to upgrade would be minor, however.
> 
> I would also want to review some of the spatial databases to see what 
> kind of measured object models they provide, to try and support as many 
> as possible.
> 
> Any comments?
> 
> Martin
> 
> 
> On 9/28/2010 2:30 AM, Karel Maesen wrote:
>> Hi Martin,
>> 
>> In the course of developing Hibernate Spatial, I created a package 'mgeom' which adds MGeometries to JTS. An MGeometry is a Geometry with vertices having x/y(/z) and  m-coordinates. This class I felt was needed to support the linear-referencing features in databases such as Posgis, Oracle and Microsoft SQL Server.
>> 
>> I think that this package properly belongs to JTS, not Hibernate Spatial. Would it be possible to integrate it into JTS? The code can be found here: http://www.hibernatespatial.org/websvn/ (module hibernate-spatial). The code is relatively old, and I'm certainly willing to clean it up, improve documentation and unit test coverage, and make any changes  so as to better integrate it into JTS. The code has been in production use for at least three years, and will continue to be used by several of my clients, at least.
>> 
>> I'm currently busy integrating Hibernate Spatial as a module into Hibernate Core. This would ensure that every Hibernate user will have support out-of-the-box for spatial data using the JTS Geometry model. Having the MGeometry package moved to JTS cleans up the code and provides for a neat separation between JTS (geometry model + spatial operations) and Hibernate (persistence).
>> 
>> What do you think?
>> 
>> Regards,
>> 
>> Karel Maesen
>> 
>> 
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Jts-topo-suite-user mailing list
>> Jts...@li...
>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>> 
> 
> -- 
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Jts-topo-suite-user mailing list
> Jts...@li...
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user