Fand ich aber zu interessant, um das Thema nicht mal hier aufzunehmen.
Den oben verlinkten Thread wollte ich nicht kapern. Deshalb stelle ich hier mal die Frage: Kann mir mal bitte jemand den Unterschied zwischen beiden Keys erklären? Im WIKI gibt es für mich keine schlüssige Aussage, wann ich den einen und wann ich den anderen Key verwenden soll.
Das der website=* Key nur für Webseiten ohne Kontaktmöglichkeit genutzt wird, kann ich mir auch nicht vorstellen.
Also effektiv war das Key:contact-Schema gedacht, alle Kontaktdaten (website, phone, etc) abzulösen und in eine inhaltliche konsistenz zu bringen (Man hat halt in Editoren und als Datennutzer alle Kontakt-Daten zusammen).
Aber es ist ein oft geführter Streit, was man denn haben will und was nicht. Effektiv bilden sie beides ab. Viele Datennutzer haben Verfahren eingeführt, beides irgendwie zu verwenden (entweder wird ein Key priorisiert behandelt oder einfach beides angezeigt.)
Meine persönliche Meinung: Der Systematik halber eigentlich immer contact:* verwenden. (Nein, man muss hier nicht drauf antworten - ich will kein Streit aufmachen.)
in meinen Augen sind website (die ältere Variante) und contact:website ein und das selbe.
contact:* schafft halt einen Namensraum, der diverse Abfragen vereinfachen würde (wenn man sich dazu durchringen könnte, die älteren Variante abzuschaffen)
Wenn man alle Kontaktmöglichkeiten sucht, ist es einfacher nach contact:* zu suchen, als alle möglichen Kontaktvarianten (einschließlich smoke_signs, drums, can_phone ) einzeln abzufragen.
zumindest hierzulande gibt es eine Impressums-Pflicht, so dass immer eine Kontaktmöglichkeit über die Website besteht
Die Geschichte von “contact:” geht ungefähr so: es gab schon alle wesentlichen tags in weiterer Verbreitung (phone, fax, website, …) als sich jemand aufmachte, die Tagfragmentierung voranzutreiben, indem für jeden einzelnen dieser tags eine Variante vorgeschlagen wurde, der “contact:” vorangestellt wurde. Im Namen der Vereinfachung. Diese Idee hat sich zwar nicht allgemein durchgesetzt (die tags ohne die Vorsilbe sind in den 10 Jahren stärker gestiegen als die mit), aber sie hat genug Anhänger gefunden, dass sie sich auch nicht totgelaufen hat.
Der propagierte Vorteil der Vorsilbe war, dass man damit im Editor die Kontaktmöglichkeiten alle untereinander stehen hat (das könnte man auch einfacher haben, wenn man wie ID die Reihenfolge vorgibt und nicht nur alphabetisch macht).
Von den Vertretern der “contact:”-Vorsilbe wird gesagt, die tags hätten dieselbe Bedeutung. Neben der Definition im Wiki spielt bei tag-Definitionen aber immer auch mit, was der tag als Wort aussagt. Bei “contact” schwingt mit, dass es um Kontaktaufnahme geht. Aus Gründen der Konsistenz wäre es kontraproduktiv, eine Eigenschaft als “Kontaktmöglichkeit” zu klassifizieren, die das gar nicht ist.
Alleine schon daher würde ich davon abraten, für “website” einen “contact:”-Präfix zu verwenden, weil ich nicht unterscheiden will zwischen Webseiten, die zur Kontaktaufnahme genutzt werden können und solchen, wo das nicht geht.
Weiterhin hat das Setzen solcher Vorsilben den Nachteil, dass die Autocompletion nicht mehr richtig funktioniert. Anstatt 2-3 Buchstaben muss man viel mehr eingeben, bis man sinnvolle Vorschläge erhält.
ich bin klar dafür, die “contact:”-Vorsilbenidee aufzugeben, aber da es leider genug Leute gibt, die das gut finden, muss man halt auch in Zukunft für alle solchen tags doppelt suchen.
Mir ist eigentlich egal, welche Variante bevorzugt wird. Ich kann mich für beide erwärmen. Es wäre nur toll, es einheitlich zu haben. Die Diskussion darum verbraucht einfach zu viel Energie, die besser genutzt werden könnte.
Es gibt im Grunde keinen Unterschied. Beide machen oder sind für das exakt gleiche da. Der contact:= namensraum ist eben nur dazu da, die Sachen zu gruppieren. Das wäre ein Vorteil. Ein Nachteil gibts nicht, zumindest keinen, der mir bekannt ist.
“Das andere gibts öfter” ist weder ein Vorteil, noch ein Nachteil.
Ich selbst benutze das contact:= Schema, wenn ich aber wo einen tag hinzufüge, wo bereits mehrere nach altem Schema dabei sind, änder ich das üblicherweise nicht direkt ab.
Und, die Verbreitung hat unter anderem deswegen nicht zugenommen, weil iD das contact:= Schema nicht mag. Würde iD das einführen, sähe das ganze wohl gleich ganz anders aus. Üblicherweise ist eine Webseite immer für den Kontakt da. Zumindest finde ich dort auch alle weiteren Kontaktdaten. Ich persönlich gehe für den ersten Kontakt immer auf die Webseite und schaue dort, was es noch gibt. Ich kenne kein Beispiel, wo auf der Webseite der Kontakt bzw. die Kontaktaufnahme möglichst vermieden oder verhindert wird, zumindest bei keiner Firma.
Achso, wenn ich einfach über die API die Daten anzeigen lasse, kann ich das sortieren? Also rein pur die Daten. Man muss auch mal aus Sicht eines Entwicklers nur nicht nur des Nutzers denken…
Ich dachte das soll alles zusammen gruppiert werden? Was brauche ich dann da noch autocompletion?
Ich finde es schlimm, dass immernoch “Kontaktmöglichkeiten” nur unidirektional gesehen wird (aka Kunde → Firma). Eine Webseite ist primär für den Kontakt von Firma/Institution/etc. zum Kunden. Denn “Kontakt” bedeutet so erstmal nichts anderes, als “Berührung oder Verbindung” - Ich komme über eine Webseite mit einem Objekt in Kontakt, auch wenn ich “nur” weitere Informationen abrufen kann.
Ich hatte es bereits im anderen Thread geschrieben (und diesen hier übersehen):
Es gibt auch Webseiten, die der reinen Information und nicht der Kontaktmöglichkeit dienen. Z.B. eine Webseite zu einem Denkmal oder ähnliches. Da passt contact:website einfach nicht und schränkt den neutralen Key website unnötig ein. Das spricht für mich dagegen, website komplett durch contact:website zu ersetzen.
Das ist aber kein Daten-, sondern ein Komfortproblem. Gemäß “wir mappen nicht für den Renderer” (Anpassung der Daten, nur damit es gut aussieht) werden Daten auch nicht angepasst, nur um die Keystrokes in deinem UI zu optimieren.
Ein zielgerichtetes Autocomplete wäre, 1. ‘:’ als Stopper zu verwenden, so wie es ‘/’ auf bash-Kommandozeile der Fall ist, und 2. JOSM zu lehren, bei Autocompletion nicht den Text zu markieren.
Für effektives Arbeiten. Nicht jeder benutzt Eingabemaske und Maus für die Datenerfassung. Persönliche Erfahrung: Je professioneller desto weniger
Na ja - zum Beispiel genau das vorstehende. Und die unnötige Änderung von ein paar Millionen Objekten.
Das ist ein Indiz dafür, dass es mehr akzeptiert ist.
Der Gemeine Datennutzer muss eigentlich nur einmal in seinem Code aussuchen, welche Schlüssel er nutzen/unterstützen will. Daher ist das Argument der einfachern/besseren Nutzbarkeit ein schwaches Argument.
Schlimmer ist es, wenn man ständig die Schlüssel oder die Bedeutung derselben ändert Gibt es ja schon des öfteren bei OSM:-(
Eine “optimale” Datenbank gibt es nicht. Schon gar nicht bei einem offenen Projekt wie OSM mit diversen Nutzeranforderungen. Ich kenne aus meiner beruflichen Erfahrung genügend Optimierer, die die Daten so lange optimieren, bis sie in der täglichen Praxis an Bedeutung verlieren, weil es für einfache Nutzer zu aufwendig wird, die Anwendung immer wieder anzupassen…
Zum Thema: aus Sicht der Entwickler denken, und “Komfortproblem”. In OSM ist die Devise, es dem einfachen Mapper so leicht wie möglich zu machen. Die Entwickler kommen erst weiter hinten. Der Mapper geht vor. Viele Mapper nutzen ein freies Eingabefeld und nicht eine Maske, für die ist Autocompletion das ein und alles, und wenn man die tags halbwegs kennt ist das auch die effektivste Methode. Unnötige “Keystrokes” auf einem Mobildevice sind ein absoluter Showstopper. Mich nerven schon die “addr:”-Vorsilben, bis man zu addr:housenumber kommt (an addr:housename vorbei) muss man ewig tippen. Das wollen wir hoffentlich nicht zum Prinzip erklären.
Ich habe selbst schon einige Karten aus OSM-Daten gemacht, der angebliche Vorteil von “contact:” war die letzten 10 Jahre nur ein Mehraufwand, um diese tags auch noch einzusammeln, und ehrlich gesagt will man als Entwickler auch oft nicht alle tags (auch nicht alles “contact-Tags”) sondern eine Auswahl, d.h. eine Liste muss man sowieso machen. Allein schon wegen der Tippfehler, und auch, weil das oft überhaupt keine “Kontaktmöglichkeiten” sind. Ruf mich doch mal an mit “Vimeo”, oder “place” oder “phone:description” oder “pobox” oder “flickr” oder “p.o.box” oder “vhf”, oder “person”, oder “atom”, oder “housename” oder “pinterest” oder “addr” (2278 mal), oder “webcam” (1970). Einfach mal den langen Schwanz ansehen: https://taginfo.openstreetmap.org/search?q=contact%3A
Kein guter Punkt. Kontaktmöglichkeiten ist mehr als wo eine Person anrufen oder sonstwas kann. Wie oben schon gesagt → Kontakt - und das englische “contact” erst recht - umfasst viel mehr, nämlich alles, wo ich mit einem Objekt in KONTAKT (aka. Berührung) komme… (auch @dieterdreist)
Naja, aber auch nur, weil ID als meist genutzter Editor (v.a. von nur “Gelegenheitsmappern”) halt diese Option schon seit Jahren aus persönlicher Motivation nicht integriert hat. Und hätte man in ID die Wahl, würde die Verteilung sicher anders aussehen.
1.) Geht mir diese Bewertung und Klassifizierung von OSM-Mitwirkenden anhand des verwendeten Editors gehörig auf die Senkel.
2.) Was soll das heißen, “von nur Gelegenheitsmappern”. Ist das abwertend gemeint? Deren Beitrag ist mindestens genauso erwünscht und wertvoll, wie von Powerusern.
Zu 1. wo bewerte ich denn hier?
2. sorry, da haben die Finger was anderes getippt, als gedacht war - war mir nicht mehr aufgefallen. Sollte eigentlich heißen: "v.a. von “Gelegenheitsmappern”. Das soll auch nicht negativ gemeint sein, sondern spiegelt einfach die Realität wieder. Wer nur gelegentlich in OSM mappt, der wird sich keine extra Software installieren, sondern einfach auf den “Standard”-Webeditor zurück greifen. Was ja auch okay ist. Dann muss dieser aber alle entscheidenen Funktionen mit angeben. So z.B. halt auch den contact-Namensraum mit x-hunderttausend Verwendungen… Das tut er aber nicht und gegen ein Einbinden stellen sich die Entwickler.
Das war eigentlich auch einer meiner Gedanken, als ich den Thread anstieß. Ich bin ehr ein an Geographie interessiert Mapper und weniger ein Entwickler oder Kartenersteller. Deshalb bin ich bei den Keys auch ein Fan des KISS-Prinzips und nicht nur da. Ein weiterer Beweggrund, den Thread anzustoßen, war, dass ich festgestellt habe, dass ein Mapper massenhaft Impfzentren, die eigentlich schon fertig mit dem einfachen Schema getaggt waren, auf das contact:= Schema umgetaggt hat. Aus dem WIKI bin ich damals nicht schlau geworden und habe es erst einmal so gelassen. Kann es sein dass einige Mapper durch das massenhafte umtaggen auf das contact:= Schema durch die Hinterür vollendete Tatsachen schaffen wollen?
Namensräume dienen -bestenfalls- dazu einfacher eindeutige Schlüsselwerte zu erstellen, irgendwelche Abfragen werden dadurch überhaupt nicht einfacher (wenn man so oder so über alle Schlüssel iteriert, dann muss man tatsächlich weniger tippen, aber das fällt nicht wirklich unter “Abfrage”).
Ich finde es nicht KISS, wenn ich ein Element auf OSM angucke und alle Daten kreuzt und quer liegen. Auch beim Mappen finde ich es deutlich angenehmer, wenn ich durchgucken kann, dass alle contact:*-Tags beieinander stehen. Das ist wirkliches KISS. Denn da vergisst man nichts bzw. sieht schneller wenn etwas fehlt.
Nein, ich kenne es in beide Richtungen… Also da nimmt sich eine Fraktion der Anderen nichts
Ja klar… Kann man, wie viele Leute nutzen aber bei ID hauptsächlich die oben gruppierten Angaben…?
Lass mich raten. Da spricht bestimmt der Entwickler iaus dir?
Weshalb ich ein Anhänger des KISS-Prinzips bin, hast Du halt nicht mitzitiert. Ich will mich nicht erst, durch den Sinn und Zweck von diversen Doppelpunkt Keys durchwühlen, wenn auch der Weg ohne Doppelpunktkeys zum Ziel führt. Bin halt vordergründig kein Entwickler.
Aber das ist halt Interpretationssache, was man als bequem ansieht. Und ich wage mal zu behaupten, solche Mapper wie ich, die nur “die Welt mappen” wollen, gibt es in ziemlich großer Zahl in OSM.
) einzeln abzufragen.
Und ich wage mal zu behaupten, solche Mapper wie ich, die nur “die Welt mappen” wollen, gibt es in ziemlich großer Zahl in OSM.