yohanboniface
commented
11 years ago For the record, the answer I sent you on the mailling list:
I understand your point. The HDM rendering is work in progress, so certainly the road rendering point have to be refined, but let me argue a little bit on the current choices.
- first point, which is for me an important point: in my understanding of the project, the HDM rendering targets users more than OSM editors; what this means is that we should render the OSM infos, but not necessarily the OSM data scheme for itself; this is a main principle I'm working with in mind. So for example in the road case, what in my opinion is important to render is a clear hierarchy of the roads, something like: this one sounds like a big, well maintained road, where this one is clearly small and in bad conditions. But the fact that it's tagged as a primary road in itself is a OSM editor private information.
- Road rendering is not just color. It's: color + border color, width, border width, fill pattern, border pattern, name, optional shield. The smoothness only alters the fill pattern, and so the color is unchanged. Other example: the "narrow" tag only alter the width. On the other hand, the surface, as you've seen, alters the color, but only the color: all the other elements are kept as is. So in my opinion, but I may be wrong, the level of the road in the hierarchy is still clear, while it is also clear that this piece of road is not good.
- OSM has billions of informations. Creating a rendering means making choices. Making choices in what to display or not, of course. But mostly making choices in the hierarchy of the infos we want to display. And the hard thing here is that the more one specific info is visible, the more noise it creates for the other infos around. Believe me, it's hard to find the limit between the info and the noise ;) Thus, it's also important, in my point of view, to keep the color spectrum as simple as possible. To be clear it's not possible to keep it simple, but we should try hard. For this reason, in my opinion, it would be a bad idea to try to create an "unpaved" new range of colors, like for example: black red for normal primary road, and light red for unpaved primary road. And so this is why I've chosen to use just one color for unpaved road, keeping, as said before, all the other rendering elements as is.
Anyway, I've heard and understood your concerns. I believe in my current choices, as exposed here, but I will run a neurone in background task to see what I can do better in surface road rendering :)
Example http://umap.fluv.io/en/map/hdm-first-draft_728#15/18.6665/-72.3048 where a piece of the primary road is unpaved)
In this example of rendering for road surface and smoothness, we see how a section of a primary road that is unpaved is rendered. For this section, the color for the primary road is grayed. This means that the surface and smoothness color scheme have preseance over the road classification.
Would it be possible to render differently, without modification of the color representing the road classification? This way, we would not loose information about the road classification.