Hello, Andy from OSM's Data Working Group here.

> I am from the Argentine community, the change was agreed upon with the Chilean community at the time and had already been eliminated.

Would it be possible to link to where those conversations happened?

> There were lines without content, what I did was delete that.

Maybe it's just a mistranslation, but relation/13723952/history definitely did have content.

It's always difficult to represent very large features like this with detailed relations, ways, and nodes - perhaps a simpler "mountain range line" would have been better?
However, deleting it with a terse "no es precisa" without a link to other discussion seems a bit rude.
Best Regards,
Andy

Hola joserrg12,

Utilice comentarios más descriptivos que simplemente "detalles añadidos".

Saludos,

Andy

Hello joserrg12,

Please use more descriptive comments than just "added details".

Best Regards,

Andy

Yes - but it's quite a long river! It's 1 relation and 8 ways in total. The relation is relation/12906468 - I think that 3 of the northern sections were edited by this mapper.
It was a bit odd before because the name:ckb of e.g. way/288636154/history did not match the name tag, yet the name tag looked like it might have been an alternative ckb name.

@LockOnGuy This changeset covers areas where the first language varies, so your comment isn't really helpful unless you actually link to the object that was changed, so that everyone can see where it is, and judge for themselves what languages would be appropriate in the name tag.

OK, done. I undid it with a combination of JOSM's "reverter" plugin and the Perl revert scripts.
JOSM is an OSM editor that is an alternative to the in-browser one - see osm.wiki/JOSM . It supports plugins, such as osm.wiki/JOSM/Plugins/Reverter which can be used to revert changesets.
The perl scripts are described at osm.wiki/Perl_Scripts and allow programmatic object by object changes.
In iD (the in browser editor) if something has gone a bit wrong, such as an accidental node drag, you should just be able to "undo" back past the problem and then go forward again.

I'll have a go at undoing it

Thanks!

Thanks - fixed

Er, "contact me in private message for souces" isn't really OK. Please include source details here.

Oops - forgot to close changeset. There's nothing other than in the very northeast and the very southwest, honest.

Thanks - I'll sort that out.

@Pink Duck but it sounds like what you're saying is that in your example the "highway" tag was wrong - it's not just for foot traffic, and so DaveF's "fix" here is incorrect (and has actually made the problem worse)?
The southern part of way/992713995 can't logically be a highway=footway and the aerial imagery suggests not either, but I'm not familiar with the area of course.

@DaveF re "you may thank me" above, being a smug git is not helping anyone, especially you. Let's try and work together here and understand each other's point of view.

Thanks - I was wondering what the "new national park" on https://map.atownsend.org.uk was!

One situation where "Remove access=private from footways with designation=public_footpath" might be incorrect is where the it's not the access tags that are incorrect but the highway tag. If any of these 44 ways was actually a highway=track, but incorrectly tagged as a highway=footway, then it's the "highway" tag that needs changing, not the "access" tag.

For completeness, https://overpass-turbo.eu/s/1lOm is a shared query that is close to what you might want. All of these are likely mistagged, as the "access=private" on a footway will be overridden by the "foot" tag, and access tags for other modes are assumed to be "no" by default as it's a footway.

in the case of way/992713995/history , not really - that public footpath (with "foot=designated") has been there since you added it 11 months ago. The "access=private" never had any effect, because it was "highway=footway".

@DaveD Does OutdoorActive route down "highway=footway; foot=yes; access=private"? If it doesn't, that's a bug, and it'd be great if you could badger them to fix it. If not, I'd suggest stopping using that app because it is just broken.

@Pink Duck Can you please give an example of a way that was adversely affected by this change where mapping that was correct "on the ground" is now incorrect?
So far I'm aware of basically two sorts of cases in the list below - ones like way/723570831/history where the original access=private was surely a cockup, - something looked private, but technical actually isn't, and ones like way/1054074314/history which is a different sort of cockup - a "private" tag looks like it got left over from splitting the way. Maybe the error in this second one is with the highway tag not the access one, but either way I don't see how information is really lost here.