And that's what I've done. I've used highway=no to map the 'ground truth' that there is no physical highway following that part of the line of the public footpath.

From a legal point of view the pedestrian route there certainly exists, and it is physically possible for it to be used, despite there not being a dedicated physical path occupying that section.

These three aspects are all important, and can/should be recorded in OSM. This can't be done without the way being present to hold the tags (designation=public_footpath + foot=designated + highway=no). Without the way, we would not have this information, and there would be no way to tell whether the route exists or not or is accessible or not on the ground. i.e. it would not distinguish between the route not existing there and that part just not having been surveyed.

You're presumably talking about way/1154315514 .

The tagging highway=link was me mis-remembering highway=footway + footway=link. Though possibly highway=no would be better here. Either way though, the segment is needed to be able to map the legal route of the Public Footpath, so it shouldn't be deleted.

(It would have been better to wait for a response here rather than just deleting a way whose tagging you didn't understand. And your changeset comment of "fixing tags" is not a good description when the only action is to completely delete an object.)

Yes, it is the same. Not sure why I didn't find that key value in the wiki at the time. Now fixed, thanks.

Also, you added designation=public_footpath to way/235428293 . But in this case, I believe that the footpath has been diverted around the farm. See https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/926782/row_3238952_od_.pdf .

Hi! In this changeset, you added designation=public_footpath to this way: way/152909708 . Could I check if this was a mistake, or if not, why you think it's a Public Footpath?

According to the Council data I have Blickling FP 14 and Aylsham FP 9 follow a path to the north of this track. See https://osm.mathmos.net/prow/progress/norfolk/broadland/blickling/ and https://osm.mathmos.net/prow/progress/norfolk/broadland/aylsham/ .

As you can see from https://osm.mathmos.net/chains/Q116779207/ the far bigger issue is that previously mapped Martin's stores have since closed. But now we have the brand tags added, it means that it's straightforward for QA tools to flag up discrepancies for editors to re-survey. Have you had a look at https://osm.mathmos.net/survey/ in your local area?

To answer your question, I'm sure I've made hundreds of errors while editing OSM. But hopefully the small relative number is more the outweighed by the positive contributions.

But on these particular changes, I'd be surprised if there were any errors on existing objects that were correctly tagged. As I already said, it would be very unlikely for a convenience store or newsagent to be called "Martin's" and not be part of the McColl's owned chain. For objects that were incorrectly tagged (such as the shop you pointed out, where the name in OSM was incorrect), then mistakes are more likely. But I think that's less of an issue, as in some sense the error was already there.

Anyway, prompted by your concerns I reviewed all the "OSM Objects not matched to list" at https://osm.mathmos.net/chains/Q116779207/ . (We can be confident all the matched objects are genuine Martin's stores.) There were only 5 where I could not verify (using e.g. Google Streetview and/or other OSM-incompatible sources) that there was a McColl's owned Martin's store at the site previously. Three locations are in pedestrianised shopping areas with no imagery available, but the brand tags on those weren't added by me. For the other two, imagery showed them to be similarly-named non-McColl's stores. One was the one you've pointed out already. The other had the brand tags added by someone following iD's suggestion.

So I think we can say that there were most likely no other "false amendments" in this changeset.

Ok, thanks. I've removed the brand tags, added a not:brand:wikidata (to prevent iD suggesting an incorrect change again) and added a human-readable note to alert other editors.

I'm really sorry if I've mis-undersrood the issue here. I assumed you were complaining about the addition of the brand:wikidata tag that pointed to the Wikidata entry for McColls. That was added following the NSI preset at the time, based on an exact name match of "Martin's". (Given UK trademark law, I though it very unlikely that a convenience store called "Martin's" could be anything other than part of the McColl-owned Martin's branded chain.) That wikidata tag now been altered by another mapper to the newly created wikidata entry for Martin's.

But presumably that's not the issue you were raising originally. Apologies again for misunderstanding. Perhaps you could explain exactly what the issue is, as I'm still not sure. Are you saying it's an independent shop and not part of the Martin's brand?

(If so, it would have been helpful if you said this explicitly in the changeset comments, or left a note=* tag on the object, when you removed the brand tags from way/676788755/history . Also, should the name be put back to "Martins Local", as you mapped it originally? Note that I haven't altered the name. Had it been named "Martin's Local", or if there had been a note tag explaining it wasn't part of the Martin's brand, it would not have been included in my recent changeset. )

I'm not sure if it was deliberate or not, but both of the two nodes above have amenity=bank on them. This is wrong, as it means that the OSM data is recording two banks there, when in reality there is only one.

To capture the situation you describe, I would probably have one amenity=bank node for the bank itself with (with atm=yes on it if you want), and then one amenity=atm for each of the physical ATMs. The one inside the bank could have indoor-=yes to distinguish it. You can add appropriate opening_hours to all three objects.

Is the brand=* needed if brand:wikidata=* is present? Feel free to add it if you want...

In terms of how the edit was done, it was an overpass turbo search on the name, results exported to JOSM, followed by a manual sanity check on the objects returned before adding the brand:wikidata tags.

Hi Phil,

In this changeset you created the node node/10080826333 . This appears to duplicate a pre-existing bank node node/6871715012 .

I presume this was a mistake. But should the first node above be deleted, or did you e.g. intend to add a second ATM at that position?

Wikidata item for Martin's now created: https://www.wikidata.org/wiki/Q116779207 , and pull request submitted to NSI: https://github.com/osmlab/name-suggestion-index/pull/7775

If you disagree with any of the NSI pre-sets that are used in iD, then you can file issues at https://github.com/osmlab/name-suggestion-index/issues . There was some previous discussion on this one at https://github.com/osmlab/name-suggestion-index/issues/1273 .

Yes, It's a "Martin's", hence the band=* tag. Rightly or wrongly, NSI has assigned brand:wikidata=Q16997477 to these as well. https://nsi.guide/index.html?t=brands&k=shop&v=newsagent&tt=martin%27s . It's not entirely wrong, since both fascia's are trading names of the same parent McColl's brand.

Personally, I'd like to see a separate brand:wikidata=* value for Martin's (it's already on my OSM To Do list), but it will need NSI to be updated as well, otherwise iD will be 'suggesting' everyone changes it back. At least with the brand=Martin's values set, it should be straightforward to change to a more specific brand:wikidata value when one is available (which is better than some previous NSI tagging decisions).

Can I check if way/230878776 has really changed from a Tesco Express to a Londis? It's odd, as there's another Londis store just next door at the Petrol station: node/10058580419 .

If way/230878776 is now a Londis, then the brand tags could do with being updated.

Many thanks. I think you're mapping is perfectly correct then. Though the paths on the ground don't agree with the official Public Rights of Way data.

Thanks for the very detailed changeset comment! Can I just check (if you can remember) whether there really are two parallel routes (the track and path) running NE from osm.org/?mlat=52.60698&mlon=1.40271#map=19/52.60698/1.40271 ?

According to Norfolk County Council's GIS data, Surlingham FP 12 should run SE alongside the residential property, and then meet Surlingham FP 10 at a T-junction at that point, where you can turn right or left. This isn't the geometry that's currently mapped.

I've been to have a look at the ground today. There are no signs on the ground for the Hereward Way round there, so I've routed the OSM relation along the riverside route that's used by the other Long Distance Trails, and most closely follows the PRoWs.