BAG v1_1 WFS wijziging

daneng 2019-12-09 15:45:45 UTC #1

Hallo allemaal,

de BAG v1_1 WFS service is gewijzigd na aanleiding van een aantal verzoeken vanuit onze afnemers.

De wijzigingen hebben betrekking op het gebruik van het featureID.
De featureID’s hebben een prefix gekregen met ‘bag:’. Hiervoor is gekozen omdat er problemen waren met het aanroepen van features die een ID hebben met voorloopnullen.

Een paar voorbeelden:

We maken gebruik van de BAG v1_1 WFS:
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?request=getcapabilities&service=wfs

Stel we halen eerst met een GetFeature verzoek een ‘ligplaats’ op:
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?request=getfeature&service=wfs&version=2.0.0&typenames=bag:ligplaats&startindex=0&count=1

Het antwoord ziet er dan ongeveer zo uit:

    <wfs:FeatureCollection>
      ...
      <wfs:member>
        <bag:ligplaats gml:id="ligplaats.bag:0003020000000001">
      ...
      </wfs:member>
    </wfs:FeatureCollection>

Hierin zien de nu dus een id met ‘ligplaats.bag:0003020000000001’. Dit is toevallig een ID met voorloopnullen.
Vervolgens gaan we dit feature met een ‘GetFeature’ verzoek met ‘featureID’ ophalen:
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?request=getfeature&service=wfs&version=2.0.0&typenames=bag:ligplaats&featureId=ligplaats.bag:0003020000000001

En nu zien we dat dit feature gevonden wordt en wordt teruggeleverd.

Dit zelfde werkt ook met een FES filter:
BAG v1_1 WFS GetFeature met FES Filter

    <fes:Filter>
       <fes:ResourceId%20rid="ligplaats.bag:0003020000000001"/>
    </fes:Filter>

Graag horen we of dit een werkbare situatie is voor jullie.

Eerdere forumberichten over dit issue:

wouter.visscher 2019-12-10 09:54:38 UTC #2

rli 2019-12-11 16:30:25 UTC #3

Helaas is de performance van de WFS query met het FES filter dramatisch maar daarvan zijn jullie al op de hoogte.
Bij MapServer werken ook WFS queries met matchcase=“false” niet. Dat is al een vrij oude bug maar nog steeds niet opgelost. Het geeft wel een beetje te denken wat doorontwikkeling betreft t.o.v. Geoserver.

Jullie hebben zo je redenen wat betreft stabiliteit en geheugengebruik om te kiezen voor MapServer ipv Geoserver maar MapServer heeft ook zo zijn nadelen (ook geen CQL_FILTER).
Hopelijk komen er niet nog meer nadelen naar boven.

wouter.visscher 2019-12-11 19:48:24 UTC #4

Hoi @rli, nee daar waren we (ik) niet zo van op de hoogte. Wij zien namelijk met “simpele” FES filters requesten dat mapserver een aanzienlijk stuk sneller is, in bepaalde gevallen een factor 10x. Ik geef toe dat onze testen zich richten op 80% van wat ons verkeer is en dat we met “complexere” FES filters testen geen 100% dekking kunnen creëren op wat allemaal op ons kan worden afgevuurd.

bijvoorbeeld een POST request met FES filter als:

<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="true"><fes:ValueReference>identificatie</fes:ValueReference><fes:Literal>0200100000713326</fes:Literal></fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
</wfs:GetFeature>

Komt vanuit de mapserver stack terug binnen <50ms en vanuit de geoserver stack boven de 400>ms.

Graag zou ik voorbeelden zien van requesten met een FES filters waarin de performance te wensen overlaat? Mogelijk dat we naar de onderliggende queries kunnen kijken. Mogelijk iets met de tijd van de dag? @rli zou jij die kunnen posten?

M.b.t. onze redenen hoop ik dat jij die kan begrijpen waarom wij (PDOK) deze weg hebben (moeten) nemen. Het klopt Mapserver heeft issues net zoals Geoserver en vrijwel ieder stukje software. Hoewel we CQL_FILTER zien als iets “vendor specific” en het creeeren (wat nu de situatie is) van een “vendor lock-in” verre van wenselijk is voor een open data platform.

Hier zit ook de “uitdaging”, een platform bouwen wat werkt voor zoveel mogelijk mensen/use-cases. Hierin kunnen we helaas nooit iedereen 100% facilitieren maar hopen we mensen wel zo veel en goed mogelijk op weg te kunnen helpen met hoe we de data in PDOK “presenteren”. Dat hier dan soms iets buitenboord valt is dan soms een gegeven. Dat gezegd hebben zijn wij altijd bereid om mee te denken over mogelijk alternatieve of andere oplossingen.

Feit blijft dat voor het bouwen van oplossingen tegen PDOK (of iedere NSDI of ander data platform) dit niet een “one-way street” is. Platformen zijn dynamisch (WFS -> OGC OAF, TMS -> WMTS), dat mag dan ook verwacht worden voor de applicaties die daar mee interface.

Dat is iets waar wij natuurlijk geen garanties op kunnen geven.

rli 2019-12-12 14:03:26 UTC #5

Het gaat om een WFS query op ResourceId die je in je originele post hebt geplaatst maar dan niet voor ligplaats maar voor verblijfsobject. Die is zeer traag.

<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:ResourceId rid="verblijfsobject.bag:0153010000320447"/>
</fes:Filter>
</wfs:Query>
</wfs:GetFeature>

De WFS query op identificatie van verblijfsobject en pand is wel snel omdat jullie daar op mijn verzoek een index op hebben gezet.
Echter de WFS query op pandidentificatie van verblijfsobject is nog traag omdat daar nog geen index op staat waarschijnlijk. Deze is nodig om te achterhalen welke verblijfsobjecten bij een pand horen:

<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>pandidentificatie</fes:ValueReference><fes:Literal>0153100000258528</fes:Literal></fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
</wfs:GetFeature>

wouter.visscher 2019-12-13 15:10:09 UTC #6

Hoi @rli,

Wij hebben na aanleiding van jouw vragen de onderliggende queries aangepast voor de https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1. De fes:ResourceId request gaan hiermee voor de verschillende bag objecten nu snel. Wij zien sub 100ms responses hierop.

Voor de pandidentificatie is er een index toegevoegd, hiermee zien wij ook een verbeterde performance.

rli 2019-12-13 15:56:21 UTC #7

Heel fijn, beide queries werken nu snel. Bedankt!

idemag 2019-12-23 22:27:15 UTC #8

Ik zie nog andere verschillen met de oude WFS service:

huisnummer was numeriek, maar is nu een string
huisletter en toevoeging geven een leeg element voor NULL waarden. De oude WFS service liet de elementen weg, zoals je in een xml document zou verwachten. Mogelijk is dit een MapServer eigenaardigheid? Dat zou betekenen dat NULL waarden in andere string velden ook problemen geven.

Geen heel schokkende zaken maar wel onverwacht als het niet wordt vermeld in het overzicht met wijzigingen:

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’

idemag 2019-12-23 22:41:12 UTC #9

In aanvulling op mijn vorige post: Ook ontbrekende postcode worden in v1_1 gepresenteerd als een leeg element.

geonovation 2020-03-26 19:44:08 UTC #10

De featureID van een feature is erg belangrijk voor het terug kunnen zoeken via een featureID in het GetFeature request. Ik zie dat bij outputFormat GML wel de featureID wordt meegegeven , maar bij application/json niet.
Dit is superlastig. We werken namelijk niet met GML, maar natuurlijk met json output.
Dus:
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?request=getfeature&service=wfs&version=2.0.0&typenames=bag:ligplaats&startindex=0&count=1&outputFormat=application/json
Geeft geen featureID, als je outputFormat weg laat dan wel ( dus wel; <bag:verblijfsobject gml:id=“verblijfsobject.0307010000437123”> )
Ook ik vind het echt jammer dat Mapserver nu gebruikt wordt, nu moeten we de WFS van Mapserver, die zich iets ander gedraagt, in onze viewer opnemen. Maar dus die featureID in het resultaat bij JSON is essentieel. Kan die er a.u.b. in ?

EfekE 2020-03-30 12:59:47 UTC #11

Beste BAG-afnemers,

Wij hebben de oorzaak gevonden en werken aan een oplossing. Zodra wij dit getest hebben en willen uitrollen plaatsen wij weer een reactie.

groet, Erkan Efek

geonovation 2020-03-30 13:16:47 UTC #12

Dag Erkan,
Ik neem aan dat dit gaat over het toevoegen van de featureID in de json ouputFormat? Geldt dit ook voor de GetFeatureInfo in een WMS aanroep?
Peter-Paul

wouter.visscher 2020-03-30 14:03:48 UTC #13

Hoi @geonovation (Peter-Paul)

Het ontbreken van het id in de application/json responses hebben wij over het hoofd gezien dit willen we graag herstellen gezien wij ook van mening zijn dat dit de correct oplossing is.
Wat er voor de het response dan ‘mogelijk’ zal veranderen is dat het veld features>properties>identificatie naar features>id ‘verplaatst’.

Is dit in lijn met de verwachting die er is van jouw kant?

Tevens hebben wij het gevoel dat er mogelijk meer dingen spelen gezien de posts. Zoals in eerder posts naar andere gebruikers is aangegeven, willen wij graag met onze klanten meedenken.

Bij deze opmerking willen we graag van jou weten waarom dit jammer is?
Welke gedrag heeft Mapserver ten opzichte van wat jij zou verwachten? Bedoel je bijvoorbeeld het CQL_FILTER?
Voor ons (PDOK) is het namelijk lastig om dit soort informatie te achterhalen, dit soort feedback helpt ons. En dan graag met voorbeelden/linkjes naar jullie implementaties/enz… zodat we van te voren mogelijk afwijkend gedrag kunnen constateren.

Deze proberen we dan ook zoveel mogelijk in lijn te trekken met de WFS json output.

@geonovation zoals eerder in dit topic is aangegeven. Dat services “moeten” wijzigen (door technisch of functioneel redenen) is een gegeven daar proberen we dan ook zo goed mogelijk mee om te gaan en is feedback van onze gebruiker belangrijk. We krijgen het gevoel dat dit door nu niet zo ervaren is door jullie klopt dat? En wat zou er volgens jou dan beter kunnen?

geonovation 2020-03-31 18:30:50 UTC #14

Dag Wouter en Erkan,
De featureId is belangrijk, zodat je weet hoe je bij elk object kunt komen ( als het ware de primary key van een feature, zodat een feature is op te halen met featureID= ). Doordat identificatie niet meer in de properties zit, verwacht ik dat veel afnemers die gaan missen. Het lijkt dubbelop om de identificatie als feature.id op te nemen en als feature.properties.identificatie, maar naar mijn mening is het dat niet. Identifcatie is namelijk een belangrijk attribuut om te tonen. Daarom moet dat ook blijven bij identificatie.
Wat we wel eens tegenkomen is dat een feature niet een eenduidige sleutel heeft. Dus 2 attrributen ( een id en volgnummer) wat het object uniek maakt. Dit is wellicht een niet veel voorkomend voorbeeld, maar het geeft wel aan dat we graag en een feature.id willen hebben en een attribuut wordt ook getoond kan worden.
afbeelding

Mogelijk gemaakt door Discourse, best bekeken met JavaScript ingeschakeld