[postgis-users] Seamlessly handling lat/long coordinates

Craig Miller craig.miller at spatialminds.com
Tue Aug 30 01:01:44 PDT 2005 

Lance,

I know this is addressed to Paul, but a couple of thoughts:

- PostGIS is an implementation of an OGC specification.  I'm sure that it
would be fairly unpopular to do a partial implementation as it relates to
the sphere.

- Interestingly enough,  the topological relations realized on the plane
using the standard 9 intersection model actually yields 12 relations when
realized on a sphere.  This would indicate that the OGC spec itself should
be updated to accommodate the additional relations available on a sphere.
If anyone cares:  http://www.spatial.maine.edu/~max/RJ51.html

- I don't want to discourage you, because I too think it would be a popular
product.  I believe however that it is a lot of work in a significantly
different direction than PostGIS is currently going in.  I wouldn't know
this for sure though, since I haven't looked at the code in detail for a
very long time.

--Craig


-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Lance
Arlaus
Sent: Saturday, August 27, 2005 11:46 PM
To: 'PostGIS Users Discussion'
Subject: RE: [postgis-users] Seamlessly handling lat/long coordinates

Paul-

Thanks a lot for the thorough answer to my question.  I did take a cursory
look at the math involved and, ouch, it's certainly not trivial.  However, I
hope you don't mind if I take the conversation one step further.  I'm just
left with the sense that this may be one of those situations where the
perfect is the enemy of the good to the detriment of a terribly common use
case outside the hardcore GIS crowd.

For the purpose of discussion and clarification, I'm assuming the following
use case:
1. The user has a number of points and geometries defined in a geodetic
coordinate system (WGS84 or other).
2. The points are located over a large region that no standard single
projection can easily accommodate (continental US for example.
3. Creation of new geometries is rare.  This includes boolean operations
such as union, intersection, and the like as well as buffering.
4. Query of geometries is frequent.  This includes contains, intersects,
overlaps, etc., but not less common operations such as area.  Note that
distance calculation may fall into this category, but only after narrowing a
selection based on a bounding box filter, as is common best practice.
5. The user is willing to trade accuracy and functionality for speed and
simplicity.  Of course, everyone's definition of "good enough" will vary,
but I'm guessing that either a reasonable standard can be achieved or,
perhaps, the system can include a configurable accuracy goal for iterative
algorithms.  After all, if you're going for meter level accuracy, you're
probably doing something more sophisticated and are not a candidate user for
this feature anyway.

Based on the above, I'm left with the following.

1. Is there a reasonable, clear feature set that can be defined to address
this problem, especially given the lopsided usage profile (many queries with
few creations) and the fact that the user is willing to accept some
limitations and constraints?  For example, prohibiting mismatched coordinate
systems (the user doesn't even want to deal with disparate CRS in the first
place).  I'm not trying to trivialize this, I'm just wondering if a
reasonable comprimise can be reached to serve a large audience of users.  Of
course, the constraints would have to be well documented and communicated to
prevent inappropriate use and resulting headaches for you and others that
generously donate your time.
2. Can these features be seamlessly integrated to make functions on geodetic
reference systems "just work" without comprimising the integrity or
performance of the rest of the system?  Or, is this such a disparate feature
that it becomes it's own addon or such?  As you mentioned, I wouldn't want
to introduce "magic" that's detrimental to other users, but perhaps that's
not the case if it's well designed or properly segmented.
3. How does DB2 Geodetic approach this problem?  What's their performance
profile and do they impose simplifying limitations?  I haven't worked with
the product (nor can I), but it's always helpful to understand others'
approaches before potentially reinventing the wheel.


Thanks again for responding to my original message.  I'm really hoping that
something good can come of the conversation.

-Lance

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, August 26, 2005 11:47 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Seamlessly handling lat/long coordinates


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.

_______________________________________________
postgis-users mailing list postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

More information about the postgis-users mailing list