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.
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,
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.
@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
@SunCobalt: in meinem JOSM brauche ich auch ohne Plugin contact:* nie ausschreiben, sondern er schlägt es mir beim manuellen Hinzufügen von Tags schon vor, sobald ich anfange zu tippen. Dann einfach mit den Pfeiltasten das richtige auswählen, mit TAB in das Wert-Fenster und schon geht es los. Vom Zeitaufwand ist das kaum ein Unterschied. Vermutlich bietet das Plugin aber noch mehr Möglichkeiten. Muss ich direkt mal ausprobieren…
Yokr schrieb in #14 “einfach weil ich irgendwie immer dachte, dass es was auf sich haben sollte wo man einen Kontakt herstellen kann”. Ich sehe bei dem, was nach dem “:” kommt, keinen Widerspruch, denn sowohl Websites als auch die sogenannten sozialen Netzwerke bieten die Möglichkeit, einen Kontakt herzustellen. Ob dies am Ende per Website, Facebook, oder einen Anruf stattfindet, spielt nicht wirklich eine Rolle.
Wieso wird in der JOSM-Vorlage Anmerkung / Kontakt die Telefonnummer (phone=) nach E 123 mit “schmalen Leerzeichen” vorgeschlagen? Sollte doch ohne “schmaleren Leerzeichen” erfolgen. Hatte es hier unter contact:phone= bemängelt unterschiedliche Formatierungen zu verwenden.
Die Formulierung
“Bei Bedarf kann die Teilnehmernummer zur besseren Lesbarkeit durch zusätzliche Leerzeichen untergliedert werden. Diese sollten aber schmaler sein als die Hauptgliederungen.” sollte eventuell gestrichen werden https://de.wikipedia.org/wiki/E.123
Als Anwendung bei dem Darstellen der Nummer bei der Datenauswertung finde ich es ja gerechtfertigt. Aber als Daten sollte +49 11223 4567890 statt +49 11223 456 7890 eingetragen sein - wie es im WIKI https://wiki.openstreetmap.org/wiki/DE:Key:phone beschrieben ist.
Ich wurde schon ein paar mal angeschrieben, ich solle doch das neue Format nehmen. Warum eigentlich habe ich aber noch nicht verstanden. Ich gehe davon aus, dass eine Telefonnummer pro POI reicht und auch eine originäre Webadresse. Das kann eine Homepage sein und wenn diese nicht vorhanden ist notfalls auch Facebook. Wobei mir es Facebook als Nichtmitglied schwer macht die Seiten zu besuchen. Einen extra Eintrag für Facebook passt für mich nicht zu OSM, da hier für ein Privatunternehmen Werbung gemacht wird. Fax und Email sind mir zu speziell und wer die nutzt, der hat die eh schon oder schaut auf der Homepage nach.
Fazit: ich werde weiterhin nur Tel und Url kartieren. Und die Telefonnummer werde ich weiterhin aus der Homepage kopieren, da sollte es ein Skript geben, um die 49 davorzusetzen. Das ist keine Mutwilligkeit sondern nur effektives Kartieren.
Guter Punkt! Eine Gliederung der Rufnummern durch weitere schmale Leerzeichen ist eine typographische Konvention und daher mMn eine Aufgabe für den Renderer. Das zeigt sich doch schon daran, dass in verschiedenen Ländern diese schmalen Festabstände an verschiedenen Stellen gesetzt werden (nach drei Ziffern, alle zwei Ziffern, aber von rechts gezählt usw. …). Die Gliederung von Rufnummern sollte daher vom Renderer (oder, falls möglich, sogar erst vom Client = Browser) in Abhängigkeit von den (vermuteten) locale-Settings des Betrachters vorgenommen werden.
Andere typographische Konventionen ignorieren wir doch auch – selbst typographisch korrekte Anführungszeichen („deutsch“, “amerikanisch”, ‘britisch’ etc,) oder korrekte Bis- und Gedankenstriche werden in OSM-Daten kaum verwendet – warum sollen dann ausgerechnet dieses seltsame Telefonnummerngliederungsfestabstände in die Daten?
Bin gerade wieder über eine Änderung gestolpert, da wurde nur website in contact:website geändert oder ein phone durch contact:phone mit Leerzeichen ergänzt.
Ich halt es nach wie vor für nicht besonders überlegt etablierte Tags wie website und phone umzutaggen. Der nächste ändert es dann wieder zurück, weil er es anders mag etc. usw. pp.
Wenn was neues, dann gerne contact, z.B. für contact:twitter, aber nicht jedes Tag braucht eine Keystruktur weil es gerade modern ist.
Das kann man in diesem Falle von zwei praktisch gleichberechtigten Tags machen, allgemein darfst du auch gerne mehrere Werte durch Semikolon getrennt angeben - wird mehr als 15.000 Mal so gemacht.
Das Thema und die Besprechungen dazu sind eingeschlafen. (Scheint zu komplex oder zu uninteressant geworden zu sein) Von daher Danke, dass Du das Thema hochholst
Ich hatte auf Wunsch die Editierungen eingestellt, die alleine nur die Syntax vom alten aufs neue Schema ändern. Wobei ich wegen der Ordnung und damit Fehleranfälligkeit weiterhin fürs neue contact:* Schema werbe. Es wäre schön, wenn nicht nur die OSM-Mitwirkenden das neue contact:* Schema bei Ihren täglichen OSM-DB Eintragungen (manuell) verwenden, sondern es würde mich noch mehr freuen wenn zusätzlich die Software-Entwickler den involvierten Vorlagen(Presets) ein Update aufs neue Schema spendieren würden.
Ferner gab dann noch den Punkt, dass die verschiedenen involvierten osm-wiki’s nicht synchron sind, siehe:
Von daher könnte man mal schauen, dies irgendwann mal zu bewerkstelligen
Vielleicht sollte man die osm-wiki Änderungsbesprechung aber hier nicht off-topic machen, sondern dazu eine separate Diskussion mit diesem Thema beginnen, ähnlich wie es kürzlich zum Thema Kreisverkehr-Splitt gemacht wurde.
