You are not logged in.

#1 2019-06-08 07:31:46

Luzandro
Member
Registered: 2015-12-16
Posts: 334

Import reparieren

Beim aktuellen Massenimport wurden bewusst Sicherheitsvorkehrungen entfernt und trotz vielfacher Warnung Daten einfach unkontrolliert in riesigen Mengen blind hochgeladen, die dafür gar nicht geeignet sind - mal abgesehen davon, dass mit Ausnahme der Lizenz wohl auch noch gegen jeden einzelnen Punkt der Import Guidelines verstoßen wurde. Ich teste dennoch gerade ein paar zusätzliche Checks für die BEV-Daten, die eigentlich VOR dem Upload geklärt werden müssten, um hier jetzt wenn möglich zumindest im Nachhinein noch einige Problemfälle zu finden ohne alles rückgängig machen zu müssen, oder zumindest die Auswirkungen in Zukunft zu reduzieren. Manche Punkte kosten gar nichts, andere sind in der aktuellen Form aber nicht gerade effizient was die Laufzeit betrifft. Ein einzelner Bezirk kann dann in manchen noch nicht so gut erfassten Gegenden auch schon einmal 1-2 Stunden laufen. Prinzipiell könnten solche Fälle gefunden werden:

1) BEV-Adressen ohne Gebäude oder Identadressen
Die Daten scheinen hier nicht besonders verlässlich zu sein. Die meisten Adressen des folgenden Chaos haben in den BEV-Daten zwar kein Gebäude zugewiesen (mit "F" markiert), es sind aber durchaus auch einige dabei, wo die "Gebäudeposition" mitten im See liegen soll - ohne visueller Kontrolle wird man solche fehlerhaften Daten oft nicht finden:
HfHR16w.png
Umgekehrt gibt es auch Adressen, wo eindeutig Gebäude vorhanden sind, der BEV-Adresse aber dennoch keine zugewiesen sind (und mit "eindeutig" meine ich lokales Wissen und nicht möglicherweise veraltete Luftbilder)
7FJ0Yeb.png

2) ähnliche Adresse in X m Entfernung
Ähnliche Adressen werden nur heraus gefiltert, wenn es keine größere Abweichung der Position gibt, da anderenfalls nicht klar ist, welche der Positionen falsch ist (falls überhaupt und nicht nur das Gelände so groß ist). Diese Fälle werden jetzt entspr. markiert.

3) sehr nahe andere Adresse gefunden bzw. innerhalb eines Gebäudes/Bereichs mit anderer Adresse

ueXZPna.png
(Der Screenshot ist nicht mehr ganz aktuell, ich prüfe bspw. nicht mehr mehrere Bedingungen, wenn schon eine zutrifft, aber zur Demonstration ist es ganz gut geeignet)

4a) keine Straße mit diesem Namen (oder alt_name/official_name) in der Nähe / in dem Bereich gefunden
Neben einem fehlenden Straßennamen kann das auch ein Hinweis darauf sein, dass eigentlich addr:place statt addr:street gehört, oder dass die Schreibweise des Straßennamens in einer Form abweicht, die nicht durch die Normalisierung abgedeckt ist.
tDny3Y5.png

4b) Straße weit entfernt von der einzelnen Adresse
ix7snXW.png

Punkt a kann zum Teil auch mit dem OSM Inspector überprüft werden, der ebenfalls auch alternative Straßennamen unterstützt, ansonsten aber um einiges kleinlicher ist, was die Schreibweise betrifft und schon fehlende Bindestriche bekrittelt. Bei der Distanz zur Straße ist er dagegen recht tolerant und nicht geeignet solche Ausreißer zu finden.

( 5) Hausnummern ohne addr:street/addr:place in der Umgebung gefunden)
Es gibt Bereiche, wo Leute OTG oder per basemap nur Hausnummern, aber keine dazugehörigen street/place eingetragen haben.
Wird tlw. schon von Punkt 3 und v.a. auch vom OSMI abgedeckt, also habe ich das wieder gestrichen.

BINYlEG.png
FrFPwzD.png

( 6) addr:place ohne Place mit entsprechendem Namen in dem Bereich)
Nach meinen Tests war das oft falscher Alarm, da addr:place sowieso nur automatisch gesetzt wird, wenn der Straßenname mit dem Ortsnamen in den BEV-Daten ident ist und in diesen Fällen existiert auch meistens ein place Node für die Ortschaft, der nur in bestimmten nachvollziehbaren Fällen durch die Auswahl des Suchbereichs nicht gefunden wurde, weshalb ich das wieder gestrichen habe.
Kann auch mit OSMI überprüft werden, was aber offenbar keine flächigen Places unterstützt.


Nachdem die Ausgangsdaten des Imports bekannt sind und praktisch alle davon völlig unbearbeitet sind, sollte sich das auch im Nachhinein noch recht einfach finden und löschen lassen. Die gefundenen Adressen sind natürlich nicht alle zwingend falsch, aber auch nicht so problemlos, dass man sie ohne weitere Bearbeitung einfach irgendwo in die Gegend schmeißt und die "Drecksarbeit" dann anderen Mappern überlässt. Bei den Fällen von Punkt 4a (keine Straßen mit diesem Namen in dem Bereich) zahlt es sich wohl aus, die zu kontrollieren, Stichprobenweise habe ich das auch schon quer über Österreich gemacht, alle anderen Treffer würde ich löschen, beginnend mit einzelnen Bezirken in NÖ/Bgld. und anschließender Evaluierung. Auch tlw. automatisiert ist das Bereinigen aber immer noch um einiges aufwändiger als der Import roll

Code dazu findet sich hier. Für einzelne Gemeinde sollte damit das Filtern auch über den Standard-Overpass-Server möglich sein.

Last edited by Luzandro (2019-06-08 08:17:08)

Offline

#2 2019-06-08 12:31:16

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,438
Website

Re: Import reparieren

Oh je, hat mal wieder jemand zugeschlagen sad

Als Außenstehender kann ich nur vorschlagen, diesen Import komplett zu reverten. Wenn jemand so gegen die Spielregeln verstößt und solchen Schrott abliefert, gäbe es bei uns (DE) keinerlei Gnade. Jetzt mühselig und sicher auch unvollständig nachträglich die Fehler auszumerzen, ist mMn vertane Zeit. Zudem hat so ein Full Revert auch nebenbei einen didaktischen Effekt.

Der Import könnte jederzeit - natürlich nach entsprechenden Änderungen - wiederholt werden. Somit gäbe es keine Datenverluste.

Gruss
walter

ps: aus dem Post geht erst nach mühseliger Textanalyse hervor, dass etwas gemacht werden sollte - nur wer? Die arme AT-Community?

Last edited by wambacher (2019-06-08 12:32:10)

Offline

#3 2019-06-08 12:52:43

Luzandro
Member
Registered: 2015-12-16
Posts: 334

Re: Import reparieren

wambacher wrote:

ps: aus dem Post geht erst nach mühseliger Textanalyse hervor, dass etwas gemacht werden sollte - nur wer? Die arme AT-Community?

Gemacht werden muss auf jeden Fall etwas, die Frage ist was? Kompletter Revert? Teil-Revert basierend auf den oben genannten Checks? Letzteres würde ich durchführen, auch wenn es eine Zeit dauert und vorher noch gründlichere Tests notwendig sind, ob damit der Großteil abgedeckt ist, oder noch mehr auftaucht.

Offline

#4 2019-06-08 13:22:25

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,438
Website

Re: Import reparieren

Luzandro wrote:

Gemacht werden muss auf jeden Fall etwas, die Frage ist was? Kompletter Revert? Teil-Revert basierend auf den oben genannten Checks? Letzteres würde ich durchführen, auch wenn es eine Zeit dauert und vorher noch gründlichere Tests notwendig sind, ob damit der Großteil abgedeckt ist, oder noch mehr auftaucht.

Wie groß ist denn die Gefahr, dass weiterhin solchen Imports gemacht werden?
Ich sehe da echte Probleme auf euch zukommen, wenn man das durchgehen läßt.

Gruss
walter

Last edited by wambacher (2019-06-08 13:23:18)

Offline

#5 2019-06-08 18:08:37

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,438
Website

Offline

#6 2019-06-08 18:11:56

Gppes
Member
From: Leoben / Austria
Registered: 2015-12-15
Posts: 611

Re: Import reparieren

Hallo,

der User wurde jetzt mal gesperrt. Das Chaos oben gehoert komplett revertiert. In der AT-Mailingliste gibt es weiters die Moeglichkeit ueber einen Komplettrevert aller Edits des Users innerhalb der letzten Jahre "abzustimmen". Siehe dort.

Lg, Gppes

PS.: Danke, Luzandro fuer Deine Arbeit und Deine Beobachtungen!

Offline

#7 2019-06-09 07:05:04

Luzandro
Member
Registered: 2015-12-16
Posts: 334

Re: Import reparieren

wambacher wrote:

Wie groß ist denn die Gefahr, dass weiterhin solchen Imports gemacht werden?
Ich sehe da echte Probleme auf euch zukommen, wenn man das durchgehen läßt.

Die haben wir mit dem User sowieso schon die ganze Zeit, auch mit Revert (damals noch manuell mit basemap abzeichnen). Ich habe bei einem Teil-Revert insofern ein etwas besseres Gefühl, als da relativ klar definiert ist, was gelöscht wird.
Ich habe bspw. kürzlich den Bereich der Gemeinde Neulengbach überarbeitet. Auch da geht es um Adressen, auch dort ist er mit einer brachialen Vorgangsweise auffällig geworden, wobei mir selbst die "originellsten" Änderungen zu spät für einen Revert aufgefallen sind, während das meiste wie üblich nur schlampig ausgesehen hat. Es wäre damit aber wohl auch nicht weniger Aufwand und nur mehr Ärger gewesen. Wenn seine restlichen korrekten Edits dort allerdings auch wieder rückgängig gemacht werden, muss das ganze noch einmal überarbeitet werden, wobei ich das hier zumindest weiß. In anderen Fällen wird sich nur irgendwann jemand wundern, dass das doch schon einmal korrekt / vorhanden war.
Ich sehe da mehr Kollateralschäden als didaktischen Effekt. Schuld an seinen Fehlern und Aktionen sind sowieso immer alle anderen, vom BEV über die basemap, Thomas Konrad mit dem AddressHelper, oder die von mir aufbereiteten Daten, auch wenn er bei allen Hilfsmitteln immer wieder große Anstrengungen unternimmt, die gerade nicht so zu verwenden, wie sie gedacht sind, und immer wieder versucht, alles zu Umgehen, was ihn davon abhalten soll. Der einzige didaktische Effekt, den ich feststellen konnte, ist dass es offenbar eine Weltverschwörung geben soll, die nichts anderes im Schilde führt, als ihm Steine in den Weg legen zu wollen.
Was ich eher sinnvoll finde ist, wie friedl schon geschrieben hat, ein Revert der Änderungssätze "Fehlende oder neue Adressen..." bzw. "Fehlende Hausnummern..", wobei ich auch da ehrlicherweise nicht weiß, ob es dann bei seiner Vorgangsweise nicht wiederum vorkommen könnte, dass er anschließend in anderen Changesets vorhandene Adressen als "Duplikate" gelöscht hat und diese Löschung dann übrig bleibt.

Last edited by Luzandro (2019-06-09 07:09:04)

Offline

#8 2019-06-10 07:56:12

Luzandro
Member
Registered: 2015-12-16
Posts: 334

Re: Import reparieren

Ich habe damit einmal testweise den schon davor sehr gut erfassten Bezirk Baden bereinigt und die Checks beim Test der praktisch vollständig erfassten Gemeinde Hernstein ein wenig justiert und noch aggressiver gestellt.

Die ursprünglich nicht gefunden teilen sich auf in:

2-3 schon vorhandene Adressen, die erst nach dem Stichtag angelegt wurden, den ich bei meinem lokalen overpass Server als Vergleich für vor dem Import verwende (Anfang April).

Ein paar vereinzelte Adressen innerhalb von umschließenden Gebäuden, wo es mir ein wenig ein Rätsel ist, warum dort das umschließende Gebäude nicht wie sonst mit der folgenden overpass-Abfrage gefunden wird:

nwr["addr:housenumber"](around: 3.0,47.926796,16.087789);out center;

Dabei war der Node hier auch noch ziemlich zentral und üblicherweise funktioniert es auch in folgenden Fällen problemlos:
oidzmXg.png
Wenn ich den Radius für "sehr nahe" auf 6 Meter verdopple werden auch diese eigenartigen Fälle (und wohl auch ein paar falsche Treffer, wie man auch bei obigem Bsp. sieht, wenn man den Radius erhöht) gefunden.

Damit bleiben gerade einmal 5 / 141 importierten Nodes der Gemeinde über
Die schauen mehr oder weniger plausibel aus, auch wenn bei manchen erst eine Baustelle erahnbar ist:
https://www.openstreetmap.org/node/6506538435
https://www.openstreetmap.org/node/6506538411
https://www.openstreetmap.org/node/6506538503
https://www.openstreetmap.org/node/6506538466

Das näherungsweise:
https://www.openstreetmap.org/node/6506538465
möglich, dass das Gebäude zum nordöstlichen Grundstück gehört, das an der Berndorfer Straße liegt, die Adresse sollte wohl aber auch auf dem anderen Gebäude dort liegen


Im gesamten Bezirk Baden wurden anschließend 2335 der noch vorhandenen 3075 Nodes entfernt, damit bleiben diese hier als unverdächtig angesehene über.


edit: im noch weniger gut erfassten Bezirk Bruck an der Leitha (~60%) wurden 5673 / 15444 entfernt, womit diese hier übrig bleiben

Last edited by Luzandro (2019-06-10 20:12:26)

Offline

Board footer

Powered by FluxBB