[GRASS-user] Explain v.in.ogr error

[Rich Shepard]

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