Bij het Kadaster Dataplatform volgen we de DSO API Strategie als het gaat om gebruik van GeoJSON. Hoewel GeoJSON een eigen application/geo+json
mimetype kent gebruiken we GeoJSON enkel ‘embedded’, dus we volgen de GeoJSON structuur voor een property dat een geometrie is. Zo kun je op dezelfde manier ook niet-geodata ontsluiten. GeoJSON kent zelf bijvoorbeeld properties (waar je bijvoorbeeld ‘bouwjaar’ in kwijt zou kunnen) maar in feite zegt ‘bouwjaar’ niets over de geometrie, wel iets over een pand. Voorbeeld in application/json
:
{
"bouwjaar": 1932,
"geometrie": {
"type": "Point",
"coordinates": [
46.05468749999999,
62.75472592723178
]
}
}
En in application/hal+json
:
{
"bouwjaar": 1932,
"geometrie": {
"type": "Point",
"coordinates": [
46.05468749999999,
62.75472592723178
]
},
"_links": {
"self": {
"href": "https://...."
},
"next": {
"href": "https://....?page=2"
}
}
}
Zo kunnen we ook gewoon hypermedia controls van (in dit geval) HAL gebruiken om te navigeren (bijvoorbeeld naar de volgende pagina). Bovendien zijn er ook resources met meerdere geometrieën, zoals ‘vlakGeometrie’ en ‘lijnGeometrie’ bij een ‘wegdeel’ wat met standaard GeoJSON als meerdere features gezien zou worden, terwijl het toch maar om 1 wegdeel gaat.
Wat betreft de gekozen CRS is volgende mij de conclusie van de laatste versie dat GeoJSON hier helemaal niets meer over zegt, het zegt enkel iets over de structuur van het GeoJSON object en de bijbehorende coördinaten. Of dit WGS84 of iets anders is moet op een andere manier kenbaar gemaakt worden. Hier zijn hevige discussies over maar omdat wij geen tijd hebben om daarop te wachten hebben wij een Content-Crs
header in het leven geroepen die aangeeft welke CRS gebruikt wordt in de response of in de request, voor het geval een client een geometrie naar de server stuurt (bijvoorbeeld om alle panden binnen een bepaald gebied te krijgen). Hiermee hebben we gelijk een Accept-Crs
request header geïntroduceerd welke een client kan gebruiken om aan te geven welk CRS hij terug wil hebben. Zie hiervoor onder andere https://github.com/w3c/dxwg/issues/311 waar ook ik en @brinkwoman in verwikkeld zijn
Een issue waar we nog wel mee zitten is de precisie van de coördinaten, zoals @thijsbrentjens ook terecht aangeeft. Er zijn manieren om deze te simplificeren door het aantal decimalen te beperken en/of door coordinaten weg te halen zodat je als het ware ‘uitzoomt’, maar dan loop je het gevaar dat sommige geometrieën niet meer valid zijn en bovendien - wat in ons geval nogal belangrijk is - niet meer rechtsgeldig.