* Victoria Drive, not Road

It is. There's a letter box with the house number attached to the gate on the building passage through #154.

Feel free to interpret it that way with your own mapping. Please don't inflict your personal view of how tagging should be "standardised" from an armchair on existing and survey-derived mapping by others.

Also, with your replacement of more specific tagging of traffic_signals=* with the pointless traffic_signal=signal, I refer to to the wiki for that tag:

"traffic_signals=signal - A standard traffic signal, typically with three steady aspects. This is the default value in iD for a traffic signal node. Since this kind of signal is assumed for highway=traffic_signals, please choose a more specific value for a more specialized signal."

traffic_signals=*

Please don't add tactile_paving to crossing ways which do not have tactile paving along the whole length of the way. In common with almost every pedestrian crossing in London, these don't. Surveying the site, or even looking at the Mapillary imagery would confirm this. THe tactile paving is already and correctly mapped on nodes (only).

tactile_paving=*

I see that you have removed the correct crossing=no tag from highway=traffic_signals where the crossing is mapped as a separate node. Please revert, familiarise yourself with the wiki, and desist.

highway=traffic_signals

Also traffic_signals=signal conveys no useful information.

#DWG

I see you have also deleted tactile_paving=yes from nodes at the carriageway edge.

Mapping the actual location of the tactile paving appears to be in line with the wiki.

tactile_paving=*#Use_on_nodes

It is also added by StreetComplete at either end of a footway=crossing way, so removing them is somewhat futile unless you can persuade the developers to remove that quest.

https://github.com/streetcomplete/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/tactile_paving/AddTactilePavingKerb.kt

Hi,

You've added crossing:island=yes to two separate crossings (node/8266616528 and node/1346106463), although neither of these crossings have an island - this is mapped as way/962940056. Is this due to some quirk of VI routing software, or am I misreading the wiki here?

crossing:island=*

When you add separate footways/sidewalks to roads, would you mind adding the tag sidewalk:both=separate (or sidewalk:left/sidewalk:right as appropriate) to the road as well? Pedestrian routing software should be able to use that information to avoid using the carriageway.

Thanks!

sidewalk=*#Separately_mapped_sidewalks

Just to make life a little more fun, the parking:lane:*=no* tags have been moved to parking:condition:*=* (proposal approved on 2022-01-21). Unfortunately, this doesn't work properly in Osmose.

parking:condition=*

Thanks!

Thanks!

A section of service road parallel to Hertford Road appears to be one way in the wrong direction. Does the way need reversing, or is the cycleway a contraflow?

way/669759917

Pedestrians, yes, so it should probably be something like foot=destination. Bikes could physically get round on the pavements, but I don't think I'd want to explicitly tag access for them.

There appear to be two "barriers" on Rewell Street in the TfLCID traffic calming dataset.

RWG043305 is an unspecified barrier (TRF_BARIER=TRUE). After looking at TfL's photographs, it's a gate across the carriageway, but leaving the sidewalks unobstructed. There's no evidence that bicycles are permitted, so perhaps:
barrier=gate + vehicle=private + foot=yes
https://cycleassetimages.data.tfl.gov.uk/RWG043305_1.jpg
https://cycleassetimages.data.tfl.gov.uk/RWG043305_2.jpg

The other feature, RWG043304 is an side road entry treatment (TRF_ENTRY=TRUE). I would probably have mapped it as something like:
traffic_calming=table + highway=crossing + crossing=unmarked + crossing:island=no + tactile_paving=yes + kerb=flush
https://cycleassetimages.data.tfl.gov.uk/RWG043304_1.jpg
https://cycleassetimages.data.tfl.gov.uk/RWG043304_2.jpg

Bing imagery here is not very clear and the gate cannot be seen in available Mapillary images.
https://www.mapillary.com/app/?pKey=297077145411938

Why barrier=yes? TfLCID entries have two photographs showing what sort of barrier is present, if it cannot be determined from database fields. How can a barrier of unknown type have known access restrictions?

Barrier node/9748911676 appears to be TfLCID asset RWG065518, which appears to be a rising bollard from tfl's survey image dated 2017-09-07. This was already mapped as node/6682086798. Unfortunately, TfL's surveyor has incorrectly placed the location of the traffic calming infra to the East of the junction with St Luke's Close, which is easy to confirm as there's a rather distinctive church in the photograph.

A similar set of bollards is present to the East of the junction of Mitchell Street and Helmet Row. This is not recorded in TfLCID, but clearly visible in one of the photographs for the speed table at the junction mapped as RWG064984.

https://cycleassetimages.data.tfl.gov.uk/RWG065518_2.jpg
https://cycleassetimages.data.tfl.gov.uk/RWG064984_2.jpg

I have changed the section of Mitchell Street between St Luke's Close and Helmet Row to highway=pedestrian, deleted node/9748911676 and added the TfLCID refs in changeset/123046010

As all TfLCID entries appear have two photographs taken by their surveyors, there is no excuse for not using that information as part of the conflation process. Many location also have Bing aerial imagery and Mapillary images more recent than TfL's surveys, although in this case trees obscure the aerial imagery and there is nothing in Mapillary.

It also seems absurd that the imported data does not include the TfL ref or the check_date.

@AyushS183 there are two sets of Mapillary images on that section of street. The link you posted is to imagery from 2015!

Please could you confirm whether or not your edits are part of the TfLCID conflation done on behalf of TfL by Sweco UK Limited?

@AyushS183 The problem is that the tool you have used to "verify" the import shows that (advisory) cycle lanes *were* present on this segment of Chobham Road in October 2017, when TfL's surveyors checked assets RWG154882 and RWG155596.

Even the most cursory examination of Bing aerial imagery (date uncertain, but certainly more recent than 2017) shows that the footways/sidewalks have been widened and have cycle pictograms indicating that they are shared cycle tracks.

There is also Mapillary imagery from February 2020 available, as pointed out in my original comment.

Mapping historic "low quality" cycle infrastructure like advisory lanes, when it has been replaced with "better" infrastructure with physical separation, is somewhat unhelpful to users wishing to use OSM maps or data to plan cycle routes.

In the light of recent legislative changes regarding the enforcement of parking and moving traffic contraventions in mandatory cycle lanes (cycleway:lane=exclusive), not importing the type of lane from TfLCID may also be a questionable choice.

Checked on the ground 2022-06-26T12:45. Corrected in changeset/122865564

The southern end of Water Lane (way/1064067306) is tagged as both cycleway:both=no and cycleway:left=lane. Please could you clarify which you believe to be the case?