We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I am getting this error with some of my files:
ERROR 1: Maximum number of characters allowed reached.
using this function call:
"/Library/Frameworks/GDAL.framework/Versions/2.2/Programs/gdalwarp" -multi -overwrite -te 243981.149256099 4169328.58664336 316574.679779182 4239670.70617033 -te_srs "+proj=utm +zone=11 +datum=WGS84 +units=m +no_defs" -tr 1000 1000 -t_srs "+proj=utm +zone=11 +datum=WGS84 +units=m +no_defs" -r "near" -dstnodata "-99" -of "GTiff" "data/snodas/swe/conus/us_ssmv11034tS__T0001TTNATS2017120105HP001.Hdr" "data/snodas/swe/tuo/swe_tuo_20171201.tif"
you can download the files here: ftp://sidads.colorado.edu/DATASETS/NOAA/G02158/masked/2017/07_Jul/SNODAS_20171201.tar
Is there a character limit for lines in the header file? Most of the other dates work fine, 20171101 is another example that doesn't work
macOS 10.12.6 GDAL 2.2.4, released 2018/03/19, from kyngchaos.com
The text was updated successfully, but these errors were encountered:
I added a hack that mostly solves my issue but it'd be nice if that didn't have to happen!
I was actually using gdalUtils in R to use gdalwarp, but I confirmed the issue on the commandline.
in R, before using gdalUtils I added this chunk, where f is the filename of the .Hdr
f
library(tidyverse) rl <- read_lines(f) rl2 <- str_trim(rl) rl3 <- map_chr(rl2,function(x){ # print(x) if(grepl('BARD',x)){ x <- 'BARD codes too long' } return(x) }) write_lines(x=rl3,path=f)
Sorry, something went wrong.
8688d60
SNODAS: accept header lines up to 1024 characters. Fixes #506
bafa089
@rouault for my own benefit, is 1024 a magic number or just a reasonable number to increase to from 256?
yes arbitrary number... One must put some limitation. I didn't research if SNODAS had some documentated limitation.
documenting reported gdal bug OSGeo/gdal#506
8b1b9ec
rouault
No branches or pull requests
I am getting this error with some of my files:
using this function call:
"/Library/Frameworks/GDAL.framework/Versions/2.2/Programs/gdalwarp" -multi -overwrite -te 243981.149256099 4169328.58664336 316574.679779182 4239670.70617033 -te_srs "+proj=utm +zone=11 +datum=WGS84 +units=m +no_defs" -tr 1000 1000 -t_srs "+proj=utm +zone=11 +datum=WGS84 +units=m +no_defs" -r "near" -dstnodata "-99" -of "GTiff" "data/snodas/swe/conus/us_ssmv11034tS__T0001TTNATS2017120105HP001.Hdr" "data/snodas/swe/tuo/swe_tuo_20171201.tif"
you can download the files here:
ftp://sidads.colorado.edu/DATASETS/NOAA/G02158/masked/2017/07_Jul/SNODAS_20171201.tar
Is there a character limit for lines in the header file?
Most of the other dates work fine, 20171101 is another example that doesn't work
macOS 10.12.6
GDAL 2.2.4, released 2018/03/19, from kyngchaos.com
The text was updated successfully, but these errors were encountered: