[GRASSLIST:2234] Re: Vector Import..

[Rich Shepard]

On Wed, 1 Aug 2001, Hans Koren wrote:

> But when I try to import the same vector data as a shape file (with
> default options) I get the following messages:

> Can anyone tell me what might be wrong?

Hans,

   You are trying to import a polygon file, and v.in.shape is still not
working flawlessly. Neither is v.in.mif. It will be a while yet before they
do work on all data.

  To help everyone understand why it has been a painful process so far for
David Gray (with minor help from me) to make this all work you need to know
the major difference between GRASS and ARC/Info on one side and
ArcView/MapInfo on the other side. In a word: topology.

  GRASS stores (and uses) information about the spatial relations of one
polygon with another. For example, if you have a file with soil polygons,
the boundary of two map units is a single line. GRASS "knows" what polygon
is on the left side of that line and what polygon is on the right side of
that line. Topologically elegant and correct.

  ArcView and MapInfo do not contain topological information in their files.
(I"ve never used ArcView but I have seven year's experience with MapInfo.)
MapInfo will store the soil map units as two separate graphic objects, so
the boundary between the two is doubled. This makes it much more difficult
to ask questions such as, "How many hydric (i.e., wetland) soil map units
have a stream along one boundary and upland soil map units adjacent to all
other boundaries?" With GRASS and ARC/Info that's an easy spatial query;
with MapInfo it's a PITA that requires programming with MapBasic.

  The general process of translating data from MapInfo/ArcView into GRASS
goes something like this: 1) disassemble the original data into component
parts; 2) record the details of each part (e.g., start node, end node,
previous segment, next segment); 3) translate into GRASS data structure; 4)
build topology (i.e., identify common boundaries, islands,
islands-within-islands, overlapping but distinct polygons, and so on).

  If anyone out here has experience, knowledge, a better practical
understanding of computational geometry than I do, and the time and
willingness to help, step right up. I'll risk writing for David, too, when I
note that we'd appreciate assistance in getting these two import filters
finished so everyone can benefit. My ego won't be hurt one bit by someone
else getting this done this week. :-)

  So, it's not an excuse, but a reason. As I've been slowly learning the
last layer of GIS expertise can be a difficult learning experience. The
first layer is knowing how to manipulate and use your GIS software system.
The second layer is knowing how to use the GIS to perform spatial analyses
and models that have technically sound results. The third layer is learning
how a GIS is built, understanding computational geometry, topology and the
algorithms used to implement them on a computer.

  And, not to diminish Michel Wurtz's efforts in any way, but ARC/Info
contains the topographic information in the AAT and PAT tables. That does
make it a few orders of magnitude easier for many of us -- including me. So,
m.in.e00 works (except when user error masquerades as a module bug), but
neither v.in.mif or v.in.shape can yet brag of such robustness.

HTH,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            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
                 Making environmentally-responsible mining happen.