-
Notifications
You must be signed in to change notification settings - Fork 827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review some tags we already render #3305
Comments
Interesting. A lot of the open issues are to do with features that are missing from the map (and I'm guilty of that) but not so much for things we shouldn't render. #1003 (
I can't think of anything else that should lose rendering at the moment, but there are things that are too prominent or render too early for the scale of the feature. |
Another one is leisure=common. It has a very UK-specific meaning, the tag is misused very often, and should normally always be tagged with a physical tag like landuse=grass. |
I think this is a good chance to reduce what we render as we've been adding so much. |
Default style renders highway=footway areas while due to OSM Wiki mapping them as areas is incorrect: https://wiki.openstreetmap.org/wiki/Tag:highway=footway What do you think about allowing pedestrian and cycle area:highway=* areas (~35k uses in total) instead? |
The wiki does not explicitly discourage area=* on a footway, it is used 45K times. I'd say it's just badly documented. I see that being used a lot, e.g. in a park where the linear footways join in the middle and form a little area with some benches around. I'd not start rendering area:highway=* in isolation for one particular highway type. |
For me personally it's not about removing or adding, rather exploring how do we decide to render things in reality. Old tags are interesting case to check, since they are with this style since day 0 probably (they were ported from XML style) and maybe they could tell us something - or we could change their rendering. |
I've just discovered |
sent from a phone
On 26. Jul 2018, at 17:03, lakedistrictOSM ***@***.***> wrote:
I've just discovered man_made=cutline. Seems like a lazy way of splitting forests into smaller sections. Also the rendering make them look like strips of grass.
exactly, just that you don’t get the advantage of the smaller polygons you obtain when splitting
|
@lakedistrictOSM Cutlines are very important in fire-prone boreal forests like Russia or Canada. If there is misuse of a tag this should be tackled through education or retagging, not by abandoning a valuable rendering. But the color could be changed, indeed. |
I'd consider the cutline as part of the forest landuse. You don't have two forests in reality just because of a cutline. However, we are in the issue of landuse vs. landcover again. Landuse is forest, just the cutline is not covered with trees. |
I would like to add my opinion that landcover=grass should be rendered. I just created such an area and expected it to render green, but it doesn't render at all, to my surprise (bad sign). On #osm I found out that it indeed does not render and yes, the community is in dispute between landcover and landuse. I used landcover, because it seemed to be the more semantically correct tag to use in my case (patch of grass not really used by anyone, not useful). Someone suggested to use landuse in addition to landcover, just so it renders as green, which demonstrates the issue. The core issue being that the semantics don't match their representation, which leads to people misusing tags to fix the presentation, rendering the semantic value of the data moot. (To take this issue to an extreme, one might as well have a In my opinion, this is the source of the landcover-landuse controversy. It's a symptom of a presentation layer bug. That issue would have never arised, had the landcover been rendered correctly from the start. |
@avoidr - please read up on the previous discourse on the topic (in #2548 where the reasons for not rendering the two tags was explained in detail but in particular also on the tagging mailing list - look for the subject The endless debate about "landcover" as a top-level tag in June) before bringing arguments once again that have already been discussed many times. That there is a dispute between landcover and landuse is a misconception. But this and any other discussion on what is the right way to tag certain things does not belong here. |
I'd like to see power=station and power=sub_station not be rendered anymore. Since both tags have been abandoned/depreciated and it might help discourage their use going forward if they don't show up on the map anymore. Unfortunately, power=sub_station still has pretty high usage numbers. Therefore, it should probably stay for now. Power=station usage is semi low though at this point though and might be able to go without much offense now, if not sometime soonish. |
Deprecated Deprecated Adding Dropping deprecated tags could be done some time after announcement on the Tagging and Talk list. It worked nice with dropping @Adamant36 Would you like to make such announcement and create PRs for these actions? |
@kocio-pl Deprecating power=sub_station will be a triumph for the automatic retaggers. They – and nobody else – has retagged this old tagging. |
I disagree. While it is unfortunate that we have two synonymous methods for tagging forested areas, meaning of them and wide acceptance is clear. Though I agree that two values with de facto the same meaning lead to people inventing differences between them what is a bit pointless. |
Of course there is a difference: landuse=forest is used by forestry while natural=wood is an unexploited forest (a 'wild' forest in some languages). |
This should be automatically retagged from the start, because this is a simple and clear job. People checking their properties is another, manual job, which can be done every other time. It would be a triumph of consistency and not trying to put every possible job in a single, well defined object edition. |
@chazanov, wrong. Me and a few other people have re-tagging them when we have the time for a couple of years now. Although, its been massively undermined with hate mail and reversals by people like you that want to gripe about it being automatic edits when they aren't or go off about how the changes aren't legitimate, unless every detail of tagging quality on the surrounding area is checked in the process. Its a weak excuse for people to dig their heals in the ground on a depreciated tag and I'm sick of hearing it. As @kocio-pl says, they should have been automatically re-tagged from the start. So me and others don't have to waste our time on it unnecessarily. Plus, checking properties is a separate issues from re-tagging. Ultimately, neither have anything to do with what should or shouldn't be rendered on the main map anyway though. |
@Adamant36 - I understand what you are looking at, but take a bit of fresh air. I think it is sufficient for this style here to observe that a particular tag is on the decline with reasons, and to decide not to render it anymore. It has been announced on the tagging list, so users are not taken by surprise and can adjust their tagging. It is not the job of the style project to encourage, discourage or organise any retagging (other than being an influencer that is not showing it anymore). |
Sorry for being forced into a very rude statement, but here things are getting misrepresented. It wasn't the people, it was only the Germans which did this cleanup effort. No other community than the Germans (+Dutch, Belgian, Austrians and Swiss) would be able or interested in such an effort. There is still much to do for farms: Take on this. And many farms were automatically retagged without proper review (also mainly a problem of Georgia, US)! |
Thanks for the clarification and correction of what I said - I see nothing rude about being precise. I believe automatic retagging was good to make things a bit better (proper review is needed anyway for all the objects in OSM database, retagging of type is just a nice opportunity!) and still not all is resolved, which might be an issue for a long time. It also made sense to cut rendering at some low point above "0 usage". |
Why is the Overpass link dead? |
Because it got "And" appended. I am pretty sure that you wanted to link https://overpass-turbo.eu/s/CZz |
Should I open a new issue about removing the deprecated tags power=station and power=sub_station, or should I open a PR directly? |
I would open an issue first. Given significant use ( https://taginfo.openstreetmap.org//search?q=power%3Dstation 16k, 4k entries). See for example "drop rendering for waterway=wadi" #1365 where similar idea was rejected. |
The difference for me is that the numbers for power=sub_station and power=station are both on a steep, consistent decline. Whereas that's not the case for waterway=wadi. I think that should factor into it more than the current usage numbers. |
The ration for substations in currently 16 229 elements [4,6%] for |
I opened a new issue #3871 specific to |
It's one of the things that came to mind when evaluating new tags for rendering: we do this tag by tag and without critical view on currently rendered tags.
In heated debate about
landcover=*
we talked only about relative numbers and problems with new proposition. Yet nobody touched the problems withlanduse=forest
andnatural=wood
- see Add rendering to landcover=grass and landcover=trees #2548 (comment). I'm pretty sure that we would not let them in (especially both) if they would be proposed today.Another issue and much smaller remark (render highway=street_lamp at z=19 #3277 (comment)) has shown that we also render some things which have no direct use for typical map user, like aeroways. So why we have them at all? And if it's what we want - why should we still show them?
And to touch also picking tag-by-tag, let's think about roads. They are poorly defined if we take the objectivity rule (just like
tourism=attraction
), but let's assume only some of them are bad. Yet lack of one type of the road would cause the map to loose its coherence. Similar new case are castles, where it's natural to use some system than pick tags one by one.Do you see any other problems with existing tags we show?
The text was updated successfully, but these errors were encountered: