[Talk-at] Quantität vor Qualität beim BEV-Adressimport?

[various at mailbox.org]

Hallo, 

so, wie ich das sehe:
geocodec/.../adresshistory bevorzugt Nodes gegenüber Gebäudetagging. Mit seiner Arbeitsweise, die er selbst mehrfach erklärt hat, funktioniert das ganze einfach so, dass er zuerst alles setzt und danach alle Doppeltadressen löscht. Das zieht natürlich nach sich, dass er fröhlich die Gebäudeadressen, die vorher da waren, löscht. Ich behaupte inzwischen einfach, er macht das auch absichtlich so, weil es anders auch einfach mehr Aufwand wäre.
Was er ebenfalls macht ist, seine eigenen Fehler nicht auszubessern, auch nach Hinweisen nicht. Darum kümmert er sich vielleicht später mal, sagt er immer wieder oder er redet sich damit heraus, dass die Quelle halt nicht besser ist und macht nichts, in der Hoffnung, dass jemand anderes das behebt (was auch meist passiert).
Was zusätzlich ist, er ignoriert alles, was nicht Hausnummern betrifft, schön gesehen auch im Forum, wo er von mir mehrfach darauf hingewiesen wurde, dass er eine Adressnode gesetzt hat, ohne überhaupt einen Gebäudeumriss zu haben. Die Straße, klar auf Basemap erkenntlich hat er auch ignoriert und nicht hingezeichnet. Da ich mich dort auskannte, habe ich das dann nachgeholt. Auf meinen erneuten Hinweis, bevor ichs selbst gemacht habe, wurde nur pampig reagiert.

Seine gesamte Arbeitsweise fußt imho auf: 
Ich mach mal, bis jemand mir sagt, was ich falsch mache. Dann passe ich das an und mache weiter, bis der nächste auf einen Fehler draufkommt, dann passe ich das wieder an. Die vergangenen Sachen sind mir wurscht, die will ich nicht noch mal angreifen.

Einen kompletten Revert halte ich für unsinnig, trotz aller Fehler und persönlicher, äh, unstimmigkeiten, bringen die ganzen Adressen, die er einträgt einen großen Mehrwert, imho. 
Da noch eher genauere Kontrolle und Reverts der betroffenen Changesets und wenn er sich wieder mit so bescheuerten Argumenten dagegen wehrt, dass er selber mal seine Fehler ausbessert, einen 0-day Ban bis er sich mal dahinterklemmt und seine Fehler ausbessert. 
Die Fehler mach er eh ständig. 

Mit freundlichen grüßen

ps: Die inoffizielle Übereinkunft mit Hausnummern ist schön und gut, hilft aber nix, wenn man das nirgendwo nachlesen kann oder darauf hingewiesen wird. Im großen und ganzen ist es wurscht. 

> Robert Kaiser <kairo at kairo.at> hat am 28. August 2018 um 14:06 geschrieben:
> 
> 
> andreas wecer schrieb:
> > alleine in dem einen
> > Changeset wurden bei 200 Gebäuden die vorhandenen Adressen bei den Gebäuden
> > gelöscht und stattdessen ein Node gesetzt.
> 
> IMHO gehören Chagesets, die das machen, revertet. Wenn er dann weint, 
> weil das nur ein Teil des Changesets ist, dann soll er entweder mehr 
> überlegen, was er macht, oder auf kleinere Changesets aufteilen, damit 
> Kontroversen und Reverts nicht gleich viele gute Dinge auch betreffen.
> 
> Einerseits ist in Ö die inoffizielle Übereinkunft, dass Adressen auf das 
> Gebäude getaggt gehören, wenn eindeutig eine 1:1-Relation zwischen 
> Adresse und Gebäude herrscht. Andererseits ist es gegen die 
> OSM-Vorgehensweise, solche Dinge an bestehenden Objekten umzuändern, 
> ohne wirklichen Mehrwert für diese Objekte zu schaffen und auch ohne 
> vorher auf Listen/Foren-Diskussion eine breite Zustimmung zu dieser 
> Änderung bekommen zu haben.
> 
> Der Revert muss schon alleine deshalb sein, weil durch unreflektierte 
> Imports schon einmal die Community in Ö deutlich geschwächt wurde und 
> wir das nicht mehr zulassen können.
> 
> > Die Aussage, "Was dem amtlichen BEV genügt, sollte einstweilen auch für OSM
> > ausreichend sein", finde ich einigermaßen originell
> 
> Die Aussage ist schlichtweg BS. Wir wissen, dass jeder Datensatz Fehler 
> hat, aber mal abgesehen davon sind wir kein Amt, und nicht das BEV. Wir 
> haben andere Reglen und andere Zwecke. Wir haben keine bezahlten 
> Mitarbeiter, die wir schicken können, um Daten zu korrigieren, wenn "da 
> oben" wer beschließt, dass irgendwas jetzt sein muss. Wir haben eine 
> freiwillige Community, die es sehr vorsichtig zu hegen und pflegen gibt, 
> und wenn wir die vergraulen (weil wir z.B. ihre Daten mit einem Import 
> überschreiben), dann schadet das dem Projekt langfristig.
> 
> Daher: Einzeln recherchierte kleine Changesets (wie viele von den im 
> ländlichen Raum bestehenden Gebäuden und Adressen) übertrumpfen den 
> Import aus jedweglichen externen Datensätzen immer, schon alleine, weil 
> sie von einer breiteren and in Summe engagierteren Community kommen.
> 
> Robert Kaiser
> 
> 
> _______________________________________________
> Talk-at mailing list
> Talk-at at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at