GML.Next: hoe zet je JSON/GeoJSON in als lichter alternatief voor online toepassingen?

We zijn op zoek naar best practices, ideeën en opmerkingen voor de inzet van JSON/GeoJSON als lichter alternatief voor GML voor bulk downloads van data. Wie heeft dit al goed draaien? Waar moet je zeker aan denken als je dit wilt uitrollen / standaardiseren? In andere woorden: hoe doe je dit zo interoperabel mogelijk? Moeten we een soort referentie-implementatie aanbieden? Wat kan Geonovum doen om JSON/GeoJSON succesvol als alternatief naast GML te positioneren?

Dit topic starten we n.a.v. de 1e sessie van GML.Next op 17 juli, lees hier het verslag!

2 likes

Veel online toepassingen gebruiken GeoJSON al (ik heb er vele implementaties mee gedaan), er is zowel aan client- als serverkant ondersteuning voor in software pakketten en in (veelgebruikte) bibliotheken. Als er behoefte is aan een lijstje van tools die GeoJSON ondersteunen, wil ik best helpen. PDOK biedt bij de WFSen standaard ook al GeoJSON aan. Misschien is daar inzicht in het gebruik ervan?
Verder wat voorbeelden van data platformen waar GeoJSON data te vinden is als “bulk” download: https://dataplatform.nl, https://kaart.amsterdam.nl/datasets, https://data.overheid.nl/data/dataset?q=geojson

Ik heb niet het idee dat er veel aan moet gebeuren om GeoJSON echt interoperabel te maken. Er zijn wel wat generieke zaken om op te letten, die mede bepalen hoe eenvoudig de data te gebruiken is:

  1. Welk CRS gebruik je? GeoJSON zelf gaat uit van lat lon in WGS84. Hoewel het mechanisme voor aangeven van het CRS in de laatste versie van de GeoJSON specificatie is weggehaald, kan het nog wel gebruikt worden (ook volgens de spec RFC 7946 - The GeoJSON Format ). Veel geo-software ondersteunt het ook nog wel. (Zijstap: InformatieVlaanderen heeft hier ook discussie over gevoerd: Ondersteuning van GeoJSON · Issue #71 · Informatievlaanderen/OSLO-Discussion · GitHub)

  2. Ga je in 1 GeoJSON bestand meerdere “featuretypes” zetten? Volgens de spec kan je in 1 bestand namelijk prima meerdere featuretypes kwijt. Dat kan voor sommige datasets en toepassingen best relevant zijn. Voor het uitlezen van de data kan het weer wat ingewikkelder worden, maar sommige pakketten ondersteunen dit wel (zoals QGIS, GDAL/OGR).

  3. Het voorgaande geldt ook voor gebruik van meerdere geometrietypes.

  4. Net als bij GML: ga je geneste elementen gebruiken of houdt je een platte structuur aan? Ik denk dat er in het gebruik een sterke voorkeur is voor het tweede. Zo lang dat enigszins mogelijk is, zou ik dat gebruiken, maar nesting kan wel. Bij gebruik van geneste datastructuren is vaak wel maatwerk/extra programmeerwerk nodig om dat goed/mooi in te bouwen.

Wat kleinere dingen:

  1. aantal decimalen van coördinaten, om het een beetje compact te houden. Soms worden coördinaten op nanometers nauwkeurig uitgeleverd, wat onzinnig is

  2. om het voor implementaties door derden wat makkelijker te maken: praktische naamgeving van attributen (zijn het een beetje logische attribuutnamen?) en logische waardes meegeven, dus geen interne codes tenzij daar ook lijsten van gepubliceerd zijn.

Andere JSON formaten dan GeoJSON (ze zijn er vast) zou ik niet aanraden.

Wat misschien nog interessant is (maar nu niet gebeurt in de praktijk volgens mij): gebruik van JSON-LD context in GeoJSON. Vooral voor informatiemodellen kan dat een mooie toevoeging zijn, zodat er directe links in de data staan naar de definities.

1 like

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 :slight_smile:

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.

Dank voor deze info. Bij INSPIRE wordt er gekeken naar best practices voor GeoJSON. Deze info helpt al enorm en ik ga voorbeelden doorzetten naar die INSPIRE groep.

Zijn er voorbeelden van WFS met GeoJSON?

Paul

Klinkt goed. Heb je ook voorbeeld datasets? Dit voor gebruik als best practicevoorbeelden binnen INSIPRE werkgroep hierover.

Bijvoorbeeld de ruimtelijke plannen: https://rebilly.github.io/ReDoc/?url=https://data.informatiehuisruimte.nl/api/ruimtelijke-plannen/v1/#tag/Bestemmingsplangebieden/paths/~1bestemmingsplangebieden~1{id}/get

voorbeelden van wfs met geoJson output

https://geodata.nationaalgeoregister.nl/bag/wfs?request=GetFeature&service=WFS&typeName=bag:verblijfsobject&outputFormat=json&srsName=EPSG:4326&count=1&version=2.0.0

http://services.geodata-utrecht.nl/geoserver/w01_6_waterstaat/wfs?request=GetFeature&service=WFS&version=2.0.0&typeName=Veiligheid_regionale_waterkeringen_van_de_WVE&outputFormat=application%2Fjson&count=5

Wat betreft geoJson als json-ld, er is/was een initiatief GeoJSON-LD, maar ik begreep dat er een niet te overbruggen probleem zat in de combinatie van beide standaarden https://github.com/geojson/geojson-ld/issues/32 de laatste status weet ik niet

Naar mijn weten ontbreekt support voor crs in geojson omdat de standaard wgs84 afdwingt, een crs header toevoegen lijkt me dan niet handig. Maar inderdaad RFC 7946 - The GeoJSON Format stelt “However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.” Dus binnen de scope van een set afspraken rond de omgevingswet zou iets dergelijks alsnog kunnen werken. Ik kwam ook dit tegen: GitHub - opengeospatial/conneg-by-crs, blijkbaar gaan ogc en ietf samenwerken aan een content negotiation strategie voor crs, mogelijk kun je de omgevingswet ervaringen inbrengen als use case.

Ook goed om op te merken dat de huidige ter public review staande (op OAS/swagger gebaseerde) wfs 3 specificatie, geojson als een basis encoding (naast gml en html) opneemt. ogcapi-features/clause_8_encodings.adoc at master · opengeospatial/ogcapi-features · GitHub (zie CRS support beyond WGS84 lon/lat · Issue #65 · opengeospatial/ogcapi-features · GitHub voor crs in geojson discussie)

Hmm, crs en GeoJSON blijft een lastig iets. Voor onze terugmeldingen API hebben we ervoor gekozen om de crs op de ‘oude’ GeoJSON manier te ondersteunen (voordat het geschrapt werd…), omdat alle gegevens die we uitwisselen in RD zijn. Dus als volgt:

“crs”: {
“type”: “name”,
“properties”: {
“name”: “urn:ogc:def:crs:EPSG::28992”
}

Een moderne GeoJSON validator vindt het niet zo leuk, maar een pakket als QGIS snapt dit wel gewoon en pakt RD als coordinate reference system. Het zou wel fijn zijn als hier in Nederland een standaard aanpak voor kan worden gekozen, omdat onze oplossing en die van Dimitri dus al uit elkaar lopen.

CRS opnemen in de payload via de ‘oude’ GeoJSON standaard lost nog niet het probleem van CRS negotiation op. Daarmee bedoel ik dat er dan nog geen manier is om in je request aan te geven dat je eventuele geometrieën in een bepaald formaat terug wil hebben.

@brinkwoman weet hier meer van volgens mij :wink:

Een (output) CRS meegeven is in WFS 2 een standaard parameter. De vragende kant van CRS Negotiation wordt dan ook pas interessant als je het buiten de OGC standaarden trekt (of als nieuwe versies van de OGC standaarden meer de REST concepten gaan volgen).

Kwam dit tegen op twitter vanmorgen:
gRPC, an Alternative to REST in Geospatial APIs, mogelijk ook relevant hier.

Dat (coördinaten buiten OGC standaarden) doen we nu al voor de Digitaal Stelsel Omgevingswet API’s. Daar wordt voor alle data-uitwisseling gebruik gemaakt van REST API’s waardoor wij nu al een combinatie van JSON en GeoJSON gebruiken en daarbij ook behoefte bij gebruikers zien om aan te geven in welk stelsel ze coördinaten meegeven en in welk stelsel ze de coördinaten terug willen zien. Vandaar dat we dus al CRS negotiation hebben toegevoegd. Zie bijvoorbeeld de Ruimtelijke Plannen API van Informatiehuis Ruimte: https://data.informatiehuisruimte.nl/api/ruimtelijke-plannen/v1

1 like

Ik ken Jo (@jabhay op Github) die dit werk wil doen; maar heb al even niets hiervan gehoord. Ik hou het in de gaten!