Hi,
I have notice that "v.category option=print type=area" never prints any
categories. Why is that so?
Example: in spearfish there is a 'fields' vector which has 65 areas, 63
of them with centroids. But
v.category fields option=print type=area
prints nothing; a bug?
Whereas
v.category fields option=print type=centroid
gives 63 lines of output - OK.
Maciek
Hi Maciek,
2006/11/21, Maciej Sieczka <tutey@o2.pl>:
Hi,
I have notice that "v.category option=print type=area" never prints any
categories. Why is that so?Example: in spearfish there is a 'fields' vector which has 65 areas, 63
of them with centroids. Butv.category fields option=print type=area
prints nothing; a bug?
not sure, I see vector type 'area' as a "virtual" type, so I think an
area cannot be associated with category number. It's always centroid
(and/or boundary) which has category number. So
v.category fields option=print type=area
does not make sense to me... (??)
Whereas
v.category fields option=print type=centroid
gives 63 lines of output - OK.
Best, Martin
Maciek
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Wed, Nov 22, 2006 at 12:58:08PM +0100, Martin Landa wrote:
Hi Maciek,
2006/11/21, Maciej Sieczka <tutey@o2.pl>:
>Hi,
>
>I have notice that "v.category option=print type=area" never prints any
>categories. Why is that so?
>
>Example: in spearfish there is a 'fields' vector which has 65 areas, 63
>of them with centroids. But
>
> v.category fields option=print type=area
>
>prints nothing; a bug?not sure, I see vector type 'area' as a "virtual" type, so I think an
area cannot be associated with category number. It's always centroid
(and/or boundary) which has category number. Sov.category fields option=print type=area
does not make sense to me... (??)
This sounds reasonable. If true, the area type should be removed
from the list to avoid confusion.
Markus
Markus Neteler wrote:
On Wed, Nov 22, 2006 at 12:58:08PM +0100, Martin Landa wrote:
Hi Maciek,
2006/11/21, Maciej Sieczka <tutey@o2.pl>:
Hi,
I have notice that "v.category option=print type=area" never prints any
categories. Why is that so?Example: in spearfish there is a 'fields' vector which has 65 areas, 63
of them with centroids. Butv.category fields option=print type=area
prints nothing; a bug?
not sure, I see vector type 'area' as a "virtual" type, so I think an
area cannot be associated with category number. It's always centroid
(and/or boundary) which has category number. Sov.category fields option=print type=area
does not make sense to me... (??)
This sounds reasonable. If true, the area type should be removed
from the list to avoid confusion.
I'd rather suggest to map area to centroid (i.e. if area is given behave the same as if centroid is given), as intuitively people are looking for information concerning areas not centroids.
Moritz
Hi,
2006/11/22, Moritz Lennert <mlennert@club.worldonline.be>:
I'd rather suggest to map area to centroid (i.e. if area is given behave
the same as if centroid is given), as intuitively people are looking for
information concerning areas not centroids.
Area = centroid + boundary
simplification you suggest tend to be misguided;-) I prefer (but not
sure) removing area from the type list and update manual pages of
v.category to make it clear to user. What do you think about it?
Best, Martin
Moritz
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
Martin Landa wrote:
Hi,
2006/11/22, Moritz Lennert <mlennert@club.worldonline.be>:
I'd rather suggest to map area to centroid (i.e. if area is given behave
the same as if centroid is given), as intuitively people are looking for
information concerning areas not centroids.Area = centroid + boundary
simplification you suggest tend to be misguided;-) I prefer (but not
sure) removing area from the type list and update manual pages of
v.category to make it clear to user. What do you think about it?
I think both approaches are valid. My suggestion tries to just gloss over the user's lack of understanding, yours tries to teach him. So probably yours is better and more in line with the general GRASS approach.
Moritz
Hello,
On Wed, Nov 22, 2006 at 12:58:08PM +0100, Martin Landa wrote:
Hi Maciek,
2006/11/21, Maciej Sieczka <tutey@o2.pl>:
>Hi,
>
>I have notice that "v.category option=print type=area" never prints any
>categories. Why is that so?
>
>Example: in spearfish there is a 'fields' vector which has 65 areas, 63
>of them with centroids. But
>
> v.category fields option=print type=area
>
>prints nothing; a bug?not sure, I see vector type 'area' as a "virtual" type, so I think an
area cannot be associated with category number. It's always centroid
(and/or boundary) which has category number. So
FWIW, and to be able (I'm talking about myself) to have an overview of
your new vector engine here is how things were going with CERL
GRASS 4.1 vector format (and GRASS GPL <= 5.4) [this was not
explicitely stated; this is an extended description].
1) the vector element is an ARC, that is an oriented vector of vertices.
2) the vertices can be seen as control points. The nature of the one
dimension element drawned according to these control points can be
called the functional type (in KerGIS V_FTYPE_*). There was (is) only
one functional type supported: V_FTYPE_LINE (polylines, or segments).
3) the topological type of the ARC tells what _geometrical_ element to
deduce from the ARCS. Topological types are : V_TTYPE_DOT, V_TTYPE_PATH,
V_TTYPE_EDGE (were respectively DOT, LINE and AREA in legacy code).
4) the geometrical figures are deduced from the previous informations.
The geometrical figures are V_GTYPE_POINT, V_GTYPE_LINE, G_GTYPE_AREA.
5) the legacy categories are associated with _geometrical figures_ by a
_topological_ mean: a point "on" an element (nearest to this element
than to another one) [category are now in KerGIS group numbers, and
label group names à la DNS].
So, with the legacy topological vector engine, categories are precisely
associated with areas, the centroïd being the topological mean to make
the association.
How does your new vector engine define these things?
Cheers,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Moritz:
> I'd rather suggest to map area to centroid (i.e. if area is given
> behave the same as if centroid is given), as intuitively people are
> looking for information concerning areas not centroids.
Martin:
Area = centroid + boundary
simplification you suggest tend to be misguided;-) I prefer (but not
sure) removing area from the type list and update manual pages of
v.category to make it clear to user. What do you think about it?
does "area" not make sense for all other options as well?
option Action to be done:
add - add a new category
del - delete category
chlayer - change layer number (e.g. layer=3,1 changes layer 3 to layer 1)
sum - add the value specified by cat option to the current category value
report - print report (statistics), in shell style:
layer type count min max
print - print category values, more cats in the same layer are separated by '/'
options: add,del,chlayer,sum,report,print
default: add
Hamish
I'd suggest removing centroid AND boundary from the type list and explaining
the centroid+boundary=area relationship in the docs. Lines can have
categories, but it makes no sense for a "boundary" to have a cat if it is
really the boundary of an area. If it is not, it is simply a closed
line/arc.
The underlying topology of GRASS vectors is logical and sensible overall.
However, the terminology is a legacy that should be discussed as such, but
it should not confront the everyday user.
Functionally, GRASS is like any other vector GIS in that is has points,
lines/arcs, and polygons/areas. This is how it should be presented to the
normal user.
The fact that a polygon/area is built from a closed line/arc and an
associated point that is located inside the closed line/arc seems to be a
very clean kind of underlying organization. It makes it nice to teach about
GIS and geospatial data. It also makes manipulating those data in
sophisticated ways more transparent. BUT the normal user doesn't really need
to know that simply to do basic GIS activities.
So my recommendation is to explain this in the docs so that users can learn
sophisticated techniques like reassociating sets of boundaries and points to
create areas with new kinds of data. In this respect, we should also leave
this in v.type for vector type conversions (though this module needs to have
a better GUI and explanations to be usable). However, we should drop
references to centroids and boundaries in most other places--like in
v.category or d.vect. Somehow, we also need to make vectors respond to mouse
clicks anywhere inside their boundaries and not just on the centroid. GRASS
is complex enough without including options and terminology that don't
really offer anything to users.
My 2 cents worth
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Wed, 22 Nov 2006 14:30:34 +0100
To: Martin Landa <landa.martin@gmail.com>
Cc: grass-dev <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] v.category option=print: fails to print area's
categoriesMartin Landa wrote:
Hi,
2006/11/22, Moritz Lennert <mlennert@club.worldonline.be>:
I'd rather suggest to map area to centroid (i.e. if area is given behave
the same as if centroid is given), as intuitively people are looking for
information concerning areas not centroids.Area = centroid + boundary
simplification you suggest tend to be misguided;-) I prefer (but not
sure) removing area from the type list and update manual pages of
v.category to make it clear to user. What do you think about it?I think both approaches are valid. My suggestion tries to just gloss
over the user's lack of understanding, yours tries to teach him. So
probably yours is better and more in line with the general GRASS approach.Moritz
Hi,
2006/11/23, Michael Barton <michael.barton@asu.edu>:
I'd suggest removing centroid AND boundary from the type list and explaining
the centroid+boundary=area relationship in the docs. Lines can have
categories, but it makes no sense for a "boundary" to have a cat if it is
really the boundary of an area.
I don't agree with you, sorry, boundary line (between two areas) can
be associated with a category number!! As an example I can mention the
cadastral maps. Removing centroid and boundary type from the list
would be restriction which I think does not follow GRASS way of
thinking and its freedom.
If it is not, it is simply a closed
line/arc.The underlying topology of GRASS vectors is logical and sensible overall.
However, the terminology is a legacy that should be discussed as such, but
it should not confront the everyday user.Functionally, GRASS is like any other vector GIS in that is has points,
lines/arcs, and polygons/areas. This is how it should be presented to the
normal user.The fact that a polygon/area is built from a closed line/arc and an
associated point that is located inside the closed line/arc seems to be a
very clean kind of underlying organization. It makes it nice to teach about
GIS and geospatial data. It also makes manipulating those data in
sophisticated ways more transparent. BUT the normal user doesn't really need
to know that simply to do basic GIS activities.
I don't know a normal user/man;-) Restrictions in general are not
good, there is a documentation for user who has power to use GRASS/or
something similar.
Best regards, Martin
So my recommendation is to explain this in the docs so that users can learn
sophisticated techniques like reassociating sets of boundaries and points to
create areas with new kinds of data. In this respect, we should also leave
this in v.type for vector type conversions (though this module needs to have
a better GUI and explanations to be usable). However, we should drop
references to centroids and boundaries in most other places--like in
v.category or d.vect. Somehow, we also need to make vectors respond to mouse
clicks anywhere inside their boundaries and not just on the centroid. GRASS
is complex enough without including options and terminology that don't
really offer anything to users.My 2 cents worth
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton> From: Moritz Lennert <mlennert@club.worldonline.be>
> Date: Wed, 22 Nov 2006 14:30:34 +0100
> To: Martin Landa <landa.martin@gmail.com>
> Cc: grass-dev <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] v.category option=print: fails to print area's
> categories
>
> Martin Landa wrote:
>> Hi,
>>
>> 2006/11/22, Moritz Lennert <mlennert@club.worldonline.be>:
>>
>>> I'd rather suggest to map area to centroid (i.e. if area is given behave
>>> the same as if centroid is given), as intuitively people are looking for
>>> information concerning areas not centroids.
>>
>> Area = centroid + boundary
>>
>> simplification you suggest tend to be misguided;-) I prefer (but not
>> sure) removing area from the type list and update manual pages of
>> v.category to make it clear to user. What do you think about it?
>
> I think both approaches are valid. My suggestion tries to just gloss
> over the user's lack of understanding, yours tries to teach him. So
> probably yours is better and more in line with the general GRASS approach.
>
> Moritz
>
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
tlaronde@polynum.com wrote on 11/22/2006 04:10 PM:
Hello,
On Wed, Nov 22, 2006 at 12:58:08PM +0100, Martin Landa wrote:
Hi Maciek,
2006/11/21, Maciej Sieczka <tutey@o2.pl>:
Hi,
I have notice that "v.category option=print type=area" never prints any
categories. Why is that so?Example: in spearfish there is a 'fields' vector which has 65 areas, 63
of them with centroids. Butv.category fields option=print type=area
prints nothing; a bug?
not sure, I see vector type 'area' as a "virtual" type, so I think an
area cannot be associated with category number. It's always centroid
(and/or boundary) which has category number. So
FWIW, and to be able (I'm talking about myself) to have an overview of
your new vector engine here is how things were going with CERL
GRASS 4.1 vector format (and GRASS GPL <= 5.4) [this was not
explicitely stated; this is an extended description].1) the vector element is an ARC, that is an oriented vector of vertices.
2) the vertices can be seen as control points. The nature of the one
dimension element drawned according to these control points can be
called the functional type (in KerGIS V_FTYPE_*). There was (is) only
one functional type supported: V_FTYPE_LINE (polylines, or segments).3) the topological type of the ARC tells what _geometrical_ element to
deduce from the ARCS. Topological types are : V_TTYPE_DOT, V_TTYPE_PATH,
V_TTYPE_EDGE (were respectively DOT, LINE and AREA in legacy code).4) the geometrical figures are deduced from the previous informations.
The geometrical figures are V_GTYPE_POINT, V_GTYPE_LINE, G_GTYPE_AREA.5) the legacy categories are associated with _geometrical figures_ by a
_topological_ mean: a point "on" an element (nearest to this element
than to another one) [category are now in KerGIS group numbers, and
label group names à la DNS].So, with the legacy topological vector engine, categories are precisely
associated with areas, the centroïd being the topological mean to make
the association.How does your new vector engine define these things?
The Programmer's manual should hopefully explain it:
http://mpa.itc.it/markus/grass63progman/
-> Related Pages <http://mpa.itc.it/markus/grass63progman/pages.html>
-> GRASS 6 Vector Architecture
-> Vector library Topology management
Markus
Michael Barton wrote:
I'd suggest removing centroid AND boundary from the type list
That wouldn't improve anything and you could not manage categories of
centroids and boundaries anymore.
and explaining
the centroid+boundary=area relationship in the docs.
area=centroid+boundary indeed, but they also happen to go alone (eg. in
not topologicaly clean data, that require a cleanup; or when one
extracts some centroids or boundaries from his areas for further
processing).
Lines can have
categories, but it makes no sense for a "boundary" to have a cat if it is
really the boundary of an area. If it is not, it is simply a closed
line/arc.
No. Because when I want to v.extract some boundaries from a vector, I
have to add categories to them. Then I might want to remove them. Same
about centroids.
<snip>
we should drop
references to centroids and boundaries in most other places--like in
v.category or d.vect.
Being able to display only centroids, or only boundaries is a usefull
option during exploring the data. Don't remove it.
Somehow, we also need to make vectors respond to mouse
clicks anywhere inside their boundaries and not just on the centroid.
That's already achieved in v.what and d.what.vect - wherever I point
withing the area, it is querried; do you mean something else?
Back to topic: I came to conclusion that v.category option=print
failing to print area's categories is a bug and should be fixed, and
that reporting for boundaries and centroids separately should be kept
as is. That's because the user might want to report categories
separately for centroids, areas and boundaries, eg. to find out which
centroids are outside area, or which areas are broken. IOW - the option
is there and is usefull, only it is not working - 'v.category
option=print' fails to print area's categories. Is that possible to be
fixed?
Maciek
On 11/23/06, Michael Barton <michael.barton@asu.edu> wrote:
I'd suggest removing centroid AND boundary from the type list and explaining
the centroid+boundary=area relationship in the docs. Lines can have
categories, but it makes no sense for a "boundary" to have a cat if it is
really the boundary of an area.
It makes sense. Try to import TIGER data (all the layers to one vector)
and query the map.
Radim
If it is not, it is simply a closed
line/arc.The underlying topology of GRASS vectors is logical and sensible overall.
However, the terminology is a legacy that should be discussed as such, but
it should not confront the everyday user.Functionally, GRASS is like any other vector GIS in that is has points,
lines/arcs, and polygons/areas. This is how it should be presented to the
normal user.The fact that a polygon/area is built from a closed line/arc and an
associated point that is located inside the closed line/arc seems to be a
very clean kind of underlying organization. It makes it nice to teach about
GIS and geospatial data. It also makes manipulating those data in
sophisticated ways more transparent. BUT the normal user doesn't really need
to know that simply to do basic GIS activities.So my recommendation is to explain this in the docs so that users can learn
sophisticated techniques like reassociating sets of boundaries and points to
create areas with new kinds of data. In this respect, we should also leave
this in v.type for vector type conversions (though this module needs to have
a better GUI and explanations to be usable). However, we should drop
references to centroids and boundaries in most other places--like in
v.category or d.vect. Somehow, we also need to make vectors respond to mouse
clicks anywhere inside their boundaries and not just on the centroid. GRASS
is complex enough without including options and terminology that don't
really offer anything to users.My 2 cents worth
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton> From: Moritz Lennert <mlennert@club.worldonline.be>
> Date: Wed, 22 Nov 2006 14:30:34 +0100
> To: Martin Landa <landa.martin@gmail.com>
> Cc: grass-dev <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] v.category option=print: fails to print area's
> categories
>
> Martin Landa wrote:
>> Hi,
>>
>> 2006/11/22, Moritz Lennert <mlennert@club.worldonline.be>:
>>
>>> I'd rather suggest to map area to centroid (i.e. if area is given behave
>>> the same as if centroid is given), as intuitively people are looking for
>>> information concerning areas not centroids.
>>
>> Area = centroid + boundary
>>
>> simplification you suggest tend to be misguided;-) I prefer (but not
>> sure) removing area from the type list and update manual pages of
>> v.category to make it clear to user. What do you think about it?
>
> I think both approaches are valid. My suggestion tries to just gloss
> over the user's lack of understanding, yours tries to teach him. So
> probably yours is better and more in line with the general GRASS approach.
>
> Moritz
>_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
Michael Barton wrote:
Lines can have categories, but it makes no sense for a "boundary" to
have a cat if it is really the boundary of an area.
I do not want to flog a dead horse, but 2c more -
The classic example was a road vector acting as a boundary between two
parcels of land. The boundary's cat holds info about the road name,
etc. It can't hold area info (beyond what roads bound it) as it is
ambiguous as to if it refers to the area on the left side or right side
of the boundary. Perhaps don't force centroid+boundary talk in the
"first day tutorial", but folks eventually need to know how the vector
systems work to have any hope of fixing their data when it breaks or
doing something new (line->area).
Hamish
I do not want to flog a dead horse, but 2c more -
The classic example was a road vector acting as a boundary between two
parcels of land. The boundary's cat holds info about the road name,
etc. It can't hold area info (beyond what roads bound it) as it is
ambiguous as to if it refers to the area on the left side or right side
of the boundary.
Sorry if I was not clear. A polyline with a cat value--including a closed
polyline--can certainly be useful when it forms the boundary of an area or
is in any other context. However, AFAICT, a "boundary" is simply a cloased
line/arc associated with point that together define an area. It is
nevertheless a line/arc. Adding categories to a boundary is the same thing
as adding categories to a line/arc. By the same token, a "centroid" is
still a point, whether it is in an area or not.
If you have a map of areas, using v.category to add categories to the lines
is the same thing as adding categories to the boundaries. I suppose you
could have a vector map that has both unclosed lines and closed lines and
only want to categories to one group or the other. But in this case, some
kind of more general querying might be more useful to accomplish this.
In the case of "centroids" and "areas", I fail to see how you can add cats
to centroids but not to areas, or cats to areas and not to centroids. Not
only is it impossible to have an area without a centroid, but all the
attribute data for an area resides in the centroid data table.
It's not that having the option of a different cat (and potentially
attribute table) for the line around an area and for the area inside the
line. It's the legacy terminology that is confusing.
Having a v.category that lets you add cats to points (and area centroids)
and lines (and area boundaries) covers all that actually happens currently.
Since, most GIS talks about points, lines/arcs, and polygons/areas as the
fundamental building blocks of 2D GIS, however, portraying the GRASS vector
structure in this way for basic tasks is pretty easily understandable by
anyone familiar with GIS.
Differentiating open lines from closed ones can be useful sometimes, but
there is no guarantee that adding cats to boundaries will only affect areas,
since closed lines exist with or without being associated with areas. This
can lead to confusion unless clearly explained. This is why I suggested
dropping the boundary option; you simply assign cats to lines regardless of
whether they border areas or not. If we really want to manage those lines
that bound areas, then they need to be defined differently from closed lines
that do not bound areas. Currently, the terminological category "boundary"
includes both.
Having different options to add cats to areas and centroids makes no sense
at all since you can't do one without doing the other.
Perhaps don't force centroid+boundary talk in the
"first day tutorial", but folks eventually need to know how the vector
systems work to have any hope of fixing their data when it breaks or
doing something new (line->area).
I agree with this. That was the other point I was trying to make. This is a
very useful way to create areas, and means that you can do some
sophisticated things--including fixing squirrelly data or changing
attributes associated with areas in complex ways. But it's not something
that needs to confront the user in many circumstances. I'm not suggesting
that we restrict functionality, but to our best to portray the very complex
functionality of GRASS in as clear and understandable way that we can.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
A polyline with a cat value--including a closed polyline--can
certainly be useful when it forms the boundary of an area or is in any
other context. However, AFAICT, a "boundary" is simply a cloased
line/arc associated with point that together define an area.
that is an "area" is simply a closed BOUNDARY line/arc associated with
CENTROID that together define an area.
the raw boundary feature type is not associated with any single point or
centroid.
points,centroids are both a single point in 3D space, but are stored
differently in the vector file. Same for line,boundary. Hence v.type.
It is nevertheless a line/arc. Adding categories to a boundary is the
same thing as adding categories to a line/arc.
fundamentally they are both polylines. But we are abstracted from that.
...
Differentiating open lines from closed ones can be useful sometimes,
boundaries can be open or closed, that has nothing to do with their
vector feature-type status.
a closed line + a centroid does not make an area. An example of a closed
line which is not a boundary is a closed contour line around a hill.
but there is no guarantee that adding cats to boundaries will only
affect areas, since closed lines exist with or without being
associated with areas.
I don't understand this. Adding cats to boundaries is rare, but when it
happens it will not affect the surrounding areas one way or another.
This can lead to confusion unless clearly explained.
Indeed.
This is why I suggested dropping the boundary option; you simply
assign cats to lines regardless of whether they border areas or not.
If we really want to manage those lines that bound areas, then they
need to be defined differently from closed lines that do not bound
areas. Currently, the terminological category "boundary" includes
both.
is this what you are asking:
v.category --help
type Type
Feature type(s)
- options: point,line,boundary,centroid,area
+ options: point,line,boundary,centroid
or this:
v.category --help
type Type
Feature type(s)
- options: point,line,boundary,centroid,area
+ options: point,line,area
??
I'm not sure about the first, the second is bad.
Hamish
From: Hamish <hamish_nospam@yahoo.com>
Date: Sat, 25 Nov 2006 20:54:43 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] v.category option=print: fails to print area's
categoriesboundaries can be open or closed, that has nothing to do with their
vector feature-type status.a closed line + a centroid does not make an area. An example of a closed
line which is not a boundary is a closed contour line around a hill.
So what *is* a boundary when it is not associated with an area? This is both
a question of concept and topology. Probably 2 different answers.
I'm beginning to suspect that what ought to happen is that boundaries should
be restricted to lines surrounding areas and lines are everything else. It's
not that you can't create an entity with the topology of a boundary that is
not associated with an area, but perhaps you shouldn't. What purpose does it
serve? (This is a real and not a rhetorical question. Maybe it does
something I don't understand).
but there is no guarantee that adding cats to boundaries will only
affect areas, since closed lines exist with or without being
associated with areas.I don't understand this. Adding cats to boundaries is rare, but when it
happens it will not affect the surrounding areas one way or another.
What I meant is the following. Combine a map of boundaries (some open and
some closed) with a map of points to create areas. Run v.category to give
cats to the boundaries. Cats will be assigned to the "boundary" arcs that
are not area boundaries as well as those that are. This is computationally
correct. But conceptually I don't see the difference between adding cats to
the boundaries, and calling the boundaries lines and adding cats to the
lines. This is in a large part a definitional issue related to my questions
about the nature of boundaries above.
This can lead to confusion unless clearly explained.
Indeed.
This is why I suggested dropping the boundary option; you simply
assign cats to lines regardless of whether they border areas or not.
If we really want to manage those lines that bound areas, then they
need to be defined differently from closed lines that do not bound
areas. Currently, the terminological category "boundary" includes
both.is this what you are asking:
v.category --help
type Type
Feature type(s)
- options: point,line,boundary,centroid,area
+ options: point,line,boundary,centroidor this:
v.category --help
type Type
Feature type(s)
- options: point,line,boundary,centroid,area
+ options: point,line,area??
I'm not sure about the first, the second is bad.
At least the first. Why list area and centroid separately?
The second would be even better (IMHO) if adding cats to lines included the
lines bordering and defining areas. If boundaries can be conceptually
differentiated from lines, then the first might be preferable, but I'm still
not sure.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
Why list area and centroid separately?
Because you can have "broken areas" - there is a centroid inside, but
the boundary is not closed (eg. after importing a non-topological
shapefile; or due to an error during digitizing). Listing areas and
centroids separately can help you debug the issue.
The second would be even better (IMHO) if adding cats to lines included the
lines bordering and defining areas. If boundaries can be conceptually
differentiated from lines
If they were not, any closed line without a centroid would be an
invalid area according to GRASS topological model. The boundaries type
enables to distinguish the closed lines from incomplete areas (closed
boundaries missing the centroid).
, then the first might be preferable, but I'm still
not sure.
Maciek