6

I'm trying to transform this shapefile from EPSG:3338 (Alaska Albers) to EPSG:4326.

When I display the file in EPSG:3338 in QGIS it looks as you'd expect:

enter image description here

But when I display it in EPSG:4326 I see all kinds of problems:

enter image description here

And when I export it as EPSG:4326 I see the same problem. This happens both whether I export it in QGIS, or use ogr2ogr:

ogr2ogr -f GeoJSON -s_srs EPSG:3338 -t_srs EPSG:4326 .   
  mv_oil_and_gas_basin_py.geojson mv_oil_and_gas_basin_py.shp

How can I transform this file to EPSG:4326 without getting problems around the international dateline?

mgri
  • 16,159
  • 6
  • 47
  • 80
Richard
  • 3,289
  • 6
  • 35
  • 66
  • you'll need to use the technique described in https://gis.stackexchange.com/questions/70411/qgis-display-world-country-shape-files-centered-on-pacific-ocean-using-robinson to put a break in at 180 – Ian Turton May 22 '17 at 10:03

1 Answers1

8

You can use -wrapdateline in ogr2ogr to split the polygons at the anti meridian (as the dateline in fact misses Alaska).

ogr2ogr -s_srs EPSG:3338 -t_srs epsg:4326 -wrapdateline output.shp mv_oil_and_gas_basin_py.shp

Once I fixed the 4 invalid polygons I get this: enter image description here

Ian Turton
  • 81,417
  • 6
  • 84
  • 185
  • Unfortunately that hasn't solved the problem - still looks the same in QGIS. (I tried: ogr2ogr -s_srs EPSG:3338 -t_srs EPSG:4326 -wrapdateline output_file.shp mv_oil_and_gas_basin_py.shp. Trying without the t_srs option produced a warning.) – Richard May 22 '17 at 11:08
  • It would work if all the polygons were valid. – Ian Turton May 22 '17 at 12:23
  • It doesn't, sorry - I just tried importing the shapefile to PostGIS and running ST_MakeValid on all the polygons, and I get the same result. – Richard May 22 '17 at 12:58
  • Thanks! What worked for me in the end was to import it to PostGIS without reprojecting, then run ST_MakeValid, then export it using ogr2ogr to reproject to 4326 on the fly, with the -wrapdateline option. – Richard May 22 '17 at 14:34
  • I guess that wrapdateline produces the invalid geometries during cutting, while my workaround from the linked question does not. – AndreJ May 23 '17 at 05:45
  • @AndreJ - no there are 4 invalid geometries in the downloaded dataset, mostly reversed winding order – Ian Turton May 23 '17 at 07:39