I won’t attempt to re-edit the original diary post after so many months, but it’s worth mentioning that some of these issues have now been addressed, for example voting up and down.

Just as a bit of context, according to a local database of changesets, between January 2022 and May 2023 342163 users made a changeset with at least one change in it.

Of those, 173514 were making their first changeset in iD, and 118034 their 2nd changeset in iD. 2 people were making their 100,000th changeset in iD in that period.

Over the life of the project (ish, because changesets weren’t around from day 1 and older non-redacted data was made into “pretend changesets”), 2011005 users made a changeset with at least one change in it.

If you think quality is not a factor in FB Places data, yikes.

“yikes” doesn’t even begin to cover it! Basically, one of the following is presumably the case:

1. the OSM community has misinterpreted the data, and realistically Facebook don’t think that it’s 88% likely that there is a car valeting service operating in the north transept of York Minster.

2. the data is very low quality (in OSM terms) but actually perfectly serviceable for Facebook’s data use, which was to drive potential customers to Facebook.

3. Facebook actually think that this is “high quality data” (in OSM terms) because their view of “quality” does not match OSM’s.

I suspect (but obviously don’t know for sure) that “2” is what is actually going on here. It doesn’t mean that other Overture Maps members don’t have access to better data, just that that has not been made available in this release.

The most important challenge in getting this data into OSM is making sure the place labels in Overture have an equivalent in OSM.

No, the biggest challenge is to make sure that the data proposed to be added isn’t utter garbage. See the discussion in the forum thread at https://community.openstreetmap.org/t/overturemaps-org-big-businesses-osmf-alternative/6760/271 and elsewhere.

With regard to “what this data was used for”, see the threads at https://en.osm.town/@migurski@mastodon.social/110804743862527535 . It sounds like the FB data was basically used to drive potential customers to Facebook; quality wasn’t really a factor in that. Having a high false positive rate wasn’t a problem with that use case; some people just got (even) more spam from Facebook than they might have done otherwise.

There is a “confidence rating” in the released data, but a quick test shows that not to be especially helpful. at that location (York Minster, a large cathedral dating from the 1200s).

The POI for York Minster appears with a confidence of about 0.9, but unfortunately so does a statue (which exists, but not in that location) and a childcare facility (that certainly does not exist there either). A car valeting company appears with a “confidence” of about 0.88. I have never seen cars being cleaned in the north transept.

There may be some benefit in using some of this data as an “aide to survey”, but it certainly isn’t any use for e.g. maproulette or (heaven help us) some “AI” attempt at adding data, which would simply come up with plausible OSM tags for something that simply does not exist.

@pitscheplatsch Excellent, thanks! Although of course some “reverts” (for example in my case osm.org/node/1731217800/history ) is just tracking data as it changes.

Just to expand on what SK53 said above:

One of the key discoveries for me was that to understand the issues you absolutely need to survey in-person, arguably in or with one of the vehicles that you’re surveying access for. Many official “crossings” (while useful for cyclists) weren’t great for mobility scooters because if turning circle or camber issues - dropped kerbs where private driveways exited were much more useful. Another was that gates designed to deter cyclists but permit wheelchairs didn’t work for all mobility scooters (turning circle again).

Another, related to turning circle issues was that knowing width was important. More more on this, see the tagging list thread here and other related threads at around that time with the same posters in them.

Finally my general takeaway was that the overall quality and detail of mapping required to be useful for wheelchair and mobility scooter routing was significantly higher than what most people just “mapping sidewalks separately” (or not) are doing. A logical way to capture this sort of information would be expanding on what e.g. StreetComplete do now - but it’d need a level of expertise about the problem that apps like that are designed not to need.

Looks like information=route_marker has a few more uses

Yes, I was surprised to see that “information=route_marker” tends to be used for this (albeit for a few values only), as that doesn’t really match it’s normal meaning. I’d be tempted to make up a new value for these, but like you I’m surprised that other examples in the US aren’t already mapped as something else.

Taginfo suggests there aren’t that many mapped so far, but information=trail_register seems sensible to me!

They aren’t as much of a thing in England (though leaving details where you’re staying about where you’re going and when you’re expected back are).

I think it’s destructive to remove runways mapped as lines and I think this idea should go through a formal proposal first.

I absolutely agree with this comment. It’s easy to calculate the length of a runway from a line but impossible from an area.

Taginfo suggests a number of consumers for aeroway=runway, so I’d suggest discussing this more widely - perhaps at https://community.openstreetmap.org/ , and also contacting data consumers listed at taginfo (there will be at least a github project listed for each) to point them to the community discussion.

However, if someone was to add a polygon area:aeroway=runway around an existing linear aeroway=runway then clearly no data would be lost.

Perhaps I wasn’t clear about my second example - it is clearly not a hedge.

However, generally speaking you’re correct - things such as way 1086001254 is currently tagged in OSM as a hedge, but is surely mistagged. Bing and Maxar imagery there suggest different bits of woodland (perhaps some broadleaved and some needle-leaved). Rather then guess from imagery I’ve left a number of these for future survey.

When i was looking at the “alleged hedge areas sorted by area” in the UK and Ireland yesterday I didn’t see many that looked like scrub - most were some either obviously fields (which I fixed), genuine large hedges or sort of woodland (which I left).

I’d agree that wheelchair=yes doesn’t help here, and it’s certainly not appropriate for access tags (there’s been no change to the legal status), so I’d just tag what you see - width, surface, smoothness, tracktype etc.

Other things to think about are the incline along the path (which sometimes is tagged in OSM) and the (here, lack of an) incline perpendicular to it, which can make paths challenging for mobility scooter users, which may have a narrow track and relatively high center of gravity.

You can also add some sort of description or note. That won’t get picked up by routers but might very well be by a human vetting the results that a router returns.

With regard to translation - pages now seem compatible with Google Translate, so for example https://translate.google.ca/?sl=en&tl=de&text=https%3A%2F%2Fcommunity.openstreetmap.org%2Ft%2Ftagging-help-for-osmose-error-untagged-named-object%2F99233%2F11&op=translate now works as is. Obviously that’s just an anonymous view of the page, so you can’t reply from there, but it’s much less clumsy to use than Discourse’s built in one-post-at-a-time-but-not-the-thread titles translation.

I’ve no idea whether this was a change at Discourse or at Google, or when (it might have been working for ages and I haven’t tried it).

Changeset comments for info: https://resultmaps.neis-one.org/osm-discussion-comments?uid=550560 .

Re the “hashtags” part of your question - no-one is stopping you from using hashtags. However, please do follow the advice at osm.wiki/Good_changeset_comments and use good changeset comments as well to help other mappers understand what changes you are making.

Suggesting that other mappers should resort to using things like chatgpt to decode your gibberish is a ridiculous suggestion.

You were asked before at osm.org/changeset/123219182 but you ignored the request.

In osm.org/user_blocks/7082 you were therefore sent a message that you had to read before continuing to edit.

You were at no stage blocked from editing OpenStreetMap.

@SaltyKimchi I’ve hidden the crypto spam comment that you were referring to and reported the user

Sometimes the people creating these accounts have a sense of humour, like with the picture here: osm.org/user/Ranah%20Medle .

I’ve just tried the Nokia 6.1 with an incognito Chrome tab - 4 seconds. The Nokia X10 with Chrome, about 3 seconds. Maybe it’s slightly faster than Firefox, but 4 seconds to do anything in 2023 is just too slow. An iPhone 8 Plus of about the same vintage as the Nokia 6.1 (but obviously much more expensive new) is about 2.5 seconds.

I’ve saved a recording from the “performance” tab of firefox on a Chromebook to https://map.atownsend.org.uk/tmp/c.osm.org.profile.json . From me pressing return in the address bar to the page appearing took about 8 seconds.

@Firefishy - Re the speed issue, I suspect that this is mostly due to just how bloated the site is. I’ve just tried a couple of times, each time in a new Firefox private window on a mobile phone.

On a Nokia 6.1, Android 9 on 3 (4G with 31 Mbps down) I got a 5 second delay before the front page https://community.osm.org loaded.

On a Nokia X10, Android 13 on O2 (4G with 26 Mbps down) I got a 3 second delay before the front page https://community.osm.org loaded.

On a PC, Windows 10 / Chrome Incognito (FTTC “broadband” with 16 Mbps down), the delay was about 2 seconds.

If there’s anything I can do to test this locally, let me know. I’ve also got a chromebook and a couple of old laptops here that might show the same issue and show what is “eating all the pies” in the site itself.