Trying to import an ESRI FileGDB with 10m DEM for Oregon. I don't understand
what I've done incorrectly and would appreciate learning from the grass
command error message.
Input file is OR_DEM_10M.gdb
$ ogrinfo -al -so
Geometry: Multi Polygon
Feature Count: 1
Extent: (-106508955.000000, -85400955.000000) - (109133655.000000, 130241655.000000)
Layer SRS WKT:
PROJCS["NAD_1983_Oregon_Statewide_Lambert_Feet_Intl",
GEOGCS["GCS_North_American_1983",
DATUM["North_American_Datum_1983",
SPHEROID["GRS_1980",6378137.0,298.257222101]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["False_Easting",1312335.958005249],
PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",-120.5],
PARAMETER["Standard_Parallel_1",43.0],
PARAMETER["Standard_Parallel_2",45.5],
PARAMETER["Latitude_Of_Origin",41.75],
UNIT["Foot",0.3048]]
FID Column = OID
Geometry Column = FOOTPRINT
RASTER: Binary (0.0)
FOOTPRINT_Length: Real (0.0)
FOOTPRINT_Area: Real (0.0)
Run error:
v.in.ogr input=/data/grassdata/OR_DEM_10M.gdb output=dem10m Check if OGR layer <DEM_10meter_Oregon> contains polygons...
Creating attribute table for layer <DEM_10meter_Oregon>...
WARNING: Column type (Ogr_ftype: 8) not supported (Ogr_fieldname: RASTER)
Importing 1 features (OGR layer <DEM_10meter_Oregon>)...
DBMI-SQLite driver error:
Error in sqlite3_prepare():
table dem10m has 4 columns but 3 values were supplied
DBMI-SQLite driver error:
Error in sqlite3_prepare():
table dem10m has 4 columns but 3 values were supplied
ERROR: Cannot insert new row for input layer <DEM_10meter_Oregon>: insert into dem10m values ( 1, 862570440, 4.65017352476121e+16 )
(Wed Sep 11 08:48:30 2019) Command finished (0 sec)
Is the .gdb download corrupted?
Regards,
Rich
On 11/09/19 17:53, Rich Shepard wrote:
Trying to import an ESRI FileGDB with 10m DEM for Oregon. I don't understand
what I've done incorrectly and would appreciate learning from the grass
command error message.
Input file is OR_DEM_10M.gdb
$ ogrinfo -al -so
Geometry: Multi Polygon
Feature Count: 1
Extent: (-106508955.000000, -85400955.000000) - (109133655.000000, 130241655.000000)
Layer SRS WKT:
PROJCS["NAD_1983_Oregon_Statewide_Lambert_Feet_Intl",
GEOGCS["GCS_North_American_1983",
DATUM["North_American_Datum_1983",
SPHEROID["GRS_1980",6378137.0,298.257222101]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["False_Easting",1312335.958005249],
PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",-120.5],
PARAMETER["Standard_Parallel_1",43.0],
PARAMETER["Standard_Parallel_2",45.5],
PARAMETER["Latitude_Of_Origin",41.75],
UNIT["Foot",0.3048]]
FID Column = OID
Geometry Column = FOOTPRINT
RASTER: Binary (0.0)
FOOTPRINT_Length: Real (0.0)
FOOTPRINT_Area: Real (0.0)
Run error:
v.in.ogr input=/data/grassdata/OR_DEM_10M.gdb output=dem10m
Check if OGR layer <DEM_10meter_Oregon> contains polygons...
Creating attribute table for layer <DEM_10meter_Oregon>...
WARNING: Column type (Ogr_ftype: 8) not supported (Ogr_fieldname: RASTER)
Could it be that your FileGDB contains raster data ?
AFAIK, this not support by GDAL at the moment, and if it was, you would have to use r.in.gdal, not v.in.ogr.
Moritz
On Thu, 12 Sep 2019, Moritz Lennert wrote:
Could it be that your FileGDB contains raster data ?
Moritz,
Yes, it should be raster data.
AFAIK, this not support by GDAL at the moment, and if it was, you would
have to use r.in.gdal, not v.in.ogr.
That is the problem: FileGDB is not supported by GDAL and is not in the
r.in.gdal's list of suported formats.
Is there a tool to convert .gdb to something that r.in.gdal will accept? I'm
not going to have the source change the format as they use only ESRI's
ArcGIS and are likely limited to what export options that has.
Thanks,
Rich
On 12/09/19 17:10, Rich Shepard wrote:
On Thu, 12 Sep 2019, Moritz Lennert wrote:
Could it be that your FileGDB contains raster data ?
Moritz,
Yes, it should be raster data.
AFAIK, this not support by GDAL at the moment, and if it was, you would
have to use r.in.gdal, not v.in.ogr.
That is the problem: FileGDB is not supported by GDAL and is not in the
r.in.gdal's list of suported formats.
Is there a tool to convert .gdb to something that r.in.gdal will accept? I'm
not going to have the source change the format as they use only ESRI's
ArcGIS and are likely limited to what export options that has.
I've tried with this: https://github.com/r-barnes/ArcRasterRescue, but without success so far.
You can also try Even's script referenced at the link above: https://github.com/rouault/dump_gdbtable
So, sorry, this is proprietary format hell with only reverse engineering as a solution...
Moritz
On Thu, 12 Sep 2019, Moritz Lennert wrote:
I've tried with this: https://github.com/r-barnes/ArcRasterRescue, but without success so far.
Moritz,
This reminds me of the early 1990s when it was easy to import .e00 files
into grass and other formats needed a lot of research and trial-and-error to
write conversion filters.
You can also try Even's script referenced at the link above: https://github.com/rouault/dump_gdbtable
I downloaded the directory. The python scripts need to run on the files, not
the entire directory. Running dump_gdbindexes.py on a0000001c.gdbindexes failed:
./dump_gdbindexes.py a0000001c.gdbindexes nindexes = 59086867
idx_name = øvn¦шøvÿuùǀ|huùǀ|hÿ
Traceback (most recent call last):
File "../dump_gdbindexes.py", line 61, in <module>
magic1 = read_int16(f)
File "../dump_gdbindexes.py", line 44, in read_int16
return struct.unpack('h', v)[0]
struct.error: unpack requires a string argument of length 2
I'll contact the author with this informatino.
So, sorry, this is proprietary format hell with only reverse engineering as a solution...
Nothing justifies an apology. Frank Warnedam (sp?) did extraordinary work in
writing successful geodata format conversion filters. Why an agency would
use the FileGDB format for a raster DEM rather than the ENVI format (and why
ESRI would allow this) is puzzling.
I sent an e-mail message to someone who might help having the DEM exported
to ENVI format.
Best regards,
Rich
On Thu, 12 Sep 2019, Moritz Lennert wrote:
So, sorry, this is proprietary format hell with only reverse engineering
as a solution...
Moritz,
Patient searching on the web found the USGS 10m data for the US. If anyone
else wants 10m DEM data in a GDAL acceptable format the URL is:
<https://prd-tnm.s3.amazonaws.com/index.html?prefix=StagedProducts/Elevation/13/ArcGrid/>
Regards,
Rich