Ich nutze das website=* (1 312 586 tag-info) als Anzeige der Webseite und auch die anderen “einfachen” Angaben (phone/email).
Plötzlich sind die “leer”.
Da hat es jemanden nicht gefallen und hat das zu contact:website (152 348 tag-info) usw. geändert. Das ist auch wieder so ein Beispiel irgendwo etwas zu ändern, wo man nicht vor Ort ist. Habe einen CS-Kommentar hinterlassen und wieder geändert.
Noch einmal die Frage: Ist das “alte” nun überholt und sollte nur noch das “neue” angewendet werden?
Nein kein mechanischer Edit. Da war bei einem tag ein Tippfehler, der wurde ordnungsgemäß korrigiert. Aber dann alles “umstellen” finde ich nicht richtig.
Nö, solange das gute alte website in den Daten noch 5-10 mal öfter verwendet wird und es in der Doku nicht als obsolet gekennzeichnet wird, ist es nicht überholt.
Ich bin auch ein “Fan” vom contact-Schema und erfasse alle Links so, lasse aber - inzwischen - meine Finger von contact-losen Links.
Für einen Auswerter - und dazu zähle ich ich dich auch - sollte es machbar sein, beide Schemata parallel zu verwenden. Ansonsten geht ihm immer was durch die Lappen.
Leider setzen immer mehr User ihre Vorlieben durch Veränderungen im WIKI durch, was ich nicht für richtig halte. Die dort verlinkten Dokumente als Nachweis (pdf) sind von 2001 und wesentlich älter als die DIN.
Ich bin bemüht meinen Ort aktuell zu halten. Dabei bin ich dankbar, wenn andere auch “falsches” korrigieren - aber nicht, wenn “Richtiges” einfach nach eigenen Vorlieben geändert wird.
Mittlerweile ist es besser sich einen weißen Fleck zu suchen.
Bei contact:website finde ich die pauschale Voranstellung von “contact:” quasi “falsch”, es geht bei Webseiten ja nicht nur um Kontakt, im Gegenteil gibt es auch Webseiten, die überhaupt keine Kontaktmöglichkeit bieten. Das hingegen zu differenzieren in Webseiten, die dem Kontakt dienen und solche, wo das nicht der Fall ist, wäre noch eine Stufe schlimmer
Grundsätzlich (phone, fax, email, etc.)
Als Auswerter würde ich derzeit auch noch die “contact:”-Versionen mitberücksichtigen, wobei seit vielen Jahren absehbar ist, dass sich das nicht durchsetzt (die Kurve mit “contact” ist viel flacher als die ohne, und das seit immer und unverändert), von daher würde ich an die Leute die das immer noch nutzen appellieren ob es nicht Sinn macht, darauf zu verzichten, es vergrößert nur die Tagzersplitterung.
Nüchtern betrachtet entscheidet sich die Frage was sich durchsetzt wahrscheinlich hauptsächlich dadurch, welche presets iD und JOSM für diese Daten verwenden.
Nach der aktuellen Diskussion um den Namespace service:vehicle braucht man dem Autor von iD vermutlich nur einen kleinen Wink zum contact-Namespace geben, dann geht das von heute auf morgen in die andere Richtung
Das hast du ja jetzt auch als statement auf die Wiki-Seite mit aufgenommen. Das Wiki sollte aber objektiv sein - für viele der social-media-Kontakte gibt es keine Entsprechung ohne “contact” (mit Ausnahme von facebook, aber auch hier ist “contact” wesentlich häufiger).
Ich bin übrigens bei den spezielleren Dingen (nicht unbedingt bei phone, email) sehr für die Verwendung des Prefixes: auch wenn man einen Service nicht direkt kennt, so kann man mit dem Prefix sehen, dass es sich um eine Kontaktmöglichkeit handelt und diese auch einfach gebündelt darstellen.
+1. Ich sehe auch keinen Schaden darin, vor bestehende Kontaktangaben ein contact: zu setzen, wenn ich ein Objekt schon mal in der Mangel habe. Es erleichtert die Auswertung.
Und trotzdem wird ein Schaden erzeugt, wenn alte Abfragen nach phone=* plötzlich leer sind. Dann macht es doch doppeltgemoppelt und setzt das contact:phone=* meinetwegen zusätzlich.
Was meinst du mit “alte Abfragen”? Das ‘contact:’ Schema ist ja nicht gerade eine neue Erfindung, ‘contact:phone’ existiert seit 2008 (und zeitweise sogar häufiger als ‘phone’)
Ich habe doch nichts dagegen contact:= zu verwenden. Verstehe aber nicht wenn jahrelang phone=* in den Daten ist und nun in contact:phone=* geändert wird.
Warum kann z.B. auch das Wiki bezüglich der Telefonnummer nicht einheitlich sein - jeder schreibt einfach etwas nach seinen “Wünschen und Vorstellungen”:
phone=+49 123 4567890
contact:phone=+49 123 456 7890
… dann sind diese Abfragen hochgradig wartungsbedürftig und sollten dringendst damit anfangen, contact:phone zusätzlich abzufragen. Schon ist der Treffer wieder da. Wer nur phone=* abfragt, der will ausdrücklich keine vollständigen Daten haben
Der Vorteil des contact-Schemas ist ja offensichtlich: Mit einer Abfrage nach contact:* bekommst du sämtliche so erfassten Kontaktdaten auf einmal zum lokalen Weitersortieren und musst nicht separat nach phone und fax und email und website und twitter und btx und wasweißich abfragen und dann doch was vergessen. Das mindert auch die Overpass-Serverlast
Mit welcher Begründung? Dass der Löwenanteil der Einträge in der DB ein anderes Schema als das auf dieser Seite beschriebene nutzt erscheint mir durchaus einen Warnhinweis wert.
Welche der von dir gelöschten Aussagen war denn objektiv unwahr? Dass die Varianten ohne contact: häufiger verwendet werden und ihren Vorsprung derzeit sogar noch ausbauen muss man nicht gut finden, stimmt aber soweit ich sehe.
Du hast ja im Übrigen auch nicht nur die kleinen Änderungen von vorgestern rückgängig gemacht, sondern gleich den kompletten Hinweiskasten ersetzt.
Die Änderung ist nur ein Vorschlag basierend auf den Äußerungen hier im Thread, ich lasse mich da gerne auch überstimmen.
die alte Warnung bezog sich gerade mal auf 3 der ungefähr 30 gelisteten Tags. Bei vielen davon gibt es keine Entsprechung ohne ‘contact:’ oder die ‘contact:’-Variante ist wesentlich häufiger anzutreffen
‘url’ gehört da gar nicht rein, da es keine Entsprechung innerhalb des ‘contact’ Schemas gibt.
ein Faktor ~2 in der Verwendung zwischen den verschiedenen Keys mit Ausnahme von phone, website und email würde ich jetzt nicht “far more popular” nennen
Ich sehe nicht, dass ein Key schneller wachen würde als der andere - der prozentuale Abstand z.B. bei phone und website wird sogar seit Jahren langsam kleiner.