Je mist de boodschap van mijn bericht. Op dit forum reageer je netjes en vriendelijk, hoe gefrustreerd je ook bent.
3 likes
Dit is nou een vraag waar ik inhoudelijk wel wat mee kan.
Ik begrijp goed dat dit soort verschillen vragen oproepen. De verschillen zijn echter goed te verklaren.
De belangrijkste oorzaak is:
De WFS bevat alleen huidige objecten (zie de link die ik eerder deelde) en de XML bestanden bevatten ook historie (bijvoorbeeld voorkomens met een einddatum of objecten met een eindstatus).
Dat er verschillen zitten tussen de WFS en de XML-bestanden is overigens logisch. De WFS voorziet in een andere behoefte dan de xml-bestanden. Voor WFS gebruikers is historie over het algemeen niet interessant, voor gebruikers van de xml-bestanden juist wel.
Je kunt gegevens van de WFS en de XML-bestanden dus niet zo maar met elkaar vergelijken. Het zijn in zekere zin verschillende datasets. Je zult dus de huidige voorkomens uit de xml bestanden moeten filteren.
De oranje locaties op de kaart zijn de locaties van verblijfsobjecten die inmiddels niet meer bestaan. Het oranje puntje in de hoek van asterstraat 31 hoort bijvoorbeeld bij verblijfsobject 0268010000002345. Dit verblijfsobject is in 2016 ingetrokken omdat het gebouw wat er stond gesloopt is. In 2017 is er vervolgens op dezelfde locatie een nieuw pand gebouwd met een nieuw verblijfsobject 0268010000097610. Omdat de xml-bestanden ook de ingetrokken objecten bevatten, zie je dus daarvan meer puntjes terug dan bij de WFS.
1 like
Ik moet zeggen dat ik je frustratie heel goed begrijp, maar ik ben het wel met Anton eens. Probeer hier althans een beetje positief te blijven. En vergeet niet dat het Geoforum geen helpdesk is, maar een verzameling vrijwillige enthousastelingen, die dus net zo makkelijk kunnen zeggen: nou, daar waag ik me niet aan, en je dus geen enkele reactie meer krijgt.
En heel belangrijk: help ons om jou te helpen. Je hebt al een aantal keer aangegeven dat “de WFS” onbetrouwbaar is. Maar je hebt verder niks gezegd over hoe je die wfs aanspreekt, hoe je met de resultaten om gaat, welke vraag je stelt aan “de WFS”, om welke wfs het gaat, welke software je gebruikt, enzovoorts. En dat heeft allemaal invloed op wat jij uiteindelijk als eindresultaat ziet. Heb je wel eens gelet op het feit dat het antwoord van de WFS beperkt is tot een bepaald aantal, en dat als jouw antwoord meer objecten bevat, je dan zelf via paginering de rest van de resultaten moet ophalen? Dat kan de lege plekken veroorzaken die jij ziet. Maar daar kunnen we niets over zeggen omdat we geen idee hebben hoe je eigenlijk exact de dingen doet, dus wij kunnen ook niets reproduceren.
Dat gezegd hebbende: ja, de BAG is veel te gecompliceerd gemaakt. Ben ik met je eens. Maar we moeten het er wel mee doen. En er zitten regelmatig fouten in de BAG, kom ik in mijn werk ook heel vaak tegen. Maar in plaats van daar op te foeteren, meld ik die fouten terug, en neem deel aan DisGeo, en leer te werken met de BAG zoals ze nu is. Er is wel wat aan te merken op vrijwel alles wat er in PDOK zit, en soms doe ik dat ook.
5 likes
Die conclusie had ik ook getrokken, alleen: De historische objecten hadden eruit gefilterd moeten zijn (ik heb de filteroptie toegepast zoals eerder in dit topic beschreven)
De frustratie heb ik echt lang voor me gehouden. Het probleem is dat het Kadaster haar eigen dataset niet meer lijkt te begrijpen. Voorbeeld: Het niet kunnen genereren van een geopackage, ondanks jaren van beloften. Ook het doorschuiven van verantwoordelijkheid (Dat was de gemeente Purmerend…) is echt een probleem (als de versnellingspook van je Peugeot stuk is, bel je dan de dealer, of ga je uitzoeken wie de pook aan Peugeot geleverd heeft?). Een dataset als dit gaat alleen maar complexer en complexer worden. Het Kadaster lijkt de greep nu al te verliezen, over een paar jaar wordt dit een drama (ik werk bij een waterschap, je hoeft me niets te leren over datasets die een drama worden).
Sidenote: Ik snap de redenen voor het behouden van de historie. Er is geen reden voor het bewaren van fouten. En fouten op zich zijn niet erg, die kom ik vaak zat tegen in datasets (en ik maak daar ook melding van). Maar dit gaat wat verder dan wat foutjes in de data.
WFS: Ik gebruik hier Qgis en FME voor. In FME heb ik:
- Alle wfs opties geprobeerd (1.1, 2.0).
- Geprobeerd per buurt (CBS) binnen te halen
- geprobeerd met tegels (tot zelfs een resolutie van 100 x 100) binnen te halen.
Ik blijf continu records missen. Willekeurige records. Dus gewoon 15x compleet de wfs leeghalen en op duplicaten checken is serieus een optie.
Ik wil dit in FME doen omdat ik dan alles in 1 pakket kan doen. Tot nu toe lukt echt alles (eventueel een enkele keer via commandline/systmcaller/pythoncaller) in FME. Ik kan dan ook gebruik maken van FME server.
Het probleem is hier dat het eigenlijk geen dataset is van het Kadaster, maar van elke gemeente. Kadaster beheert alleen de landelijke voorziening waar elke gemeente haar gegevens aan aanlevert. Dus daar zitten wel aardig wat haken, ogen en valkuilen vrees ik. Ik kan me voorstellen dat het Kadaster haar vingers niet wil branden aan individuele gegevens, en zichzelf alleen als doorgeefluik ziet. Niet dat ik het daarmee goed wil praten, maar in een polderend landje als NL zijn dit soort constructies niet bevorderlijk voor de afnemers. Vergelijkbaar met bronhouders in de BGT…
Tot op zekere hoogte ben ik het met je eens. Waar ik het niet met je eens ben, is de historie van geplande bebouwing. Ik zie op sommige plekken langs komen dat men 3 of 4 keer een omgevingsvergunning indient en weer intrekt met telkens een ander grondplan van het nieuw te bouwen huis. Naar mijn mening heeft het geen enkele zin om die volledige historie te bewaren. Naar mijn mening zou 1 enkel vlak van een bouwput als geplande bebouwing, vervolgens alleen het daadwerkelijk gerealiseerde gebouw, met een indicatie gesloopt als het weer weg is, en eventuele verbouwingen. Al die overige verschillende voorkomens gaan nergens over als je het mij vraagt. Ik zie daar ook veel te grote verschillen tussen op sommige plekken (Waterloopbos is een prive projectje van me, daar zie je hele rare dingen…).
Dit vind ik vreemd, want herken ik absoluut niet. Ik gebruik zelf ook FME, zowel prive als professioneel, beide ook in combinatie met QGis. En dit is niet iets wat ik eerder ben tegen gekomen, tenzij het met het maximum aantal objecten en de paginering te maken had. Wat ik wel merk, is dat de nederlandse bestandsformaten door FME niet als zodanig herkend worden. Als een PDOK service aangeeft een CityGML terug te geven, en ik lees 'm als zodanig met FME, dan gaat dat vrijwel nooit goed. Idem met GeoJSON. Ik val dus meestal terug op de basis (XML en JSON) en haal die vervolgens zelf uit elkaar en bouw er features van. Frustrerend? Ja zeker, enorm. En ik heb het ook al verschillende malen aangekaart hier.
Maar ik ga wel eens kijken naar die WFS met FME. Welke URL gebruik je? Op welke plekken zie je gaten vallen? Is dat landelijk gebied of stedelijk gebied? In het laatste geval loop je een groot risico op het overschreiden van het aantal objecten, en dan is een Custom Transformer die over het aantal pagina’s heen loopt noodzakelijk. Heb ik al eens eerder gebruikt om alle Rijksmonumenten uit de RCE te trekken voor alle gebieden van mijn werkgever, en dat werkt prima.
Geplande bebouwing is dan ook zeker geen fout, ook ik zou die data graag (blijven) zien. Een pand dat heel Nederland beslaat of enkele tientallen kilometers doorloopt in de Noordzee is overduidelijk een fout en heeft geen plek in wat voor dataset dan ook. Wall of shame datasets uitgezonderd misschien
Dit is exact het probleem. De wijze van ontsluiting is onnodig complex en frustrerend. Vragen hierover worden genegeerd. Vragen naar een Geopackage (telefonisch) worden beantwoord met dat dat erg ingewikkeld is (goh…). Ergens schokkerend en verontrustend trouwens.
Ik mis willekeurige panden (elke keer anderen) in stedelijk gebied. Volgens mij is de max die je in 1x kan opvragen 1000. Ik ben tot tegels van 100x100 gegaan (dat duurt veel te lang, maar goed) en dan nog mis ik panden. No way dat er meer dan 1000 panden in een stukje van 100 x 100 staan in een provinciestad. Shit in = shit out. Dus mijn analyses zijn compleet waardeloos bij dit inconsistente resultaat van de WFS (Meermaals gemeld, nooit een reactie op gehad). Ik ben hierdoor gedwongen de XML’s te gebruiken met alle bijbehorende frustraties. Ik gebruik: https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1
Het is voor iedereen echt héél eenvoudig om op zijn minst een paar geautomatiseerde checks in te bouwen bij aanlevering. Geometriefouten, ligt het pand wel in de aanleverende gemeente, is een pand kleiner dan x hectare. Dat de gegevens door derden worden aangeleverd ontslaat het Kadaster niet van een inspanning om te zorgen dat de gegevens geen te grove fouten bevat en om niet de verantwoordelijkheid door te schuiven.
De gemiddelde autofabrikant heeft duizenden toeleveranciers. Toch ga je voor een garantiekwestie naar de dealer en niet op zoek naar de toeleverancier die het foutieve onderdeel aan de fabrikant geleverd heeft. Dat is aan de dealer die daar ook de juiste kanalen voor kent.
Als Kadaster zijn we inderdaad ‘slechts’ beheerder van de Landelijke Voorziening. Het is wettelijk bepaald dat gemeenten verantwoordelijk zijn voor de inhoud van de registratie. Onze wettelijke taak is ook dat we de gegevens van gemeenten moeten verwerken in de Landelijke voorziening. Het past niet binnen onze taak mutaties op inhoudelijke gronden te weigeren. Onze speelruimte is daarmee beperkt.
Verder is het ook in regelgeving vastgelegd dat fouten in de BAG niet mogen worden verwijderd. Het toekennen van een tijdstip Niet BAG is de enige manier waarop fouten gecorrigeerd kunnen worden. Het is voor (een deel van de) afnemers belangrijk dat ook de historie van fouten is terug te vinden.
Het is overigens wel onze taak gemeenten te ondersteunen bij het uitvoeren van hun taak als bronhouder van de data. Zo hebben we het mogelijk gemaakt eenvoudig fouten terug te melden via de BAG-viewer en voeren we maandelijks kwaliteitsrapportages uit die we in een dashboard terugkoppelen aan de bronhouders. Er is trouwens ook een kwaliteitsdashboard voor afnemers: BAG kwaliteitsdashboard voor afnemers - Kadaster.nl zakelijk
De vergelijking met een autodealer en een autofabrikant vind ik enigszins gevaarlijk, zo simpel ligt het niet zoals Pieter al aangeeft. er spelen allerlei wetten mee die dit beinvloeden.
Bovendien vrees ik dat je hiermee het aantal panden onderschat:
Vrijwel overal worden tuinhuisjes ook als pand opgenomen, dus dat loopt al heel snel enorm op.
Dat gezegd hebbende: De WFS adverteert niet duidelijk, en naar mijn mening niet voldoende, dat paginering ondersteund word en in sommige gevallen noodzakelijk is. Er staat zelfs nergens op de pagina’s van PDOK, althans niet dat ik dat kan vinden, dat de responses beperkt worden. En als ik een gewoon request stuur, dan krijg ik 1000 resultaten terug, zonder enige indicatie dat er meer resultaten zijn. Pas als ik count=“1000” toevoeg aan mijn request, krijg ik de indicatie dat mijn request meer dan die 1000 resultaten bevat, in de vorm van een numberReturned=“1000” en een next attribuut.
Dat zou wel wat duidelijker in de documentatie op PDOK mogen staan vind ik (Geo services - PDOK)
Ter reproductie:
POST de volgende GML naar https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1:
<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs"
service="WFS"
version="2.0.0"
xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<wfs:Query typeName="bag:pand"
srsName="urn:ogc:def:crs:EPSG::28992"
xmlns:ogc="http://www.opengis.net/ogc">
<ogc:Filter xmlns:ogc="http://www.opengis.net/ogc">
<ogc:Not>
<ogc:Disjoint>
<ogc:PropertyName>geometrie</ogc:PropertyName>@Value(_geometry)</ogc:Disjoint>
</ogc:Not>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>
(Edit: @Value(_geometry) is FME-speak, de inhoud van dit attribuut bevat de grens van de gemeente Hoorn in GML)
Levert eenvoudigweg een featurecollection van 1000 features op. Pas als ik aan de header het count-attribuut toevoeg:
<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs"
service="WFS"
version="2.0.0"
count="1000"
xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Dan komt er in het resultaat een numberReturned en een next attribuut mee. Qua documentering en melding zou daar wel wat aan gedaan kunnen worden lijkt mij, bijvoorbeeld bij meer dan 1000 resultaten zonder count een http 206 teruggeven, of een foutmelding met iets als “request genereert meer dan 1000 resultaten, probeer met paginering” of iets dergelijks.
En het zou prettig zijn als dat ook op Geo services - PDOK (en alle andere plekken waar een gelimiteerde WFS aangeboden word) vermeld word. @PieterDijkstraBAG, is dat iets dat jullie kunnen initieren, of is dat meer iets voor @wouter.visscher?
Ikzelf merk dit al nauwelijks meer, omdat ik in FME gebruik maak van een custom transformer voor dit soort requests, die automatisch loopt net zo lang tot ie alle resultaten binnen heeft. Erfenis van anderhalf jaar geleden 
1 like
Als de tekst op de website moet worden “aangescherpt” dan ligt dat niet (direct) in mijn invloed. Dus het klopt dat mogelijk @PieterDijkstraBAG en @Rob_PDOK hier naar kunnen kijken.
@sbjager: Qua beschrijving/documentatie geldt (gold? lang geleden al gemeld) hetzelfde voor de API. Nergens stond (staat?) dat er max 20 per pagina waren. Dus ik heb daar veel tijd in gestoken, wat weer geresulteerd heeft in een forse schep extra op de berg kadasterfrustraties.
Ik ben er overigens voor de volle 100% zeker van dat ik gebieden heb gekozen die minder dan 1000 panden zouden moeten opleveren. Geen enkele twijfel.
@PieterDijkstraBAG Bedankt voor de uitleg. Ik snap niets van de logica achter deze afspraken, maar meen wel te bespeuren wat ik bij mijn waterschap ook veel zie: doorschuiven van verantwoordelijkheden. Wat ik ook weet: Dit soort afspraken zijn een garantie op chaos.