For most purposes it is counted as Kent. For local government it is in Medway and outside the jurisdiction of Kent County Council, but if you stop 100 people in Rochester High Street and ask them "are we in Kent?" I expect 99 of them would say yes.... You will have a hard job to convince people that Southend is not in Essex, or that Torquay is not in Devon, or that Leicester is not in Leicestershire.

Sorry, of course I meant Broxtowe BC not Rushcliffe BC

I expect it is still fully under control of both Nottinghamshire CC and Rushcliffe BC... unless you have information to the contrary?

Alex, could you please explain what you mean by "Beeston *has* departed from Council control"?

Alex, please remember that OSM is not your personal playground. Please engage with the community first if you want to suggest changes to the current way of working.

Alex, please note that there is no such thing as an "unparished parish". A location in England is either within a Civil Parish, or it is within an unparished area.

What is the intention with "ref:hectares"? Firstly, it has nothing to do with a "ref" in the traditional sense and a tag such as "landarea=*" might be a better fit. Secondly there is no need to record the area in OSM as it can be calculated from the geometry.

I fully concur with SK53. The fact that the UA and the city boundaries are coterminal does not make them the same object.

I am not convinced that the unparished areas should be in OSM at all, as the individual areas are all purely historical, unmaintained (though liable to change) and of no current value. It is possible that the polygons may be useful as the bases for a "place=*" object, but the common perception of the (sometimes rather woolly) boundaries of a named settlement often conflict with the legally defined administrative boundaries, so care is required here.

The OS data and the OSM "boundary=administrative" objects represent administrative entities, not places! Either there is a "City of Nottingham CP" or there isn't - it is not a matter of judgement, it is a matter of fact. If Nominatim gets confused by the rather complex system in the UK then it is Nominatim that needs fixing. You could always petition Parliament to sort it out, but when they come back from recess they "may" have more pressing matters to attend to first...

You have left route 481 in a dreadful mess... I will sort it out but please be more careful in future to leave things in a consistent state!

Please check the name, I think it should be spelt Kwikfit

Richard, you are right. As I mentioned in the note on that relation it was only intended as a temporary container while i sorted out the boundary. I will remove 6196005.

Hi,
I have removed the footpaths from the admin boundary as this is used to describe the outer edge of the area, not as a container for things within. This can easily be derived by geometry.

I have done the section from Hay down to where the NP diverges from the admin boundaries at osm.org/relation/357283#map=18/51.90467/-2.96697
For most of this distance I have used the new data, but where there is no significant deviation from the existing Boundary-Line data over a reasonable distance I have let that stand.

OK, I have sorted the relations. The original relation #357283 now has the new boundary data, but this has not yet been consolidated with other features. The previous boundary is in osm.org/relation/6196005 for reference - this relation can be deleted eventually when the consolidation is done. I will start work on the eastern boundary (herefordshire and glouscestershire) - @shaun, can you cruise round the welsh bits?

AFAIK these volatile boundaries are resurveyed periodically. Certainly every edition of Boundary-Line contains many changes to coastal boundaries where the MLW line has been updated. I assume that the boundary is where OS say it is (although that is second-hand information as they do not determine the boundaries) and the river/stream may or may not follow the boundary; I tend to leave the waterway alignments alone.

I see what you mean about the boundary south of Hay-on-Wye. It looks like the NP boundary is intended to be colinear with the admin boundaries, and the NP data is less generalised. Then I suggest we use the NP boundary instead of Boundary-Line in this area.

The E/W border in the area of this NP should all be from OS Boundary-Line now. By coincidence I am currently working on Herefordshire boundaries. Further north (Worcs. etc) there may well be issues with old "NPE" based boundaries. Where do you see the inaccuracies?

I can see that the NP boundary has a tiny wobble where those three nodes are, whereas the OS boundary line data has a straight line without the wobble nodes. Boundary-Line is based on 1:10000 mapping and is not the most accurate detail that exists.

Do we agree that the new data is the best data (most accurate boundary) to have in OSM? If so, we can get on with a process to replace the current NP boundary with the new data. If not, what is wrong with it and how do we fix it? Or is it so wrong that the old boundary is actually better? Let's move forward here and make some progress.

@SomeoneElse So you don't mean there are too many nodes in a numerical sense, just that nodes should be re-used where appropriate?

These boundaries from OS and others are already generalised to some extent. I don't think we want to encourage further generalisation. After all, we are reminded frequently that there are no limits to the amount of detail that can be accommodated in OSM and the database is already huge anyway. The data consumer can always generalise if that is appropriate for their case, but you cannot recreate detail which has been lost by generalisation.

The simplest approach appears to me to be to move the current members of the old relation to a new (backup) relation and then move the members of the new relation to the old relation. The temp relation can then be inspected for ways which can be deleted entirely (their only function was the NP boundary). Optionally the old and new boundaries can be visually compared with other features to see if there are reasonable opportunities for combining the boundary with other features such as waterways, highways and paths. (Note that my personal preference is for a conservative sharing of nodes with other features, NOT sharing of ways.) Then the temp relation can also be removed.
Any comments on this proposal?