I have now undeleted the City of Nottingham admin_level=6 relation and deleted the admin_level=8 one. I checked the relation members and tags matched up between the two (where correct).

Here you have added a non-existent admin_level=10 boundary named 'Beeston and Stapleford' but it doesn't even cover Stapleford! Why?

This is just nonsense. I propose to delete this, although will give you a chance to reply first.

Firstly, I do recognise you have spent a lot of time tidying the geometry of boundary relations. That is definitely worthwhile and I've got absolutely no intention of doing anything that will negatively affect that. In this case, there's no reason why changes to the tagging and structure of the relations themselves should affect the underlying ways. I believe the deleted City of Nottingham relation could be undeleted without affecting anything else.

The tagging of administrative boundaries is confusing. My understanding is that the City of Nottingham (unitary authority) relation could be tagged as admin_level=6;8;10 because it covers all those levels, however, the general rule is to only tag the lowest level. I don't think Nottingham is any different from the City of Derby, which is also a unitary authority without any civil parishes.

I've got no plan to remove your admin_level=10 (civil parish) relation covering the whole of Nottingham, but I would support anyone else who chose to do so. More generally I would be interested to know the views of other contributors on this. To me it just seems problematic, because it makes it hard to find real civil parishes, because the only indication it isn't a real civil parish is a descriptive name.

Here you have deleted the Nottingham administrative boundary relation, which has existed in OSM since 2009. I see you have recently created another relation for the city with admin_level=8. This is wrong because Nottingham is a unitary authority and therefore admin_level=6. It is the relation you created that should be deleted because there is no admin_level=8 boundary.

I also don't understand the purpose of the admin_level=10 boundary you have created covering the whole of the City of Nottingham area. It seems very misleading because this area isn't a civil parish and doesn't contain any civil parishes.

I've not seen any trains going along that branch since 2011. It's some time since I've had a proper look at the state of the track. I don't object to it being changed, although it would be worthwhile also checking where it crosses the canal, because that bit was in good repair last time I checked (perhaps 2-3 years ago), while further along at the service road it was quite overgrown back then too.

Thanks for pointing this out. All now corrected. The extra tags were intended for another shop and I guess I copied them by mistake.

I appreciate that there are arguments in favour of using the sport key in these cases. However, there are counter arguments of which two immediately come to mind:

1. As mentioned in my changeset comment, with shops it's common to use the format shop=x x=y to expand on the products sold.

2. There's no reason why the values included in the sports key tag on sports shop have to be exclusively sports. For example, sports=fitness;sport_supplements;bicycle_parts would be valid.

My view is that if you think it's important to include the sport tag in these cases, then fine, go ahead and add it,
but that should be in addition to the sports key and not instead.

In general, I agree the tagging conventions in these situations could be improved and the sells=* tag might be a way to go about it.

I think its borderline whether Bakersfield is a neighbourhood or suburb. I added the node originally and decided on neighbourhood, but I don't have any strong views either way.

I suppose I decided on neighbourhood, because I find it's a lesser known part of Nottingham. A lot of people haven't heard of it or don't know where it is, at least in the SW part of the city where I live. Surrounding suburbs like Carlton, Netherfield, Colwick, Sneinton and St Ann's all seem more well known.

My view is that the quality of the underlying data is by far the most important consideration. The data can be used for a range of purposes, so making it less accurate to work round a particular software deficiency seems the wrong way to go.

I agree that incorrect locations shown in diary entries are an irritation. Reliably determining a place name using just nearby place nodes is actually an almost impossible task. The solution is perhaps to map places as areas in addition to nodes. SK53 has already tried this for Wilford: osm.org/relation/5376380. I've got no idea whether Nominatim (or whatever geocoder is used in this case) supports this.

Please could you explain in more detail why you have changed Carlton from a suburb to a neighbourhood? I don't understand your changeset comment. Deciding on the relative importance of different places is subjective, but Carlton is one of Nottingham's main suburbs, so I find it hard to see any justification for downgrading it to neighbourhood.

Hi,

Are you sure that the change you made here is correct:
osm.org/way/53054452/history

Have you surveyed it or else what's your source?

The canal no longer passes under the road, except in narrow pipes, so waterway=canal seems inaccurate to me. See http://www.geograph.org.uk/photo/3793331

Hi,

Welcome to OpenStreetMap.

Please note that road references should never go in the name tag, so the name=A6006 you added needs to be removed.

If you are confident that this section of road really doesn't have a name, then remove the name completely, else the previous name should be put back.

Hi, there's no need to enter speed limits in km/h. You just need to add the unit after the number, e.g. 20 mph.

See osm.wiki/Key:maxspeed

Welcome to OpenStreetMap.

You have added the name '(no-name close)', please note that the name tag should only be used for proper names. If something has no name, then the correct thing to do is to not use the name tag at all. You can use the 'note' or 'description' tags if further explanation is needed.

Second, you have changed highway=service to highway=road. Highway=road is used when the highway type is unknown. In this case, the road has been surveyed and it is an alleyway and for alleyways highway=service is in fact the correct tag, even if the road serves no real purpose.

I see you have added highway=footways along the walls that mark the layout of Shipley Hall (e.g. osm.org/way/363666662/history). Are you sure they really should be mapped as paths? Some of the walls are flush with the ground, but they are too narrow to walk along comfortably, and there are drops on some edges and between the different sections. I think the intention is that people walk on the grass inside the walls and for this purpose there are steps connecting the different levels, which you haven't added.

I would map the walls with barrier=wall even through they are mostly close to ground level. The real still missing paths through the middle and around the edges could then be added.

Hi,

What was your intention here? - osm.org/way/327955126/history

You have tagged the takeaway as both open and disused. Which is correct?

Please don't merge duplicate nodes when they belong to ways with different layer or level tags. I've fixed some nodes you wrongly merged around Nottingham.

In this changeset you deleted a way (osm.org/way/291667372/) inside Nottingham's Broadmarsh shopping centre (osm.org/way/16533081/). Your changeset comment was 'Fixing overlapping ways'. The way you deleted did indeed overlap another, but did you not notice it was tagged with level=1, while the other had level=0? In multi-level locations it is normal for ways on different levels to overlap.

Indoor mapping of shopping centres is difficult. I spent several hours working on the area you have fouled up. Please be more careful and do not change data you don't understand.

Also, please consider limiting your changesets to a smaller geographic area to make it easier for other mappers to check what you changed.

If you give 'local survey' as a source that should absolutely imply you have looked at it on the ground. In my view anything else is highly misleading. If you are using online sources, you should cite these so other mappers can easily verify where the data has come from.

Additionally, please give more accurate changeset comments. "UK: landuse refinements" is too vague. The main purpose of your recent edits was clearly to retag amenity=youth_club as amenity=community_centre. This is a controversial change that I for one strongly disagree with. It is the sort of change that should be discussed first and certainly should not be concealed in any way.

You have added the postcode NG2 3AA to Nottingham Mail Centre. This appears wrong to me, because the mail centre is in the NG9 postcode area. I don't doubt mail for the postcode you added is processed here, but it is certainly not the postcode of the mail centre itself.