@BCNorwich see also osm.org/changeset/165085015

I see that you have chosen to ignore the comment made on your earlier deletion of these paths. I suggest that you read that comment again and also the linked wiki pages.
osm.org/changeset/165074768
osm.wiki/Why_we_won%27t_delete_roads_on_private_property
osm.wiki/Why_can%27t_I_delete_this_trail%3F

No problem.

There are things like floating gardens in some water bodies which don't render properly now matter how they're tagged. Unfortunately, it's probably a bit too niche to bother with raising an issue.

The problem with adding access=no here is that it doesn't represent the signed restriction and it creates a pedestrian prohibition which doesn't exist.

A no entry sign means "no entry for vehicular traffic", which is vehicle=no (or vehicle=private if you want to include service vehicles at a bus station). The plate with "Except buses" then gives the bus=yes tag overriding vehicle.

I'm not entirely convinced that mis-tagging the puffin crossings on Harbour Road as crossing=uncontrolled was entirely helpful to data consumers.

osm.org/node/7282538486/history/3

Please stop mis-tagging crossings at traffic signals as crossing=uncontrolled. Doing so hides information useful to data consumers, particularly those using OSM data for pedestrian navigation. If this is deliberate, it's vandalism.

The crossings here are clearly identifiable from Bing street side imagery as puffin crossings at a traffic light-controlled junction.

It's also pointless to add iD-inspired nonsense like crossing:markings=yes. If you can see what they are - and you can clearly see that they're dots in the Bing aerial imagery - then tag a meaningful value. If you can't see what they are, please don't add a tag uselessly telling data consumers that "this marked crossing is marked".

It's also extremely unhelpful to tag only the cycle Advance Stop Lines (and in the wrong place - they go on the *line* rather than the centre of the protected area). Choosing to tag the ASLs but not the associated traffic signals at the stop line is also unhelpful to data consumers.

Fixed in osm.org/changeset/164971164

Welcome to OpenStreetMap and thanks for adding your business.

I've added the tag office=accountant so that data consumers know what type of map feature this is. I've also tweaked the address and phone tags to fit OSM conventions.

At least one of which was added as an isolated node, which is no use to anyone.

Unfortunately, motor_vehicle=designated means "designated for use by all motor vehicles at all times".

The short segment of Parliament Street doesn't have any signed vehicle restrictions and doesn't really need access tags in OSM. There are turn restrictions in place which mean it can only be reached by buses approaching from Bridge Street turning right and cycles heading straight on from Parliament Square traffic island.
osm.org/way/260763235

Unfortunately, you blocked pedestrians routing by setting access=no here.

The signage here is TSRGD diagram 953 "Route for use by buses, pedal cycles and taxis only". As UK traffic signs generally only apply to vehicles, this translates to OSM access tagging as:
vehicle=no + bicycle=yes + bus=yes + taxi=yes

Updated in osm.org/changeset/164936881

(Review requested)

Welcome to OpenStreetMap and thanks for updating your details. That looks fine to me.

Updated to match signage in osm.org/changeset/164901026

There's still a bus=yes access tag on each segment, so this shouldn't have any impact on your routing.

Apologies, I see you expanded the abbreviation in ref=*, not prow_ref=*

Apologies, I see you expanded the abbreviation in ref=*, not prow_ref=*

Thanks for fixing this. PSV gets misused a lot as a synonym for bus+taxi, but doesn't mean that in the UK.

I've made a few other tweaks, as that section of Station Road/Poplar Road had acquired some "interesting" tagging over the last 10 years. Some of it may have made sense at the time, others like highway=living_street look a lot like tagging for the renderer. This shouldn't have any impact on you as bus=yes is still there, but please let me know if you notice any problems.
osm.org/changeset/164891122

Is it really a "correction" when you break the tools which consume prow_ref, like https://osm.mathmos.net/prow/progress/essex/uttlesford/aythorpe-roding/

We've got an established format for the key here osm.wiki/Key:prow_ref

Unfortunately, using your own preferred format for prow_ref breaks things like https://osm.mathmos.net/prow/progress/essex/uttlesford/great-dunmow/

Although the iD editor you're using provides drop down boxes suggesting that all the access values should be filled in, that really isn't necessary here. That's not your fault, it's poor design.

If you have a highway=footway, that implies access of foot=yes + (everything else)=no

Adding access=yes to highways is usually wrong, as it means that all modes of transport have a legal right to use that highway. More specific access tags override that, so the (otherwise unnecessary) motor_vehicle=no takes precedence. The horse="not specified" and bicycle="not specified" tags will likely be ignored by routing software, as "not specified" won't be understood by routing software and access=yes might take precedence.

osm.wiki/Key:access

By converting Eden Dock (Middle Dock) to a multipolygon with the piers as inner members, you have effectively turned them into islands, which they are not.

I've restored the dock's extent in osm.org/changeset/164884805

These roads are visible in aerial imagery as under construction and are in use by construction vehicles. Some even have clearly visible road markings.

If your navigation software is so broken that it cannot process access=no (this should be actually be access=private), that is not a valid reason to delete objects from OSM.

I have reverted your changeset and made a few other changes.
- the roads to the south of The Boulevard have been changed from highway=proposed + proposed=* to use a lifecycle namespace as proposed:highway=*
- changed access=no to access=private in most cases