[GRASS5] GRASS -> SF

[Radim Blazek]

On Wednesday 18 February 2004 20:39, John Gillette wrote:
> I must be that second person interested in topology that Radim was talking
> about. I am fascinated with how Grass does this and how it differs from say
> Arcinfo.

Yes, you are the first one. 

> I will quickly tell you what I know about topology in Grass 5.0 and
> then I hope Radim will tell us what I got wrong or has changed in 5.7.
>
> A vector layer in 5.0/5.3 contains lines that are of type dot, line or area
> edge. Area edges obviously are used to make up closed areas. So this allows
> you to separate the lines types.  You specify the type on input to Grass,
> Grass doesn't decide.  Areas are identified by a point file which pairs an
> x,y point location with a category number (dig_att file). This identifies
> the area.

These points are stored in 5.7 as centroids in the same binary 'coor' file with 
other primitives.

>  This is why (with respect to that conversation you had
> a while back concerning importing tiger areas) Radim had to use the PIP
> (point in polygon) layer.  I think you have to do that to identify the
> area.  (Radium was explaining that you COULD import tiger areas in
> 5.7, but it took about 6 or 8 steps with one of those steps the import
> of the PIP information.)

BUT, then I changed v.in.ogr so that it is possible to import TIGER in one step 
http://grass.itc.it/pipermail/grass5/2003-August/008422.html

> It is interesting to me that this is different from the Arcinfo approach
> where I think every thing is considered a line and an edge list is created
> with area left, area right information stored.  The tiger files are
> created this way.  Every thing is a area edge and an isolated line
> is identified by a test for (area left ?= area right).  If true,
> then the line is dead end line.  This approach is discussed in
> computational geometry books as the doubly connected edge list (DCEL).  The
> CGAL computational geometry library has routines for this, for example.

v.in.ogr/v.clean can identify dangles and change the type from boundary
to line. Distinction between line and boundary isn't important only
for dangles. Example:

+-----+-----+
|     .     |
|     .     |
+.....+.....+
|     .     |
|  x  .     |
+-----+-----+

----  road + boundary of one parcel => type boundary
....  road => type line
x     parcel centroid (identifies whole area)

Because lines are not used to build areas, we have only one area/centroid,
instead of 4 which would be necessary in TIGER. 

> Actually, Grass does store the area information internally, so perhaps the
> only difference between Arcinfo and Grass is that Grass allows for the line
> definition which allows for the 2 type to co-exist in the same file.
> The other difference is, of course, the use of the point in the area
> to identify it.

What is the difference?

> I am reminded of the famous Texas problem.  A Grass user couldn't get a
> Census map of the US to topology check. Texas wouldn't check because of a
> line connected to the edge extending into the interior.  Evidently the
> problem was there for some time but Arcinfo users didn't have a problem
> with it.  Grass won't allow it (an area edge connected at one end only,
> that is).

This is now resolved by v.in.ogr as mentioned above. It would be possible
to allow free ends in GRASS topology, but for me it does not make sense.
The boundary is something separating 2 different areas, to 'separate'
partialy one area would be something strange.

> Another interesting problem I have had is with SDTS DLG files.  They
> come with a bounding box.  It turns out to be part of the topology.
> If you remove the bounding box (to merge adjacent files for example)
> grass complains about area edges that are now open.

Bounding box in this case is regular boundary, so what you say is not surprising,
but either 
v.patch; v.clean tool=break,rmdupl
or 
v.in.ogr layer=map1,map2 
should import those maps correctly. v.in.ogr with more layers should 
even keep more attributes for area overlaps near the box boundary
(but in more tables).

> (Again, this is 5.0 information. 5.7 has utilities to fix this, I believe.)
> I believe that I read in the SDTS documentation that the information
> is stored with topology.  (Note: I don't know how grass decides here
> which lines are area edges and which are lines.  Perhaps this is specified
> in the spec and defined in the file.)

SDTS I don't know.

> One thing I am very curios about is the comment recently in a Radim email
> which had the following:
> /* number of elements for each type (point, line, boundary,
>              centroid, area, face, kernel) */
> I am very curious about the use of the different "types".

This is only information about number of types for each field.
Say that there are 2 features in the map, roads (type line, field 1)
and crossroads (type point, field 2), usig this info it is possible 
to get (in OGR for example) list of layers without reading all features:
roads_line
crossroads_point

> I don't know if I am helping or just asking more questions, but I
> remain
>
> "Interested in Topology"

You are the only candidate who can write the document about GRASS topology,
what do you think about that?

Radim