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

Have you read the OpenStreetMap guidance on mechanical edits (see osm.wiki/Automated_edits)? Also the guidance on good changeset comments is relevant (see osm.wiki/Good_changeset_comments).
Aside from probably contravening the policy on mechanical edits, there are a number of specific issues I've noticed with this changeset. (It seems likely that these issues and other similar issues will be present in other changesets you have made).

1. This changeset does a lot of different things in a number of different locations. The changeset comment does not give any useful explanation for why you are making any of these changes. Even if they could be explained with a single useful changeset comment (which they can't), it would still be useful to split this up into multiple changesets covering a smaller geographic area, so that people view your changesets can get a better understanding of what places are affected by them (unfortunately the main tools for viewing changesets either show just the bounding box, don't work properly for relations, or don't work if the bounding box is too large).
2. You've changed the tagging of 'Killarney Lake' from a reservoir to a lake. It clearly has a dam, so the lake tag may be incorrect (I couldn't find any clear information about what tag is appropriate if an existing lake is enlarged by building a dam, and I have no idea if that scenario is relevant here anyway).
3. You've moved a number of nodes near a fountain by a distance of less than 1m. Why? Also, you've used a fountain=water tag, which is not standard and appears not to have existed anywhere in the world before now.
4. You've been removing a lot of instances of the tag landuse=reservoir, despite this still being a permitted tag. (Mechanical edits that replace one permitted tag with an alternative permitted tag are particularly discouraged. The history of some of the objects you changed in this changeset shows that the change you made here has actually been made before and subsequently reverted).
5. The tag seamark:type=gate seems to just be a duplication of the tag waterway=lock_gate. While both seem to be indepently recommended in the wiki, there seems to be no discussion of why this duplicate tagging is necessary. (This isn't a specific issue for you; rather it's a more general observation that should perhaps be raised elsewhere.)

Can you explain why you have made the changes you made here? For any mistakes you've made, can you please fix them (if possible) and try to avoid making them again in the future?

Thanks,
ACarlotti

I think this tagging is generally better. However, I'm pretty sure there is not a central island on the east side of the roundabout (which is what I understand your tag there to mean). Also, when splitting ways, I think it's generally worth trying to preserve the way history on a sensible part of the way - in this changeset you've instead attached the history of three of the roads to a short stretch of way next to the roundabout. There's nothing I'd do to change it now, but it's something you could consider for future changes.

It looks like you also made some change near the Milton Road/Elizaebth Way roundabout, possibly involving bus route 9, but I can't easily tell what it was. Also, I'm curious as to how this changeset was created by both Potlatch and JOSM.

Reverted in 88828701

I think that improves some things. I've tidied up some further inconsistencies in 88828581; you might be interested in checking what I've done there. Overpass is usually good for viewing the changes in a changeset (though this doesn't show relations) - e.g. https://overpass-api.de/achavi/?changeset=88828581

You also need to remove the construction=residential tags on those roads.

Hello egmont,
It looks like you've included two unrelated sets of changes in this changeset - can you try to ensure that unrelated changes in different parts of the world are uploaded in separate changesets? Looking at your other changesets, I suspect this was just a one-off mistake.

Also, your changeset comments don't say anything useful about what the changeset is doing, which makes it hard for other people (and you in the future) to work out what the intention of the changes was. If you are able to write more descriptive changeset comments in the future, that would be helpful. (This could be in any language - a good comment in a language someone can't read will be more helpful to them than a generic comment in a language they can read). You can read more about good changeset comments on the wiki (osm.wiki/Good_changeset_comments).

I think you've misunderstood how junctions of ways are mapped in OpenStreetMap. According to your changeset, it is no longer possible to get onto taxiway D from taxiway L, or onto the runway from taxiway D, since these ways do not connect (via a shared node). Assuming this is a mistake, can you correct it?
I have a couple more questions in case you have the local knowledge to answer this. According to Esri World Imagery (which I think is the most recent I've seen), the grass to the northeast of taxiway D comes closer to this taxiway than the current mapping shows - is that up-to-date? Also, the same imagery shows runway 10/28 as closed but still in existence - is that the current situation?
Thanks,
ACarlotti

This changeset covers a very large geographic area, which makes it very hard to work out what it actually affects. The changes in Scotland and the changes near Munich should ideally have been in separate changesets (I can't easily tell if you made any changes elsewhere - if so, then it probably should have been more than two changesets).
Also, splitting up changesets that include multiple unrelated sets of changes usually makes it easier to write a useful changeset comment - "various" tells me nothing that I can't already guess from the large size of the changesets bounding box (and that bounding box doesn't tell me much either).

One example is nodes 7773139223 and 7773139227, which lies on the way/58821394. Basically there is no relation between the end of a ditch and a point on the outline of Cambridge - there's no relation between the two, and the presence of one doesn't affect the presence of the other. So we use disjoint features to map them - no shared nodes. On the other hand, if you had a new footpath crossing over a road, then clearly this junction is meaningfully a common point on both objects, so we map it with the same node.

JOSM makes it relatively easy to change objects back to earlier versions (or at least, I know how to do it fairly easily in JOSM). If you want, I can help you fix this (although for the other two boundaries I wouldn't just revert to the previous outlines, because I think they don't make sense in relation to each other). However, it's a minor thing, so I'll leave the data as it is for now to help you learn.

Looking at the Bing imagery, I'd agree that these paths meet at a single point, but I think that point is further north (the path to the east doesn't cross the corner of Charger Green).
Also, as a result of your earlier edit, I think this had the unintended side-effect of changing the outline of the residential area.

Hello mk270, and welcome to OpenStreetMap.
In this changeset you've some of the nodes you've added (for new features) have also been added to existing area boundaries. This is usually incorrect (since the two features merely happen to be in the same place, rather than actually sharing a common point). These node should be detached from the ways you've mistakenly added them to.
This is a common mistake to make, and one I still make sometimes myself. I suggest you try to work out how to avoid adding to the wrong way in your editor, and also have a look at the list of objects your changeset affects before uploading it (I know I can do this in JOSM, but I'm not sure if iD also lets you do that).