Here are the results of some playing with gdalwarp and NASA’s Blue Marble images of the Earth. My experiences with gdalwarp and NOAA’s national weather radar mosaic, used to create a time-lapse animation of twelve months of weather, prompted a comment on the video’s YouTube page by someone having difficulty using gdalwarp with Blue Marble images. That prompted me to write up how I used my limited understanding of gdalwarp and related subjects for those radar images. But of course I had to try my hand on the Blue Marble next. What follows is how I went about it and the results I got.
I was initially put off by this post by a subject matter expert, which I definitely am not, explaining why “EPSG:4326 is usually the wrong ‘projection’.” (See my earlier post that very briefly explains EPSG codes and their use in gdalwarp.) After trying to follow his reasoning and to find some implementation of his suggested alternative, I went back and tried EPSG:4326 in this context and found that it works fine, at least as far as my eye can tell at these scales. So for now I have put aside Mr. Nielsen’s concerns to investigate further another day. In all that follows EPSG:4326 rules for the source projection.
The EPSG code is a shorthand way to define the use of a specific spatial reference system (SRS). EPSG:4326 appears to work for this case where the source is a rectangular array of pixels with fixed a constant scale. Each pixel, regardless of where it is in the source image, has a constant degree width, and each pixel in the image has a constant degree height. Therefore the pixel’s [x,y] position in the image is trivially converted to geographic longitude (x) and latitude (y).
Here is a “Blue Marble” image from NASA’s Earth Observatory. It is a “plate carrée” equirectangular projection that is not really a projection in the geometric sense. But it has that constancy of scale across the whole map to which we can apply EPSG:4326 and with which we can do some simple arithmetic for related purposes.
The initial image I worked with was scaled to a pixel dimensions of 1024 wide by 512 high for convenience. The image spans the whole Earth — 360° west-to-east and 180° from pole to pole. So each pixel is 360°/1024 wide and 180°/512 high, both of which equal 0.3515625° per pixel. So the world file for this image is trivially:
0.3515625 0.00000 0.00000 -0.3515625 -180.0 90.0
The world file calculator will do this math for you and produce the world file in the proper format. Remember that the world file is needed to tell the software where the image fits in the spatial reference system (SRS) being used. We now have both an SRS (EPSG:4326) and a world file, so we’re ready to try some projections.
Trial projections
To the right are two images. The first is an excerpt with associated text taken from the user manual by Gerald I. Evenden for version 3 of the proj program. I manually colored the map to make it clearer. Many GIS programs, including gdalwarp, use the same +proj notation for SRS notation, so we can take this example of an Albers equal area conic projection from the proj document and try to reproduce it with gdal using the Blue Marble image. The command is:
gdalwarp -s_srs EPSG:4326 -t_srs '+proj=aea +lon_0=90w +lat_1=20n +lat_2=60n' world.jpg aea-world.jpg
The result in the second image is almost identical to the example shown in the manual. Success! The gdalwarp program does crop the projection differently. I manually shaded the portion of the projection encompassed by a triangle between the center of the north polar circle and where the outside of the projection meets the top of the frame. The remaining color part of the projection appears to exactly reproduce the manual’s illustration.
The next projection that I tried is the “Polyconic (American) Projection” on page 37 of the version 3 manual for proj. The corresponding gdalwarp command used here is:
gdalwarp -s_srs EPSG:4326 -t_srs '+proj=poly +lon_0=90w' world.jpg poly-world.jpg
On the left is the example image from the manual, and the result from gdalwarp is show below. Gdalwarp apparently only shows the results that fit in the center circle of the manual’s example. I manually colored the example to highlight that portion. The gdalwarp results again very closely mirror the example, giving confidence that this approach is working correctly. You will notice that whereas the example in the proj documentation appears perfectly circular, the output of gdalwarp seems slightly elongated, and I have no explanation for that yet. The overall results appear correct, though — compare Africa, Greenland, Alaska, and Antarctica in the two images. I will call my initial efforts at projecting the Blue Marble image are a success.
One minor note to add about the use of gdalwarp in these projections is that if there is an EPSG equivalent to the target projections, then those codes could be substituted for the target SRS. I didn’t bother to look those up because I wanted to be sure that I exactly follwed the examples.
My next post will document a more complex and practical use of the Blue Marble image.








One thing to note for people who are having problems with gdalwarp being fast enough, one of the problems that GDAL has a preset cache size, so it isn’t using your many gigs of ram automatically. run it with
gdalwarp –config GDAL_CACHEMAX 500 -wm 500
subsituting 500 for how many megs you want to give it, and, in my experience, you can get some great performance increases.
Yep, huge! I did finally get it to work with that plugin, just a long processing time, of course… we’ll play with tiling into gdalwarp next time around. Anyway, thanks again for this post, it was an invaluable introduction to all the principles involved!
Gdalwarp can mosaic images together. An interesting experiment would be to chop the full-size image into smaller ones, still at full resolution, and warp them individually into a larger composite. BTW, my 21600×10800 image printed at 300dpi would be 6′x3′ (~2m x 1m), and your 86400×43200 would come out to 24′x12′ (~8m x 4m)!
@egb13, thanks for the reply. Yes, I had the same results, mine (4GB RAM) ran to just past 20% then kicked back out…
What I did manage to locate is a commercial Photoshop plugin that seems robust enough to handle these quite readily… downloaded the trial, it’s running a test on the 86400px image right now; we’ll see how it turns out. http://www.avenza.com/products.geographicimager.html
@Mark; I’m don’t know the limits of gdalwarp are, but I seem to have run into them. I tried to do a whole earth Albers equal area projection of the image at http://veimages.gsfc.nasa.gov/2433/land_shallow_topo_21600.tif, which is 21600×10800 pixels. Gdalwarp tried to swallow it but failed, saying, “ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds.”. It continued on anyway, but the output image was incomplete. The fact that it continued rather than bombing out immediately upon issuing the error makes it seem more like an internal limit than a lack of available system memory for handling such a huge image, but I don’t know. I only have 1GB of RAM in the system I use for most of this stuff.
Google didn’t help much with this error. The energetic are invited to scan the source code to determine the source of the problem.
That’s wonderful, thanks for the intro. Been playing today with using gdalwarp on the full-res blue marble image (86400×43200), as remarkably I was doing for an internet search of how to do an AEA projection warp of that very image and of course came across this posting, but gdalwarp would appear to be limited to images of 17546 strips? Have you tried this technique with (much) larger images?
Very good! I really appreciate the effort you put into documenting this!