W dniu 09.07.2014 14:19, Matthijs Melissen napisał(a):
Two reasons. First, we are trying to clean up current problems with the style sheet first, rather than adding new features. Also, development of the stylesheet has been put on hold for like four
Ok, I get it. =} It explains a lot, thanks!
years, so there is still quite a large backlog. Second, sometimes things seem easy, while they are not. In the case of fountains, do we really want an icon for every fountain? What about a tiny fountain in someones garden? A small ventilation fountain in a pond? Even for slightly larger public fountains, an icon might attract more attention than it deserved.
Now, that's a big favor for the vision that there should be better communication between tagging and rendering depts!
Look: there are some people crafting tags. They think about a big picture - what is the right mental model for categorizing reality. Than they put that model in the tags and give to the community. Than the rendering team looks at the output and thinks: "well, it's nice and shiny, but that doesn't work on the map!" - so they just don't do anything, because the tags definitions are The Law you can't discuss with, you just need to obey it or silently avoid it...
But what if the rendering team could "phone" to the tag making dept and say: "oh, we have some questions regarding visualization - in the current scheme we can't do this and that, could you fix it somehow?". Than the tagging community could say: "well, let's look at our nice mental model and let's think how can we tag it better". See? The work is still generally separated between the depts, but is not completely isolated.
BTW: what the tagging dept could do about those messy fountains? It could add subtag "public=yes/no" to make it possible to render public fountains on bigger scale than private ones. It can add add subtag "decorative=yes/no" to sort the park attraction from the purely technical (ventilation) fountains. It can even make totally different tag - like "amenity=drinking_water" if it makes sense. But now it can't do anything, since there is no sign there are any more problems with rendering/mental model than pure tagging discussion suggests!
First of all, we are past the state where every tag can be rendered. For example, I believe that fire hydrants are an officially accepted tag. That doesn't mean that we should render them on openstreetmap-carto. Same thing for underground cables, etc.
I guess it's not a coincidence that my problem started with micromapping. I thought micromapping (as well as 3D and indoor) is a natural extension of a global map. But it is not. It deserves to always look at the scale and redefine some things that does not scale today.
Sometimes it's easy - the street lamp is something different than a lighthouse, no need for redefinition. But what if we have a "peak" and you see it by default as "(the mountain) peak"? With such a model in mind you are not ready to notice that in small scale it can have also different meanings, because you still think big - after all it's still a world map, doesn't it?
You said the fire hydrants should not be visible at any zoom level. But wait - you can already have as many bollards on the main map as you wish, the same for the trees, no matter how small. What would be bad in adding some (say) red dots to the black and green ones? I can see them from at least z=16 and they was not removed from default map up to this moment. And the fire hydrants are not such a common thing as the bollards and the trees.
Underground cables - that is something that makes me think that may be an exception. But how do we know if can't see the mess it causes (or not)? That makes me even more sure we need a "testing" map with everything but a kitchen sink.
However, if you could create a table on the wiki that links accepted features to their Github id (if existing), that would be helpful, I think. But as I said, the focus at the moment is not on adding
OK, when the dust after discussion and voting will settle, I can happily do that. I don't think just linking to carto issues is enough, but that's a good beginning.
features - but that might change in a couple of months. By the way, the number of features officially accepted is surprisingly small. For example, there are only about 5 officially accepted shop types (but much more implicitly accepted ones, of course).
I think "shop=*" key should be always rendered - HOT has nice basket icon for that. What makes some types of shops better than the others?
But if you are right, that official accepted tags are minority, I don't consider adding them all too risky. Of course, still I would prefer the testing map, where we can really see it instead of just guessing.
than two years ago), it's better to fix these first before adding new stuff to the mess.
I understand that. I feel sorry it took so long to do all the groundworks, but I'm happy they are more or less laid, at last. But if I understand Andy's talk good, he wants to have more people contributing to the carto subproject, and the best way I know to get into something big and scary is to make something clear, small and useful for the start. The POIs are such a thing. Even the OSM programming has 10 clearly identified tasks you can start with.
So - what about making the testing map and adding there all the already documented features for the start? Maybe we should discuss it elsewhere, because we're far from the tagging: what is a better place - talk list or maybe carto issue tracker?
-- Mambałaga _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
