Fictitious separate bus stop highway osm.org/way/1335597072 deleted. Please do not map for the renderer by adding separate highways where no physical separation exists.

If you wish to add a bus bay, you can do it by splitting the parent highway and adding a bus_bay tag.
osm.wiki/Key:bus_bay

Please stop mapping for the renderer. Deleting your fictitious carriageway splits at T-junctions is getting very tedious.

Welcome to OpenStreetMap. There obviously isn't an enormous building here, but what were you trying to do?

You might find https://learnosm.org/ useful to get you started.

The building has already been deleted by another user in osm.org/changeset/159324469

I'm fairly sure that Guildhall House hasn't suddenly ceased to be a building. Reverted.

Wide hatched areas are not adequate separation for a dual carriageway, which requires physical separation by a central reservation. This is the case both for OSM mapping and in law.

Even if this were really a dual carriageway, leaving the original way as a 2 lane road and adding a parallel road, neither of which are one way, would be seriously incorrect mapping.

Mapping for the renderer by adding non-existent separation and geometries is detrimental to OSM data consumers. Routing in this part of North Kent is becoming increasingly compromised, to the point that I would have to fall back to Google Maps.

Please ensure that you have read and understood the following before making further edits to major roads:
osm.wiki/Tagging_for_the_renderer
osm.wiki/Dual_carriageway

Rochester Road is not a dual carriageway where there is no physical separation of the lanes by a central reservation.

In any case, what you have created here is not a dual carriageway, but two parallel roads with two way traffic.

(Review requested)

That wasn't the problem, but it's now fixed.

(Review requested)

Adding a fictitious vertical separation to get rid of a warning generated by the iD editor is not a good idea.

The iD editor makes a lot of suggestions, some of which are ill-advised, but they are only suggestions. If you do not know how to resolve an issue, even after reading the documentation, please leave a fixme tag on the affected objects and/or add a note to the map.

The actual reason for iD generating this warning is that you incorrectly added building=yes to the enclosing polygon for the school in changeset #159150764. If this really were the case, iD would expect to find different layers, or a tunnel=building_passage.

I have fixed both issues.

This is not a dual carriageway, either in terms of OpenStreetMap's mapping conventions or law - there is no physical separation of the lanes by a central reservation.

The OSM wiki for central reservations is here:
osm.wiki/Dual_carriageway

The legal definition in Schedule 6 Road Traffic Regulation Act 1984, which sets national speed limits for different classes of vehicle uses the following definition:
“dual-carriageway road” means a road part of which consists of a central reservation to separate a carriageway to be used by vehicles proceeding in one direction from a carriageway to be used by vehicles proceeding in the opposite direction.
https://www.legislation.gov.uk/ukpga/1984/27/schedule/6/paragraph/2

(Review requested)

No, not really. You can read the documentation for the layer key at osm.wiki/Key:layer

(Review requested)

No, unfortunately turning the entire length of the driveway into a tunnel=building_passage is neither helpful nor coherent. Highways are often split into segments because their physical properties differ along their length. In this case, a passage through a building with a 4.5m surveyed clearance only applies where the road goes through the building.

osm.wiki/Tag:tunnel%3Dbuilding_passage

I have reverted your changeset, so there's nothing you need to do here.

(Review requested)

That looks fine to me. Thanks for spotting and correcting it.

Thank you!

Please also refer to discussion here https://community.openstreetmap.org/t/uk-quarterly-project-2024-q4-pedestrian-crossings/119792

Please don't degrade the tagging of crossing=traffic_signals to crossing=marked just because Rapid tells you to. Where both the crossing node and way are tagged, Rapid is rather stupidly giving automatic precedence to the tags on the way, rather than suggesting that you check which best represents the situation. In London, the node rather than the way is more likely to be accurately and completely tagged.

You can use crossing:markings=dots to convey this information without removing information about the type of crossing.

The point of this project is to improve pedestrian routing and navigation, so hiding information about the type of crossing from routers is a little unhelpful.

Thanks!

That's annoying from OsmAnd. Given the described state of the path, it might be worth adding appropriate smoothness and tracktype tags.

Thanks for editing OpenStreetMap.

If a footpath is already mapped as highway=footway, the default access for bicycles, horses, motor vehicles, etc. is already "no". Adding those tags does no harm, but they are unlikely to have any effect on routing software.

It can sometimes be worth adding bicycle=no if there is a sign explicitly prohibiting cycling. Where a sign is present, you can also add the sign itself by adding a node (point) on the path at the location nearest the sign, tagged with traffic_sign=GB:951 + bicycle=no

Please STOP degrading crossing=traffic_signals nodes to crossing=marked

As someone who actually lives here and uses the data in real life, blindly changing tags without understanding what you're doing or why is incredibly unhelpful.

What is the point of these sidewalks, other than decorative mapping for the renderer?

Sidewalks which do not connect via crossings at junctions are at best useless for pedestrian navigation, but often create absurdly circuitous routes.