Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
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.0008323 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.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) 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.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N) Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S) 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.0008323 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
Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
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 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.0008323 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.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) 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.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N) Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S) 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.0008323 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
[gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
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 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.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) 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.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N)Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S)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.0008323 to 205.686440189378940)... ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 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 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.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) 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.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N)Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S)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.0008323 to 205.686440189378940)... ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
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.0008323 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.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) 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.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N) Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S) 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.0008323 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
