Oops, not sure what’s going on with the link there. The forum is at community.openstreetmap.org .

The iD editor at openstreetmap.org reflects the current OpenStreetMap data. I’m not sure what source you’re using for ArcGIS. You may get a better answer by posting a complete description of your situation on our forum.

Hi there. I’ve seen many of your diary posts and community threads, and I’ve seen the way you and others have communicated. I agree with you that sometimes others have been rude and dismissive to you. You’ve also been quite abrasive and unhelpful yourself much of the time. I don’t know the technical details of your gripes with Australia’s road tagging, but from my perspective, it seems like you will get a much better response from the community if you stop with the accusations and focus on 1. Understanding why others disagree with you on the roads issue, and 2. Explaining your reasoning to them in a clear way. Since OSM is made up of so many contributors, it’s imperfect. I think in order to see some of the changes you want, you’ll need to accept that everyone has flaws, make some compromises, and communicate respectfully.

People generally use it as a blog for OSM related goings-on.

Very cool! Is the GPS receiver built-in to the camera? Any additional hardware or just stick it to helmet and ride?

Great article, and some thought provoking questions. I’m in a similar position of wondering more about “OSM Philosophy” after making quite a few map changes. I’d love to see more meta-discussion in an accessible format*.

So if you’re reading this comment, here’s your invitation to make an OSM diary post or community forum post with your deep questions, spicy opinions, or general thoughts! Hear ye, hear ye - OSM is a movement!

*(it seems like much of the high-level osm discussion goes on in mailing lists. I just don’t want to comb through millions of emails to get to the juicy write-ups like this one.)

I had no idea until now that changeset creation time was even recorded. Interesting!

To clarify a little on Karlos’s comments, OpenStreetMap data can take a little while to trickle down to various data consumers depending on how things are set up. So if, for example, a smartphone map app only updates their data every 2 months, an access restriction tag that’s only in the main OSM database for 2 days might end up being shown in the app for months, if the timing is just right. (Does that make sense…?)

For that reason, some people recommend that if a change is temporary (like a road closing for construction or a business operating at a temporary alternate location), it maybe shouldn’t be added to OSM. In my opinion, since most data consumers I’m aware of update at least every month or so, anything not lasting at least a couple weeks should be omitted.

So the question here is, what’s your estimate for how long the trail will be blocked? However, since you’ve already changed it, I’d personally suggest you leave it as is, and update it to allow access again when that’s changed in reality.

Hope that makes sense. To anyone - let me know if I’m misunderstanding or if you disagree!!

Great analysis!

Pieter, glad you enjoyed it. Great idea - I do have a budding Mastodon account. I’ll make a higher resolution image and post it!

Great write-up. I find cleaning up certain kinds of stale data really rewarding and fun. (Other types not so much.)

Actually, looking into the Dragon/Open/Sunnypilot issue, it looks like there is at least some discussion going on to address that: - Sunnypilot: Too Many Traces - SunnyPilot: Please simplify traces before upload - Possibly simplify traces before db insertion on OSM infra - OSM API database size growth has doubled

Do you have any clue as to why there are so many onosm notes in Iran specifically?

You might take a look at my (still ongoing, stalled) import project that seems a very similar situation:

• https://wiki.openstreetmap.org/wiki/Utah/CacheValleyAddressImport
• https://github.com/lint3/cachevalley-address-import-osm

I should prioritize finishing that up when I get some more time…

This is a really cool project! I did a “wide-coverage” bike project a while ago, but tired quickly of adding data since it’s such a hassle to stop. I’ve long imagined some kind of a system that could record preset features without stopping. An electronic device with buttons like “Feature A Left Side”, “Feature A Right Side”, “Feature B Left Side”, and so on…

I’d be curious to see specifically which of my changes were reverted. Is there a way to check that?

Also, just want to say thanks for creating your analysis tools, especially HDYC. It’s really fun to see my stats!

Great tip! It seems there’s a JOSM plugin for everything. Obviously it’s the more powerful option for editing, but after trying to get used to it several times I can’t seem to get over that initial wall of unfamiliarity. I suppose one of these days I should make myself switch over and reap some of the benefits you describe…

Nice writeup! I’ve been doing a similar process to gradually import addresses in my area. The conflation plugin is really handy. My only gripe is that switching back and forth between active layers in JOSM is a pain and slows me down a lot.

Regarding the data that is stored in OSM, specifically smoothness=*, I wonder if there would be interest in an app like StreetComplete using device accelerometer data to record this. That might be simpler and more accessible than lidar. I think the user would have to be educated a bit (“Please leave your device on the dash of your vehicle or attached to your bike frame or handlebars”). It also seems like you’d want to have the surveyor manually approve each tag change suggested from the data. Just an idea.

This seems potentially similar to the Roadroid system you linked, but I’m not sure whether that’s using a separate dataset, or updating OSM data.

Is the ultimate end goal here to have any continuously connected wooded area be a multipolygon? So most of the western US will be included if so? I agree that philosophically it makes sense that a “wooded area” have something describing/connecting the whole thing. I also agree that lines breaking up large polygons are arbitrary and don’t reflect anything physically on the ground.

However, in practice, I don’t see what it accomplishes. I agree with yvecai that it only creates headaches in the long run.