If the whole thing is better tagged as a restaurant than a pub, then change the tag on node/492510160/history (I'm not a local).

Hello,
Thanks for splitting Foss Islands here - I think it makes sense.
I've moved the Foss Walk and the Millennium Way onto the footpath at the side of the Foss Islands Road (no sign, but it's where you'd end up walking if you followed either route - see relation/370667#map=18/53.95891/-1.07197 and relation/370674#map=17/53.95904/-1.07211 ).
I'm not sure what relation/13282370 , relation/13282371 and relation/13282368 are supposed to be for though - osm.wiki/Relations/Proposed/turn_lanes makes no sense, has never been widely adopted and (see @andygol/diary/35489 ) is quite controversial - turn=*#Turning_indications_per_lane is more common if you want to say "what lanes there are and where you can go from them".
Best Regards,
Andy

Just as a comparison, at osm.org/#map=19/54.04349/-0.99931 is something that I added as "trail_visibility=intermediate" in the UK. On the Bing imagery in OSM it's actually quite clear, but most of the year on the ground the paths can be tricky to see - things change with the seasons, and also in some places from year to year.

> based on Bing imagery clearly showing the north side of the trail
That's a bit of a stretch, to be honest - at different zoom levels Bing shows me to different sets of imagery (one greener than the other). You can maybe say that there's something there up near the stream on the "less green" images, but I'd struggle to call it a path, and I'd be reluctant to add it to OSM based on what Bing shows.

... and for completeness the reason that I'm commenting here in New Hampshire (somewhere I've no local knowledge of) is that someone has mentioned the same issue elsewhere (somewhere I am familiar with) to OSM's Data Working Group, which I'm a member of.
Best Regards,
Andy

If you're going to add off-piste or unofficial trails, then I'd suggest you actually need to survey it yourself, so that you can get the access, surface, trail_visibility etc. tags correct. Just adding lots of "highway=path" because you've seen something on Strava devalues the work of people who do actually do proper surveys nad take time to get the tags correct.

(to address some comments above) I map walking trails a lot myself and "there is a heavy walking activity on Strava which determines that it is a walking trail" wouldn't, on its own, be enough information to add something to OSM. There's information that someone was there once (or at least nearby, as ZeLonewolf says), but nothing saying what is there - there's no value to add to OSM.
I've spent lots of time local to me chasing down alleged trails added from Strava in this manner, many of which don't exist where they've been added, or don't exist now.

Hello Andrew,
Your changeset comment here is just "updated". It'd be better if you could use comments that explain in more detail what you're actually edited.
Best Regards,
Andy

Привет,
Вы добавили node/9126630246 сюда, но он выглядит как точная копия way/67029280.
С уважением,
Энди

Hello,
You've added node/9126630246 here, but that looks like an exact duplicate of way/67029280 .
Best Regards,
Andy

Hello,
You've added node/9107771244 here, but is it perhaps the same thing as way/906621443/history ?
Best Regards,
Andy

Bonjour,
Je ne sais pas ce que signifie "corrections pb ID" mais je pense que cela aurait pu casser relation/7640939 en n'en faisant plus un multipolygone. J'ai ajouté un lien sur changeset/111918710 pour le corriger.
Meilleures salutations,
Andy

Hello,
I'm not sure what "corrections pb ID" means but I think that this might have broken relation/7640939 by making it no longer a multipolygon. I've added a link back in at changeset/111918710 to fix it.
Best Regards,
Andy

It may be that at this point the AONB should be defined in terms of the stream or the admin boundary, in which case the "other" bit is wrong and this link isn't needed.

Bits and pieces around York, from survey 31/8/2021, tr8110b

Hmm - maybe I was misremembering what I'd seen at https://en.wikipedia.org/wiki/.eh (note - that's for the ccTLD .eh, _not_ the ISO3166-1:alpha2 code EH).
We'll see what people say at https://en.wikipedia.org/wiki/Talk:ISO_3166-2#Is_EH_code_referring_to_currently_existing_entity%3F_Or_only_to_defunct_country%3F . I'm guessing that the answer will be effectively the same. See also https://www.europarl.europa.eu/doceo/document/E-8-2017-007241_EN.html for another source that takes it as read that "EH" applies to the whole of relation/2559126 , not just relation/5441968 .

If the quality of this data is so poor that the shape, size and even the number of buildings is wrong, then it needs to be removed.
It's much easier to add correct data to OSM if you don't have to remove poor-quality data first.
OSM data is always a process of iteration - but this isn't a first iterative step - it's dumping 1000s of poor-quality objects in OSM that don't correspond to actual buildings.

Thanks - adding "not:" does help to clarify here.
Obviously at some point in the future the situation may change.

re the alleged source of Bing - it doesn't look like it to me. See changeset/111064067 .

> but I NEVER called you such word!

To be clear, what actually happened was I said:

> An attempt to communiciate with the user creating the errors at [1]changeset/110820868 was met with no answer about the source at all, and no promise of a date when the errors would be fixed.

and you replied "False," at the start of a longer answer that still provided no answer about the source at all, and no promise of a date when the errors would be fixed.

To reiterate what I have said elsewhere - we are trying to help you. Please do not assuming that if someone says you have made a mistake that it is a personal attack on you.
If someone asks you a question, do not argue or say incorrectly "I have already answered that" - answer the question.