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.
ich vermute nicht nur Thüringen, sondern die ganze Welt Das war einer dieser maproulette Aufgaben, wo ich mir ziemlich sicher bin, das es die Verschleierung eines mechanical edit ist/war.
Nachtrag: [hier](https://forum.openstreetmap.org/viewtopic.php?pid=698381#p698381) hatte sich der "Thüringer Kollege" geoutet...
Nachtrag 2: @geri-oc: du hattest ein paar Beiträge weiter schon deinen "Senf" dazu abgegeben, mal so als Gedächtnisstütze :P
Käse, ist ja hier derselbe Thread nur auf Seite 1 :laughing:
Ich habe mir mit Hilfe einer maproulette Aufgabe verschiedene POIs anzeigen lassen und bei denen dann das Format des Telefonnummernwertes geändert. Ich war der Meinung, weil mit dieser Aktion die Datensätze der involvierten POIs sowieso angefasst werden (und damit eine neue Version bekommen), dies zu verbinden mit der (1) “stupide” Umstellung auf das neue contact:* Schema.
Weiterhin hatte ich, damit nicht für jedes einzelne POI ein eigener Änderungssatz kreiert wird mehrere POIs im selben Änderungssatz gepackt. Dies fand hauptsächlich speziell in Gebieten mit “höherer POI-Dichte pro qm” statt. Bei späteren maproulette Funden hatte ich folglich viele Fälle die ich überspringen konnte, weil diese von mir zuvor selbst, durch die gewissen Sammeländerungssätze, bereits erledigt waren. Streetcomplette macht es doch so ähnlich und sammelt auch paar Elemente zusammen, weil die kleinen Änderungssätze anfangs kritisiert wurden, oder?
Wieso wurde denn dann die maproulette Aufgabe, obwohl sie umstritten war, überhaupt freigeschaltet?
Diese Frage stellt sich nicht, da jeder mit einem OSM Account sofort eine Maproulette Aufgabe öffentlich starten bzw. freischalten kann, und das ohne vorherige Diskussion …
Alles schön und gut: Wenn Daten fehlen kann ich sie nach alten oder neuen Schema eintragen. Das alte ist aber nicht falsch, das es geändert werden muss.
Es geht doch um die Auswertung. Zum Beispiel eine Gaststätte lässt sich phone=* und website=* in ihrem POI auf der Karte anzeigen: Nun ist der Schlüssel leer und der Nutzer steht “leer” da. (Kommentar: “Warum wird das geändert? Bei G… funktioniert es.”
Das war einer dieser maproulette Aufgaben, wo ich mir ziemlich sicher bin, das es die Verschleierung eines mechanical edit ist/war.