2

I've carefully cut the collar off a set of USGS geotifs and I'd like to run through them with gdal2tiles but producing a vrt that undersands the alpha layer, or having gdal2tiles overlap two source files into one tile is not working. Some things I have tried have made all black pixels transparent. Other attempts rendered the transparent borders on my source files as if they were solid white, so when one tile is made from two adjoining tifs the transparent border from one covers up the useful content of another. Here is my process, maybe someone can tell me a conversion step I'm missing:

  • Download regular USGS geotif from Topoquest
  • gdal_translate -expand rgba -co COMPRESS=LZW orginal.tif translated.tif
  • Open translated.tif in Photoshop, cut off the collar, save.
  • gdalcopyproj.py translated.tif prepared.tif

Do that for all of them

  • gdalbuildvrt temp.vrt *.tif
  • gdal2tiles.py temp.vrt tiles

P.S. I can merge them all smoothly with gdal_warp but on this group of 30 it is making a combined geotiff of 51223 x 65163 and on other sets there will be lots of wasted space when the source tifs are in a diagonal line but gdal_warp will create a rectangular output.

Improve this question
2
  • 1
    The final command that build a valid VRT was gdalbuildvrt -srcnodata b4 -hidenodata map.vrt *.tif. See MerseyViking's answer for how I got there
    – Craig
    Nov 3, 2011 at 21:08
  • 1
    I've written up the whole process on my blog incase anyone comes here and is starting from scratch. craig.stanton.net.nz/2011/06/07/usgs-map-tile-sets
    – Craig
    Nov 4, 2011 at 23:40

1 Answer 1

Reset to default
1

GDAL supports a mask layer, but it also supports a "no data" colour which I tend to use because it cuts the size of the final image down by 25%. So the steps I would use with your data, after cutting off the collar is:

gdal_translate -expand rgb -gcp <pixel/coordinate pairs> -co TILED=YES -a_srs <EPSG code for the map's projection> -a_nodata 255 255 255 original.tif translated.tif

Note, I've put in Ground Control Points (GCPs) and a projection which you'll have to determine empirically. Also note I've assigned pure white to the nodata value.

These images are still not properly georeferenced however, as they still only have GCPs rather than proper coordinates. So you will need to run gdalwarp:

gdalwarp -t_srs EPSG:4326 -co TILED=YES -srcnodata 255 255 255 -dstnodata 255 255 255 translated.tif warped.tif

Note again the explicit setting of the nodata values. This is probably overkill, but it doesn't hurt, and I've had gdalwarp ignore what I thought was implicit nodata vales.

Next, you need to run gdalbuildvrt like you have it, but I usually explicitly specify the nodata values again, to be on the safe side:

gdalbuildvrt -srcnodata 255 255 255 -vrtnodata 255 255 255 temp.vrt <warped files>.tif

Edit

This may be closer to what you want:

gdalbuildvrt -srcnodata 255 255 255 -hidenodata temp.vrt <warped files>.tif

Finally, you can call gdal2tiles.py as you have it.

Improve this answer
6
  • What are the GCPs for? this images area already fully georeferenced so if they are for that then I'll leave them out. Unfortunately pure white is used in the map, as is pure black and it'd be pot-luck if I tried to guess at a colour that wasn't already in use.
    – Craig
    Oct 23, 2011 at 19:42
  • The reason you need to specify GCPs is because GeoTIFFs are only georeferenced by the top left corner, and so by trimming the image down your maps will appear in the wrong place. If you have just cleared the surrounding text and not changed the image size, then yes they'll be properly georeferenced but will have a fair amount of wasted space. As for the transparent colour, because your maps only overlap at the borders, using white is ok. If you have a background layer and you don't want it to come through, do a bucket fill around your margin of a colour that isn't used such as pure magenta.
    – MerseyViking
    Oct 24, 2011 at 9:44
  • Oh right. I avoided reszing the tifs in anyway, just cleared the unwanted borders with map noes etc. If I allowed white to be the transparent colour the output tiles would be largely transparent except for the contour lines and would look very bad laid over Google Maps. You said GDAL supports a mask layer, and I know gdal_merge is able to understand transparency, how would I get gdalbuildvrt to to do the right thing so I don't have to hunt for a colour that doesn't exist in any of the 30+ tifs I'm playing with?
    – Craig
    Oct 24, 2011 at 18:19
  • Having a rethink, you won't need to specify the -vrtnodata option on the buildvrt command because you're only interested in the sources' nodata value which you can safely set at white because there is no overlap of the actual map data, and you can use -hidenodata to make it appear the VRT has no nodata. That way, when gdal2tiles.py does its thing, the output tiles won't obscure each other, and your background won't show through either. The only thing you will have is the white margin around the outermost maps but there's no way round that without trimming or using a nodata colour.
    – MerseyViking
    Oct 25, 2011 at 9:39
  • Thank you for spending time on this. I'm still getting messed up results. With these two commands I get mostly transparent tiles with tiny little slivers between the original maps. gdalwarp TILED=YES -srcnodata "255 255 255" -dstnodata "255 255 255" translated.tif warped.tif and gdalbuildvrt -srcnodata 255 255 255 -hidenodata temp.vrt <warped files>.tif and in tiles that are no near the boundary I get the background (between the contour lines) being transparent too.
    – Craig
    Oct 26, 2011 at 18:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.