Format translator development

[Thomas Adams]

David,

I believe SDTS is the answer. Try going to:

http://gis.itc.nrcs.usda.gov/archive/GRASS-import_dir/msg00011.html
http://www.ngdc.noaa.gov/seg/tools/sdts/grass.html

Regards,
Tom



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

-- 
Tom Adams                              adams at ohrfc.noaa.gov
                                       http://www.nws.noaa.gov/er/iln
Development & Operations Hydrologist   NWS-Ohio River Forecast Center
1901 S. State Route 134                Wilmington, OH 45177
(937) 383-0528 (VOICE)                 (937) 383-0033 (FAX)