Is www.openstreetmap.org a mirror for contributors or a showcase for the benefit of the rest of the world?
2 Likes
I noticed that a ‘busway’ I tagged recently completely failed to render in the default OSM view (that’s Carto, right?)
The only reason chose the tag was because it seemed by far the most appropriate one on offer in the drop-down menus in the default OSM browser editor (that’s ID, right?)
Regardless of all the issues stated above (I confess I scrolled through most without reading), it’s stoopid to offer default tags which don’t render by default 
Either support the tag, or don’t offer it for people to use.
If this situation happened for lots of tags, it would badly damage the usefulness of the map.
7 Likes
Of the 6 map styles at OpenStreetMAp.org, it does render in Cyclosm and the Humanitarian style. It also renders in this style (disclaimer - mine) that I use as a general-purpose replacement for OSM Carto.
Actually, at least 9 different map styles explicitly handle that tag, and that doesn’t include those projects that haven’t advertised what tags they use.
4 Likes
That’s all very well, but (whilst I don’t have access to any kinda of analytics data for OSM websites),
would bet £5 that over 95% of users only ever look at the default OSM map style.
When people go to a website that don’t expect it to be broken by default and only work if you click on extra options.
8 Likes
Actually, I’d have thought that the “most popular rendering of OSM data” these days is one of Apple, Bing, Mapbox, Meta/Facebook/Instagram or Snap.
3 Likes
There are different kinds of mapper feedback. Sometimes mappers want the instant gratification of knowing they successfully added something to the database. A rough-around-the-edges style like Osmarender or a raw debugging style like the OpenMapTiles inspector can easily satisfy this need with negligible consideration given to design. Other times, the mapper wants to know that their mapping is making it all the way to a realistic, consumer-facing map. This is where the craft of visual design matters most, but also where there should be the widest range of options to choose from.
Sometimes the mapper just needs to know they haven’t horribly broken the map, and either will do. The other day, someone broke one of the Great Lakes. (It happens all the time.) If OSM Carto would’ve rerendered at low zoom levels in a timely fashion, the mapper could’ve more quickly seen their mistake. Fortunately, another astute mapper found and fixed the error within a couple hours, but not before it made it into fast-updating data consumers like OSM Americana and Wikimedia Maps:
Thanks to a new shoestring rendering server, OSM Americana fixed itself later that day, but artifacts remained on Wikimedia Maps for several days (even after clearing the local cache):
Americana is happy to serve as an end-to-end test for OSM data, but as any software developer knows, this kind of testing is a last resort. Something that makes it to this stage has a larger blast radius: OSM has long been the butt of jokes among Wikipedia’s editors and readers because we occasionally pull the drain plug on one of the Great Lakes.
Americana’s maintainers do consider mapper feedback to be a goal, but at a higher level than quality control. Would rendering a particular tag support the community’s stated desire to see some feature or attribute depicted on a transportation map? If the tagging scheme or tile schema doesn’t facilitate a treatment that’s reasonably consistent with our artistic direction, we collaborate with the local mapping community on a solution, or at least we document what we see as actionable requirements, so that someone else can come up with a solution upstream. If we consider something out of scope for the project, at least we’ve tried to make it easier to someone to stand up their own viable fork.
Americana is not the only data consumer that operates at this level. StreetComplete is another great example of a project that deeply cares about its relationship with the OSM community, and there are plenty more at the local level.
Feedback means little unless it’s part of a feedback loop in which users and mappers also have some influence over the state of affairs. Many of us were drawn to OpenStreetMap because we felt that proprietary mapping platforms were unresponsive to our feedback and even less responsive to our ideas that didn’t fit inside their feedback forms. It’s wonderful that OSM Carto can more or less provide mapper feedback at the level of raw data (new road opened!), but this thread exposes the perception that this feedback loop has become dysfunctional at the editorial level.
14 Likes
Well this may be not wrong.
And if there were a bunch of tags which are on the ID autocomplete choices, and which don’t render in them, I’d strongly argue that ought to be fixed too 
So are you suggesting that:
- iD doesn’t offer tag presets for things that don’t appear in all or most popular maps
or
- those popular maps should render everything in iD’s presets?
The second of those is problematical because many popular maps are thematic (transport, cycling, roads for cars, etc.) and it really doesn’t make sense to show things that don’t fit that theme - a road map only shows enough non-road detail so that the user has a bit of context; to show more would clutter the map and make it less good as a road map.
The first of those is equally problematic because it means that the wealth of detail that differentiates OSM from other maps simply couldn’t be entered with iD, and the thematic maps that use that dtaa would be much poorer as a result.
6 Likes
Hmmm…
Yes I take your general point.
(Although I don’t think it has much practical bearing on the ‘busway’ tag in Carto, tbh) -
Maybe in general, the iD editor could offer some kind of indication of tag support? There’s an ‘info’ button with a line or two of helpful into for the majority of tags, maybe something could be made to display there?
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.
1 Like
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.
1 Like
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.
13 Likes
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.
https://wiki.osmfoundation.org/wiki/Strategic_Plan_Outline#The_Foundation_at_OpenStreetMap’s_core
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.
4 Likes
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.
17 Likes
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?
3 Likes
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.
5 Likes
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?
4 Likes
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?
4 Likes
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.
4 Likes
Put it that way, yes, but maybe an offer could be made to help in some way, especially in light of decreasing maintainers motivation.
2 Likes