BAG v1_1 WFS wijziging

Ik krijg het idee dat de lijst met properties afkomstig is van de ‘ouwe’ bag wfs: https://geodata.nationaalgeoregister.nl/bag/wfs?request=describefeaturetype&service=wfs&version=2.0.0&typename=bag:pand

Is deze aanname correct?
Is deze lijst met properties dynamisch of statisch in de applicatie?

De laatste versie van de 1_1_beta werkt voor mijn use case nu zo goed als identiek aan de bestaande 1_1. :+1:

2 likes

Dit is inmiddels opgelost. We geven de lijst met properties niet meer door in het WFS request. Het lijkt me nog steeds wel dat de Id altijd onderdeel moet uitmaken van het resultaat want staat ook niet onder properties in JSON.
@wouter.visscher @Jeroen_D Wanneer gaat de beta versie in productie? Toch wel voor 1 juli hoop ik.
Anders zou ik willen verzoeken om de oude BAG WFS nog niet uit productie te nemen op 1 juli.

@rli daar kan mijn collega @EfekE het meeste over zeggen (die is er vandaag niet dus dat zal volgende week worden).

@EfekE Wanneer gaat de beta versie in productie? Toch wel voor 1 juli hoop ik.
Anders zou ik willen verzoeken om de oude BAG WFS nog niet uit productie te nemen op 1 juli.

Beste Ron,

Het streven is om de beta voor 1 juli in productie te zetten, afhankelijk van de tests door afnemers. We houden jullie op de hoogte.

groet, Erkan

Ok, dat zou mooi zijn. Voor zover ik kan overzien werkt het goed.
Bij Kadaster V4 werkte het al goed en dat is dacht ik ook een MapServer implementatie? Waarom was dat bij BAG dan een probleem?

De werkwijze met FeatureID is nu bij de BAG gelijk aan de DKK gemaakt.

@EfekE De beta BAG 1.1 WFS werkt niet meer: https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1_beta?service=WFS&request=GetCapabilities

Bij de WFS zonder _beta hebben we nog geen featureid.in JSON.
Wanneer wordt dit opgelost?

De …/bag/wfs/v1_1_beta hebben we moeten hernoemen naar /bag/wfs/v1_2-preprod in verband met architectuur richtlijnen/URL strategie. Gezien de v1_1_beta het idee geeft dat dit de ‘voorloper’ is/was van de v1_1 (terwijl dat niet het geval was).

Vandaar dat er nu de …/bag/wfs/v1_2-preprod is, die dan mogelijk (?) naar een v1_2 versie gaat. Ik was in de veronderstelling dat dit al ‘communiceert’ was naar “iedereen” die van het bestaan van de v1_1_beta wist… excuses dat we jou zijn vergeten. Ter volledigheid het is niet het idee dat we deze URL ‘breedt’ verspreiden qua nieuws berichten/enz…

https://geodata.nationaalgeoregister.nl/bag/wfs/v1_2-preprod?service=WFS&request=GetCapabilities

Ik zit al 2 dagen te testen met WFS en POST, maar mijn POSTMAN geeft niets meer terug. Ook onze applicatie niet meer. Dit geldt voor: https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1 en voor https://geodata.nationaalgeoregister.nl/bag/wfs/v1_2-preprod . Ben ik de enige die geen POST meer kan doen?

@geonovation

Post berichten gingen alleen fout in Post requesten zonder querystring.
Dit is nu opgelost.

Hallo iedereen,

Bovenstaande was heel nuttig, ik heb de nieuwe manier aan de praat gekregen. Alleen met CGL_FILTER was het mogelijk om de verblijfsobjecten binnen een pand te bepalen. Is dit nu nog steeds mogelijk? Ik probeerde TYPENAMES=bag:verblijfsobject&featureId=pand.bag:PAND_ID maar die geeft alleen het BAG pand.

Weet iemand hoe ik dit voor elkaar kan krijgen?

Alvast bedankt,

Jelmer Oosthoek

Hoi @jhpoosthoek,

Dit onderwerp is al vaker langsgekomen in andere topics hier op 't forum:

Maar samengevat kan je dit met een ‘standaard’ OGC WFS FILTER parameter oplossen, door bijvoorbeeld het volgende request te doen:

https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?request=getfeature&service=wfs&version=2.0.0&typenames=bag:verblijfsobject&filter=<Filter><PropertyIsEqualTo><PropertyName>pandidentificatie</PropertyName><Literal>0388100000203974</Literal></PropertyIsEqualTo></Filter>

het filter parameter bevat dus een stukje XML/GML waarmee je een specifiek pandidentificatie (of meerdere) kan meegeven en zo de gerelateerde vbo’s bij een pand kan vinden.

<Filter>
    <PropertyIsEqualTo>
        <PropertyName>pandidentificatie</PropertyName>
        <Literal>0388100000203974</Literal>
    </PropertyIsEqualTo>
</Filter>

1 like

Dank voor je antwoord, dat was precies wat ik zocht.

1 like