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@appl-ecosys.comRich - 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@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)