[GRASS5] m.in.e00 updated and some questions

GRASS GRASS developer
1

I have corrected a bug in m.in.e00 that prevented the line
attributes to be correctly placed, and produced lot of errors
when running v.support. This should now be correct.
I've modified release_branch and main trunk.

One problem remains : if there is a line with a dead end,
the area in which it is cannot be labelled (BAD in the
exemple bellow).

+----+-----+-------+
| | | |
| + + | + OK |
| BAD | |
+----+-----+-------+

Should I add a flag to indicate if you want a line or an area
result ? This can be done with the "type=..." parameter and can
lead to a better interpretation of e00 input :

line => no area attributes, only line attributes (actually not
        working : adding area attributes erases line attributes)
area => suppression of lines with the same left and right area
        (so v.support will work better), only area attributes

PS: don't expect a reply before the end of the week, I will
not be at my office before friday.
   
--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

2

[GRASSLIST:3899] Re: m.in.e00: Attaching cat labels to lines.
I suspect that the initial design of Grass does not support well mixed
(areas and lines) vector files, because labels are common to areas and
lines.

I think that it is possible to mix areas and lines in one map
(and I used taht many times), also in progman 6.7.5 is:
--------------------
5. It is recommended that area features and linear features be placed in
separate layers. However if area features and linear features must appear in
one layer, common boundaries should be digitized only once. An area edge that
is also a line (e.g., a road which is also a eld boundary), should be
digitized as an area edge (i.e., arc type A ) to complete the area. The area
feature should be labeled as an area (i.e., feature type A in the dig_att
le). Additionally, the common boundary arc itself (i.e., the area edge which
is also a line) should be labeled as a line (i.e., feature type L in the
dig_att le) to identify it as a linear feature.
--------------------

If you mean dig_cats by labels, then you are right, if lines and areas
have the same category numbers, category labels may not differ.

On Tuesday 18 June 2002 09:55 am, Michel Wurtz wrote:

I have corrected a bug in m.in.e00 that prevented the line
attributes to be correctly placed, and produced lot of errors
when running v.support. This should now be correct.
I've modified release_branch and main trunk.

Thanks.

One problem remains : if there is a line with a dead end,
the area in which it is cannot be labelled (BAD in the
exemple bellow).

+----+-----+-------+

| + + | + OK |
| BAD | |

+----+-----+-------+

Should I add a flag to indicate if you want a line or an area
result ? This can be done with the "type=..." parameter and can
lead to a better interpretation of e00 input :

line => no area attributes, only line attributes (actually not
        working : adding area attributes erases line attributes)
area => suppression of lines with the same left and right area
        (so v.support will work better), only area attributes

Yes, useful.

Other possibility could be, to import dangles as grass type line, then
both lines and areas could be imported, and v.support should not fail.

Radim

3

Radim Blazek wrote:
[From Progman...]

...An area edge that
is also a line (e.g., a road which is also a eld boundary), should be
digitized as an area edge (i.e., arc type A ) to complete the area. The area
feature should be labeled as an area (i.e., feature type A in the dig_att
le). Additionally, the common boundary arc itself (i.e., the area edge which
is also a line) should be labeled as a line (i.e., feature type L in the
dig_att le) to identify it as a linear feature.

Yes, but I have noticed that opening dig_att file for updating it erase
all the previous content. I wonder if this grass lib "feature" must be
changed... I will try to have a closer look at the library and maybe
propose some change (opening for writing may clean the file, but not
opening for updating...)

If you mean dig_cats by labels, then you are right, if lines and areas
have the same category numbers, category labels may not differ.

Yes.

[...]

Other possibility could be, to import dangles as grass type line, then
both lines and areas could be imported, and v.support should not fail.

Yes, this will also work... if one can write mixed dig_att file, as I say
above...

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

4

On Tuesday 18 June 2002 11:51 am, Michel Wurtz wrote:

Yes, but I have noticed that opening dig_att file for updating it erase
all the previous content. I wonder if this grass lib "feature" must be
changed... I will try to have a closer look at the library and maybe
propose some change (opening for writing may clean the file, but not
opening for updating...)

OK, however, I would prefer to look into g51 lib.

Radim