GRASS 7 Terminology

This page is dedicated to discussion about changes in terminology for GRASS 7.

Map

Currently data entities like rasters or vectors are called in GRASS "maps", i.e. "raster map" or "vector map".

• ML: GRASS is basically "layer-based" GIS, calling single raster or vector entities as "maps" is quite confusing. Better would be to use term "layer" or "map layer" for this purpose. "Map" can be used for layer composition, e.g. for cartography outputs.

Proposal(s)

• map layer
  • raster layer
  • 3D raster layer
  • vector layer

Vector layer

The term "vector layer" is currently used even in more confusing sense, to mark subgroup of vector objects in vector entity. Originally called as "field".

• ML: Not sure if to go back to the original term "field" (DB-based) or use something like "sub-layer".
• WB: How about calling it "attribute-layer" which connects to an "attribute-table" (DB table)?
• Moritz: I think the original motivation of layers was not necessarily DB-based, but rather to make it possible to have different types of features in one file. For example, you could have a file with fields and roads together, where the boundary of a field is a road. So in layer 1 (the fields) this line would not have a category value, but in layer 2 (the roads) it would. The fact that you can (but do not have to) then link each of these layers to different tables is just part of the story.

Proposal(s)

• field number
• key
  • +1 (Michael). This is the proper term in database terminology. A vector must have at least one set of keys (= 1 or more layers). These are currently called "CAT" for category. The history of this is that it parallels the "category" of a raster cell. Back in GRASS 5 and below, vectors were not regularly linked to external tables (although it was possible to link up a PostgreSQL table) and each vector object had an integer identifier (i.e., a category) and a label, just like a raster. However, since Radim rewrote the vector architecture for GRASS 5.7 (6.0 beta) and above, it is used quite differently, as the key field to link vector objects to lines in an attribute data table. This is pretty standard relational database structure. A linked table is not mandatory, but AFAIK, at least 1 "layer" of "cat" values (i.e., key field values) is required for any vector file. So, I suggest that we don't make up a special GRASS term for a key field but just use the term key (or keyfield). Any set of vector objects in a file can have 1 or more key fields. This identifies each vector object with 1 or more keys, and has the potential to link each object to a line in an attribute data table that has a matching key. In GRASS, keys do not have to be unique; this does not keep them from being keys, but is simply a characteristic of GRASS key fields.
• keyfield
• table link
• category set
  • +1 (ML)
  • +1 - in light of my above remark this seems to be the most general term (Moritz)

See also

• http://lists.osgeo.org/pipermail/grass-dev/2008-August/039277.html
• GRASS 5 terminology
• GRASS 6 terminology fixes
• The terminology is related to flags and parameters standardization. See proposal(s).