On Jun 16, 2009, at 11:06 PM, Markus GRASS wrote:
Michael Barton wrote:
On Jun 16, 2009, at 12:39 PM, Paul Kelly wrote:
On Tue, 16 Jun 2009, Michael Barton wrote:
In GRASS, displaying Layer 1 will show all objects for some vector
topologies, and only ID 1 and 2 for other topologies. However, by
putting
values into cat for Layer 1, you can also display ID's 3 & 4 for
Layer 1. You
can achieve the same effect by querying cat = 1 for Layer 2. The
difference
is that sometimes empty cats are displayed and sometimes they are
not. To me
this is kind of an automatic (inadvertent even) query. Some of this
is only
semantics, but I think we all agree that semantics can be
important.
IMHO these are all side-effects of the inconsistent way layers are
handled
amongst different GRASS modules. It's an implementation problem
(perhaps
caused by confusion among developers as options were added and
modified
over the years), rather than a fundamental problem with the layer
concept.
The inconsistent implementation is an issue certainly. I don't think
that there is a problem with underlying concept of the layer feature.
Indeed, it is a very powerful data management feature of GRASS. I
just
think that another name for the feature would help users to
understand
and make use of it better--especially since we also use the term
layers in the GUI layer manager to refer to superimposed displays of
distinct geospatial data files, a very common usage in GIS.
You may notice that you have to specify a vector layer for d.vect in
the
GUI layer manager, i.e. the GUI layer manager displays a vector layer
unless layer=-1. I bet you yourself use most of the time d.vect
layer=1
and not layer=-1.
I do. But that is because I prefer to use a linked attribute table to
control what is displayed, what is not displayed, and what is used for
labels--and usually only need to link a single table to do so. I
prefer the linked table because the actual cat values that make up
each layer table are more difficult to manage than an attribute table
linked to the vector file via the cat values. There is no way that I
know of to access and change these values directly--only through
v.category or v.reclass. In both cases, these programs display the
raster-like heritage of vector data management and layers, but we lack
the equivalent of a d.rast.edit. This also makes layers as now
structured difficult to use for differentially displaying sets of
vector objects.
While I'm happy with the way vector layers work now, but think they
should be called something different to avoid confusion with display
layers and OGR layers, several commentators are expressing a
preference for a function that does work like OGR layers to subset
vector objects within a file for display or other manipulation. If we
really want a structure that will subset a vector file into mutually-
exclusive groups like CAD layers, we need to rework how GRASS vector
layers actually work. In this sense, the database relationship should
be 1 layer to many vector objects, rather than the current 1 vector
object to many layers. Moreover, to make this truly useful, I suggest
we also look at changing vector manipulation modules (v.distance,
v.overlay, etc) so that selecting a layer works like a MASK in rasters
by only carrying out the operation on the objects that are grouped
into that layer. Other programs that use vector layers work in this
way, allowing you to "lock" a layer so that objects in that layer are
not altered during editing actions.
Michael
If we manage to come to a full understanding of the capabilities and
possibilities of the concept of vector layers in GRASS (which I feel
this
discussion is really helping us to work towards, for me anyway),
then it
would be an exciting project to do an audit of all vector modules
and
the
way they handle layers, and tidy up all the inconsistencies so
that the
meaning of layers is much more obvious, simply from the module
options and
flags. Perhaps too radical though.
Tidying up inconsistencies is not radical but regular maintenance
work IMHO.
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
