Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Do not use generic words for keys Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Wie ist denn nun die allgemeine Meinung: sollen es jeweils eindeutige (unique) keys sein, oder soll die Bedeutung (ggf. auch) kontextabhängig sein? Je früher man solche Fragen klärt, um so eher kann man konsistent weitermachen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 01.11.2010 15:54, schrieb M∡rtin Koppenhoefer: Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Und noch ein Beispiel: bicycle=yes an Barrieren heisst: hier können Fahrräder passieren; an Wegweisern (information=guidepost) bedeutet es: Hier gibt's Infos für Radfahrer. Interessant wird es, wenn der Wegweiser an einer Barriere befestigt ist. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
On Mon, Nov 01, 2010 at 03:54:56PM +0100, M∡rtin Koppenhoefer wrote: Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Do not use generic words for keys Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Gutes Beispiel. Wenn man auf http://taginfo.openstreetmap.de/keys/service schaut, dann sind die häufigsten Values: parking_aisle, driveway, alley, spur, yard, siding, parking, yahoo aerial images, dealer;repair, parts, ... Offensichtlich ist das eine wilde Mischung aus Zusatztags für highway, railway und shop. M.E. ein klarer Fall, wo das in mehrere Tags aufgelöst gehört. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Da kann man sich auch auf den Standpunkt stellen, dass das eher wie name ein Tag mit beliebigen textuellen Werten ist, der übergreifend benutzt werden kann. Bin ich mir auch nicht sicher. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 1. November 2010 18:00 schrieb Jochen Topf joc...@remote.org: operator Da kann man sich auch auf den Standpunkt stellen, dass das eher wie name ein Tag mit beliebigen textuellen Werten ist, der übergreifend benutzt werden kann. Bin ich mir auch nicht sicher. ja, wobei auch width und sowas ja nicht statistisch ausgewertet wird, sondern freie Werte üblich sind. Trotzdem will man da Klarheit haben, was gemeint ist. D.h. Definition und Dokumentation. ist Man darf m.E. nicht nur auf Taginfo und ähnliches in der jetzigen Form schielen, wie es da am einfachsten ist, eine Auswertung zu machen, evtl. müsste man dort auch nochmal eine Unterscheidung treffen, in welchem Kontext ein Tag verwendet wird. Grundsätzlich sind verschiedene Bedeutungen desselben Tags wie bei service (übrigens bisher AFAIK wenigstens mit unique values) eigentlich kein Problem, solange es bei den Kombinationen keine Überschneidungen gibt (also z.B. ein way railway und highway gleichzeitig wäre). Bisher steht eigentlich nur fest, dass unique keys die Auswertung erleichtern und es andererseits dem Mapper geringfügig schwieriger machen, da sich das Vokabular vergrößert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
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. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 19:56:54 schrieb Karl Eichwalder: Bernd Wurst be...@bwurst.org writes: Also klar, ein paar Ausnahmen gibt es: name, comment, solche Dinge, die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. Manche dinge haben allerdings zwei doer mehr namen; standardbeispiel: straße auf einer brücke. Das können wir so ohne weiteres nicht abbilden. name:highway = foo name:bridge = bar signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Ich freue mich über Rückmeldungen hier oder im Wiki und würde mich auch freuen, wenn andere ihre persönliche Liste aufstellen. Das sind dann alles Schritte zu einem Konsens. Danke Jochen, finde ich allgemein sehr sinnvoll. Habe ein paar kleine Tippfehler korrigiert und ein paar Anmerkungen, mit denen ich hier anfange (bin etwas unter Zeitdruck, daher kommt vermutlich später mehr): Do not use generic words for keys Hier führst Du aus, dass man keine allgemeinen Keys verwenden/erfinden sollte. Ich kann das nicht so gut nachvollziehen. Klar haben diese dann unterschiedliche Bedeutung, je nach Kontext, aber ist das schlimm? Nimm z.B. name. Wäre es da besser street_name als Name für Straßen zu verwenden und station_name für Bahnhofsnamen? Solange es um eine allgemeine (assimilabile) Eigenschaft geht, sind universell verwendbare Keys m.E. durchaus sinnvoll. Schwierig wird es bei solchen Sachen wie width. Da ist dann teilweise schon unklar, ob es um die Durchgangsbreite oder die Breite des Objekts geht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Hallo Jochen, danke für: http://wiki.openstreetmap.org/wiki/User:Joto/How_to_invent_tags Kannst Du das auch noch in Deutsch zur Verfügung stellen? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 13:20 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Do not use generic words for keys Hier führst Du aus, dass man keine allgemeinen Keys verwenden/erfinden sollte. Ich kann das nicht so gut nachvollziehen. Klar haben diese dann unterschiedliche Bedeutung, je nach Kontext, aber ist das schlimm? Nimm z.B. name. Wäre es da besser street_name als Name für Straßen zu verwenden und station_name für Bahnhofsnamen? Solange es um eine allgemeine (assimilabile) Eigenschaft geht, sind universell verwendbare Keys m.E. durchaus sinnvoll. Schwierig wird es bei solchen Sachen wie width. Da ist dann teilweise schon unklar, ob es um die Durchgangsbreite oder die Breite des Objekts geht. ich würde das gerne noch weiter ausführen: m.E. sollten die Tags so spezifisch wie nötig aber so generisch wie möglich sein. Das ermöglicht die Verwendung derselben Tags in unterschiedlichem Kontext. Dabei muss natürlich die Eindeutigkeit sichergestellt sein. Gruß Martin PS: Entschuldigung für das assimilabile, gemeint war übertragbar, assimilierbar, so langsam scheint sich der Auslandsaufenthalt bemerkbar zu machen ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 16:48:04 schrieb M∡rtin Koppenhoefer: Das ermöglicht die Verwendung derselben Tags in unterschiedlichem Kontext. Ist das erstrebenswert? Also klar, ein paar Ausnahmen gibt es: name, comment, solche Dinge, die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. Aber bei Tags die Eigenschaften eines Objekts beschreiben ist es doch recht entscheidend, dass der Auswerter den Kontext kennt. Ein Tag das gleich aussieht, in einem anderen Kontext aber eine völlig andere Bedeutung hat, ist nicht unbedingt ein Vorteil. Gruß, Bernd -- Beeth Girls are like internet domain names, the ones I like are already taken. honx well, you can stil get one from a strange country :-P signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 17:53 schrieb Bernd Wurst be...@bwurst.org: Am Sonntag 31 Oktober 2010, 16:48:04 schrieb M∡rtin Koppenhoefer: Das ermöglicht die Verwendung derselben Tags in unterschiedlichem Kontext. Ist das erstrebenswert? Also klar, ein paar Ausnahmen gibt es: name, comment, solche Dinge, die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. Aber bei Tags die Eigenschaften eines Objekts beschreiben ist es doch recht entscheidend, dass der Auswerter den Kontext kennt. Ein Tag das gleich aussieht, in einem anderen Kontext aber eine völlig andere Bedeutung hat, ist nicht unbedingt ein Vorteil. Das stimmt, aber wie ist die genaue Liste: wo macht es Sinn, und wo nicht. Eigenschaften reicht als Kriterium nicht aus m.E. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 17:59:55 schrieb M∡rtin Koppenhoefer: Das stimmt, aber wie ist die genaue Liste: wo macht es Sinn, und wo nicht. Eigenschaften reicht als Kriterium nicht aus m.E. Du hast ein sehr gutes Beispiel schon genannt: width. Ist es aus Sicht des Nutzers (Durchgangsbreite) oder aus Sicht des Karten- Malers (Gesamtbreite/Aussenmaße)? Da gibt es (ziemlich sicher) noch weitere Tags, die dem Tag-Erfinder vielleicht in dem Moment eindeutig oder gar universell einsetzbar erscheinen mögen, es aber im Nachhinein gar nicht sind. Setzt man den Namen des Tags also möglichst spezifisch, werden spätere Unschärfen in der Interpretation gleich vermieden. Im schlimmsten Fall muss ein Daten-Verwerter nachher halt mehrere Tags wieder als Synonym behandeln, wenn er dann doch vergleichbare Werte von verschiedenen Objekten auswerten möchte. Solch eine Vorverarbeitung ist trivial. Gruß, Bernd -- Fettflecke werden wie neu, wenn man sie regelmäßig mit Butter einreibt. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 18:16 schrieb Bernd Wurst be...@bwurst.org: Am Sonntag 31 Oktober 2010, 17:59:55 schrieb M∡rtin Koppenhoefer: Das stimmt, aber wie ist die genaue Liste: wo macht es Sinn, und wo nicht. Eigenschaften reicht als Kriterium nicht aus m.E. Du hast ein sehr gutes Beispiel schon genannt: width. Ist es aus Sicht des Nutzers (Durchgangsbreite) oder aus Sicht des Karten- Malers (Gesamtbreite/Aussenmaße)? m.E. ist width für die Straßenbreite etabliert, d.h. bei linearen Features kann man es m.E. universell für die Breite verwenden. Auch ein Node mit barrier=gate ist eigentlich klar. Einer mit barrier=bollard oder block allerdings nicht ;-). Man könnte das aber so definieren, dass width immer die Durchgangsbreite ist --- sinnvoll wäre es IMHO. Unklar ist dabei natürlich trotzdem noch, bis zu welcher Höhe es gilt (Lichtraum), vor allem, wenn der Querschnitt nicht rechtwinklig ist, reichen Höhe und Breite zur Definition ja sowieso nicht aus. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31.10.2010 11:04, schrieb Jochen Topf: Die Diskussion hier hat mich dazu angeregt, mal aufzuschreiben, was ich beim Erfinden von Tags für wichtig halte. Ich hab das mal hier aufgeschrieben: http://wiki.openstreetmap.org/wiki/User:Joto/How_to_invent_tags Das ist meine persönliche Liste, die sich sicher ändern wird. Ich hab auch einfach mal nur runtergeschrieben, was mir im Moment so einfällt, da gibts sicher noch mehr. Es soll natürlich keine Vorschrift sein. Aber vielleicht ist es ein kleiner Baustein für eine Best Practice, die wir gemeinsam als Community mittelfristig erarbeiten. Ich freue mich über Rückmeldungen hier oder im Wiki und würde mich auch freuen, wenn andere ihre persönliche Liste aufstellen. Das sind dann alles Schritte zu einem Konsens. Jochen hi ! bei einem solch wichtigen thema - is it possible to make a german side ?? gruß jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
On Sun, Oct 31, 2010 at 05:59:55PM +0100, M∡rtin Koppenhoefer wrote: Am 31. Oktober 2010 17:53 schrieb Bernd Wurst be...@bwurst.org: Am Sonntag 31 Oktober 2010, 16:48:04 schrieb M∡rtin Koppenhoefer: Das ermöglicht die Verwendung derselben Tags in unterschiedlichem Kontext. Ist das erstrebenswert? Also klar, ein paar Ausnahmen gibt es: name, comment, solche Dinge, die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. Aber bei Tags die Eigenschaften eines Objekts beschreiben ist es doch recht entscheidend, dass der Auswerter den Kontext kennt. Ein Tag das gleich aussieht, in einem anderen Kontext aber eine völlig andere Bedeutung hat, ist nicht unbedingt ein Vorteil. Das stimmt, aber wie ist die genaue Liste: wo macht es Sinn, und wo nicht. Eigenschaften reicht als Kriterium nicht aus m.E. Die Frage ist mal wieder, was man mit diesen Tags machen will. Beim Namen macht es Sinn einen Tag zu haben, weil der Name eines Objektes letzlich nichts anderes ist als der Name eines anderen Objektes. Beides sind willkürliche Bezeichner, die uns Menschen helfen, auf das Ding zu verweisen. Bei der Eingabe habe ich einfach ein Eingabefeld. Beim Erstellen einer Karte, kann ich den Namen einfach mal so dazuschreiben, egal, was das Objekt genau ist. Bei einem ref sehe ich das schon anders. Für Straßen gibt es bestimmte offizielle Bezeichnungen, die wir im ref speichern. Die haben eine spezifische Struktur und Bedeutung. Wenn ich jetzt für, sagen wir, Bushaltestellen, auch einen ref-Tag nehme, weil das ja auch irgendwie eine Nummer ist, dann bringe ich zwei Sachen durcheinander. Die Bezeichnung der Bushaltestelle hat eine andere Struktur, wird von jemand anderem vergeben und auf einer Karte anders dargestellt. 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. 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. 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. 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. 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. 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. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
On Sun, Oct 31, 2010 at 07:11:58PM +0100, Jan Tappenbeck wrote: Am 31.10.2010 11:04, schrieb Jochen Topf: Die Diskussion hier hat mich dazu angeregt, mal aufzuschreiben, was ich beim Erfinden von Tags für wichtig halte. Ich hab das mal hier aufgeschrieben: http://wiki.openstreetmap.org/wiki/User:Joto/How_to_invent_tags Das ist meine persönliche Liste, die sich sicher ändern wird. Ich hab auch einfach mal nur runtergeschrieben, was mir im Moment so einfällt, da gibts sicher noch mehr. Es soll natürlich keine Vorschrift sein. Aber vielleicht ist es ein kleiner Baustein für eine Best Practice, die wir gemeinsam als Community mittelfristig erarbeiten. Ich freue mich über Rückmeldungen hier oder im Wiki und würde mich auch freuen, wenn andere ihre persönliche Liste aufstellen. Das sind dann alles Schritte zu einem Konsens. Jochen hi ! bei einem solch wichtigen thema - is it possible to make a german side ?? Also ich werds nicht machen, weil ich keine Lust habe zwei Versionen meiner persönlichen Seite zu pflegen. Wenn jemand das für ein wichtiges Thema hält, dann kann er ja... :-) Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Bernd Wurst be...@bwurst.org writes: Also klar, ein paar Ausnahmen gibt es: name, comment, solche Dinge, die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. Manche dinge haben allerdings zwei doer mehr namen; standardbeispiel: straße auf einer brücke. Das können wir so ohne weiteres nicht abbilden. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 19:47 schrieb Jochen Topf joc...@remote.org: Die Frage ist mal wieder, was man mit diesen Tags machen will. Beim Namen macht es Sinn einen Tag zu haben, weil der Name eines Objektes letzlich nichts anderes ist als der Name eines anderen Objektes. Beides sind willkürliche Bezeichner, die uns Menschen helfen, auf das Ding zu verweisen. Bei der Eingabe habe ich einfach ein Eingabefeld. Beim Erstellen einer Karte, kann ich den Namen einfach mal so dazuschreiben, egal, was das Objekt genau ist. Bei einem ref sehe ich das schon anders. Für Straßen gibt es bestimmte offizielle Bezeichnungen, die wir im ref speichern. Die haben eine spezifische Struktur und Bedeutung. Wenn ich jetzt für, sagen wir, Bushaltestellen, auch einen ref-Tag nehme, weil das ja auch irgendwie eine Nummer ist, dann bringe ich zwei Sachen durcheinander. Die Bezeichnung der Bushaltestelle hat eine andere Struktur, wird von jemand anderem vergeben und auf einer Karte anders dargestellt. das ist doch aber nicht entscheidend, ob der Bezeichner von einer anderen Stelle vergeben wird oder in einem anderen Format ist. Auch international ist das ja der Fall bei highways. Wenn ich einen Tag habe, werde ich den m.E. immer öfter im Kontext interpretieren müssen, bzw. wird immer klarer, dass das auch jetzt schon so ist. 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. 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. naja, wie man will. vermischt ist da eigentlich nichts. Dein Programm zur Auswertung muss nur schlau genug sein, die Informationen richtig zu interpretieren. 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, stimmt. Schau ich eine Statistik der Werte an, finde ich alle möglichen wild durcheinander. je nachdem, wie die Statistik aufgebaut ist. Das Wort speciality ist zu generisch, es sagt eigentlich nichts aus, außer dass hier eine hierarchische Unterordnung stattfinden will. 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. das stimmt zwar, Vorteil ist aber, dass man mit einem geringen Vokabular (geringer Einstiegshürde) viele und mächtige Taggingmöglichkeiten hat. Man könnte das allerdings auch erreichen, indem man die Tags logisch aufbaut, also z.B: healthcare:specialty (oder anders rum), restaurant:specialty, ... 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. in der Tat, oder name:bridge oder sowas. Macht da auch Sinn, weil es ja durchaus beides geben kann (dass es derzeit Sinn machen würde ist aber vielleicht auch nur eine Folge aus den unterentwickelten Brücken). Hier hilft es auch, sich zu überlegen, was denn der typische, häufige Fall ist und was eher ein Spezialfall. Ja, das ist sehr wichtig, aber teilweise auch schwierig zu beantworten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 20:11 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 31. Oktober 2010 19:47 schrieb Jochen Topf joc...@remote.org: Taggingmöglichkeiten hat. Man könnte das allerdings auch erreichen, indem man die Tags logisch aufbaut, also z.B: healthcare:specialty (oder anders rum), restaurant:specialty, ... die Frage ist bei einer Systematik zur Bildung individueller Keys dann allerdings, wie man die aufbaut. Am obigen Beispiel sieht man ja schon, dass einerseits (healthcare) ein Key genommen wurde, auf der anderen Seite ein Value (restaurant), weil amenity:specialty eben nicht (viel) weitergeholfen hätte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Im Moment hat die Seite noch wenige Querverweise. Sie sollte aber gut eingebunden sein. Ein Querverweis wäre zum Beispiel möglich zu http://wiki.openstreetmap.org/wiki/Just_Map, wo ähnliche Gedanken (nicht so ausführlich) geäußert werden. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
On Sun, Oct 31, 2010 at 08:18:06PM +0100, Johannes Huesing wrote: Im Moment hat die Seite noch wenige Querverweise. Sie sollte aber gut eingebunden sein. Ein Querverweis wäre zum Beispiel möglich zu http://wiki.openstreetmap.org/wiki/Just_Map, wo ähnliche Gedanken (nicht so ausführlich) geäußert werden. Danke für den Hinweis. Ich hab einen Verweis auf diese Seite eingebaut. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
