FME BGT-downloader en BGT-processor

[Terralytics]

Voor de FME-technici onder ons:

De BGT-downloader die ik enkele jaren geleden heb geüpload naar de FME-hub (Safe Software) wordt veel gebruikt. De downloader maakt het mogelijk om direct vanuit FME de landelijke BGT te downloaden via de PDOK-API. De mogelijkheden van de BGT-downloader zijn afgelopen jaren flink gegroeid. Daarnaast waren er nog diverse wensen voor nieuwe functies. De functies van de transformer werden daardoor onoverzichtelijk. Daarom heb ik de transformer nu opgesplitst in twee aparte transformers:

1. De BGT-downloader. Die doet (nu weer) wat de naam al zegt: de BGT downloaden.
2. De BGT-processor. De processor verwerkt de data van de BGT-downloader. De processor is nu geoptimaliseerd voor snelle verwerking. Daarnaast wordt de data nu direct geïnterpreteerd waarbij de meest gangbare attributen (optioneel) worden hernoemd. Hierdoor hoeft niet iedereen iedere keer het wiel opnieuw uit te vinden.

Ik ben erg benieuwd naar jullie feedback!

[Michiel1]

Ik heb hem wat langer geleden geprobeerd te gebruiken, toen werkte het niet. Ik ga dit zeker testen! Super goed dat je dit soort custom transformers publiceert!!

[Geomancer]

Hoi @Terralytics,

Goede actie!
Splitsen in een downloader en een processor maakt het geheel veel overzichtelijker. En het resultaat van de BGT-Processor vergt veel minder nabewerking dan het resultaat van de oude downloader. Je ‘interpretatie’ (‘Processed’) bevalt ook goed.

Tijdens mijn eerste tests heb ik al wel wat aandachtspunten ontdekt:

• Openbareruimtelabels krijgen waarde ‘Weg’ in attribuut BgtType
• Openbareruimtelabels krijgen waarde NULL in attribuut Hoek
• De Nummeraanduidingreeksen lijken volledig te ontbreken.
• In de logfile zie ik de volgende melding:

INFORM|Potentially retrieving dataset ‘https://terralytics.nl/schemamapper’ for reader R_5

In eerste instantie miste ik de Openbareruimtelabels die als multipoint zijn opgeslagen, maar met een Deaggregator zijn die te splitsen in losse puntobjecten.

[Terralytics]

Bedankt voor de feedback @Geomancer! Ik wacht nog wat meer feedback deze week af (nu iedereen langzamerhand de kerstvakantie erop heeft zitten).
De nummeraanduidingsreeksen zijn als het goed is terug te vinden als de panden worden meegenomen als featuretype. De attributen daarvan zijn niet direct exposed. Dat moet dan handmatig nog even worden gedaan.

Ik gebruik inderdaad een Schemamapper voor het hernoemen van attributen zonder ze direct allemaal te hoeven exposen. Die komt van een excelbestand op mijn website. Hopelijk levert dit nergens problemen op. Mocht dat wel zo zijn dan hoor ik het graag.

[Geomancer]

Dom van mij: natuurlijk kunnen Openbareruimtelabels waarde ‘Weg’ krijgen in attribuut BgtType. De BAG kent immers 7 typen openbare ruimten, waaronder ‘Weg’.

In de BGT-processor zijn de attributen voor de Nummeraanduidingreeksen (inclusief BAG-ID van het laagste - en optioneel het hoogste - verblijfsobject per Nummeraanduidingreeks) als list aanwezig.
Dat geldt ook voor de BAG-ID’s van de panden.
Tekst en rotatie van de Nummeraanduidingreeksen zijn in de list als XML opgeslagen.
Deze gegevens zijn ook als list aanwezig wanneer er maar één van bij een pand is (maar ontbreken als er geen bij een pand aanwezig is).

imgeo_identificatie_bagpnd{0}
imgeo_nummeraanduidingreeks{0}.imgeo_nummeraanduidingreeks_imgeo_identificatie_bagvbolaagste_huisnummer
imgeo_nummeraanduidingreeks{0}.imgeo_nummeraanduidingreeks_imgeo_identificatie_bagvbohoogste_huisnummer
imgeo_nummeraanduidingreeks{0}.imgeo_nummeraanduidingreeks_imgeo_nummeraanduidingreeks

Bij de Openbareruimtelabels wordt de rotatiehoek niet correct afgehandeld in SchemaMapper_2, deze zit in
openbareRuimteNaam.Label.positie.Labelpositie.hoek

Maar wanneer een Openbareruimtelabel meerdere labelpunten heeft, wordt een list gebruikt, waarbij elk labelpunt een andere rotatie kan hebben.
openbareRuimteNaam.Label.positie{0}.Labelpositie.hoek

Ik vraag me hier even hardop af, of het zinvol is om de Nummeraanduidingreeksen als aparte objecten uit de ‘Processed’-poort te laten komen.
En ook of het zinvol is om de multipoint Openbareruimtelabels gesplitst naar losse labelpunten uit de ‘Processed’-poort te laten komen (en dit dan eventueel ook nog beperkten tot de labelpunten die binnen de oorspronkelijk opgevoerde polygoon vallen).

[Terralytics]

@Geomancer , het heeft wat langer geduurd dan gepland voordat ik weer met de BGT-processor aan de slag ben gegaan. Maar bij deze! Ik heb afgelopen tijd aan verschillende mensen gevraagd hoe de BGT-processor bevalt. Voor de meeste doeleinden wordt de transformer zonder noemenswaardige aanpassingen in de uiteindelijke attributen toegepast. Er zijn een aantal attributen die ik niet aanpas via de SchemaMapper (zoals labelpositie.hoek) omdat op dit niveau het aantal attributen erg lang is.

Ik heb nog bekeken wat je precies bedoelt met de afhandeling van de rotatiehoek. Maar volgens mij gaat dat wel gewoon goed? Zie onderstaand screenshot. Als een openbareRuimteNaam één label heeft, dan wordt het attribuut teruggegeven zoals in het screenshot zichtbaar is. Als er meerdere labels zijn wordt het als lijst teruggegeven. Aangezien dit bij meerdere attributen zo gebeurt lijkt het me verstandig om dit zo te houden. Of gaat er naar jouw idee echt iets fout en zie ik iets over het hoofd?

Wat betreft de andere vragen in je laatste alinea: ik ben het met je eens dat dit een mooie toevoeging zou zijn voor degenen die dagelijks met nummeraanduidingsreeksen en openbareruimtenamen bezig zijn. Maar ik ben dan bang dat dit weer te specifiek gaat worden. Voor nu kies ik er dus voor om dit zo te houden.

[Geomancer]

Hallo @Terralytics, bedankt voor je reactie.
Naar aanleiding daarvan heb ik even verder gekeken. Mijn conclusie is dat de Openbareruimtelabels uit de BGT-Processor net wat anders moeten worden verwerkt dan ik dacht. Veel Openbareruimtelabels zijn een multipoint, bij punt n hoort dan rotatiehoek openbareRuimteNaam.Label.positie{n}.Labelpositie.hoek.

Bij een pand moeten de gegevens van de Nummeraanduidingreeksen blijkbaar nog achteraf uit de panden worden gepeuterd. Ik had het gebruikersvriendelijker gevonden als de ‘Processed’-uitgang van de BGT-Processor geen post-processing meer nodig had.

Maar dit nadeeltje wordt ruimschoots overtroffen door de voordelen.
Ik vind het erg tof dat je deze BGT-downloader en BGT-processor hebt gemaakt, en gratis ter beschikking stelt!

[Terralytics]

Bedankt voor de feedback @Geomancer ! Fijn om te horen dat de transformers goed worden gebruikt.