The current state of map design in OpenStreetMap | Hacker News Reader

The current state of map design in OpenStreetMap

imagico.de

218 pointsaltilunium67 comments

Note that the author of this piece is also directly responsible for blocking the acceptance of many new features in Carto, including community-developed and broadly accepted features like highway=busway:

https://github.com/gravitystorm/openstreetmap-carto/issues/4...

Carto is of course just one style for OpenStreetMap, but it is also the default style shown on openstreetmap.org, with direct support from the operational team (server resources etc.). If a high-profile feature is not rendered by Carto, gaps show up all over the world where people use Carto-based screenshots, etc., and of course on openstreetmap.org.

The stagnation of Carto, and thus openstreetmap.org, the website, is one of the major pain points for many mappers and developers in the OSM community, including myself. (It also highlighted the failure of the OpenStreetMap Foundation to deal with this situation, although the recent move to develop a successor vector style is somewhat hopeful).

Personally, this makes me very hesitant to consider anything Christoph Hormann writes regarding OpenStreetMap in a positive light.

Agree! Outsiders sadly wouldn't have experienced this first-hand. The thing is, PR acceptance criteria aren't even firm. If imagico after a long back-and-forth decides he doesn't like it, then too bad for the prospective contributor.

A similar situation holds with openstreetmap-website. Sadly currently barely anyone uses Rails...

Honestly even reading his prior blog post and this together, his own outline of his position made me feel there was more to it. Like the way I read it, they had a process of open contribution, and then they closed it down, partly at the author's suggestion, and then those contributors who felt the process was too onerous because of pushback against perceived euro-centrism of their contributions went and made their own projects.... which were more succesful for Europe and North America.

Sounds like open source working correctly. If someone doesn’t agree they can always fork the project and aim for their own direction.

Absolutely possible; that's not the problem here.

The deeper problem is that Carto gets a free ride on the website as the incumbent house style. You can fork it, but doesn't make it the default style shown on openstreetmap.org. You could fork it, get popular community support, and still get nowhere except for wasting a lot of effort, because displacing Carto takes a lot of political manoeuvring as well as server resources for hosting the default style (which are not insignificant).

If it was a matter of just forking it, and have the openstreetmap.org website maintainer pick it up if it proved more popular than that would be that, but given the fact that the one other Carto maintainer who seems semi-active is also a member of the OpenStreetMap operations working group (i.e., server resources), spending any effort on a fork with the goal to displace Carto seems pointless at this point in time. I prefer to spend my resources on just making the map better.

Some people justly pick up their crayons and go make a nice thing elsewhere (like the Americana style), or contribute to the styles used by popular apps. For now part of the community just gave up on Carto and is waiting to see how developments for the new vector style will pan out.

And as always, forking might solve a specific issue, but creates so many new ones that it isn't such a clearcut and obvious or even sensible solution.

I wouldn't compare osm-website and osm-carto at all. The commit logs are very different.

openstreetmap-website: https://github.com/openstreetmap/openstreetmap-website/commi... . Numerous commits most days.

openstreetmap-carto: https://github.com/gravitystorm/openstreetmap-carto/commits . So far in 2024; one small regression fixed, one niche bit of tagging added to an existing style, some largely pointless code style tidying. That's it.

Sure, you're right - I haven't checked osm-carto in a while. Nonetheless, the barrier to contributing to osm-website is too high and the maintainers also not welcoming. TomH is infamous for his comments that brush off even OSMF board members. The openstreetmap-website is due for improvements, but the same thing applies - maintainers are very finicky and even worse, one of them is abrasive as hell.

Elsewhere in the comments it was pointed out about hostility to experimentation, the same applies to openstreetmap-website. There are many things that could be tried on the front-end, but in the eyes of TomH you need to be perfect at the first shot, based on his understanding of the situation.

Somebody pointed out that openstreetmap-website contributions pace curiously picked up after the NorthCrab's blogs detailing his unofficial and unsolicited Python rewrite, OpenStreetMap NG. Honestly even if he's somewhat cringe at times, he's still more adaptive than TomH and co. E.g. people pointed out that Mongo is fauxpen source so he duly rewrote the DB part in Postgres.

If you're willing to entertain more leisurely mappers like me (i.e. those unaware of what happens in the community), care to steelman their reasons for the blockade?

I've read (and engaged with) everything in that issue, but I still don't understand the vague 'well the tag is just too loosely defined' argument.

I mean, sure, there is some ambiguity around the exact limit of this tag, i.e., is it only meant for ways dedicated to rapid transit bus routes, or is it for ways dedicated to any bus performing a public transport role? That is a valid question (of the kind which tends to get answered in the OSM project with the passage of time and observing the actual usage of the tag), but, and at the end of the day, ways tagged with highway=busway are undeniably:

a) roads;

b) used by buses;

c) unless otherwise indicated, not accessible to general traffic.

Absolutely refusing to render even a simple line after three and a half years (despite two PRs provided) is hard to explain as anything but antagonistic gatekeeping behaviour.

The arguments in that discussion don't really make sense either. Such lanes exist outside Latin America too. Like the "busbaan" in Almere, Netherlands. Edit: And in Diemen, as pointed out above.

But generally this "process-first" attitude makes me step back as a contributor immediately. I prefer doing something the wrong way and fixing it later instead of not doing it at all.

The same thing totally antagonizes me against Wikipedia editors so I never participate there either.

These lanes also exist in Germany.

Definitely agree. This type of gatekeeping is toxic and ultimately makes us all worse off.

My reading of the situation is that, in general, they want the community to reach consensus on a globally appropriate data model and visual language, ultimately for the purpose of serving all of humanity, fairly. Given the unique position of influence held by this renderer, ad hoc iteration on it without holistic planning risks inadvertently establishing harmful precedent that might take years to correct, or worse, to notice at all if only underrepresented users are impacted.

For the specific case of busways, this holistic planning simply has yet to occur.

> risks inadvertently establishing harmful precedent

What sort of harmful precedents might be established?

Modeling the world in a way that alienates or fails to serve people in specific places or cultures, creating undue technical burden on data consumers, causing pains that discourage mappers from contributing, dividing the already precariously small community, wasting volunteer time on later schema migrations

> causing pains that discourage mappers from contributing

Like not rendering (bus dedicated) roads despite them being tagged as (bus dedicated) roads using a tag approved by the community three and a half years ago. The openstreetmap.org website currently shows gaps all over the world wherever bus dedicated roads exist. This certainly discourages for mappers.

Compare:

Carto (default):

https://www.openstreetmap.org/#map=18/52.32853/5.04991&layer...

Tracestrack Topo:

https://www.openstreetmap.org/#map=18/52.32853/5.04991&layer...

Don’t wait for me to do it; you can steelman too: It’s plausible that the consequences of an actively wrong implementation would be more costly than this delay.

Instead of just throwing costs at each other, you could acknowledge the other party’s and then argue that yours are greater. (I personally would agree with you about this.)

What are the odds, this random example points to only a couple km away from my home.

I had never seen OSM for the area, the detail around Maxis is astounding. And the busway is quite relevant to understand traffic around the area.

"What are the odds, this random example points to only a couple km away from my home."

Probably a rhetorical question, but the odds for you individually were probably low, but the odds that the random example (where random here still means close to major cities) was close to some HN reader were probably quite high ..

I see the same roads in both, one of them has a dashed pattern on top. What is the problem?

In the first one what you’re seeing is just the absence of grass.

As an OSM contributor, the biggest pain for me is working hard to add data to the map only for it to not show up at all or look ugly.

Bus routes? I've read the wiki pages in order to map them. I don't even ride the bus, I just wanted to add the data in. Why put in all that effort when the map won't even show it though?

> Why put in all that effort when the map won't even show it though?

Just select a different layer, the "Transport Map" renders bus routes: https://www.openstreetmap.org/#layers=T

This is a problem with all maps. You cannot show everything, so you reduce it to something you want the map to show. While things like waste baskets, hydrants, dog excrement bag dispensers, etc. Can reasonably show up on deep zoom levels because they're just small icons, I think bus routes can clash with plenty of things that many people would also consider important.

Remember Falsehoods Programmers Believe About Names [1]. The amount of trouble people from across the world have had with tech, because some SWE in Silicon Valley decided that the way their names work is how everyone's names in the world work.

[1] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

I'm very aware of those issues. My full name has four words, it does not fit into first/last name fields. I have to deal with that problem constantly. I'm reminded of it every single time I pay for something with a credit card due to their idiotic first/last name fields. Some of them even have length limits.

This is a non-issue with Open Street Map. Tags are freeform. You can input literally anything into the database. You can have simple tags or ridiculously detailed and nested schemas, and values can be literally any text. You can and should seek community consensus so that a controlled vocabulary can be created and documented, effectively turning it into an API. It's not actually required though. If you have geospatial information and you add it to the map, the map is made richer and more useful than it was before. The map didn't have that data at all and now it does. Doesn't actually matter if the format hasn't been agreed upon yet, it can always be edited later so that it fits into a more regular format. I did a lot of tagging and schema improvements in my city.

Software that consumes the Open Street Map dataset obviously won't render the data it doesn't understand. They should be made to understand more stuff. Software can always be updated to make the most of data. The data has to actually be there to be usable though. The software won't matter at all if the data is missing or if it's garbage.

That sounds a bit far-fetched to be honest. Right now by not rendering them you're impacting everyone, not just some underrepresented users :)

Oh boy, global consensus? That's a big ask.

Why not allow branches of divergence? You'll maintain a higher and increasing level of free help from a bigger base of contributors that way.

There are kind of branches already (other layers have different styles [1]), but this debate is over the default layer style, which appears on first page load of openstreetmap.org

[1]: Transport Map Layer https://www.openstreetmap.org/#map=15/42.3594/-71.1051&layer...

> global consensus?

No, that’s not what I wrote. It’s local consensus on a system that is fit for global use, which means being cautious about what concepts receive special treatment from the renderer.

> not allow branches of divergence

I’m not sure where you got this idea. It’s explicitly licensed under CC0 and GitHub shows 800 forks. This freedom to diverge is one of the arguments in support of being conservative about changes to the common default.

I work full time in web mapping. IMHO the ugly OSM style and its lack of innovation held back adoption of OSM severely for years.

Do you mean the early-2010s era style? Sure that one was quite ugly.

The current style on https://www.openstreetmap.org/ basically looks the same as I remember it in ~2010, and is quite ugly compared to Apple Maps and even new google maps.

Or even something like OrganicMaps which runs on OSM data

No, it does not look the same as in 2010. Your memory is failing you.

That's very subjective, I find the Google style barely usable compared to OSM carto. No experience with Apple.

How did this stop you from deploying your own tile server with your own style?

First, my remark is about the impact on the adoption of OpenStreetMap in general, not my personal usage of it.

And second - it did not stop me from doing that, but it was extremely difficult, and took months of effort. I built a tool to set up a server with all the components required to download the data, load it into PostGIS, style it with Tilemill and generate and serve tiles: https://github.com/stevage/saltymill

So I find your comment quite disingenuous.

Wow. This sort of obstructionism is what convinces people Open Source is not worth the time and effort. Really disappointing. As someone else said in that issue, "perfect is the enemy of good". Thousands of KMs of road are currently not VISIBLE on the map due to stonewalling.

The material difference between this and someone intentionally sabotaging things is in practice, zero.

It's crazy destructive

Is he?

> 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.

Effectively. There are two PRs (one a stand-in minimal solution, another a fully worked out one) which solve this problem; neither has gotten merged or even seriously considered. If you dig around a little the gatekeeping patterns become obvious, and you'll also note a number of other maintainers giving up and resigning. But don't do that; it just makes for depressing reading.

Besides, regardless of what he says there, there isn't even a single thin line on Carto rendered maps to indicate the presence of significant infrastructure where this tag is used. That inaction speaks clearer than his words.

I'm not sure if you read his recent comment (from March) where he explains the reason for blocking the PR.

The reason so far is that there is no consensus on whether highway=busway should replace the additional tags one can add to indicate that a highway street is limited for buses only.

  > However, so far we are pretty far away from highway=busway replacing highway=\* + access=no + bus=yes as the consensus tagging for any and all bus only roads world wide. Hence my suggestion in #4226 (comment) still applies - solving #214, and in context of that think about rendering highway=busway in a way that reflects a distinct meaning (which would likely be in analogy to highway=pedestrian). A possible design approach to this is shown in https://imagico.de/blog/en/rethinking-road-access-restrictions-rendering/

So, no, it's not stagnated because the author wants it. A previous commit from one of the maintainers (jeisenbe) said the issue was closed because no consensus was obtained from the tag proposal, dated 2020:

  > I’m closing this for now because there is still no established way to tag these features. Once either service=busway or highway=busway (or some other tag) becomes established as the clear consensus of most mappers, we can reopen this issue.

https://github.com/gravitystorm/openstreetmap-carto/issues/4...

Ask anyone from the community and this is quite a good reason to block the addition of new features to the map style, especially if they aren't widely used and not standard.

I don’t really want to get into the weeds on this one again but as someone from the community I completely disagree with this characterisation. osm-carto is comatose and largely for reasons like this.

> But it is also visible, that despite Americana being a relatively young and not yet feature complete project by its own goals, it already struggles significantly with the technical limitations of the map rendering framework used and the commercially developed data schema it is built on.

I wonder what goals of Americana the author feels are fallen short? [1]

> The purpose of the Americana project is to:

* Promote collaboration and shared purpose in the American mapping community

* Express the American experience through cartography, taking inspiration from the familiar features of North American paper maps

* Close technology gaps that impede the use of American cartographic principles. Where the technology to build our map doesn't exist, we will build it.

[1]: https://github.com/osm-americana

He's talking about the OpenMapTiles vector tiles schema.

So nice to see OSM still continuing to care about maps after Google abandoned their last remaining pretensions to cartography in favor of the almighty advertising dollar.

AAA maps are very legible. Here are some examples:

https://www.aaa.com/aaa/common/mapgallery/pa/philadelphia.pd...

https://www.aaa.com/aaa/common/mapgallery/ma/bostonandvicini...

https://www.aaa.com/aaa/common/mapgallery/or/portlandandvici...

https://www.aaa.com/aaa/common/mapgallery/dc/washingtondcand...

https://www.aaa.com/aaa/common/mapgallery/ny/newyorkvicinity...

Largely what permits this clarity is that these maps are specialized to one application, in this case highway driving. The OpenStreetMap renderers similarly specialized to e.g. highway driving, public transport, cycling, hiking, etc. also have this benefit.

https://wiki.openstreetmap.org/wiki/OpenStreetMap_Americana comes top mind: See https://zelonewolf.github.io/openstreetmap-americana/

Very nice looking in my american eyes

Nice for driving, but not for walking. Look how much pedestrian info is simply not rendered in my home area. Tons of stairs and walkways are not visible:

https://zelonewolf.github.io/openstreetmap-americana/#map=16... https://www.openstreetmap.org/#map=17/58.97226/5.72803&layer...

It's not a complete style, the early work focused on highway shields that resemble highway signing (a traditional driving map feature which is more difficult than it might sound when you start considering places where many routes are concurrent, or the large number of posted highway systems).

Sure, Americana is car-focused.

Mapy.cz is also OSM based and more focused on pedestrians: https://en.mapy.cz/zakladni?source=osm&id=1056429822&ds=1&x=...

I know this is subjective, but I dislike most of the contemporary map design. Google Map is atrocious, the recent update to the color scheme is even worse. OpenStreetMap is at least information dense, and seems to have somewhat improved, but still doesn't look good to my eyes. Fuzzy text, ugly color palette (even if better than Google Maps). The one I kinda like is mapy.cz which I tend to use for hiking: https://de.mapy.cz/turisticka?x=13.1100771&y=47.1737326&z=16

> penStreetMap is at least information dense, and seems to have somewhat improved, but still doesn't look good to my eyes.

I want to make sure people are aware that there's many different map designs on OpenStreetMap.org, and all of them (for better or worse) are quite aesthetically different from each other. Check out https://www.openstreetmap.org/#map=14/42.3580/-71.0725 and click the "Layers" button on the right to see a list (with previews) of each alternative design.

Also don't forget about apps like OrganicMaps and OsmAnd, which bring their own styles and technology, and, of course, downloadable off-line maps.

For people on Android: get OsmAnd~ from F-Droid instead of Google's app store, and enjoy the unlimited version for free (alternatively: use the freemium version from Google Play, or pay for it).

Yeah I love OSMAnd especially since its new 3D mode. Which is really useful in my area that is far from flat. A normal map doesn't really work here even with contour lines.

Got it for free at first, soon after paid for it. Love how customisable OsmAnd is, most maping programs are very much tailored to drivers, which is not my use case.

but most uses of osm are leaving default scheme, like public transport, embeded maps etc and defaulr osm scheme is bad to say the least

they are not easily available on osmand~

for example, no Americana style.

Interesting read - there's a lot of progress in the open map styling scene and OSM maps with good data can make amazing maps and it has many different features [0].

It's also interesting to make maps directly from raw data (in this case that would be aerial imagery with mostly elevation data). E.g. if you find good training data you can easily make "land-cover" maps and although my example (of Austria) [1] does not have annotations (addresses, etc.), it's still nice to look at and has the benefit of being extremely compressible (compared to aerial raw imagery).

[0] https://wiki.openstreetmap.org/wiki/Map_features [1] https://turmfalke.httpd.app/test.html

One company recently had some incident because their client had no possibility to choose the delivery location. Apparently someone changed the openstreetmaps which they're using on their page, in the way that their customer's street was renamed to some bad words on Andy Townsend

Sorry, I don't buy this. The vandalism only persisted in the rendered map tiles due to CDN caching. Actual map data (which is input to the geocoding) was reverted very quickly by the DWG (moderators).

This is also possibly a violation of Tile Usage Policy, you're not supposed to use OSM infrastructure in volume. OSM data is free, but hosting not so. Either self-host or use other providers.

Yeah, there was a bad bit of vandalism recently. The data was quickly restored though. This is not too different from vandalism on Wikipedia, but instead of facts getting mangled, navigation can be impacted.

Odd that that company hit one of the bits of map which was impacted though; the chance of anyone actually hitting the bad data seems quite small (as in, lottery jackpot winning small).

> the chance of anyone actually hitting the bad data seems quite small (as in, lottery jackpot winning small).

I saw it on a small cycling site that uses OSM's tiles. I was surprised and checked OSM's site for this French back-country and a few random places, and the offensive messages were still there.

Even if the vandalism was purged after a few (dozens of) minutes, I suppose there were more witnesses across this short period than winners of lottery jackpots across this century.

If company runs 24/7 deliveries it's really not hard to hit the vandalized time interval

Reply on news.ycombinator.com