The break in route was caused by the Northern Distributor Road construction (A1270), now named Broadland Northway, but nearly all call it the NDR. I've checked the latest timetable of Sanders Coaches (https://sanderscoaches.com/timetables/45) and revised the route accordingly for the mainstay running.

The timetable also hints at part-day running through Felthorpe and Reepham.

There are further breaks around Cawston.

By law all roads are open to pedestrian use in the UK, except for Motorway and explicit no pedestrian signage.

Perhaps motor_vehicle:conditional="no @ (2022 Jun 2+)" instead? Or date range if end date known.

What was this about? You've routed a service road through a fence.

If you are going to route a service road through highway=service with area=yes, then you should change the service area to area:highway=service so it renders and is no longer part of routing.

This because highway=service with area=yes is already intended as a freely routable space from all interconnects. So there was no need in this instance to add additional way connectivity.

It may suggest the gap finding is not factoring in highway areas correctly.

It is up to the routing agents to correctly handle any edge-to-edge connection within highway areas from entry/exit points.

The way was actually connected already by means of highway=service with area=yes tagged. By connecting the service road between, you really should change the former to area:highway=service.

That's actually legally incorrect. It is only motorways that pedestrians are restricted from (in England).

Thanks :)

I have restored the addressing tags for this building and tagged the new details at the new building location.

Future changes could be reported by using the "Add a note to the map" facility.

From a coding and database point of view a non-conditional fee would be stored as a nullable currency numeric value. Which is probably why seeing fee=yes + charge=1 GBP/hour seems a bit strange to me, instead of fee=no or fee=1 GBP/hour. Despite the many use cases that TagInfo higlights, but such is the sway of the wiki.

I'm fine with the conditional, but if you read the wiki discussion it becomes apparent that bias towards using two keys appear to originate from one single user unsure of how to code handling for the fee key. Not a great single-point reference for defining guidelines.

I don't really see what the problem is with using charge key-like value in the fee key. Either there's no fee and zero charge, or a fee and non-zero charge. Seems wasteful to be using two keys for that sort of thing. People really should be able to handle fee=no, fee=0, fee=free few cases as none, and the rest paid.

Lakenfields apartments, that is.

Something amiss with your edits on this one, per doubled up 10-20, 22-36, 67-75, 76-81 address numbering. Shouldn't they be unique?

Of note, Royal Mail have gone and changed their wording/definitions since I last checked, and lifted what may have been the mistaken text from before. So I no longer take issue with postcodes going on to polygons such as this, but do check buildings to avoid duplicate addressing.

Also houses displaying only name or number, but having both in the addressing system, still benefit from having a name key to express their preferred identifier per installed signage.

Could add access=private to indicate if it is signed private or physical barriers exist to prevent public access.

Probably better to use surface=paved for BitMac surfaces, rather than surface=asphalt of typical driven road material.

addr: prefix is related to the postal address service addressing scheme. The name tag is the commonly known identifier for an object. In the case of a named-only house either addr:housename and name should exist and be the same without nohousenumber=yes to indicate the fact, or if the latter is present then I think it acceptable to just have addr:housename.

However, there are numerous services out there making use of OSM that fail to make use of the addressing scheme and other schemes for suitable name resolution. There's little harm in having two definitions that are the same spelling but for different purposes. It's a sort of optimising for the database approach, instead of just focusing on capturing data key-value pairs.

Sometimes shop names change and the address name lags behind.

The main objection I have to the mass edit you did was that it destroyed the semantic content from some of my previous edits for other cases of name-only houses.

Did you actually take into count the nohousename, noaddress, etc. tags during the dataset build request?

I'm still left manually reviewing and restoring…