Fouten door BAG-updates

Het valt mij op dat er (volgens mij) door BAG-updates relatief veel fouten ontstaan met betrekking tot gebouwen. Zie bijvoorbeeld http://osmose.openstreetmap.fr/nl/map/#zoom=9&lat=52.151&lon=5.891&item=0000&level=1%2C2%2C3 voor de meldingen, of de validator in JOSM.

Gaat er iets systematisch mis bij het updaten van de BAG-gegevens? En hoe zouden we dat, én de reeds aanwezige fouten kunnen verhelpen?

Het valt me op dat Osmose meer ziet dan de JOSM validator.
Ik ga even van mezelf uit, en heb een paar steekproeven gedaan.
Persoonlijk weet ik dat ik zeer secuur met deze overlappingen ben omgesprongen, en ben dan ook verbaasd dat het ook in mijn changesets voorkomt.

In de meeste gevallen lijkt het dat osmose gelijk heeft.
Maar als de validator ze niet opvalt, is het (bijna) ondoenlijk om deze te corrigeren.

Verdere inzichten zullen vermoedelijk volgen in onderstaande reacties.
Ik wacht dan ook even af.

Mij zijn deze fouten ook opgevallen. Zoals Commodoortje al zei heeft Osmose vaak gelijk. Veelal is het mini overlap, een kleine spleet tussen gebouwen of een node halverwege een gedeelde muur op slechts één gebouw. Aangezien ik geen BAG-importeur ben, weet ik niet wat de oorzaak is.

In mijn eigen omgeving heb ik de meeste fouten ondertussen gerepareerd, maar dit is natuurlijk een landelijke kwestie.

N.a.v. Commodoortje’s observatie over de JOSM validator: wellicht kunnen we aan de JOSM ontwikkelaars voorstellen om met de validator net zo nauwkeurig naar gebouwen te kijken als Osmose doet, zodat onze importeurs sneller een waarschuwing krijgen bij deze fouten. Ik weet echter niet of dat het probleem al verhelpt of dat er meer / iets anders nodig is.

Heb eens even snel gekeken, OSMOSE lijkt vooral gebouwen te vinden waar er een mini spleet tussen zit en niet zo zeer overlap. Als ik een bag update doe dan vind JOSM altijd de overlappende gebouwen of gebouwen met een duplicate node. Die los ik dan op. Op deze ruimte tussen een gebouw daar kijkt josm niet naar.

Het valt de sws op dat de BAG panden zoals ze worden gedownload niet altijd zuiver op elkaar aansluiten. Misschien dat bij het corrigeren van die kleine fouten, deze kleine tussenruimtes ontstaan.

Het is misschien goed zoals Friendly_ghost zegt om het hier eens met de JOSM ontwikkelaars over te hebben. Het is natuurlijk geen ramp zoals het nu is want de gebruiker ziet het vaak niet eens maar als het kan worden opgelost is dat mooi natuurlijk.

Er zijn best veel gebouwen waar een minispleet tussen zit. Zeker in historische omgevingen, maar wellicht ook in moderne bebouwing. Misschien is deze spleet gevuld met een dilatatieband of dergelijks, maar dan zijn het formeel losse gebouwen. Ik zou dat niet wijzigen. Overlap op grondniveau kan natuurlijk niet.

heb ook zomaar 1 voorbeeld bekeken, hier in de buurt

https://www.openstreetmap.org/way/430960057
https://www.openstreetmap.org/way/268487743

hier lijkt het prima aan elkaar vast te zitten, ook bij heel ver inzoomen

maar als ik de garage verschuif zie ik dit

Weet niet zeker of het door een BAG Update komt, de garage zit alleen in de linkerbovenhoek aan het huis vast,
dat rapporteert OSMOSE dan blijkbaar als “ruimte tussen gebouwen”

de andere hoek van het huis had ook aan de garage vast moeten zitten neem ik aan.
geen idee verder of die BAG Import Plugin dat zou moeten herkennen/oplossen.

JOSM meldt overlap van 2 gebouwen (ook bij een minieme overlap). Maar niet als 2 gebouwen een stukje uit elkaar liggen. Of er 1 node verbonden is, maar er verder een overlap is.

Zelf ga ik geen prioriteit leggen bij het corrigeren van een spleet tussen 2 gebouwen. Daar heeft waarschijnlijk niemand echt last van.
Een enorm groot percentage van de gebouwen in OSM heeft nog een flinke afwijking van de geometrie t.o.v. de BAG, naast de vele ontbrekende gebouwen en adressen.

Er zijn volgens mij 3 soorten fouten die nog wel eens voorkomen:

  1. Meerdere punten van gebouwen op één plek: dit is een (rode) foutmelding in JOSM en is automatisch te herstellen.
  2. Overlappende gebouwen: in Osmose is deze veel strikter dan in JOSM. Alleen handmatig op te lossen door knopen samen te voegen of aan een bestaand gebouw te koppelen. De fout wordt veroorzaakt doordat gebouwen (nagenoeg) op één lijn liggen, maar geen gemeenschappelijk punt hebben.
  3. Dubbele adressen: wanneer in de BAG een adres is verplaatst en deze opnieuw wordt geïmporteerd, wordt het oude adres regelmatig niet verwijderd. Dit komt uiteraard niet zo vaak voor. En daarmee samenhangend: wordt er ook gecontroleerd op BAG-id’s die niet meer in de BAG maar wél in OSM voorkomen, en die dus uit OSM verwijderd zouden ‘moeten’ worden?

Als je goed kijkt is de bovenste node versmolten met het huis op nr. 65
Dit kun je zien, je node is iets vergroot.
De niet versmolten node ligt los van het huis op nr. 65
Dit kun je zien, je node is iets kleiner, maar je kunt het ook zien als je (in JOSM) volledig inzoomd. Hij ligt namelijk los van het huis.
Het meest waarschijnlijke is dat de muren wel aan elkaar vastzitten.
Je kunt hier een node maken en versmelten met de schuur.

ah, bedankt, door het schuiven van die schuur zag ik uiteindelijk dat de schuur maar op 1 plek vastzat,
en niet zover ingezoomd als jij :slight_smile:

is dan deze van wat BAGgeraar noemt:
De fout wordt veroorzaakt doordat gebouwen (nagenoeg) op één lijn liggen, maar geen gemeenschappelijk punt hebben.

die zitten vast inderdaad, ik had hem nog niet gefixt, omdat ik het voorbeeld even wilde laten staan, ga dat nog wel doen,
is er toch weer 1 meldinkje minder…

het voorbeeld wat ik hierboven gaf op 2021-06-17 11:45:09
is door een recente BAG update weer als fout aagegeven door osmose.
Ik ken die BAG plugin verder niet, maar betekent dit dat het vrij zinloos is om te proberen
om dit soort fouten handmatig te herstellen? Heb dat nu bij een tiental huizen rond Ulvenhout maar wel gedaan.

Hier een voorbeeld wat ik nog even “als fout” heb laten staan: gaat over volgende 2 gebouwen
https://www.openstreetmap.org/way/269821776
https://www.openstreetmap.org/way/269820806

Zie de verandering na de update, de nieuwe gele node ligt niet vast aan gebouw https://www.openstreetmap.org/way/269821776

volledige changeset
https://overpass-api.de/achavi/?changeset=116398271
Heel veel updates, waarvan dus het overgrote deel gewoon goed is gegaan.

Bij inzoomen zie je weer dit (andere hoekpunt van gebouw zit wel vast aan elkaar)

Je kunt je afvragen of dit erg is, want het gaat om minder dan 1cm, niemand ziet dat verder op een kaart.
Het is alleen die osmose tool die erover valt (op zich ook wel terecht).

Je hebt gelijk in je bewoordingen.

Er mag wel een kanttekening gemaakt worden.
JOSM validator heeft deze check niet, en kan ook niet want het is geen “fout” in de ruimere zin
OSMOSE is bekend om de nauwkeurigheid, maar ook om de “false- positives” die OSMOSE genereert.

Daarentegen heb je gelijk, maar het is ondoenlijk om elke node op het maximale zoomniveau in te zoomen.
Tevens is het geen belemmering voor de data gebruikers (of ik ken ze niet)

De data verwerkt door de gemeente medewerkers liet (vooral in het begin) de wensen over. Ook dit is per gemeente verschillend.
De data dient minimaal gechecked te worden met de JOSM om overlappende delen etc. er uit te kunnen halen.

Mocht het zijn dat je kunt programmeren, denk dan gerust mee in een oplossing hierin.
Wel is dit fenomeen vaker aan de orde geweest, en daar is wel degelijk gepoogd om dit in de plugin te kunnen realiseren.
Helaas is hiervoor nog geen oplossing.

Mijn advies (aan iedereen):
Werk met JOSM en draai op elk gebied dat je hebt gedownload de validator, en niet alleen over hetgeen jezelf hebt aangeraakt.
Je zult zien dat door deze actie zeer veel grotere problemen uit de database worden gehaald.
Daar zijn de voorbeelden van nodes die niet verlijmd zijn, maar wel verlijmd zouden moeten worden, maar een kleinigheidje.

Hopelijk kun je met dit antwoord genoegen nemen, en het laat je niet weerhouden om de OSMOSE signaleringen hierin te corrigeren.

Het gebeurt wel eens dat een net geïmporteerd polygon in JOSM foutloos lijkt, maar na de upload zijn er wel geometrie-problemen: dubbele node’s, overlap’s, self-intersecting geometry. Voor mij is dat een probleem met de JOSM validator; anderen hebben dat eerder opgepikt https://josm.openstreetmap.de/ticket/18074

Ik merk op dat het over kleine problemen gaat: het overlapt maar net.
Ik vermoed dat dit met afronding te maken heeft: de positie van node’s wordt in OSM op 1e-7 graad afgerond, dat komt neer op ca 5mm (zie https://wiki.openstreetmap.org/wiki/Node#Structure)). Stel dat twee node’s in de rauwe data 5mm uit elkaar liggen. Geen overlap, JOSM validator klaagt niet. Na de upload worden beide posities afgerond en ze komen op dezelfde positie te liggen: dubbele node.

Dat is moeilijk te voorkomen als je JOSM validator het niet oppikt pre-upload.

+1
Zeker bij BAG-updates kom ik veel foutmeldingen en waarschuwingen tegen, die ik gelijk oplos (als het kan): dubbele adressen, dubbele node’s, overlappende gebouwen, oude landuse=construction… Op die manier hoop ik dat ik meer problemen oplos dan ik veroorzaak.

Gebruik van de validator kan inderdaad bijdragen aan verbeteringen, maar het is dan inderdaad wel van belang om de laatste zin in de quote van Smoothefiets steeds in het achterhoofd te houden.

Ook de JOSM-validator geeft vals-positieven (en waarschuwt daar soms ook in algemene zin voor), dus het is zaak om alleen zaken te repareren via de validator (zeker automatisch met de “Fix”-knop) als je zelf hebt vastgesteld dat het inderdaad echt fout is op basis van conventies voor mappen. Iets is op zich nog niet fout enkel en alleen omdat de JOSM-validator iets fout noemt.

Dus bij twijfel: niet wijzigen en als je er verder mee wilt dan uitzoeken / navraag doen. Als de conclusie is dat JOSM ten onrechte een foutmelding doet dan help je het systeem vooruit door daarvan een melding te doen (“ticket aanmaken”) bij de ontwikkelaars van JOSM zodat dat kan worden aangepakt. Dat kan via deze link: https://josm.openstreetmap.de/newticket

Hier twee voorbeelden van issues waar automatische “fixen” via de validator leidde tot het automatisch verwijderen van correcte data (en waar de validator op is aangepast na aanmaken van een ticket):
https://josm.openstreetmap.de/ticket/19862
en
https://josm.openstreetmap.de/ticket/19930

Ah oneway=yes op waterways. Leuk voorbeeld. Ja dat bestaat zeker. In Leeuwarden heeft de gemeente eenrichtingsverkeer ingesteld op twee stukjes gracht, omdat je anders in de pijpen (de tunnels die grachten verbinden) opstoppingen krijgt. Het is met bordjes en al aangegeven.

oow, wie ben ik om geen genoegen te nemen met de antwoorden van de doorgewinterde forumleden :slight_smile:

ik doe niet zoveel in OSM als de meesten hier op het forum, ik vind die osmose dingen meestal wel een leuke aanleiding om iets bij mij in de buurt wat verder uit te zoeken, en om wat kleine dingen te verbeteren. Als het tenminste geen false positive is.

mijn vraag was ook: ik had iets soortgelijks gecorrigeerd in juni (zie eerder in deze discussie), wat door een recente BAG update weer terug is gekomen, precies op dezelfde 2 gebouwen. Het lijkt me logisch dat die BAG plugin gewoon weer alles uit de BAG importeert, inclusief zo’n kleine fout, die heeft geen weet van een handmatige correctie achteraf. Maar advies is, om toch handmatig te blijven corrigeren? Had ik voor Ulvenhout dus grotendeels ook al gedaan…

In de BAG worden alleen losse panden vastgelegd. Geen relaties/verbindingen met andere panden. De BAG plug-in knoopt de lossen panden zo goed mogelijk aan elkaar. Mogelijk is de tolerantie daarbij te klein en worden bovenstaande panden daarom niet aan elkaar geknoopt. Bij een te grote tolerantie zouden panden ten onrechte aan elkaar geknoopt worden en te veel af gaan wijken van het BAG pand. Het is dus zoeken naar een goede balans.
Voorlopig heb ik helaas geen mogelijkheden om wijzigingen te kunnen doen aan de BAG plug-in.

Handmatige edits worden niet automatisch teniet gedaan.
Als de situatie weer naar de BAG situatie is gegaan, dan is er om een of andere reden opnieuw een import gedaan.
De BAG plugin is geen automatisch synchronisatie mechanisme.

ja, geheel begrijpelijk.

dat was hier inderdaad het geval, een update van zowat het hele dorp op 20 januari, met flink wat wijzigingen, zie de changeset hierboven,

verder ook allemaal prima wat mij betreft, zo vaak zal zo’n grootschalige update ook niet gebeuren gok ik, en als het wel gebeurt, dan zie ik het wel weer zo’n osmose opmerking voorbijkomen (voor die paar dorpen waar ik meestal naar kijk)