@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?
Als ik eerlijk ben, ben ik het wel met jbaltussen eens. Het lijkt mij logischer om, als er geen datum word opgegeven, alleen de actuele stand van zaken terug te geven. Pas als je geinteresseerd bent in historie, of toekomst, zou je datums moeten gaan opgeven.
Zelf ben ik eigenlijk alleen maar in de actuele stand van zaken geinteresseerd, historie opvragen komt (bij mij) eigenlijk niet voor - of het gaat om historie van (heeel) ver voor de basisregistraties…
Ik had de spaties inderdaad in de browser geconstateerd. Als de vermeende spaties niet de oorzaak zijn dat de validator geen features vindt, dan lijkt het mij toch goed dat jullie uitzoeken waarom de validator dan geen features vindt.
We hebben eerlijkheidshalve zitten wikken en wegen wat te doen (zie ook topic). Voor beide opties (met/zonder historie) valt iets te zeggen, ook afhankelijk van de usecase. Voor de live-gang van de OGC API Features voor de BGT binnenkort (mei) is besloten het te laten zoals het nu is (met historie) maar we blijven de ervaringen (waaronder die van jullie) natuurlijk nauwlettend volgen.
Beste Pieter, de OGC validator is niet door PDOK gerealiseerd. Omdat deze voor handen was hebben we het als een black box toegepast. Wij veronderstellen dat de testdata/aanpak in de validator niet toereikend is en gebruik wordt gemaakt van coördinaten buiten Nederland.
De vraag zou gesteld kunnen worden aan de maker van de validator, of we wachten de ontwikkelingen binnen OGC API’s naar meer volwassenheid nog even af.
Ik heb begrepen dat de demo op 1 mei afloopt, maar ik zie nergens terug wanneer de officiële API in productie treedt, wanneer kunnen wij dit verwachten?
Inderdaad is de demo (min of meer) afgelopen. We hebben de laatste bevindingen opgelost en zijn bezig met afrondende werkzaamheden.
Op 21 mei is de definitieve versie gepubliceerd en voor iedereen beschikbaar. Dit topic wordt dan gesloten en met een nieuw topic gelanceerd.
Dankjewel voor de toelichting Anouk.
Is de feature limit in de definitieve versie hoger dan de demo versie? (1000)
Nee die is niet verhoogd.
@Pieter_Bresters Toen je (namens GeoNovum) de conformance test uitvoerde adverteerde we de extent van de collecties nog in RD. Daarmee kon de validator niet overweg, dit hebben we meteen aangepast naar WGS84 (zie eerdere bericht). De validator kan nu wel de bbox checks uitvoeren en slaagt daar ook voor.
De enige checks die nu nog - terecht - worden overgeslagen zijn degene waarbij een bbox buiten de geadverteerde extent valt. De validator controleert namelijk ook op een aantal randgevallen (o.a. rond de evenaar, poolgebieden, etc). Deze zijn niet van toepassing op PDOK APIs aangezien deze alleen Nederland beslaan. Merk ook op dat de validator bewust hier niet op faalt, alleen skipped.
Het feature limit (1000) is gelijk aan wat momenteel in WFS services wordt toegestaan. Indien een call meer dan 1000 features oplevert is het mogelijk om via de “next”-link in de (GeoJSON) response door alle gevonden features te pagineren. Zodoende is het - via extra calls - mogelijk om alle features op te vragen.
Dank voor de toelichting!
Ik sluit dit topic en verwijs naar de lancering van versie 1: BGT Features (OGC API) zijn nu ook beschikbaar