[postgis-users] Seamlessly handling lat/long coordinates

[Paul Ramsey]

Lance,

The problem is one of math.  What is the distance between two points,  
measured on an oblate spheroid?  Turns out there is no direct  
solution to the problem, it can be expressed as a set of differential  
equations that can only be solved with a (usually) converging  
approximation (god bless computer scientists) and that is what  
distance_spheroid() does in PostGIS.  That is why distance_spheroid()  
is 10 times as computationally expensive as the slightly less  
accurate distance_sphere(), which is a relatively simple trigonometry  
equation.

There are papers about how to solve area of a polygon on a spheroid  
(with some relative efficiency), apparently, so if someone did the  
primary research at the library to hunt them down it would be  
possible to implement area_spheroid().  Doing intersections, unions,  
buffers, etc, are all harder than you think, because instead of  
straight lines, if you are doing them in spheroid space, they have to  
be calculated with great circles instead.  And the calculations for  
them in cartesian space are complicated enough to start with.

Finally, making things "magic" in terms of SRS is possible, with a  
great deal of extra code wrapped about every function, that does  
coordinate reference system transformation in the event of mismatched  
CRS, and/or spheroid calculation in the event of geodetic  
coordinates.  But in some ways hiding the complexity of the problem  
is a disservice to the user: there are many ways to deal with it, and  
any "magic" would have to choose just one way; are we sure that we  
would be picking the way the user wanted? Would the existence of the  
"magic" obscure the face that tradeoffs are being made on the users  
behalf and eventually lead to even harder debugging and problem  
solving later?

For example, Intersection( GeomFromText( 'POLYGON(...)', 26910),  
GeomFromText('POLYGON(...)',42102)) ... what SRS should it return a  
result in, if it is doing magic SRS handling?

When a user runs Length(myline) and complains on the list that it is  
ungodly slow, do we then tell him that we are secretly running  
length_spheroid() on him behind the scenes because his data is  
geodetic?  Are the users of length() in cartesian space prepared to  
pay the extra overhead involved in doing a SRS lookup for all their  
geometries to confirm whether or not their SRID is geodetic or not,  
so that a magic geodetic handling system can work?

Anyhow, suffice to say that once you start peeling this onion, it  
just goes on and on and on, but the core problem is one of hard math,  
followed closely by the army of small problems that arise in  
implementing such a thing transparently and efficiently.

Paul

On Aug 26, 2005, at 2:06 AM, Lance Arlaus wrote:

> All-
>
>  I wanted to follow up on a thread from the other week.  I don't  
> know if this question is appropriate for this list or if it belongs  
> on devel instead.
>

> I'm new to GIS, but I can't help wondering what it would take to  
> enable PostGIS to easily handle lat/long coordinates.  It seems  
> like such a common use case that I'd really like to understand what  
> the hurdles are.  It would be great to have the ability to get  
> distances, create buffers, and perform boolean operations without  
> going through intermediate transformations.
>
> Can someone give me some more insight into the problem?  DB2  
> Geodetic was mentioned as a product that already accomplishes this,  
> so it sounds like it's possible.
>
> I hope this doesn’t come off as obnoxious – that’s certainly not  
> the intent.