Van 3 tot 6 juni organiseert Geonovum samen met PDOK een week van experimenten rondom de nieuwe versie van de OGC Web Feature Service (WFS) standaard, WFS 3.0.
Het verschil tussen WFS 3.0 en de huidige versie, 2.0 is groot. WFS 3.0 is REST gebaseerd, en zorgt er voor dat geodata op een manier kan worden gepubliceerd, die indexeerbaar is voor zoekmachines en bruikbaar voor ontwikkelaars. De ontwikkeling van de standaard is heel open geweest met ontwikkelaars samen, een unicum voor een OGC standaard.
Er is nu een stabiele conceptversie van WFS 3.0 beschikbaar en daar willen we tijdens de werkweek in juni ervaring mee gaan opdoen. Iedereen die mee wil doen is welkom!
Het programma ligt nog niet vast, maar het idee is nu om te beginnen met een online kickoff op maandag 3 juni, waarna mensen de hele week aan de slag kunnen met hun eigen WFS 3.0 server- of client implementaties (een soort high five dus). Dit met hulp van een groepje experts die de hele week beschikbaar zijn voor vragen en om mee te denken. Op donderdag organiseren we een event met 's ochtends inloopspreekuur voor de deelnemers en 's middags demo’s en lessons learned voor een breder publiek van geïnteresseerden (fysiek, ergens in of in de buurt van Amersfoort). Op vrijdag is er de ruimte om je implementatie nog verder te perfectioneren.
Iedereen die dit interessant vindt: Zet de datum vast in je agenda en laat evt. een reactie achter in dit topic (dan krijgen wij ook een idee van de interesse hiervoor).
[EDIT] Voor de kennissessie op donderdagmiddag 6 juni, die de werkweek afsluit, is er nu een aanmeldformulier op de Geonovum website.
11 likes
Aanvulling: voor diegenen die met WFS clients aan de slag willen zullen er een paar WFS 3 services beschikbaar zijn om mee te werken vanaf het begin van de week!
1 like
Een “high five” is binnen het Kadaster de term voor een intensieve (high), 5-daagse (five) werksessie, waarbij een team met een nieuwe, innovatieve technologie aan de slag gaat. 
3 likes
OGC heeft ook een API hackathon aangekondigd later in juni bij de Geovation Hub!
2 likes
OGC heeft ook een API hackathon1 aangekondigd later in juni bij de Geovation Hub!
Dus iedereen die eerst de WFS 3 werkweek in NL doet heeft daarna al een voorsprong bij de OGC hackathon. Het overwegen waard… het is in Londen dus niet ver weg.
1 like
Leuk! Ik/wij doe(n) mee: gisteren op de OpenGeoGroep “hacking-dag” met subgroep (o.a. @thijsbrentjens) hele dag besteed aan WFS3 m.n. de Python Open Source WFS3 implementatie PyGeoAPI waarin ook vanuit NL (o.a GeoCat ) aan ontwikkeld wordt: bijv Leaflet WFS3 Client en een PyGeoAPI WFS Proxy Wrapper ontwikkelen om bestaande WFS-en (v1, v2) te ontsluiten.
PyGeoAPI is nog in ontwikkeling, maar de code is eenvoudig te begrijpen, weinig afhankelijkheden. Sterk punt is vooral de “plugin-structuur” waardoor gemakkelijk meerdere soorten “data backends” (Providers) in te passen zijn zoals: CSV, GeoJSON bestanden, PostGIS, GeoPackage en zelfs ElasticSearch. En dus binnenkort WFS2.
Als er nog partijen zijn die deze ontwikkeling willen sponsoren hoor ik dat graag 
1 like
Ha Just, wat is de url van die wfs3-client in leaflet, ben ik benieuwd naar.
Voor WFS3, recent hernoemd naar “OGC API features” is voorlopig alleen het basis uitwissel-model beschikbaar. Het definieren van datamodellen, anders dan standaard YAML (bv uml,xsd,owl), wordt mogelijk ondergebracht in te ontwikkelen plugins. Mogelijk kunnen we in deze werkweek hier een vooruit blik op werpen. Bijvoorbeeld hoe je 1 van de INSPIRE data modellen (dan wel xsd of owl) zou kunnen ontsluiten via ogc api features (hoe kort je dat af? OAF?).
In de week van 13-17 mei vindt in Minneapolis de OSGEO community codesprint plaats. Just en Jorge organiseren een remote nl variant van dit event bij GeoCat in Bennekom op 15 en 16 mei. Er zijn nog plaatsen, stuur me een mailtje als je geinterresseerd bent. Op de agenda staan zaken als pyGeoApi, GeoHealthCheck, GeoNetwork (binnen de nieuwe OGC API’s wordt ook gewerkt aan een catalog variant gebaseerd op OpenAPI, genaamd STAC).
He @pvgenuchten , de WFS-3 client in Leaflet kwam van @thijsbrentjens . Meer als een PoC/quick hack, nadat OpenLayers te complex bleek om in een paar uur te realiseren. Het meeste staat in de OpenGeoGroep GitHub, meer als losse aantekeningen van de dag: GitHub - opengeogroep/wfs3-experiment: WFS 3 experiment OpenGeoGroep, config en docs
.
Maar we zijn wel enthousiast geworden over WFS-3. Het ontsluiten van WFS1,2 via PyGeoAPI kan m.i. ook met GDAL Python bindings, dan kun je in 1x ook heel veel OGR-Sources ontsluiten: van Shapefile tot GeoPackage. Iets dergelijks doen we al jaren in Stetl.
INSPIRE data modellen etc: juist fijn al die (GML/AppSchema-) complexiteit niet in WFS-3 te hebben, ok via extensions dan. Werkweek is nog ver, eerst de code sprint. Die kan je anders nog als apart event hier op GeoForum onder Events aankondigen.
Ik begrijp de hang naar eenvoud, maar sommige cases zijn nu eenmaal niet eenvoudig, dus moet je een manier hebben om ook complexere datastructuren uit te wisselen, zou gek zijn om dan terug te moeten grijpen naar wfs2. Overigens kun je in yaml behoorlijk complexe modellen beschrijven, dus mogelijk is dat voldoende.
Bedankt @pvgenuchten . Het is maar een demo client, maar helpt denk ik wel. Wat betreft complexere datastructuren: in de werkweek kan dat prima een van de onderwerpen zijn.
Wat betreft complexere data structuren, als je kijkt naar het huidige response model ogcapi-features/featureGeoJSON.yaml at master · opengeospatial/ogcapi-features · GitHub dan is het properties:Feature model niet verder uitgewerkt (los van de vraag of application/geo+json uberhaupt dan nog een relevant response formaat is). Ben benieuwd hoe anderen hier naar kijken. Bijvoorbeeld zou een constructie mogelijk zijn, waarbij een collection een array “lantaarnpaal” terug geeft, waarbij de specificatie vereist dat lantaarnpaal de properties van FeatureGeoJSON “erft”. Maar ja, dan is het natuurlijk geen geojson meer. Als voorbeeld https://brk.basisregistraties.overheid.nl/api/v1 waar iedere collectie expliciet objecten van een bepaald type terug geeft, maar wel eigenschappen van FeatureGeoJSON bevat.
Ik wil ook nog even op deze thread wijzen implement schema.org in responses · Issue #33 · geopython/pygeoapi · GitHub, een alternatieve aanpak waarbij je het datamodel niet in YAML definieert maar in een json-ld context. Mogelijk ook relevant voor de werkweek
1 like
Ook wij (GeoNovation) willen graag aanwezig zijn bij deze Werkweek. WFS 3.0 lijkt me noodzakelijk voor de nabije toekomst.
1 like
wfs3 in qgis experiment
GDAL heeft reeds een wfs3 driver beschikbaar, in qgis kun je deze gebruiken om wfs3 te laden. Je maakt daarvoor een VRT bestand aan en opent dit als nieuwe laag in qgis
<OGRVRTDataSource>
<OGRVRTLayer name="ahccd-stations">
<SrcDataSource>WFS3:https://geo.weather.gc.ca/geomet-beta/features</SrcDataSource>
<SrcLayer>ahccd-stations</SrcLayer>
<LayerSRS>WGS84</LayerSRS>
</OGRVRTLayer>
</OGRVRTDataSource>
Zorg dat je een recente versie van GDAL hebt met WFS3 support
2 likes
Voor de kennissessie op donderdagmiddag 6 juni, die de werkweek afsluit, is er inmiddels een aanmeldformulier op de Geonovum website.
2 likes
Ik wil graag een challenge indienen voor de WFS 3 werkweek, het is niet direct op WFS 3 gebaseerd, maar wel sterk gerelateerd.
Tegenwoordig biedt Google dataset zoeken aan op https://toolbox.google.com/datasetsearch.
Het zou interessant zijn om de mogelijkheid in QGIS/ArcGIS/SuperGis/… te hebben om de dataset zoekmachine te doorzoeken om relevante datasets te vinden en deze te openen zonder het pakket te verlaten. Met de aanstaande WFS 3-standaard, die direct door zoekmachines gecrawld wordt en waarschijnlijk zonder enige tussenkomst in de dataset zoekmachine verschijnen, zullen zoekmachines populairder worden als zoekplatforms voor datasets.
Enkele uitdagingen om onderzoek naar te doen:
- Biedt google een API voor het opvragen van datasets of is er alleen de website
- Google stelt de distributie-URL momenteel nog niet beschikbaar (of zal misschien nooit), dus het is moeilijk om de daadwerkelijke data-inhoud link te vinden, er is alleen een link naar een webpagina die metadata over de dataset geeft, die een distributie-URL kan bevatten ( geïdentificeerd door DataDownload.contentUrl)
- Google heeft een interessant mechanisme voor het identificeren van duplicaten tussen catalogi, wat betekent dat een enkele dataset hit kan resulteren in verschillende links over waar het is gepubliceerd, de meest handige optie lijkt om elk van deze locaties te bekijken om het eerste exemplaar te vinden dat de informatie bevat die we nodig hebben, of laat de gebruiker beslissen welk exemplaar moet worden gebruikt.
- Hoe de encoding / formaat te identificeren en te valideren of het een geldig type is voor het pakket, veel voorkomende typen die kunnen worden toegevoegd zijn geopackage, shape, csv, excel, wms, wfs, wcs
- Die datasets die standaard niet ruimtelijke zijn, kunnen ruimtelijk worden gemaakt door enkele kolommen toe te wijzen om te worden gebruikt als coördinaten, of adressen / locaties die worden gebruikt om coördinaten af te leiden, maar dit moet waarschijnlijk worden gedelegeerd aan andere delen van het pakket
Ik ben benieuwd of dit een aardige case is voor de werkweek.
3 likes
Hoe technisch wordt de bijeenkomst op 6 juni? Wij maken als OD veel gebruik van geoservices, maar zit niet zo in de techniek er achter. Ben wel benieuwd naar de nieuwe mogelijkheden.
Moeilijk om hierop antwoord te geven. De werkweek heeft een redelijk technisch karakter, maar het evenement op donderdagmiddag 6 juni is voor een iets breder publiek bedoeld. Bijvoorbeeld resultaten tonen van de werkweek, samenvatting van de (on)mogelijkheden, ervaringen delen.
Het is lastig om te zeggen wat de exacte invulling wordt, dat ligt namelijk ook aan het verloop van de week.
Bedankt, snap ik. Ik ga mezelf gewoon inschrijven en laat me verrassen.
Sinds kort ben ik actief betrokken by het pygeoapi [1] project, een Open Source implementatie in Python van WFS v3 (en meer bijv Processes en Coverages) en zou daar in deze werkweek graag verder mee gaan.
Afgelopen week was de jaarlijkse OSGeo (.org) CodeSprint in Minneapolis. Vanuit Nederland hebben o.a. Jorge Jesus en Paul v G. (GeoCat) en ik ‘remote’ deelgenomen. Er is veel werk verzet, o.a.:
- een “OGR Connector” waarmee in theorie alle GDAL/OGR Vector bronnen via WFS v3 kunnen worden ontsloten. Voorlopig vnl WFS v2, dus bijv bestaande PDOK WFS-en via WFS v3 ontsluiten (RDinfo, zie plaatje)!
- demo website: [2]
- serverless invoke
- Docker Images
pygeoapi gaat dus verder dan WFS v3, ook bijv (Raster) Coverages zijn gepland. Wie weet vindt iemand dat leuk om daarin te duiken. Sowieso verwelkomen we graag bijdragers!
Je kunt de dagelijkse activiteit via Gitter [3] volgen.
[1] https://pygeoapi.io
[2] https://demo.pygeoapi.io
[3] https://gitter.im/geopython/pygeoapi
3 likes
