r-barnes
nodata region affecting georegistration
I'm looking at this raster GDB: http://frap.fire.ca.gov/data/frapgisdata-sw-fveg_download
In correct alignment it looks like this
with
PROJCS["NAD_1983_California_Teale_Albers",
GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
SPHEROID["GRS 1980",6378137,298.2572221010042,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6269"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4269"]],
PROJECTION["Albers_Conic_Equal_Area"],
PARAMETER["standard_parallel_1",34],
PARAMETER["standard_parallel_2",40.5],
PARAMETER["latitude_of_center",0],
PARAMETER["longitude_of_center",-120],
PARAMETER["false_easting",0],
PARAMETER["false_northing",-4000000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (-636269.999999998137355,530310.000000000000000)
Pixel Size = (30.000000000000000,-30.000000000000000)
Size is 39623, 38094
Upper Left ( -636270.000, 530310.000) (127d44' 2.84"W, 42d33'31.44"N)
Lower Left ( -636270.000, -612510.000) (126d44'50.64"W, 32d17'39.60"N)
Upper Right ( 552420.000, 530310.000) (113d16'53.19"W, 42d36'58.97"N)
Lower Right ( 552420.000, -612510.000) (114d 8'21.71"W, 32d20'40.82"N)
Center ( -41925.000, -41100.000) (120d28'32.91"W, 37d38'44.53"N)
The box on the plot shows the extent of the raster itself, so there's a region 9031 pixels wide before any valid data is present, at easting = -365340 (which is -636270 + 9031 * 30).
When I convert with ArcRasterRescue I get the following, and the western edge of valid data is right at the left extent, at -636270 - so the region of missing data has not been accounted for. There's a smaller gap at the top causing a shift north as well.
Driver: GTiff/GeoTIFF
Files: fveg15.tif
Size is 30592, 35456
Coordinate System is:
PROJCS["NAD_1983_California_Teale_Albers",
GEOGCS["GCS_North_American_1983",
DATUM["D_North_American_1983",
SPHEROID["GRS_1980",6378137.0,298.257222101]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Albers"],
PARAMETER["False_Easting",0.0],
PARAMETER["False_Northing",-4000000.0],
PARAMETER["Central_Meridian",-120.0],
PARAMETER["Standard_Parallel_1",34.0],
PARAMETER["Standard_Parallel_2",40.5],
PARAMETER["Latitude_Of_Origin",0.0],
UNIT["Meter",1.0]]
Origin = (-636254.999999998137355,530295.000000000000000)
Pixel Size = (30.000000000000000,-30.000000000000000)
Metadata:
AREA_OR_POINT=Area
PROCESSING_HISTORY=2018-05-08 03:48:17 UTC | Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=b60ea39fcf11666d, compiled=2018-05-08 03:43:04 UTC) | ./ArcRasterRescue/arc_raster.exe fveg15_1.gdb/ 0 fveg15.tif
TIFFTAG_DATETIME=2018-05-08 03:48:17 UTC
TIFFTAG_SOFTWARE=Arc Raster Rescue (url=github.com/r-barnes/ArcRasterRescue, hash=b60ea39fcf11666d, compiled=2018-05-08 03:43:04 UTC)
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -636255.000, 530295.000)
Lower Left ( -636255.000, -533385.000)
Upper Right ( 281505.000, 530295.000)
Lower Right ( 281505.000, -533385.000)
Center ( -177375.000, -1545.000)
Band 1 Block=30592x1 Type=Int32, ColorInterp=Gray
NoData Value=-9999
I've seen this problem with another example, but I didn't understand it at the time and I can't share that file. I hope my explanation is clear.
This second plot shows the output of ArcRasterRescue plotted in the same context as the plot above, and with the states overlaid. The frame and map context is correct, but the raster is shifted to the west, and north.
Thanks!
(My apologies if you happened to see the first draft, I had an unrelated rendering issue disrupting both plots, and had to change them in an edit. All is accurate as described now).
Also, the reported geotransform seems to be "off by half", with the 15m offsets from left and top - but my benchmark is a GeoTIFF from ArcGIS created by someone else, so I'm less certain about the details between the source GDB and the file I have.
Thanks for uploading a dataset demonstrating the problem! Is it possible for you to export a GeoTIFF from Arc containing the expected data? (If you don't have Arc, we can find a way to work around the problem.)
You want me to share the Arc-export GeoTIFF? I do have access but I had a friend do the conversion so I could report here.
Yes, please. Reverse engineering a file type is made much easier by having both inputs and outputs.
-R
On Wed, 9 May 2018, 18:08 Michael Sumner, [email protected] wrote:
You want me to share the Arc-export GeoTIFF? I do have access but I had a friend do the conversion so I could report here.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/r-barnes/ArcRasterRescue/issues/2#issuecomment-387890529, or mute the thread https://github.com/notifications/unsubscribe-auth/AC-T1Fobus6XYZiV6UaPxf9dXpLlI4zEks5tw2jrgaJpZM4T4ELN .
Ok cool I put it up here: https://github.com/mdsumner/arc/tree/master/arc-tif
That .zip (184Mb) contains the .tif files from converting the GDB to GeoTIFF with ArcGIS. The readme contains more details.
Got it! I'll see what I can do, though I'm afraid this project isn't super high on my priority list just now.
@mdsumner : I've just brought in a new projection PR that might solve this issue. Is it possible for you to test again?
No, sorry I don't have that file and it seems it can be accessed anymore. If I can find a similar situation I'll check
Just came back to say that on this data source it now works correctly. :)
File is here, zipped (I couldn't figure out a bare url for it):
https://calfire.app.box.com/s/f3ajflnmj7cd7isjimf52hdraxxtjyoy/file/926246506822
with ArcRasterRescue dc5d45206982c7f76dbd121359f0b442a9092a30
And with GDAL directly from the gdb zip:
FYI @rouault
FYI @rouault
I assume you mean that things are OK with the GDAL OpenFileGDB driver?
yes, GDAL gets it right too (I was concerned to revisit this one because I couldn't find an example anywhere else with the same situation )