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.
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:
We gaan ermee aan de slag en laten het weten als het aangepast is. Bedankt voor de feedback!
cc @John_Schaap
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.
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:
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
Bij wijzigingen aan een object blijft het object-ID behouden, er ontstaat een nieuwe versie in de LV-BGT; de huidige versie krijgt van de bronhouder een eindRegistratie. De bronhouder maakt een nieuwe objectversie aan. Deze versie van het object behoudt dezelfde objectBeginTijd en krijgt een nieuw tijdstipRegistratie, waarbij tijdstipRegistratie gelijk is aan de eindRegistratie van de vorige versie. Bij opname van de nieuwe versie in de Landelijke Voorziening krijgt het object ook een nieuwe LV-publicatiedatum.
In dit geval betreft de wijziging een object dat vervallen wordt verklaard. Het krijgt dus een eindRegistratie. De LV-publicatiedatum van het vervallen object is dan nog niet geregistreerd. Daarom wordt er een nieuwe versie van het object aangemaakt met alleen een andere LV-publicatiedatum.
Dit verklaard waarom er twee objecten in de LV aanwezig zijn met dezelfde gegevens, waarbij alleen de LV-publicatiedatum verschilt.
Dezelfde situatie zit ook zo in de BGT downloads.
Dank voor de toevoeging, je opmerking is in onderzoek!
@ThomasHaarlem we hebben verbeteringen doorgevoerd in de visualisatie waardoor het objecttype erf nu correct wordt weergegeven. Bedankt voor de feedback!
Dank voor de feedback @Pieter_Bresters, hier een reactie.
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.
Bekijk je de JSON via een browser? Deze zet waarschijnlijk een extra spatie na de komma. In werkelijkheid zitten er geen spaties tussen de coordinaten. Bijgaande afbeelding toont alle onzichtbare tekens. Achter de komma volgt een line break, geen spatie:
De JSON is alleen pretty-printed maar dat zou verder geen invloed mogen hebben. Zoals je zelf ook aangeeft volgt er uit de OGC validator (wij gebruiken deze ook) geen fout. De test wordt alleen overgeslagen aangezien er geen features worden gevonden. Wellicht is de testdata/aanpak in de validator op dit punt niet toereikend (coordinaten buiten Nederland?).
De extent van de collecties stond overigens nog op RD. Dit hebben we inmiddels aangepast naar WGS84 zodat het meer in lijn is met het feit dat WGS84 de default projectie - in OGC API Features - is.
Standaard: OAS 3.0.0
De verplichte elementen als “openapi”, “info”, “path”, “components” staan er in, maar wel in een ongebruikelijke volgorde.
Dit heeft verder geen invloed op de werking, elementen in JSON mogen in elke volgorde voorkomen. Vanuit gebruiksvriendelijkheid/cosmetisch oogpunt begrijp ik je opmerking. We hebben het inmiddels aangepast, “openapi”, “info”, “paths" etc komen nu in een meer logische volgorde voor.
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.
Zie punt 1.
Standaard: Dutch API Design Rules
Het versienummer in de URL mag alleen het major nummer bevatten volgens regel API-20.
Dit is ons bekend. Er is daar een conflict tussen de PDOK en ADR url strategie. De PDOK strategie wordt hierop aangepast, te beginnen bij nieuw te lanceren OGC APIs. Kortom: er wordt aan gewerkt.
Standaard: Dutch API Design Rules
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 (…)
Dit is ons bekend. Geldt voor elke OGC API. Wij hebben dit eerder ook al bij de adr-validator gemeld. Hier lijkt een taak voor GeoNovum weggelegd.
Standaard: INSPIRE
De BGT is geen INSPIRE dataset, maar toch zijn bepaalde onderdelen uit dit document wel aan te bevelen die nu ontbreken.
Links naar Nationaal Georegister zijn wel al in de HTML representatie opgenomen. Nog niet in de JSON. Er wordt hier in breder verband naar gekeken door @Jeroen_D. Zelfde geldt voor de downloads.
requirement 22 C in de OGC API Features core 1 standaard schrijft dat een hoger limit in een parameter in een request dan is ingesteld in de service, niet mag leiden tot een foutmelding. Dit zou dus aangepast moeten worden in de service
Dank voor het testen in ArcGIS Pieter en @jbaltussen. Dit is nu aangepast, een limiet hoger dan 1000 geeft nu geen foutmelding meer maar levert maximaal 1000 features op. We horen graag of dit naar behoren werkt.
@Marijnbiekart Misschien ten overvloede maar zie PDOK lanceert de BGT Features (OGC API) als demo - #24 door FKrijgsman voor antwoord op je 2e vraag.
Top! Het request https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/collections/put/items?f=json&limit=5000 geeft nu netjes 1000 records terug.
Maar… en …
In specs (OGC API - Features - Part 1: Core corrigendum) staat ook:
To support access to larger collections without overloading the client, the API supports paged access with links to the next page, if more features are selected than the page size.
…
The limit parameter may be used to control the subset of the selected features that should be returned in the response, the page size.
…
Each page may include information about the number of selected and returned features (numberMatched and numberReturned) as well as links to support paging (link relation next).
De link naar de next page ontbreekt als je meer records vraagt als is toegestaan. Hierdoor kan een GIS client niet iets implementeren om een groter kaartbeeld op te bouwen.
@jbaltussen Als ik https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/collections/put/items?f=json&limit=5000 opvraag zie ik wel een next link.
Deze werkt ook. Op de volgende paging is weer opnieuw een next-link beschikbaar en tevens een prev-link om eventueel terug te gaan. De next/prev links in de GeoJSON zouden door de GIS tools gebruikt moeten worden.
Klopt: dit werkt wel. Ik keek niet goed. Bedankt voor je snelle antwoord.
PDOK heeft de api aangepast nav de melding, zodat er geen foutmelding meer komt als je meer records vraagt als het maximum.
Nu worden netjes de eerste 1000 records getoond in de kaart bij het request.
https://api.pdok.nl/lv/bgt/ogc/v1_0-demo/collections/wegdeel/items?f=json&limit=5000
In de Mapviewer van ArcGIS online werkt het nu ook zonder de workaround van Pieter. Dus je kunt gewoon het type OCG-objectlaag kiezen als je BGT toevoegt als layer.
Wat wel vreemd is (lijkt een bug) als je bij parameters de limit aanpast naar bv 999, dit niet gebruikt wordt.
De viewer blijft het limit=5000 als request uitsturen.
Ps
PDOK ondersteunt ook paging. Als de viewer dit ook zou doen, zou je ook meer records in het kaartbeeld kunnen tonen.
Dit zou een optioneel knopje kunnen zijn, want heel veel records opvragen is ook niet erg zinvol en onnodig duur.
Voor een pand in Amersfoort zie ik ook 3 voorkomens met alle dezelfde creation date, maar met verschillende niet aansluitende lv_publicatiedatums en tijdstip_registraties. Geen van de 3 voorkomens heeft een termination_data_leeg. Hoe kun je nu het meest recent object tonen? Is het ook niet logischer om default alleen het meest recente object te tonen?
@FKrijgsman
Voor dit voorbeeld moet je me het ID sturen, want ik heb nu geen antwoord.
Je kunt een datum in de toekomst meegeven, dan krijg je de BGT zonder historie; bv https://api.pdok.nl/lv/bgt/ogc/v1_0-demo?datetime=2039-01-01T00:00:00.000Z. Beantwoord dat je tweede vraag?
