Hoe moeten we omgaan met complexe GeoJSON op het web?

Overig
#1

Met de ontwikkeling van de API’s voor data.pdok.nl lopen we tegen een functionele uitdaging aan m.b.t. het ontsluiten van GeoJSON in WGS84. De ‘payload’ van de response kan soms enkele MB’s groot zijn door complexe geometrieën in GeoJSON en dit is onacceptabel voor op het web. Dit komt door zowel veel decimalen per coördinaat als het aantal coördinaten zelf. Ik weet niet precies wat het praktische verschil is tussen beiden (verschil tussen precisie en zoomniveau ofzo?) maar wel dat we hiermee kunnen spelen. Ik ben benieuwd wat deze community hier nu eigenlijk van vindt!

Decimalen per coördinaat
De coördinaten zijn omgezet vanuit RD, waardoor we een nauwkeurigheid van 15 decimalen krijgen. Nu begrijp ik uit dit artikel (tnx voor de tip @emacgillavry!) dat dit gelijk staat aan een nauwkeurigheid van 0,1 nanometer (de grootte van een atoom) en dat deze precisie dus eigenlijk praktisch nergens op slaat. We zouden alle coördinaten kunnen afkorten tot 7 decimalen (cm) maar dan krijg je uiteindelijk neem ik aan wel afrondingsverschillen of kun je niet meer terug naar een andere stelstel? Een optie zou kunnen zijn om standaard ‘cm’ te hanteren en met een optionele parameter de gebruiker de nauwkeurigheid kunnen laten bepalen.

Aantal coördinaten
Ook hier ben ik benieuwd naar de term die hierbij hoort, maar een andere manier om de payload te verkleinen is het weghalen van een aantal coördinaten. Dit hangt echter wel af van het schaalniveau volgens mij: als je heel Nederland op de kaart hebt kun je best wat minuscule hoekjes weglaten, dat ziet een mens toch niet. Maar als er slechts 4 coördinaten zijn (ook al is dit een heel groot gebied dat heel Oost-Nederland beslaat) kan dit niet, want dan krijg je een driehoek. Kun je het ‘simplify’ algoritme toepassen op basis van het aantal coördinaten? En wat zou dan acceptabel zijn? Of ook hier default een algoritme toepassen en de gebruiken laten beslissen hoe ‘nauwkeurig’ (ben dus echt benieuwd naar het begrip dat hierbij hoort) hij/zij de response wil?

Zoekmachines
Eén van de dingen die we willen is dat zoekmachines de data gaan indexeren. Dit brengt echter wel tegenstrijdigheden met zich mee: als we alle decimalen en coördinaten behouden dan is de payload dusdanig groot dat een zoekmachine het niet leuk vindt en waarschijnlijk niet gaan indexeren, terwijl een geïndexeerde geometrie die niet 100% betrouwbaar is dus ook geen betrouwbaar antwoord kan geven op de eventuele vraag of ik op een bepaalde plek een brouwerij mag beginnen…

Ik ben zeer benieuwd naar jullie feedback en suggesties!

Groet, Dimitri

#2

Ha Dimitri, de titel van je post “Hoe moeten we omgaan met complexe GeoJSON op het web?” vind ik een beetje verwarrend, ik dacht dat je bedoelde “complexe geojson” als in “complexe GML” (appschema), echter appschema is by design niet compatible met geoJson. Maar met het lezen van je post begrijp ik dat je bedoelt: “hoe om te gaan met gedetailleerde geometrien op het web”. Het aantal decimalen betreft inderdaad de locatie nauwkeurigheid van de geometrie (blijkbaar soms tot op atoom niveau). Het aantal coordinaten bepaalt de complexiteit van het gevectoriseerde object.

Ik begrijp je uitdaging en het is een typisch schaal probleem waar de geo community (maar ook data met een temporele dimensie) eeuwig mee worstelt. De opslag van de geometrie is bij voorkeur in de hoogst haalbare nauwkeurigheid, echter in het vraag antwoord spelletje zou je het liefst een aggregatiefactor meegeven, zodat je nooit teveel detail terug krijgt voor je use case. Verschillende niveaus van aggregatie zou je vooraf klaar kunnen zetten zodat er weinig processing nodig is tijdens het request. Dit is een techniek die bijvoorbeeld gebruikt wordt in het ECW formaat (een bitmap formaat).

De OGC standaard WFS ondersteund (helaas) niet het meegeven van een aggregatie factor. Echter het recent populair geworden formaat vector tiles is op dit principe gebaseerd. Vector tiles is echter geen geaccepteerd formaat in bijvoorbeeld search engines.

Je moet dus altijd een afweging maken tussen nauwkeurigheid en snelheid/grootte, het doel waarvoor je een eventuele conversie doet moet leidinggevend zijn. In het geval van search engine crawling (discovery) is nauwkeurigheid waarschijnlijk minder relevant, als een hit eenmaal gevonden is in de zoekmachine kunnen mensen altijd doorklikken naar het originele object alwaar je de volledige geometrie presenteert.

Enne, bij veel datasets betreft het overigens een schijn accuraatheid, na de herprojectie van rd naar wgs84 wordt vaak niet correct afgerond, een computer denkt nu eenmaal dat 1/3=0,333333…, tenzij we hem vertellen dat 1 alles tussen 0.5 en 1.5 kan betekenen

#3

Thnx voor de reply! Processing is ons probleem niet, het gaat puur om het aantal MB dat over de lijn moet. Wat betreft het aantal decimalen lijkt de oplossing mij dus eenvoudig. De parameter accuracy (locatie nauwkeurigheid) staat standaard op cm maar er kan ook voor gekozen worden om mm of m etc. mee te sturen, dan krijg je meer of minder decimalen terug.

De default waarde voor de compressie van complexiteit is lastiger. Neem bijvoorbeeld de ‘registratieve gebieden’ uit de BRT. Eén response kan zowel ‘Nederland’ als ‘Utrecht’ bevatten, waarbij de eerste logischerwijs veel meer coördinaten bevat dan de tweede. Voor Nederland is het dan ook logisch om meer coördinaten weg te halen dan voor Utrecht. Wij zaten zelf te denken aan een ‘max aantal coördinaten’, waarmee per geometrie bepaald kan worden of en hoeveel coördinaten verwijderd moeten worden. En wat zou dan een geschikte default zijn? Any thoughts?

#4

Mogelijk is het een optie om de geometrie van het betreffende object te clippen naar de opgevraagde extent. je krijgt dan nooit het effect dat iemand die rond maastricht de nl-grens wil bekijken, heel nederland terug krijgt (dit is ook een van de ideeen achter vector tiles). In je API zou je een parameter clip2extent=true/false op kunnen nemen

Ik ben geen voorstander van een max-aantal coords per object, je krijgt dan het effect dat de nl-grens af gaat wijken van de provincie limburg grens ofwel hoe groter het object des te onnauwkeuriger.

Merk op dat de accuraatheid parameter ook invloed zal hebben op complexiteit, op het moment dat je coordinaten af gaat ronden zullen veel coordinaten weg vallen (omdat ze samen vallen). Hiervoor zijn diverse generalisatie algoritmen beschikbaar.

#5

Clip2Extent begrijp ik niet helemaal. De API geeft objecten terug, dat kan bijvoorbeeld ook op basis van het criterium ‘geef me alle registratieve gebieden die status actief hebben en type is gemeente’. Hier doen we niets met geo, maar ik krijg wel geometrieën (als property van de objecten) terug. Als hier een vierkante gemeente in zit en een gemeente met heel veel coördinaten, dan zou je met max coordinaten het vierkant intact laten en de andere gemeente iets versimpelen. Als ik voor mijn toepassing interesse heb in de complexe geometrie kan ik dit ook terugkrijgen, maar als dat niet zo is en ik wil het op een kaartje laten zien dan moet het voor het menselijk oog ook nog zichtbaar zijn. Met andere woorden: als het object heel groot is dan maakt het toch niet uit dat het in eerste instantie onnauwkeuriger is? Zie ook: Line Simplification. Als je met je muis op de westkust gaat staan heb je al 25% compressie.

#6

zo’n clip2extent is relevant als je geinteresseerd bent of je parachute nu wel of niet in nederland geland is, daartoe wil je niet de hele grens van nederland downloaden, maar alleen het stukje grens wat door het weiland loopt waar je geland bent (en dan graag erg nauwkeurig). zo’n clip2extent is inderdaad alleen interessant als je ook een extent (je positie + kilometer omtrek) mee stuurt.

De use case die je beschrijft met gemeentes op een kaart is volgens mij prima af te handelen met slechts een accuraatheid parameter.

#7

De ‘payload’ van de response kan soms enkele MB’s groot zijn door complexe geometrieën in GeoJSON en dit is onacceptabel voor op het web.

Los van nauwkeurigheid: een eenvoudige manier om de payload te verkleinen is door gebruik te maken van standaard GZIP compressie op HTTP niveau.

WFS responses json en gzip compressie
#8

Hoi Bob,

Dat doen we al :wink:

#9

Hallo Dimitri,

Om een idee te geven van de wat het aantal decimalen inhoudt een snelle voorbeeld berekening. De omtrek van de aarde langs de lengtegraad (over de polen) is 40008 km. Een volledige cirkel betreft 360 graden. Dit houdt in dat 1° t.o.v. de lengtegraad gelijk staat aan 111,13 km.* Nemen wij nu 1 cm dan staat dit gelijk aan 8,99 x 10-8 graden (0,01 m / 111133,33). Ofwel 8 decimalen. De 15e decimaal staat dan gelijk aan 1,11 x 10-10 m (0,1 nanometer).

Voor geometrische data is dit zeer gedetailleerd. Qua landmeetkundige inwinning is een dusdanige nauwkeurigheid niet haalbaar. Het gewenste detailniveau van de dataset wordt in de bron bepaald door de inwinwijze, veel “standaard” topografische bestanden worden op cm – dm niveau ingewonnen.

De generieke vraag hierbij is; welk detailniveau (De kaart of de viewer) kan en moet in het systeem nog kunnen worden gedetecteerd? Wat voor jou toepassing de beste optimalisatie geeft zouden wij eens specifiek aan de hand van de betreffende dataset, het systeem, en de uiteindelijke gebruiker moeten bepalen.

Mvgr,
Kees

*Voor de breedtegraad is 1° gelijk aan 68,5391 km.