Issue rescuing PRISM data
Dave-Evans opened this issue · 10 comments
Hello,
Thank you so much for this program, I really appreciate your time and efforts.
I am trying to rescue PRISM data downloaded from Geospatial Data Gateway. I am able to run the executable successfully and produce a Tiff file, however, it seems that I am not able to read this file in either R or visualize in QGIS or visualize at GeoTIFF.io.
The source data are in decimal degrees with a cell resolution of 0.000000001 decimal degrees; could the cell resolution be too small and some weird rounding errors are happening?
The error from RGDAL:
> tst = readGDAL(fname = "precipann_r_mn.tif")
precipann_r_mn.tif has GDAL driver GTiff
and has 768 rows and 1024 columns
Error in validObject(.Object) :
invalid class “GridTopology” object: cellsize has incorrect dimension
And from the web console from GeoTIFF.io I get the following error messages:
ERROR initializing GeoTIFFLayer ReferenceError: proj4 is not defined
Uncaught (in promise) TypeError: this._bounds is undefined
QGIS doesn't show any image, but it does show a histogram that I would expect for annual precipitation in Minnesota:
Running gdalinfo
(results below) show a pixel resolution of 0, 0.
I can't seem to understand why I can't open it and yet there is a reasonable histogram of the data, the data is there.
Could this be an issue of just updating the metadata with something like exiftool?
Thanks for any and all help toward resolution or just clarification,
Dave
I have uploaded the zip file containing the gdb and I ran the following to run the program
./arc_raster.exe ./mn_prism_climate_1981_2010.gdb/ 0 ./precipann_r_mn.tif
The results of gdalinfo
are below:
gdalinfo precipann_r_mn.tif
Driver: GTiff/GeoTIFF
Files: precipann_r_mn.tif
Size is 1024, 768
Coordinate System is:
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]]
Origin = (-97.306988166333326,49.448243586642462)
Pixel Size = (0.000000000000000,-0.000000000000000)
Metadata:
AREA_OR_POINT=Area
PROCESSING_HISTORY=2020-10-24 21:03:28 UTC | Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=2f4140e9d209355e, compiled=2020-10-22 19:44:46 UTC) | ./arc_raster.exe ../mn_prism_climate_1981_2010.gdb/ 0 ../precipann_r_mn.tif And thanks again for this tool
TIFFTAG_DATETIME=2020-10-24 21:03:28 UTC
TIFFTAG_SOFTWARE=Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=2f4140e9d209355e, compiled=2020-10-22 19:44:46 UTC)
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -97.3069882, 49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
Lower Left ( -97.3069882, 49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
Upper Right ( -97.3069882, 49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
Lower Right ( -97.3069882, 49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
Center ( -97.3069882, 49.4482436) ( 97d18'25.16"W, 49d26'53.68"N)
@Dave-Evans : Do you know what the correct cell sizes should be?
Hi @r-barnes, @Dave-Evans said 0.000000001 decimal degrees, anyway I tried to open mn_prism_climate_1981_2010.gdb
with ArcMap and ArcCatalog 9.3.1 SP2 without success: Failed to connect to database
@Dave-Evans : I've pushed a new version which should do a better job of giving a geotransform that'll at least let you see a picture. I don't know if the values are correct, though.
@agiudiceandrea : I saw that value (0.000000001); however, it's incorrect and I'm not sure how he obtained it. When you open the decoded data (using the newly-updated code) it shows a map of Minnesota, but there are far too few pixels for 0.000000001 to be the resolution.
Wow, I was not expecting such a fast or effective response.
Thank you for your help, the new version looks good.
My apologies on the 0.000000001 figure for cell resolution, that was obtained through the metadata that came with the download, precip_meta.txt. Perhaps that is some strange default?
Looking at the product description here it says the cell size is "~800m". Using the new version of ArcRasterRescue and when I reproject this to UTM I get a cell size of 755 m.
This is fantastic! Thank you so much for your help,
I will mark this issue as closed.
Dave
@Dave-Evans : Yeah, I think that 0.000000001 is an error. The same precip_meta.txt
file also says "800m spacing" :-/
@Dave-Evans : Glad I could help. If it's convenient to your use-case, citations are always appreciated.
I will attribute whenever I can.
I'm curious, so it wasn't a rounding issue, it a more general issue with the geotransform?
Thanks,
Dave
@Dave-Evans : You can check the diff - the previous code assumed that various parameters were integers and rounded the result of a computation. In your case, that gave 0
as an output. The code now converts to floating-point and does not round.