[postgis-devel] Geog/Geom Hack

Havard Tveite havard.tveite at umb.no
Mon Nov 2 02:12:48 PST 2009


My opinion is, that if this is to be implemented, it must be
properly documented (for all affected functions and for the
geography support in general).  The support for geography in
1.5 will also have to be called "experimental" with this kind
of behaviour.

Since the plan is to implement all the functions properly
in the future, I think it is a good idea to use the function
names that are going to be used in the future (as Paul
suggests).  However, I guess it can be a lot of work to
do a proper implementation of some of these functions for
geography.

Paul's approach is clearly a hack, and the results will be
unreliable.
Examples: Using this approach, a geography line may not be
contained in it's buffer.  An intersection between to
geography lines will in the normal case not be on any of the
original lines.
So, we must expect a lot of topological inconsistencies
using this approach.

For cases where it is not possible to find an OK "BestSRID",
an error should probably be thrown.

Håvard Tveite

Paul Ramsey wrote:
> I'm interested to know what the general opinion is of the trick I've
> used on ST_Buffer(geography):
> 
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541
> 
> I ask because I could apply the same idea to the larger suite of OGC
> SFSQL predicates before release. Is half-a-loaf better than no loaf in
> this case? (Note that there will be failure cases for really large
> geometry, like a polygon of "Asia" or "Russia" that have polygons over
> the dateline.)
> 
> P.

-- 
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB
Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/



More information about the postgis-devel mailing list