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]>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] >>> 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
