In een ander draadje heeft Gertjan e.e.a. gemeld over een JOSM BGT plugin. Om de discussie gescheiden te houden open ik maar even een nieuw draadje.
Ik heb het inmiddels werkend en bekeken en moet zeggen dat het er al goed uitziet. Knap staaltje werk.
Ik heb het resultaat van de plugin vergeleken met het resultaat van mijn script dat voor BGT2OSM gebruikt is.
De plugin is erg prettig werkbaar en veel handiger dan op verzoek bestanden mailen zoals bij BGT2OSM
De plugin heeft zo te zien nog niet de geometrie vereenvoudigd en dat is te zien. Zie verschil plaatje 1 en 2.
De plugin houd geen rekening met het uitsnijden van de building polygonen bij de erfdelen. Zie verschil plaatje 3 en 4.
Ik zie een paar area:highway=cycleway waar âbridge=yesâ staat maar er geen brug te bekennen is.
Het is een mooi stukje werk Gertjan maar net als bij BGT2OSM blijft ook hier wel de vraag of en hoe we e.e.a. in OSM kunnen inpassen. Ook als alle âissuesâ opgelost zijn. Maar goed ⌠dat gaan we wel zien.
Als je een landcode in een ref-sleutel stopt, is het gebruikelijk om na de landcode een dubbele punt te gebruiken in plaats van een underscore, dus dan zou het ref:NL:BGT moeten zijn in plaats van ref:NL_BGT.
Dank voor de tip. Ik heb het aangepast in mijn ontwikkel omgeving. Over of en hoe we deze tag gaan gebruiken moeten nog afspraken gemaakt worden. Nu is het een lokaal id van de data eigenaar.
Klopt. Dit is nog even een uitdaging, omdat bij vereenvoudigen van de geometrie de aansluiting tussen de nodes van twee aangrenzende vlakken verloren kan gaan. Hoe heb jij dat aangepakt?
In de ontwikkel ontwikkel omgeving heb ik dit aangepast. Heel rigoureus zelf, door alle gaten uit alle polygonen te halen en waar mogelijk te versimpelen tot een OSM Way. Dit sluit beter aan bij de OSM werkwijze. Voor uitzonderingen kan ik de gaten weer opnemen.
Was mij ook opgevallen en heb ik gerepareerd in de ontwikkel omgeving. Naar bruggen en tunnels moet ik nog eens kijken.
Binnenkort zet ik een nieuwe versie van de plug-in klaar. Die is ook beter bestand tegen het per abuis uploaden van de BGT laag, of downloaden van OSM data in de BGT laag.
Ik stop eerst alle features in 1 postgis tabel en daarna gebruik ik de window functie ST_CoverageSimplify zodat bij het versimpelen van de geometrie rekening wordt gehouden met de omliggende/aansluitende geometrien.
Ik heb de plug-in even getest maar dat is inderdaad een stuk handiger dan een export halen en dan door bgt2osm halen.
Wat me op viel is dat als je eenmaal een gebied hebt binnen geladen en je dat nog een keer wilt doen, de download lijkt te gebeuren (geen foutmelding o.i.d.) maar in de praktijk geen data is binnen geladen. Ik heb geprobeerd met zowel de âDownload modified areasâ checkbox aan en uit.
Ik weet niet of ik je helemaal begrijp. Met BGT2OSM lever ik een min of meer kant en klaar bestand van een select gebied. Daar hoeft een ontvanger niet veel meer mee te doen behalve het goed inpassen in OSM en dat is weer, net als met de plugin, veel werk.
Wat ik er mee wilde zeggen dat in josm Data > NL BGT > Download toch een stuk sneller is dan naar de site te gaan daar een download te doen en vervolgens door bgt2osm trekken. De route via jou heeft nog meer doorlooptijd.
Zolang je niet al te complexe data hebt (MPâs, vlakken die aan elkaar zitten met gedeelde ârondâ vlak etc.) is er, voor mij, ook prima mee te werken, met Shift-J vlakken samen voegen en met Shift-Y de vlakken vereenvoudigen.
Bij BGT2OSM hoeft niemand naar een site te gaan en iets te downloaden hoor. Een verzoek om data in dat draadje (of via PM) volstaat als je daar aangeeft voor welk gebied je data wil ontvangen. Nog makkelijker voor mij is als de bounding box wordt opgegeven bv.
5.352, 52.113, â bounding
5.41, 52.174, â box limits
BGT2OSM is nog in experimenteel stadium. Mocht de kwaliteit voldoende blijken en er een goede werkwijze komen om die data in OSM te krijgen dan is het wel de bedoeling het uitlever proces aan te passen zoals in de wiki beschreven. Misschien wel een combinatie van BGT2OSM en een plugin
Ik begrijp dat een plugin makkelijker werkt en een oplossing via een plugin heeft ook zeker mijn voorkeur maar vereist momenteel m.i. meer nabewerking dan een bestand dat ik lever. En bij veel polygonen krijg ik het niet voor elkaar om de geometrie (voldoende) te versimpelen waardoor er m.i. veel te veel nodes blijven bestaan.
Ik hoop echt dat Gertjan het voor elkaar krijgt om de huidige issues op te lossen want via een plugin werkt wel zo lekker.
Beide werkwijzen hebben voor- en nadelen.
Een belangrijke beperking van de plug-in is het niet kunnen versimpelen van de geometrieen van vlakken. Dat kan alleen in relatie tot de aangrenzende vlakken. Die hebben echter weer andere aangrenzende vlakken etc., tot aan de grenzen met de buurlanden. BGT2OSM kan dat wel oplossen omdat daar heel Nederland in staat.
Een oplossing zou kunnen zijn om de resultaten van BGT2OSM in een database te zetten, deze regelmatig te updaten en die database te benaderen met de BGT plug-in. Dan moet er wel iemand (liefst meerdere personen) zijn die deze database wil en kan hosten en onderhouden. Dat is best veel gevraagd voor een vrijwilliger.
Ook de plug-in is nog in een experimenteel stadium. Met behulp van jullie terugkoppeling wil ik proberen om zoveel mogelijk van de BGT2OSM nabewerkingen in te bouwen. @PeeWee32, heb jij een overzichtje van de nabewerkingen die BGT2OSM doet?
Even wat meer info over BGT2OSM. Zie overigens ook de wiki. Ik maak dit met een sql script dat losgelaten wordt op beperkte boundingbox (bv een wijk , dorp of een deel van een stad) . Het is dus niet zo dat ik heel NL al klaar heb staan in een tabel/database. (Of dat uberhaupt mogelijk is vraag ik me af maar dit terzijde.) Dus voor ieder verzoek moet ik het script draaien en dan is ie zoân 10 a 30 min bezig afhankelijk van de Bbox..
Het script is in de loop van een flink aantal maanden gemaakt waarbij telkens geanalyseerd moest worden of het tussen resultaat nog âlogischâ was. Het script is niet opgeschoond waardoor het nogal een aantal overbodige stappen lijkt te hebben. Zo check ik na veel stappen of er geen overlap tussen polygonen is of dat er gaten vallen. Het script is dus nog niet âgithubâ waardig maar als je een kopie wil kan ik het je wel sturen.
Ik heb een aantal handelingen die worden uitgevoerd. Samengevat doe ik de volgende stappen startend met de BGT_Full DB van Geotoko (want BGT_lean leverde issues op)
Maak je Bbox van het gewenste gebied.
Haal van een groot aantal tabellen (features) het Bbox deel op en valideer de geometrie. Dat zijn niet alleen de vlakdekkende maar ook features als âoverigbouwwerk_vlak, kunstwerkdeel_vlak en pand_vlakâ omdat deze vaak inners zijn van andere multipolygonen.
Alle tabellen worden in 1 tabel gestopt met een beperkt aantal attributen waaronder âtabelnaamâ, functie, plus_functie, type, plus_type, bgt_fysiekvoorkomen, plus_fysiekvoorkomen, hoogteligging)
Alle inners van vlakken die weg kunnen (omdat de inner bv een pand is) worden verwijderd zodat bv de gaten in erf delen verdwijnen.
Pandgeometrien die naast een andere liggen geven hun geometrie door aan de âbelangrijksteâ naastgeleven geometrie (anders krijg je gaten omdat we panden niet meenemen (BAG)).
Polygonen die naast elkaar liggen en zelfde attributen hebben worden samengevoegd.
De geometrie wordt versimpeld met de functie ST_CoverageSimplify.
Alle wegdelen geef ik OSM attributen mee (o.a. name, highway) zodat ik later alleen wegdelen samenvoeg van de zelfde straatnaam.
Wegdelen zonder naam (bv de stoep) geef ik de naam mee van de naast gelegen weg.
Wegdelen worden samengevoegd mits ze de zelfde attributen hebben.
Van alle gewenste Keys in OSM wordt een kolom toegevoegd met waarde"magweg"
Alle key kolommen worden geupdate obv de BGT features waardoor bv bouwland wordt farmland.
Geometrie conversie naar EPSG4326
Het resultaat (=1 tabel) wordt door ogr2osm gehaald.
Dat resultaat wordt middels een python script ontdaan van alle keys met de waarde âmagwegâ
M.n. het samenvoegen van wegdelen was een behoorlijke klus waarvan je je kan afvragen of dit nodig is want willen we de wegdelen wel in OSM hebben? En het proces om OSM te verbeteren zitten ze behoorlijk in de weg is mijn ervaring.
Ik heb de nieuwe versie (0.1,2) van de plug-in klaar gezet. Deze versie verwijdert gaten (inner ring) uit polygonen. Dat scheelt enorm in het aantal OSM multipolygonen. Daarnaast is er een betere beveiliging tegen het per abuis uploaden van BGT data naar OSM en tegen het per abuis downloaden van OSM data in de BGT laag.
Er is nu de street:name tag in gebruik zodat de kaart niet vol gepleistert wordt met zelfde naam naast elkaar. Key:street:name - OpenStreetMap Wiki Heeft 15K gebruik volgens taginfo⌠het is vrij nieuw.
Gebruik dit ook of langslopende fietspaden, en de vele hier gedeelde voet/fietspaden (ready for the future, er is per April 2025 1 cyclerouter die dit meeneemt)
Even voor de duidelijkheid over BGT2OSM. Die name tag gebruik ik alleen om polygonen samen te kunnen voegen. Ze worden niet meegegeven in het .osm bestand en komen dus ook niet in OSM terecht.
Klinkt mij als taggen voor de renderer maar heb me er niet in verdiept. Ik tag sowieso geen name op een sidewalk die los ingetekend is maar ik teken ook geen stoep los in.
Er zijn geen wegdelen meer te zien maar ik vermoed dat dit bewust is en ik denk dat het een goede keuze is (het is al complex genoeg) .
Als ik de validator draai krijg ik best veel errors en warnings. Een aantal is op te lossen middels de FIX knop maar niet allemaal. Er zijn relatief veel (meer dan BGT2OSM) overlapping polygons en die moeten nu handmatig opgelost worden.
Als ik een 3e , 4e etc. gebied probeer binnen te halen dan lukt dat niet omdat er dan telkens maar een paar features meekomen.JOSM sluiten en opnieuw opstarten lost dat weer tijdelijk op.
Dank je wel voor het overzicht. Daar zitten inderdaad nog wel wat uitdagingen in. Stap 1 t/m 3 zijn voor de plug-in vergelijkbaar.
Dit doet de plug-in vanaf versie 0.1.2 ook. Op dit moment voor alle inners (binnenringen), omdat ik behalve trap-doorgangen in perrons nog geen binnenringen in beeld heb die niet weg mogen. Dit sluit m.i. beter aan bij de OSM werkwijze en scheelt enorm in het aantal multipolygonen.
Bedoel je met ââbelangrijksteâ naastgeleven geometrieâ de landuse=residential (BGT erf)? Ik ga kijken of ik dat in de plug-in kan inbouwen.
Resulteert dit niet in heel grote polygonen? In het utreg.osm bestand dat je voor mij gemaakt hebt zijn meerdere grachten/stukken singel aan elkaar geknoopt. Ik ga kijken of ik dit in de plug-in kan inbouwen, maar dan misschien wel met een beperking in de grootte van de vlakken.
Welke tolerantie gebruik je hier bij? En wat doe je aan de randen (simplifyBoundary waar of onwaar)? In de plug-in kan ik het wel-of-niet versimpelen van de randen misschien als keuze optie opnemen.
Ik kan geen namen vinden van wegdelen. Waar haal je die vandaan? Zoals je later in je tekst al stelt, is het nog de vraag of we de wegdelen in OSM willen hebben en of dit samenvoegen dus relevant is. Voor de plug-in nog even niet relevant. Op termijn kunnen de weg vlakken misschien wel helpen om de middellijnen van de wegen op hun plek te leggen, maar dat is van later zorg.
Wat ik nog mis in dit stuk is het omgaan met niveau verschillen (bridge=yes etc.). Zitten daar nog bijzondere dingen in, of voeg je bridge=yes toe aan wegdelen als relatieve hoogteligging>0 ? Het Gouwe aquaduct bij Gouda is in de BGT trouwens als tunnel ingetekend. Daarvoor moeten we misschien een uitstapje maken naar de DTB dataset van Rijkswaterstaat. Dat kent wel aquaducten. Ook toekomstmuziek.
Binnenkort begin ik met re-integratie na een ziekteperiode. Dan zal ik dus minder tijd beschikbaar hebben dan nu.
Ik vindt het een slechte zaak, als de wegdelen niet worden meegenomen.
Later inpassen is een hele klus.
Mijn grootste zorg is, het in de loop van de tijd aansluitbaar kunnen werken. Dat de eerder geuploade data naar OSM, later over een tijd maand(en) jaar, nog aansluit. Zeg maar stabiel is in uitvoering. Dat de hoeveelheid nodes, plaats van de nodes, bij niet wijzigende BGT geometrie nog hetzelfde zijn.
Eerste keer gebruik plugin:
De wegdelen zijn er deels aanwezig.
( area:highway landcover visualisatie, ten dele gemaakt)
Na weggooien layer een tweede keer de data van onderstaande plaatjes ophalen lukte niet.
Er zijn multipolygonen (bv bos) waarvan een binnenring een combinatie van een pand en bv een stuk erf is . Dat is lastig op te lossen.
Ja .. zo ongeveer wel. Ik heb dan een hierarchie van waar de prio ligt om mee samen te voegen. onbegroeid terreindeel heeft hoge prio.
In theorie wel maar ik heb een maximale grootte van 500meter (ST_longest_line) van de nieuwe geometrie dus super groot gaat het niet worden.
Ik gebruik dit:
ST_SetSRID(ST_CoverageSimplify(c.geometrie_vlak, 0.075,false) OVER (partition by c.relatievehoogteligging) ,ST_SRID(c.geometrie_vlak)) as geometrie_vlak
De data die ik uitlever is m.n. bedoeld voor het deel binnen de randen al ik ik dat nog niet goed gecommuniceerd. Aan de randen zie ik wel vaker data issues nl.
Ik was niet helder. Ik pak OSM highway en plot die op de BGT wegdelen en probeer zo de naam aan dat wegdeel toe te wijzen. Vervolgens heb ik nog een paar stappen om ook de wegdelen die in eerste instantie niet door de OSM line geraakt worden ook van een naam te voorzien. Dit alles met als enkel doel om alleen wegdelen samen te voegen die bij elkaar horen (o.a. qua straatnaam) .
Ik hou (naast relatieverhoogteligging) ook nog rekening met features âoverbruggingsdeel_vlakâ en âkunstwerkdeel_vlakâ voor het bepalen van bridge. Ik zal je mijn SQL wel sturen dan is het hopelijk duidelijker (of niet )
OSM en BGT kan wel wachten hoor⌠er zijn belangrijker dingen in het leven. Succes met de reintegratie/herstel.
Dit was niet mijn intentie. Heb je een voorbeeld waar dit gebeurt? Het lijkt per gemeente te verschillen en in âmijnâ Utrecht gaat het wel goed.
Bij niet-gewijzigde geometrie blijft de aansluiting stabiel, tenzij we het algoritme wijzigen. Daarom is het belangrijk om eerst een consensus te hebben over het beste algoritme voordat we massaal gaan importeren.
Kan je de locatie aangeven waar dit ten dele gebeurt?
Dank voor de tip. Dit is niet de beveiliging. Ik houd bij welke objecten al gedownload zijn om te voorkomen dat ze 2 keer gedownload worden. Ik had er nog niet aan gedacht dat dat lijstje leeg gemaakt worden als de BGT laag verwijderd wordt. Ga ik aanpassen.
Dit is bewust gedaan. Het is redelijk standaard in OSM om niet alles uit te snijden. Dat scheelt een boel multi-polygonen die OSM onnodig complex maken als het niet nodig is. Dit kan niet in alle gevallen. Het eerste voorbeeld hiervan zijn de trapopeningen in perrons.
)