ARC/INFO to GRASS conversion

[Rod Paterson]

Ralf,
     I have seen this problem also and I used digit to remove the offending lin
es.
     These lines appear to be bridge lines connecting island polygons which don
't
     seem to be removed by ArcInfo clean operations.
     Grass is very fussy about such things and considers polygons using a commo
n
     line to be invalid.
     Ideally it would be nice to fix this problem at the ArcInfo end so that
     the bridge lines are removed. I presume they are there in the ungenerate
     format for the benefit of some other programs which otherwise have difficu
lty
     recognising islands.

     Does anyone out there have an ArcInfo solution for this problem?

     I am enclosing below a copy of some communication I had with Olga Waupotit
sch
     regarding this problem.

     Hope this helps. If you find an easy solution I would love to hear about i
t.

start inclusion 1 - my message to Olga
-------------------------------------------------------------------------------
----
Olga,
     Thank very much for your quick reply.

     I have tried relabelling but to no avail.I have put the labels
     v.support claims not to have matched to areas in a sites file
     to see where they lie.
     They look to be inside the areas which have open area lines and outside
     any islands.
     However I have noticed that v.support does not build the topology
     correctly if a redundant line is present linking an island to a
     surrounding area.
    ie. ----------
       |          |
       |          |
       |          |
       |   ---    |
       |  |   |   |
 ----->|--| x1|   |
       |  |   |   |
       |   ---    |
       |     x2   |
       |          |
        ----------
       In this case the polygon with label x2 is left with open area
       lines.ArcInfo must be able to tolerate this but the GRASS logic
       can not.Is this a difficult problem to solve or should I try
       to find these little redundant vectors ?
-------------------------------------------------------------------------------
--
end inclusion1

start inclusion2 Olga's reply
-------------------------------------------------------------------------------
--
The behaver you described I noticed before. I know exactly why it happens
I know exactly how to fix it in v.support.
but Dave Gerdes doesn't want me to fix it. because
he says such polygons are not correct and do not fit the definition of polygon.
The reason it happens is that v.build goes through area edges in clockwise
order always taking the right most edge is the vertex has degree more than 1
when it can't complete the area (i.e. it can't come back to the vertex it start
ed from, it quits.
Instead I beleive it should come baanched out to the right and try with the nex
t edge to the left. This can easily bee implemented as recursion, i.e. at each 
vertex we arrive , the function
calls itself for every adjacent edge except the one we came from starting
from the edge thay makes the right most turn.

example
            1
        o________o
        |        |
    6|        |
        | 5      |
 o___o    |2
        |        |
    4|        |
        |        |
        o________o
            3

v.build goes through edges #1, #2, #3, #4, then it tries to
make the right most turn, and so goes to edge #5, where it comes to dead end
and area fails.
instead it should come back and try edge 6, then it would complete the area.
This is exactly what happens in your case. If you delete the edge connecting bo
undary of
larger area with the island, everything will work fine.
Roight now your large area is not legal by definition, because it
intersects itself. My method would complete your area.
Actually, don't delete this edge, convert it to line edge using v.digit
then it will also work
Olga
-------------------------------------------------------------------------------
end inclusion 2

> Subject: ARC/INFO to GRASS conversion
> Content-Length: 1804
>
> Dear GRASS-users
>
> I will import ARC/INFO vector-files to GRASS. These files contain either area
> coverage data or contour lines and have far more than 2000 lines/polygons eac
h.
>
> At this point we try to import a relatively large map containing polygon
> features (like a soil map for example). The data were exported using the
> UNGENERATE and DISPLAY functions of ARC/INFO resulting in a lines file (.ply)
,
> a label point-file (.pnt) and a label-text file (.txt), according to the
> v.in.arc man pages of the users reference manual.
>
> Importing the file using v.in.arc worked without any problems. But when
> running v.support, only about half of the polygons were not recognized as
> areas and could not be recognized. I got an error message like
>
> PNT_TO_AREA failed: (3500166.000000 6056598.500000) (Category 4)
>
> Using v.digit, I could see that the problematic polygons seem to be
> characterized by a connection to another area both at the start and the end
> point of the polygon, that means, the polygons are not closed by itself.
>
> I would like to ask if there is a chance to import these ARC/INFO files, eith
er
> by choosing another export/import format like DXF or by changing export optio
ns
> of ARC/INFO resulting in completely closed polygons. The important point to m
e
> is to have a completely labelled vector area map after importing, because thi
s
> map has to transformed into raster format.
>
> Thanks in advance
> Ralf Kunkel
>
>                                                                              
  Phone: +49-2461-3262
> Program Group Systems Analysis and                    Fax:      +49-2461-2540
> Technological Development (STE)                          E-mail: r.kunkel at kfa
-juelich.de
> Research Center (KFA) Juelich
> D-52425 Juelich, Germany
>
        Rod Paterson
        Aberfoyle Resources Ltd
        Level 31
        525 Collins Street
        Melbourne Vic., 3000

        Phone: 61-3-2706666
        Fax:   61-3-2706699
        Email: rgp at aberfoyle.oz.au