Het is mij opgevallen dat de geometrie van objecten die cirkelbogen bevatten verschilt afhankelijk van het formaat dat wordt gekozen om de data op te halen. GML en StUF formaat (uit de download service) bevatten cirkelbogen.
Echter, als vanuit de OGC API (Geo)JSON (ondersteund geen cirkelbogen), als download formaat gekozen wordt , worden de cirkelbogen automatisch verstrookt.
Maar ook JSONFG (wat in principe cirkelbogen zou moeten ondersteunen) resulteert in verstrookte cirkelbogen.
Allemaal geen probleem als de download enkel gebruikt wordt voor visualisatie. Als de download echter gebruikt wordt als bron voor mutaties die teruggestuurt moeten worden naar de LV-BGT, dan worden de WAS cirkelbogen vervangen door de WORDT verstrookte cirkelbogen (en dit kan resulteren in validatie fouten).
Betekent dit, dat de bron voor BGT mutaties altijd de downloadservice moet zijn?
Dat is correct. In OGC APIs serveren we sowieso geen mutaties uit, daarvoor zijn inderdaad de download APIs. Verder zijn de OGC APIs onder water gebaseerd op geopackages, waarin wij geen curves ondersteunen.
Dit heeft ook te maken met het feit dat veel clients beter met verstrookte geometrieƫn om kunnen gaan als ze al met cirkelbogen om kunnen gaan. Verstroken is de gangbare manier van curves op die simpelere manier aanbieden. Zo zijn onze APIs in een zo breed mogelijke set van clients te gebruiken.
Dat is niet helemaal wat ik bedoelde.
Ik probeer niet de OGC API als bron voor mutaties te gebruiken, maar de downloaded objecten als bron om mutaties op uit te voeren.
Als deze mutaties dan vervolgens worden ge-upload naar de LV-BGT dan is de WAS (gedownload vanuit de OGC API met verstrookte cirkelbogen) anders dan de WAS in de LV-BGT (met de originele cirkelbogen) en zijn ze dus per definitie verschillend?
Geometrieƫn in de Download APIs bevatten (indien zo aangeleverd) curves. In OGC APIs zijn de geometrieƫn sowieso verstrookt.
Maar wat is dan het punt van het ondersteunen van JSONFG? Het was me namelijk ook al opgevallen dat ik telkens geen cirkelbogen kon vinden. Ik had alleen geen duidelijk vergelijkmateriaal en nam vooralsnog aan dat het telkens reeds gestrookt bronmateriaal betrof. Maar uit je opmerking maak ik op dat het dus (vooralsnog) nooit origineel bronmateriaal is.
Dan rijzen er twee belangrijke vragen:
1/ Gaan jullie op termijn wel het originele bronmateriaal beschikbaar stellen met curvetypes? (Waarbij het dus logisch is dat JSONFG beschikbaar is als format).
2/ In hoeverre voldoet dit aan de vereisten van openbaarheid van data?
De huidige API strategie met de nodige verwarringen rondom CRS is bij dat laatste ook niet direct bevorderlijk. Naar mijn mening dient er bij elke API met publieke overheidsdata een duidelijke optie beschikbaar te zijn waarbij de originele ruwe data, compleet ongefilterd opgehaald kan worden. Met de genoemde strategie van geopackages, is dat dus blijkbaar helemaal niet mogelijk. De vraag is dan of dat wenselijk is, en je kunt je zelfs afvragen of dat juridisch stand houdt.
Het punt van JSON-FG binnen de OGC APIs van PDOK heeft met de ondersteuning voor CRSen te maken. De CRS zit dan ook in de data/response bij JSON-FG.
GeoJSON ondersteund officieel alleen WGS84. Er is binnen de standaard aangegeven waarom: RFC 7946: The GeoJSON Format, daar staat ook:
However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.
Omdat OGC API Features het mogelijk maakt om andere CRSen op te vragen geven we bij een dergelijk expliciet request dan ook de geojson in die CRS terug. Zoān expliciet request interpreteren we dan als āprior arrangementā. Vergelijkbaar gedrag is te zien bij veel OGC API Features implementaties.
Overigens staat JSON-FG niet op de pas-toe-of-leg-uit-lijst van het forum voor standaardisatie. OGC APIs zijn bij PDOK in ontwikkeling. Zoals gezegd de data van de BGT met curves is in de Download API op te vragen.
In al mijn onschuld zie ik een match met:
Als de hosting van een wat grotere GeoPackage een probleem is voor PDOK kunnen we daar samen wel een mouw aan passen.
@geotiles, dat draadje gaat inderdaad ook over geopackages. We hebben geen probleem met geopackages.
Wij gaan ook even contact opnemen met de data-aanbieder, zodat we beter de inhoud en de geleverde service in combinatie met deze vraag kunnen beantwoorden.
Dit lijkt me een keuze die is gemaakt bij het ontwerp van het ETL proces:
In principe ondersteunen Geopackages volgens mij namelijk wel cirkelbogen, dus dat ze niet in de afgeleide geopackages beschikbaar zijn is het resultaat het ETL proces.
Een ander punt uit dit draadje is dat niet alle formaten beschikbaar in PDOK dezelfde data bevatten. Een object (feature) opgevraagd als JSON heeft een andere geometrie als datzelfde feature gedownload via de downloadservice. Dit staat nog los van het feit dat hetzelfde feature (met hetzelfde BGT id) ook nog verschillend kan zijn in de LV-BGT.
Uiteindelijk onstaat er een landschap waarin geen sprake meer is van Ć©Ć©n duidelijke āsource of truthā, maar een hele reeks endpoints die geen van alle een werkelijke āsource of truthā zijn, zonder dat dit direct duidelijk is voor de gebruiker. Dat lijkt me geen wenselijke situatie.
Dank voor de gemaakte opmerkingen!
Zoals gezegd gaan we even contact opnemen met de data-aanbieder om de databron zoals geleverd door de data-aanbieder nog beter af te stemmen op deze nieuwe dataproducten van PDOK.
De OGC API is geen product dat gebruikt kan worden als bron voor mutaties. Dit moet inderdaad via de downloadservice; StUF-Geo IMGeo.
Voor meer informatie over het standaard BGT berichtenverkeer, zie: BGT | IMGeo | Geonovum | BGT berichtenverkeer
Er zijn meerdere partijen die last hebben van bogen in de BGT. Ook voor bv. 3D toepassingen zijn ze niet heel erg handig. Er loopt dan ook een discussie om alleen nog verstrookte bogen in de BGT op te nemen.
In het jaarplan BAG ā BGT 2026 staat een actie om het āAanscherpen afspraken over cirkelbogen in het kader van vereenvoudiging van ketens en uniformere werkwijze bij de bronhouders;ā met prioriteit in 2026 vorm te geven.
Op dit moment is nog niet aan te geven of Ć©n wanneer er afscheid van bogen genomen zal en kan worden.
Cirkelbogen worden ondersteund in een extensie van de geopackage, maar niet in de basis. Dat is waar PDOK momenteel van gebruik maakt. Zoals @FKrijgsman hierboven aangeeft zijn cirkelbogen niet voor iedere toepassing geschikt. En zoals eerder aangegeven passen cirkelbogen sowieso niet in de GeoJSON standaard. Het verstroken van dergelijke geometrieƫn is een gangbare manier om daar mee om te gaan in een geoservice of API bij het uitserveren in een formaat die dit niet ondersteund (GeoJSON). PDOK past de data niet aan, anders dan er op basis van de service en outputformaten mag worden verwacht. Zo zullen wij een transform uitvoeren op de data als je data in een andere CRS opvraagt. Op die manier kan je het verstroken van de data beschouwen om het aan te bieden middels GeoJSON. JSON FG biedt de mogelijkheid om cirkelbogen uit te serveren in het place attribuut. Dat doen wij niet, wij maken gebruik van het geometrie attribuut, wat een GeoJSON veld is, en op die manier dient te worden ingevuld (dus met verstrookte geometrieƫn). We doen hier dus niets geks. De source of truth is dus dezelfde, de interface gedraagt zich als wat verwacht kan worden van een geoservice. Voor andere datasets geldt dat we (mits er een feature service voor is, zoals een OGC API) we de data as-is ontsluiten zoals deze is aangeleverd.
Wat ik in deze draad lees is dat men graag ook cirkelbogen ondersteund wil hebben in de geoservices van PDOK. Deze vraag geldt alleen voor de BGT. Daar is de reactie van @FKrijgsman hierboven op van toepassing. We wachten eerst op de uitkomst van die discussie. Tot die tijd ontsluiten we zoals hierboven aangegeven sowieso de ruwe data in de download API van de BGT; zie ook de download viewer.
Correctie. Ik wordt er net door een collega op gewezen dat we het place attribuut wel degelijk gebruiken in het geval er een andere CRS wordt uitgeleverd in JSON-FG. Dus we gebruiken het geometrie veld bij JSON-FG alleen in het geval van WGS84. Mijn vorige reactie blijft verder in stand, we wachten de discussie over cirkelbogen in de BGT af.
Zie bijvoorbeeld dit feature in WGS84:
{
"id": "5d394ef5-6a5d-5011-a729-29def1c51dd9"
"type": "Feature"
"time": null
"place": null
"geometry": {
"type": "Point"
"coordinates": [
4.222735689145067,
52.06517285239795
]
...
}
Versus dezelfde in RD:
{
"id": "5d394ef5-6a5d-5011-a729-29def1c51dd9"
"type": "Feature"
"time": null
"place": {
"type": "Point",
"coordinates": [
75152.343,
453626.907
},
"geometry": null
...
}
nu ga ik verraden hoe oud ik ben: diezelfde discussie herinner ik me nog van de GBKNā¦