Add rendering for highway=busway.
#4226
Comments
|
Because none of the busways are distinguishable at zoom-level 13, I decided to include an additional photo of the West Busway at zoom-level 16. Unlike the East Busway and South Busway, this one does not run alongside any railways. If you are having trouble finding it, look for the bus-stop icons.
|
This combination of tags is also used for short service roads which bus only and doesn't let us distinguish them from busways. I don't think we can do this until these features have a distinct tag in OSM and it has wide-spread usage. |
|
The tagging is currently being discussed on the mailing list (See this thread: https://lists.openstreetmap.org/pipermail/tagging/2020-October/055747.html). There was a new draft proposal to use We could use |
|
I’m closing this for now because there is still no established way to tag these features. Once either @kolgza if you wish to help clarify the situation, consider using the Proposal process to get one of the tags discussed by the community. |
Is it theoretical example? Or something actually happening? Are there any service roads where access is restricted to buses, but are not busways? Triggered by https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tag:highway%3Dbusway#service_roads_where_access_is_restricted_to_buses (answering at wiki would be likely preferable if possible) |
|
I believe that it would now be appropriate to reopen this issue. |
kolgza
changed the title
highway=busway.
|
Reopening to encourage a renewed discussion based on the concrete tag Observations from my side:
|
This was all my doing. It was incredibly ill-advised, and I'm currently working to revert some of the more-careless changesets I've submitted. I must sincerely apologize.
I should have finished migrating all the information from the proposal page to the Wiki page before declaring my work in that aspect to be finished. |
|
Here's a mockup based upon the
It could do with being wider and appearing at a lower zoom level, but it gets the point across. The existing |
|
Here's a mockup I made based on what @jleedev did, but using the colors from the rendering of
|
|
It seems to me that busways are more similar to roads and bus guideways are more similar to train tracks. Thus I would expect bus guideways to render in the "railway" family and busways to render in the "highway" family. |
|
@ZeLonewolf That's what I think too. In addition, the electric blue of bus guideways can be confused with water by the users of the map. One may consider purple, violet or magenta instead. Perhaps purple can be a good choice in combination with landuse=railway or any future landuse=* value for rail-like systems such as bus guideways and BRTs. |
|
IMHO it could render as something, at the first moment even the same as An interesting discussion is going on over the tag's talk page. |
|
Would it be possible to render them at least the same as On the Dutch forum the Catch-22 nature of supporting this new tag has popped up as well. If there is a clear minimum number of tagged instances to work towards, mappers can more easily decide if using it is acceptable with rendering forthcoming, or that it would mean years of having a gap on the map. |
|
A busway under construction, |
|
Is there any progress here? I'm reluctant to convert the busways in my area to a new tag, and some of the ones that were converted by another user were reverted since they thought it was vandalism. Why must something have "widespread usage" before it is rendered? It seems to me that it should be the opposite; that you render it immediately (and also add a preset on iD), so users would have the knowledge that such a tag exists, and therefore have an incentive to actually map it. |
|
Currently this tag has over 4200 uses. The tag highway=bus_guideway, that has been used for comparison in this issue, only has 900. I don't really understand how many uses we need until this approved tag will be rendered. It really lowers the quality of this map and therefore the Openstreetmap website, when really prominent features like this busway are rendered as an empty space. I also see people changing busways to highway=service, because highway=busway doesn't render in OSM Carto. Therefore idea that this tag wouldn't be accepted is actually a circle reasoning. Some people don't accept it, because this issue isn't solved. |
|
I completely agree with the above. I find it very sad that there has been pretty much no activity with regards to this issue since April. |
|
The same. A widely used tag is not being rendered. Other renderers, such as OSMand, already support this tag and render it. |
Yes - if there are issues with the tagging they need to be fixed in OSM before we add it to osm-carto. We never add features until they are established with a consistent definition. Cartography chosen needs to work in all regions, so if regions are using it very differently we can't develop something that will work well everywhere. If such a cartography was possible I might be okay with it, but that part of the cartographic space is so crowded it's going to be hard enough to find something that works with one usage, let alone with both.
I'd be fine if someone came up with a busway rendering that fits with the current rendering of access restrictions. I think #214 makes this much more difficult but not impossible. |
|
Just my 10 cents worth of comments on: What if diviations on the standardkey can be noted as country-ID: standardkey so the differences will then be applied for that country ? Could this be an acceptable solution to solve the discussion? edits being applied: either done to emphasise matters by using bold type or resolving plain typ-errors |
|
Just a quick comment on the idea of regionally differentiating the style. This is a separate topic so if you want to discuss this in more depth please open a separate issue. OSM-Carto has the aim to provide a map for a global audience with no special preference being given to the current de facto spatial distribution of either map users or mappers. This in our interpretation includes (a) as far as possible not regionally differentiating the style rules and (b) not interpreting tagging that is deliberately designed to be region specific. For (a) we have essentially two exceptions: The Mercator projection itself - which is a variable scale projection, hence what the style shows at a specific scale depends on latitude. And the Antarctic ice sheet - which we render based on the established convention that all land south of -60 degrees latitude is ice covered unless mapped otherwise. Point (b) does not mean that we do not render tags for features that exists primarily or exclusively in certain regions (think of things like coral reefs and glaciers but also places of worship of a certain regional religion) - or that we do not render tags that have not been used with global scope from the start. But it means that if a tagging is explicitly designed in a way that the same thing is meant to be tagged differently in different parts of the planet we are not going to support such tagging. This is part of our aim to support mappers in consistent mapping practice. As said before - working on improving consensus among mappers regarding the use of tags is desirable, as is improving documentation of tagging practice. But inquiring here what hypothetical developments in tagging practice might lead to certain design decisions is not very productive. We will look at how mapping practice develops and will adjust our decisions accordingly. But we do not want to have any part in actively steering mappers - neither through our style changes nor through promises of future style changes based on hypothetical changes in tagging. |
Thanks for speaking clear language!
Could you elaborate a bit more about this? I don't entirely understand what you mean here.
Same here, thanks for the clear language!
Ok, in general we know what to do now.
I get that you don't want to steer that discussion in principle, because for you it is a different platform. But I completely disagree that this is not productive: if you were willing to answer those hypotheses instead, that would be productive, so please do. The current mapping practice is clearly not good enough to support rendering, it would be very helpful to know what would be instead. By not wanting to elaborate on that, we don't know what can help us go forward. Which sadly, seems to be the whole issue in this discussion, by not speaking clearly what concrete steps are needed for it to be supported, no one seems to see an outcome any more. I'm not asking you to pick which direction it needs to go, I'm just asking you a few hypothetical situations to know in advance what the outcome would likely be if that path were chosen. This would be really valuable information for a discussion on OSM, so we at least know what the implication of choices to be made will be. Maybe you don't see the point right now, but the more insight we have, the better and more productive the discussion on OSM can be held too. So could you please elaborate a bit more on the hypotheses I asked about in my previous post? I'm trying to break through this status quo that has been going on for years, but that can't be done by sticking to existing habits of staying unclear, because that clearly was even less productive. So please, can you elaborate on the hypotheses in my previous post? |
|
Independent of my role as a maintainer here (in which my opinion how bus infrastructure should best be mapped is simply irrelevant) i personally simply have no qualified opinion on what tagging concepts are best for bus infrastructure. So even if i wanted to contribute to that discussion i don't feel qualified to do so. As indicated already we try to support mappers in consistent mapping practice - no matter how that looks like. At the moment and from my point of view for bus specific road infrastructure this would primarily mean addressing #214. As mappers you should work on consensus in tagging and documenting mapping practice in complete disregard of what map designers might or actually do communicate they desire. Having observed the development of tagging in OSM for more than a decade now i am convinced that the best recipe for a successful tagging scheme is to design it for the suitability for verifiable mapping and not for the perceived needs of data users. I understand that for someone whose primary goal is to get a certain real world feature into the map this approach might seem convoluted and inefficient and the direct approach to negotiate the method of mapping with those in control of the map design seems attractive. But there are very good reasons why we do not take that route. That is why i said inquiries in that direction are not very productive. And i reject the claim that i am not speaking clearly here - i have been very clear on what i consider the prerequisites of supporting an addition of |
|
Ok, I think I kind of understand. In the current implementation of the tag, you see #214 as a necessary step because otherwise you feel a rendering of busways will result in tagging for the renderer. But I don't understand why you don't understand that is already a big issue right now, just because it doesn't render. If I'm correctly, for example @pnorman did not see it as a prerequisite. Decoupling means faster solutions, perfect is the enemy of the good. Why can't a two step solution work, where first we get them rendered, and second the big access rendering update is rolled out? As long as the busway style takes this future addition into account, I don't see why it should be coupled. A bit of tagging for the renderer might still happen in the meantime, but less than what is currently the case because it doesn't yet render. You need to understand that because of the non-rendering, you're currently causing the polar opposite of the principle of encouraging correct mapping practices, and creating problems for OSM mappers by doing so. Which is why we need as soon of an implementation as possible. A good one, that can be perfected later on by solving #214 would be vastly more helpful to the mapping community than waiting years for a perfect solution. It is not that a solution for the busway problem rules out an implementation of that perfect solution later on. But even if that's your hard stance and even regardless of the rendering issue, I agree it is best to have a discussion on OSM first to define the tag usage better so mapping practices can be aligned to it. A tagging scheme that is verifiable would indeed help a lot, both in mapping OSM itself, and in deciding on how to render it. Given a lot of the raised issues with implementing a rendering style seem to get stuck at regional variations and the possibility of getting 'tagging for the renderer', a broadly supported, verifiable definition and in turn adoption by OSM mappers would mitigate a lot of these concerns, am I correct? That way, depending on the outcome, getting it rendered might become a breeze. |
|
My 10 cents clearly did not land well and/or was not understood very well. On my side there is no money left so I wil swallow the Carto imperfection (what ever season the base and/or root of the problem is) since there are many other maprender types which will support diviations… It is just a matter of not using Carto as standard map anymore what will solve the problem… |
|
@Squizie3 - we all have different experiences in OpenStreetMap and as a result we see things differently. In the end all i can do to deal with that is to explain my view and the reasoning this is based on and listening to the reasoning others present for their views. Regarding the influence not showing something in the map has on mappers - there is a qualitative difference between the influence of showing something (i.e. endorsing a certain way of mapping) and not showing something (i.e. not endorsing a certain way of mapping) and there is also (as already pointed out) a quantitative difference between the use of OpenStreetMap's system of differentiated mapping of access restrictions on roads and the implicit mapping of bus only restrictions via @GJDillen - that is an approach i very much support. We need more diverse community map styles in OSM. And as counter-intuitive as this may sound - the OSM community being less dependent on OSM-Carto would actually be good for OSM-Carto. But ultimately it all depends on the OSM community actually stepping up and developing more ambition in the design of maps. #214 has been open for more than 10 years now and other than my own demo i am not aware of any system of comprehensive visualization of access restrictions on roads in maps having been developed during that time. OTOH in the three years |
Ok, but I hope this is more than a discussion just to present viewpoints without doing something with it, and this also could serve to get to a solution... The discussion from past years has shown there's a lot of community feedback asking for a solution, and there were also a lot of people willing to put effort into it, but your answers manage people just to give up, instead of getting them to work on solutions. Being honest here, you should probably ask yourself why that is. If you want people to help improve, you will also need to be open for their input so we can work towards a solution. I'm being completely honest here, because I hope this might lead to some insights: you don't seem to be open to community feedback on this issue. You only seem to push your own priorities, which is the access restrictions overhaul, which for everyone else seems not necessarily tied together. That's how I and others who have contacted me by now perceive it currently. This might not be intentional and please don't see this as an insult, I'm just communicating the perceptions I and others get. I hope this is not intentional, and if you want, you can take steps to change that perception. Or if it was intentional, then not, but then please just say so. Then we at least know. Currently, I still want to work towards a solution, but you also need to be open for community feedback for that, or no solution is reachable ever. This could mean that you have to accept a good solution over a perfect one, for example. Please, take a step back and ask yourself, is it really needed to ty both issues together, or are there certain conditions under which it isn't any more and what are they? This way, we can work towards more simple goals in a step by step approach, that actually leads somewhere.
And I'm going to ask a brutally honest question here again: why do you think you have the legitimate power to decide for OSM users to not endorse mapping busways by not showing them?
But why do you think people would be stepping up, if all they get is that they should strive for your personal perfect map style? You need to be open for feedback more, otherwise you're putting people off from investing time in it. You're always coming back to access restrictions rethinking, yet you seem to be alone in the vision that this should be tied together. All other major map styles have by now adopted highway=busway rendering, even in it's current form with ambiguous usage around the world. If this isn't a clear sign that this map style is getting out of touch with the community, then I don't know what will. So I have now made a post that's a bit different than others, because I want you to know how this discussion is perceived. This is not meant as an attack on anyone, I just hope it can open some eyes. Sometimes this might be necessary to get out of a loop, which seems to be ongoing in this discussion for years now. I honestly hope you will read this in good faith and overthink it a bit, maybe even before reacting right away. Apart from that, from the whole discussion, I conclude that whatever we do, the current ambiguous tagging practice leading to regional variation and tagging-for-the-renderer based on personal interpretation needs to be solved first. This discussion will need to be held on OSM, hopefully resulting in better, verifiable tagging practices on the OSM map, and thereby also clearing some of the roadblocks that prevent them being rendered. |
|
While it is insightful to see how people perceive this project this has moved now almost completely outside the topic of this issue. My impression is that you quite radically reject many of the basic premises of OSM-Carto - both the core values (some of which i have explained in previous comments) as well as the governance model (working through consensus among a diverse group of autonomous maintainers). None of these premises is set in stone - you are welcome to discuss ideas for changes in those in a separate issue. But you will need to convince the maintainers with arguments and reasoning of the merit of the changes you suggest. And in contrast to design decisions where we have the practice of individual maintainers to try not to stand in the way of consensus building where possible (and i have stated this explicitly for this issue on multiple occasions) on governance matters broad consensus will be required. However, my feeling is that your vision of community map design is so fundamentally different from what we try to do here in OSM-Carto that it might be advisable for you to consider initiating a separate project implementing that vision. You indicate you consider yourself speaking for a considerable group of people so there should be capacity to start something like that. I have made this suggestion before when people fundamentally oppose the ideas and values of OSM-Carto and like before i mean this seriously. Both OSM-Carto and the OSM community would profit a lot if there were other community projects with a global scope competing for providing a map for OpenStreetMap. It is also possible though that your view is substantially shaped by incorrect assumptions made. You seem to base a lot of your ideas on assumptions regarding the motives and roles of people - assumptions that substantially contradict what has been said here. So it might be advisable for you to follow one of the oldest principles of OSM and assume good faith and take the explanations made on what motivates us to see things the way we do at face value and re-evaluate your reasoning under that premise. Independent of that the matter of this issue remains - all maintainers (as far as they have voiced their opinion) are open to the possibility of rendering |
Yeah sorry for that, I'll try to get back on topic later this post! But I thought it might provide some insights. Maintaining a community driven project also involves people skills, apart from technical and design skills. So if something feels off, at least I think it could be valuable to let it be known, because one might not be aware of it.
Ok, then that's not entirely well communicated from my part, as in fact I don't question any of the core values itself. But I do have some issues with the implementation of it, yes. The governance model of working through consensus among a diverse group of autonomous maintainers is very good in principle. But the way it seems to be implemented here seems off: currently, you seem the only maintainer around here in this discussion that actively holds back the process by requesting #214 to be solved first. There's almost no interaction from other maintainers, and if there is, they don't even seem to support the same hard stance as yours. You have to understand, that from the communities' viewpoint, this doesn't feel very much as a consensus model, but rather a one man's vision. If a few other maintainers would step in and also figure out this was a hard requirement, ok, then it would feel more legitimate. But I don't see that consensus now.
Sure, but you all know as well as me that there's a very big difference between being interested in map design, and maintaining a whole new map rendering. The former requires a completely different skill set than the latter. And you may have guessed, the vast majority of people in the OSM community who express their interest in e.g. rendering of busways are part of the former group.
Ok, I'll take that one! I deliberately pushed it a bit because I was genuinely questioning the motives so I wanted to challenge that, so the contrary could be proven. I really do hope as you just stated, that this feeling was wrong, and I'll assume good faith.
Ok, to finally go back on topic. Could this stepped approach work: Step 1: A discussion on OSM about the definition of highway=busway is to be held, as the current regional variations and open-to-personal-interpretation definition seems to be a barrier for rendering for multiple people (and is also just not in line with OSM's own stated goals). Either this leads to a confirmation of the current definition, or preferably leads to a more universal definition with better verifiability that in turn could solve the issue of personal interpretation and regional variability. Once that discussion has concluded it also needs adoption on the OSM map, which depending on the outcome might take a while. Step 2: design work on one of the proposals needs to be resumed. If the outcome of step one is a well verifiable and well adopted definition of busways, a design that takes a future access marking overhaul into consideration may suffice. If the outcome is more or less a status quo, an access marking overhaul might be required first, if this is endorsed by multiple maintainers. Does this seem a good approach? If so, we can finally starting to work on these steps and make meaningful steps towards a solution. |
|
Since the matter of consensus based decision making has been put into the foreground i like to emphasize again that in contrast to many other matters in this style there is no lack of maintainer consensus on this issue. And even if there was disagreement on a concrete decision - i have stated many times now that from my side that would not stand in the way of merging a change implementing this and none of the other maintainers has indicated that this is a matter of fundamental importance for them either. One of the reasons why many of the maintainers here have largely stopped participating in discussions is the demanding and disrespectful attitude that has become widespread among commenters here. Several current and former maintainers have made statements to that effect. In light of this trying to instrumentalize maintainers who have stayed silent in this discussion to allege a disagreement with my assessments is - to put it very mildly - not a very good idea.
I'd advise against trying to follow a pre-defined checklist on matters of tagging development. Most mappers do not see it kindly if they are pushed around in pursuit of someone's pre-defined agenda. But as already said working on improving agreement among mapper on the use of tagging for bus-exclusive roads is a very good idea and would make it substantially easier to develop a suitable approach to rendering in maps - not only, but also here. Like @pnorman i am not going to provide predictions on how i would view future design proposals for rendering such roads under changed conditions regarding the practical use of tags. As has been mentioned the conditions for this are challenging with the crowded design space in this style - but i also consider this to be doable in principle. And as i have pointed out several times already: There is nothing any of the maintainers here has against displaying bus exclusive roads if there is clear agreement among mappers on how to map those. There are also things style developers can work on right now independent of bus exclusive road tagging that would make such work definitively easier - in particular the points the move to the flex backend and disentangling the use of blue and purple color in the style in #4901. The former would for example allow adjusting road rendering of roads based on route relation membership - which, as mentioned in #4226 (comment), is one of the main ways of bus infrastructure mapping. |
Ok, I really thank you for this explanation, as it makes things clear. It is good to know that this in fact is something the others are also on broadly on board with, we can't know if it isn't mentioned and they don't say it themselves. My conclusion was drawn on this statement, which seems to imply a more relaxed stance on the access restriction issue:
But apart from that, I conclude that in general there is consensus among maintainers, which is good to know. And if I've been too direct and perceived rude, my sincere apologies, because that's not how I want you to feel. This is an important and beautiful mapping renderer, which I think we all just want to see succeed. There's just a bit of an incongruence between the maintainers and wider community expectations, but I think we all acknowledge you guys do it with the best intentions, and probably with good reasons.
It's intended to know what actually can be done to move forward, nothing more, nothing less. A clear set of things that could be worked on was most likely the reason why no one was taking action for a while now. But it's good to know that there is clear consensus that improving the tagging practice would help moving forward. This can now be worked on.
Ok, I understand you don't want to anticipate on hypothetical outcomes in principle. No problem, we'll then just come back at it after possible developments in the tagging definitions and practices have taken place.
Ok, good to know. If anyone can help out, please do so. Although, I'm personally not the right person to do so, I'm afraid. General conclusion: time to work on the busway definition and mapping practices. After that, design work can be resumed based on the developments. Let's do it. |
|
Great work Squizy3! Now for the follow-up: I saw you and others made some updates to https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dbusway&type=revision&diff=2680862&oldid=2599055 but is there any ongoing (community) discussion on the exact meaning and intended usage of highway=busway? |
The comment of the revision you shared points to this community thread: https://community.openstreetmap.org/t/highway-busway-on-non-brts/110578 |
|
This issue affects the non-guided sections of the Cambridgeshire Guided Busway, seen here: https://www.openstreetmap.org/way/464098914 Are we likely to see this implemented? |
|
I did some experimentation to render busways. I settled on normal width to indicate that it is not a service way, and modified the colour:
I also believe we should not be rendering any implicit access. As they can a do change. |
I had to look at that a few times to realize that it was not a canal. This would be more obvious in most of the world, but makes me think the colors are too similar. |
|
It would make sense to connect the colour with https://www.openstreetmap.org/way/111495268#map=18/52.22907/0.15036 (The guideway stops where the the busway starts.) The image shows the current problem with too many shades of blue (4 shown). Personally I don't care for the |
Ok, ill see if it is possible to separate it more. I also attempted a more purple color however then it becomes the next color after the motorway color, and I thought that was confusing. But maybe it is better than being in the blue space. With guided busway there would be a few options we could go. Some options could be to change the color to be the same as busway and leave the rest. Another option would be to render busway and guided_busway the same. We could also render guided busway and busway the same but make the inner fill smaller to make the casing a bit wider, or do a hybrid highway/railway rendering. Ill try some different options/colors to see what works. |
|
Would a lavender shade be a good option?
|
|
quite heavy for a feature "no one" is allowed to use. |
Except that these are used by the general public heavily in a similar way to how the general public uses railroads. The material and construction of the surface is like a normal street, but the usage is more like light passenger rail, street cars, and trollies with regular public transit running on a defined infrastructure. |
|
I have tested some diferent options on this location: No change to guided busways: Change the color to be the same: Render busways and guided busways the same: Render guided busways with narrower fill, resulting 2x casing width: Render guided busways with more narrower fill, resulting 2.5x casing width: Hybrid railway-highway rendering: |
|
I would be okay with rendering busways and guided busways the same. The current guided busway rendering is largely for historical reasons dating back to the start of the XML style. Of the options I find the same rendering or the hybrid railway-highway rendering the best. The lavender shade looks too much like a border to me. The pink color works in the sense that it's distinct from any other color on the style. It also is a shade I've never seen for transit features anywhere, which is not great. Is the transit blue too close to water? I haven't run the delta-E calculations but it might work. |
I’m not sure to witch blue colour you are referring to. However I would say blue is problematic because of the many usages already. And blue is used to indicate bicycle traffic. I think it would be best if we try to pick separate colours for different traffic types. Do you have a suggestion of colours that you think would work best? |
I think the pink is a very good choice here as it is distinct, which is very rare to find. Just visually, the blue/green seems rather close to existing features as indeed water, bike lanes,... regardless of calculations. For the pink, I did not expect there to be any colour left that is distinct enough to not blend with backgrounds or to look too similar to existing features, and still not look as a continuation of the existing highway classification system (like purple would). I don't think not having seen it used for other transit features is an issue though. Transit is usually either displayed by their line colours or a base colour depending on the map style, but they vary wildly from map style to map style, if they are shown at all. With that additional requirement, there will simply be no colours on the colour wheel available that also do not blend with backgrounds or look to similar to existing features. As for the styling options: I think the conclusion was that it needed to work with the existing access restriction implementation, so no rendering of implicit access restrictions indeed (as no other roadway types do that either currently). For the guided busway, it was clear in other threads that there was large support to redo that styling together with busways, as for the general public those de facto mean the same thing: a road for buses where you cannot drive with your personal vehicle. A rendering that is exactly that of normal busways would indeed work, although I like the idea of a small variation to set them apart for the viewer that wants more detailed information. The old styling (even with colour change) does not make any sense to me and gives the impression it is a sort of railway, which is further from the truth than it being a sort of busway, so it should follow that latter one's styling closely. I do like the narrower fill options a lot more than the 'railway dash' version though, for one specific reason: to me this looks like the access restriction for a closed road. And given the current access rendering scheme should also apply for the busways, you should probably test out a version with gray access markings as well (which would indicate the busway is closed entirely), and I am pretty sure that would clash resulting in a visually very ugly result. Could you try out a rendering with the access restrictions of the different options (not as default, but this should render when a tag "access=no" or "bus=no" is present, meaning busway closed)? |
My two cents on the busway symbology, as being both a transport engineer specialised in public transport and a professional mapmaker myself (also, a long-time OSM contributor, right now mostly to the meta drama because of lack of time): While I really liked the latest pink suggestion, I don't think it's necessary for it to have a whole new colour. It could be the same colour of a highway class on the higher side (such as the orange-ish If I was to choose a specific symbology, it should have a As for the meaning of a busway, as for any other highway, it is fuzzy. There is no way to have a full-fledged definition and most other classes don't have either (even motorways). What is being asked here, some kind of distinct and universal definition, is unreasonable because the definition of a road class is a wicked problem. Road classification for any class is as hard and diverse as it is for busways, because there are many different types of legislation worldwide (or utter lack of). I think classifying roads with the OSM scheme is an easy task only in the UK, because it is based on the British legal system. Nevertheless, one could still infer some loose definition of busways. It is indeed physically and legally the equivalent of I think what I said settles the argument of what busway is supposed to be (it doesn't mean anything, and never will, but at same time it does). But, if this is not enough, which is frustrating because I shouldn't be wasting my time on this, I suggest a makeshift solution: just render any |
I agree that it would make sense for the design to support an Personally I like the 2.5 casing render for guided busway, as this suggests guides, but I wonder whether a guided busway should be narrower than a normal busway. Note that this example connects to the carriageways via short sections tagged I assume that any PR would move guided busways into the main roads layer to avoid this effect: ? |
and others
BRT (Bus Rapid Transit) systems is a form of public transportation that is extremely common in the America's (especially in Latin America). A notable feature of these systems are bus-only roadways. Sometimes, these roadways are refereed to as busways (not to be confused with bus-lanes on public access roads) or fixed guideways (not to be confused with guided busways).
The tagging scheme for this type of roadway is a combination of
highway=service,acces=no, andbus=designated, although a proposal forhighway=buswayis in the draft stage.These roadways are often incredibly important pieces of infrastructure. However, they have extremely low visibility in carto.
The image displays how the busways in the city of Pittsburgh are shown in carto at zoom-level 13.
The following is an image of one of the busways—the East Busway—after a user incorrectly tagged it as a guided busway. The East Busway is the most important piece of transit infrastructure in Pittsburgh (carrying more passengers than the light rail lines), and so this user tagged for the renderer in order to highlight this. Who knows how often this happens?
The following is the official transit map for the city of Pittsburgh. Notice how it depicts the busways with the same level of importance as the light rail lines. Notice how the first image does not reflect this level of importance.
The text was updated successfully, but these errors were encountered: