The simpler, the better

Las_Wolski · 2025-09-16T20:55:09.714Z

Minh_Nguyen:

nor are we anywhere near rivaling the map that Borges brought us.

Really enjoyed the article “There Is No Perfect Map” (with the Borges reference). Thanks!
It’s worth remembering that in Borges’s story, the attempt to create a perfect map ended in failure.

But if we do talk about a “perfect” map, I’d argue: it has to be up to date. A map full of tiny details from 10 years ago but missing new roads and buildings isn’t “perfect.”

It’s like software: development is one thing, but maintenance is just as important. Maybe that’s why it’s better not to go overboard on tiny details.

Peter_Elderson · 2025-09-16T21:08:18.467Z

Lumikeiju:

I simply add another way, using the same nodes as the barrier=kerb way, and add the appropriate tags.

Two circular ways using exactly the same nodes? That is a big no for me! Using a MP relation for an area is just basic mapping. In this case the kerb actually is the perimeter of the central island, so it’s correct to use it as the outer of the area.

UW_Amy_Bordenave · 2025-09-16T21:20:33.110Z

SimonPoole:

we currently have no applications that utilize a) highway areas in general (though there is some hope there), b) separately mapped sidewalks in a consistent fashion.

AccessMap does both!

For example: if one were visiting Washington, DC and used AccessMap to head to lunch at Georgia Brown’s after touring the Renwick Gallery, their route will include passing through Lafayette Square’s highway=pedestrian+area=yes multipolygon:

ScreenshotAccessMap Area Routing - 011920×1083 140 KB

This is, of course, a cherry-picked example - but I hope it is illustrative of the use of this type of data that is already deployed in a production application.

I’ll get AccessMap’s consumed OSM tags into a Taginfo project file! [Edit: Done!]

Peter_Elderson · 2025-09-16T21:26:48.782Z

UW_Amy_Bordenave:

their route will include passing through Lafayette Square’s highway=pedestrian+area=yes multipolygon:

Doesn’t the route follow the mapped footways?

Minh_Nguyen · 2025-09-16T21:54:31.547Z

Hungerburg:

I started a poll in the local category: All of the local community voted “this makes my stomach ache, who will groom that?” The mapper complained, why should the local community have a saying in this? A number of non-local members support that stance: After all, this will add lots of detail to the “map” and perhaps, it will entice new mappers to contribute, to make their neighbourhood look just as pretty on the “map”.

I guess this is frustrating to you. Someone from afar is telling the locals they need to maintain extra detail that they don’t want to maintain. Now consider the converse proposition: what if someone from afar tells me, a local, that I shouldn’t map what I want to map and am prepared to maintain?

I started mapping my hometown’s buildings back when the rule was to only map “significant” buildings. (That’s what the map legend still says to this day.) I guess the idea was to keep the editing experience lightweight and easy. There were difficult Wikipedia-style debates about which buildings were notable enough to map, which I avoided by mapping ordinary buildings indiscriminately.

These were very messy buildings because Potlatch 1 didn’t have a corner-squaring function. Yahoo! Aerial Imagery was so grainy at zoom level 17 that I often mistook three buildings for one or vice versa. Yet the building coverage attracted two more local mappers who began mapping POIs, landcover, and well-hidden public staircases that I would never have been able to map on my own. It was a big deal at a time when the nearest mapper had been hundreds of miles away from me.

Eventually, though, the buildings and landcover made the map look so complete that it started to stagnate a bit. Even after moving away, I was the one left updating the map whenever something big changed, like a new bridge or park. On a lark one day, I added some sidewalks and utility lines, things that not every renderer or router cares about. It didn’t take long for mappers to come and extend those sidewalks and utility lines – and tag roof shapes and street surfaces and more. They also helped me clean up the messy buildings. With all this help from others, I no longer feel like OSM will go stale because I’m unable to keep up with local news in my former hometown.

Las_Wolski:

It’s like software: development is one thing, but maintenance is just as important. Maybe that’s why it’s better not to go overboard on tiny details.

As a global community or as leaders of local mapper communities, we can be strategic about what kind of mapping we want to encourage. But this is very different than discouraging an entire category of mapping, dismissing it out of hand without a viable alternative, on the basis of personal inconvenience. If the features are factually correct and consistent with OSM’s purpose, this should be a discussion about how to better accommodate the features.

Peter_Elderson:

Two circular ways using exactly the same nodes? That is a big no for me! Using a MP relation for an area is just basic mapping. In this case the kerb actually is the perimeter of the central island, so it’s correct to use it as the outer of the area.

Is it basic mapping, or mapping for the editor? Specifically, optimizing for the workflows available in JOSM at the expense of iD and, yes, mobile editors. On this point, I do agree with @Las_Wolski: the simpler the better.

Fenced landuse? Tagging help & support

In my opinion, this is more indirection than necessary. While it’s great that folks here are taking the time to explain multipolygon semantics, the fact is that new mappers often make their first edits around schools, parks, and playgrounds. Creative uses of relations are likely to confuse these mappers, who are more likely to make a mess of them. Moreover, considering the schoolground to be coextensive with the fence is often just a crude approximation. If you come back later and realize ther…

UW_Amy_Bordenave · 2025-09-16T22:55:02.748Z

No – AccessMap is routing over the area here, not the centerline ways. You can see that the path AccessMap generates through the area is created based on the edges of the multipolygon’s members, and I’ve layered on top the also-in-OSM centerline ways:

upload1329×882 139 KB

ezekielf · 2025-09-17T01:58:27.510Z

Peter_Elderson:

Two circular ways using exactly the same nodes? That is a big no for me! Using a MP relation for an area is just basic mapping.

While I agree it is fairly basic mapping, two objects sharing the same geometry is a bit of a confusing and hard to deal with situation for an inexperienced mapper. This is true whether modeled as two coincident ways or as one way and one multi-polygon relation. Which one is harder to deal with depends on the mapper and the editor they are using. I’d be happy to see editor improvements for dealing with both. I do try to reserve multi-polygons for situations that truly require multiple ways though. Something about a single way multi-polygon just doesn’t quite live up to the name.

SimonPoole · 2025-09-17T05:35:29.978Z

UW_Amy_Bordenave:

This is, of course, a cherry-picked example

We’ve had “in principle” working area routing for OSM data for a good decade, and it is slowly (as in with glacial speed) finding itself as functionality in to some routing engines, mobile apps less so. That’s the background for the (though there is some hope there), but we are a long way away from it being a standard feature supported globally for all appropriate OSM features that would allow us to do away with centerline ways.

As to sidewalk routing, you don’t seem to be doing anything special, it seems just as broken as with every other routing engine, see the mastodon thread I linked to (yes I tested outside of the US to avoid illegal jaywalking comments :-)).

Mateusz_Konieczny · 2025-09-17T06:26:30.038Z

Minh_Nguyen:

I started mapping my hometown’s buildings back when the rule was to only map “significant” buildings. (That’s what the map legend still says to this day.)

github.com/openstreetmap/openstreetmap-website

we are mapping not only significant buildings

master ← matkoniecz:patch-1

opened 06:26AM - 17 Sep 25 UTC

matkoniecz

+1 -1

### Description fixed legend - we are mapping not only significant buildings … triggered by https://community.openstreetmap.org/t/the-simpler-the-better/135578/29 ### How has this been tested? untested change, but hopefully text-only change is trivial enough

Peter_Elderson · 2025-09-17T08:45:02.660Z

Minh_Nguyen:

Is it basic mapping, or mapping for the editor? Specifically, optimizing for the workflows available in JOSM at the expense of iD and, yes, mobile editors

It’s basic mapping. MP’s are not defined or created for JOSM. If an editor can’t handle the simplest areas with an MP, in a way that is clear to the user, it’s flawed and should be improved. MP areas are all around, and a mapper who is not aware of that fact must be made aware by the editor tool.

I’m not talking about monster MP’s here, with multiple outers and inners, disjoint outers, inners outside the outers, that kind of sh(beep)t; just simple areas.

On the other hand, closed ways using exactly the same nodes present a complication in all editors, because one of them is always hidden. A starting mapper is guaranteed to miss that.

Minh_Nguyen · 2025-09-17T14:42:00.807Z

Peter_Elderson:

It’s basic mapping. MP’s are not defined or created for JOSM. If an editor can’t handle the simplest areas with an MP, in a way that is clear to the user, it’s flawed and should be improved. MP areas are all around, and a mapper who is not aware of that fact must be made aware by the editor tool.

Sure, every editor exposes multipolygons, even making them look like normal areas. But if the mapper needs to manipulate it further, they need to understand this abstract concept. For laypeople, it’s easy enough to understand that a multipolygon is an area with a hole in it. Beyond that, the style of mapping popularized by the Relation Toolbox plugin – converting ordinary areas into multipolygons whenever they touch – gets in most mappers’ way, for the relatively arcane purpose of preventing area way segments from overlapping. Every editor newer than Potlatch 1 offers the ability to select areas that share way segments or a way that runs along the perimeter of an area.

SomeoneElse · 2025-09-17T17:04:03.505Z

Minh_Nguyen:

Every editor newer than Potlatch 1 offers the ability to select areas that share way segments or a way that runs along the perimeter of an area.

What’d be extra helpful would be to link to documentation that actually explains what buttons to press in what order to achieve this, in the two most common editors**. A quick search for JOSM finds this which links to this which doesn’t answer the question as it doesn’t contain the word “shared” anywhere. Similarly for iD a search finds this which doesn’t work. Neither JOSM nor iD have searchable help within the application.

** Potlatch is easy - it’s ‘click on the node and then press “/” to cycle through the ways’.

Minh_Nguyen · 2025-09-17T17:55:01.055Z

SomeoneElse:

What’d be extra helpful would be to link to documentation that actually explains what buttons to press in what order to achieve this, in the two most common editors**.

In the case we’re discussing, a circular barrier=kerb way is a member of a single-member type=multipolygon area:highway=central_island relation. In iD, you can click the curb to select it, or you can click the shaded fringe inside to select the multipolygon.^[1] So far, so good. But for some hidden reason, iD won’t let you circularize the central island, only the curb. If you want to duplicate the central island to map a nearby roundabout, you can’t copy it by itself; the curb always comes along with it.

Now if it turns out that there isn’t a curb here, just a change in surface, then a layperson would intuitively expect to delete the curb. They can’t, because it’s a member of a multipolygon. By this point, at most they’ve learned from the help documentation that a multipolygon is “for example a building with a hole in it”. Nothing explains that it could also be a workaround for the lack of an intuitive affordance for selecting overlapping geometries, which would be kind of embarrassing.

If instead the area:highway=central_island were an area completely connected to the curb, then you’d still be able to click on the curb to select it, or the shaded fringe inside to select the central island. You’d also be able to interact with the central island independently of the curb.

As it happens, the central island isn’t completely paved over. It’s just a truck apron surrounding a patch of shrubbery. So you’d select the central island (whether it’s an area or a multipolygon) and the shrubbery area and press C (for “combine”) to punch a hole in the central island. The result is a multipolygon. All the same caveats apply, but there’s a good reason for this added complexity.

SomeoneElse:

Similarly for iD a search finds this which doesn’t work.

Ctrl↑ (⌘↑ on macOS) is for selecting all the ways connected to a selected node, similar to the W shortcut in Potlatch. As far as I know, it does work, but if not, file a bug report with more details. iD also supports \ for cycling through the ways connected to the selected node, similar to / in Potlatch, but only for the purpose of navigating among the vertices. These shortcuts are listed in the Keyboard Shortcuts pane, accessible from the Help panel or by pressing ?. There’s more room for improvement in this interface, but the primary difficulty at this point is coincident lines, not lines coincident with areas.

If you don’t see this fringe, check your Style Options in the Map Data pane or press W to turn off wireframe mode. ↩︎

Peter_Elderson · 2025-09-17T18:02:42.006Z

JOSM cycles through the objects with alt-click.

Middle mousebutton shows the objects with tags, then cycles through them.

Middle mouse button then control + middle button lets you choose from the list.

I only use alt-click.

Peter_Elderson · 2025-09-17T18:12:57.116Z

UW_Amy_Bordenave:

AccessMap is routing over the area here, not the centerline ways.

Nice. But… why? As long as the ways are there, isn’t it easier to use those?

SomeoneElse · 2025-09-17T18:14:47.231Z

Minh_Nguyen:

Ctrl↑ (⌘↑ on macOS) is for selecting all the ways connected to a selected node

(That ^^ isn’t clear on screen but is “control uparrow” for info)

That’s not what I’m trying to do - I’m trying to select one of the ways that connect at a node to edit it. Here is an example on the dev server. I can select the node, select both ways, but now what? How do I know which one is which?

Minh_Nguyen · 2025-09-17T18:52:53.531Z

Peter_Elderson:

UW_Amy_Bordenave:

AccessMap is routing over the area here, not the centerline ways.

Nice. But… why? As long as the ways are there, isn’t it easier to use those?

So Lafayette Square’s footpaths are mapped as a very complex highway=pedestrian area=yes multipolygon with linear highway=footway ways running through it. Based on the results of this straw poll, this multipolygon should probably be area:highway=footway instead, so that even a sophisticated router like AccessMap would follow the footways (and incidentally provide a more discrete level of guidance instructions).

In principle, if a router is able to compute a visibility graph over a true pedestrian plaza, it doesn’t strictly need to follow any manually mapped virtual paths through the plaza. However, it might be a good idea to anyways, in case of any obstructions that aren’t apparent from the plaza’s geometry. So I imagine that eventually virtual paths would only be necessary in cases where something automatic would fall short.

SomeoneElse:

That’s not what I’m trying to do - I’m trying to select one of the ways that connect at a node to edit it. Here is an example on the dev server. I can select the node, select both ways, but now what? How do I know which one is which?

For those without dev server accounts:

Two fences overlapping in the middle and diverging on both ends.1856×976 119 KB

There’s a list of selected features in the left sidebar. Click the one you want to keep selected, or click next to the ones you want to deselect.

Two features, both fences, with close buttons to the right of each.798×570 14 KB

This is the part of the workflow that I’d like to improve someday, with something more interactive on the map itself. Even so, I personally find it more intuitive than the alternative of a multilinestring relation. (Some of OpenHistoricalMap’s JOSM aficionados disagree with me on that point and use multilinestrings heavily, so a more usable workflow may be necessary at some point.)

SomeoneElse · 2025-09-17T18:57:54.079Z

Minh_Nguyen:

SomeoneElse:

but now what? How do I know which one is which?

There’s a list of selected features in the left sidebar. Click the one you want to keep selected, or click next to the ones you want to deselect.

Two features, both fences, with close buttons to the right of each.798×570 14 KB

At the risk of channelling Jeremy Paxman, how do I know which one is which without selecting each one in turn, clicking through to the main site and clicking (e.g.) relation memberships?

UW_Amy_Bordenave · 2025-09-17T18:59:55.092Z

SimonPoole:

We’ve had “in principle” working area routing for OSM data for a good decade

My intention in sharing this example is to show that we have working area routing for OSM data in production, not just “in principle” – and it is not merely “the production of eye candy” as you stated here:

SimonPoole:

You seem to completely ignore the tiny weeny issue that outside of the production of eye candy, we currently have no applications that utilize a) highway areas in general (though there is some hope there), b) separately mapped sidewalks in a consistent fashion.

An additional question: What do you mean by “utilize separately mapped sidewalks in a consistent fashion”? What would that look like to you?

Peter_Elderson:

Nice. But… why? As long as the ways are there, isn’t it easier to use those?

Easier, sure, in the same sense that it is easier to drop the edges for all sidewalks and crossings and create routes for pedestrians using only roadways. However, as with that example, you necessarily also drop some use cases. For example, given AccessMap’s focus on blind/low-vision routing, we find that users benefit from the type of route generated by AccessMap over areas as it more closely mirrors the path a white can user would take.

It’s also just more accurate in general - I wouldn’t walk into that central square part, make a 45-degree turn, continue forward a few feet, make another 45 degree turn, etc. - I would follow roughly a “racing line” trajectory. Area routing in this way also gives better distance and time estimates as well as better routing instructions.

Minh_Nguyen · 2025-09-17T19:02:26.263Z

I didn’t see any relation memberships in this example, but you’re rather proving my point and the original poster’s: geometries should be represented by geometric primitives when possible. Generally, relations should be for abstract concepts, not physical concepts, but multipolygon is a necessary workaround for our lack of more geometric primitives. Otherwise, overreliance on relations creates a poor user experience for mappers.

Now if first you name one of the overlapping fences “Chesterton’s”, at least you’ll have a sporting chance of knowing which one to delete.