logo-header

 
 

Inleiding:

Dit document beschrijft naamgeving conventies voor het schrijven van GeoDMS configuratiebestanden. De conventies zijn veelal niet dwingend, dat wil zeggen dat de GeoDMS ze niet hard afdwingt (het niet naleven leidt meestal niet tot syntax fouten). Het is echter sterk aan te raden de conventies zoveel mogelijk te volgen met het oog op de helderheid, overzichtelijkheid en overdraagbaarheid van GeoDMS configuraties.

Algemeen:

  1. Beperk de lengte van tree item namen: Gebruik het label, description of url property voor langere namen en/of extra beschrijvingen en voorkom redundantie in naamgeving (zie 2).
  2. Voorkom redundantie in volledige tree item namen. Een item wordt gekenmerkt door zijn volledige naam (vanaf de root) en niet alleen door zijn directe naam binnen zijn parent container. Neem geen informatie in de directe naam op die ook al uit de parent container(s) volgt. Het volgende voorbeeld illustreert dit:
    container InwonersPerProvincie
    {
    container Jaar1999
    {
    attribute<nrInwoners> InwGroningen1999 (provincie);
    attribute<nrInwoners> InwFriesland1999 (provincie);
    attribute<nrInwoners> InwDrenthe1999 (provincie);
    }
    }
    In het voorbeeld komen twee vormen van redundantie voor.
    • De attribuutnamen bevatten de informatie dat het om Inwoners gaat, dit blijkt ook al uit de containernaam: InwonersPerProvincie.
    • Het jaartal 1999 wordt in iedere attribuutnaam herhaald.
    De te prefereren configuratie is :
    container InwonersPerProvincie
    {
    container Jaar1999
    {
    attribute<nrInwoners> Groningen (provincie);
    attribute<nrInwoners> Friesland (provincie);
    attribute<nrInwoners> Drenthe (provincie);
    }
    }
    De volledige padnaam van het  tweede attribuut is nu: InwonersPerProvincie/Jaar1999/Friesland. Deze naam bevat alle relevante en geen dubbele informatie.
    Op deze regel bestaat een uitzondering, namelijk indien de directe tree itemnamen alleen uit numerieke karakters zouden gaan bestaan. Dit komt bijvoorbeeld voor bij opsomming van typen, zoals grondgebruikstypen: Omdat een tree item naam niet alleen uit numerieke karakters mag bestaan, is hierbij enige redundantie moeilijk te voorkomen. Het volgende voorbeeld illustreert dit:
    container GrondGebruik
    {
    attribute<ha> gg1 (Nl100mGrid);
    attribute<ha> gg2 (Nl100mGrid);
    attribute<ha> gg3 (Nl100mGrid);
    }
    De afkorting gg staat voor grondgebruik en is dus redundant met de containernaam. Tree item namen 1,2,3 zijn echter geen geldige tree item namen, vandaar dat deze vorm van redundantie aanvaardbaar is.
  3. Benoem objecten in enkelvoud, bijvoorbeeld vliegveld i.p.v. vliegvelden en weg i.p.v. wegen.
  4. Gebruik voor acroniemen(veelgebruikte verbindingen) hoofdletters, bijvoorbeeld NIP (voor Nederland in Plannen).
  5. Gebruik voor afkortingen kleine letters, bijvoorbeeld ov voor overig en gg voor grondgebruik.
  6. Beperk tree item namen tot meest zinvolle informatie en neem geen informatie op die uit context volgt, bijvoorbeeld: spoor i.p.v. spoorlijn, heide i.p.v. heidegebied.
  7. In samenstelingen, eerst algemene dan specifieke informatie, bijvoorbeeld: agr_vee_grondgeb, gg_werk_kantoor. De informatie na het koppelteken _ geeft een nadere specificatie of beperkende conditie aan. Indien geen alternatieven aanwezig zijn, is een liberale benadering mogelijk, bijvoorbeeld: nat_hoogveen ipv nat_veen_hoog. Als alternatief mag de reeks tot aan de eerste combinatie ook samengesteld worden door de eerste met kleine letter en de volgende elementen met hoofdletter, voorbeelden: ggModel, ggRB, ggLumos.
  8. Combinaties in begrippen aan elkaar schrijven, met Hongaarse hoofdletters, bijvoorbeeld: SocCultureel, AkkerTuin.

Eenheden:

Globaal worden in een GeoDMS configuratie drie typen eenheden onderscheiden:

  • Quantity units voor hoeveelheden, zoals meter, euro etc.
  • Class units voor geclassificeerde(zoals bodemtype, provincienummer) of te classificeren data.
  • Geografische domeinen als Gemeente of NlGrid100m.

Deze verschillende type eenheden worden in verschillende containers, meestal direct onder de root container, geconfigureerd en kennen hun eigen naamgevings conventies:

Quantity Units (eenheden die een hoeveelheid aangeven)

  1. Configureer quantity units in een units/eenheden container direct onder de root, liefst als een van de eerste containers.
  2. Gebruik zoveel mogelijk si eenheden of monetaire eenheden als base units, leidt afgeleide eenheden als vierkante meter hier via expressies vanaf.
  3. Gebruik de volgende naamgeving voor si eenheden en factoren:

    Grootheid

    Eenheid

    Symbool

    Lengte

    meter

    m

    Massa

    kilogram

    kg

    Tijd

    seconde

    s

    Elektrische stroom

    ampere

    A

    Temperatuur

    kelvin

    K

    Hoeveelheid stof

    mol

    mol

    Licht intensitiet

    candela

    cd


    Factor

    Naam

    Symbool

    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. Gebruik de prefix Nr voor 'metriek loze' aantallen, zoals NrInwoners, NrWoningen.
  5. Gebruik het range property voor het specificeren van de range van floating point units indien bekend en afwijkend van de default range van het value type,zie value types voor de range van de value types.
  6. Gebruik het NrOfRows property voor het specificeren van de range van integer units, indien bekend.

Class units (eenheden voor klassewaarden)

  1. Configureer klasse eenheden in een classifications/klassificaties container, onder de root en meestal direct na de units/eenheden container.
  2. Gebruik het NrOfRows property om het aantal klassen aan te geven.
  3. Bij een klasse eenheid worden vaak de volgende attributen geconfigureerd:
    - Een ClassBreaks item, met de klassengrenzen vertaald naar klassennummers. Het DialogType property voor dit attribuut dient te worden geconfigureerd met de waarde: "Classification". Een voorbeeld van een Classes item voor een Klasse eenheid met 4 elementen:
    attribute<m> Classes: DialogType = "Classification", 
    [0,200,400,800];
    De values unit van dit ClassBreaks item (in het voorbeeld m van meter) dient overeen te komen met de values unit van de te classificeren data items. Voor reeds geclassificeerde data hoeft geen classes item geconfigureerd te worden (denk bijvoorbeeld aan provincie nummers). De GeoDMS werkt zero based werkt, de eerste klasse krijgt altijd waarde 0, een tweede waarde 1 en zo oplopend. Configureer eventueel een rekenregel (bijvoorbeeld via een rlookup) om een niet zero based, of een niet met 1 oplopende klasse indeling om te zetten naar een in binnen de GeoDMS gebruikte klasse waarde,

    - Een Label item, met de voor de klasse gebruikte labels (in de legenda van de map view en in de tabelweergave). Het DialogType property voor dit attribuut dient te worden geconfigureerd met als waarde: "LabelText".
    Een voorbeeld van een Label item voor een Klasse eenheid met 4 elementen:

    attribute<string> Label: DialogType = "LabelText", 
    ['0 - 200','200 - 400','400 - 800','> 800'];
    De values unit van dit Label item is van type string.

    - Een set van mogelijke stijl items voor de visualisatie van de klassen in een map view. Het betreft attributen die kleur, symboolgrootte, lijndikte, lijnstijl en/of hatchingstyle per klasse configureren. Een voorbeeld van een stijl item voor een Klasse eenheid met 4 elementen:

    attribute<uint32> SymbolColor: DialogType = "SymbolColor",
    [rgb(128,255,0),rgb(0,128,0),rgb(0,64,128),rgb(255,0,0)];
    Dit item configureert de te gebruiken symbool kleuren voor iedere klasse. Zie Modellers Guide Chapter 8 Visualisation voor de verschillende mogelijke stijl items.

3. Geografische domeinen

Veel van de toepassingen van de GeoDMS hebben een ruimtelijke dimensie.
Data wordt geanalyseerd en gepresenteerd op een bepaald ruimtelijk niveau (Europa, landen, regios). Zo'n ruimtelijk niveau wordt geconfigureerd als een ruimtelijk domein.

Geografische domeinen worden in een aparte Geografie container geconfigureerd.

Bij ruimtelijke data wordt een onderscheid gemaakt worden in 4 typen:

  1. punt lokaties: lokaties van hoofdsteden, woningen etc.
  2. lijn: verbindingen(arcs) zoals wegen, spoor etc.
  3. gebied: zoals landen(polygonen), provincies etc.
  4. griddata: in verschillende gridgroottes

De values units voor deze type ruimtelijke data is van type:

  • (s)(f)(d)(i)point voor puntlokaties en griddata (1 coördinaat voor ieder object)
  • (f)(d)arc voor iedere arc (NYI), een verzameling van tenminste twee coördinaten, momenteel wordt hier ook (f)(d) polygoon als data type voor gebruikt, met als geconfigureerd format property: Arcs.
  • (f)(d)polygoon, een verzameling van ten minste drie coördinaten.
    Deze values units worden meestal ook in een Geografie container geconfigureerd.

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