I did make an input error here. Looking at my notes I recorded 39 & 41 immediately at the junction and then 35/35A/37/37A (newer than the surrounding properties).

I agree it's more important to get the tagging right than to change things quickly.

My comment regarding boundary=place assumed it would also be tagged with place=town, but I now realise that wasn't what you meant. Using a place boundary with some other place=* value seems sensible to me.

I'm not aware of boundary=administrative commonly being used for anything other than official administrative boundaries, although I'm only familiar with tagging used in the UK. I know unparished areas are sometimes used for statistics and I recognise that might be an argument for adding these areas in some form, but I don't think boundary=administrative is the right way.

These boundaries were previously added in 2016, and then following discussion most were either retagged or deleted. At that time there were several objections and little support for adding them.

Retagging as boundary=place might be appropriate in some cases, although it is complicated because these unparished areas often cover several former civil parishes. For example, the Beeston one also includes Attenborough, Bramcote, Chilwell and Toton, and it's questionable whether Beeston as a place should cover all of those. To me, something closer to Beeston's former parish boundaries seems better and then add the other places separately.

To the best of my knowledge the revert is complete. Many objects were touched twice. For example, fhrs:rating and fhrs:inspectiondate appear to have been removed in separate changesets.

Hi,

Here you have created relations for unparished areas, for example Beeston: osm.org/relation/9246079

I don't think these areas should be tagged with boundary=administrative, because these aren't really administrative entities, but rather record the absence of such an entity. Also, as far as I know these areas don't have official names, so the names you are adding are more descriptions.

Have the additions you are making been discussed anywhere?

There has been some discussion on the mailing list in the past, e.g.:https://lists.openstreetmap.org/pipermail/talk-gb/2016-August/019111.html

Thanks,
Will

This changeset also includes some buildings and addresses in Shipley View, Ilkeston. I wrongly thought these changes were in a separate layer in JOSM.

I've found a survey photo taken from the cycleway which confirms that at least part of the wood is needleleaved. Overall mixed might be the correct tag.

In general, I don't think you should be adding leaf_type from aerial imagery, because I don't believe it is possible to tell accurately enough. Around Nottingham this tag has almost always been added from survey, but following your edit it is difficult to tell which woodland has been surveyed and which has not.

Hi,

You have added a lot of leaf_cycle and leaf_type tags in this changeset. The only source you give is 'Wiki'. How did you determine the correct tags to use? I'm guessing this is a remote edit and not from survey.

I'm asking because I'm concerned that the data you have added may not be accurate. For example, from memory I recall osm.org/way/78194971 being mostly pine trees, but you have tagged it as leaf_type=broadleaved.

Thanks,
Will

I'm surprised it doesn't have a junction tag already. Perhaps junction=crossroads could be added? I don't think that would make any difference to the rendering though. Looking at other junction names I've added, they do all appear to render too early, so I think it is probably a rendering issue rather than a problem with the tagging.

There was no discussion at all about a mechanical edit. There are lots of tags in the OSM database that are discouraged to varying degrees, but to remove or change them en masse still requires you to follow the procedure for mechanical edits. Also you didn't address my point about your removal of other fhrs:* tags.

For the record I don't support adding fhrs:rating at all, but that's not the point. The number of undiscussed mechanical edits seems to have increased recently and I think it needs to be challenged. In my view uncontrolled mass edits are a far greater threat to OSM data quality than a small amount of transitory data.

I can't see any discussion in the link you have provided that justifies this edit. Back in 2016 there was some discussion and agreement that the fhrs:rating tag should not be used. However, there was no discussion over whether that tag should be summarily removed by mechanical edit in future. Additionally you have removed other fhrs:* tags, some of which are not transient, such as fhrs:local_authority_id.

Even when there are good reasons for a mechanical edit, advance notice and discussion is still important, so the mappers using those tags understand what is happening. The fact is some mappers have continued to use the fhrs:rating tag. They should have been informed of the deletion in advance and have been given a chance to respond. As it is, they may not understand how or why the tags have disappeared and so may now carry on adding them.

This appears to be a mechanical edit. Was it discussed anywhere?

Hi,

Thanks for removing those names. Some local authorities do seem to include the home addresses of businesses when perhaps they shouldn't. These seem to be administrative addresses, rather than the primary location where the businesses operate. For example, I have come across the home addresses of market stall holders a few times in the past. Others are mobile caterers, ice cream men and so on. I don't think there's any problem with adding the fhrs:id with a note.

There are definitely more FHRS IDs and addresses that could be added in Erewash, but when you get to the last 5 or 10% you do need to be a little more careful, because you do tend to be left the more difficult or problematic ones, which have deliberately been left until last.

I do make a lot of use of FHRS data myself, although I've been busy with other things recently and as I'm sure you can appreciate keeping things up-to-date is a never ending task.

In answer to your other points:
I only added the addr:housename "Ladybird House" in September and it was correct then (based on a sign outside).

The business you added from the note in Long Eaton does look a bit suspect, but I think it's more borderline than the cases I raised above, because the owner asked for it to be added and the address is shown prominently on the business website. I'd definitely have a look on ground before considering whether it should be removed.

Cheers,
Will

Hi,
Are you sure it's correct to add a business name here? This is a residential address and I've never seen any sign of a public facing business here. When this has been discussed in the past, the general view has been businesses run from residential addresses should not be added unless they are clearly public facing in some way.

The same point applies here: osm.org/way/79436901
Again a residential address. This business has a website but it does not mention this address, suggesting it's not public facing. The website indicates that the business sells food from a van.

OSM isn't intended to be a business directory. If businesses aren't verifiable on the ground or are mobile they usually shouldn't be included.

Sorry to find fault! You are doing an excellent job of keeping things up to date, but sometimes it is necessary to raise concerns.

Cheers,
Will

Are you sure this change is correct? Most spiritualist churches don't consider themselves to be Christian, but a separate religion. This certainly applies to churches affiliated with the Spiritualists' National Union, which is the most common type.

Regards,
Will

Thanks for correcting the address.

Could I point out though, addresses shown on Google search pages are definitely not a suitable source for OSM. The same applies to all other Google data (Google Maps, etc.). It is important to make sure the data sources you use are suitable for OSM. For addresses, websites belonging to individual businesses and organisations are generally OK, as are datasets released under the Open Government Licence (such as FHRS and Code-Point Open), but most other sources should be avoided.

Hi,
Did you intend to add the house number to St Nicholas church? If so, what's the source? It's rare for old churches to have numbers. Also, in this case, there is a number 10 on the other side of the road.
Thanks,
Will

Hi,
I notice you are adding names to electricity substations across the country. Please could you inform me of the source for these names? When adding names from a source other than survey, it's always helpful to give a source so other mappers can verify what you have added.

This query was prompted by me noticing you have changed the ref name for the following substation: osm.org/way/86751793/history
I walked passed this just last Sunday and the name on the gate definitely read 'Stanton Grid', but you have changed it to 'Stanton Substation'.

Thanks,
Will

Hi,

I've been looking at the historic Nottinghamshire county you have been editing here and specifically at places where the current boundary line differs from the historic one. For example, Ilkeston Junction (osm.org/way/59365220) was until the 1990s in Nottinghamshire, but it is now Derbyshire. The historic county you have added places it in its present day location in Derbyshire. I was wondering, do the official 'historic counties' actually follow the present day boundaries in this way, or are you just adding the counties approximately?

Thanks,
Will

Thanks for explaining your reasoning. When adding addresses in the UK it is usual practice to put all the address tags on the individual objects. Few mappers would think to check whether tags have been added to the surrounding landuse areas. Therefore I don't think you should delete tags in this situation, especially not addr:street or addr:place.

Your comment regarding addr:city is correct in this case, but it is problematic more generally. The administrative area of a city rarely matches with the usage of addr:city for postal purposes. For example, I live in the suburb of Stapleford (osm.org/node/26984573) for which the addr:city is Nottingham, but it does not fall within the administrative area, so it cannot unambiguously be determined in that way

Your point about addr:postcode is less clear to me. My understanding is that Nominatim uses postcode centroids to find the postcode for UK addresses when it is not tagged on the object. That is fine when more accurate data is not available, but it's not always correct, because the nearest postcode centroid isn't always the correct one for a given address.

The situation regarding addr:city and addr:postcode obviously might be different in other countries.

Regards,
Will