3

I have a Gtiff which loads into QGIS and seems to be OK. It's a US topo. When I try to clip it to remove the margins it fails (from QGIS or from cmd line) with this error:

dt1:gdal_translate -projwin 253.875 38.625 254 38.5 -of GTiff  CO_Salida_West_451198_1983_24000_geo.tif topo.tif

Input file size is 6579, 8096 Computed -srcwin 3441 7202 0 0 from projected window. Error: Computed -srcwin 3441 7202 0 0 has negative width and/or height.

I also tried it with the corresponding negative value for longitude The output from gdalinfo:

Driver: GTiff/GeoTIFF
Files: CO_Salida_West_451198_1983_24000_geo.tif
Size is 6579, 8096
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["NAD27",
        DATUM["North_American_Datum_1927",
            SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
                AUTHORITY["EPSG","7008"]],
            AUTHORITY["EPSG","6267"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4267"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",33],
    PARAMETER["standard_parallel_2",45],
    PARAMETER["latitude_of_origin",38.5],
    PARAMETER["central_meridian",-106.0629999999992],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (-6739.200995264532139,14674.596086209008718)
Pixel Size = (2.032000000000000,-2.032000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_XRESOLUTION=300
  TIFFTAG_YRESOLUTION=300
Image Structure Metadata:
  COMPRESSION=YCbCr JPEG
  INTERLEAVE=PIXEL
  SOURCE_COLOR_SPACE=YCbCr
Corner Coordinates:
Upper Left  (   -6739.201,   14674.596) (106d 8'26.95"W, 38d37'58.41"N)
Lower Left  (   -6739.201,   -1776.476) (106d 8'26.36"W, 38d29' 1.98"N)
Upper Right (    6629.327,   14674.596) (105d59'11.22"W, 38d37'58.41"N)
Lower Right (    6629.327,   -1776.476) (105d59'11.80"W, 38d29' 1.98"N)
Center      (     -54.937,    6449.060) (106d 3'49.08"W, 38d33'30.29"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
  Overviews: 3290x4048, 1645x2024, 823x1012, 412x506, 206x253, 103x127, 52x64
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
  Overviews: 3290x4048, 1645x2024, 823x1012, 412x506, 206x253, 103x127, 52x64
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
  Overviews: 3290x4048, 1645x2024, 823x1012, 412x506, 206x253, 103x127, 52x64
  • 4
    Your projwin is geographic but your data is projected. If you're using GDAL 2.0 or higher you can specify -projwin_srs EPSG:4267 for NAD27 geographic (I think that EPSG is right, I don't deal with North American projections much). However, other problems might occur as the geographic box defining the map face is no longer perfectly rectangular due to warping by the projection.. if this is an issue you might be better to use gdalwarp with -cutline and supply a shapefile of the map face area, suitably densified, projected to NAD27/Lamberts. – Michael Stimson Nov 28 '17 at 22:25
  • @MichaelStimson I think your comment is worth a full answer. – AndreJ Nov 29 '17 at 7:58
  • I have 'enable on the fly CRS xform' set. I see that the CRS for the layer is 'Generated ...'. If I set the CRS of the layer to NAD27, the map disappears, zoom to the layer. Now the coordinates at the bottom show pixels(?) instead of lat/lon. When I use the qgis clipper now it works! – brad80242 Nov 29 '17 at 17:14
  • I have a lot to learn about GIS, so is this user error or a QGIS bug? – brad80242 Nov 29 '17 at 17:17
  • It's not a bug, nor an error, it's simply a small lack of understanding by the operator. Hopefully the answer I have posted explains a bit about why it didn't work so the next time you approach the same situation you will have the understanding. – Michael Stimson Nov 29 '17 at 21:26
2

Check your coordinations values and order of them. I had same problem because I had wrong order of coordination values. You recieved this error when output size of raster is negative.

1

Despite having 'on the fly' enabled, which incidentally means nothing to the geoprocessing tools, the coordinates that you have entered are just numbers and without a spatial reference supplied the default is the same spatial reference the raster is in. To supply a -projwin in a spatial reference other than the input rasters' existing spatial reference you can use the option -projwin_srs.

You have to remember that computers are obedient but unintelligent, the process will do precisely what you tell it to do, whether it's what you really want or not, because your coordinates numerically are not correlating you end up with a row/col range that is nonsensical which causes the process to fail.

When extracting rasters in a projected coordinate system the graticule is not rectangular, rather a slightly squashed trapezoid, using geographic coordinates for the sheet corners will trim off some of the real image or include slivers of ephemera depending on which way the distortion goes. This situation may be acceptable, you'll still end up with 99% of a map, but if you're after nothing less than 100% of the map with 0% of the ephemera then you will need to do some extra processing, either projecting the input raster to geographic coordinates with GDALWarp or create a geographic box, densify to a few minutes to allow the sides to bend, export the box in your Lamberts coordinate system and use GDALWarp with -cutline Your_Projected_extent to erase everything outside but retain the map face.

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.