[postgis-users] Geography casting woes

[Marshall, Steve]

I've been having some trouble with casts between geometry and geography 
in 1.5.2.  I'd like to solicit the rest of the community for feedback on 
this issue.

I have used both vanilla 1.5.2 code and modified code referenced in an 
earlier post 
(http://postgis.refractions.net/pipermail/postgis-users/2011-January/028672.html).   
However, in either set of code, the problem is essentially the same.  
Geography objects cannot represent some types of valid geometry objects 
that are in SRID 4326.  This means that you cannot cast between geometry 
and geography without either errors (in vanilla 1.5.2) or information 
loss (in the modified code).

The problem is best exhibited by polygons or linestrings that cross the 
international dateline.  To handle such cases as geometries, I've 
allowed the longitude coordinates to run  less than -180 or greater than 
+180, so that the coordinates increase from left to right in the 
resulting geometry.  However, this approach is not allowed in 
geographies; the constructors have checks that force longitudes into the 
range -180 to 180.   If you force the coordinates of such a geometry 
into the -180 to 180 range, you drastically change the geometry.  In 
some cases the geometry can become invalid.

I'm wondering if the constraints on longitude values for geography 
objects should be relaxed.  If the range of values spanned two rotations 
of the earth (i.e. 720 degrees from -360 to 360), any dateline crossing 
could be legitimately handled by geographies without information loss if 
they are casted back to geometries.  Since geographies have so few 
functions currently, users will frequently need to cast data back and 
forth between geometry and geography.  Therefore, it would be good to 
ensure casts are lossless in both directions.

If there is some reason that geographies must have the -180 to 180 
range, I think that geometry-geography casts must be more tightly 
controlled.  Currently I run into cases where implicit casting sometimes 
chooses to cast to geography, rather than geometry, with erroneous 
results.  These cases are hard to reproduce, as they do not happen 
consistently.  As of 1.5.2, all the casts between text, geometry, and 
geography are all implicit, which allows postgres to follow several 
different paths for implicit casting.  This is a recipe for trouble, as 
this excerpt from the "CREATE CAST" document describes:

<start quote>
It is wise to be conservative about marking casts as implicit. An 
overabundance of implicit casting paths can cause PostgreSQL to choose 
surprising interpretations of commands, or to be unable to resolve 
commands at all because there are multiple possible interpretations. A 
good rule of thumb is to make a cast implicitly invokable only for 
information-preserving transformations between types in the same general 
type category. 

Sometimes it is necessary for usability or standards-compliance reasons 
to provide multiple implicit casts among a set of types, resulting in 
ambiguity that cannot be avoided as above. The parser has a fallback 
heuristic based on /type categories/ and /preferred types/ that can help 
to provide desired behavior in such cases. See CREATE TYPE 
<http://www.postgresql.org/docs/9.0/static/sql-createtype.html> for more 
information.
<end quote>

To ensure the reliability of both geometries and geographies, I think we 
need to do one of two things: either be able to convert losslessly 
between geometry and geography types OR be able to better control 
casting between geometry and geography to avoid unpredictable results 
from implicit casts.  I'm interested in thoughts from the community on 
which approach would be best, or if there is another way to solve this 
problem.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20110405/da325b5b/attachment.html>