I'd point out that there is some existing code in Geotools that can
help out with this problem. They've got a class called
GeodeticCalculator or something like that. It can return distances on
the surface of the Ellipsoid between two points.

Martin is the King of JTS, but I'll throw in my 2 cents:

I think JTS is popular and successful because it does one thing
(represent 2D goemetries on a plane) and it does it well. JTS doesn't
mess with curves, it doesn't mess with 3D, and I don't think it should
mess with geometries on the ellipsoid either. Package that stuff in a
separate library that could interface with JTS at some level.

Think about Coordinate objects in JTS for a minute. The z ordinate is
there, but it isn't really used. In some sense that makes JTS a 2.5 D
library. I think any good library that deals with geometry
calculations on the ellipsoid should be set up for true 3D
calculations.

I'd also point out that map projections don't solve all problems, as
mentioned above. I think geometry calculations on the ellipsoid is a
unique problem domain that stands all on its own. It deserves its own
library. (Or clearly segregated packages at least.) :]

The Sunburned Surveyor

On Thu, Feb 5, 2009 at 9:37 AM, Martin Davis <[email protected]> wrote:
> Thanks, Rory.
> This adds to my impression is that there isn't a big driver out there to add
> the ability to compute on the ellipsoid to JTS.  It would be nifty to do -
> but perhaps not worth the time and effort?
>
> Any comments, Jeff?
>
> Rory Plaire wrote:
>>
>> In SharpMap, we use on-the-fly reprojection a lot, and the computational
>> cost of doing this is a small percentage of application CPU consumption,
>> even with millions of coordinates. I'd suspect it would be a fairly
>> efficient route, computationally, if the error which can result from
>> projection can be tolerated.
>> On the java side of things, I've used JTS with GeoTools' OGC-compliant
>> reprojection code quite successfully for similar tasks as this - projecting
>> from lat/lon to mercator, performing some measurements, and unprojecting
>> back to lat/lon.
>>  -r
>> On Thu, Feb 5, 2009 at 9:21 AM, Martin Davis <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>    More thoughts on this...
>>
>>    I can imagine a JTS enhancement which would offer the following:
>>    - ability to define a Datum (Cartesian, spherical, ellipsoidal)
>>    - ability to define a mapping from the Geometry coordinate system
>>    onto the Datum coordinate system (Cartesian or spherical).  This
>>    would support using existing Map Projection libraries to perform
>>    this transformation.
>>    - this information would be carried as parameters on the
>>    GeometryFactory
>>    - functions to compute distance, area, and azimuth on the Datum
>>    - a way of injecting this information into operations which
>>    required it
>>    - updates to operations to use the Datum-based metrics in internal
>>    computation
>>
>>    I'm not sure about the interface to Map Projection libraries.
>>     That would imply coordinate conversion on the fly, which is
>>    perhaps too expensive.  Maybe it's better to leave this as an
>>    external concern, and just support 3 datums (Cartesian, spherical,
>>    ellipsoidal) using standard spherical coordinates (lon/lat).
>>    (Although if this idea is taken to the extreme, you wind up with
>>    Rory's suggestion of simply transforming in to a Cartesian space
>>    and computing there.  I'm interested in see what people think
>>    about this.)
>>
>>
>>
>>    Martin Davis wrote:
>>
>>        You're correct.  Operations in JTS assume a uniform Cartesian
>>        grid.  This makes metric operations such as distance problematic.
>>
>>        There's nothing currently in JTS to address this.  I have had
>>        some thoughts about starting work on supporting ellipsoidal
>>        models for distance calculations.  Haven't got very far with
>>        this, though.  If you want to help out it would be helpful to
>>        know what operations you want to perform in the ellipsoidal
>>        space (e.g. distance between points, length/area, buffering,
>>        etc).  It's going to be a big job to retrofit all existing
>>        operations, but the first place to start is to get some use
>>        cases identified, and then perhaps to provide some simple
>>        prototype implementations which can be used to test out the
>>        design.
>>
>>        Martin
>>
>>        Jeff Adams wrote:
>>
>>            I think this has been discussed before, but I just wanted
>>            to double-check... am I correct in thinking that
>>            operations like "distance" do not produce useful results
>>            when working in a lat/lon coordinate system?
>>
>>            I.E. they produce results in "degrees" but since a degree
>>            is not a constant distance along the surface of the earth,
>>            it can't be compared usefully with any other distance.
>>
>>            I know PostGIS has a "DistanceSphere" function that will
>>            calculate distance (in meters) across the surface of a
>>            sphere between two lat/lon points, is there anything
>>            similar in JTS?  Or another library I might use?
>>
>>            Thanks,
>>            Jeff
>>
>>  ------------------------------------------------------------------------
>>
>>            _______________________________________________
>>            jts-devel mailing list
>>            [email protected]
>>            <mailto:[email protected]>
>>            http://lists.refractions.net/mailman/listinfo/jts-devel
>>
>>
>>
>>    --    Martin Davis
>>    Senior Technical Architect
>>    Refractions Research, Inc.
>>    (250) 383-3022
>>
>>    _______________________________________________
>>    jts-devel mailing list
>>    [email protected]
>>    <mailto:[email protected]>
>>    http://lists.refractions.net/mailman/listinfo/jts-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> jts-devel mailing list
>> [email protected]
>> http://lists.refractions.net/mailman/listinfo/jts-devel
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> jts-devel mailing list
> [email protected]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel

Reply via email to