Mmmh, das ist mir noch nicht aufgefallen. Vielleicht sollte man es mal anpassen, denn ich denke nicht, dass es einen Grund gibt, den Wert anders zu formatieren. Merkwürden…
Ja, ist bekannt. Problem sind halt die über 1 Million Einträge von phone=*
und auch website=* ist noch weit verbreiteter als contact:website
Hier bin ich gegen eine mechanische Umtaggung.
Es steht jedem Mapper frei das alte oder das neue Schema zu nutzen.
Das hatte ich vor ein paar Monaten auch schon einmal angesprochen.
Was stört dich an dieser Liste, die passt doch, also ich habe dort (zumindest auf der ersten Seite) nichts ungewöhnliches entdeckt
wenn du auf contact:housenumber, contact:street anspielst, das nehme ich z.B. wenn ich eine Ferienhütte erfasse und der Besitzer woanders wohnt.
Was mich aber ärgert ist eher die full-url-copy Tatsache bei vielen Subkeys, z.B. Instagram, Twitter und Co, obwohl dort nur der Benutzername verlangt wird … da frage ich mich wie sowas kommt … ist es die Bequemlichkeit? … hat man bei anderen Objekten geschaut und dann “copy&paste” gemacht? … oder liest man schlicht und einfach die Wiki Dokumentation nicht?!
- Ja
- Vielleicht
- Ja, ich wusste bis vor ein paar Minuten nicht mal das es contact:xyz überhaupt gibt (Woher auch, da müsset man ja im Wochenrhytmus kontrollieren), wird ja auch nirgends vorgeschlagen, wenn ich schnell in iD einen POI eintrage gibt es website, phone, etc aber nix mit contact:xyz. Und rein vom Bauchgefühl hätte ich auch immer alles rein kopiert.
Ach ganz vergessen: JOSM hat übrigens ein contact:* Preset wenn man sich simonpoole’s beautified-JOSM-preset installiert 
das gibt es aber nicht als Erweiterung direkt in JOSM, oder finde ich es dort nur nicht?
Ich finde die jahrelange Parallelexistenz von contact:* mit den etablierten Tags wie website und phone eher suboptimal und halte das für eines von vielen kleinen Dingen, die das OSM-Tagging derzeit unnötig verwirrend machen.
Letztendlich ist es mir nicht wichtig, welches der beiden Schemata sich letztlich durchsetzt, denn es ist aus meiner Sicht eine Geschmacksfrage ohne handfeste inhaltliche Unterschiede. Allerdings wird contact für die gängigsten Schlüssel deutlich seltener verwendet …
… und trotz jahrelanger Bemühungen holt es auch nicht auf, eher im Gegenteil. Angesichts der langen Vorgeschichte des Themas drängt sich mir da die Frage auf: Wäre es nicht an der Zeit, den Versuch der Einführung als gescheitert zu betrachten und abzubrechen? Alternativ: Die Idee nach einem knappen Jahrzehnt jetzt doch einmal zur Abstimmung bringen und mit dem Ergebnis zu leben?
Ich bin manchmal ganz froh, dass es zwei Schemen gibt. Da kann man dann aus phone_2, website_2 usw. contact:… draus machen und gut ist.
Ich kannte contact schon, allerdings habe ich trotzdem weiterhin ab und an eine website=* gesetzt, einfach weil ich irgendwie immer dachte, dass es was auf sich haben sollte wo man einen Kontakt herstellen kann. Aber eine Website ist ja irgendwie oft auch einfach auf Informationen aus, nicht mal unbedingt um eine Kontaktmöglichkeit zu haben. Das habe ich dann also falsch gesehen oder?
Was mMn ein wenig unsauber ist: wenn man bspw. contact:facebook=* nimmt und bspw. contact:phone gegenüberstellt, dann hat das nach dem Doppelpunkt ja eine unterschiedliche Bedeutung.
Das sehe ich genau gleich.
Geschmacksfrage auf jeden Fall, aber ich sehe auch große Inhaltliche Unterschiede.
Bei ganz normalen Webseiten und Telefonnummern unterscheidet sich natürlich nicht so viel, aber für die alle weiteren Dinge (z.B. soziale Netzwerke, Handynummern, etc.) sehe ich einen großen Unterschied.
Wenn man die Prozentualen Werte nimmt (für contact:Website) holt es langsam auf:
11,67% (23.12.17)
12,03% (10.2.18)
12,04% (25.2.18)
Grundsätzlich halte ich eine Entscheidung auch für sinnvoll.
Das Problem dass es sich bisher noch nicht durchgesetzt hat, sehe ich darin, dass die meisten Leute logischerweise die Voreinstellung des Editors benutzen. Und diese wollen das Schema nicht implementieren, da es zu wenig Leute benutzen. Es handelt sich also um einen Teufelskreis…
Dieser würde sich jedoch (denke ich) unterbrechen lassen.
Zumindest mir ging es so dass ich sehr lange Zeit nichts von diesem Schema wusste, bis ich durch Zufall einmal darauf gestoßen bin
contact:website= kann immer anstatt website= verwendet werden, egal welche Informationen auf der Seite angeboten werden. Es muss sich jedoch um die offizielle und eigene Seite des jeweiligen Geschäfts etc. handeln.
Leider habe ich nicht ganz verstanden was du meinst. Bei addr: werde ja auch verschiedene Tags hinter das addr: gepackt.
Das ist so gedacht dass hinter dem : genau spezifiziert wird, um welche Kontaktinfo es sich handelt. Wie bei addr: hinter dem : genau spezifiziert wird, um welche Adressinfo es sich handelt.
Das halte auch ich für das große Problem. Weiterhin wird auf nahezu allen Wiki Seiten auf die alten keys verwiesen.
Solange die Editoren die alten keys verwenden, hat contact kaum eine Chance sich durchzusetzen.
Um eine Entscheidung zu treffen, müsste ein proposal erstellt und zur Abstimmung gebracht werden? Könnte dies jemand tun? Ich fürchte das mein Schulenglisch dafür nicht ausreicht, würde aber mithelfen.
ein Proposal wäre natürlich eine gute Idee, würde ich mir jedoch gerade auch nicht zutrauen.
ich kann diesen Forumspost auch nochmal im englischen Forum veröffentlichen, dann können da die weiteren Schritte mit einbeziehung der anderen besprochen werden.
Habe nun diesen Post noch auf Englisch in den “General Chat” gepackt:
Warum nicht beides erhalten?
Es gibt mitunter zwei verschiedene Webseiten - oder Telefonnummern. Dann nutze ich das contact:= als zweite Angabe (besser als phone_1=* → https://taginfo.openstreetmap.org/search?q=phone_1 )
Hallo,
ich habe (wohl etwas zu voreilig) verschiedene Eigenschaften vom alten Schema (phone=, fax=, url=, website=, email=) zum neuen Schema (contact:phone=, contact:fax=, contact:website=, contact:email=*) im grösserem Ausmass geändert. Dies fand grösstenteils zusammen während einer aktuellen maproulette-Aufgabe (Formatänderung von Telefon- und FAX-Nummern) im Thüringer Gebiet statt.
Markus366 schreibt in einen meiner Änderungssätze in der Diskussion dazu, es wäre keine gute Idee, dies ohne eine Besprechung durch eine breitere Allgemeinheit zu tuen. Die weiteren Informationen dazu sind im Änderungssatz (https://www.openstreetmap.org/changeset/58388486) in der Diskussion zu finden.
Den betreffenden Abschnitt aus der Diskussion hänge ich hier unten an:
"*Bezüglich contact= Schema.
[…]im deutsch-sprachigen Raum gibt es keine Vorgaben, das contact= Schema zu verwenden.
Sicher ist dies nicht falsch, jedoch hat es sich in osm eingebürgert, dass solche großflächigen Maßnahmen zum umeditieren zuvor (z.B. im Forum ) besprochen werden.
https://forum.openstreetmap.org/viewtopic.php?id=61464
Es wäre schön, wenn du dem folgst, bevor du weiterhin Änderungen einträgst.[…]
Danke für den Link zur Besprechung im Forum. Generell sagt mir dieses neue Schema etwas mehr zu, da wie auch im Forum erwähnt
- beispielsweise die „Kontakte“-Tags, (wenn alphabetisch geordnet wegen Präfix contact:…) alle etwas übersichtlicher direkt untereinander stehen
- die Option auch für contact:mobile gegeben ist
- das Schema scheinbar einfacher in dieser Übersichtlichkeit erweiterbar ist
Dass das alte Schema durch die bestehenden Vorlagen/Presets bevorteilt wird, finde ich nicht so optimal.
Nebenbei, um die “großflächigen Maßnahmen” etwas genauer zu beschreiben. Ich hatte jetzt mal im kleinen “Thüringen” Änderungen vorgenommen, die ich mit dem iD-Editor einzeln händisch durch kleine Änderungssätze umgesetzt habe.
Mal eine Gegenfrage, wurde in der Gemeinschaft besprochen, dass die iD-Editor Vorlage und JOSM-Hauptvorlage für das ältere und nicht das neuere Schema Anwendung findet?
Generell ist mir aber nicht so sehr wichtig, wie gesagt nur der Ordnung halber.
Danke für den Tipp, ich werde mal im Forum zu hier und somit zu den Info’s von verlinken und mal fragen ob noch mal Änderungen solcher Art gewünscht sind oder eher nicht.
Würdest Du ein eins der beiden Schemen (mit oder ohne contact:=) bevorzugen? Falls ja, welches?*"
Wie seht Ihr das Thema?
- alle bis jetzt gemachten Änderungen diesbezüglich rückgängig machen,
- aktuelle Änderungen behalten aber keine weiteren neuen durchführen,
- Edits weiterführen aber in einer anderen Art und Weise,
- so wie bisher in gleicher Art weiter editieren.
Dafür. Ein Revert würde wieder neue Versionen in die Datenbank schreiben, das ist vollkommen unnötig. Eine Änderung bestehender Kontaktangaben finde ich andererseits genauso unnötig. Lass alles so, wie es jetzt ist, lass bestehende Kontakte stehen und erfass neue Kontakte nach dem dir lieberen Schema. Mir gefällt das neue auch besser, weil es weniger Firstleveltags erzeugt: Auswerter, die das ignorieren, müssen nur contact:* ausblenden (auch nach einer Erweiterung des Tag-Raumes) und nicht alle einzeln; Auswerter, die nur das benötigen, können ebenso einfach alle für sie relevanten Tags selektieren. Aber vor einer Änderung sollten auch Befürworter des alten Schemas zur Sprache kommen.
–ks
@amilen: mir stellt sich aber eine andere, vielleicht noch viel wichtigere Frage: WIE führst du deine Änderungen durch? Du musst dich jetzt nicht rechtfertigen, aber das ist schon wichtig zu wissen, ob du z.B. (1) “einfach nur stupide” das alte Telefonnummerformat in das neue überträgst, oder ob du (2) in jedem Einzelfall prüfst, ob die Telefonnummer noch aktuell ist? Dasselbe gilt natürlich nicht nur für die Telefonnummer, sondern auch für den Umzug von “altem” aufs neue contact:Schema, prüfst du da auch zunächst, ob die Website noch exisitiert, etc. oder trägst du einfach nur um?
PS: Soweit ich das auf anderen Channels mitbekommen habe, ist/war diese #Phone_or_fax_number_is_not_in_international_format_(ITU-T_E.164) Maproulettes auch ziemlich umstritten!
Ich finde beide gerechtfertigt. Als “Grundausstattung” nehme ich das phone=, … und als Ergänzung das contact:phone=. Wo bei ich contact:phone=* auch ohne phone=* zum Beispiel bei Kleingärtenvereinen, Sportvereinen, … nutze, die vor Ort keinen Ansprechpartner haben.
“Alte” durch “neue” Daten zu ersetzen finde ich sowieso schlecht. Und das mit dem “mechanischen” Edit über das eigene Gebiet hinaus ebenfalls. Stelle dir einmal eine Gaststätte vor, die für sich die Daten auswertet und jetzt bei phone= nichts mehr angezeigt bekommt.
Ich mag die alten Tags (phone, fax, etc) lieber. Ganz einfach weil ich zu faul bin, jedesmal contact: davor zu schreiben. Solange es eine 1:1 Beziehung (bspw phone <-> contact:phone) gibt, sehe ich keinen Vorteil darin, mir mehr Arbeit zu machen. Und wer einen sieht, kann das ja sehr einfach mit einer Fallunterschiedung in der DB selber ändern. Da diese Tags nur einen sehr geringen Anteil bei mir ausmachen, möchte ich mich daher auch nicht mit einem neuen Plugin beschäftigen. Optisch sieht es natürlich schöner aus, wenn alles geordnet ist 