So then we appear to have a mixture of good work and vandalism in this changeset and some of your other recent changesets.

In most cases the changes to the geometry of the streets are improvements. However what on earth you have done at the south-western approaches to the Pont de l'Entente Cordiale is beyond me. The most recent aerial imagery does not support the changes you have made. The IGN map does not support the changes you have made. Heck the Google Streetview imagery from June 2021 does not support the changes you have made. So why have you made those changes? If the IGN map supported them that would be one thing, but it doesn't.

Then we have the actual vandalism: mass removal of lanes:forward and lanes:backward tagging. That is valid tagging, so why did you remove it en masse? Consider Rue des Bergeronnettes for example. Not only did you thoroughly mess up your alteration of the geometry of the street by leaving multiple traffic sign tags formerly attached to the deleted ways in place as orphaned nodes, but you also removed lanes:foward=1 and lanes:backward=1 from the tagging for no legitimate reason.

There is one lane in the direction of the way. There is one lane against the direction of the way. Hence lanes:forward=1 and lanes:backward=1 is valid tagging. The road is obviously wide enough for two vehicles to pass each other.

Incidentally your vandalism of those tags will be vain. I will simply add them back over the next few days. Oh and yes that does include adding back lanes:foward to one-way streets as well.

So what is it this time then?

Can't be "tagging for the renderer" since neither tag is shown in common renderers. Can't be using the more widely used tag since the one you changed things to is vastly less widely used, and has all of the classic hallmarks of an artificially-enhanced tag given the essentially vertical jump in usage in mid-2018.

Your removal of unsigned_ref is NOT wanted. It is the more widely-used tag by several times. It is the tag supported by a major editor (Vespucci) when no editor supports the tag you are changing things to.

The changeset is at least of reasonable size this time, but that's the only remotely positive thing that can be said about it.

If you are going to insist on using that tag then add it as an additional tag. Do NOT remove the correct tagging already in place.

Did I really verify all of them? Yes. As much as is possible with armchair mapping. The problem with that particular changeset is the Megabus route. That is the thing that makes it have a massive geographical extent. Otherwise you will notice that everything is firmly in the Sheffield area. That Megabus route happens to through the Sheffield area.

So regarding borough v town: how do we tag things? For administrative entities? Yes. Hounslow is a borough there. For geogragraphical locations? Yes. Hounslow is a town there.

So Hounslow is BOTH in the grand scheme of things.

This particular node? Certainly not the borough. Therefore the tagging of it as such is wrong.

As for Hounslow West's tagging? Well it's a certainly a Hounslow Borough Council ward. Don't know if it's actually used as a neighbourhood name locally, but I suspect not. Were it a geographical name then it would be more likely to be West Hounslow instead. However that's a matter for those with more local knowledge than me.

Because it's bad tagging. To quote from the Gloucestershire definitive map website, "The routes shown have been transposed from the original Definitive Map, which is at a published scale of 1;10,560; therefore please make due allowance for any extra implied accuracy at the supplied scale."

That highway=no tag way was slavishly copied from the definitive map site with no consideration for the actual situation on the ground. The highway tag is for situations where there actually are ways through to follow.

In general the state of the geometry of the roads around that area is appalling. Far too angular and not really bearing proper relation to what is actually present on the ground.

And AGAIN your arrogant crusade continues. Stop this NOW!

Engage with the proper process to get this sorted out. Stop vandalising the map or I will report your to the DWG and try to get you banned for doing this.

Rue Roland Dorgelès? Really? You think that's good editing?

You have just taken the BANO data and dumped it onto the map without any proper thought. Did it ever cross your mind that maybe, just maybe the BANO location data might be wrong? There is clearly a row of buildings on Rue Roland Dorgelès numbered between 28 and 40. There are also clearly two buildings from Rue Carnot numbered 238 and 240. Yet you just create address nodes willy-nilly in the locations where BANO purports to indicate that the buildings are. No consideration as to the actual location of the addresses.

Now there can be discussion about the practice of tagging random points near buildings rather than the actual buildings (or entrances of buildings if there are multiple addresses within one building). You haven't done that. You've just splurged a whole lot of junk onto the system. You've also removed valid addr:street tagging from a number of locations.

BANO says. BANO correct. Me map. That's the level of thought and care you've displayed with this.

So please stop doing this as you have been. If you're going to create these associated street relations then at least do so with some proper care. At least check that the BANO location information is actually correct. Oh and don't remove valid addr:street tagging when creating these relations.

My, my, my I see you're STILL at this.

Well they've altered the presets in iD to deal with the fairways etc issue and bring it into line with the wiki. However that did NOT cover bunkers and on this you're out of line with the wiki as well.

"A type of hazard, also known as a sand trap, which is a depression in the ground filled with sand. Recommended to also tag with surface=sand or natural=sand. Do not use natural=beach--it's not a beach!"

Now it does say surface=sand or natural=sand, and iD is using both, but you're going about this the wrong way. Open a ticket on the iD presets tracker. Get it sorted out there.

Stop edit-warring. Stop doing edits like this covering enormous areas. Stop being so arrogant and high-handed.

What do I think is incorrect?

What I think is incorrect is claiming that using the tag lanes:forward in combination with oneway=yes and lanes is wrong.

To me there is absolutely nothing wrong with NOT using the tags in combination. So there is nothing wrong per se with simply using oneway=yes and lanes. It implicitly means lanes:forward. I'm merely making that explicit.

For me it's the same sort of thing as adding oneway=no explicitly to ways. People tend not to do it, but again it's just making explicit what was previously implicit tagging.

That's why I strongly dislike validators flagging it. It is NOT invalid tagging. It is merely being more explicit in tagging than usual. It's very different to (for example) tagging lanes=4 lanes:forward=2 lanes:backward=1. That's clearly wrong as there are four running lanes tagged in total with two in one direction and one in the other for a total of three.

There is nothing wrong with using that key on a one-way road. It is no more likely to create "incoherences" on a one-way road than a two-way road.

I warned you about doing this again. You did it again.

Data Working Group it is.

You really do seem to be causing serious issues with this don't you.

They are small areas of grass which are mown. This is correct tagging for golf greens and golf fairways and golf tees. The wiki is not definitive as has been repeatedly said in other places.

Now admittedly I'm only going to revert your changes round the area where I actually live, but revert them I will.

If you remove the correct tagging again I will complain to the DWG.

Thanks for dealing with the bus routes through the toll booths. I thought I'd linked them all back up again.

However you removed a great deal of valid tagging of lanes:forward. Simply put Osmose's "validator" is wrong on this, as is JOSM's. Implicit tagging is not a problem, but neither should explicit tagging be either. By flagging correct explicit tagging as an "error" JOSM does the system no favours.

Please don't tag bridleways like this. Designation refers to legal access rights, and tagging a bridleway as bicycle=no and horse=no means cycling and riding a horse along it is legally prohibited. That makes a nonsense of the bridleway tagging. It also triggers ID's QA cleanup code.

There are other ways to tag physical access problems for particular modes of transport.

It was an unfortunate editing, and I should have been more careful. Classic case of using IDs' automatic improvement suggestions a bit carelessly.

However, that said, using a deprecated tag like that does carry some risk. To me building:type does not describe a specific design like that. If it were not deprecated it would designate a bungalow or a detatched house or a terraced house or similar. A better (and not deprecated) tag would seem to me to be building:design or something similar. That would indicate a specific design of building, rather a general type of building.

Still there we have it. So my way out of this would be to tag things as building:design, rather than the deprecated building:type. That way the information is recorded, and it won't fall foul of ID's outdated tags search.

How extensive is the area of those houses? Is it essentially all of the area between the ring road and the Jubilee Campus down to Charnock Avenue?

If you haven't already I'll go through those houses in that area and tag to restore the information where it's been removed.

Oh there most assuredly is a way of seeing changes of position: OSMCha. Filter by the changeset number on that site and it will show you the before and after position of any nodes, ways or areas changed like that in the changeset.

No idea exactly where it's meant to be in terms of placement. I modified it to have standard tagging as indicated by ID. Hence the fix minor errors edit summary. Adding bus=yes in this case if I read the changeset correctly.

It's perhaps correct to say that it's not necessary to add that tag to one -ay roads. However there is no harm which comes of adding the tag. It doesn't make the tagging ambiguous. It doesn't make the tagging contradictory.

It's declared an error by wiki article writers. I see no reason to remove the tagging as it does no harm at all.

Nope doesn't work like that. Only possibilities when the validator is enabled is to set it as to whether to indicate where a tag is expected for a particular preset or optional for a particular preset.

The alternative to what I've done is to remove the boundary tagging from those ways, since they're just tagged with the boundary tag as otherwise they' just be tagless and members of the relevant relations.

To some degree it's tagging for the renderer. The renderer in question is the Vespucci validation engine which colours things pink if certain tags are not present. I have set one of those tags to be name tag.

The boundary ways tagged in this case are ones that are in place to allow a relation to follow the centreline of a street. It's the boundary between two wards in Leamington, and it follows the centreline of Victoria Terrace, which at that point is split in two by an island.

So that's why I've done it that way. If it were a way or relation relating to the whole of a ward/constituency/whatever other political boundary I would tag it with the actual name of the political or administrative division being represented. It just happens that these two ways don't follow that way of doing things.