[Talk-de] amenity und Untergruppen (was: Re: tag: Sonennstudio)
Bernd Wurst schrieb: Wo immer es sinnvoll möglich ist, eine Untergruppe zu spezifizieren sollte man diese nutzen. Amenity ist IMHO wesentlich überstrapaziert und mittlerweile sehr matschig in der Bedeutung. Wodurch genau entsteht ein Nachteil, wenn amenity zahlreiche mögliche Werte ohne weitere Kategorisierung hat? Wir hatten ja kürzlich z.B. den Vorschlag, alle amenity=hospital auf healthcare=hospital umzustellen. Nur: Was bringt das? Der Schlüssel, sei es amenity oder healthcare, hat doch ohnehin keine zusätzliche Information -- was ich mit diesem Tag sagen will (dies ist ein Krankenhaus) steckt komplett im Wert hospital. Oder gibt es auch Krankenhäuser, die nicht in healthcare einsortiert würden? Für solche Dinge, bei denen der Key keinerlei Information trägt, halte ich es eigentlich für die beste Lösung, einen Sammelkey zu verwenden, und das ist aus historischen Gründen eben amenity, ob der Name nun passt oder nicht. Hier eine Unterteilung einzuführen, erhöht nicht die Ausdruckskraft des Tags, sondern zwingt einen nur, sich neben dem Wert-Namen auch noch den Schlüssel zu merken. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity und Untergruppen (was: Re: tag: Sonennstudio)
Hallo. Am Sonntag 31 Mai 2009 12:36:11 schrieb Tobias Knerr: Wodurch genau entsteht ein Nachteil, wenn amenity zahlreiche mögliche Werte ohne weitere Kategorisierung hat? Nun, weil ein Interpreter einfach alle Werte kennen muss um selbst eine Kategoriesierung durchzuführen. Beispiel shop. Ein Navi kann jetzt eine POI-Liste machen, und sämtliche Einkaufsmöglichkeiten ohne genaue Kenntnis des Tags gruppieren. Leider wurden in jüngerer Zeit wohl einige Diensleister und nur begrenzt als Einkaufsmöglichkeit taugliche POIs unter shop einsortiert. Würde man aber z.B. anstelle von amenity=restaurant oder amenity=pub oder amenity=fast_food (wir wissen alle: die Übergänge sind fließend) das zusammenfassen unter restaurant=* oder etwas ähnlichem, dann könnte ein Navi ohne genaue Kenntnis von vielen Unter-Typen schonmal eine Liste aller Gastwirtschaften erstellen. wer es genauer weiß, kann dann noch nach weiteren Kriterien unterteilen, aber man muss ja nicht. Wenn man alles unter einem nichtssagenden Sammelkey hat, werden unbekannte POI-Typen grundsätzlich ignoriert, das macht die Hemmschwelle größer, neue Tags zu benutzen. Gruß, Bernd -- Anonyme Poster kann man nach Belieben beleidigen, man beleidigt ja niemand konkretes. - Sven Paulus, de.admin.net-abuse.news, 31.8.1999 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] amenity und Untergruppen
Bernd Wurst wrote: Würde man aber z.B. anstelle von amenity=restaurant oder amenity=pub oder amenity=fast_food (wir wissen alle: die Übergänge sind fließend) das zusammenfassen unter restaurant=* oder etwas ähnlichem, dann könnte ein Navi ohne genaue Kenntnis von vielen Unter-Typen schonmal eine Liste aller Gastwirtschaften erstellen. wer es genauer weiß, kann dann noch nach weiteren Kriterien unterteilen, aber man muss ja nicht. Ich denke auch, diese Methode ist zukunftsweisend. Ich finde hier jedoch die hierarchische Variante eine deutlich flexiblere Ergänzung. Hier also z.B. amenity=restaurant:fast_food:chinese (ob das jetzt amenity oder genauer restaurant oder allgemeiner locality/place sein sollte, steht auf einem anderen Blatt) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity und Untergruppen
Bernd Wurst schrieb: Wodurch genau entsteht ein Nachteil, wenn amenity zahlreiche mögliche Werte ohne weitere Kategorisierung hat? Nun, weil ein Interpreter einfach alle Werte kennen muss um selbst eine Kategoriesierung durchzuführen. Der Interpreter muss eigentlich ohnehin alle Werte kennen, die er in POI-Listen oder so anzeigen will. Wie soll er sie sonst in die Sprache des Nutzers übersetzen, mit Icons versehen oder sonst wie in nutzerfreundlicher Weise (nicht als rohen OSM-Key) darstellen? Beispiel shop. Ein Navi kann jetzt eine POI-Liste machen, und sämtliche Einkaufsmöglichkeiten ohne genaue Kenntnis des Tags gruppieren. Und er kann es nur auf genau eine Art gruppieren. Dir sagen, was es dort zu kaufen gibt, kann er ohne Kenntnis der Tags auch nicht. Wenn man alles unter einem nichtssagenden Sammelkey hat, werden unbekannte POI-Typen grundsätzlich ignoriert, das macht die Hemmschwelle größer, neue Tags zu benutzen. Sobald dir nur eine Kategorisierung nicht passt (Dienstleister in shop, z.B.), was bei freier Tag-Erfindung unvermeidlich sein dürfte, brauchst du in der Anwendung sowieso zumindest eine Kategorienliste. In eine solche was neues einzutragen ist bei entsprechendem Willen kein Aufwand. Wenn neue Tags nicht berücksichtigt werden, liegt das entweder daran, dass der Entwickler höhere Anforderungen hat, die noch nicht erfüllt sind (Icon vorhanden o.ä.), oder daran, dass er es schlicht nicht berücksichtigen will. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity und Untergruppen
Am Sunday 31 May 2009 schrieb Tobias Knerr: Bernd Wurst schrieb: Wodurch genau entsteht ein Nachteil, wenn amenity zahlreiche mögliche Werte ohne weitere Kategorisierung hat? Nun, weil ein Interpreter einfach alle Werte kennen muss um selbst eine Kategoriesierung durchzuführen. Der Interpreter muss eigentlich ohnehin alle Werte kennen, die er in POI-Listen oder so anzeigen will. Wie soll er sie sonst in die Sprache des Nutzers übersetzen, mit Icons versehen oder sonst wie in nutzerfreundlicher Weise (nicht als rohen OSM-Key) darstellen? Beispiel shop. Ein Navi kann jetzt eine POI-Liste machen, und sämtliche Einkaufsmöglichkeiten ohne genaue Kenntnis des Tags gruppieren. Und er kann es nur auf genau eine Art gruppieren. Dir sagen, was es dort zu kaufen gibt, kann er ohne Kenntnis der Tags auch nicht. Wenn man alles unter einem nichtssagenden Sammelkey hat, werden unbekannte POI-Typen grundsätzlich ignoriert, das macht die Hemmschwelle größer, neue Tags zu benutzen. das kann aber auch genau andersrum sein... kategorien haben viele vorteile: - man kann beim zeichnen der POI besser filtern, bzw. vorsortieren: z.B. alle einkaufsmoeglichkeiten oder alle orte anzeigen, wo's was zu gibt. - man kann wesentlich uebersichtlichere menues generieren: es gibt mehrere 100 verschiedene arten von POI. die fuer ein menue in einer baumstruktur abzubilden, ist wesentlich uebersichtlicher, als eine lange liste zu haben. - man kann ganz leicht neue tags in einer kategorie hinzufuegen: selbst wenn bestimmte anwendungen noch nichts von dem neuen POI-typ wissen, gibt es durch die uebergeordnete kategorie schon mal eine einordnung und ein icon, mit dem man sortieren und rendern kann. genau deshalb hatte ich mal fuer gpsdrive ein kategorienbasiertes POI-schema inklusive zugehoerigen tags im osm-stil entwickelt. wen's interessiert, eine grobe uebersicht gibt's in den index*.htm-dateien unter http://svn.openstreetmap.org/applications/share/map-icons/ oder natuerlich in gpsdrive... 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] amenity und Untergruppen
Am 31. Mai 2009 15:41 schrieb Guenther Meyer d@sordidmusic.com: Am Sunday 31 May 2009 schrieb Tobias Knerr: Bernd Wurst schrieb: Wodurch genau entsteht ein Nachteil, wenn amenity zahlreiche mögliche Werte ohne weitere Kategorisierung hat? Nun, weil ein Interpreter einfach alle Werte kennen muss um selbst eine Kategoriesierung durchzuführen. Der Interpreter muss eigentlich ohnehin alle Werte kennen, die er in POI-Listen oder so anzeigen will. Wie soll er sie sonst in die Sprache des Nutzers übersetzen, mit Icons versehen oder sonst wie in nutzerfreundlicher Weise (nicht als rohen OSM-Key) darstellen? Beispiel shop. Ein Navi kann jetzt eine POI-Liste machen, und sämtliche Einkaufsmöglichkeiten ohne genaue Kenntnis des Tags gruppieren. +1 das ist genau der Grund, warum ich auch eine Systematik bevorzugen würde. Man könnte, auch ohne dass man weiss, was genau der Wert bedeutet, ihn entsprechend anzeigen. Und er kann es nur auf genau eine Art gruppieren. Dir sagen, was es dort zu kaufen gibt, kann er ohne Kenntnis der Tags auch nicht. doch, kann er. Er sagt Dir, es ist ein shop, und der hat den Wert xy. Wenn Du xy kennst, kannst Du damit was anfangen, auch wenn das Programm den Wert nicht kennt. Ähnlich könnte man auch Gastronomie (Restaurant, Fast-Food, Bar, Café, Kneipe, Pub), Kulturbauten (Museen, Art_centres), Elektrizität (Kraftwerke, Windmühlen, Umspannwerke, Stromleitungen), öffentliche Verwaltung und Behörden, Gesundheitswesen (Krankenhäuser, Apotheken), Kommunikationseinrichtungen, Bildungseinrichtungen (Schule, Uni, FH), etc. etc. klassifizieren. Bei highway und railway machen wir es ja auch so. Alles nur Beispiele, die sich sicher weiter differenzieren lassen. kategorien haben viele vorteile: - man kann beim zeichnen der POI besser filtern, bzw. vorsortieren: z.B. alle einkaufsmoeglichkeiten oder alle orte anzeigen, wo's was zu gibt. - man kann wesentlich uebersichtlichere menues generieren: +1 es gibt mehrere 100 verschiedene arten von POI. die fuer ein menue in einer baumstruktur abzubilden, ist wesentlich uebersichtlicher, als eine lange liste zu haben. +1 - man kann ganz leicht neue tags in einer kategorie hinzufuegen: selbst wenn bestimmte anwendungen noch nichts von dem neuen POI-typ wissen, gibt es durch die uebergeordnete kategorie schon mal eine einordnung und ein icon, mit dem man sortieren und rendern kann. und vor allem auch die Details (tags) in elektronischen Karten anzeigen, so dass ein Mensch damit was anfangen kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity und Untergruppen
Hallo. Am Sonntag 31 Mai 2009 14:43:11 schrieb Tobias Knerr: Der Interpreter muss eigentlich ohnehin alle Werte kennen, die er in POI-Listen oder so anzeigen will. Wie soll er sie sonst in die Sprache des Nutzers übersetzen, mit Icons versehen oder sonst wie in nutzerfreundlicher Weise (nicht als rohen OSM-Key) darstellen? Mein Garmin hat hier in der Kategorie Einkaufen z.B. einen Eintrag Stoff-Truhe. Ausgewertet wird dabei shop=* = Einkaufen und der name-Tag zur Anzeige. Eine genauere Kategorisierung ist in diesem Fall zwar denkbar, aber nicht nötig. Welche Art Laden das ist, erkennt man in den meisten Fällen auch schon am Namen. Und die genauere, maschinenlesbare Klassifizierung steckt ja zudem in den Daten, obwohl das Navi in diesem Fall die gar nicht anschaut. Gruß, Bernd -- Faulheit ist die Mutter aller Erfindungen. 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
