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
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.
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
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
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
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
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
7 matches
Mail list logo
