logo-header

 
 

Introduction:

This document describes naming conventions for writing GeoDMS configuration files. The conventions are often not binding, the GeoDMS will not generate syntax errors if the conventions are not complied with. It is however strongly recommended to follow the conventions for reasons of clarity and uniformity, which makes it easier to support multiple users.

General:

  1. Limit the length of tree item names: Use the label, description or url property for longer names and/or extra descriptions and prevent redundance in naming of tree items (see 2).
  2. Prevent redundance in full tree item names: An item is defined by it's full name (starting from the root) and not only by the direct name in it's parent container. Don't absorb information in a name which is already configured in direct or indirect parent items. The next example illustrates this:
    container InhabitantsPerRegion
    {
    container Year1999
    {
    attribute<nrInhabitants> InhGroningen1999 (region);
    attribute<nrInhabitants> InhFriesland1999 (region);
    attribute<nrInhabitants> InhDrenthe1999 (region);
    }
    }
    In this example two types of redundances occur:
    • The charachters: Inh (number inhabitants) are part of each attribute name, but the same information is already available in the parent of the parent: InhabitantsPerRegion.
    • 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 pathname of the second attribute is now: InhabitantsPerRegion/Year1999/Friesland. This name contains all relevant and no redundant information.
    There is an exception to this rule, in case the tree item names would only consist of numeric characters. This occurs for example in a enumaration of types, like land use types. As tree item names may not only consist of numeric characters, some redundancy can not always be prevented. The next example illustrates this:
    container LandUse
    {
    attribute<ha> lu1 (Nl100mGrid);
    attribute<ha> lu2 (Nl100mGrid);
    attribute<ha> lu3 (Nl100mGrid);
    }
    The abbreviation lu means land use and is as so redundant with the parent container name. Tree item names 1,2,3 are however no valid tree item names, therefore this type of redundancy is acceptable.
  3. Name objects singular, e.g. airport in stead of airports and road in stead of roads.
  4. Use capitals for acronymes, e.g. NIP (for Nederland in Plannen).
  5. Use for abbreviation lower-case letters, e.g. ot for other and lu for lumos.
  6. Limit tree item names to the most relevant information, e.g.: heather instead of heathland.
  7. In conjunctions, name first the generic followed by more specific information, e.g.: agr_cattle, lu_labour_office. The information after the hyphen _ 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.
  8. Combinations of concepts can be combined in one name, e.g. SocCultural.

Units:

In a GeoDMS configuration three types of units are distinguished:

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

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

Quantity Units

  1. Configure quantity units in a units container, preferably as one of the first configured containers.
  2. Use as much as possible si units or monetary units as base units. Derive other units as square meter from base units with expressions.
  3. 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

  4. Use the prefix Nr for numbers, like NrInhabitants, NrResidences.
  5. Use the range property to specify the range of floating point units, if known and different from the default range of the value type,
    see value types for the range of the value types.
  6. Use the NrOfRows property to specify the range of integer units, if known.

Class Units

  1. Configure class units in a classifications container, in general after the units container.
  2. Use the NrOfRows property to indicate the number or classes.
  3. 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 need to be configured with the value: "Classification".
    An example of a ClassBreaks item for a class unit with 4 elements:
    attribute<m> ClassBreaks: DialogType = "Classification",
    [0,200,400,800];
    The values unit of this classes item (in the example m of meter) should correspond with the values unit of the data to be classified. For classified data no classes item need to be configured (think e.g. about region keys). The GeoDMS works zero based. A first class gets the value 0, the second class a value 1 etc. Configure, if necessary, an expression (e.g. with a rlookup) to transform a non zero based with one increasing class distribution to a distrubtion as used in the GeoDMS.

    - 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 configure with as value: "LabelText".An example of a Label item for a classe unit with 4 elements:

    attribute<string> Label: DialogType = "LabelText", 
    ['0 - 200','200 - 400','400 - 800','> 800'];
    The values unit of this Label item is of the string value type.

    - A set of possible style items for the visualisation of the classes in a map view. These are attributes configuring the color, symbolsize, pensize, penstyle and/or hatchingstyle for each class. An example of a style item for a class unit with 4 elements:

    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 colors for each class. See Modeller's Guide Chapter 8 Visualisation for the possible style items.

      Geographic Domains

      GeoDMS applications often have a spatial dimension. The data is analysed and presented at a specified spatial level (Europe, countries, regions). This spatial level is configured as a Geographic Domain.

      Geographic domains are usually configured in a seperate Geography container.

      For spatial data a distinction is made in four types:

      1. point locations: locations of capitols, houses etc.
      2. line(arcs): connections like roads, rail etc.
      3. area(polygonen): like countries, regions etc.
      4. griddata: in different gridsizes.

      The values units for these types of spatial data is of the value type:.

      • (s)(f)(d)(i)point for point locations and griddata (1 coordinate for each object)
      • (f)(d)arc for each arc (NYI), a collection of at least two coordinates, at the moment also (f)(d) polygon is used as data type, with as configured format property: Arcs.
      • (f)(d)polygon, a collection of at least three coordinates.

      OBJECT VISION BV
      Vrije Universiteit
      De Boelelaan 1085
      1081 HV Amsterdam
      The Netherlands

      tel: +31 (0)20 598 9083
      fax:+31 (0)20 598 9904