IS
.O
O
IO
Ti.®
4
li Api
6
Geo-Info I 2018-6
ces en data, via een centraal stelselknooppunt.
In het DSO Ontwikkelaarsportaal [7] staan de
eerste resultaten klaar om gebruikt te gaan
worden. Hierdoor kunnen leveranciers hun
applicaties straks verbinden met het DSO.
Hier onder wordt verder ingegaan op de
manier waarop geo-informatie naar DSO
wordt gebracht en door DSO naar gebruikers
wordt ontsloten.
Informatiekundige architectuur DSO
Het DSO is op informatiekundig niveau vooral
een stelsel van afspraken rondom lokale en
landelijke voorzieningen. Binnen dit zoge
naamde afsprakenstelsel kunnen deelnemers
aansluiten in de rol van aanbieder of afnemer.
Voor beide rollen gelden aansluitvoorwaarden
die afhankelijk zijn van het soort dienst en het
gewenste dienstverleningsniveau.
Om te zorgen dat we functionaliteit slechts
één keer realiseren en flexibel inzetbaar
maken, hanteren we 'alles is een service' als
leidend principe. Technisch gezien worden
services beschikbaar gesteld als API's, die
we bewust op het niveau van gebruikers
interfaces voor softwareontwikkelaars
positioneren. Bovendien maken we hierbij
geen onderscheid tussen interne en externe
ontwikkelaars. Het stelsel zal op deze manier
tientallen API's beschikbaar stellen die vaak
in samenhang door één afnemer worden
gebruikt. Dit perspectief is weergegeven in
figuur 2.
Afnemer
1 1 API I
rV.\—'v.r-TA|
i a pi
Stelselknooppunt DSO
API
Aanbieder 1
I Aanbieder
Figuur 2 - Perspectief op het DSO voor een afnemer
van API's.
Een DSO-brede implementatiestrategie moet
zorgen voor consistentie en herkenbaarheid
op twee niveaus. Zo moet de DSO API strate
gie [8] zorgen voor RESTful API's, die uniform
zijn opgezet en gedocumenteerd. RESTful
staat voor Representational State Transfer, een
architectuurstijl voor API's op basis van HTTP
die is bedacht door Roy Thomas Fielding.
Daarnaast moet de DSO URI strategie [9] er
voor zorgen dat alle API's uniform identifi
ceerbaar zijn en dat we deze via een centraal
stelselknooppunt beschikbaar kunnen stellen.
Uiteraard doen we dit om de drempels zo laag
als mogelijk te houden. Voor externe afnemers
(derden) zijn de API's beschikbaar via het Open
Stelsel voor Derden. Voor alle open API's is
er een basisniveau zonder garanties en een
'fair-use policy'.
Maar voor er kan worden ontsloten, moe
ten gegevens eerst worden aangeleverd.
Dit wordt hieronder nader toegelicht.
Aanleveren van geografische informatie
aan DSO
Overheden moeten hun officiële omgevings
wetbesluiten publiceren. Dit doen ze straks
via het platform voor overheidspublicaties:
de Landelijke Voorziening Bekendmaken en
Beschikbaar stellen (LVBB). De besluiten die
overheden publiceren komen, worden via dit
platform als omgevingsdocumenten doorge
leverd aan het DSO. Het uitwisselformaat met
de LVBB is op een aantal punten afwijkend
met het welbekende IMRO-formaat [10], dat als
een voorloper van de omgevingswetbesluiten
kan worden beschouwd:
we gaan planteksten en plangeometrieën
bundelen in één XML-uitwisselformaat;
plangeometrieën zijn geen GML feature
collection meer, maar bevatten alleen een
opsomming van geometrieobjecten;
een nieuw gegevenselement legt de
verbinding tussen tekst en geometrie;
technisch gezien zijn deze verbindingen
onderdeel van de tekst;
tekstobjecten en geometrieobjecten heb
ben een versie: bij wijziging worden niet
meer gehele omgevingsdocumenten aan
geboden, maar alleen gewijzigde objecten,
conform een mutatiesystematiek.
Voor bevoegde gezagen en hun (geo-)
ICT-leveranciers zal vooral het objectgericht
muteren de nodige gevolgen hebben. Er zijn
al proeven gestart met deze systematiek,
onder andere door middel van mapping
vanuit bestaande software. Uiteindelijk is
de modelmatige opbouw van de bronge-
gevens een belangrijke ontwerpcriterium
voor beheersystemen. Het is daarom van
belang om nu iets te zeggen over de gekozen
objectoriëntatie.
Objectoriëntatie
Een basisconcept in elke RESTful API is de
resource. Een resource is een object met een
type, bijbehorende data, relaties met andere
resources en een aantal operaties om deze te
bewerken. Resources worden aangeduid met
zelfstandige naamwoorden die gegeven het
domein, relevant zijn vanuit het perspectief
van de afnemer van de API. Enkele relevante
voorbeelden van resource-collecties uit het
omgevingswetdomein zijn: activiteiten, regels
en locaties. In de API-strategie is bepaald dat
objecten primair in de vorm van JSON [11]
worden uitgewisseld. In aanvulling hierop
passen we HAL [12] toe om te navigeren tussen
sub-collecties en sub-resources. Een concrete
toepassing van hypermedia in de DSO API's
wordt weergeven in figuur 3.
Waarom deze opzet? De activiteit zoals hier
is gedefinieerd is niet de regel zelf. De regel
beschrijft wat er juridisch geldt voor de acti
viteit of activiteiten. Omdat aan een activiteit
ook een locatie wordt toegekend, kan voor
iedere locatie worden bepaald welke regels
gelden voor een bepaalde activiteit.
Omdat we alle objecten primair in de vorm
van JSON uitwisselen, is de geografische
informatie ingebed in het locatieobject.
Binnen dit object passen we GeoJSON [13] toe
om gestandaardiseerd een breed scala aan
geometrieën te kunnen ondersteunen. Geo
JSON biedt ondersteuning voor 2D en 2DD
door het opnemen van een elevatie. Omdat
de geografische informatie altijd is ingebed
als een los object, behoort ook uitbreiding
naar 3D tot de mogelijkheden. Een geschikte
representatie hiervoor is nog niet bepaald.
Een ander belangrijk aspect in deze context
is het feit dat er geen sprake is van een vast
coördinaatreferentiesysteem (CRS). In plaats
daarvan dient bij iedere API-aanroep expliciet
te worden aangegeven in welk CRS de vraag
wordt gesteld, maar ook hoe het antwoord
wordt verwacht. In beide gevallen zijn de
opties: RD, ETRS89 en WGS84. Hierdoor kan
dus een vraag worden gesteld in RD en het
antwoord worden ontvangen in ETRS89.
Van API tot dienst
De hier gepresenteerde API's staan aan de
basis van de dienstverlening van het DSO.
De overheid is verantwoordelijk voor de
wettelijk bepaalde functionaliteit. Een open
community is nodig om de functionaliteit van
het DSO te verbreden. Welke ontwikkelaars
met de API's en data zullen werken, is onbe-
