For my first mapping project since college 15 years ago, I need the Natural Earth I 10m in a Lambert Azimuthal Equal Area projection centered on North America.
I’m limited to free tools — I’m using Quantum GIS for building the map, but it can’t reproject raster files. I found the very useful gdal utilities, and I think I have the command line figured out:
gdalwarp -s_srs EPSG:4326 -t_srs EPSG:2163 NE1_LR_LC_SR.tif NE1_LR_LC_SR_reprojected.tif
However, this leaves a large jagged gap through far northeastern Asia, which is going to end up still being visible in the upper left corner of my final map.
Does anyone have any hints or advice they can give me? Is there a better tool I can use?
Congrats on getting back into mapping!
Can you post a screenshot of the problem area? It will help in diagnosis.
You could be suffering from a known issue with the GeoTIFF having a slight offset in the tag registration versus the .TWF registration. Or you could be using the wrong ellipsoids.
Here are some screenshots:
http://www.flickr.com/photos/45680204@N06/sets/72157623020406148/detail/
I’ve put an overlay of the 10m coast layer on a couple of the screenshots, so you can see that it almost does appear that data is missing from the output.
As far as the ellipsoids, I’m using the standard EPSG ID’s for reference systems, which I obtained by reviewing the options available in Quantum GIS.
According to Quantum GIS, the source EPSG: 4326, points to WGS 84, or in the full Proj syntax: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs. I believe it said somewhere on this site that the Natural Earth maps are in WGS 84.
The destination is 2163, Lambert Azimuthal Equal Area -> US National Atlas Equal Area, or +proj=laea +lat_0=45 +lon_0=-100 +x_0=0 +y_0=0 +a=6370997 +b=6370997 +units=m +no_defs.
If there is a problem with my parameters, or how I’m trying to go about this, can anyone give me any ideas to try?
If it is a problem with the Natural Earth base map, does anyone have any ideas for a workaround until it can be fixed?
Can you provide the latitude longitude extent that Quantum / GDAL thinks the raster image has? If it does not start at -180, 90 (but rather something like -180.xxxxxx, 90.yyyyyyyy) then it is likely the GeoTIFF problem. There is a way to over write the extents. You want it to read -180 and 180 on left right and 90 and -90 on top and bottom. The developer of the software we used to write out the GeoTIFFs is still looking into the problem and with the holidays in the US, this prob. won’t be resolved for another week or two. If you can read in the .TWF and use those coordinates instead, you’ll be good.
Thanks for the idea. I tried stripping out the geotiff metadata so that it would look at the world file instead, and I still had the same problem.
Also, here: http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg05214.html, a difference between the origin in the world file versus the geotiff is expected and normal. The difference I see (-180.00000, 90.00000 in the world file and -180.0111111, 90.0111111 in the geotiff — the geotiff origin is northwest of the world file origin) is exactly as described in that thread, assuming a pixel size of .0222222. The world file origin is in the center of the pixel, and the geotiff origin is on the outermost corner.
So, the good news is that I’m not certain that there is any problem with Natural Earth (assuming that link above is correct). The bad news, for me, is that I’m going to have to figure out what else I might be doing wrong 
.
Thanks for your help, though.
Try replacing these for the 10m and 50m world files respectively (thanks Hans!):
0.01666666666667
0.00000000000000
0.00000000000000
-0.01666666666667
-179.99166666666667
89.99166666666667
=====================
0.03333333333333
0.00000000000000
0.00000000000000
-0.03333333333333
-179.98333333333333
89.98333333333333
I tried both of these in the world file (although I’m only doing the 10m), and gdalwarp throws out an error message when I try to transform with those .
ERROR 1: Too many points (441 out of 441) failed to transform,
unable to compute output bounds.
I’ve decided not to use the raster image in my project for now, until I build up my experience a little and have more time to play with it (which will not be soon). I’ll still be using the vector data, however, which is working out very nicely.
Thanks for your help, and thanks a lot for this wonderful data set.
For completeness sake:
10M hi-res
0.01666666666667
0.00000000000000
0.00000000000000
-0.01666666666667
-179.99166666666667
89.99166666666667
10M lo-res
0.02222222222222
0.00000000000000
0.00000000000000
-0.02222222222222
-179.98888888888889
89.98888888888889
50M
0.03333333333333
0.00000000000000
0.00000000000000
-0.03333333333333
-179.98333333333333
89.98333333333333
Open an existing tfw file with a text editor, replace its content with the appropriate updated version and save it again under the same name. Save it as a plain text file. The tfw file should contain only 6 lines, nothing else.
The 50m and 10m raster data on the NE download page are updated and now contain Hans’ corrected TFW files. I did tests in NSD Pro 5 georeferencing the rasters with the TFW files and reprojecting them. No funny gaps appeared at the 180th meridian.
Please let us know if you still experience reprojection problems. And many thanks for letting us know about this.
Tom
Hee hee, sorry, now it’s even worse. Not only is the artifact still there, but the final result is only half as wide as it should be, cutting off on about the central meridian of the projection and everything to the right of that.
Also, the world file in NE1_LR_LC_SR.zip is named “NE1_LR_LC_SR.tfw.txt” instead of “NE1_LR_LC_SR.tfw”.
Anyway, if it’s working in other programs, it must be a problem with the gdal tools.
As I’m not using the raster layer in my project anymore, I don’t have much time to play with this, I’ll have to leave it open for anyone who’s more experienced with the gdal tools. Unless someone has suggestions on other free tools that will do this reprojection correctly.
I’ll post a GeoTIFF version of the NE1_LR_LC_SR file for you momentarily to see if that fixes the problem for you.
A little more background: the world file (TFW) that comes with the TIF does not specify the projection as WGS84 geographic. It does set the upper-left corner and the cell size. Se either the wrong world file (maybe for the High-res?) is being used but that TIF doesn’t have enough pixel width to make up for it. The GeoTIF option includes projection and cell registration all in one single file. I hope this solves your problem! If so, we’ll roll out GeoTiff versions of all raster imagery in Natural Earth.
Please try this file:
http://www.nacis.org/naturalearth/temp/NE1_LR_LC_SR_GEOTIFF.zip
There is a world file, but you shouldn’t need that.
I’ve figured out what the problem was. Thanks for all of your assistance in trying to help me figure this out, I know you spent some time on it.
I switched over to using Grass GIS (http://grass.itc.it/), and I was able to reproject the raster data I had without getting a broken Alaska. As I guessed, the problem was with my own inexperience and/or my configuration of the gdal tools, so there was absolutely nothing wrong with *your* data. Now, I don’t know what I was doing wrong before, but I’ve achieved my goal down a different path, so I’m fine with it.
Great to hear it worked out for you
We have successfully transformed it to spherical mercator for use with OpenStreetMap using GDAL without having the black lines mentioned above.
However we loose some of the top and bottom of the world, is there any way to keep this ?
See http://91.143.80.122/osm_tiles_test/0/0/0.png
Thanks for your help
@ loffenauer: The original files have the full ±90 extent. When you import them raw in geographic original projection, do you see the missing area? Sometimes web Mercator clips the top and bottom since the distortion is so extreme in the higher latitudes. Perhaps there is a setting in GDAL to preserve these areas? Cool! What OSM rending will this be included in?
.
