I've noticed that using avcimport (which converts .e00 files to binary coverages) greatly speeds up import of .e00 files when you use ogr2ogr. So v.in.ogr probably uses avcimport for this reason.
Bob Moskovitz
Research Analyst I
Seismic Hazard Evaluation Project
California Geological Survey http://gmw.consrv.ca.gov/shmp
CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed. This message contains information from the State of California, California Geological Survey, which may be privileged, confidential and exempt from disclosure under applicable law, including the Electronic Communications Privacy Act. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
-----Original Message-----
From: grass-user-bounces@lists.osgeo.org
[mailto:grass-user-bounces@lists.osgeo.org]On Behalf Of Rich Shepard
Sent: Tuesday, November 17, 2009 4:51 PM
To: grass-users@lists.osgeo.org
Subject: [GRASS-user] v.in.e00 vs. v.in.ogr
Looking for the v.in.ogr man page I was reminded that
there is a v.in.e00.
Should I use the latter rather than the former?
Tried running v.in.e00. After entering the .e00 file name
and specifying
'area' for the type I and saw this fatal error message:
ERROR: 'avcimport' program not found. Install it first.
The source file is an ASCII .e00, not compressed and not needing
comversion from ARC/Info binary to exchange format.
(in theory OGR should meanwhile support E00 but I am not 100% sure
about polygons being correctly done - there was/is a ticket open).
The source file is an ASCII .e00, not compressed and not needing
comversion from ARC/Info binary to exchange format.
What have I missed here?
If you are sure you can just hack the v.in.e00 shell script and remove
the test. Or simply execute manually what the script does (it simply calls
v.in.ogr with some magic parameters).
Looking for the v.in.ogr man page I was reminded that there is a v.in.e00.
Should I use the latter rather than the former?
OK. Looks like I want v.in.e00 because the v.in.ogr man page explicitly
cites .shp and MapInfo files.
As a suggestion, include the avce00 and e00compr libraries in the GRASS
distribution. Even though I can read the .e00 file, v.in.e00 reported that
it was compressed (!) but it's now happily munching on it.
I've noticed that using avcimport (which converts .e00 files to binary
coverages) greatly speeds up import of .e00 files when you use ogr2ogr. So v.in.ogr probably uses avcimport for this reason.
Bob,
I read the opposite: that avcimport converts binary files to .e00 for
purposes of import. It was v.in.e00 (not v.in.ogr) that asked for this and
e00compr to be installed before it would run. Interesting.