And if you edit/replace the boundary ways of a boundary relation, please reuse the existing relation instead of creating a new one. This allows a better view of the history of the admin area! Also, because admin areas are relatively static, their IDs tend to get remembered, for example in the OSM Wiki at osm.wiki/London_borough_boundaries

Please don't use relations as a collection - see osm.wiki/Relation#Usage

Sounds like a good compromise to me... I will do it like that. Are you local enough to check for that sign anyway? It has got my curiosity going.

Hi, thanks for your local view. Having searched high and low for evidence of Skelwith as a separate entity, I have not found anything on old maps or similar. However I have seen photos indicating there is a sign in the sharp right bend in the A593, opposite the Skelwith parish notice board....
That is the sum total of my evidence as to the existence of Skelwith, but it is beyond doubt that the main village of Skelwith Bridge is actually in Lakes CP, despite the many claims to the contrary!
My usual test for the "Admin centre" of a parish is the location of the (parish council-run) Village Hall. Any idea where that would be for Skelwith/Bridge?

Would you be able to check if that sign is still present, and suggest whether that is sufficient to conclude that "Skelwith" exists?

I think you are confusing Civil Parishes with electoral wards... I have rolled this back to how it should be...

Did you consider using admin_centre to link the villages to their community areas? That is, if they have a community council - I know that many do not. If admin_centre is used then label is redundant, unless it indicates a different location of course.

Please do not change admin boundaries you know nothing about!

Hi,

what is the source of your "correct" borders? how can they be verified?

Please take care not to move boundaries away from their official line. It may look neat and tidy to align boundaries with rivers etc but the boundary is where the boundary is... If you think it should be in a different place please contact the local authorities involved.

Sure, but I don't think this changeset is the right one to talk about that...

Hi Robert, did you possibly mean for way#554221884 to be an embankment? You tagged it as an admin boundary and that looks really odd.

osm.org/way/554221884#map=19/52.42569/0.76400

you are still breaking relations with these edits!!!!! Check out Colaton Raleigh for example.
osm.org/relation/3355387#map=16/50.6993/-3.3822

Please retrace your steps and either fix the problems or revert your changes.

Hi,
The reason your name is not here, is that you have NOT updated the relation when splitting a component way - and this is the exact problem. The fact that a component way (or node) has changed, does not change the relation itself. This is one of the "quirks" of OSM. However a relation in this list is there because it is considered "broken," usually because of a geometrical issue like not being a complete ring.

I notice the list is empty again now - for a large part thanks to FvGordon.

Thanks for engaging here. Could I ask you to explain your process for this? Where do you source the knowledge to make the right repairs? I have seen a couple of cases where the admin boundaries have been fixed, but other relations (for example type=waterway=river are not. My opinion is that the person who breaks these things should be given the opportunity to fix them as well - not only because it is their responsibility, but also because they need to learn something. As you know reverting a whole changeset is made much more complex when the objects have been edited in the mean time, and you seem to be on a hair-trigger sometimes, fixing stuff very quickly after it gets broken. Have you thought about having a cooling-off period of (say) 24 hours? You cannot have local knowledge of all the things you fix, so it is only fair that people who do (including the 'breaker') are given a chance as well.

Unfortunately it appears your reverts were not complete... And now another user (FvGordon) has started to patch up the admin boundaries but I have no idea if they are fixing ALL the broken relations. That may now complicate the revert process, This is starting to become a proper mess.

Take a look at http://www.loach.me.uk/osm/boundaries/ to see where boundary relations are affected. It is a lot of work to check and fix everything!!!

It looks like where you split a way, the "old" half (which retains the original ID) is OK but the "new" part (which gets a new ID) does not inherit the relation membership. You need to make sure the relation membership is copied over. Potentially it is not just parishes, but any relation - including waterways.

As it is you that is breaking things, I think it should be you who fixes it... What is actually your goal with these edits?

Hint: if you look here in after about 1100UTC tomorrow you should see some affected admin boundaries showing up, but as I said, there may be other relations getting broken by these edits.
http://www.loach.me.uk/osm/boundaries/

Hi.... You might not be aware of this but these edits to the rivers are screwing up the admin boundaries... Can you please ensure the boundaries are complete and correct again? Example here: osm.org/relation/4253482

Any questions, please get in touch. Otherwise I expect this damage to be repaired quickly...

It seems to be open to the public - there are no gates or "keep out" signs. I think it is just privately owned and maintained, i.e. not by KCC. In this case access=permissive is what you need.

Better to delete the toilets entirely, if there is no (immediate) possibility of re-opening. Data consumers cannot process the free text comments and will assume the toilets are still there.

thanks, I have fixed this now - silly copy/paste error in my notes!