<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
I have used both vanilla 1.5.2 code and modified code referenced in an
earlier post
(<a class="moz-txt-link-freetext" href="http://postgis.refractions.net/pipermail/postgis-users/2011-January/028672.html">http://postgis.refractions.net/pipermail/postgis-users/2011-January/028672.html</a>).
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
<start quote><br>
It is wise to be conservative about marking casts as implicit. An
overabundance of implicit casting paths can cause <span
class="PRODUCTNAME">PostgreSQL</span>
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.
<div class="NOTE">
<p>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 <i class="FIRSTTERM">type categories</i> and <i
class="FIRSTTERM">preferred types</i> that can help to provide desired
behavior in such cases. See <a
href="http://www.postgresql.org/docs/9.0/static/sql-createtype.html">CREATE
TYPE</a> for more information.<br>
<end quote><br>
</p>
<p>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.<br>
</p>
<blockquote class="NOTE">
<p><br>
</p>
</blockquote>
</div>
<br>
</body>
</html>