<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Coming from New Zealand, near 180, I think it is fair to say that a geometry with <br>left lon > right lon is not wrong. Just that Postgis fails to interpret such correctly.<br><br>A polygon such as POLYGON((179 -45,181 -45,181 -46,179 -46,179 -45))<br>is obviously crossing the dateline, and is geographically identical to <br>POLYGON((179 -45,-179 -45,-179 -46,179 -46,179,-45))<br><br>However it is not interpreted as such.This is not a problem unique to Postgis, and the casting of geometries to geographies, and vice versa for some geography functions, means that in Postgis, the geography datatype is still not a complete solution.<br><br>It is a topological as well as a geometric problem. Polygons crossing 180 need to be split/merged, not just "moved".<br><br>See the map of a mercator projection covering New Zealand here:<br><a
href="http://www.spatialreference.org/ref/epsg/3994/">http://www.spatialreference.org/ref/epsg/3994/</a><br><br><br>(& if anyone knows who to contact to get the proj4txt values for this projection added to the web site, please let me know)<br><br>Cheers,<br><br> Brent Wood<br><br><br>--- On <b>Fri, 7/13/12, Sandro Santilli <i><strk@keybit.net></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Sandro Santilli <strk@keybit.net><br>Subject: Re: [postgis-users] Why should these boxes intersect?<br>To: "PostGIS Users Discussion" <postgis-users@postgis.refractions.net><br>Cc: "DrYSG" <ygutfreund@draper.com><br>Date: Friday, July 13, 2012, 3:14 AM<br><br><div class="plainMail">Yechezkal, the reason why your solution isn't taken is because<br>it assumes that the geometry is expressed in long/lat.<br>This isn't always the case.<br>The semantic of units,
and thus the value of the anti-meridian<br>(if any) depends on the spatial reference system.<br><br>The GEOGRAPHY type was introduced specifically for this: add knowledge<br>about the earth shape.<br><br>In GEOMETRY semantic, a box with minx > maxx would be just wrong.<br>We choose to swap rather than throw an exception. Such choice could<br>be debatable.<br><br>--strk;<br><br> ,------o-. <br> | __/ | Delivering high quality PostGIS 2.1<br> | / 2.1 | <a href="http://strk.keybit.net" target="_blank">http://strk.keybit.net</a> - <a href="http://vizzuality.com" target="_blank">http://vizzuality.com</a><br> `-o------'<br><br><br>On Thu, Jul 12, 2012 at 07:55:27AM -0700, DrYSG wrote:<br>> Thank you Paul,<br>> <br>> You certainly are the expert, and I have learned a great deal from you<br>> posts, as well as the PostGIS book which sits on my desk with<br>> your
introduction.<br>> <br>> So I will hope you will excuse the chutzpah, but to me it feels like<br>> something is broken, and I don't think it is that hard to fix.<br>> <br>> What do you think about this as an improvement to ST_intersects:<br>> <br>> 1. Implement a "pre-pass" check for polygons that span the anti-meridian<br>> (180 longitude) (e.g. intersect with anti-meridian)<br>> 2. If there is intersection:<br>> a. Split the polygon into shards by the anti-meridian<br>> b. perform normal ST_Intersects of the shards against the other polygon (or<br>> shards)<br>> c. Boolean AND the results<br>> d. use short-circuit logic if any intersection results in false<br>> 3. If no intersection proceed as normal<br>> <br>> Notes: <br>> <br>> 1. I say something feels broken because I sense it in your article & there<br>> is no
clue in the documentation about this.<br>> 2. The test #1 can be very low overhead (just checking if the all longitudes<br>> are positive, all negative or mixed (and short circuiting if there are any<br>> mixed which would indicate a span of the anti-meridian)<br>> 3. The case where there is a span of the anti-meridian will be rare (who has<br>> that much data in the pacific?)<br>> 4. Yes, the code for handling the shards is not very elegant, but that<br>> branch would not often be taken<br>> 5. Note that my geometry column of the database is GIST indexed and the<br>> Boston rectangle is still picking up the one in the pacific, so the bounding<br>> box optimization for indexed search seems to be not working so well.<br>> 6. ST_Within might have this same issue, but the same fix should work for it<br>> (symmetry is wonderful!). <br>> <br>> The reason I do not want to go to GEOGRAPHY types is that my application
is<br>> using using a view-box (of a map) as the search box<br>> against a 20 Million record database of map objects (images, features, etc.)<br>> that are all represented as by rectangular bounding<br>> boxes. The PostGIS notes talk a lot about he overheard of GEOGRAPHY types,<br>> and it is overkill in this case. All I want to know<br>> is what is in the view-box - and rough estimates will work for that.<br>> <br>> - Yechezkal<br>> <br>> --<br>> View this message in context: <a href="http://postgis.17.n6.nabble.com/Why-should-these-boxes-intersect-tp4998895p4998924.html" target="_blank">http://postgis.17.n6.nabble.com/Why-should-these-boxes-intersect-tp4998895p4998924.html</a><br>> Sent from the PostGIS - User mailing list archive at Nabble.com.<br>> _______________________________________________<br>> postgis-users mailing list<br>> <a ymailto="mailto:postgis-users@postgis.refractions.net"
href="/mc/compose?to=postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>_______________________________________________<br>postgis-users mailing list<br><a ymailto="mailto:postgis-users@postgis.refractions.net" href="/mc/compose?to=postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></div></blockquote></td></tr></table>