Which OS data are you using as your source?

MHWS and MLWS obviously aren't coincident here. They're skerries, not cliffs, and 3 different aerial imageries (Bing, Esri, and Mapbox) show the rocks covered different amounts at different tide heights. Comparing imagery to MHWS and MLWS on the Monach Islands, current Mapbox imagery looks close to low tide, while Bing and Esri are somewhere between high and low tide. For these skerries, the tide line on Mapbox quite closely matches the Boundary-Line high water polygons (and admin polygons/low water, and OpenData StreetView MLWS). Therefore, the Boundary-Line data for these skerries is MLWS, not MHWS, and so is wrong. No, MH/LWS can't be determined from aerial imagery alone, but it is still useful for determining if an area of OS data is at all correct, especially when multiple imagery sources show different tide heights.

The latest OpenData StreetView is from April 2016, but no MHWS line is shown on these skerries at all on the newer, less detailed OpenMap Local (April 2024), presumably because they're too small. I don't know if the coastline here was resurveyed between 2016 and now.

I removed the coastline tagging because the pre-existing geometries were essentially outlines of the skerries at some mid to low tide point (they were tagged with Landsat as the source), and therefore seemed to me to be representing the skerries, i.e. the natural=bare_rock, rather than the tiny natural=coastline rocks I chose not to add.

OS Boundary-Line MHWS data appears to be wrong for these two - their geometry exactly matches the admin boundaries from Boundary-Line, and the MLWS shape from OpenData StreetView, which implies that they are also MLWS rather than MHWS.

According to OpenData StreetView, there are two tiny bits of skerry that are above MHWS (within ways 30452363 and 30452364 respectively) - I just didn't bother to add these because they're so small.

Personally I don't really have an opinion on that - I find the Hebridean relations somewhat unwieldy and mostly ignore them, but it's almost impossible to avoid editing them when dealing with Hebridean coastlines. Removing Rockall etc. would at least result in smaller changeset bounding boxes which would be nice, but I don't have an opinion on whether that would be "correct".

It was rebroken due to a conflict with your changeset fixing the relation, so sorry about that and thanks for fixing it. I'd appreciate if you were less accusative though - breaking the relation obviously wasn't intentional.

Thought it was unlikely considering it was so long ago. Thanks for responding!

Thank you for explaining

Why did you remove these? I can't see anything wrong with them in the history.

Hi, sorry for commenting on such an old changeset. The name of Runcorn Wood (osm.org/way/159818656) is being discussed in osm.org/note/3534705. This is the oldest changeset in its history, so do you happen to know/remember the source of the name "Runcorn Wood"?

Thanks for the advice. I wasn't aware of that nuance, so I'll keep it in mind in future.

And notes 3288901, 3288915, 3288922, 3288924, 3288925, 3288927, 3288929, 3288944, 3288948, 3288950, 3288958, 3288960, 3288984, 3288992, 3289159, 3289164, 3289984, 3289995, 3291845, 3305615, 3305617

The relations only had one member so it was unnecessary for them to be relations

Hi, thanks for giving this area some attention and adding so much detail. My justification for removing the junction nodes was that they aren't located at an exit, although they may just be in the wrong place - highway=motorway_junction should be tagged on the node where a named or numbered exit splits from the main road. If these exits are named then the junction nodes just need to be moved to the correct location.