[GRASS5] line types

Radim Blazek blazek at itc.it
Wed Apr 10 03:14:29 EDT 2002


On Tuesday 09 April 2002 06:31 pm, rgrmill at rt66.com wrote:
> No, it isn't one special case.  It is a fairly general case.  Many of us
> have to deal with public data sets.  The data sets tend to be large,
> they tend to be imperfect and they often don't fit the GRASS vector
> model.

many != all;
There are other public data sets using distinction between edges and lines. 

> >  'type=edge,line' instead of only 'type=line'

> This is a change that I can make myself.  It's a simple work around for
> these two modules.  There are certainly other modules that share the
> problem.

Of course, all modules missing boundary type needs that option.
If you add that option, please commit also to cvs for other users.

> This isn't a matter of limiting functionality.  If a user needs to
> distinguish between lines and area edges then the functionality is
> already there in the category values and in layer separation.  Removing
> the distinction between area edges and lines can actually increase the
> functionality.

No. For a map where are only areas and lines, and lines are never boundaries,
it is much more easier to just use appropriate type during digitizing than to 
attache category + type in label and then select lines according to the type 
saved in label.

> I already demonstrated that by removing the distinction
> from two modules and getting behavior out of those modules that I could
> not get otherwise.

I don't understand why you cannot not do the task with type=edge,
why you must remove 'line' type.

> The division between lines of type "line" and lines of type "area edge"
> is wrong; it's a bad model.  There is no actual distinction between the
> edge of an area and a line.  A fence is also an edge of a field.  A user
> could very reasonably want to know both the length of the fence line and
> the area of the field. A single object should be able to serve both
> functions. Trying to draw and maintain a synthetic distinction may work
> for some things but in the long run I don't think that it is a good
> idea.

I think that model with lines/edges is better in many cases . Example:
map with forests, fields and roads. Forests and fields are areas with type 
saved in category label. If roads (type line) are crossing area of one type,
the area is not divided to many parts. If you have only area edges available,
you get area, splitted to many parts, and you must lable all that parts.

> A lot of problems can be avoided by separating line features and areas
> into different data sets.  Once they're separated the distinction should
> be insignificant.  What difference should the line type make if the data
> set contains only one type of data?  

Yes, but we are talking about the cases, where separation is not effective.

> Category values can also be used to draw the distinction.

Then type is only saved in another place. It is not usefull for build 
process, for which is best to save type in dig file.

> Errors in building the topology are nothing new.  I guess I would worry
> more about reported errors in the build if the system worked now without
> errors.  It doesn't.

I think that build process works without errors, i am interested in clean 
data sets, for which build process fails - please send to me if possible.
I care about error messages, and i need to know if error is realy error
in area topology and not correct free end of line.

> Finally, I far prefer spending a few extra minutes waiting for v.support
> to build extra areas to spending days manually assigning the correct
> line types.  Imagine digging through 45,000 lines of type "line" to
> manually toggle 10,000 lines to "area edge" so that they can be used to
> define areas.

I don't understend why you must do that. If you like, you can use edge type 
for all arcs. We must keep possibility to do that, for those who want.

In general, you can use edge type only, if you want, in system with both
edge/line type, but others who need the distinction, cannot use the system
where line type is not present.

Radim




More information about the grass-dev mailing list