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

[Ari Simmons]

Do you mean

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

?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150612/3f60d877/attachment.html>