Hallo, Am Montag 11 Oktober 2010 10:59:30 schrieb M∡rtin Koppenhoefer: > Am 11. Oktober 2010 08:59 schrieb Wolfgang <wolfg...@ivkasogis.de>: > > Wir taggen weder für Renderer, noch für Router, noch für sonstige > > Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da > > ist. Ein Tag kann halt mehrere Werte haben. > > das kann er eben nicht so einfach, daher gibt's ja die Probleme. > > > Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als > > diese "yes"-Krankheiten, die Tag und Value im einem auszudrücken > > versuchen. cafe=yes > > restaurant=yes > > cusine_greek=yes > > cuisine:italian=yes > > (schauder) > > warum schauderts Dich da? Das ist besser auszuwerten und wird daher in > der Regel dargestellt. Was Du dagegen forderst vernichtet im Prinzip > die Daten auf der Auswertungsseite.
Du übersiehst, dass der Programmierer hier ein im Grunde größeres Problem hat. Die Eigenschaften sind nach wie vor mehrfach vorhanden. An dieser grauenvollen Wirklichkeit führt auch dieses Schema nicht vorbei. Aber die Auswertung muss erkennen, dass cuisine_greek und italian sich auf die gleiche Eigenschaftsgruppe beziehen. Zusätzlich zum Vorhandensein der Mehrfacheigenschaft muss diese Mehrfacheigenschaft erkannt werden, sonst malt der Renderer das eine Icon über das andere. Oder er nimmt immer das zuerst gefundene. Damit wären wir auch nicht weiter. Eine Software, die ein Icon für eine relativ häufige Kombi wie diese hier darstellen könnte, hätte einen erheblichen Mehraufwand, weil sie die Kombi erst suchen müsste. Aber die Eigenschaftenliste wird in jedem Editor länger und auch hier muss die humane Schnittstelle die Mehrfacheigenschaft erst mühsam erkennen, während das Semikolon diese brutal vor das entsetzte Auge zerrt. Man muss sich immer überlegen, dass es sich letztlich um ein grundsätzliches Problem handelt. Wenn nur ein yes-Tag dabei ist, fällt das Problem nicht auf. Wenn aber alles so getaggt würde, weil es scheinbar einfacher ist, würde die Übersicht schnell sparsamer werden: automatic_entrance_door=yes bar=yes blinking_leuchtreklame=no cafe=yes cuisine_greek=yes cuisine_italian=yes decoration_greek=yes decoration_italian=yes english_money_accepted=no english_spoken=yes euro_accepted=yes fish_dishes=yes german_spoken=yes good_speed_of_service=yes greek_music_sound=yes greek_spoken=yes high_qality_of_food=no interior_color_read=yes italian_music_sound=yes italian_spoken=yes japanese_spoken=no kitchen_visible=yes kitchen_visible_by_window=yes leuchtreklame=yes leuchtreklame_color_blue=yes leuchtreklame_color_red=yes maestro_card_accepted=yes master_card_accepted=yes music_box=yes music_box_accepts_credit_cards=no music_box_accepts_coins=yes number_of_seats=100 oven_in_guest_room=no outside_color_blue=yes pizza_oven=yes prices_high=yes restaurant=yes tables=25 traveller_cheques_accepted=yes visa_card_accepted=yes weelchair_geeignet=yes Da habe ich natürlich maßlos übertrieben. Aber ein Problem zeigt sich immer am Extremfall, und so eine Liste möchte ich weder im josm noch im merkaartor editieren müssen. Mehrfacheigenschaften sind trotzdem drin. Wenn man das Schema noch etwas ausbaut, kann das yes/no weggelassen werden, und wir sind beim valuelosen tagging. > > Früher konnte man ja mehrmals denselben Key auf demselben Objekt > verwenden (zumindest erlaubten Editoren und DB das), was war da genau > der Grund, dass man es abgeschafft hat? (Sorry für die Frage, bin > weder Mathematiker noch Informatiker wie man sicher leicht erkennen > kann). > Da würde ich auf die DB-Struktur zu dem Zeitpunkt tippen. Ist aber nur Spekulation. Gruß, Wolfgang _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
