[postgis-users] [postgis-devel] Geog/Geom Hack

[Paragon Corporation]

Havard,

Good points. You stated my concerns better than I could.  

I see the benefit of having these functions and even think we should have
them linked in our documentation, but I don't want to "pollute" our
production waters with them.  So I would much prefer just a link to these
functions as a separate thing people can improve on.  As Nicklas and I think
Steve mentioned -- use it almost like a tutorial to demonstrate how you can
expand on the functionality of geography and see how people improve on it.

the problem with putting it in our production code is 
a) People will see it as a black box and won't bother to look behind the
covers and then they'll be disappointed when they run into issues and think
the whole geography datatype is a hack.
b) With our new policy of release, we won't be able to make patches to it or
add new ones until the next minor.  Which to me puts novices at a great
disadvantage.
c) I don't feel we know absolutely the best way of doing these even from a
hack point of view and I would like to see what others come up with as
solutions.

The geography functions we have in place are really spectacular I think.
They do the right thing - they measure around a sphere/spheroid and use a
more advanced spatial index (though just WGS84 for this first release).
Sure they don't do everything, but they satisfy the number one need of many
people -  How do I figure out proximities, areas, lengths and get real
accurate distances with long lat data and still have full power of spatial
indexes?

I would hate for people to think the whole thing is a hack by introducing
these things in what we call "production". 

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Havard
Tveite
Sent: Monday, November 02, 2009 5:13 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

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/
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel