Verwendung des contact: Schemas

kreuzschnabel · 2018-05-09T05:41:07.000Z

amilen:

aktuelle Änderungen behalten aber keine weiteren neuen durchführen,

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

Harald_Hartmann · 2018-05-09T06:12:25.000Z

@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!

geri-oc · 2018-05-09T07:21:02.000Z

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.

SunCobalt · 2018-05-09T07:31:32.000Z

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

highflyer74 · 2018-05-09T12:20:56.000Z

@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.

geri-oc · 2018-06-05T09:57:11.000Z

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.

wegavision · 2018-06-05T15:23:36.000Z

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.

Chrysopras · 2018-06-06T07:03:02.000Z

geri-oc:

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.

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?

geri-oc · 2018-09-04T08:08:02.000Z

geri-oc:

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.

https://www.openstreetmap.org/changeset/58791024

Was ist den nun hier der Stand?

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.

Ist wahrscheinlich für ganz Thüringen erfolgt:

https://www.openstreetmap.org/changeset/58790138

R0bst3r · 2018-09-04T08:37:14.000Z

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.

Siehe auch die ganzen Dupletten bei POIs

phone und contact:phone
https://overpass-turbo.eu/s/BBW
website und contact:website
fax und contact:fax
usw.

geri-oc · 2018-09-04T09:58:01.000Z

R0bst3r:

Siehe auch die ganzen Dupletten bei POIs

phone und contact:phone

Muss nicht unbedingt Duplette sein. Ich nutze es z.B. bei zwei Telefonnummern in einen Unternehmen.

mueschel · 2018-09-04T11:47:35.000Z

geri-oc:

 phone und contact:phone -  Ich nutze es z.B. bei zwei Telefonnummern in einen Unternehmen.

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.

wambacher · 2018-09-04T12:06:09.000Z

mueschel:

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.

Wobei es “nur” ~2330 POI mit phone=contact:phone weltweit gibt. Zudem sind so nur Dubletten möglich, bei der 3. TelfNr klemmt es dann.

Also: wie bei vielen anderen Tags, die mehrere Werte haben, durch ; trennen.

amilen · 2018-09-04T13:53:12.000Z

geri-oc:

https://www.openstreetmap.org/changeset/58791024
Was ist denn nun hier der Stand?

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:

https://wiki.openstreetmap.org/wiki/Key:phone
https://wiki.openstreetmap.org/wiki/DE:Key:phone
https://wiki.openstreetmap.org/wiki/DE:Key:contact (Weitergeleitet von Key:contact:phone)
https://wiki.openstreetmap.org/wiki/Key:contact (Weitergeleitet von Key:contact:phone)

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.

Harald_Hartmann · 2018-09-04T14:33:26.000Z

geri-oc:

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.

Ist wahrscheinlich für ganz Thüringen erfolgt:

https://www.openstreetmap.org/changeset/58790138

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:

amilen · 2018-09-04T14:38:14.000Z

Harald Hartmann:

…, 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? …

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 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?

Harald_Hartmann · 2018-09-04T14:41:32.000Z

amilen:

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 …

amilen · 2018-09-04T14:42:46.000Z

Harald Hartmann:

Nachtrag: hier hatte sich der “Thüringer Kollege” geoutet…

“geoutet” Kann man so nicht sagen,

Dass es mit maproulette zusammenhängt, steht doch ganz klar und offiziell im Änderungssatzkommentar, siehe:
https://www.openstreetmap.org/changeset/58790138

geri-oc · 2018-09-04T15:13:28.000Z

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.”

Tordanik · 2018-09-04T18:05:08.000Z

amilen:

Das Thema und die Besprechungen dazu sind eingeschlafen. (Scheint zu komplex oder zu uninteressant geworden zu sein)

Ich finde das Thema nicht uninteressant und es wäre ein Gewinn für OSM, wenn es dazu eine Einigung gäbe. Dass ich zu diesem Thema nichts mehr weiter geschrieben habe, liegt daran, dass ich nach den bisherigen Diskussionsbeiträgen keinen klaren Weg zu einem Konsens sehe.

Ausschlaggebend scheinen ja letztlich nicht die Dinge zu sein, die wir gemeinsam recherchieren können (Nutzungshäufigkeit der Tags etc.), sondern das subjektive Empfinden, welche Variante sich für den Mapper “ordentlicher” anfühlt. Und da fehlt mir die Phantasie, wie in dieser Frage eine der Seiten die andere überzeugen könnte.

An diesem Punkt bleibt aus meiner Sicht eigentlich nur, herauszufinden, wie die Meinungen in der Community denn jetzt tatsächlich verteilt sind: Finden die Leute tatsächlich überwiegend, dass hier die alte Lösung die bessere ist – im Sinne von “keep it simple”? Oder ist das contact-Präfix unter denjenigen, die sich darüber Gedanken machen statt nur die Vorlagen zu nutzen, eigentlich populärer? Darum hatte ich ja in meinem vorigen Post angeregt, dass das Proposal von seinen Befürwortern zur Abstimmung vorgelegt wird. Sonst fällt mir wenig ein, wie wir das Problem in absehbarer Zeit gelöst bekommen.