PDOK lanceert de BGT Features (OGC API) als demo

[Anouk]

Vandaag deelt de BGT een demo versie van de BGT Features in OGC API’s. Wij willen jullie oproepen om deze demo te testen en ons feedback te sturen via dit topic. De informatie is beschikbaar tot 1 mei 2024, daarna gaat deze URL uit de lucht. Gebruik deze informatie niet voor productiesystemen maar wacht de formele lancering daarvoor af!

Features en de toegepaste OGC API Standaard

Met de BGT Features (OGC API) kan je zonder geo-kennis of specifieke applicaties gebruik maken van deze informatie. De OGC API Features leunen op de wereldwijde standaard voor RESTful API’s. Hierdoor zijn de BGT Features (OGC API) breed inzetbaar. Via HTML zijn de API’s goed vindbaar en geeft het meer gebruiksgemak.

Deze realisatie is volledig conform specificatie gerealiseerd. Dit zorgt ervoor dat de BGT Features (OGC API) zich voorspelbaar en eenduidig gedragen. Wij hebben part 1 en part 2 gerealiseerd en er is (nog) geen rekening gehouden met draftversies. De OpenAPI specificatie beschrijft de eigenschappen van de data die de API als input accepteert en als output teruggeeft. Kijk bij conformance https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/conformance voor meer informatie.

Wat kan je met de BGT Features (OGC API) in deze demo?

De OGC API Features zijn een bevragingsservice en een vervanger van de huidige WFS. Deze demo is in feite de door ons voorgestelde implementatie die wij graag per 1 mei 2024 naar productie willen gaan brengen. We stellen de data in diverse projecties en in de formaten HTML en (Geo)JSON(FG) beschikbaar. Het is mogelijk om via een bounding box (BBOX) een selectiegebied op te geven om de gewenste informatie te bevragen. Per bevraging worden er 1000 objecten teruggegeven en je kan hiermee pagineren. Het is ook mogelijk om te filteren op ID of op peildatum.

Waar kan je de BGT Features (OGC API) demo vinden?

De BGT Features zijn direct te vinden door naar de BGT landingspagina te navigeren. Hier zie je in één oogopslag alle relevante productinformatie waaronder de collections waar je de features van de BGT vindt (https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/collections).

Er heeft nog geen formele publicatie plaatsgevonden, daardoor vind je nog niets via de PDOK website of via het Nationaal Georegister.

Toekomstige ambitie

PDOK werkt continu aan verbetering van het platform en de kwaliteit van de geleverde services en API’s. Behalve om voor de BGT, de BAG, de Bestuurlijke Gebieden, de BRT TOP0NL en De Kadastrale Kaart OGC API’s beschikbaar te stellen, heeft PDOK ook de ambitie om deze voor alle data-aanbieders mogelijk te maken. Hiervoor zal het platform voldoende geautomatiseerd moeten zijn en daarbij voldoen aan de gestelde performance- en kwaliteitscriteria. Ook ontwikkelingen van de resterende OGC API specificaties zijn onderdeel van toekomstige ambitie. Aankondiging van verbetering en vernieuwing vindt via de gebruikelijke kanalen (website, attenderingsservice , GeoForum en X ) plaats.

Deel je je ervaringen met ons via het Geoforum?

Wij kunnen alle feedback goed gebruiken!

[halam]

Een aantal features lijken lastig te laden. Dan blijft het hangen, in ieder geval Qgis

Sporen, de brugdelen en overige bouwwerken vind ik een een verrijking! Alhoewel de meeste in ‘Overbruggingsdelen’ staan, dat klinkt een beetje merkwaardig klinken.

En ‘ondersteunende wegdelen’ … Het lijken de taluds te zijn die het ‘ondersteunen’
Deze geeft ik default liever een representatieve kleur mee als berm, groen. Het veranderen van de style kost nog best veel tijd. Op een of andere manier is Qgis daar lang zoet mee.

Style aanpassen is erg lastig. Is er een BGT standaard voor het kleurgebuik en volgorde layers?

Verder valt het mij op dat ik weinig relevante informatie kan vinden over bruggen, namen van kunstwerken, nummers, satus of bevoegd gezag dat het in beheer heeft?

[Anouk]

Hi Fijn dat je meetest en ons voorziet van je bevindingen!
Weet even dat je alle data inclusief historie inlaadt en dat is HUGE. Wij hebben zelf getest door het kiezen voor het toevoegen van WFS /OGC API objecten en dan een peildatum meegeven. Ook maakt het nogal wat uit via welke cliënt (internet) je data gebruikt.
Wil je de Features als een viewservice gebruiken dan kan je beter de vectortiles gebruiken en de daarbij voorgedefinieerde style toepassen. Hopelijk ben je met dit antwoord al iets meer op weg.

[hulstg]

In QGis kan je een peildatum opgeven door deze als parameter aan de URL toe te voegen, bijvoorbeeld: https://api.pdok.nl/lv/bgt/ogc/v1_0-demo?datetime=2025-03-01T00:00:00.000Z. Voor de actuele stand moet je een datum groter of gelijk aan vandaag gebruiken.

[halam]

Datum toevoegen lukt me niet met deze .json benadering

[rkettelerij]

De API kan in QGIS worden toegevoegd via WFS / OGC API Features > New Connection.

Hier kan optioneel een datetime parameter worden meegegeven om de stand van de BGT op dat moment in tijd te zien (registratiedatum). Een datum van nu of in de toekomst geeft alleen de actuele situatie weer. Vervolgens zijn de verschillende collecties als lagen te benaderen:

[halam]

Dank! Dat werkt inderdaad een stuk sneller.

[ThomasHaarlem]

In QGIS heb ik vai de PDOK Service Plugin de BGT OGC API - Tiles aangeklikt. Fijn om gelijk in één kaartlaag het overzicht te krijgen van de beschikbare objecttypen (begroeid terreindeel, waterdeel, wegdeel, etc).

Vraag: Klopt het dat het objecttype “erf” is weggelaten? De BGT moet vlakdekkend zijn, toch zie ik de luchtfoto eronderdoor. Of zit dat in het maximum van 1.000 features die per keer opgehaald worden?

Vraag 2: Klopt het ook dat de puntobjecten (bomen, Paal (type lichtmast) niet geserveerd worden?

Ik heb gewoon de laag aangeklikt zonder request parameters in te voeren. Ligt het daaraan?

[Jeroen_D]

Ik vermoed dat dit met de styling van de achtergrondvisualisatie te maken heeft (https://api.pdok.nl/lv/bgt/ogc/v1_0/styles). De feature info geeft bijvoorbeeld wel de objectinformatie terug en bij de standaardvisualisatie speelt het niet. We gaan er naar kijken.

Achtergrondvisualisatie (style) in de PDOK Viewer:

Standaardvisualisatie (style) in de PDOK Viewer:

[Marijnbiekart]

Hey goedemorgen, werkt prima! Heb hem nu draaiend via standaard http calls, een stuk sneller dan de andere API en de json is ook makkelijker verder te verwerken.
Ik heb wel twee opmerkingen:

1. in de documentatie is de bounding box geschreven als coordinaat(komma)(spatie)coordinaat maar de call werkt alleen met coordinaat(komma)coordinaat.

2. de datumselectie werkt nog niet perfect of er is meer aan de hand. Call bijvoorbeeld naar https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/collections/pand/items?crs=http://www.opengis.net/def/crs/EPSG/0/28992&bbox=100396%2C450344%2C100397%2C450345&bbox-crs=http://www.opengis.net/def/crs/EPSG/0/28992&datetime=2024-04-02T00:00:00Z

En je krijgt twee keer lokaal_id G1892.322c19db4e834227846213bdccd8cec0 terug. Het id en de lv-publicatiedatum verschillen dus ontdubbelen is makkelijk maar ik verwacht als ik een peildatum aangeef ik dan ook de status van dat moment te krijgen.

Hoop dat jullie er wat mee kunnen, in ieder geval een mooie service.

[Anouk]

Dank je wel ik zet je opmerkingen door naar ons team!

[rkettelerij]

Dank voor de feedback.

Betreffende punt 1: het is inderdaad coordinaat(komma)coordinaat. In welke documentatie zie je coordinaat(komma)(spatie)coordinaat staan? Kan je daarheen verwijzen?

Betreffende punt 2: Vermoedelijk iets in de data zelf, we gaan dit navragen bij het BGT team.

[Marijnbiekart]

Goedemiddag, jullie noemen de bbox inderdaad niet expliciet, en in bijvoorbeeld OGC API - Features - Overview staat het wel netjes beschreven, maar bijvoorbeeld:

schept wat verwarring. geen groot punt overigens.

[Anouk]

Punt 2 hebben we bij de data-aanbieder neergelegd en laten vaststellen of er in de API mbt datumselectie iets verkeerd zit of data inderdaad zo uit de bron komt.

Het blijkt dat de data inderdaad zo uit de bron komt als gevolg van het historiemodel zoals deze is geimplementeerd in de BGT. Het is dus correct en datumselectie werkt naar behoren, maar verwarrend.
We denken nog even na of dit te voorkomen is of nader moet worden toegelicht.

[ThomasHaarlem]

yes het zit hem in de styling van het objecttype Erf. Als ik in Qgis de OGC API Tiles open vanuit PDOK services plugin zonder aanvullende parameters, kan ik de attributen van het Erf object gewoon opvragen.

Bij Symbologie zie je dat ook terug.
Ga je met de muis op Erf staan, dan zie je niet echt een wit vlakj in de blauwe balk:

Dat in tegenstelling tot Fietspad datde sytling Wit heeft meegekregen. Ga je daarop staan met de muis, zie je duidelijker een wit vierkantje verschijnen:

[Jeroen_D]

We gaan ermee aan de slag en laten het weten als het aangepast is. Bedankt voor de feedback!

cc @John_Schaap

[rkettelerij]

Helder. We hebben de omschrijving in de API specificatie wat aangescherpt.

[Pieter_Bresters]

Die spaties staan ook in de extent in https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/collections?f=json
Dit zorgt er volgens mij voor dat de OGC validator op OGC-API-Features niet kan testen op het bbox-request. De validator geeft dan geen fout, maar alleen aan dat er geen elementen gevonden worden binnen de opgegeven extent en dat die dus niet heeft kunnen testen of het werkt.

[Pieter_Bresters]

Namens Geonovum heb ik getest op een aantal standaarden:

Standaard: OAS 3.0.0
De verplichte elementen als “openapi”, “info”, “path”, “components” staan er in, maar wel in een ongebruikelijke volgorde.

Standaard: OGC API - Common - Part 1: Core
De 4 requirement classes (Core, Landing Page, HTML, JSON en OAS 3.0) worden genoemd in https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/conformance

Standaard: OGC-API - Feature - Part1: Core
De validator van OGC geeft geen foutmeldingen, maar geeft wel aan dat de bbox op het extent geen features terug geeft en dat dit onderdeel daarom niet getest kan worden. Dat komt vermoedelijk door de spaties waar hierboven ook al iets over is gezegd.

Standaard: OGC-API - Feature - Part2: CRS
De validator van OGC geeft geen foutmeldingen en komt volledig door de test.

Standaard: Dutch API Design Rules
Het versienummer in de URL mag alleen het major nummer bevatten volgens regel API-20.
Er is tevens een conflicterend vereiste tussen de OAS en de Dutch ADR standaard t.a.v. de landing page. ADR zegt dat er geen “/” op het einde van endpoints mag en OAS geeft aan dat dit bij de landing page wel moet. Het is te verwachten dat er een uitzondering voor zal komen bij ADR voor de landing page. zie ook API-48.
Verder wordt niet voldaan aan API-54, want de namen van de collecties zijn in enkelvoud en zouden volgens deze regel in het meervoud moeten.

Standaard: INSPIRE
De BGT is geen INSPIRE dataset, maar toch zijn bepaalde onderdelen uit dit document wel aan te bevelen die nu ontbreken:

• neem een link naar de metadata van de dataset op: Nationaal georegister
• neem een link naar een bulkdownload op (bv naar PDOK API - Swagger UI)

Wat wel conform deze INSPIRE good practice is, is dat ETRS89 ondersteund wordt en dat er een link naar de license is opgenomen.

Test in clients:
Tenslotte is onderzocht hoe de deze service aangeroepen kunnen worden in clients als QGIS en ArcGis Online. De eerste levert geen problemen op. Zeker met de aanbevelingen elders in dit topic.
In ArcGis Online lukte het niet als het als een OGC-API feature service werd ingelezen, maar wel door het in te lezen via kaartlaag type “geojson bestand” met een URL als:
https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/collections/put/items?f=json&bbox=6.853,53.320,6.856,53.321&limit=1000
![image|690x391](upload://o631IMIBqDPznuNdwI5VO3AVXPD.jpeg

[Anouk]

Goed bezig Pieter, dank voor je test en je gemaakte opmerkingen in dit forum.
Wij gaan je bevindingen nalopen en valideren of wijzigingen gedaan kunnen/moeten worden voordat we gaan lanceren. Je hoort van ons via het forum!