Talk:Tagging for the renderer
Actually, when people say "Don't tag for the renderer", what they usually mean is "What you do is wrong and what I do is right, and your arguments are not important". I wish this rule would just be removed. In my opinion, one should tag for the renderer. Rendering is not the only application of OSM, it is still an important one, and to not take that into account (as this rule seems to suggest) is just silly. The better rule would be: Don't tag for a specific renderer, but by all means possible tag for renderability. - Andre Engels 01:34, 1 February 2010 (UTC)
- It has been addressed several times especially on the mailing lists, that such use (plain "you do it wrong and I do it right") of the phrase is in error (well, they could be effectively right, but it's at best only a consequence of the real meaning of the phrase). As is written on page, if there are several alternative, correctly descriptive ways to tag the objects, then users should by all means use the tags that get the feature rendered, but they shouldn't use tags that describe something else. It might require a bit extra effort for the first users, if they want their new feature rendered on the main layers, in that they possibly need to file a ticket in Trac, but that step serves to remove duplicate ways to tag the same thing. When users want to (correctly) "tag for the renderer", they (hopefully) in fact want to "use tag combinations for which developers can write simple rendering rules, given currently available software". Alv 08:11, 1 February 2010 (UTC)
- Indeed, that's what they do, and that's when they get told that they shouldn't tag for the renderer. The rule may be good, the phrase is totally wrong, and misused 90% of the time it is used. - Andre Engels 13:51, 26 July 2010 (UTC)
Could we add instructions for what to do instead if a particular rendering bothers you but you still want to tag it correctly? Then it's not just "don't!".
I often wish I knew what to do that might actually be effective. A recent example for me is tagging landuse=port. This is approved on the wiki but does not render in Mapnik. It's obviously correct, but I realised how much better my port looked in Mapnik by keeping it landuse=industrial and reverted my change.
- add a feature request to Mapnik on github or wherever the code is canonically maintained?
- email the Mapnik mailing list?
[OK, I see on the OSM Mapnik wiki page that they suggest and link to adding an issue on Github. If someone can confirm how effective this really is, I'll add it in to this page.]
I seem to remember reading or hearing somewhere that Mapnik is really slow/behind at dealing with issues and requests, so I'm not inclined to undertake what might be a futile process. However, I genuinely think in this example it's an easy feature to roll out and adds value. It would be nice to know we have an agile process. -- Hubne (talk) 00:29, 7 July 2015 (UTC)
- "does not render in Mapnik" - is it about default map style? In that case "Standard"/"Default"/"openstreetmap-carto" works better, Mapnik is name of software used to generate maps - not only this style ( https://github.com/mapnik/mapnik ). The place to suggest improvements to Default is at https://github.com/gravitystorm/openstreetmap-carto by creating a new issue. Note that landuse=port is used only 160 times, it is extremely unlikely that rendering would be added for that feature. Mateusz Konieczny (talk) 06:04, 7 July 2015 (UTC)
- Yes, you are right, Mapnik is simply a rendering engine, that was sloppy of me. I was referring to the default stylesheet, because I care about users coming to the site, which is their first impression of the project, and what they see. Most casual visitors confuse that map/website with "OSM".
- The official default stylesheet repo you link to is where I read a discussion in the issue #1630 comments that made me think the process for requesting changes is likely to test my patience. The problem with ruling tags out based primarily on usageis that a tag's usage/application may well be skewed by the fact that the tag has poor rendering support in common stylesheets. That is, mappers like me make a decision to use a broader tag because I want my local friends to be more impressed by their local map. To implement something like landuse=port seems algorithmically cheap. It is a replacement fill colour, not a new one. So I'm saying, in some cases, tags are not popular because of renderer behaviour and there are more considerations than that. --Hubne (talk) 21:49, 19 November 2015 (UTC)
- "really slow/behind at dealing with issues and requests" - you may see how it works at https://github.com/gravitystorm/openstreetmap-carto/pulse/monthly https://github.com/gravitystorm/openstreetmap-carto/commits/master and https://github.com/gravitystorm/openstreetmap-carto/issues Mateusz Konieczny (talk) 12:01, 7 July 2015 (UTC)
Water tanks blocking addresses
Make items show up now during rescue operations
Well if for some reason the worlds biggest building, mountain, fairgrounds, etc. don't show up...
No. instead let's say during a critical rescue operation for some reason properly tagged bridges aren't showing up. It would seem to make sense to
- Submit a bug report, and
- Adjust tagging to make it show up while waiting for the bug to get fixed.
Fixing the bug might take a long time as the software is very complicated and needs a big team. At least we can adjust the tags to make the bridges show up now. Jidanni (talk) 08:51, 23 December 2019 (UTC)
- "Adjust tagging to make it show up while waiting for the bug to get fixed." - it is OK as long this is not a mapping for renderer (adding incorrect data/removing correct). Note that everybody may make their own rendering, showing whatever is important for them Mateusz Konieczny (talk) 12:00, 23 December 2019 (UTC)
Legitimate cases of inspecting how the map was changed after your edit
In fact after each edit, the user sees
You just edited OpenStreetMap! Thank you for improving the map around Nibblesburg. Your changes should appear on OpenStreetMap within a few minutes.
Therefore we see there is never a need to waste time and inspect how the map now looks after our edit, as if we don't trust the message.