I think there is a bus stop here. I don't know if there is a physical sign here, but route 606 (previously 206) to Impington Village College runs along this road northbound in the morning (on schooldays).

I looked at that page but failed to see the schedule completion date above the table. The table itself gives estimated end dates of Spring 2021 for Phase B+C and Summer 2021 for Phase D.

I suspected so. Thanks!

I think there are issues with most of the changes in this changeset.
1. The southbound carriageway through the junciton with Kings Hedges Road is not under construction, and is not being changed as part of these works (though there is a slight change to the kerb line further north). This stretch of road is also still open to cyclists, and to vehicles accessing the Darwin Green site.
2. The section immediately south of Kings Hedges Road is not a cycleway. It is secondary road that is temporarily closed to most traffic (but still open to cyclists and vehicles accessing Darwin Green - the access to Darwin Green is why I didn't add access=no tags here).
3. I think the direction=both tag you added to the traffic calming on Windsor Road is unecessary, and I can't find anything on the wiki to suggest that this tag needed to be added.
4. I don't think changes you made at the junction with Victoria Road are particularly accurate or helpful - they don't really match either the current or future routes for cyclists.
5. I have no idea where you got "approx July 2021" from - it isn't in the latest construction update I've seen. The scheduled completion dates are different for different phases of the work.

I think this best thing to do with this changeset is to revert it entirely, and then perhaps add more accurate tags to the bits of Histon Road that are temporarily oneway.

Why did you edit relation/1016554 in this changeset?

Can you explain why you have made this change? As far as I can tell, the existing tags were more accurate.
Also, your recent pattern of edits (involving bus lanes in seemingly random locations across the world) suggests that you may be making edits based on a systematic rule without sufficient understanding of the area being mapped. If so, then you should read the policy on mechanical edits on the wiki (osm.wiki/Automated_Edits_code_of_conduct).

I believe so - I remember seeing the 'end of shared pedestrian/cycle area' sign just round the corner on Fendon Road (south) a few days ago. I don't know how far they extend.

I'm not entirely sure what you mean. It isn't usually possible to delete or amend existing changesets (once they are closed), so the way to fix mistakes is to create a new changeset with the corrections. I think I've corrected Tom Scully Motors; if there are any other mistakes that I've missed, than I suggest you fix them yourself (in a new changeset).

I think you've added an excessive number of nodes in this changeset (and the other one in the same location). Most of the nodes you've added change the position of the way by less than 1m (and almost all by less than 2m), and some affect the alignment by less than 10cm (compared to straight lines ignoring those nodes). GPS traces won't be accurate to less than 1m, and imagery often isn't that accurate either - it can be distorted in various ways. It is also rarely possible (and never sensible) to try to identify the centreline of a road accurately to a precision of less than 10cm.

You should also add addr:street tags when tagging address (assuming the street name is part of the address - see addr=* for more details).
Also, if these are semi-detached or terraced houses, then I think a nicer way to map them is to put a node roughly in the middle of each home, and add the address tags to that node. (For a terraced house you can either do each one individually, or do the two ends and use interpolation). There are some good examples of address tagging for a variety of situations if you look at the area around Norfolk Street in Cambridge.

These are not housenumbers, so should not be tagged with addr:housenumber. I think this needs to reverted. (The added data seems to just be duplicating existing data, sometimes even duplicating the name of a different building.)
Have you made any other changes like this?

Correction: that last sentence should have started "This isn't a particularly strong opinion"

You make a good point. However, I think there's also a competing argument - namely that the path at a crossing is somehow different to an ordinary way in that things like the width and surface aren't quite the same as on the path away from crossings.
There's an example on the wiki that seems to support the previous style of mapping
footway=crossing
Note that I didn't introduce the precise mapping in the first place - that was by CycleStreets in changeset/88795945. I think my opinion is that tagging separate ways across each carraigeway and island is too precise, but tagging a single way for the whole crossing as "footway=crossing" is probably better than just treating it as an ordinary footway running through the junction (in situations where the parallel footways are both mapped). This a particularly strong opinion though (and may well change in the future), hence why I chose to just preserve the mapping style that was already there.

Is there a reason why you deleted the detailed tagging of the crossing ways in this changeset?

I think you moved the stretch of road immediately east of Ditton Lane too far to the south, especially in comparison to the adjacent bits of Newmarket Road. I've now straightened out the inaccurate wiggle (which was partly there before, partly exacerbated in this changeset).

You didn't notice that there was already a node for the traffic signals at the end of the bus lane to the east of Coldhams Lane (it was first mapped slightly too far west in 2009). I've merged that node with your node for the end of the bus lane.

It looks like you're just blindly converting bus routes without making any effort to check that the existing data is up-to-date. The through bus service stopped almost four years ago. Also, your new westbound data shows a bus stop being served despite the mapped route not passing over the adjacent road.

On what basis are you making your changes? Are you adhering to the guidance on mechanical edits (osm.wiki/Automated_edits)? Updating an entire bus route in this manner would suggest (to me, at least) that the data was accurate (or at least as accurate as could reasonably be determined) at this point in time.

Finally, if you're converting a bus route to PTv2, where that route is currently represented by a single relation, then I think that relation should become the route_master relation, and not just an arbitrary choice of the individual routings.

You've merged cycleways on opposite side of the road into the same way; I think that's a bad idea, since in reality they aren't directly connected and noone would normally want to travel directly from one to the other. It can also cause renderers to put oneway arrows in strange places.

EN:
Hi lenux,

I agree with Nakaner that these extra nodes should not be added. If the routing is unknown, then a way with no intermediate nodes represents this much better than some arbitrarily placed nodes in the middle of an ocean, which are almost certainly in the wrong place. Extra nodes should mean that someone knows that the way passes through those points in reality. Also, 20km (or whatever spacing you used) seems to be just some arbitrarily chosen spacing - if larger spacings would cause a problem for some users of OSM data, then there's no reason to believe that shorter spacings will fix this problem for all users either.
I therefore agree with Nakaner that this changeset should be reverted.

RU (via Google Translate):
Привет lenux,

Я согласен с Nakaner, что эти дополнительные узлы не должны быть добавлены. Если маршрут неизвестен, то путь без промежуточных узлов представляет это намного лучше, чем некоторые произвольно расположенные узлы посреди океана, которые почти наверняка находятся в неправильном месте. Дополнительные узлы должны означать, что кто-то знает, что путь проходит через эти точки в реальности. Кроме того, 20 км (или какой бы интервал вы не использовали), кажется, просто какой-то произвольно выбранный интервал - если большие интервалы вызовут проблему для некоторых пользователей данных OSM, то нет никаких оснований полагать, что более короткие интервалы устранят эту проблему и для всех пользователей.
Поэтому я согласен с Nakaner, что этот набор изменений должны быть отменены.

Hello IanBennett, and welcome to OpenStreetMap.
I think there are a couple of issues with this changeset. Firstly, as far as I can tell from looking online, Tom Scully Motors is a repair garage, not a rental service, and therefore should be tagged "shop=car_repair".

Secondly, this changeset contains two unrelated changes in different countries. This often makes it difficult for other people to work out what a changeset has affected, so it usually best to split up changes where possible so that each changeset covers a group of related changes over a fairly small geographic area.

Anyway, thanks for the contribution; can you just verify the tagging on Tom Scully Motors for me?

Thanks,
ACarlotti