-
Notifications
You must be signed in to change notification settings - Fork 2
Waarom GeoDMS
RSopen is gebouwd in GeoDMS, een open-source platform voor grote ruimtelijke rekenmodellen. Die keuze is niet toevallig. De eisen die aan de RuimteScanner worden gesteld (landsdekkend rekenen op fijne resolutie, meerdere scenario's en varianten doorrekenen, en volledige controleerbaarheid van beleidsrelevante uitkomsten) zijn precies de punten waarop GeoDMS zich onderscheidt van modelbouw in een algemene scripttaal. Deze pagina zet op een rij wat het platform het model oplevert.
Het model rekent landsdekkend op gridcellen van 25 tot 100 meter, over meerdere zichtjaren, sequenties en iteraties (zie Tijdsdynamiek en Allocatie procedure in formules). Per variant gaan zo miljoenen tot tientallen miljoenen cellen vele malen door het allocatieproces. GeoDMS is hiervoor ontworpen: het rekent multithreaded en verdeelt grids automatisch in tegels (tiling), zodat niet alles tegelijk in het werkgeheugen hoeft te staan. Een volledige modelrun draait daardoor op een gewone werkplek, zonder cluster of rekenserver. Het concept CompactedDomain beperkt het rekenwerk verder tot de relevante cellen (zie Programmatuur en dataelementen van het model).
Alle resultaten in het model vormen samen een afhankelijkheidsboom, die GeoDMS lui evalueert: alleen de items die daadwerkelijk worden opgevraagd worden berekend, en binnen een sessie wordt niets dubbel gerekend. Daarnaast kent het model strategische ontkoppeling: stabiele tussenresultaten, zoals brondata en basedata die voor alle varianten gelijk zijn, worden eenmaal opgebouwd en weggeschreven, en daarna in elke run en elke variant hergebruikt (zie de Write-containers in Programmatuur en dataelementen van het model). Welke onderdelen ontkoppeld worden is in de configuratie zelf belegd, niet in losse scripts, en blijft daarmee zichtbaar en controleerbaar. Wijzigt de onderliggende data, dan wordt het betreffende deel bewust opnieuw weggeschreven; die stap is onderdeel van de werkwijze, geen verborgen automatisme.
Voor een model dat beleidsverkenningen voedt is navolgbaarheid een harde eis. In GeoDMS is elke kaart en elke indicator gedefinieerd als een formule op brondata en eerdere resultaten. In de GeoDMS GUI is die herkomst per item na te lopen, tot aan het bronbestand. De configuratie zelf is platte tekst en staat openbaar op GitHub: iedereen kan nalezen hoe een uitkomst tot stand komt, en elke wijziging is regel voor regel te volgen in het versiebeheer. Er zijn geen verborgen tussenstappen, handmatige bewerkingen of scripts die buiten beeld blijven.
Alle data-items in het model dragen een eenheid: hectares, woningen, euro's per vierkante meter. GeoDMS controleert bij het inlezen van de configuratie of formules qua eenheden kloppen. Hectares optellen bij euro's is geen stille rekenfout die pas bij de resultaten opvalt, maar een foutmelding vooraf. Hetzelfde geldt voor domeinen: een attribuut op gemeenteniveau kan niet per ongeluk gecombineerd worden met een attribuut op gridcelniveau, daarvoor is altijd een expliciete relatie nodig.
De GeoDMS GUI toont elk tussenresultaat als kaart of tabel, zonder export- of plotcode. Wie wil zien hoe de geschiktheid voor wonen is opgebouwd, of waar de zeefanalyse ruimte overlaat, klikt het betreffende item aan (zie Geschiktheid en Beschikbaarheid). Dat maakt modelontwikkeling, kalibratie en review veel sneller dan een cyclus van rekenen, exporteren en plotten, en het verlaagt de drempel voor anderen om kritisch mee te kijken.
GeoDMS en Python sluiten elkaar niet uit, maar de rolverdeling is bewust: de kern van het model staat in GeoDMS, Python komt aan de randen. Elke externe scriptstap midden in een rekenketen is voor de engine een black box: daar stoppen de eenhedencontrole, het luie rekenen en de herleidbaarheid, voor die stap en voor alles wat erop volgt. Aan de randen is Python juist sterk, bijvoorbeeld bij het schatten van modelparameters vooraf (zoals de hedonische prijsanalyses) of het maken van figuren en rapportages achteraf. De GeoDMS wiki beschrijft drie manieren om beide te combineren: Python dat de GeoDMS-engine aanstuurt, een GeoDMS-model dat Python-scripts op aanvraag uitvoert (met uitwisseling via parquet-bestanden), en de geodms-module die de engine binnen Python beschikbaar maakt. Voor het rekenhart van het model (de allocatie, het geheugenbeheer en de herleidbaarheid van elke uitkomst) biedt GeoDMS infrastructuur die anders in Python zelf gebouwd en onderhouden zou moeten worden. Wie vanuit pandas denkt, vindt op de GeoDMS wiki een vertaaltabel van begrippen.
- Why GeoDMS op de GeoDMS wiki, met het volledige betoog
- GeoDMS Academy voor hands-on tutorials
- Programmatuur en dataelementen van het model over de opbouw van RSopen in GeoDMS
- Installatie tutorial om zelf met het model aan de slag te gaan
Object Vision B.V.
Deel I — Wat is het model?
Deel II — Hoe werkt het model?
- Tijdsdynamiek
- Startstaat (basisjaar)
- Beschikbaarheid
- Geschiktheid
- Dichtheid
- Allocatie procedure in formules
- Uitwerking wonen
- Uitwerking werken
- Uitwerking overige sectoren
- Uitwerking waterberging
- Uitwerking landbouw
- Landgebruikskaart
- Effectmodules en indicatoren
Deel III — Toepassingen
Deel IV — Overig