Having looked at the description of the PostgreSQL interface to GRASS, I
am convinced that it would let me do what I'm trying to do. The only
question now is how to input the data I have into a postgres database,
whether from what was loaded in the standard way or from the e00.
Is there a standard utility which will convert grass's dig format data
into postgres format? If not, is there an already written utility for
input of e00 files to postgres? Barring either of those, I would need
to do it myself, which would require some knowlege of the schema that
grass expects to find when accessing the data.
If I were to produce the database myself, my planned schema would be one
table for each of: polygons, lines and nodes with views for each
coverage (Arc/INFO terminology here). In addition, I would have tables
for displays and projects which would not hold any fundamental data but
would facilitate redrawing the maps with each change.
The contents with field names and types of the three data tables would
be as follows,:
Polygons
Coverage:varchar, PolyID:char, PolyN:char, Bounds:box,
numArcs:int, arcIDs:char, reversed:bollean, nodeIDs:char,
polyIDs:char, area:float, perimeter:float, centroid:point
Lines
Coverage:varchar, LineID:char, LineN:char, fNode:char,
tNode:char, lPoly:char, rPoly:char, arcPath:path, length:float
Nodes
Coverage:varchar, NodeID:char, NodeN:char, Pos:point
In addition, various coverages would have their own base tables which
would contain data specific to that coverage. For instance, roads would
contain fields for function class, rt. number, etc. A side benefit of
this approach is that it would permit various analyses, such as
aggregations, to be performed by the database that would otherwise have
to be done manually.
These fields are based on what I read about the format of e00 files and
would therefore contain everything that is available to describe each
coverage. The question is what structure should the view take so that
when any of the grass modules look query them, which the modules think
are ordinary tables, they would find what they expect. I would accept
directions to check a set of functions and files in the source.
On a separate note, I was looking through the e00 files and noticed that
there were several instances where multiple features (lines, polygons)
had the same feature-ID. Would importing with the -i flag under such
circumstances explain the problems I've been having with duplicates?
Scott Smith