This is a new question based on a response on the thread white page border when converting geoPDF to geoTiff with gdal_translate

I am using gdalwarp as described to do a cutline of GeoTIFF images that have been rendered from geospatial PDFs. The neatline in the PDFs is not accurate but I can easily create UTM coordinates and adjust them accordingly to get the GeoTIFF image that I desire.

This is the CSV file. The coordinates are not square

1,"POLYGON ((410290.5552 4025996.01,410434.6684 4039895.26,421656.358 4039786.037,421530.3048 4025886.935,410290.5552 4025996.01))"

This is the command line:

gdalwarp original.tif original.crop.tif -cutline mycutline.csv -crop_to_cutline

The new image is square and the cropped image is canted inside as is expected. The problem is that the outer crop area is showing up as black. When I tile the image and display it on top of a map base layer, it aligns perfectly except that it has a black edge around it. If the edging was transparent then it would be fine, but the when tiled, it definitely retains the black color.

Here is a sample image http://www.appalachianbiketrails.org/images/resized.tif

Here is the tile example http://www.appalachianbiketrails.org/tiles/openlayers.html

I have tried adding the -dstalpha flag as mentioned in other posts and shown in the code snippet below, but that gives the error "Cannot compute bounding box of cutline."

gdalwarp original.tif original.crop.tif -cutline mycutline.csv -crop_to_cutline -dstalpha

On a side note, I found that the direction of the coordinates in my CSV file determined whether the crop was inside or outside of the coordinates.

  • 1
    Have you tried -dstnodata 0? – user30184 Mar 12 '16 at 19:04
  • It gives the error "Cannot compute bounding box of cutline." which is what I get when I use -dstalpha. – bakerjw Mar 13 '16 at 20:33
  • I would have a try with some other format than .csv for the cutline. Convert it into for example shapefile and add the info about the projection with -a_srs and see if that helps. – user30184 Mar 13 '16 at 21:28

For those finding this via search, note the NEATLINE (as obtained from gdalinfo) in many (all?) USGS quad PDFs are incorrect, being larger than the correct NEATLINE (still true in 2020 as of this post). Is why above did not work.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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