RE: [GRASS5] GRASS -> SF

I think I still don't get how the boundaries work. In a well
formed polygon
layer, is the one closed boundary per polygon feature? If
there are centroids
how are they associated with their polygon?

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.

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. 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.)

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.

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.

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).

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.
(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.)

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".

I don't know if I am helping or just asking more questions, but I
remain

"Interested in Topology"
John

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

> 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

Could you explain what the vector model definitions of "face" and
"kernel" are?

I'm not sure I fully understand these.

thanks,
Hamish

On Friday 20 February 2004 03:08, Hamish wrote:

Could you explain what the vector model definitions of "face" and
"kernel" are?

face and kernel are 3D equivalents of boundary and centroid,
but there is no support for 3D topology (volumes) so you can forget about them.
The only current use of face is possibility to display vertical planes in nviz.

Radim

On Fri, Feb 20, 2004 at 09:15:35AM +0100, Radim Blazek wrote:

On Friday 20 February 2004 03:08, Hamish wrote:

> Could you explain what the vector model definitions of "face" and
> "kernel" are?

face and kernel are 3D equivalents of boundary and centroid,
but there is no support for 3D topology (volumes) so you can forget about them.
The only current use of face is possibility to display vertical planes in nviz.

Examples for illustration:

http://grass.itc.it/images/grass51_watertower.jpg
http://grass.itc.it/images/grass51_nviz.jpg

Markus