On 15.01.2015 23:10, Tobias Knerr wrote: > I feel this is far too generic. Imagine a renderer which wants to show > names of lakes at zoom 12, cliff formations at zoom 14, and cave systems > at zoom 16. If all these are simply a type=cluster + name=*, then that > becomes difficult. There needs to be a clear indication of what type of > feature we are dealing with, not just a name.
In order to display a name, the renderer needs to know a position. In order to calculate a position, it needs to iterate through the relation members. While iterating, it can sum up their types and counts. Say, if two mampers are lakes, five are natural=cliff, and one is a cave, the natural=cliff members make up the majority, and the cluster can be handled as a cluster of cliffs, thus rendered at zoom level 14 and higher. Another idea is to propagate the name to the members and then treat each member individually. Of course any ot these algorithms only works when it is implemented, but this not too difficult. If the algorithm is not implemented, nothing evil happens. The name is just invisible, as is already right now without the relation. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
