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.

I removed the part of the old LNWR/LMS line in Leamington and Radford Semele because it is NOT visible on the ground. There is now a housing estate built over it in much of Leamington and industrial buildings at the Riccardo facility. Where there is now nothing visible on the ground then features should not be mapped.

Do NOT restore this railway as an OSM way where it has been totally destroyed and removed from the landscape. OSM is for mapping current features and is not for showing inaccurate, outdated information such as totally razed structures and routes.

Tell you what, why don't you try not treating it as a roundabout next time you go through the junction? Say what time and date you're going to do it. I can make sure I'm there to record your actions on camera and then I'll pass it on to Warwickshire Police to see what they have to say about it.

I'm sure the lack of diagram 606 signs at the junction will mean that they would be very forgiving of you not going round the junction in a clockwise sense. I'm sure that they would not investigate you for committing a road traffic offence if you were to do that.

Care to take that course of action?

"I guess you don't have a day job as if you did and your spoke to co-workers like you do on here, then you soon would not."

Ah unwarranted assumptions galore! So nice to see that surfacing.

As for traffic signs on the A452 Binswood Street, note that I referred to traffic signs specifically in the vast majority of my post. I did they very deliberately because traffic sign has a distinct legal meaning. The restrictions are advisory, not mandatory, but they are very much there and very much indicated by traffic signs. Also try going round the junction in normal traffic whilst completely ignoring those restrictions in front of a police officer. You'd end up with a fixed penalty notice so quickly you wouldn't even have time to blink. Like I said driving without due care and attention.

As I have said previously those traffic signs are diagrams 1038 and 1039 from the Traffic Signs Regulations and General Directions 2016 and I have told you where they are on the road.

Just to be very, very, very clearly about this: diagram 1038 and diagram 1039 are road markings painted on the road surface. Road markings are just as much traffic signs as things stuck on top of an upright post.

As for, "Ooh, but you have identified a problem with the signage at this roundabout - it is not actually signposted as a roundabout at all!"

Let's see:

https://www.google.com/maps/@52.2945455,-1.5400096,3a,75y,359.17h,67.24t/data=!3m7!1e1!3m5!1sOkbgNWENFvR7L3BMrSWZKQ!2e0!5s20201101T000000!7i16384!8i8192

What's that big green thing on the left hand side of the road? Why it's traffic sign signposting this junction as a roundabout.

https://www.google.com/maps/@52.2953395,-1.5420073,3a,75y,66.24h,80.8t/data=!3m6!1e1!3m4!1sCZoUSx5A_UNvP7itCeRSOg!2e0!7i16384!8i8192

What's that big white thing on the left hand side of the road? Why it's traffic sign signposting this junction as a roundabout.

https://www.google.com/maps/@52.2967641,-1.5389084,3a,75y,221.55h,70.66t/data=!3m6!1e1!3m4!1siP99PjZrol1H2OocOHCnVQ!2e0!7i16384!8i8192

What's that big green thing on the left hand side of the road? Why it's traffic sign signposting this junction as a roundabout.

So that's three of the four arms of the junction with traffic signs on the approach clearly showing it as a roundabout. Northumberland Road doesn't have such signage, but it's a residential road with local, rather than long- or medium-distance traffic and so rather different priorities for the street furniture.

If you're referring to the Princes Drive junction then you should know as well as I if you're local to the area that used to be a roundabout, until the junction was modified a few years back.

Don't try and get hair-splittingly snarky with me. I can quite easily demolish such attempts, as I have just done with that silly comment over roundabout traffic signs.

"Wow. What a rant."

Wow. What a misuse of a word.

Check out the actual definition of rant and then compare it to what you've called a rant. Then consider actually having a correct usage of vocabulary to describe what I wrote.

It also might help your case if you substantively countered what I've said instead of summarily dismissing it out-of-hand. For example you haven't acknowledged the signposting of lane restrictions on the A452 which directly counters what you claimed.

So you think I was uncivil initially. That's unfortunate for you.

I attacked what you had done. I questioned your actions. I did not question you as a person.

Let's look at my points in turn. Were you edits destructive? Well they destroyed some of the work I had put into mapping those junctions, reducing the accuracy of the mapping at those junctions, so yes I'd definitely say that qualifies as destructive. Since they qualify as destructive, and that destruction was not creative destruction I would also say they qualify as unhelpful.

Another thing that is particularly bad about this particular edit is your claim to be removing "multiple non-existent ways". Now if you go by the database definition of a way as a line connecting a series of nodes then since you deleted half a dozen from the database then you did remove some ways. That said it is very much mistaken to call them "non-existent".

Consider what a way is when applied to the map rather than considered simply as a database item? A way is an abstraction used to represent reality: in this case the routes traffic uses along particular roads at a junction. All of the ways deleted in the edits represent real, distinct traffic flows. At this roundabout traffic flowing from the A452 Binswood Street to A445 Rugby Road uses the left turn filter lane. It does NOT go up the signed straight ahead or the signed right turn lanes and then turn left on the A445 Rugby Road. As I said in my post higher up the thread these turning restrictions are signposted by diagrams 1038 and 1039 from the Traffic Signs Regulations and General Directions 2016. Now Northumberland Road is more arguable as there aren't actually road markings there directing to a particular lane, but from the road layout it is very clear that to turn left from Northumberland Road into A452 Lillington Avenue involves using the short left turn filter lane. Again attempting to turn from Northumberland Road into Lillington Avenue via the other lanes would be considered driving without due care and attention at the very least unless a full circuit round the roundabout were done from the right turn lane.

Physically the flows of traffic on that roundabout cross. They enter or exit the roundabout at different points on its circumference. So if they enter or exit the roundabout at different points, and those different points are significantly away from each other on the circumference of the roundabout, then they should be mapped as separate points. If they are mapped as separate points then the ways representing the two traffic flows will cross away from the roundabout. If that is the case then they need turn restrictions in place to prevent improper routing. Hence the ways being split at their intersection to allow the turning restrictions to be in place.

No more ways were used than topologically and systematically demanded by the way the database works in order to represent the actual traffic flows at the junction in a geometric manner which is not too abrupt and harsh.

That is the guiding principle I use when mapping all roads and junctions. Everything is an approximation when mapping, and you will notice, for example, that the Princes Drive bridge outline is represented by nothing more than the four nodes representing the four corners of the bridge plus four more nodes where the ways for Princes Drive and the pavement which cross the bridge intersect it. The way only contains those eight nodes because four are required to represent the geometry of the bridge and four are required to handle the intersections with the ways crossing that bridge. However I judge that the junctions require more nodes to represent their geometries, and where traffic flows differ significantly in their geometries those should also be represented.

Turning to another example of this junction editing: the A452 Princes Drive and Park Drive junction where we have a good example of semantic incorrectness introduced by the editing. Now the according to the map the A452 goes through the junction as two one-way sections for the most part. However there is one section of the northbound A452 which suddenly turns two-way through the junction for some reason. That is for the movement from Princes Drive southbound into the recycling centre. However that movement does not take place on the A452 either factually or semantically. The southbound A452 runs on the other side of the junction and this movement occurs on a service road leading from Princes Drive southbound into the recycling centre. So why is it mapped as taking place on a fictitious second, parallel, southbound portion of the A452 now? Oh and another thing I just noticed as well about that editing: the stop line point for the traffic lights coming out of the recycling centre and the gates for that centre have been merged into a single node. The gates close beyond the stop line for the traffic lights. That's why the two nodes were separated previously. Only a little thing in this case, but emblematic of the style of editing employed at these junctions. Said style being reduction in correctness and detail of the mapping for no real reason.

I have no objection to edits improving the accuracy and fidelity of the map. I have a strenuous objection to edits degrading the accuracy and fidelity of the map, as these edits do.

They are signposted, at least on the A452 Binswood Street. What you need to properly consider and be aware of is what counts as "signposted".

The governing rules are the Traffic Signs Regulations and General Directions 2016:

https://www.legislation.gov.uk/uksi/2016/362/contents/made

If you look in the schedules to those regulations you will see that road markings count as exactly the same as upright signposts in law. Binswood Street has examples of diagram 1038 in the lanes leading on to the main roundabout. They very clearly indicate that one lane is ahead only and that one lane is right turn only. Diagram 1039 can be found a little further back on the carriageway from the roundabout at the point where the left-turn lane diverges. Again that is the same as an upright signpost in law.

Now they are advisory traffic signs, rather than compulsory traffic signs, but if you tried to turn left from Binswood Street into Rugby Road other than via the left-turn lane or by going a complete circuit around the roundabout then you would be guilty of driving without due care and attention and if you did so in a particularly reckless manner you could be guilty of dangerous driving.

Incidentally I see you've also done a multitude of other destructive and unhelpful edits to a multiplicity of other junctions in the Leamington and Warwick area recently. Given your lack of proper comprehension of the wrong you have done and the damage you have done to junction mapping in the area I intend to get in touch with the appropriate people to get your edits almost all reverted.

Not sure whether this is Data Working Group level of concern, but the amount of damage is considerable.

Reverse this edit now please. The "correction" is wrong. The tunnel has been lengthened beyond where it is actually a tunnel.

Did it ever occur to you that the approaches to that roundabout were laid out like they were before this edit for a good reason? There are turning lanes with islands in between them and the main lines of the roads in question. That means certain movements are not allowed at the roundabout. Those movements were restricted by turning restrictions previously and the geometries of the flows were respected.

Now the layout looks like a mess with absurdly tight turns put in place because you wanted to "tidyup" the roundabout. Now turns can be made by routing software that were forbidden previously. Oh and the gritting route relation is now completely messed up at this roundabout.

Please revert this unhelpful and destructive edit.

One-way roads have lanes, just as two-way roads have lanes. Please stop making false "corrections" to objects like way 673964083 and similar.

Not my fault. This was done with StreetComplete. There's absolutely nothing you can do to restrict when it closes a changeset, except wait an unreasonably long time.

It has been reverted. However there is a fundamental problem with the situation as it is at the moment.

I have been trying to run Overpass Turbo queries to simply select Warwick as a town and always seem to run into only being able to select Warwick as a district. geocodeArea:Warwick, England}}->.searchArea; and variants always seem to bring up the district, whereas queries like geocodeArea:Whitnash, England}}->.searchArea; and variants will of course simply bring up the area of Whitnash itself etc.

Warwick does exist as a level 10 admin area multipolygon, the same as the other towns and villages in the region. However I simply cannot seem to get Overpass to select it or indeed get to the object if I run a search in Nominatim.

For some Overpass queries this doesn't matter, but for others querying the whole district produces a massive amount of data which slows things down considerably. So any insights you might have for solving this would very much be appreciated.

The use of those tags is deliberate. I actually consider the current way of dealing with many aspects of the traffic signs to be inadequate.

It's entirely possible to have traffic signs tagged on different objects, so tagging has to be able to accommodate those. Like I have they can be tagged in the ways they affect, at the point where the effect starts. They can also be tagged where the signs physically are on a dedicated pole or attached to a streetlight or a wall. Multiple signs can also be at the same point. In the Prospect Road case it's the start and end of the 7.5 tonne weight limit which coincide, as well as signs for the cycle tracks beside the road. In those cases it's just two signs, but it can be three or even four if there are two signs in each direction (say). It might even be conceivable to have one of these weight limits but have a weak bridge within said weight limit where only 3.5 tonne vehicles can pass over. Using the namespace for each sign clearly assigns tags to that particular sign. With the namespaces it would be unambiguous which sign refers to the 3.5 tonne limit over the weak bridge and which sign refers to the 7.5 tonne general town centre limit. It's also important to note that this tagging allows distinguishing between the sign telling you about the limit 1 mile ahead and the actual limit itself.

This approach also is capturing what the sign says, not the portion of the way where the effect is actually in place. It tries to capture a lot more of what the sign says rather than just the existence of the sign. Hence nearby on Brunswick Street you will see tagging of sign 557.1 which is warning of speed bumps ahead. However that sign occurs at the end of several hundred yards of a sequence of speed bumps. What is the point of it then? It is warning of speed bumps ahead on two of the exits from a junction. The tagging of traffic_sign=GB:557.1 captures the specific sign used, the tagging of traffic sign:direction=forward gives the sign facing, the tagging of traffic_sign:arrow=left|right indicates that there are two different sets of speed bumps being warned about down roads off to the left and right of the current road and the tagging of traffic_sign:distance=700 yards|450 yards indicates unambiguously what lengths of the road off to the right and the road off to the left are being warned about. That tagging methodology was borrowed from the turning lanes tagging scheme.

The aim is to capture more semantic information about what is on the sign than just that it's a sign warning about speed bumps ahead. Use of the namespace allows this to be done unambiguously and using the namespace all the time, even when maybe not strictly necessary, makes parsing the information easier and accommodates the use of different tags on the same node. So this would allow tagging of multiple signs attached to a street light pole separately showing the facing of each sign, and the facing of the streetlight and information shown on each sign.

Use of this schema even allows the capturing of distinct, unambiguous information about two instances of the same sign on the same pole but facing in different directions and distinguished otherwise only by the information on supplemental plates below those signs. See the instance of sign 642 (a clearway) near the junction of the A452 and the unclassified road coming out of Bishops Tachbrook. It's sign 642 in both directions but one way gives warning that a clearway exists in both directions at the junction up ahead and the other ends the clearway on the side road after turning into the side road.

I've started tagging traffic signs this way to give what I've been thinking of a good test run and to show that it works in the real world of tagging. I'm thinking of bringing this up on the tagging mailing list and and also posting about it on the wiki as a tagging proposal.

osm.wiki/Tag:bus%3Dyes

"Since 2011, some mappers have used bus=yes with highway=bus_stop, public_transport=platform, or both, to specify that a feature is a bus stop. This is the most common use of bus=yes."

"Note that bus=yes with highway=bus_stop and amenity=bus_station is redundant, as bus=yes is implied by these tags. However, this combination is common."

That looks like some documentation on the wiki to me. It may be a little tautological to use it in those circumstances, but there's no particular harm in it.

Now a tag combination that I have been using recently which is undocumented would be barrier=edging and edging=flush to represent the thin edging stones which often form the edge of a pavement's tarmac on the non-road side or between a pavement's tarmac and a grass verge.

That combination I just referred to I will definitely say is undocumented, but to claim that bus=yes in the circumstances that iD adds it as a tagging correction is "undocumented" is patently untrue.

I was trying to use the appropriate editor, but it kept OSMInEdit, but it kept falling over when submitting the changesets. Don't know what's wrong with it, but it wasn't helpful!

So in the end I resort back to using iD for some stuff. That's probably where the joined ways come from. I haven't finished mapping it, but I need to take a chance to head inside the building and check that I've got the unit sizes for the shops correct.

Things are better than they were with respect to mapping what's actually there, since previously people would have been walking on thin air if they'd tried to actually follow the route that was through the centre. At least now they've got a chance of spotting the big holes in the top floor!