GRASS 7 Terminology

It is a disscussion, so it should be in Trac Wiki. Once it is finised, the result (not the disscusion) might be moved to GRASS Wiki but better option would be probably manual.

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".

Figure 1 from Vector Database Management

• 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.

Hamish: I'm pretty sure Radim meant for fields/layers to be a DB link from the start.

Proposal(s)

• field number
  • +0 (Hamish). The only thing I see against going back to this is that it can be confusing for non-native English speakers who only are familiar with the primary definition and not the intended & more abstract secondary meaning.
• 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.
  • +1 (Micha). Despite the widespread use of "cat" and "category" in GRASS, it seems clearer to me to have a totally different term for database links. In a vector context, "category" or "category sets" reminds me of thematic maps, which is not what we want. Other GIS use field names like "fid" "gid" etc. "key" or "keyfield" makes perfect sense to me.
  • -0 (Hamish). I've got nothing against key per se, but to someone not familar with common DB jargon like myself, there is little intuitive connection between the key to a lock and a link to a vector+DB grouping -- unless you are dealing with a DB which requires a username:password in which case it makes clear sense. But many/most users will not be using Postgre/MySQL/Oracle out of the box and those who do are probably advanced enough to figure out whatever name we use pretty quickly. Note name-space collision with "key column", which may rule this one out.
• keyfield
  • -1 (Hamish). Redundant; too wordy; too "wtf?".
• table link
  • -1 (Hamish). I don't like "table link" as it is too wordy, but I do really like link on its own.
• link
  • +1 (Hamish) IMHO this describes both the idea and actual mechanics of it rather well.
• category set
  • +1 (ML)
  • +1 - in light of my above remark this seems to be the most general term (Moritz)
  • -1 (Hamish). Too wordy; too close to "category" so would be confusing and in practice would get shortened to "set" which could possibly be confusing to MSWindows .bat users and csh dinosaurs; too "wtf?". "Set the category to what? Have you set the category or not?"

See also

• http://lists.osgeo.org/pipermail/grass-dev/2008-August/039277.html
• GRASS 5 terminology
• GRASS 6 Terminology
• GRASS 6 terminology fixes
• The terminology is related to flags and parameters standardization. See proposal(s).
• GRASS 6 -> 7 renamed parameter options
• GRASS Message Standardization
• OGC standards
• GIS DataFinder
• OGC Glossary of Terms
• ESRI GIS Dictionary