[postgis-users] Seamlessly handling lat/long coordinates

[Stephen Woodbridge]

Paul,

Thanks, this reminded me of all the complexity involved in this area.

I can't speak for anyone else, but it would greatly simplify my life if 
there were functions like buffer_sphere(), *_sphere(), etc. For most of 
the operations that I would like "magic" to apply, I can live with the 
approximation of a sphere. The things that come to mind are locating 
points along a path, route or point and some radius for web based 
geolocational services. I think this kind of request typically comes 
from people that are not geographers, that don't understand or care 
about the complexities of math, and will typically learn just enough to 
make a work-a-round to the problem in PostGIS without really 
understanding all/any? of the issues involved anyway.

So making it easy for this class of people to use the product will 
greatly expand its acceptance and usefulness in the market place. Sure 
you will get an occasional person that is using it in appropriately, but 
that could be largely avoided by adding a good description of the issues 
in the documentation, so you can point the user to RTFM.

By the way, I'm a TOTAL PostGIS convert at this point! My biggest regret 
is not jumping sooner onto this wagon.

Wearing my PostGIS Tee,
   -Steve

Paul Ramsey wrote:
> 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
>