FYI, this is now resolved and will be in the 1.5.1 release. http://trac.osgeo.org/postgis/ticket/450
P. On Wed, Feb 24, 2010 at 2:32 PM, Paul Ramsey <[email protected]> wrote: > OK, this looks like a bug... > > The area of 1 versus the area of 359 is expected, since the geometry > object does not handle the dateline. However, the geography area > should be identical in both cases. So, I have a bit of work to do. > > More information as I find it. > > P. > > On Wed, Feb 24, 2010 at 10:38 AM, Dale Noss <[email protected]> wrote: >> >> I'm confused about whether the new Geography type correctly handles shapes >> that cross the date-line. The documentation in >> http://postgis.refractions.net/documentation/manual-1.5/ch04.html#id2802139 >> reads: >> >> "What about the date-line and the poles? >> >> All the calculations have no conception of date-line or poles, the >> coordinates are spherical (longitude/latitude) so a shape that crosses the >> dateline is, from a calculation point of view, no different from any other >> shape." >> >> Section 4.2.3.3. reads: >> >> "What is the longest arc you can process? >> >> We use great circle arcs as the "interpolation line" between two points. >> That means any two points are actually joined up two ways, depending on >> which direction you travel along the great circle. All our code assumes that >> the points are joined by the *shorter* of the two paths along the great >> circle. As a consequence, shapes that have arcs of more than 180 degrees >> will not be correctly modelled." >> >> The st_distance() function returns a sensible result for points that lie on >> either side of the >> date-line. >> >> g4wd=# select st_distance('POINT(179.5 1)'::geography, 'POINT(-179.5 >> 1)'::geography)/1000; >> ?column? >> ------------------ >> 111.302645148245 >> (1 row) >> >> The st_area() function also returns a sensible result for a square degree >> near the equator. >> >> g4wd=# select st_area(g)/1000000, st_area(transform(geometry(g), 4326)), >> astext(geometry(g)) from (select 'POLYGON((178.5 2, 178.5 1, 179.5 1, 179.5 >> 2, 178.5 2))'::geography) as foo(g); >> ?column? | st_area | astext >> -----------------+---------+---------------------------------------------------- >> 12304.814950073 | 1 | POLYGON((178.5 2,178.5 1,179.5 1,179.5 2,178.5 >> 2)) >> (1 row) >> >> If the GEOGRAPHY object crosses the date-line, I see results similar to what >> I'd get using a POLYGON. In other words, the calculations cannot be choosing >> the shorter of the two possible paths along a great circle. (See query >> results below) 359 implies choosing the longer path, and I have no idea why >> the area in square kilometers is roughly 4.5x instead of 359x larger than >> the non-dateline case above. >> >> g4wd=# select st_area(g)/1000000, st_area(transform(geometry(g), 4326)), >> astext(geometry(g)) from (select 'POLYGON((179.5 2, 179.5 1, -179.5 1, >> -179.5 2, 179.5 2))'::geography) as foo(g); >> ?column? | st_area | astext >> ------------------+---------+------------------------------------------------------ >> 55910.8880691158 | 359 | POLYGON((179.5 2,179.5 1,-179.5 1,-179.5 >> 2,179.5 2)) >> (1 row) >> >> ///////////////////////////////// >> My setup: >> g4wd=# select postgis_full_version(); >> postgis_full_version >> ----------------------------------------------------------------------------------------------------------- >> POSTGIS="2.0.0SVN" GEOS="3.2.0-CAPI-1.6.0" PROJ="Rel. 4.7.1, 23 September >> 2009" LIBXML="2.6.16" USE_STATS >> (1 row) >> >> g4wd=# select version(); >> version >> -------------------------------------------------------------------------------------------------------------------------------------------- >> PostgreSQL 8.4.2 on powerpc-apple-darwin9.8.0, compiled by GCC >> powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490), 32-bit >> (1 row) >> >> Running OS X 10.5.8 >> >> Work arounds, clarifications, links to solutions will be much appreciated. >> >> -- >> View this message in context: >> http://old.nabble.com/Can-GEOGRAPHY-object-cross-the-date-line-tp27714275p27714275.html >> Sent from the PostGIS - User mailing list archive at Nabble.com. >> >> _______________________________________________ >> postgis-users mailing list >> [email protected] >> http://postgis.refractions.net/mailman/listinfo/postgis-users >> > _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
