This could promote tagging for the renderer though. In essence, an unintended side effect might be that mappers use “incorrect” tags simply because they are supported by a particular renderer (in this case Carto) whereas the “correct” tags are not.
Edit: it’s also worth noting that the info button shows the wiki link to the tag. Normally on that page there’ll be useful documentation, the status of the tag, as well as the number of times the tag has been used. Which is perhaps more important than whether some renderer has chosen to show it on their map.
Perhaps - although that information for some styles is only a few clicks away. From iD the link in the info takes you to the wiki. There’s a link there to taginfo, and projects lists the projects that support it and advertise the fact.
Unfortunately “OSM Carto” isn’t one of the projects that lists the tags used in that way. See issues here (closed in 2017) and here (closed as completed because “too hard” in 2022), so your point about “how do we know what tags OSM Carto uses” is very much still valid.
I think to be honest,
in general, most editors will have an understanding that there are various different renderers, with various different mapping intentions and emphases, and so not every tag is rendered on every map - and as you point out, more info about that is readily found on the OSM wiki for those who are interested.
We should not let that distract us from this particular specific gripe about Carto and busways
Like most renderers, Carto ‘shows all the roads’ so it just looks weird when busways are mysteriously left out. It was a reasonable request to ask for this to be fixed.
Speaking as an ex-Board member here. The Board has consistently taken the policy position that the Foundation should seek to ensure an open-source pathway for entering and doing QC on data for the geospatial database (supporting iD, for example, as well as Nominatim and Potlatch) but should leave map rendering to the doocracy and commercial ecosystem. That is why appealing to the OSMF Board of Directors for funding to generate an actual map – a downstream visual rendering of the data – is likely to fall on deaf ears.
Discussions of the OpenStreetMap Foundation’s role have often turned to discussing what is core. To build its strategy on firm ground, the Board has sought to improve that definition and offers the following:
The core is the mapping process.
That is a new way to define core, functionally rather than technically.
So, we now have two complementary definitions:
Technical core: rock bottom, without which OpenStreetMap disappears. Mostly the database and its API.
Functional Core: The Mapping Process.
Part of the OpenStreetMap Foundation’s mission is to ensure that there is at least one fully Free and Open Source Software path to complete the OpenStreetMap mapping process. Decisions about what software to support will follow directly from this.
If the board wishes to reconfirm this standpoint every time someone brings this up (or if former board members like @amapanda_ᚐᚋᚐᚅᚇᚐ and you wish to defensively point out that everyone can just fix it themselves), and conclude that leaving gaps and bugs on the default layer shown on openstreetmap.org is totally acceptable, than that is their prerogative.
It won’t stop people asking why this cannot be fixed, and it won’t make the issue magically go away. It also won’t stop issues like this from harming the project; something I would hope does fall within the scope of what the OSMF is willing to deal with, or at least quantify as a risk.
Something is broken here, and it is not just the lack of highway=busway rendering. Regardless of whether it is a process, governance, or some other factor, it highlights an issue that cannot be reasonable expected to be fixed by any one contributor.
OK - imagine for a second that you were appointed “OpenStreetMap Standard Layer Czar”. After highway=busway, what else should be shown? Is it literally any key/value combination in OSM data? Some lesser combination that “makes sense”?
If you sort taginfo’s projects list by keys or values you’ll see that the number of keys/values potentially used by editors is substantially more than the number used by almost any renderer. Someone has to draw a line somewhere - where would you draw it?
That is something which ideally would be decided in a sensible manner by the maintainers of that layer, according to the guiding principles of that style. If some tag doesn’t fit the design goals, or doesn’t work after giving it a go in a development version, than it is fine to conclude that it doesn’t quite work on that layer. Preferably this would be concluded with a minimum of fuss and a good deal of understanding from the people contributing to the discussion.
Do you think that is what is currently happening? Should the default layer show empty stretches of ground where kilometres of dedicated busways sit?
The default layer on openstreetmap.org invokes clear expectations of a general purpose layer with a large focus on mapper feedback (as long as the latter aligns with providing a general purpose layer with decent cartography). Omitting highway=busway in no way contributes to those goals, or even the stated goals of Carto.
And again, this issue highlights a problem which is not about highway=busway. That is just a symptom.
If you sort taginfo’s projects list by keys or values you’ll see that the number of keys/values potentially used by editors is substantially more than the number used by almost any renderer. Someone has to draw a line somewhere - where would you draw it?
so no new tags should be added to the style because there are already so many? Is there a threshold for highway key values that could be quantified (easiest is to count elements but more interesting for linear features is maybe length, and also how much of the total of the feature(hard to estimate) is tagged like this)? I think we all agree that roads tagged with a highway value that doesn’t show up is a problem? So when is this difference big enough to change from tagging problem to rendering problem?
I suspect that (some of) the maintainers of that style believe that they are doing that already, and a number of people outside of those maintainers don’t believe that that interpretation matches what “most people in OSM” want (hence this thread).
However, you haven’t said where you would draw the line. “Obviously” we’d want to show busways, but what about foot access tags, bicycle access tags, horse access tags (etc. etc. - you get the idea). Should those be shown - and if so how?
OSM Carto is a very comprehensive map style, more than most. This creates a user expectation, fair or not, that anything notable is depicted on the map. Other styles don’t necessarily have this problem because they omit more; taking a firmer stand avoids slippery slope arguments. Often, mappers have cared so much about a busway that they’ve also micromapped its surroundings, including landcover. OSM Carto dutifully renders all these less remarkable features, resulting in what can only be described as a negative-space treatment of busways. To anyone who isn’t deeply familiar with OSM tagging or politics, it simply looks like a bug rather than an intentional omission.
As with any graphic designer, a cartographer often looks to precedent to ensure that a new treatment will be intuitive to a reader, especially one who hasn’t bothered to consult the map legend. This method is of limited use when it comes to more modern innovations that historically haven’t appeared on maps. Busways might fall into that category due to a combination of factors:
Bus rapid transit only came into prominence in the late 20th century.
Maps that balance car culture with public transportation are somewhat rarer.
BRT lines are especially prominent in “Global South” countries whose transportation systems are less visible to established mapmakers.
Considering these factors, it’s especially ironic that OSM Americana added busways earlier this year. Our process leans heavily on older American print maps, of which very few depicted busways, and only ever as a one-off exception with an explanatory note. Nevertheless, we were open to adding busways, because the style isn’t a time capsule. Unfortunately, OSM Carto probably wouldn’t be keen to adopt the same treatment, due to its more comprehensive existing usage of the color spectrum. (Americana’s avoidance of European-style color-coded road classifications was partly a strategic decision to free up colors for other uses.)
OSM Carto isn’t immune to the challenge of maintaining development velocity as the project matures. The codebase is burdened by technical debt and the cartography has mostly run its course due to earlier design choices, though a lot of work has gone into mitigating both issues (such as the flex backend). Any fork or future successor project with similar ambitions ought to learn lessons from OSM Carto in terms of defining a sustainable scope and leaving the door open to periodic wholesale refactoring of color usage. (Proprietary maps refresh their color palettes regularly. It isn’t just a gimmick, though it does require some care.)
I think it should be possible to manage these challenges and set the right expectations without leaving a bad taste in the mouths of well-meaning contributors. If there is a role for an organization like the OSMF, it might be to support the community relations needs of software projects, not only around dramatic disputes but also around more mundane affairs, such as bug triage and keeping maintainers informed of current events in the community. However, it would be messy to impose that kind of support on autonomously run projects.
One further effect is that some people have worked round the deficiencies in osm-carto by tagging for the renderer. Taking two cities where there are conferences next month and using the CyclOSM layer, comparing with the previous example, we have Muiden (highway=busway), Curitiba (highway=service with a descriptive name) and Auckland (highway=tertiary). The difference is more pronounced in the humanitarian layer because it deemphasises busways.
Well, the fact is that the Board doesn’t tell mappers what to map, or working groups what to do. There is a concept called “doocracy” that has run OSM for almost two decades now, and the Board has limited the scope of its remit for some good reasons. First, the Board also consists of volunteers with limited time to devote to OSM, so it tends to stick to really, really high-priority issues that require the Board’s attention. What is shown on OSM Carto doesn’t make the cut (fund-raising to keep things working reliably is a higher priority). Second, the doocracy actually does a pretty good job of building useful stuff for the project, with occasional interventions from deep-pocketed third parties (creation of iD, RapID, for example) or the Board (ongoing support of iD by OSMF, grants for improvements to Nominatim, for example). So hammering the Board (or ex-Board members) for not attending to something that a particular individual deems a high priority is, to put it mildly, a failure to consider the limits of time the Board has to devote to everything everybody in the OSM space thinks should be done, and a failure to recognize the limits of financial wherewithal the Board has available to pay for things to be done.
Improvement to OSM Carto never came up during the outreach I did between January and April 2020 after I was elected to the Board. It was never raised as a priority by anyone, and is mentioned in a total of three freeform comments in the OSM community survey conducted in 2021. Perhaps it is broken, but it is not a high priority to the Board, which means that the doocracy, i.e., volunteers like you, will likely have to tackle it.
Do-ocracy would be “if somebody implements highway=busway support, we will include it”. At least 2 people implemented it (see OP) and they did not include it.
Even default JOSM editing style is not showing all such labels.
EDIT: note that I am pointing problem with rule relying on pure tag use counts (yes, this was considered by OSM Carto maintainers and does not really work, that is just an example of problems). Yes, highway=busway is more reasonable to render than this tags. Despite being use less.
I am not claiming that rendering highway=busway is as reasonable as rendering GeoBaseNHN:VALDATE
Someone stepped onto me hobby horse for which there’s no sock large enough… natural=fell at 28199 uses today, all white as snow In recent discussion with a fell living mapper here, if at all a substitute for painting it, use heath or maybe a darker/lighter variation but fill it. Large swaths of white space on the map. It ain’t hard, landuse=grass, meadow, natural=grassland are already indistinguishable.
A highway=busway is a specific road type, approved and in use. Not just an access tag.
Even if a renderer doesn’t like this main tag and doesn’t want to do special rendering for busways, it’s still a road and map users will expect it to be rendered.
13 Likes
Mammi71
(One feature, Six mappers and still More ways to map it)
63
Even though I do not understand the difference between busway and vehicle=no with bus=yes I would like to agree with this aspect. It would be the least and okay if busway would be rendered at least somehow as a physically existing road, e.g. in the same way as highway=service. Even if you can’t distinguish between busway and service on the rendered map. You can’t distinguish between residential and unclassified in carto-style either.
