Format translator development

[David D Gray]

David Irving wrote:
> 
> Rich Shepard wrote:
> 
> > On Sat, 13 May 2000, David D Gray wrote:
> >
> > > The problem with these others is that they mostly import lines in the
> > > originating application's native format. Often that means closed loops. Is
> > > that the case with MapInfo? If it was, I think that some kind of engine
> > > for translating the MapInfo format to GRASS arc-node would be required. Is
> > > that what you meant?
> >
> > David,
> >
> >   I don't know. The MapInfo export format for points and lines is
> > straight-forward: for points, the position and the symbol descriptor; for
> > lines, the number of segments in the line then the position for each node.
> > The MapInfo region (everyone else's polygon) is a closed line with one or
> > multiple segments. What's interesting, of course, is that MapInfo does not
> > build or maintain topology. For soil polygons, for example, each soil type
> > is its own polygon and the common lines aren't, there's one line for each
> > polygon.
> >
> > > Because there are so many formats that require these changes on import, I
> > > am coming round to the conclusion that there should be some kind of
> > > translation engine in the main GRASS lib (to economise on code space and
> > > streamline module development), perhaps like the methods incorporated in
> > > the shapefile import - but more modular, efficient and cleaner of course
> > > -...
> >
> >   Now that I think about it, I agree. I need to understand the arc-node data
> > structure's relationship to a closed polygon before I can write the
> > MapInfo-to-GRASS translator. Of course, if you or anyone else with more
> > experience in GRASS formats is willing to undertake this task, I'll be happy
> > to relinguish it. But, I will certainly answer any questions regarding the
> > MapInfo format.
> >
> > Rich
> >
> > Dr. Richard B. Shepard, President
> >
> >                        Applied Ecosystem Services, Inc. (TM)
> >               Making environmentally-responsible mining happen. (SM)
> >                        --------------------------------
> >             2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
> >  + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard at appl-ecosys.com
> 
> Rich - and others -
> 
> imo, what is _really_ required is a MapInfo-to-<something> tarnslator together
> with a <something>-to-GRASS translator, that is, use some common data format as
> an interchange mechanism between any two spatial information systems. I believe
> that there is a Standard for spatial data interchange, but have been unable to
> get hold of a copy to assess whether it is actually useful. Any other approach
> effectively means writing 2*N**2 data translation programs, where N is the
> number of spatial data formats (large and growing all the time)
> 
> Regards,
> David

I agree entirely with the idea of an intermediary format which
is designed for things to be changed into and out of, but perhaps
each application could implement this in memory, so that it could
have direct access to each filetype. Using a transfer format is OK
as long as people use it, but the most sophisticated data transfer
mechanism is not much use if what you have just happens to be a
shapefile or Arc/Info coverage.

I think by `translator' we mean 3 distinct things - at least in terms of
the tasks you will have to perform in changeing vector map data from
format A to format B. Something is needed to translate the source data
into a standard format which can store all the topological data that's
needed, then something to extract relevant data from this and write
it to the grass database. Finally you need to be able to link
the correct attributes with the topological structures in the target
format. As both the line data and methods of storing attributes may
differ widely between source and target, this can be non-trivial,
and is in any case peculiar to each source and target.

I believe the linework import can be simplified by creating an
intermediary storage database as you suggest. Shapefile data is
imported by way of a graph-like structure, which stores vertices and
links in such a way that no vertex or link is ever duplicated. It 
also makes it easy to extract area edges or lines and write them
directly.
A similar set of functions could be included in the GRASS library
with standard function calls that would make it possible to
develop an import filter for any documented format with a few standard
function calls. This is something I am planning on working on with
a view to applying it to dxf and ungen import, as well as shapefile.
Export filters would use the same machinery, but in reverse.

David