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.
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’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.
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.
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.
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?
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.
