[Talk-de] Zum 1000. mal - Hausnummern und Straßennamen?

steffterra steffterra at me.com
So Jul 18 14:06:54 UTC 2010


Am 18.07.2010 um 15:27 schrieb fly:

> Generell halte ich die Diskussion um Newbees und Relationen für fragwürdig.
> 1. Existieren immer mehr Relation und man wird damit sehr schnell
> konfrontiert, somit sollte man neuen Mitglieder diese eher gut erklären
> als zu behaupten, es wäre kompliziert.

Ich schrieb ja davon, dass man sowieso Doku lesen muss und sich Hilfe holen sollte.

> 2. Probleme sehe ich eher bei den Editors als den Mappern. Leider können
> die Editors häufig nicht gut mit Relationen umgehen.(bearbeiten/darstellen)

Auch diese sollten sich erfahrenen Usern anschließen, wenn sie es anhand von Doku nicht herausfinden wie es geht. Oder vorerst die Finger von Objekten lassen, die Teil einer Relation sind und sich vor einem erneuten Versuch weiterbilden.

> Als ich vor ca. 1 Jahr neu dazu kam, gab es leider noch weniger
> Dokumentation. Trotzdem war ich recht schnell mit route-Relationen
> konfrontiert. Schon beim Einfügen einer Abbiegespur mußte ich Relationen
> bearbeiten.
> 
> Zu der Zeit existierten zusätzlich noch einige Bugs in JOSM, wodurch ich
> auch eine Relationen beschädigte. Darauf wurde ich von zwei erfahreneren
> Benutzern hingewiesen und wir haben die Fehler gemeinsam behoben.
> 
> Diese Probleme haben mir als neues Mitglied sehr geholfen Erfahrungen
> und Verständnis zu gewinnen und zusätzlich in einer Gegend ohne
> user-group erste Kontakte zu lokalen Mappern ermöglicht.
> 
> Als Anfänger macht jeder Fehler, aber gerade dadurch kann man auch viel
> lernen.

Kann ich Dir nur zustimmen und ist auch meine persönliche Erfahrung. 

Doch speziell beim Thema Adresse/Hausnummerntagging gibt es einen Unterschied zu anderen Relationen:

Liebe Diskussionsteilnehmer :-) 

->>>  Hausnummern werden dringender als alles andere in OSM benötigt. Es gibt immer mehr Anwendungen (u.a. OSM-Router) die unter großem Konkurrenzdruck durch das kostenlose Google-Turn-by-Turn-Routing stehen und OSM _noch_ als die bessere Alternative ansehen und deshalb nicht die Flinte ins Korn werfen, sondern weiter auf OSM bauen. Das Überleben für diese ist nicht leicht. Kommerziell wie nichtkommerzielle OSM-Routinganwendungen haben zur Zeit echt zu kämpfen.

Bitte helft doch mit, OSM gerade durch seinen Mehrwert gegenüber Google&Co. konkurrenzfähig zu halten/machen und unterstützt das Adress-Tagging wo es geht.
Relationen kann man machen, aber Full-addr:-key-Tagging auch. Letzteres ist für Neuuser faktisch die beste und einfachste Möglichkeit, schnell direkt nutzbare Ergebnisse zu erzielen. Und diese Möglichkeit sollte man ihnen nicht nehmen, indem man ihnen den Einstieg in OSM übers Hausnummern-Taggen durch Relationen _unnötig_ erschwert.

Daher rührt mein Engagement für full-addr:-key-Tagging und gegen Relationen _bei Neuusern_. Denn auf die sind wir angewiesen und sie werden über die Anwendungen auch kommen. So wie beim maxspeed-tag auch: Aus dem Anwender eines OSM-Navi zum OSM-Mapper. Das Userpotential gilt es zu nutzen und nicht abzuschrecken.

Werbt dafür, dass Neuuser es superleicht haben, Addressen zu taggen, anstatt sie gleich zu Anfang mit Relationen zu demotivieren. Gebt ihnen die einfache Variante an die Hand!

Wenn die Daten in DE erstmal genauso vorhanden sind , wie Straßen, kann man immer noch darüber nachdenken, "alle Addr-tags" in Reltionen umzutaggen, (für die Redunzanreduzierung der db) was für einen Bot nicht allzu schwer sein sollte, wenn die Addr-Nodes und Gebäude in korrekter Straßenschreibweise mit PLZ, etc. im full-addr:-key-Tagging erfasst wurden. 

->>> Aber lasst es sie doch erstmal tun um Himmels willen! <<<-

Es gibt kein richtig oder falsch, beides ist möglich und nicht falsch. Darf man da nicht das eine Verfahren für Neuuser empfehlen und das andere für erfahrene User??? Bitte - besonders im oben dargestellten Kontext!
Überlasst nicht google das Feld sondern erleichtert es Neueinsteigern in OSM Hausnummern einzutragen!

steffterra








Mehr Informationen über die Mailingliste Talk-de