That seems very unhelpful. Public footpaths do cross private land. That they do does not make the land public, only the route of the public footpath itself. Hence foot=designated overriding access=private.

Pavements are usually surfaced with bitmac (bitumous McAddam), not concrete asphalt. surface=paved is fine for the user agents to understand suitability. Could always use surface=bitmac or surface=bituminous.

Tarmac is the company name, tarmac with a lowercase has been used by some to mean the material associated with the company (often bitmac from paving-sized jobs).

I just don't see the value gain from switching from 'paved' to something technically incorrect. It would be better to remain generically known as, well, not un-paved.

Shouldn't StreetComplete just simplify the choice to unpaved/paved? There’s already a specific value paving_stones.

surface=*
The guide actually mentions bitumen in 'paved' and 'asphalt concrete' for asphalt.

The value 'tarmac' might be a better fit, though only 268 uses in taginfo.

It just bugs me, since it isn’t asphalt.

Isn't paved value closer to BitMac (bitumous McAddam) as used on pavements than asphalt? (as in hot-rolled road surfacing)

Some pandemic confusion there it seems, as the farm butcher signage appeared there at the time. I've corrected things up.

A technical point, but surface=paved more accurately describes BitMac (Bitumous McAddam) as often used by pavements, than asphalt often used in roads.

It would be good if when adding cyclepaths that are shared pavements that you use tag combination: highway=path,surface,foot=designated,bicycle=designated,segregated=no,path=sidewalk=* - instead of highway=cycleway. Those sections of route aren't primarily for cyclists, rather cyclists have been given the right to use the pavement.

It was 7 years ago. It looks to have expanded into the adjacent building number since, now 62-64 in addressing. The postal city possibly originally wrong, have corrected to Lowestoft.

Perhaps remove path=right, path:surface=grass etc. tags from adjacent road way when explicitly mapping.

operator="UK Power Networks" too?

Not Cawston on review, actually Corpusty and Saxthorpe area.

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).