SPECIAL
De oorsprong van RD
ligt niet in NL maar in F
2013-8/9 Geo-lnfo
19
in de provincie Noord-Holland. Daarmee
konden mensen zien welke zwem locaties
gecontroleerd worden door de provincie, wat
het resultaat van de laatste controle was, en
welke faciliteiten aanwezig zijn. Deze data werd
door de provincie in eerste instantie ontsloten
in de vorm van een Shape-bestand. Nu hebben
Shape-bestanden zo hun bijzonderheden,
maar ze zijn wel dusdanig gangbaar, dat ook
hiervoor in allerlei talen al implementaties
bestaan. Daarmee zijn we er echter nog niet: in
het Shape-bestand staan namelijk allerlei rare
coördinaten, die toch echt niet binnen Noord-
Holland liggen. Na behoorlijk wat zoeken blijkt
wat het probleem is: er zijn talloze andere
manieren dan WGS84 om locaties op een kaart
te markeren. Voor u als lezer is dat waarschijnlijk
volledig vanzelfsprekend. Voor een ontwikkelaar
wiens geo-ervaring beperkt is tot het uitlezen
van een GPS en het plotten van locaties op
Google Maps, is dit volledig nieuw. Dat is de
hoeveelheid geo-ervaring van de meeste web-
en app-ontwikkelaars, zoals twee jaar geleden
die van mij. Veel van mijn collega's weten niet
eens dat ze veelal gebruik maken van WGS84: zij
omschrijven het puurals"gewoon een normale
lengte- en breedtegraad", want dat zijn de twee
velden die ze zoeken.
Met de kennis dat het hier gaat om een ander
coördinatenstelsel, zijn we al een stuk dichter
bij het begrijpen van het Shape-bestand met
zwemwaterinformatie van de provincie. Het
gaat in dit geval om het Nederlandse Rijks-
driehoeksstelsel. Maar je komt op je zoektocht
termen tegen als"Rijksdriehoeksmeting", "RD-
coördinaten","RDNAP","RD-kaartcoördinaten",
"Amersfoortcoördinaten"of simpelweg "RD",
wat het vinden van goede informatie hierover
niet makkelijker maakt.
Opmerkelijk is ook, dat 0,0 in Rijksdriehoeks-
coördinaten helemaal niet in Nederland ligt,
maar in een weiland ergens in Frankrijk, en
ook niet het referentiepunt is. Hiermee wil ik
niet suggereren dat RD een slecht stelsel is, of
dat het verkeerd is dat overheden hier gebruik
van maken; voor de geo-expert zijn er talloze
goede redenen om gebruikte maken van RD.
Maar voor ontwikkelaars die voorheen alleen
bekend waren met lengte- en breedtegraden,
is het met al deze bijzonderheden bij elkaar
een behoorlijke omschakeling.
Eenmaal bekend met de RD-coördinaten,
rest ons nog maar een stap voor we mensen
kunnen helpen om te weten waar ze veilig
kunnen zwemmen: de omzetting naar WGS84.
Dit is meestal het punt waar sommige geo-
experts gaan sputteren: naar ik mij heb laten
vertellen kan dit namelijk onnauwkeurigheid
in de locaties introduceren. Echter, de realiteit
is dat de eenvoudig integreerbare kaarten
allemaal WGS84-coördinaten verwachten,
en ik mij daar dus aan zal moeten confor
meren. En voor de meeste toepassingen die
ontwikkelaars op open data ontwikkelen, zal
een onnauwkeurigheid van een paar meter
geen groot bezwaar zijn. Maar, waar Shape-
bestanden nog gangbaar genoeg zijn om
in vrijwel elke programmeertaal makkelijk
te verwerken, geldt dat helaas niet voor het
RijksdrehoeksstelseIwat immers puur een
Nederlands systeem is. De talloze verschillende
namen voor dit stelsel helpen hier ook niet bij,
en zelfde omrekening doen is ook niet triviaal.
Uiteindelijk blijkt dat er voor een vergelijkbare
programmeertaal ergens een implementatie
te vinden is, die ik aan heb kunnen passen
voor mijn toepassing.
API's zijn krachtiger,
maar niet makkelijker
Ook hiermee zijn we er echter nog niet. Het
Shape-bestand was slechts een eenmalige
publicatie. Voor actuele data - wel zo handig
in het geval van zwemwaterveiligheid - word
ik verwezen naar de ArcGIS REST API van de
provincie, waar ook al diverse andere open
data terug te vinden is. Deze API wekt de
suggestie, dat er echt actuele data uit op te
halen is, maar ondanks fervent zoekwerk lukt
het mij niet om hier enige data uit te halen.
De oplossing die ik een tijd later bij toeval
ontdek, blijkt teleurstellend eenvoudig te zijn:
ik moet bij queries altijd een zoekparameter
opgeven, al is het maar 'i==V. Anders komt
er simpelweg geen data uit de query, en geen
bruikbare foutmelding. Eenmaal wetende hoe
ik hier enige data uitkrijg, en met mijn vorige
ervaringen in het achterhoofd, werkt dit eigen
lijk prima. Het blijkt zelfs dat ik al op kan geven
dat ik antwoorden in WGS84 wil, waardoor ik
de conversie niet meer zelf hoef uit te voeren.
Uiteindelijk is het mij dus gelukt om deze
dataset te verwerken in mijn app, op Apple
en Google Maps-kaarten. Eenvoudig was
het echter absoluut niet, en dat is jammer,
want naar mate het moeilijker is om de data
te verwerken zal er minder hergebruik van
open data zijn. Hoe kunnen we dit verbeteren,
zonder dat de overheden allemaal met WGS84
moeten werken, en zonder dat de overheid
een geo-helpdesk wordt?
Maar, het is toch eigenlijk
heel eenvoudig?
Wanneer geo-experts mijn verhaal horen, krijg
ik soms verbaasde tot zelfs cynische reacties.
Zo moeilijk is het immers niet. Natuurlijk
gebruikt de overheid RD-coördinaten. Wat
zouden ze anders moeten gebruiken? Die
coördinaten worden opgegeven in meters
en lopen simpelweg van -7 tot 300 km op
de x-as, en van 289 tot 629 km op de y-as, en
Amersfoort ligt ongeveer in het midden op
155,463 km. En conversie naar WGS84 waar
nodig is triviaal: je neemt software zoals
PROJ.4, zoekt de EPSG-nummers van Amers
foort RD New, en WGS84, en converteert.
Met een ArcGIS REST API is dit allemaal nog
eenvoudiger, dan wordt de conversie voor je
gedaan. Een kind kan de was doen.
Eenvoudig als het allemaal is voor de expert,
is dit volledig anders voor iemand die nieuw is
op het gebied van geodata. Het is als nieuwe
ling veel moeilijker om de juiste referenties te
vinden, die er vast wel gewoon zijn voor deze
informatie. Op het moment dat er iets misgaat,
is het veel moeilijker om te bepalen wat het
probleem kan zijn. Die uitdagingen zijn niet
uniek voor geodata. Dit geldt voor vrijwel elk
expertisegebied, en vooral in combinatie kun
nen ze een hoge drempel opwerpen. Voor mij
is dit inmiddels een minder groot probleem,
en ik ken inmiddels ook wel geo-experts die
mij waarschijnlijk graag helpen, maar daar
hebben alle andere (potentiële) hergebruikers
heel weinig aan.
Domeinkennis hoeft
geen drempel te zijn
Bij andere databronnen en -formaten kunnen
dit soort problemen ook spelen. De brandweer
Amsterdam heeft in het verleden een realtime
linked datafeed gepubliceerd van alle brand
weermeldingen, waarop queries gedaan kun
nen worden met SPARQL. Ook dat was nieuw
voor mij. Aangezien het nog erg zeldzaam is dat
