I have a dataset of country borders which I obtained from:


I have that dataset in both shp and SQL, but I'll put out there that I don't feel that affects my problem; however, please let me know if it does/can.

Because I'll be displaying those borders in something that uses Google Maps, I've got a problem. That problem is that countries whose polygons cross 180 degrees are displaying extremely weird in Google Maps. Either it's splitting them completely wrong, taking them all the way across the map, whatever the weirdness might be.

So, I thought I can simply address this by splitting the polygons of the countries that cross the line so that no country contains a polygon that presents a problem. Examples of such countries/regions would be Russia and Antarctica.

I therefore invoked the following: ogr2ogr -wrapdateline -t_srs EPSG:4326 new countryBorders.sql

I got: ERROR 1: TopologyException: found non-noded intersection between LINESTRING (-59.7742 -72.9003, -59.8494 -73.2331) and LINESTRING (0 -73.1221, -89.3211 -73.0542) at -59.8141 -73.0766 ERROR 1: TopologyException: found non-noded intersection between LINESTRING (-59.7742 -72.9003, -59.8494 -73.2331) and LINESTRING (180 -73.2589, -89.3211 -73.0542) at -59.8141 -73.0766

A few questions:

1: am I even doing this the right way? for example, I find it odd that I have to provide ogr2ogr the same srs as of the input. Is that translation even needed? Is that even the right SRS to use? I obtained that SRS from taking the .prj file and looking it up on this site:


2: all I want is for a few of the polygons of those few troublesome countries to get split so they don't cause any more problems. -wrapdateline seemed like the perfect solution ... maybe it's not?

I'm completely open to advice, suggestions, references, whatever.

I am perfectly willing to redo this dataset in another projection, run a one-time query against it to redo it so it is more compatible with displaying on Google Maps, anything at all. I'd love any advice. It doesn't have to involve my most probably incorrect approach outlined above.

Thanks so much in advance!

  • Can you explain what you mean by "something that uses Google Maps" ? and perhaps attach or link to a screenshot showing the problem?
    – Micha
    Aug 6, 2012 at 20:12
  • Let's say the polygon is a triangle and the dateline intersects it. Then the triangle will get wrapped all the way around the world, so instead of a little piece of triangle to the left and a little piece of triangle to the right of the dateline, for example, we'll have some triangle to the left and as soon as it hits the dateline, it won't cross but start highlighting back the other way until it gets to the point of interest on the other side of the dateline. I simply wish to split up my polygons so they don't do this. Aug 7, 2012 at 0:16
  • Also, I found this post which nicely summarizes what's going on even though he refers to Google Earth. blog.opengeo.org/2010/08/10/shape-of-a-polygon I'm actually using Mapkit on IOS not Google Maps as I stated in the original question. Google Maps is only for the tyles underneith the overlay I'm drawing that's exhibiting this problem with the dateline. Aug 7, 2012 at 2:51
  • Even Rouault on the gdal-dev mailing list suggests that the topology exceptions come from an outdated version of the GEOS library. I'm running the latest installed via apt., but can grab the source. Even says no -wrapdateline is needed because all coordinates are between -180 and 180. That helps because I now know -wrapdateline is not my answer, but what is? Summary, if a single polygon contains coordinates that cross the -180/180 boundary, then MapKit on IOS paints incorrectly. It thinks the polygon is big, wrapping/stretching it around the Earth, instead of allowing it to cross the line. Aug 11, 2012 at 19:32
  • If you're using SQL Server, you just need to use the geography type as opposed to the geometry type. Geography will allow you to wrap objects around the globe.
    – nagytech
    Aug 26, 2012 at 8:12

1 Answer 1


Basically the problem was found to be only at the value of 180.0, so by clamping to 179.9, all was solved and the maps display perfectly now. A short python script resolved this situation. It's amazing that after asking on the gdal-dev mailing list, other websites, this one, Twitter, and Facebook, not a single GIS expert was able to dispense this small piece of expertise smile.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.