On Fri, Jun 12, 2015 at 11:25 AM, Ari Simmons <ari.ucb.f...@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 <ea...@co.lincoln.or.us> wrote: >> >> On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons <ari.ucb.f...@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.f...@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@lists.osgeo.org >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev