Please do add some commentary!

While INSPIRE IDs do strictly speaking apply to the whole extent of the property, the same could be said to of the UPRN and even the postal address.

Where there is only one addressable building within an INSPIRE polygon (a single freehold property) and only a single UPRN, then I feel that in those cases the building can stand as a proxy for the whole property.

I'm not committed to including INSPIRE IDs, but if there isn't strong opposition I'd be inclined to include them as the link between INSPIRE ID, UPRN and postal address is something for which HM Land Registry charges a £20k/year subscription.

I saw you mentioned it on another changeset and meant to download it. Thanks for the reminder - I've downloaded it and will give it a go shortly.

Slightly related to this, I'm drafting a proposal to import postcodes from ONSUD, UPRNs and INSPIRE IDs.
osm.wiki/Proposed_import_of_UK_postcodes,_UPRNs_and_INSPIRE_IDs_(England_%26_Wales)

The centroid for postcode NN7 4AS in the Postcode Centroids overlay in iD places this on Nene Way, Kislington (add:suburb - non-dependent locality), Northampton (addr:city - it's the post town). It can't be the postcode for properties on both Willow View and Bugbrooke Road.

I'm not sure that lanes=0 is appropriate here, as it's at best ambiguous. The road is already tagged with lane_markings=no

lanes=*#No_lane_markings

Do you have permission from the architect to use this information in OpenStreetMap under a compatible licence?

osm.wiki/Copyright

I suspect you'll find a few more of those in that general area, by the same user. They don't seem to reply to changeset comments, but they do appear to respond by changing how they map objects.

If both segments of the road have the same tags, merging them is generally fine and makes life easier for others.

Some highways are split because segments are members of relations like bus and cycle routes, or restrictions like prohibited turns. Hopefully editing software like iD will complain if a merge might break a relation.

You asked for a review of this changeset. The merge of the highway segments looks fine to me. Thanks for adding the parking information as well.

Broken in what way? What did you do to attempt to fix it, before summarily deleting a relation which has happily existed for over 12 years?

Please revert your changeset.

Please don't tag for he renderer.

Some objects in OpenStreetMap are not rendered in the standard OSM Carto tiles. There may be other layers which render them, or you may have to query them using Overpass Turbo.

osm.wiki/Tagging_for_the_renderer

I have reverted this changeset.

Hi,

Thanks for all the work you've been doing on this project.

However if the pedestrian crossing is a signalised crossing, please could you revert back from crossing=marked to crossing=traffic_signals, as making it more generic is a loss of information?

The markings at pelican and puffin crossings are dots rather than dashes, as prescribed by Schedule 14 TSRGD 2016, so crossing:markings=dots should be used rather than crossing:markings=dashes

It's arguably redundant, but it wouldn't hurt to add crossing:signals=yes as well, as iD based editing software has a habit of trashing (sorry, "upgrading") the value of crossing=*

Adding wheelchair=no alone would have achieved this.

If the surface is grass, as it appears to be, adding surface=grass + tracktype=grade5 would be useful.

It's obviously not informal=yes, as that implies a desire line path, not a planned path in a landscaped garden.

For access tagging the defaults of highway=footway + foot=customers were correct. Setting foot=yes implies a public right of way, which is clearly not the case within the grounds of RHS Wisley.

I cannot see any steps on the aerial imagery and a SAC scale of mountain_hiking (terrain is steep in places and may pose fall hazards) seems improbable.

Please only tag what is actually there and resist the temptation to add fiction in order to influence the behaviour of rendering or routing software.
osm.wiki/Tagging_for_the_renderer

Many thanks.

You appear to have tagged several section of roads as foot=no in response to a StreetComplete task asking "Are pedestrians forbidden to walk on this road here?"

I'm trying to find any evidence in Bing Streetside imagery that there really is a (signed) pedestrian prohibition in any of these locations. I cannot see any TSRGD diagram 625.1 "pedestrians prohibited" signs on the imagery, so do not believe that a prohibition exists. Is this a new signed restriction created by a traffic order more recent than the Bing streetside imagery?

The wiki states that access tags reflect legal access. Subjective opinions about whether it would be pleasant, a good idea, safe, etc. for a particular transport mode are not relevant to legal access.
foot=*

As real pedestrian prohibitions on public roads other than those tagged as highway=motorway or motorroad=yes in the UK are quite rare and are always signed, this quest is probably better left disabled.

Reverted, see discussion in changeset/153312735

My apologies, reverted.

Welcome to OpenStreetMap.

I have removed the public right of way (PRoW) tags from your informal path edge diversion.

Lambourne FP11 follows the route across the field which is clearly visible in the Bing aerial imagery and in the Essex County Council PRoW GIS data.

https://osm.mathmos.net/prow/progress/essex/epping-forest/lambourne/

Can I assume that you are using highway=service + area=yes polygons around a highway=residential line, despite the fact that this is clearly incorrect tagging, because this renders in the OSM Carto tiles?

If so, please don't tag for the renderer.

While area:highway=* is not rendered in OSM Carto, it is still more "correct" for the non-routable 2D area of parts of highways.

osm.wiki/Tagging_for_the_renderer

That seems reasonable, as I would probably tag an address in Seven Kings with addr:suburb=Seven Kings + addr:city=Ilford.

Welcome to OpenStreetMap and thanks for adding your business to the map.

Unfortunately, you also changed a residential area polygon into a single and very large building. As aerial imagery show that this is not the case, I have reverted that part of your edit.
way/110505656