<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Or use 0-360 longitudes for a single geometry polygon. Valid EPSG:4326 coordinate space.<br><br>The problem then arises if you have other data in a +-180 space...<br><br>Brent Wood<br><br>--- On <b>Fri, 9/23/11, Paul Ramsey <i><pramsey@opengeo.org></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Paul Ramsey <pramsey@opengeo.org><br>Subject: Re: [postgis-users] problem with data crossing the date line<br>To: "PostGIS Users Discussion" <postgis-users@postgis.refractions.net><br>Date: Friday, September 23, 2011, 7:47 AM<br><br><div class="plainMail">Note that while a multi-poly split at the dateline will (a) render<br>find and (b) give right answers to all functions, it will do bad<br>things (if you have enough of them) to your index, since the index<br>bbox of the
feature will cover the whole world. So even tiny queries<br>in the middle of the world will end up wading through the split<br>features as possible cases turned up by the index.<br><br>P.<br><br>On Thu, Sep 22, 2011 at 12:40 PM, Jesse Bishop <<a ymailto="mailto:jbishop@whrc.org" href="/mc/compose?to=jbishop@whrc.org">jbishop@whrc.org</a>> wrote:<br>><br>> Hi Puneet,<br>> We ran into this issue as well. As a workaround for display in QGIS, we store those features that cross the date line as MULTIPOLYGONS that are split at 180/-180 line. It is not ideal, but it works for display. It does not work for some operations like ST_Centroid but others like ST_Contains will work.<br>> Jesse<br>> Examples:<br>> As displayed in QGIS:<br>> . . .<br>> From the database perspective:<br>> smddb_dev=# SELECT AsText(scene_geom) FROM scene_locator WHERE id = 28716;<br>>
astext<br>> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>> MULTIPOLYGON(((179.665 -17.733,180 -17.6550440252,180 -18.2032131661,179.794 -18.251,179.665 -17.733)),((-180 -17.6550440252,-179.699 -17.585,-179.568 -18.103,-180 -18.2032131661,-180 -17.6550440252)))<br>> (1 row)<br>> smddb_dev=# SELECT AsText(ST_Centroid(scene_geom)) FROM scene_locator WHERE id = 28716;<br>> astext<br>>
--------------------------------------------<br>> POINT(-27.1147737791952 -17.9181176096631)<br>> (1 row)<br>><br>> smddb_dev=# SELECT ST_Contains(scene_geom, GeomFromText('POINT(-179.8 -17.8)', 4326)) FROM scene_locator WHERE id = 28716;<br>> st_contains<br>> -------------<br>> t<br>> (1 row)<br>> On Sep 15, 2011, at 4:06 PM, Paul Ramsey wrote:<br>><br>> Might want to cross-post this to QGIS, it's more their problem than ours.<br>><br>> P<br>><br>> On Thu, Sep 15, 2011 at 1:22 PM, Puneet Kishor <<a ymailto="mailto:punk.kish@gmail.com" href="/mc/compose?to=punk.kish@gmail.com">punk.kish@gmail.com</a>> wrote:<br>><br>> well, I've reached that point where I have to deal with data crossing the date line. I have kept a file on my Dropbox/Public folder [<a href="http://dl.dropbox.com/u/3526821/PA.gmt" target="_blank">http://dl.dropbox.com/u/3526821/PA.gmt</a>] which has a series of
lat/lng pairs, one per line, making a single polygon. If I insert them into PostGIS as GEOMETRY, the resulting polygon is messed up. If I insert them as GEOGRAPHY, I can't view the polygon in Quantum GIS.<br>><br>> Any suggestion on the best way to handle this?<br>><br>> Puneet.<br>><br>> _______________________________________________<br>><br>> postgis-users mailing list<br>><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>><br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>><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>><br>><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>_______________________________________________<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>