Moin zusammen!
Wie würdet ihr es bewerten, wenn jemand vorhat, an einem Objekt einen Sachverhalt doppelt zu taggen? Es geht speziell um die beiden Schemata für Kontaktdaten. Er möchte, obwohl contact:website=* bereits gemappt ist, noch website=* hinzufügen (wohlgemerkt die gleiche Website).
Ich sehe das kritisch und würde gern eure Meinung dazu erfahren.
Nach persönlichen Vorlieben jeweils einen der Schlüssel löschen (aber einmal Prefix contact: in den Schlüsseln vorhanden dann immer oder umgekehrt).
Das sehe ich wie Du.
Problematisch sind Editoren, die nur ein Schema berücksichtige, wie iD. Wenn kein website=* Tag vorhanden ist, wird das Feld in der Maske leer angezeigt auch wenn contact:website vorhanden ist. Das verleitet dazu die Webseite zusätzlich als website=* einzutragen.
Wie wäre es erst mal mit einem wohlwollenden CS-Kommentar, in dem man ihn darauf hinweist, dass da schon was da ist.
Ein Hinweis auf das von OSM_RogerWilco angeführte mögliche Problem wäre auch sinnvoll.
Kannst Du mal bitte einen Link zum betreffenden CS posten?
Falls jemand Lust hat, das wäre hier https://www.openstreetmap.org/changeset/119045479
Ich selbst halte mich erstmal zurück, da wir kommunikationstechnisch wohl irgendwie nicht kompatibel sind.
Das ist sehr diplomatisch ausgedrückt. Und Deine Kommunikation war das auch. 
Ich wäre wahrscheinlich schon aus dem Anzug gesprungen, bei soviel “Kompromissbereitschaft”
Ich bin auch schon auf Doppeleinträge von phone/email/website etc. einmal mit “contact” und einmal ohne gestoßen und gestehe ohne rot zu werden, dass ich von den doppelt vorgefundenen Einträgen einfach einen gelöscht habe, allerdings im Zusammenhang mit einer generellen Überarbeitung des Objektes.
Das hat m.E. nichts mit Respektlosigkeit gegenüber dem anderen Mapper zu tun, da ja am Informationsgehalt nichts verloren geht. Bisher hat sich noch niemand darüber beschwert, sollte das einmal der Fall sein, werde ich gerne auf dieses Topic hier verweisen.
Moin,
der „Verursacher“ dieser Debatte meldet sich jetzt selber zu Wort.
Zunächst: Ich habe jetzt die fraglichen POIs auf den Ursprungszustand zurückgesetzt. Wenn es Probleme bei der Auswertung geben soll, da Algorithmen beide keys als gleichwertig interpretieren, ist das auch nicht in meinem Sinne.
Ich ärgere mich jedoch über einige Dinge: Ich muss mich auf eine Dokumentation verlassen können und offiziell mappen wir nach der Wiki von OSM. Ob die Seiten nach Jahren nicht mehr gepflegt werden, weil offenbar keiner mehr Bock drauf hat, ist nicht mein Schalter. Dieses Forum oder OSM-Stammtische (an denen ich nicht teilnehme) ersetzen nicht die Vorgaben, die jedem zur Verfügung stehen. In diesem konkreten Fall gibt es für den selben Wert zwei keys. Das ist Mist, aber solange es keine genaue Vorgabe gibt, welcher denn nun schlussendlich verwendet werden soll, wird es solche Diskussionen immer wieder geben. Und das ist keine Entscheidung, die paar Leute hier im Forum fällen können, sondern sie muss schon weltweit einheitlich sein.
Ich mappe auch in Italien und Spanien, dort ist der contact-key ungebräuchlich. Nochmal, die Dokumentation ist maßgeblich und nicht die Meinungen in solchen Foren bei (bei diesem Thread gegenwärtig 5 Diskuttanten). Ich konnte einen italienischen User mit dieser Dokumentation nämlich auch schon einmal davon überzeugen, mir nicht ständig meine hinzugefügten turn_lanes an Autobahnanschlußstellen zu löschen, weil das Mappen in der Wiki genau so beschrieben ist.
Wenn ich künftig POIs korrigiere, werde ich darauf achten, welches Schema vorherrscht. Ich werde aber garantiert nicht darauf achten, welches Schema in der Region „üblich ist“, das ist mir zu albern.
Bei neuen POIs werde ich weiterhin meine keys „phone“ und „website“ verwenden.
Gibt auch Mitleser, die nicht in jedem Thread “sehe ich auch so” abkippen.
Nein, das Wiki versucht lediglich (!) zu dokumentieren, wie wir mappen. Das ist ein wichtiger Unterschied.
Es gibt unterschiedliche Auffassungen zur Rolle des Wikis. Dass das Wiki mindestens teilweise auch dokumentiert, wie wir mappen sollen, finde ich aber offensichtlich. Wozu gäbe es sonst z.B. Abstimmungen über Proposals.
Ich kann Patricks Frustration verstehen, denn es gibt keinen guten Grund für die Koexistenz der beiden Schlüssel. Die ist ausschließlich unserer Unfähigkeit geschuldet, einen Konsens zu strittigen Taggingfragen herbeizuführen.
Sollten, vielleicht. Aber nicht sollen.
Ich bin auch ein großer Freund von Standards und dass es diese bei OSM leider nicht gibt, daran musste ich mich anfangs auch erstmal gewöhnen. Bei der Qualität des Wikis rate ich stark davon, das Wiki als bindende Vorgabe zu bezeichnen. Ich finde es eher offensichtlich, dass aufgrund der häufigen nicht abgesprochenen Änderungen und der zahlreichen Widersprüche, das Wiki sich nicht als bindende Vorgabe eignet.
Bezüglich der Proposals: Es ist keineswegs verboten z.B. ein Tag oder ein Schema zu verwenden, dass bei einem Proposal abgelehnt wurde.
Bezüglich dem contact-Schema: Diese sind ausschließlich für Kontakt-Zwecke gedacht. Der website-Tag ist da weiter gefasst (z.B. für eine Webseite zu einem Objekt, die rein beschreibende Funktion hat). Von daher gibt es zwar eine große Überschneidung aber die beiden Schemata sind nicht redundant.
Verboten nicht. Man darf dann aber nicht rumheulen, wenn es jemand “verbessert” und dann wenn man sich gegen wehrt (“Mapping Krieg”), freut sich die DWG über Arbeit 
Da nehme ich aber eine andere Verwendung wahr… Was ist überhaupt ein “Kontakt-Zweck” bzgl einer Webseite. Eine Webseite wo ich Infos bekomme? Eine Seite, wo ein Kontaktformular ist? Hier merkt man, eine Webseite dient immer einem “Kontakt”-Zweck; Es ist aber zu großen Teilen einseitige Kommunikation,
Nein, das ist nicht richtig. Es gibt auch rein informative/beschreibende Webseiten. Z.B. zu einem Denkmal.
So ist es, was mir schon lange fehlt fehlt sind niedrigschwellige “Meinungsbilder” mit denen man lokal bzw. auf landesebene mal schnell+unbürokratisch festlegen kann, was perspektivisch eigentlich gewünscht ist,
dann könnte man im DE-Bereich verankern:
“In Deutschland soll(te bitte) ausschließlich die Methode A statt B (oder C oder …) verwendet werden. Vgl. dazu Meinungsbild x”
(Selbst habe ich kürzlich, im Rahmen von Überarbeitungen, an etlichen Objekten das “contact:” entfernt, bzw. das Tagging an das mehrheitlich verwendete Schema der vergleichbaren Nachbarobjekte angepasst.)
Ich denke, wir sollten in diesem Thread nicht (schon) wieder eine Diskussion über das Für und Wider der beiden Schemata eröffnen. Das ist doch alles schon tausend mal diskutiert worden. Fazit: wir finden keine Einigkeit.
Dass das nicht schön ist, weiß jeder. Die Auswerter werten beide Schemata aus und beide existieren parallel und gleichberechtigt. Ein pauschales Umtaggen, nur weil einem das jeweils andere nicht gefällt, ist nach meiner Aufassung nicht gewollt, da es keinen Mehrwert bringt. Wenn sich an einem Objekt doppelt vorhandene Informationen befinden, kann man dies ändern, in dem man sich auf eines der beiden Schemata beschränkt.
Das ist doch eigentlich ganz einfach…
@ highflyer
Stimme Dir zu und mache es genau so (siehe #7). Trotzdem hat Patrick1977Bln insofern Recht, dass solche Diskussionen immer wieder losgetreten werden, solange nicht mal auf nationaler Ebene Einigkeit darüber herbeigeführt werden kann, wie bestimmte Sachverhalte zu taggen sind … 
Bei anderen Themen haben wir auch unterschiedliche Erfassungsmöglichkeiten: Gehweg als separaten way oder als sidewalk-Tag, Adresse am Gebäude oder als Node im oder am Gebäude,… Ist halt so. Ist auch nicht tragisch.
Würde ich nicht machen.
Steht etwa irgendwo im wiki*, dass das i.O. wäre, oder steht nirgendwo im wiki*, dass das nicht i.O. ist?
Im betreffenden Fall gibt es kein akzeptiertes Proposal, von daher beschreibt das wiki wohl die Datenbank Situation und es sollte m.E. keine Empfehlung oder Anweisungen geben, dass das eine Schema vor dem anderen zu benutzen ist.
+1
iD ist also parteiisch und ich wäre froh, wenn es den beiden Schemen neutral eingestellt wäre
Hallo,
ID ist nur bei den Vorgabefeldern “parteiisch”
Bei den Eigenschaften wird schon “contact” vorgeschlagen
Gruß
Danfost