BAG WMS en WFS versie 1.1 nu beschikbaar

Rob_PDOK · 31 juli 2019 om 09:37

Op PDOK is de vernieuwde versie van de BAG WMS en de BAG WFS webservices beschikbaar gesteld.

Dit naar aanleiding van een aantal gebruikerswensen. Het betreft nu een minor release. Mogelijk komt er in 2020 een nieuwe wijziging i.v.m. BAG 2.0.

De volgende aspecten zijn in deze v1.1 veranderd ten opzicht van de huidige BAG webservices:

• Het attribuut ‘actualiteitsdatums’ is komen te vervallen
• De voorloopnullen van het BAGID worden niet meer verwijderd
• Ieder featuretype bevat een verwijzing naar Linked Data door middel van ‘rdf_seealso’

De webservices zijn te benaderen door middel van onderstaande links:

WMS - https://geodata.nationaalgeoregister.nl/bag/wms/v1_1?request=getCapabilities&service=WMS
WFS - https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?request=getCapabilities&service=WFS

Heb je vragen of opmerkingen laat het ons dan weten via het Geoforum of ons klantcontactcenter.

Gebruikers van de vorige BAG WMS- en WFS-services wordt dringend verzocht te switchen naar bovengenoemde URL’s.

De vorige URL’s blijven bij PDOK beschikbaar tot en met 31 januari 2020.

Hugo · 1 augustus 2019 om 06:29

Ik krijg een foutmelding bij het gebruik van de WFS. De WMS gaat wel goed.

Melding: WGPProxy WebException for https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?srsName=EPSG:28992&service=WFS&version=1.1.0&request=GetFeature&typename=bag:ligplaats&outputFormat=application/json

Details: subtype=geojson&maxfeatures=1000 , error: The remote server returned an error: (500) Internal Server Error.

Doe ik iets fout met instellingen?

rli · 1 augustus 2019 om 07:22

Probleem met WFS GetFeature query met filter op identificatie.

Een WFS query met de nieuwe WFS URL https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1
met filter op identificatie levert geen resultaat op.

De query is:

<wfs:GetFeature service="WFS" version="2.0.0"
                      outputFormat="application/gml+xml; version=3.2" count="1000" startindex="0" xmlns:bag="http://bag.geonovum.nl"
                        xmlns:wfs="http://www.opengis.net/wfs/2.0"
                        xmlns:fes="http://www.opengis.net/fes/2.0"
                        xmlns:ogc="http://www.opengis.net/ogc"
                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                        xmlns:gml="http://www.opengis.net/gml/3.2"  
                        xsi:schemaLocation="http://www.opengis.net/wfs
                                            http://schemas.opengis.net/wfs/2.0/wfs.xsd">
                     <wfs:Query typeNames="bag:pand" srsName="EPSG:28992"><fes:Filter>
<fes:PropertyIsEqualTo matchCase="false"><fes:ValueReference>identificatie</fes:ValueReference><fes:Literal>0153100000272020</fes:Literal></fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
</wfs:GetFeature>

Het resultaat is:

<?xml version='1.0' encoding="UTF-8" ?>
<wfs:FeatureCollection
   xmlns:bag="http://bag.geonovum.nl"
   xmlns:gml="http://www.opengis.net/gml/3.2"
   xmlns:wfs="http://www.opengis.net/wfs/2.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://bag.geonovum.nl https://geodata.nationaalgeoregister.nl/bag/wfs/v1?SERVICE=WFS&amp;SERVICE=WFS&amp;VERSION=2.0.0&amp;REQUEST=DescribeFeatureType&amp;TYPENAME=bag:pand&amp;OUTPUTFORMAT=application%2Fgml%2Bxml%3B%20version%3D3.2 http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd"
   timeStamp="2019-07-31T15:40:18" numberMatched="unknown" numberReturned="0">
</wfs:FeatureCollection>

Met de oude WFS URL kreeg ik wel resultaat.
(wel met identificatie zonder voorloopnullen)

wouter.visscher · 1 augustus 2019 om 07:29

Hoi @Hugo,
Het issue wat jij beschrift is opgelost, het bleek dat er een setting ontbrak in onze configuratie.

wouter.visscher · 1 augustus 2019 om 07:38

Hoi @rli

We gaan hier naar kijken, het lijkt een specifiek issue te zijn met een bepaald bag object…
We krijgen namelijk wel response wanneer er een ander bag:identificatie is opgegeven (bijv. 0193100000010617)

<wfs:GetFeature service="WFS" version="2.0.0"
                      outputFormat="application/gml+xml; version=3.2" count="10" startindex="0" xmlns:bag="http://bag.geonovum.nl"
                        xmlns:wfs="http://www.opengis.net/wfs/2.0"
                        xmlns:fes="http://www.opengis.net/fes/2.0"
                        xmlns:ogc="http://www.opengis.net/ogc"
                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                        xmlns:gml="http://www.opengis.net/gml/3.2"  
                        xsi:schemaLocation="http://www.opengis.net/wfs
                                            http://schemas.opengis.net/wfs/2.0/wfs.xsd">
                     <wfs:Query typeNames="bag:pand" srsName="EPSG:28992"><fes:Filter>
<fes:PropertyIsEqualTo matchCase="false"><fes:ValueReference>identificatie</fes:ValueReference><fes:Literal>0193100000010617</fes:Literal></fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
</wfs:GetFeature>

rli · 1 augustus 2019 om 08:29

Het is wel bij heel veel objecten het geval:
0080010000480948
0080010000434326
0632010000020092
Ik heb er zelf nog geen kunnen vinden waar het wel werkt.

wouter.visscher · 1 augustus 2019 om 09:10

@rli, het lijkt een bug in mapserver.
M.b.t. het opvragen van de BAG objecten met de identificatie parameter is dit te doen door in het getfeature request de matchCase=true te zetten, i.p.v. false (gezien erbij numerieke characters geen lower/upper case bestaat).

<wfs:GetFeature service="WFS" version="2.0.0"
                      outputFormat="application/gml+xml; version=3.2" count="1000" startindex="0" xmlns:bag="http://bag.geonovum.nl"
                        xmlns:wfs="http://www.opengis.net/wfs/2.0"
                        xmlns:fes="http://www.opengis.net/fes/2.0"
                        xmlns:ogc="http://www.opengis.net/ogc"
                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                        xmlns:gml="http://www.opengis.net/gml/3.2"  
                        xsi:schemaLocation="http://www.opengis.net/wfs
                                            http://schemas.opengis.net/wfs/2.0/wfs.xsd">
                     <wfs:Query typeNames="bag:verblijfsobject" srsName="EPSG:28992"><fes:Filter>
<fes:PropertyIsEqualTo matchCase="true"><fes:ValueReference>identificatie</fes:ValueReference><fes:Literal>0080010000480948</fes:Literal></fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
</wfs:GetFeature>

dan werkt het zoeken naar de verblijfsobjecten wel

Hoop dat je hiermee voor nu uit de voeten kan

rli · 1 augustus 2019 om 10:00

Voor nu wel. Het betekent wel dat je ook niet hoofdletterongevoelig kunt zoeken op straatnaam, woonplaats etc.
Gaat dat nog opgelost worden?

rli · 1 augustus 2019 om 10:13

Nog een probleem gevonden. De Legenda-URLs’ van de Styles in de WMS-GetCapabilities kloppen niet.

B.v. https://geodata.nationaalgeoregister.nl/bag/wms/v1?SERVICE=WMS&language=dut&version=1.3.0&service=WMS&request=GetLegendGraphic&sld_version=1.1.0&layer=verblijfsobject&format=image/png&STYLE=bag:verblijfsobject

Foutmelding:

<?xml version="1.0" encoding="UTF-8"?> java.lang.NullPointerException: request.getStyle() request.getStyle()

rli · 1 augustus 2019 om 10:47

In plaats van v1 moet er v1_1 in de URL staan, dan werkt het wel.
Geldt niet alleen voor de Style legenda-URL’s maar ook elders in https-links in de GetCapabilities XML.

wouter.visscher · 1 augustus 2019 om 12:29

Dat is wel het idee, we willen deze ‘operation’ ondersteunen. De hoe/wat/wanneer is afhankelijk van tijd/prio en resources.

De WMS Capabilities bevat nu overal v1_1 op de plekken dat het nodig was.

https://geodata.nationaalgeoregister.nl/bag/wms/v1_1?version=1.3.0&service=WMS&request=GetCapabilities

In o.a. QGIS komen de legenda’s er goed in

rli · 1 augustus 2019 om 12:58

De URL’s en legenda plaatjes zijn weer goed.Bedankt.
Waarom is Geoserver eigenlijk vervangen door MapServer?

wouter.visscher · 1 augustus 2019 om 13:28

@rli heel beknopt:

Voornaamste redenen:

stabiliteit (hele dag 70+ geoservers herstarten is niet leuk)
geoserver ‘te veel’ vendor specific options (risico van ‘vendor locking’, geoserver-verslaving)
monoliet (‘moeilijk’ schalen, past ‘minder’ goed in een micro-services architectuur)
resource gebruik (800-1000MB aan geheugen kwijt en dan niet er nog geen 1 workspace/layer/datasource geconfigureerd)
performance (voornamelijk m.b.t. raster data)

Natuurlijk zal mapserver z’n eigen ‘issues’ hebben … maar het geeft ons:

de mogelijkheid om een applicatie per ‘dataset’ te deployen (separation of concerns)
per dataset te schalen i.p.v. per geoserver (microservices)
vele malen lager resource gebruik op ons cluster (5-6MB aan geheugen gebruik bij een ‘stilstaande’ mapserver)
makkelijker te monitoren (door scheiden per dataset kunnen sneller ‘hotspots’ identifier)
(persoonlijk) mooiere plaatjes uit de WMS

Samengevat: het geeft ons de mogelijkheid om OGC services op een moderne infrastructuur (k8s) te deployen. Hierdoor kunnen we als organisatie meer richting een ‘generieke’ manier van werken/beheer gaan, i.p.v. voornamelijk te leunen op maatwerken/handwerk en markt ‘vreemde’ oplossingen. Wat zich moet vertalen naar lagere kosten, efficiënter/effectiever werken enz…

rli · 1 augustus 2019 om 13:56

Bedankt voor je uitgebreide antwoord. De problemen zijn herkenbaar.
Kun je mij op de hoogte houden van issues met MapServer? Misschien apart per mail? Is je emailadres je naam met @pdok.nl erachter?

wouter.visscher · 1 augustus 2019 om 14:17

Je persoonlijk op de hoogte houden gaat niet lukken (/kan ik niet beloven). Dergelijke communicatie zal via de officiële lijntjes lopen.

Issues met Mapserver proberen we zo goed en zo kwaad voor te zijn. Ook hier proberen we te automatiseren, zodat issues als resolven van de href niet fout gaan. Dit had nu eigelijk ook niet fouten moeten/hoeven gaan…

M.b.t. dit specificieke issue: “Mapserver + PostGIs != PropertyIsEqualTo + matchCase=false” is iets waar we verschillende oplossingsrichtingen voor hebben. Het ticket wat hiervoor opstaat heb ik deze communicatie opgenomen/naar gerefereerd. Tevens ook in opgenomen dat we je voor dit issue zullen informeren.

Ynte · 27 augustus 2019 om 14:46

Versie 1.1 bevat in de typename verblijfsobject niet langer het veld pandidentificatie, dat maakt het migreren naar de nieuwe versie in mijn geval wat lastig. Het komt vaak voor dat ik van een pand alle adressen zoek, of van een adres het pand.

Ik was benieuwd of dit een permanente wijziging is. In het overzicht van wijzigingen zie ik deze verandering niet staan.

Jeroen_PDOK · 29 augustus 2019 om 08:27

@Ynte goed punt, ga het navragen (komen er op terug)

Jeroen_PDOK · 4 september 2019 om 14:23

@Ynte deze verandering is onterecht dus we gaan het weer toevoegen. Zal verwacht ik ergens volgende week worden. Je hoort van ons!

cc @Wouter_Remijn

Ynte · 4 september 2019 om 14:59

Top! Dan blijf ik tot die tijd nog even op de oude API hangen.

daneng · 24 september 2019 om 10:31

Bij de verblijfsobjecten van de BAG services met versie 1.1 wordt nu ook weer het veld pandindentificatie gepubliceerd.

Voorbeeld BAG WFS v1.1 verzoek:
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?request=getfeature&service=wfs&version=2.0.0&typenames=bag:verblijfsobject&startindex=0&count=1

Knipsel van het antwoord:

<bag:verblijfsobject gml:id="verblijfsobject.0307010000437123">
...
    <bag:identificatie>0307010000437123</bag:identificatie>
...
    <bag:pandidentificatie>0307100000341568</bag:pandidentificatie>
...
</bag:verblijfsobject>

Met dank aan @Wouter_Remijn