Naming Conventions - ObjectVision/GeoDMS GitHub Wiki

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 the logic and maintainability of your model. Therefore, we advise you to consider your tree item names; avoid using abstract variable names like 'a', 'b', 'c', or 'var1', 'var2', or 'var3'.

Tree item names are case-insensitive with regard to the normal (i.e. A..Z) letters; however, 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.

• 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 when the tree item names consist only of numeric characters. The following 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 redundant with the parent container name. Tree item names, such as 1990, 2000, and 2010, are, however, not valid tree item names (since they start with a number). 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 data after the underscore _ indicates a further specification or limiting condition. In the absence of alternatives, a liberal approach is permitted, 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 following 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 add 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.

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 various containers, often referred to as Units, Classifications, and Geography.

• 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, such as square meters, from base units with expressions.
• Use the following naming conventions for SI units and factors:

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

• Configure class units in a Classifications container.
• Use the NrOfRows property to indicate the number of classes.
• As sub-items 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 receives a value of 0, the second class receives a value of 1, and so on.

For classified data, no class item needs to be configured (e.g. 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 value unit of this Label item is a string value 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 : [rgb(128,255,0),rgb(0,128,0),rgb(0,64,128),rgb(255,0,0)], DialogType = "SymbolColor";

This item configures the colours used for each class. Please review the visualisation style for the possible style items.