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.
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
