phone und contact:phone

derstefan · 2012-03-16T22:32:03.000Z

kerosin:

Meinst du wir sollten einen Key ersetzen?

Ja. Zwei sind in keiner Weise sinnvoll, da sie keine unterschiedliche Bedeutung haben. (z.B. man_made=cross und historic=wayside_cross haben unterschiedliche Bedeutung.) Oder?

kerosin · 2012-03-16T22:50:52.000Z

Ja, so gesehen wäre ich auch dafür den phone/website-Key mit dem contact-Key zu ersetzen.

Allerdings hat so ein Holzhammervorgehen einen faden Beigeschmack und wirft Fragen auf wie:

Für welchen der beiden Keys entscheiden wir uns?
Warum entscheiden wir uns für einen der Beiden. Ist einer wirklich “besser” als der andere?
Wer gibt uns (deutsche OSM-Forenmitglieder) das Recht dies international festzulegen?

Wobei ich an anderen Tagen das Gefühl habe etwas mehr totalitäre Ordnung würde so einem Projekt nicht schaden

woodpeck · 2012-03-16T23:48:27.000Z

derstefan:

kerosin:

Meinst du wir sollten einen Key ersetzen?

Ja. Zwei sind in keiner Weise sinnvoll, da sie keine unterschiedliche Bedeutung haben. (z.B. man_made=cross und historic=wayside_cross haben unterschiedliche Bedeutung.) Oder?

Automatische Ersetzungen sind nicht gern gesehen. Automatische Ersetzungen, bei denen ein haeufiger genutzter Key durch einen (vermeintlich ordentlicheren, besseren, schoeneren, neueren) seltener benutzen Key ersetzt wird, schon gleich gar nicht. Wollte man eine solche Ersetzung weltweit durchfuehren, so muesste man das vorher auch weltweit diskutieren und zu einem Konsens kommen. Konsens heisst dabei nicht, dass alle dafuer sein muessen, aber es heisst auch, dass 51% nicht ausreichen (schon gar nicht, wenn die 51% alle aus Deutschland sind und sich dann dranmachen, Tags in Peru “aufzuraeumen”).

Bye
Frederik

derstefan · 2012-03-17T00:35:47.000Z

Danke für den Einwand, woodpeck. Dass jemand solch große Eingriffe auf eigene Faust tätigt, verbietet sich natürlich von selbst. Die phone-contact:phone-Problematik ist eigentlich auch nur ein Beispiel für zwei Schlüssel, die nebeneinander gewachsen sind. Vermutlich gab es damals kein richtiges Proposal, über das abgestimmt wurde. Ich befürchte, dass in diesem Fall hier beide Schlüssel einfach weiter nebeneinander existieren werden. Mit einer Dampfhammer-Aktion würde man sich lediglich Feinde machen. Umso wichtiger finde ich es, zukünftig Proposals entsprechend wichtig zu nehmen und gut auszuarbeiten, um solche Dinge vermeiden zu können.

Wir sollten weiterhin Wert darauf legen, das Wiki inhaltlich sauber und soweit möglich widerspruchsfrei zu halten.

Walter_Schlögl · 2012-03-17T02:22:35.000Z

Wenn man solche TAGs wirklich ersetzen möchte, dann könnte das ähnlich aufwendig werden wie der Lizenzwechsel.

Phase 1: Ankündigung, damit sämtliche Renderer sicherstellen können, den neuen TAG zu unterstützen.
Phase 2: Bot, der bei neuen Datensätzen den alten TAG automatisch durch den neuen ersetzt.
Phase 3: Unplausibilitäten aufräumen, wo beide TAGs mit unterschiedlichem Wert verwendet sind.
Phase 4: Bot, der bei allen bestehenden TAGs die Ersetzung durchführt.

Ich würde mich daran vielleicht sogar lieber beteiligen als an dem nervigen Lizenzwechsel,
andere Mapper könnten das aber sicherlich komplett anders bewerten.

Walter

Fabi2 · 2012-03-17T05:06:11.000Z

Was ist denn der informationelle Gewinn aus dem zusätzlichen “contact:”? Das eine Telefon-/Fax- und Emailadresse, etc. zum kontaktieren da ist, sollte wohl jeder auch ohne diesen Zusatz wissen. Ergebnis ist also Null, außer das es mehr Tipperei ist und die Datenbank aufbläht. Aber die JOSM-Vorlage pusht dieses Nischentaggingschema, warum auch immer. Ordnung schaffen ist für mich, diese Tags wieder auf die Ursprungswerte zurückzuändern.

wambacher · 2012-03-17T08:12:52.000Z

Fabi2:

Aber die JOSM-Vorlage pusht dieses Nischentaggingschema, warum auch immer.

Nicht ganz: “Mein” Josm (5047) bietet beide Versionen an.
Dennoch halte ich “Contact” auch für eine Null-Info.

Gruss
Walter

chris66 · 2012-03-17T09:54:41.000Z

Fabi2:

Was ist denn der informationelle Gewinn aus dem zusätzlichen “contact:”? Das eine Telefon-/Fax- und Emailadresse, etc. zum kontaktieren da ist, sollte wohl jeder auch ohne diesen Zusatz wissen. Ergebnis ist also Null, außer das es mehr Tipperei ist und die Datenbank aufbläht. Aber die JOSM-Vorlage pusht dieses Nischentaggingschema, warum auch immer. Ordnung schaffen ist für mich, diese Tags wieder auf die Ursprungswerte zurückzuändern.

+1

kerosin · 2012-03-17T10:11:00.000Z

Fabi2:

Was ist denn der informationelle Gewinn aus dem zusätzlichen “contact:”? Das eine Telefon-/Fax- und Emailadresse, etc. zum kontaktieren da ist, sollte wohl jeder auch ohne diesen Zusatz wissen.

Gar keiner. Es ist aber ein Vorteil ähnliche Keys zu bündeln und als Subkeys zu unterteilen. Anstatt addr:housenumber könnte man auch nur housenumber nehmen, aber so kann man schön alle Adressdaten zusammenfassen. Ähnlich gut könnte es bei den Kontaktdaten laufen.
Aber wem erzähl ich was von Subkeys, in deinem Healthcare-Proposal wird das ja auch zur genüge genutzt

Fabi2:

Ergebnis ist also Null, außer das es mehr Tipperei ist und die Datenbank aufbläht.

Wenn man so argumentiert, dann könnte man auch anstatt website nur noch web zu nehmen oder anstatt phone nur fon. Schließlich weiß ja jeder was gemeint ist und alles andere füllt die Datenbank ja nur unnötig.

Ob das Taggingschema ein Nischendasein führt oder nicht ist ja eigentlich egal. Wichtig ist es, ob es mehr Aufmerksamkeit verdient oder nicht.

flaimo · 2012-03-17T12:36:55.000Z

für entwickler bietet sich der vorteil, dass er namepaces ggf. komplett ausschließen kann wenn er die daten für sein anwendungsgebiet nicht benötigt, ohne dabei alle subkeys kennen zu müssen. sind kontaktdaten nicht erforderlich, so kann er pauschal alles mit “contact:” rauswerfen und muss sich so nicht darum kümmern, ob von zeit zu zeit nicht doch neue keys, wie zB “skype”, dazugekommen sind. brauche ich keine adressdaten nehme ich einfach “addr:” raus, egal ob da jetzt ein neues “addr:door” dazugekommen ist, oder nicht. mach beim processing von mehreren milliarden datenbankzeilen sicher einen performanceunterschied. von dem her bin ich eigentlich generell dafür die wichtigsten tags in namespaces zu untergliedern.

wambacher · 2012-03-17T12:58:06.000Z

flaimo:

von dem her bin ich eigentlich generell dafür die wichtigsten tags in namespaces zu untergliedern.

so langsam beginnt mir diese Richtung zu gefallen.

Gruss
Walter

“Der Kopf ist rund, damit die Gedanken die Richtung wechseln können”

.

flaimo · 2012-03-17T13:16:01.000Z

ein weiterer vorteil wäre auch, dass man in editoren tags mit namespaces zusammenfassen kann und zB im tageditor diese bereiche wie in einer baumansicht auf- und zuklappen kann. speziell bei tankstellen wo “fuel”, “addr” und “contact” aufeinandertreffen werden die tagsets schon ziemlich lang.
weiters kann es auch für das verständnis bei neuen usern besser sein. kam einer wird wissen was “hgv” oder “psv” bedeutet, aber mit einem potentiellen namespace “access” würde er zumindest schon mal wissen zu welchem bereich es gehört.

derstefan · 2012-03-17T13:17:27.000Z

flaimo:

für entwickler bietet sich der vorteil, dass er namepaces ggf. komplett ausschließen kann wenn er die daten für sein anwendungsgebiet nicht benötigt, ohne dabei alle subkeys kennen zu müssen. sind kontaktdaten nicht erforderlich, so kann er pauschal alles mit “contact:” rauswerfen und muss sich so nicht darum kümmern, ob von zeit zu zeit nicht doch neue keys, wie zB “skype”, dazugekommen sind. brauche ich keine adressdaten nehme ich einfach “addr:” raus, egal ob da jetzt ein neues “addr:door” dazugekommen ist, oder nicht. mach beim processing von mehreren milliarden datenbankzeilen sicher einen performanceunterschied. von dem her bin ich eigentlich generell dafür die wichtigsten tags in namespaces zu untergliedern.

Da muss ich widersprechen. Für die Datenbank macht es keinen Unterschied, wie die Schlüssel heißen. Die “Namespaces” sind rein für die Übersichtlichkeit (“human readable”). Mit osm2pgsql zum Beispiel muss man jeden Schlüssel angeben, der als Spalte in die Datenbank hinzugefügt werden soll.

Die Subkey-Konvention dient rein den Benutzern.

viw · 2012-03-17T14:21:09.000Z

derstefan:

Da muss ich widersprechen. Für die Datenbank macht es keinen Unterschied, wie die Schlüssel heißen. Die “Namespaces” sind rein für die Übersichtlichkeit (“human readable”). Mit osm2pgsql zum Beispiel muss man jeden Schlüssel angeben, der als Spalte in die Datenbank hinzugefügt werden soll.

Die Subkey-Konvention dient rein den Benutzern.

Das ist nicht ganz richtig. Du hast nicht verstanden worauf er hinaus wollte. Natürlich musst du in osm2pgsql jeden Key angeben. Es gibt aber auch noch eine “richtige” OSM Datenbank. Und wenn du dir anschaust, wie dort die Daten gespeichert sind, im übrigen bei der osm2pgsql Datenbank auch, dann wirst du merken, welchen Unterschied es macht.
Schau einfach mal in die Tabelle planet_osm_ways. Dort findest du dann Arrays in denen die Tags gespeichert sind, statt Spalten wie in der Tabelle lines.
Und dort kann es dann schon interessant sein erstmal mit einem namespace zu filtern.

aighes · 2012-03-17T14:44:20.000Z

ALSO…Wenn das Namespacing denn irgendwann mal sinnvoll eingesetzt wird, kann man gerne an ein großflächiges Anpassen einiger Taggs nachdenken. Aber bis dahin halte ich davon recht wenig.

Fabi2 · 2012-03-17T14:52:06.000Z

kerosin:

Fabi2:

Was ist denn der informationelle Gewinn aus dem zusätzlichen “contact:”? Das eine Telefon-/Fax- und Emailadresse, etc. zum kontaktieren da ist, sollte wohl jeder auch ohne diesen Zusatz wissen.

Gar keiner. Es ist aber ein Vorteil ähnliche Keys zu bündeln und als Subkeys zu unterteilen. Anstatt addr:housenumber könnte man auch nur housenumber nehmen, aber so kann man schön alle Adressdaten zusammenfassen. Ähnlich gut könnte es bei den Kontaktdaten laufen.

Einen einzelnen Node mit mit z.B. city=Kleinstadt statt addr:city=Kleinstadt könnte man in einem schlecht gemappte Gebiet leicht mißverstehen, von daher braucht man da addr:um es eindeutig zu machen.

Wenn du Keys bündeln möchtest, dann mach doch eine neue Relation type=contact mit phone,fax,email, website, etc. auf. Das ist im Moment die sauberste Lösung dafür.

kerosin:

Aber wem erzähl ich was von Subkeys, in deinem Healthcare-Proposal wird das ja auch zur genüge genutzt

Da hast du aber den Unterschied zu “contact:” übersehen, nämlich, daß die Keys damit genauer iheren Zweck angeben, eben z.B. die Spezialisierung im Gesundheitswesen oder das es sich um eine Einrichtung (Gebäude) des Gesundheitswesen handelt und da die HOT-Leute da z.B. auch z.B noch ein health_facility:access=* mit ran taggen, braucht man auch Subkeys.

kerosin:

Fabi2:

Ergebnis ist also Null, außer das es mehr Tipperei ist und die Datenbank aufbläht.

Wenn man so argumentiert, dann könnte man auch anstatt website nur noch web zu nehmen oder anstatt phone nur fon. Schließlich weiß ja jeder was gemeint ist und alles andere füllt die Datenbank ja nur unnötig.

Ein besserer “ich habe keine Argumente mehr”-Pseudoargument ist dir da nicht eingefallen? Generell gilt die Regel, das das ganze im Englischen ja eine für jeden nachvollziehbare und eindeutige Bezeichnung sein sollte und das ist bei Sachen wie z.B. “fon” absolut nicht der Fall, kannst es ja mal bei Google eingeben, um den unbedarften Mapper zu simulieren. Mal ganz davon abgesehen, das es für micht einen unterschied zwischen “web” und “website” gibt.

kerosin:

Ob das Taggingschema ein Nischendasein führt oder nicht ist ja eigentlich egal. Wichtig ist es, ob es mehr Aufmerksamkeit verdient oder nicht.

Das ist das Gleiche, denn eine aus meiner Sicht unnütze Verkomplizierung eines bereits vorhandenen Taggingschemas, hat doch bestenfalls die Aufmerksamheit in Hinblick auf dessen Wiederanpassung an das alte vorhandenen Schema verdient.

Fabi2 · 2012-03-17T15:11:53.000Z

flaimo:

für entwickler bietet sich der vorteil, dass er namepaces ggf. komplett ausschließen kann wenn er die daten für sein anwendungsgebiet nicht benötigt, ohne dabei alle subkeys kennen zu müssen. sind kontaktdaten nicht erforderlich, so kann er pauschal alles mit “contact:” rauswerfen und muss sich so nicht darum kümmern, ob von zeit zu zeit nicht doch neue keys, wie zB “skype”, dazugekommen sind. brauche ich keine adressdaten nehme ich einfach “addr:” raus, egal ob da jetzt ein neues “addr:door” dazugekommen ist, oder nicht. mach beim processing von mehreren milliarden datenbankzeilen sicher einen performanceunterschied. von dem her bin ich eigentlich generell dafür die wichtigsten tags in namespaces zu untergliedern.

Ja, da wäre eben aus meiner Sicht gut, wenn die API schon baumartiges Tagging unterstützen würde, auch weil man dann nicht x-fachh “addr:” erneut angeben müßte, die sind dann alle Subkeys vom Zweig “addr”. Diese Lösung ist für beide gut, für den Menschen und für den Rechner.

Es ist aber auch nicht so, daß es im Moment unmöglich wäre, so etwas zu machen, da man solche Bäume wenigstens mit Relationen aufbauen kann. type=health läßt da grüßen… Weil schleißlich beinhaltet z.B. ein Ärztehaus diverse Praxen, und evt. noch 'ne Apotheke und sagen wir man einenTante-Emma-Laden, dann gehören die Praxen, deren Beschäftigte, und die Apotheke strukturell mit zur Gesundheitseinrichtung Ärztehaus, nicht aber der dort befindliche Tante-Emma-Laden.

Ähnlich könnte man auch mit anderen Bereichen verfahren und da spezielle Relationen basteln, weil dann erstellt man eben drei type=amenity-Relationen für amenity=cafe;bar,restaurant.

kerosin · 2012-03-18T07:47:11.000Z

Fabi2:

Da hast du aber den Unterschied zu “contact:” übersehen, nämlich, daß die Keys damit genauer iheren Zweck angeben, eben z.B. die Spezialisierung im Gesundheitswesen oder das es sich um eine Einrichtung (Gebäude) des Gesundheitswesen handelt und da die HOT-Leute da z.B. auch z.B noch ein health_facility:access=* mit ran taggen, braucht man auch Subkeys.

Der selbe Vorteil eröffnet sich doch auch beim contact-Key. Mir fällt jetzt spontan ein: contact:phone:mobile, contact:phone:reception, contact:phone:hotline, contact:website:operator, contact:website:distribution etc
Ein einzelner phone-Tag ohne weitere Informationen könnte bei komplexeren Infrastruktur eines Unternehmens auch zu Verwirrung führen. Erreich ich darüber die Kundenhotline, ein hausinternes Büro oder den Chef persönlich?

Fabi2:

Ein besserer “ich habe keine Argumente mehr”-Pseudoargument ist dir da nicht eingefallen? Generell gilt die Regel, das das ganze im Englischen ja eine für jeden nachvollziehbare und eindeutige Bezeichnung sein sollte und das ist bei Sachen wie z.B. “fon” absolut nicht der Fall, kannst es ja mal bei Google eingeben, um den unbedarften Mapper zu simulieren. Mal ganz davon abgesehen, das es für micht einen unterschied zwischen “web” und “website” gibt.

Es war nicht mal ein Argument, es ging um deine Argumentation Ok die Beispiele waren schlecht, aber mal ehrlich “zu viel Getippe” ist bei halbautomatisierten Editoren kein Argument mehr.

Fabi2 · 2012-03-18T18:26:26.000Z

kerosin:

Fabi2:

Da hast du aber den Unterschied zu “contact:” übersehen, nämlich, daß die Keys damit genauer iheren Zweck angeben, eben z.B. die Spezialisierung im Gesundheitswesen oder das es sich um eine Einrichtung (Gebäude) des Gesundheitswesen handelt und da die HOT-Leute da z.B. auch z.B noch ein health_facility:access=* mit ran taggen, braucht man auch Subkeys.

Der selbe Vorteil eröffnet sich doch auch beim contact-Key. Mir fällt jetzt spontan ein: contact:phone:mobile, contact:phone:reception, contact:phone:hotline, contact:website:operator, contact:website:distribution etc
Ein einzelner phone-Tag ohne weitere Informationen könnte bei komplexeren Infrastruktur eines Unternehmens auch zu Verwirrung führen. Erreich ich darüber die Kundenhotline, ein hausinternes Büro oder den Chef persönlich?

Wie schon geschrieben, ist das aus meiner Sicht absolut nicht vergelichbar.
Wo ist denn der Vorteil von contact:phone:operator, contact:phone:mobile, contact:phone:reception, contact:phone:hotline und contact:website:operator im Vergleich zu operator:phone (55), operator:fax (66), operator:website (13), phone:mobile (194), phone:hotline oder phone:reception? Die paar vereinzelten Keys (alle nur 1x) auf taginfo (http://taginfo.openstreetmap.org/search?q=contact%3Aphone%3A) sagen im Vergleich zu den Benutzungszahlen der anderen Keys (in Klammern), doch mehr als tausend Worte.

kerosin:

Ok die Beispiele waren schlecht, aber mal ehrlich “zu viel Getippe” ist bei halbautomatisierten Editoren kein Argument mehr.

Bei “contact:” tippe ich erst mal 8 Zeichen ohne Informationsgehalt ein, bevor ich zum eigentlich Key komme, bei z.B. phone sollte man dadgegen spätestens nach dem 3 Buchstaben den kompletten Key dastehen haben.

GeoCounter · 2012-03-18T18:39:18.000Z

Fabi2:

Bei “contact:” tippe ich erst mal 8 Zeichen ohne Informationsgehalt ein, bevor ich zum eigentlich Key komme, bei z.B. phone sollte man dadgegen spätestens nach dem 3 Buchstaben den kompletten Key dastehen haben.

Die Argumentation halte ich aus zwei Gründen für falsch: Zum Einen wird man “contact:*” auch schon vor Vollendung der Eingabe der 8 Zeichen angeboten bekommen, zum Anderen erhält man so eine Übersicht über sämtliche Kontaktmöglichkeiten und muss nicht jede selbst angeben (trägt möglicherweise zur Vollständigkeit der Angaben bei).