Verwendung des contact: Schemas

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.

MalgiK · 2018-09-10T14:21:22.000Z

Tordanik:

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.

Ich finde das Thema auch nicht uninteressant. Ich sehe ebenfalls schwarz für eine Einigung speziell jetzt nach so langer Zeit und der verschiedenen parallel etablierten Zuweisungsformen.

Tordanik:

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

Genau, das sind vermutlich reine subjektive Empfindungen, deshalb habe ich (etwas von der Seite https://wiki.openstreetmap.org/wiki/Gym_/_Fitness_centre inspiriert) hierzu auch mal eine Seite angelegt:
https://wiki.openstreetmap.org/wiki/Contact:website_/website/_url

Bitte schaut gerne mal drüber, erweitert sie gerne nach eigenen Wünschen oder subjektiven Erfahrungen speziell im zweiten Abschnitt:
https://wiki.openstreetmap.org/wiki/Contact:website_/website/url#Notes.26_Advantages
Oder löscht die Seite, sie falls sie nicht relevant ist.

Falls sie niemand löscht, würde ich ggf. später von den drei Hauptseiten:

https://wiki.openstreetmap.org/wiki/Key:url
https://wiki.openstreetmap.org/wiki/Key:website
https://wiki.openstreetmap.org/wiki/Key:contact:website
zu ihr verweisen.

PS: Könnte man es irgendwie hinbekommen, das z.B. in den Vorlagen der meistbenutzten Editoren (JOSM & iD) auch offensichtlich wird, dass es mehrere Möglichkeiten gibt die Kontaktinfo’s zu erfassen/anzugeben?

Discostu36 · 2018-09-11T06:49:00.000Z

R0bst3r:

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.

Das mache ich ganz bewusst so. Solange es keine Einigung gibt, welches der beiden Schemata benutzt werden soll, benutze ich beide. Nur so kann ich sicherstellen, dass alle Karten/Apps/Navis etc. die eingegebenen Daten auch auswerten.

mueschel · 2018-09-11T11:01:58.000Z

Discostu36:

Das mache ich ganz bewusst so. Solange es keine Einigung gibt, welches der beiden Schemata benutzt werden soll, benutze ich beide. Nur so kann ich sicherstellen, dass alle Karten/Apps/Navis etc. die eingegebenen Daten auch auswerten.

Bitte nicht. Die Unterstützung für beide Tags ist weit verbreitet genug.
Oder taggst du Fußballfelder auch mit landuse=grass, weil manche Karten Sportplätze nicht anzeigen?

Discostu36 · 2018-09-11T11:12:11.000Z

mueschel:

Discostu36:

Das mache ich ganz bewusst so. Solange es keine Einigung gibt, welches der beiden Schemata benutzt werden soll, benutze ich beide. Nur so kann ich sicherstellen, dass alle Karten/Apps/Navis etc. die eingegebenen Daten auch auswerten.

Bitte nicht. Die Unterstützung für beide Tags ist weit verbreitet genug.
Oder taggst du Fußballfelder auch mit landuse=grass, weil manche Karten Sportplätze nicht anzeigen?

Der Vergleich hinkt, leisure=pitch und landuse=grass beschreiben ja gerade nicht dieselbe Sache. Und das Eintragen beider Kontakt-Fassungen ist die einzige Möglichkeit, das zu verhindern, was hier bereits moniert wurde: Unnötige Änderungen, weil jemand vom alten ins neue Schema ändern will oder umgekehrt.

Oder anders ausgedrückt: Ich habe keine Lust, das Schema zu nutzen, was mir besser gefällt. Ich will das Schema benutzen, das als Standard festgelegt wurde. Und solange das nicht passiert ist, benutze ich weiter beide.

R0bst3r · 2018-09-11T12:52:17.000Z

Discostu36:

Oder anders ausgedrückt: Ich habe keine Lust, das Schema zu nutzen, was mir besser gefällt. Ich will das Schema benutzen, das als Standard festgelegt wurde. Und solange das nicht passiert ist, benutze ich weiter beide.

[Ironie]Dann kann man ja auch Name=Arztpraxis mit amenity=doctors, amenity_1=doctor, medical=doctor, healthcare=doctor, doctors=yes und health_facility:type=office mit office=physician und einer Relation type=health und health_person:type=physician taggen. Nicht vergessen, das Gebäude als building=doctors. Verbesserungsvorschläge? Irgendwas wird der Auswerter schon brauchen können.[/Ironie]
PS: Alles in Gebrauch laut taginfo.osm.org.