8

I'm splitting a land polygon up in order to shift the centering of the projection to the Pacific ocean. I manage to successfully cut up the original polygon on the 22 meridian, and it looks fine when I do an on-the-fly reprojection with my custom CRS:

OTF polygon projection

But appears to be shifting slightly when actually saving the polygon with the same CRS:

saved polygon projection

My CRS is using this proj4 string: +proj=eqc +lon_0=-158 +datum=WGS84 +units=m +no_defs +lon_wrap=-158

Any ideas on what might be causing this?

srha
  • 839
  • 6
  • 22
  • this is caused by features overlapping the -156+180 = 24 degree east meridian (this is more commonly seen with crossing the 180W antimeridian, but is different as you've shifted the map – Steven Kay May 18 '17 at 20:47
  • @StevenKay that's actually a typo on my part :x fixed my original post – srha May 18 '17 at 21:27
  • 2
    Maybe related: https://gis.stackexchange.com/questions/70411/qgis-display-world-country-shape-files-centered-on-pacific-ocean-using-robinson. I used a sphere instead of an ellipsoid, a cut polygon 0.2 degrees wide, and no +lon_wrap option. – AndreJ May 19 '17 at 05:56

1 Answers1

6

These 'artifacts' are a well known problem, and are usually the result of polygons crossing the antimeridian (180 degrees e/w) The go-to fix for this is usally ogr2ogr with the wrapdateline option.

But that won't help you. In your case, you're using an offset around -156. This means that any feature crossing 24E meridian (-156+180 = 24) is giving you problems.

To fix this, I removed a thin strip either side of 24E.

I started with Natural Earth data, and left off projection (for now), and just used WGS84.

To draw the 24E meridian, I used the QuickWKT plugin and added the following as a new layer...

LINESTRING (24 -90,24 90)

That draws a single line along the length of the 24E meridian.

Next, I manually digitised a polygon scratch layer, adding two polygons, one to each side of the line, and a hemisphere in size, but hugging the line as close as possible. (Note the quality of the line drawing here...)

enter image description here

You should probably do that with the QuickWKT plugin too, to get more precision - it involves more typing and I wanted a quick test :)

Next, I used clip to clip my original shapefile to the layer with the two polygons. This cuts out a thin strip around the 24E meridian...

enter image description here

finally, I applied OTF projection using your custom CRS - and the fixed result.

enter image description here

Steven Kay
  • 20,405
  • 5
  • 31
  • 82
  • Ah, oh no! Wish I'd gotten back to my computer sooner before you did all this work for me. My proj4 string was actually around 158; I just pasted the wrong one in (with 156) after doing some experimentation. – srha May 18 '17 at 21:31
  • you'll see the same issue with 158 (i do anyway) - just change 24 to 22 . If you got it to work without doing this let me know how - i'd not found the lon_wrap feature in proj4 until quite recently :) (come to think of it, that might explain why Madagscar seems slightly offset...) – Steven Kay May 18 '17 at 21:44
  • 1
    So I did all the steps you did (essentially) - WKT polygon strip around 22; Vector > Geoprocessing > Difference w land as my input layer and WKT strip as the difference layer; OTF reproject. Up til that point everything looks great. The problem arises after I save my resulting polygon with the same custom CRS - the saved polygon is all wonky but the OTF one is fine :( – srha May 18 '17 at 21:52
  • 1
    thanks for clarifying... just loaded the saved layer from my (now discarded) project (saved using the custom proj4 crs) and the lon_wrap value isn't showing up in the layer metadata. that might be the problem – Steven Kay May 18 '17 at 22:03
  • Hmm. Do you know how to fix that? I find the proj4 documentation a bit confusing. – srha May 18 '17 at 23:21
  • ok, tried again with a fresh pair of eyes :) it works fine when projected (QGIS 2.18.2). Make sure you choose the correct CRS when saving, when I tried this I picked the one which was shifted off by 2 degrees and saw the same thing as your first screenshot. Give the CRSes obvious names to make them easier to pick out. – Steven Kay May 19 '17 at 12:34
  • You know, after quitting & shutting down the computer for the end of the day and then coming back today, I re-saved the polygon again and it was fine. I think after fiddling around with the CRS, you may need to actually restart QGIS before saving a polygon with it. So the CRS changes work fine for OTF, but QGIS needs to be restarted for it to save correctly?? Bug, maybe? I have them all well-named so (I'm fairly sure) I was choosing the correct one each time! – srha May 19 '17 at 19:31