Thanks - they're the same. I've merged them.

Noted - thanks. JOSM came up with he_ref as an autocomplete, but I'll override it in future.

@DaveF Yes, that's the one I meant. Technically, I guess you're right - the original error was in the designation tag, not introduced by you. But the access=private tag was correct and your edit removed it, meaning an app could potentially route along it.

@SomeoneElse: It wasn't the right code, but I worked it out (I restricted the results to Oxfordshire, randomly, to stop it timing out).

(
area["name"="Oxfordshire"]->.boundaryarea;
way(area.boundaryarea)["highway"="footway"]["foot"="yes"]["access"="private"]({{bbox}});
);

This query found this way:

way/31900579

And yes, OutdoorActive will route along this way. So it looks like it's behaving correctly.

@SomeoneElse I tried to run an Overpass Turbo query to find ways with that combination but I couldn't find any. Is this the right code?

(
way["highway"="footway"].
way["foot"="yes"].
way["access"="private"]({{bbox}});
);

The only way a public footpath can be private is if it is legally diverted or deleted.

Again, I repeat, nowhere that I can see did DaveF's change introduce a problem. Your objections appear to be hypothetical.

I think the problem is that there is a difference between LEGAL access and PRACTICAL access, and the two may diverge. Whatever you do to a public footpath - even building a house on the line - does not affect its legal access status, though obviously it renders access impossible in practice.

Possibly the way to deal with blockages (temporary or permanent, legal or illegal) is to tag the node where the blockage occurs, rather than the whole way.

Putting up a sign does not make a public footpath private.

If it's a permanent, legal closure, then the correct action is to remove the designation=public_footpath tag.

If it's a temporary, legal closure, then the correct action is to add access=no with a note.

If it's an illegal closure, again I would suggest that the correct action is to add access=no with a note.

Nothing you can do to a public footpath makes it private. That combination of tags is fundamentally contradictory.

In your case, it sounds like the footpath is still usable, so the access tag should not change anyway.

I've been through all the cases changed by this changeset and in none of them does there appear to be a case for access=private. The only case where DaveF's change introduced error appears to be the one highlighted above, where the former line of a diverted footpath had not had its "designation=public_footpath" tag removed.

Pink Duck, I think you're missing the point. A blocked footpath is access=no, not access=private. Blocking a public footpath (legally or illegally) does not (and SHOULD not) make it private.

The fact that the underlying land is private does not affect the access status of the way itself. A public footpath is as much a right of way as a public road.

(My "likewise" was agreeing with John Stanworth, in case it's not clear.)

Likewise. My app of choice (OutdoorActive) will not route down a path that is marked access=private and designation=public_footpath.

Fair comment from ohmanger - in this case the impact of the global change was negative - an unavailable route became marked as available.

On reflection, it would have been better to have looked at each case individually and removed "foot=designated" or "access=private" selectively. While the two tags are mutually exclusive, there's no obvious way of knowing which needs to be removed or altered.

Another experienced walker agreeing with DaveF. By definition, designation=public_footpath and access=private should never coincide on the same way. If a PROW has been blocked or closed (legally or illegally) but not extinguished then it should (IMO) be set to access=no and dealt with in a note.

Thanks - it was an error on my part. It was supposed to be wikidata = Q26530677. I've corrected it now.

Have now corrected this and other changes that used he_ref. Thanks.

Yes. Didn't realise it was case-sensitive.

Hi Dave and thanks. The correct PROW ref is Hayfield BW 8. Regarding the name, I was following a precedent I came across in another parish (and I think there is an argument to be made that, in the absence of any other name, the prow_ref IS the name of the way). However, others have said the same as you so as a newbie I've accepted the convention and am no longer adding the prow_ref to the name.

No, I wasn't aware and it wasn't deliberate. How do I undo the damage?

Thanks again. I can see the problem, but I don't know how to fix it. Any advice?

Hi Bernard - whereabouts do you mean? If you mean near St Georges Road in New Mills at the western end, there was already some confusion about the line of the Sett Valley Trail but I think my line is correct. I plan to visit to check whether the previously shown line exists (I don't think there are duplicates on the ground).