[GRASS-dev] Re: terminology issues in grass7

[Radim Blazek]

I have doubts about many things I did in GRASS but not about the term
'layer'. It was in fact chosen to correspond better to OGR and usual
GIS terminology. And GRASS layer realy is OGR layer equivalent. As it
was mentioned already, GRASS layer is like shapefile and GRASS vector
is like a directory with more shapefiles. And also metioned, shapefile
is imported to GRASS layer and GRASS layer is exported to a shapefile
(or any other OGR layer e.g. PostGIS table). Giving to GRASS layer a
different name you make more confusion IMO.
Note also that GRASS layer could also be identified with a name (it is
partially coded).

Shortly:
  raster map -> layer  is OK
  vector map -> layer is bad
  vector map -> anything reasonable except layer is OK
  vector layer -> anything else is bad
also mentioned in mails:
  vector cat -> GID is bad because one geometry may have more cats and
geometry id exists in fact inside but it is not accessible for users
(except debugging info)
  vector cat -> FID is quite good, cat is used just for historical reasons

I have not read everything but I think that Markus Metz understands
GRASS vectors in the same way I do, so he is speaking for me more or
less.

Radim

On Tue, Jun 16, 2009 at 9:21 AM, Markus
GRASS<markus.metz.giswork at googlemail.com> wrote:
> Michael Barton wrote:
>>
>>
>> With OGR layers, for example, you can have a vector layer of
>> buildings, a layer of roads, and a layer of electrical lines. Each
>> layer contains a set of vector objects which can be linked to one or
>> more DBMS attribute tables. These can all be superimposed to produce a
>> map of a town.
> Just for the record, this can also be done with different "layers" in
> one GRASS vector, with the advantage that spatial analysis with features
> from different layers could be easier.
>>
>> GRASS vector layers are very different...and this is one of the
>> problems with calling them layers. GRASS vector "layers" are simply
>> cat values assigned to a single set of vector objects. A vector map of
>> roads with layers 1 and 2 displays the same vector objects (i.e., the
>> roads) regardless of whether layer 1 or layer 2 is chosen.
> Only if all roads have a category value assigned in each layer,
> otherwise only roads with a category value in the given layer are
> displayed, e.g. time series or town development, layer 1 shows roads
> present in 2000, layer 2 roads present in 2001 and so on. GRASS network
> analysis makes use of it, i.e. having only a subset of features present
> in a layer, see e.g. manual for v.net.salesman, lines in layer 1, points
> in layer 2.
>> The only difference between layer 1 and 2 is that the cat values
>> assigned to each of the vector objects can differ between "layer" 1
>> and 2. That is, for road objects (polylines) with ID's 1, 2, & 3 you
>> could have the following cat values assigned for layers 1 and 2 (L1
>> and L2):
>>
>> ID     cat (L1)     cat (L2)
>> 1       2                2
>> 2       3                2
>> 3       4                1
>>
>> That's all it is. Same vectors, different cat numbers.
> Can also be
>
> ID     cat (L1)     cat (L2)
> 1       2                -
> 2       -                2
> 3       4                1
>
> As above, a GRASS vector layer is not meant to have all features present
> in the vector. That can be but is in no way required.
>
>>
>> 2) made it possible for a vector to have multiple cat fields (integer
>> only still) instead of just one.
>>
>> The latter change (#2) made it possible to link a single vector file
>> simultaneously to more than one attribute table. Why they were named
>> layer 1, layer, 2, etc instead of cat 1, cat 2, etc I don't know.
> Currently, cat 1 would refer to category 1 in a given "layer". Cat and
> layer in current GRASS terminology are two different things, renaming
> layer to cat would cause confusion unless cat is renamed to something
> else. The cat value is more of an index that can link to a key field
> (usually cat). The cat field in an attribute table and the cat index are
> again two different things.
>
>> I'm not sure if there is a text label field that inherently goes along
>> with layer 2, 3, etc like there still is with layer
>> 1.
> AFAIKT there is no text label field for layer 1, but it would be nice to
> have such a text label going with each "layer" number. See also Radim's
> TODO.
>>
>> So in normal GRASS terminology, what are currently called vector
>> "layers" are in fact simply multiple "cat" fields for a vector.
> I don't think it's that simple because these multiple layers are very
> powerful and versatile, and that's probably where the confusion comes
> from, not from the name. GRASS layers can be very similar to e.g.
> different shapefiles, but then I guess that the term shapefile layers
> has probably not been created by the inventors of the shapefile format,
> shapefile as a layer is probably something OGR-specific. Maybe OGR did
> some over-generalization there with the word "layer".
>>
>> You could potentially create 10 such cat fields (i.e., 10 layers) and
>> assign different integer codes to indicate different attributes
>> associated with each vector object--e.g., the width coded in layer 1,
>> pavement type coded in layer 2, speed limit coded in layer 3, year of
>> construction coded in layer 4, etc for roads. In this sense, they
>> *could* be used to display a single set of vector objects with
>> different colors palettes to convey different kinds of information
>> about tghat single set of vector objects--color the roads by width vs
>> color the same roads by pavement type.
> Hmm, not sure if this is rather an example about how different geometry
> features can share the same category and thus link to the same entry in
> an attribute table instead of having a separate entry for each single
> geometry feature. If this would not be possible you could just as well
> have one layer with one big attribute table, then display the different
> fields in the attribute table as different display layers.
>> To me and other native english speakers, layers refers to things that
>> are stacked up or superimposed--stratigraphic layers, cake layers,
>> geospatial data (or map) layers for visualization, CAD (and OGR)
>> layers. GRASS vector "layers" are not physically or conceptually
>> stacked up or superimposed. They are different pieces of information
>> (i.e., integer numbers) linked to a single layer of vector objects.
>> The unfortunate choice in terminology some years back has meant that
>> many users are unaware of this important attribute management feature
>> of GRASS. So this is a good time to change it as we prepare for GRASS
>> 7. In the terminology of GRASS structure, vector layers are cat
>> fields; in terms of how they are most commonly used, they serve as
>> keys to link vector objects with attribute tables.
> Cake layers are spatially related and their topological interactions are
> very interesting :-) So it makes sense to not to deliver cake layers
> separately. Same for stratigraphic layers.
>
> The category index can be translated to a table with several cat fields
> (plus lineid fields and line type fields), although it does not have a
> tabular form, it rather conforms to an index tree. The cat field is
> usually the field in an attribute table used to link to a category index
> which in turn links to vector objects. The idea of linking different
> pieces of information to the same set of vector objects comes more from
> the GRASS vector ability to assign the same category value to different
> objects. This concept can be combined with the layer concept, but layers
> can also be used to handle a subset of objects present in the vector
> (again, GRASS network analysis provides examples).
>>
>> We can call this feature whatever we want of course, but I suggest
>> that we call it something to make its function more transparent to
>> users than it is now, so that it can be used more effectively.
> Compared to other OGR layers, GRASS layers have more functionality, that
> makes it difficult to come up with a name that describes it all. It's
> not getting easier considering that there are many different kinds of
> OGR layers, e.g. DFX, GPX, KML, POSTGIS, DODS/OPeNDAP, OGDI. "Layer" is
> a rather broad concept in OGR, and since OGR is the interface of GRASS
> it would make sense to try to stick to OGR terminology to avoid
> confusion amongst users. There are different kinds of layers and
> different kinds of maps, but choosing a completely new name could make
> it more difficult to grasp the concept. It may be easier to stick to
> layers, so a user could reason that different shapefiles or different
> layers in a GPX file can be translated to GRASS layers, but there are
> differences between GRASS layers, shapefiles and GPX layers. Starting
> with similarities, it may be easier to cope with differences, the
> strengths and weaknesses of each type of "layer", instead of starting
> with differences (no, that's not a layer) and then trying to figure out
> the best representation in a different format.
>
> My impression is that GRASS is different enough from other GIS packages,
> no need to pronounce that difference in new terminology. IMHO, GRASS
> would only profit from keeping OSGEO and GDAL/OGR terminology.
> Translated to the shapefile example: if a GRASS vector with all layers
> can be converted to a single shapefile, the whole GRASS vector would be
> an OGR layer; if it makes more sense to convert each GRASS vector layer
> to a separate shapefile, only the GRASS vector layer would be an OGR layer.
>
> No matter what the name will be in the end, I would like to have some
> more documentation and examples about what can be done with GRASS
> layers/cat fields/subsets...
>
> Markus M
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>