[Talk-de] Best Practice fürs Erfinden von Tags

Guenther Meyer d.s.e at sordidmusic.com
Mo Nov 1 21:20:57 UTC 2010


Am Sonntag 31 Oktober 2010, 19:47:58 schrieb Jochen Topf:
> Ganz absurd wird es, wenn es wie im aktuellen healthcare-Vorschlag einen
> Tag "specialty" gibt, der die Art des Mediziners angeben soll, um den es
> hier geht.

das kann ich jetzt gar nicht nachvollziehen...


> Aber wenn ich das wiederverwenden will, z.B. mit
> "specialty=italian" an einem Restaurant oder "specialty=football" bei
> einem Sportverein. Dann habe ich total verschiedene Dinge miteinander
> vermischt.

> Will ich jetzt im Editor eine Auswahlbox einbauen, die mir eine
> Auswahl der wichtigsten Werte erlaubt, dann muss ich berücksichtigen, ob
> ein "heathcare", "restaurant" oder "sports"-Tag zusätzlich hier dran ist.

Ja, und? kontextabhaengige Menues sind nichts besonderes.


> Schau ich eine Statistik der Werte an, finde ich alle möglichen wild
> durcheinander. Das Wort "speciality" ist zu generisch, es sagt eigentlich
> nichts aus, außer dass hier eine hierarchische Unterordnung stattfinden
> will.

das ist doch eine Aussage?!


> Es wird niemals Sinn machen, die "specialty"-Fälle von healthcare
> und restaurant zusammen zu betrachten, so wie man z.B. im Falle von "name"
> gerne eine gemeinsame Suche hätte, sodass man nach Straßennamen und dem
> Namen von Medizinern suchen kann.

und deswegen soll man nicht dasselbe Tag verwenden duerfen?

Betrachte specialty als generisches Tag, das einfach als genauere 
Spezifizierung des Haupttags benutzt wird. Das ist besser und v.a. einfacher, 
als fuer jede einfache Spezifizierung einen neuen Key zu erfinden...


Ich muss da Martin vollstaendig recht geben:
"So speziell wie noetig, aber so generisch wie moeglich."


> Natürlich gibt es hier keine perfekte Definition, wie man diese Fälle
> auseinanderhalten kann. Es gibt eher einen fließenden Übergang. Vielleicht
> will man einer Brücke einen anderen Namen geben als der Straße darauf,
> dann wäre ein bridge_name nicht schlecht.

Sollte so ein Fall noetig sein, dann wuerde ich dafuer name:bridge bzw. 
name:street nehmen.
Denn in erster Linie ist es immer noch ein Name wie jeder andere auch - der 
halt in diesem speziellen Fall fuer einen bestimmten Teil des Objekts gilt.


> Hier hilft es auch, sich zu
> überlegen, was denn der typische, häufige Fall ist und was eher ein
> Spezialfall. Bei Namen will man sicher auch mal Namen bestimmter Objekte
> auf verschiedene Arten schreiben. Aber notfalls reicht es eben, alle
> gleich zu schreiben. Bei einem ref glaube ich da schon weniger dran. Ich
> will sicher keine Bushaltestellen-Bezeichner haben, die aussehen wie die
> typischen Straßensymbole (highway shields). Der einfache Fall sollte
> einfach sein (also vorallem nicht die Kombination mehrerer Tags
> erfordern), Spezialfälle aber durchaus.

Bei ref macht eine Unterscheidung wesentlich mehr Sinn, als bei name, ja.
Aber auch hier kann man die Bedeutung des Tags in den meisten Faellen vom 
Kontext ableiten.
Fuer Spezialfaelle kann man immer noch sowas wie ref:highway bzw. ref:bridge
verwenden.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 198 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20101101/ded7d3ec/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de