-
Notifications
You must be signed in to change notification settings - Fork 821
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
Render highway=busway as highway=service + access=no #4714
base: master
Are you sure you want to change the base?
Conversation
One thing I couldn't get it done (sorry, first PR to the project) are the one-way arrows. I tried adding it on L4061 and L4095, but it still didn't work. (Is there some sort of pre-processing needed for it to show?) Also, as is evident on the above screenshot, it is rendering on top of other highways (i.e. highway=secondary), we could also change that as well. Nevertheless I wanted it to be a starting point (or perhaps a re-start to the discussion, which stalled). |
This competes with #4456. Both PRs communicate different ideas of how I looked again at the use of What can be seen is an increasing use of If there is consensus in the mapper community that |
Hello @imagico, first of all thanks for your reply and your detailed opinions into the matter. I personally see the tags as synonyms and would be happy with either PR being accepted. I honestly think that there are bus corridors (and specially BRT corridors) still tagged as I don't think I also think we can make clear use of the |
Just to expand a bit further on the "dos" and "don'ts" I mentioned in the previous comment, with some examples from Eindhoven, Netherlands (an example not from Latin America on purpose):
|
From my understanding, this PR is more conservative, while the other one makes a much more distinction from service roads. The other one did not advance because (among other reasons) it may conflict with other Carto problems from 5-6 years ago. I believe this one, which is way more conservative (given it does not change rendering from current tagging), is a good solution for now. If those other problems are fixed, maybe we can revisit #4456 later. This one does not introduce any problem on rendering and will help the transition from the old tagging to the (not so new) approved tag. And as said before, the lack of rendering makes the tag not used as it should. With some type of rendering, we could allow the mappers into making the transition. I did the transition in April 2021 in my city, but I understand why @nighto did not change that in Rio. (Yes, the wiki should be updated to make it clearer the distinction between |
Any news on this? Sorry to be a pain but another month went by with no news on this PR acceptance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have commented on this extensively here and in #4226 (comment). Unfortunately not much discussion has happened based on this, neither here nor in the mapper community regarding better defining the delineation between different tagging approaches to bus exclusive roads.
Anyway, enough has been said about the strategic side of this matter by me already and i perfectly understand if pursuing this on such a strategic level is not what you feel like doing. I understand that for you highway=busway
is a synonym for highway=*
+ access=no
+ bus=yes
and under that premise this change makes sense if the ultimate goal is to replace the latter tagging with the former. Unfortunately the latter tagging is vastly more widespread than the former so far (30k vs. 6.6k uses). At the same time my analysis showed that highway=busway
is not used with a higher level of consistency world wide than highway=*
+ access=no
+ bus=yes
. And our goals explicitly mandate us to try to avoid supporting proliferation of tags. Also, there are many indicators that mappers mostly think there is a semantic difference between the two taggings (but unfortunately so far opinions vary a lot regarding what that semantic difference actually is).
In light of this i am currently not inclined to merge this change but i am not opposed if it finds consensus support from the other maintainers.
It will remain so, because only some of the potential uses/meanings of highway=service + access=no + bus=yes are taken and the majority will remain. Perhaps there is not a bright line currently, and maybe there never will be, but if you believe this is a prerequisite the tag will never be widespread enough for you to support it. |
Confirming my point that there is no consensus among mappers if |
Your goals explicitly mandate you to provide feedback "for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use". The fragmentation of tag use you are referring to has been judged as favorable by community approval of the This continued refusal to accept the result of a formal OSM community vote is also terrible for the goals of being "a major part of the public face of OpenStreetMap" and "an exemplar stylesheet for rendering OSM data". |
As we have said many times in other contexts: The proposal process on the wiki is a means to allow mappers to evaluate their tagging ideas in discussion with a somewhat wider audience and possibly identify and address issues that they have not seen. It is not in any way authoritative to anyone - neither mappers nor data users. It can help increase the chance of a new tagging idea to be successful, it is not a guarantee for that. And it has no bearing on our decision if and how to render certain tags. We base that primarily on how tags are actually used. Since apparently questionable statements have been made about OSM-Carto in other venues in context of this pull request i like to clearly point out again: No OSM-Carto maintainer has so far indicated that they are against rendering Personally i have clearly stated in the discussions linked to above what for me are the conditions under which i'd support adding rendering of Anyway - this whole discussion is off topic on this pull request. Please limit comments here to matters relevant to the specific design concept suggested here. Discussion of the rendering of |
You should already render |
This is embarrassing for the OSM community, that it takes years to make such a simple tag have any render on the map. At least, make an interim render, for example matching the style of |
Fixes #4226
Changes proposed in this pull request:
highway=busway
ashighway=service
+access=no
Rational:
Before
highway=busway
introduction, busways and BRT systems have been mapped ashighway=service
+access=no
+bus=designated
. There is a two year old discussion on how to map busways and a one year old open PR with a proposal to map busways in a certain way, that unfortunately got stuck. With this PR, I intend to start with a very conservative approach: Render busways just like they used to be render with the previously accepted tag.Test rendering with links to the example places:
(Please ignore the small
highway=traffic_signals
differences on the renders, my PBF is a couple of days old)Before has OSM logo, After has Kosmtik logo. Test area is in Eindhoven, Netherlands, zooming towards WoensXL/ZH Catharina bus terminal
Z14
Z15
Z16
Z17
Z18
Z19
Also please note that this proposed rendering is exactly like the previous accepted BRT tag schema, for example BRT Transoeste in Rio de Janeiro, Brazil (which has not been migrated to
highway=busway
and therefore is still visible on the default rendering):highway=service
+access=no
on Z18: https://www.openstreetmap.org/#map=18/-23.00709/-43.31254