GRASS 7 Terminology - Revision history

Neteler: +figure explaining layers

2014-03-24T21:39:22Z

+figure explaining layers

← Older revision		Revision as of 21:39, 24 March 2014
Line 21:		Line 21:

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

			[[File:Catsnlayers.png\|800px\|thumb\|alt=cats and layers in GRASS GIS\|center\|Figure 1 from [[Vector Database Management]]]]

	* [[User:Landa\|ML]]: Not sure if to go back to the original term "field" (DB-based) or use something like "sub-layer".		* [[User:Landa\|ML]]: Not sure if to go back to the original term "field" (DB-based) or use something like "sub-layer".

⚠️Wenzeslaus: move to trac

2014-01-29T03:21:43Z

move to trac

← Older revision		Revision as of 03:21, 29 January 2014
Line 1:		Line 1:
			{{MoveToTrac}}

			''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.		This page is dedicated to discussion about changes in terminology for GRASS 7.

⚠️MilenaN: Reverted edits by Reverse22 (talk) to last revision by Neteler

2011-12-30T21:36:55Z

Reverted edits by Reverse22 (talk) to last revision by Neteler

← Older revision		Revision as of 21:36, 30 December 2011
Line 57:		Line 57:

	[[Category: Development]]		[[Category: Development]]


	~~==Other==~~
	~~[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]~~

⚠️Reverse22 at 20:51, 30 December 2011

2011-12-30T20:51:06Z

← Older revision		Revision as of 20:51, 30 December 2011
Line 57:		Line 57:

	[[Category: Development]]		[[Category: Development]]


			==Other==
			[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Neteler: /* See also */

2011-05-22T12:44:26Z

Neteler: /* See also */

2010-07-26T19:22:13Z

⚠️HamishBowman: /* Vector layer */

2010-01-09T07:31:04Z

Vector layer

← Older revision		Revision as of 07:31, 9 January 2010
Line 40:		Line 40:
	** +1 ([[User:Landa\|ML]])		** +1 ([[User:Landa\|ML]])
	** +1 - in light of my above remark this seems to be the most general term (Moritz)		** +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?''"		** -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 ==		== See also ==

⚠️HamishBowman: /* Vector layer */

2010-01-09T07:29:26Z

Vector layer

← Older revision		Revision as of 07:29, 9 January 2010
Line 30:		Line 30:
	** +1 ([[User:cmbarton\|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 ([[User:cmbarton\|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 ([[User:micha\|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.		** +1 ([[User:micha\|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.		** -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'''		* '''keyfield'''
	** -1 (Hamish). Redundant; too wordy; too "wtf?".		** -1 (Hamish). Redundant; too wordy; too "wtf?".

⚠️HamishBowman: /* Vector layer */ imo

2010-01-08T09:32:02Z

Vector layer: imo

← Older revision		Revision as of 09:32, 8 January 2010
Line 21:		Line 21:
	* WB: How about calling it "attribute-layer" which connects to an "attribute-table" (DB table)?		* 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.		* 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)		;Proposal(s)

	* field number		* '''field number'''
	* key		** +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 ([[User:cmbarton\|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 ([[User:cmbarton\|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 ([[User:micha\|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.		** +1 ([[User:micha\|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.
	* keyfield		** +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.
	* table link		* '''keyfield'''
	* category set		** -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 ([[User:Landa\|ML]])		** +1 ([[User:Landa\|ML]])
	** +1 - in light of my above remark this seems to be the most general term (Moritz)		** +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?''"

	== See also ==		== See also ==

⚠️HamishBowman: /* See also */

2010-01-05T17:48:09Z

← Older revision		Revision as of 12:44, 22 May 2011
Line 49:		Line 49:
	* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]		* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]
	* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].		* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].
			* [http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Renamedoptions GRASS 6 -> 7 renamed parameter options]
	* [http://trac.osgeo.org/grass/wiki/MessageStandardization GRASS Message Standardization]		* [http://trac.osgeo.org/grass/wiki/MessageStandardization GRASS Message Standardization]
	* [http://www.opengeospatial.org/standards OGC standards]		* [http://www.opengeospatial.org/standards OGC standards]

← Older revision		Revision as of 19:22, 26 July 2010
Line 49:		Line 49:
	* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]		* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]
	* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].		* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].
			* [http://trac.osgeo.org/grass/wiki/MessageStandardization GRASS Message Standardization]
	* [http://www.opengeospatial.org/standards OGC standards]		* [http://www.opengeospatial.org/standards OGC standards]
	* [http://www.lib.unc.edu/reference/gis/datafinder/glossary.html GIS DataFinder]		* [http://www.lib.unc.edu/reference/gis/datafinder/glossary.html GIS DataFinder]

← Older revision		Revision as of 17:48, 5 January 2010
Line 38:		Line 38:
	* http://lists.osgeo.org/pipermail/grass-dev/2008-August/039277.html		* http://lists.osgeo.org/pipermail/grass-dev/2008-August/039277.html
	* [http://grass.osgeo.org/gdp/html_grass5/terminology.html GRASS 5 terminology]		* [http://grass.osgeo.org/gdp/html_grass5/terminology.html GRASS 5 terminology]
			* [[GRASS 6 Terminology]]
	* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]		* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]
	* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].		* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].