Naming conventions

To make configurations clear (also for non-developers), maintainable, and transferable, it is strongly recommended that you follow the conventions when naming your tree items. Clear, meaningful and unambiguous naming of items in your model is essential for understanding your model’s logic and maintainability. Therefore, we advise you to think about your tree item names; don’t use abstract variable names like a, b, c or var1, var2, or var3.

tree item names are case insensitive with regard to the normal A..Z letters from the alphabet. Name names are case-sensitive for other characters, like the Greek alphabet (allowed since version 7.315). Use lowercases for keywords like container, attribute and unit.

The conventions are often not binding, and the GeoDMS will not generate syntax errors if the conventions are not complied with. See tree-item-name for the allowed syntax for tree item names.

general

  • Limit the length of tree item names: Use the label, description or URL property for longer names and/or extra descriptions and prevent redundancy in naming of tree items (see next dot).
  • Prevent redundancy in full tree item names: An item is defined by its full name, not only by the direct name in its parent container. Don’t absorb information in a name which is already part of a direct or indirect parent-item, see example:
container InhabitantsPerRegion
{
    container Year1999
    { 
        attribute<nrInhabitants> InhGroningen1999 (region);
        attribute<nrInhabitants> InhFriesland1999 (region);
        attribute<nrInhabitants> InhDrenthe1999   (region);
    }
}

In this example, two types of redundancies occur:

  1. The characters: Inh (number inhabitants) are part of each attribute name, but the number of inhabitants is already the name of an indirect parent.
  2. The year 1999 is repeated in each attribute name.

The preferable configuration is:

container InhabitantsPerRegion
{
    container Year1999
    { 
        attribute<nrInhabitants> Groningen (region);
        attribute<nrInhabitants> Friesland (region);
        attribute<nrInhabitants> Drenthe   (region);
    }
}

The full name of the second attribute is now InhabitantsPerRegion/Year1999/Friesland. This name contains all relevant and no redundant information.

The exception to this rule is the case where tree item names would only consist of numeric characters. The next example illustrates this:

container LandUse
{ 
   attribute<ha> lu1990 (Nl100mGrid);
   attribute<ha> lu2000 (Nl100mGrid);
   attribute<ha> lu2010 (Nl100mGrid);
}

The abbreviation lu means land use and is as redundant with the parent container name. Tree item names 1990, 2000, and 2010 are, however, no valid tree item names. This type of redundancy is acceptable.

  • Use the suffix: _rel in naming relations, e.g. region_rel as attribute name for the relation of a building to a region
  • Name objects singular, e.g. airport instead of airports and road instead of roads. And when you use a for_each to loop over a set, you can name it in a plural, e.g., Regios or PerRegio.
  • Use capitals for acronyms, e.g. NIP (for Nederland in Plannen)
  • Use for abbreviation lower-case letters, e.g. lu for land use
  • Limit tree item names to the most relevant information, e.g.: heather instead of heathland
  • In conjunctions, name first the generic followed by more specific information, e.g.: agr_cattle, lu_labour_office. The information after the underscore _ indicates a further specification or limiting condition. In case no alternatives are available, a liberal approach is allowed, e.g. wet_highpeatsoil or wet_peatsoil_high. As an alternative, the conjunction can also be composed with the first elements in lower-case letters and the next elements starting with a capital, e.g. luModel, luLumos
  • Combinations of concepts can be combined in one name, e.g. SocCultural.
  • Don’t use keywords like attribute, parameter, container, template, or unit for tree item names.
  • Don’t use composition type names: poly, polygon, arc for domain units.
  • Don’t use operators and functions names for templates.
  • Use informative names when naming a template: Just T does not tell a user what a specific template does. Describe it in a few words. And maybe add some more information using the Descr property.
  • Add the suffix _T to a template: Then, from reading the code, it is instantly clear that one is initiating a template.

units

In a GeoDMS configuration, three types of units are distinguished:

  1. Quantity units for quantity data items expressed in values units like meter or euro.
  2. Class units for classified data (like soil types or region keys) or for data to be classified.
  3. Geographical domains as municipality or NlGrid100m.

These different unit types are configured in different containers, often called Units, Classifications and Geography.

quantity units

  • Configure quantity units in a units container, preferably as one of the first configured containers.
  • Use as many SI units or monetary units as base units. Derive other units as square meters from base units with expressions.
  • Use the following naming conventions for SI units and factors:
Quantity Unit Symbol
Length meter m
Mass kilogram kg
Time seconde s
Elektric current ampere A
Temperature kelvin K
Qauntity matery mol mol
light intensity candela cd
Factor name Symbol
10-24 yocto y
10-21 zepto z
10-18 atto a
10-15 femto f
10-12 pico p
10-9 nano n
10-6 micro µ (mi)
10-3 milli m
10-2 centi c
10-1 deci d
101 deka da
102 hecto h
103 kilo k
106 Mega M
109 Giga G
1012 Tera T
1015 Peta P
1018 Exa E
1021 Zetta Z
1024 Yotta Y
  • Use the prefix Nr for numbers, like NrInhabitants, NrResidences.
  • Use the range property to specify the range of floating point units. If they are known and different from the default range of the value type, see value type for the range of the value types.
  • Use the NrOfRows property to specify the range of integer units, if known.

class units

  • Configure class units in a Classifications container.
  • Use the NrOfRows property to indicate the number or classes.

  • As subitems of a class unit, the following attributes are often configured:

  • A ClassBreaks item, with the class boundaries translated into class numbers. The DialogType property for this attribute needs to be configured with the value Classification. Example:
attribute<km> ClassBreaks: DialogType = "Classification", [0,200,400,800]; 

The values-unit of this class item (in the example km) should correspond with the values unit of the data to be classified. The first class gets the value 0, the second class a value 1, etc.

For classified data, no class item needs to be configured (think e.g. about region keys).

  • A Label item with the labels used for the classes (in the legend of the map view and in the table view). The DialogType property for this attribute should be configured with the value LabelText. Example:
attribute<string> Label: DialogType = "LabelText",
    ['0 - 200','200 - 400','400 - 800','> 800']; 

The values unit of this Label item is of the string values unit.

  • A set of possible style items for the visualisation of the classes in a map view. These are attributes configuring the visualisation styles for each class. Example:
attribute<uint32> SymbolColor: DialogType = "SymbolColor",
   [rgb(128,255,0),rgb(0,128,0),rgb(0,64,128),rgb(255,0,0)]; 

This item configures the used symbol colours for each class. See the visualisation style for the possible style items.