Skip to content
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

Closed
kocio-pl opened this issue Jul 15, 2018 · 29 comments
Closed

Review some tags we already render #3305

kocio-pl opened this issue Jul 15, 2018 · 29 comments

Comments

@kocio-pl
Copy link
Collaborator

kocio-pl commented Jul 15, 2018

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.

  1. In heated debate about landcover=* we talked only about relative numbers and problems with new proposition. Yet nobody touched the problems with landuse=forest and natural=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.

  2. 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?

  3. 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?

@kocio-pl kocio-pl added this to the Bugs and improvements milestone Jul 15, 2018
@lakedistrictOSM
Copy link

lakedistrictOSM commented Jul 16, 2018

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 (waterway=derelict_canal) was a good example of something that had rendering but unclear tagging.

leisure=common is another unclear tag that is currently rendered - in the UK it's an official designation so they should really be tagged under the designation= key. The green rendering for them is also misleading - I know of one common that is mainly paved! (also mentioned in #2964)

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.

@matthijsmelissen
Copy link
Collaborator

matthijsmelissen commented Jul 17, 2018

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.

@pnorman
Copy link
Collaborator

pnorman commented Jul 17, 2018

I think this is a good chance to reduce what we render as we've been adding so much.

@Tomasz-W
Copy link

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?
https://wiki.openstreetmap.org/wiki/Key:area:highway

@polarbearing
Copy link
Contributor

polarbearing commented Jul 17, 2018

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.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jul 18, 2018

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.

@lakedistrictOSM
Copy link

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.

@dieterdreist
Copy link

dieterdreist commented Jul 26, 2018 via email

@antifa-ev
Copy link

@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.

@polarbearing
Copy link
Contributor

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.

@ghost
Copy link

ghost commented Aug 17, 2018

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 colour tag. And only that tag)

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.

@imagico
Copy link
Collaborator

imagico commented Aug 17, 2018

@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.

@Adamant36
Copy link
Contributor

Adamant36 commented Aug 18, 2018

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.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Oct 20, 2018

Deprecated power=sub_station is much less popular than power=substation already (313 626 > 17 523), so I think dropping deprecated version is possible.

Deprecated power=station has even smaller usage (5 020), especially compared to power=generator (436 622), so I would also drop it and instead introduce power=plant, since it has proper usage now (14 355).

Adding power=plant area rendering could be done immediately, but this is already discussed on #3405.

Dropping deprecated tags could be done some time after announcement on the Tagging and Talk list. It worked nice with dropping landuse=farm (#2554) - it took just like 2 months for the people to retag all ~360 000 uses!

@Adamant36 Would you like to make such announcement and create PRs for these actions?

taghistory 13

@chazanov
Copy link

@kocio-pl Deprecating power=sub_station will be a triumph for the automatic retaggers. They – and nobody else – has retagged this old tagging.

@matkoniecz
Copy link
Contributor

Yet nobody touched the problems with landuse=forest and natural=wood - see #2548 (comment). I'm pretty sure that we would not let them in (especially both) if they would be proposed today.

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.

@antifa-ev
Copy link

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).

@kocio-pl
Copy link
Collaborator Author

Deprecating power=sub_station will be a triumph for the automatic retaggers. They – and nobody else – has retagged this old tagging.

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.

@Adamant36
Copy link
Contributor

Adamant36 commented Oct 23, 2018

@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.

@polarbearing
Copy link
Contributor

@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).

@antifa-ev
Copy link

antifa-ev commented Oct 26, 2018

Dropping deprecated tags could be done some time after announcement on the Tagging and Talk list. It worked nice with dropping landuse=farm (#2554) - it took just like 2 months for the people to retag all ~360 000 uses!

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)!

@kocio-pl
Copy link
Collaborator Author

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".

More or less current state:
taghistory 19

@antifa-ev
Copy link

Why is the Overpass link dead?

@matkoniecz
Copy link
Contributor

Because it got "And" appended. I am pretty sure that you wanted to link https://overpass-turbo.eu/s/CZz

@jeisenbe
Copy link
Collaborator

Should I open a new issue about removing the deprecated tags power=station and power=sub_station, or should I open a PR directly?

@matkoniecz
Copy link
Contributor

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.

@Adamant36
Copy link
Contributor

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.

taghistory 2

@sommerluk
Copy link
Collaborator

The ration for substations in currently 16 229 elements [4,6%] for sub_station versus 334 302 elements [95,4%] for substation. Of course 16 229 elements is a high absolute number; on the other hand relative to its competitor tag, it’s quite clear which tag wins…

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 5, 2019

I opened a new issue #3871 specific to power=sub_station and power=station, so this issue can be closed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests