> Thanks for getting this discussion started. I agree, thank you Colin Colin, Matthijs, good luck on this one, I hope something will come out positively.
> One thing to take into account in this discussion is that multi-valued > keys often move the problem to the data consumer. For that reason I'd > recommend to avoid them in many cases. Well in some cases they ought to be useful so let us find a way to reduce fragmentation. > Take for example your example shop=supermarket, shop=bakery. > Independent of the exact way of tagging, using a multivalued tagging > scheme forces the renderer to make a decision between a supermarket > and a bakery icon. So be it. Any data consumer can choose, what is wrong with that? (May I remind you some data consumer are not rendering data?) If you want a map/app/analysis/search/navigation on supermarkets, you have it. If you want a map/app/analysis/search/navigation on bakeries, you have it too. If you want a generic map/app/analysis/search, you can keep both. Display 2 results, count 2 instances, render 2 icons. > Basically, there is no possible way for the > renderer to support a multi-valued key here! It is more difficult, I would agree, but "no possible way" looks like an overstatement. Really. > The renderer might have a > rule that considers supermarkers always more important than bakeries, > or vice versa. But I think it's much more useful if the mapper decides > what's the main function, supermarket or bakery, rather than forcing > the renderer to make a choice. If possible, the mapper should choose the main function, or make 2 nodes, or whatever. And now, let us discuss what if not. I think it would be nice if the renderer was not forcing the mapper to make a choice when there is none. _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
