You’re joking, but having a specific “mapper feedback style” separate from any “looks vaguely nice” one is exactly what we need.
20 Likes
One of the remaining osm-carto maintainers has maintained a fork of the project for the past six years. It has some interesting additions and adjustments that are worth a look for anyone who hasn’t seen it before. Occasionally, he leaves the impression that he would like his fork to become mainstream in some capacity. I don’t know whether he would prefer that his changes be upstreamed wholesale into osm-carto or that his fork supplant osm-carto as the Standard layer.
If someone with this level of technical know-how and authority over the project has not managed to mainstream his fork, what hope can an outsider have with their own fork, as a non-expert who taught themselves how to implement a new feature because their community needed it so badly? Non-experts see “PRs welcome” and don’t realize they’re in competition with a maintainer. Not everyone wants to participate in office politics.
13 Likes
It’s also taking energy away just trying to contribute to the style itself.
7 Likes
I wrote to all e-mail addresses listed in the OSM Foundation contact page.
For whoever suggested to set up a fork of OSM Carto: This is like suggesting to run your own bus route or fix potholes yourself if your city does not have a good transport infrastructure. It is not in the least reasonable, to say the least. We already contribute by mapping, despite we have zero duty for that. Remember, the OSM Foundation gets money from our work (mappers) by literally placing a banner over it. The least they can do is to pay somebody to properly maintain the infrastructure that runs the web site, which includes the map tiles.
8 Likes
Note that amount of money that OSMF is getting right now is not enough to pay for maintaining all related software (or even critical part of it). So it relies, by design, on volunteer development. Which is done by people doing it on their own, with own priorities and preferences.
And OSMF is already paying for some of maintenance, and fundraising is needed to keep doing that.
(and it is not like money is being spend on things like for example OSMF board salary, noone there is getting paid for that, that is really time-consuming hobby)
(I will respond to other comments where it will be useful, especially #16, once I have time to do that)
8 Likes
The funny is, commercial co’s like Komoot use the OSM data (and I know because they specifically pointed me here to correct a few ways on their map), then if you want the access to the hiking map render you have to pay them 59.99 Euro annually plus buy maps ‘per (Italian) region’. The ‘for free’ data is a little too free. Maybe these data consumers could be approached for a little sponsoring.
7 Likes
As much as I appreciate the idea, this should be raised in the OSMF forum page / mailing list and seems out of scope for this topic.
5 Likes
I think you are underestimating just how ripe the situation for a sufficiently motivated community organizer to provide a viable alternative to osm-carto that the OSMF could designate as a replacement. You are also overestimating what is required. You don’t need to set up a rendering pipeline, you just need to have a viable alternative software implementation and team of maintainers that the OSMF/OWG could choose to switch the standard tile layer to.
Richard has absolutely hit the nail on the head - osm-carto is no longer a cooperative community project where decisions are made through consensus but rather one under the control of a single decision-maker. The fact that the single decision-maker thinks the reverse is true is a shocking contrast to the diverse list of major project contributors that seem to agree with Richard (based on his comment’s reactions list).
In the last year or so we’ve seen two osm-carto maintainers quit outright. Another maintainer in this thread, who we all owe a debt of gratitude for his work on the project, is practically single-handedly keeping the project afloat technically despite lamenting that he no longer finds joy in the role. The repository owner rarely interacts with the project anymore. The switch to the flex back-end, which saw a talk at State of the Map US this summer, is effectively dead due to lack of maintainer support. This blocks technical advances such as support for route relations and thus highway shields.
I agree that osm-carto is built on a technology stack that is effectively obsolete in 2023, and anyone starting a new map project should probably work off a vector stack. Now that it’s possible to run a planet-scale vector tile server for pennies, it would be imprudent for a community project to choose a raster stack without a strong technical reason.
I’m not terribly interested in organizing a team to manage a global style, since I’ve been focusing my efforts on enabling the amazing team we have working on the Americana style. Open-source American-flavored cartography is way behind other global and regional styles and it’s important to my national mapping community that we have an outlet for expressing distinctly American concepts on the map. However, I recognize that there are people that care deeply about the map that appears by default on OpenStreetMap’s web presence and I’d like to point out that they have a path to make things better.
osm-carto has one distinct advantage that makes it ripe to fork and continue advancing as the face of OpenStreetMap: it’s basically complete. So if you, or a sufficiently motivated group, were to come together with the goal and vision of having a standard tile layer that represents the whole community rather than the whims of a single maintainer, here’s your recipe:
- You make a fork of osm-carto, and preferably stick it in an organization space so it’s not under one maintainer’s personal github space. (This was a mistake I made in starting Americana; we are just now working to migrate to an organization space).
- You build a team and clearly define the values and purpose of your osm-carto alternative in order to address the social and organizational problems that have so clearly plagued the original project.
- At first, you keep the fork “tight” and to the extent possible merge in upstream changes. This way you’re only having to manage the differences between the core project and community expectations. So at first it’s something like “osm-carto plus busways and shrubbery” or whatever set of features people think are hung up.
- You petition the foundation to use your software as the standard tile layer. In other words, you don’t need to set up a new build pipeline, you just position your flavor to be shovel-ready as the style for use in the pipeline that already exists. It’s likely a one-line change in the existing scripts that deploy osm-carto to osm.org.
The “tight fork” approach I’ve outlined avoids having to build a style from scratch and also doesn’t require you to set up your own rendering pipeline. It’s an social and organizational problem, not a technical one.
20 Likes
First off, credit where it’s due: I appreciate @imagico’s prompt response to my concerns about his fork. In case anyone is wondering, he isn’t participating here because of a disagreement about how the forum is run, which is his prerogative; everyone has the right to choose which communities they participate in. That said, having seen a fair number of OSM Carto enhancement requests end in a stalemate, I share this sense of cognitive dissonance:
A true open-source project is indeed a community. Fostering and sustaining a community requires people skills like empathy, humility, and pragmatism, coupled with a shared vision. All the technical and artistic excellence in the world cannot salvage a community that lacks these qualities.
Sometimes it’s as simple as expressing concerns using the “Comment” option, instead of the “Request changes” option that acts as a senatorial hold on the proposal, in order to give other maintainers the space to disagree. Other times, maintainers hold a well-justified view that contradicts the prevailing outsider view, and it’s up to the maintainers to proactively promote their viewpoint before the wider community, speaking with one voice.
Like probably every other open-source maintainer participating in this thread, I’ve struggled to hone these important skills and put them into practice over the years. The hardest – and best – piece of advice I ever received was that I needed to let go a bit and let others make mistakes and learn from them. A maintainer influences the product not only through direct contributions but also by setting the right environment, laying out a path for others to contribute code of high quality, either spontaneously or with some handholding. This requires sacrificing time, energy, and pride. That’s a lot to ask for in a person, but fortunately there are good role models in the OSM community to look up to.
You know, it’s funny how a feature request like that can really take off. OSM Americana owes its existence in large part to the difficulty of overcoming skepticism about a feature that, on its face, seemed like it would look ugly and only benefit one part of the world. We could have forked OSM Carto, but instead we took a more experimental approach with an unabashedly regional artistic vision.
That vision is hilariously incomplete, but it has brought together a community of varied interests and backgrounds to cook a mean stone soup while having some fun. What we initially thought of as a regional need turned out to have global relevance. The expressions of appreciation from mappers and map users around the world has been very gratifying and validating for this very small, very nascent project. Maybe this is a little bit of the joy that OSM Carto contributors miss.
6 Likes
So, given this perpetuated situation since at least when I started mapping actively in 2020, noting large swats of landscape not showing though mapped and wiki supported, what is a good and readily available selection for JOSM? Preferably one that has a high tile refresh rate as now when I set Carto standard to see what has not been mapped often get a blank when the day before area parts of what’s viewed was mapped ending up with double mappings at times (my fault not refetching the data).
If there’s a link that I can add per that “new default entries can be added in the wiki” which I read as “add to wiki and it will show up here too.” Little doubt if there were they’ve already been, but who knows.
MTIA
/OT
That basically means choosing between a “mapper feedback” style and a “nice-looking general style”. OSM Carto tries to do both and doesn’t succeed; whichever purpose this new style chooses still leaves the other lacking.
5 Likes
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?