[gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)

[Eli Adam]

On Fri, Jun 12, 2015 at 11:25 AM, Ari Simmons <ari.ucb.fire at gmail.com> wrote:
> Do you mean
>
> gdal_translate -te -13813007 5569641 -13809113 5572598
> srtm_merged_3857.vrt my_subwindow.tif --config  GDAL_CACHEMAX 800
>
> ?

Oops, I made a bad typo by omitting -projwin:

gdal_translate -projwin -13813007 5569641 -13809113 5572598
srtm_merged_3857.vrt my_subwindow.tif --config  GDAL_CACHEMAX 800

Best regards, Eli

>
> On Thu, Jun 11, 2015 at 3:08 PM, Eli Adam <eadam at co.lincoln.or.us> wrote:
>>
>> On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons <ari.ucb.fire at gmail.com>
>> wrote:
>> > One notably huge difference is that there is a huge jump in pixel size
>> > (from
>> > 0.000833333333323 to 205.686440189378940)...
>> >
>> > ah, duh. Unit change.
>> >
>> > On Thu, Jun 11, 2015 at 2:26 PM, Ari Simmons <ari.ucb.fire at gmail.com>
>> > wrote:
>> >>
>> >> I am experimenting with using 'gdalwarp' on a .vrt (first time), but
>> >> I'm
>> >> not sure what I'm doing wrong. I've been running this:
>> >>
>> >> >> gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear -of VRT
>> >> >> merged.vrt srtm_merged_3857.vrt
>> >>
>> >> and it processes fast (far far *too fast* for this global file) and
>> >> returns
>>
>> That is the right speed (~0 seconds) and disk space (~0MB).  That is
>> because it doesn't actually do anything except write down notes of
>> what it would have done (and will do in the future if you ask for it).
>> I like testing large VRT files by outputting a subwindow tif like
>> this:
>>
>> gdal_translate -13813007 5569641 -13809113 5572598
>> srtm_merged_3857.vrt my_subwindow.tif --config  GDAL_CACHEMAX 800
>>
>> If things look good on the subwindow, then it is time for all the I/O
>> waiting, processor cycles, and storage space.  Evaluating a few
>> places, especially where tiles come together can find things early
>> without all the wait.
>>
>> HTH, Eli
>>
>> >>
>> >> >> Creating output file that is 194835P X 479814L.
>> >> >> Processing input file merged.vrt
>> >> >> Using internal nodata values (eg. 0) for image merged.vrt
>> >>
>> >> The return .vrt file definitely doesn't appear right...a quick look at
>> >> the
>> >> returned file:
>> >>
>> >> input:
>> >>
>> >> Size is 432000, 208800
>> >> Coordinate System is:
>> >> GEOGCS["WGS 84",
>> >>     DATUM["WGS_1984",
>> >>         SPHEROID["WGS 84",6378137,298.257223563,
>> >>             AUTHORITY["EPSG","7030"]],
>> >>         AUTHORITY["EPSG","6326"]],
>> >>     PRIMEM["Greenwich",0],
>> >>     UNIT["degree",0.0174532925199433],
>> >>     AUTHORITY["EPSG","4326"]]
>> >> Origin = (-180.000416666666670,84.000416666666666)
>> >> Pixel Size = (0.000833333333323,-0.000833333333323)
>> >> Corner Coordinates:
>> >> Upper Left  (-180.0004167,  84.0004167) (180d 0' 1.50"W, 84d 0' 1.50"N)
>> >> Lower Left  (-180.0004167, -89.9995833) (180d 0' 1.50"W, 89d59'58.50"S)
>> >> Upper Right ( 179.9995833,  84.0004167) (179d59'58.50"E, 84d 0' 1.50"N)
>> >> Lower Right ( 179.9995833, -89.9995833) (179d59'58.50"E, 89d59'58.50"S)
>> >> Center      (  -0.0004167,  -2.9995833) (  0d 0' 1.50"W,  2d59'58.50"S)
>> >> Band 1 Block=128x128 Type=Int16, ColorInterp=Gray
>> >>   NoData Value=0
>> >>   Overviews: 216000x104400, 108000x52200, 54000x26100, 27000x13050,
>> >> 13500x6525,
>> >> 6750x3263, 3375x1632, 1688x816, 844x408, 422x204
>> >>
>> >> and output file:
>> >>
>> >>  Size is 193861, 479814
>> >> Coordinate System is:
>> >> PROJCS["WGS 84 / Pseudo-Mercator",
>> >> GEOGCS["WGS 84",
>> >> DATUM["WGS_1984",
>> >> SPHEROID["WGS 84",6378137,298.257223563,
>> >> AUTHORITY["EPSG","7030"]],
>> >> AUTHORITY["EPSG","6326"]],
>> >> PRIMEM["Greenwich",0,
>> >> AUTHORITY["EPSG","8901"]],
>> >> UNIT["degree",0.0174532925199433,
>> >> AUTHORITY["EPSG","9122"]],
>> >> AUTHORITY["EPSG","4326"]],
>> >> PROJECTION["Mercator_1SP"],
>> >> PARAMETER["central_meridian",0],
>> >> PARAMETER["scale_factor",1],
>> >> PARAMETER["false_easting",0],
>> >> PARAMETER["false_northing",0],
>> >> UNIT["metre",1,
>> >> AUTHORITY["EPSG","9001"]],
>> >> AXIS["X",EAST],
>> >> AXIS["Y",NORTH],
>> >> EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
>> >> +lon_0=0.0
>> >> +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs"],
>> >> AUTHORITY["EPSG","3857"]]
>> >> Origin = (-19837179.642485119000000,18807657.848855246000000)
>> >> Pixel Size = (205.686440189378940,-205.686440189378940)
>> >> Corner Coordinates:
>> >> Upper Left  (-19837179.642,18807657.849) (178d12' 1.50"W, 84d 0'
>> >> 1.50"N)
>> >> Lower Left  (-19837179.642,-79883575.764) (178d12' 1.50"W,
>> >> 89d59'58.50"S)
>> >> Upper Right (20037399.339,18807657.849) (179d59'56.47"E, 84d 0' 1.50"N)
>> >> Lower Right (20037399.339,-79883575.764) (179d59'56.47"E,
>> >> 89d59'58.50"S)
>> >> Center      (  100109.848,-30537958.958) (  0d53'57.49"E, 89d
>> >> 2'43.78"S)
>> >> Band 1 Block=512x128 Type=Int16, ColorInterp=Gray
>> >> Overviews: 96931x239907, 48466x119954, 24233x59977, 12117x29989,
>> >> 6059x14995,
>> >> 3030x7498, 1515x3749, 758x1875, 379x938, 191x471
>> >>
>> >> One notably huge difference is that there is a huge jump in pixel size
>> >> (from 0.000833333333323 to 205.686440189378940)...
>> >
>> >
>> >
>> > _______________________________________________
>> > gdal-dev mailing list
>> > gdal-dev at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>