Hey, I've been aligning to an offset of 4.1, -1.7 within this end of London, so we aren't far off.

I wasn't aware of the new boundaries though, do you have a link to a reference? I got my offset above from a mix of GPS and landmarks, so another source would be useful.

Unfortunately iD doesn't nag people to check offsets like JOSM does, so everyone else still seems to be mapping to the uncorrected imagery :(

Hi,

You appear to be aligning a large number of changes to the Bing imagery. This imagery has a significant offset over London, which means the data generated will also be offset unless corrected for. iD has a setting for this in the layers page at the bottom.

The offset that myself and others seem to have settled on is approx 4.1, -1.7, but you should validate this yourself with a known-good source in the region you are working on.

For example in this changeset, the prison to the east is aligned to the older Bing imagery, which did not have such a major offset issue.

If you find that you are moving a large number of roads/buildings by a constant amount, consider that the existing data may be correct and the imagery itself may not be.

Once again, the Bing imagery has an offset. The old positions of these buildings was likely correct and the new position is likely not. The roads now also jump between two alignments.

As others have asked for, please also use a more helpful changeset description.

The Bing imagery has an offset over London, meaning the old position of King's Road was likely correct. See https://learnosm.org/en/josm/correcting-imagery-offset/

I've just amended the building in changeset/98514238. Perfectly happy for you to amend if I've got it wrong. Thanks

No worries, I’m glad you spotted it :)

I see now where it went wrong by connecting back between the gap. I’ll have a go at rebuilding this later today with building parts. Do you mind if I then ask you to take a quick look once done?

Hi, I hadn't realised this was self intersecting, but this wasn't necessarily a duplicate building. It's a ~3 storey base building with towers sticking out the top. The gardens you see on imagery are actually on the roof of the base building, so presently only the towers are remaining. What's the best way of tagging such a building? building:part?

This is not correct, please stop making these changes

I don't intend to disuade you from editing; I had the exact same situation before I learned about the offset :)
It may well be that you have the data to prove the existing data is misaligned.

I previously retouched some of these roads last month and matched against the GPS data tiles and local GPS data. The offset used was approx 4.1, -1.7 against the Bing imagery.

Also note that sports GPS devices often have somewhat variable accuracy and are optimised to track movement rather than absolute position. So they may display drift from true position whilst under tree cover or between buildings. e.g. it's common to see GPS track data 'undershooting' or softening a sharp corner as the device attempts to make sense of poor quality reception.

Hi. The updated Bing imagery has an offset from the existing mapped data. If you find yourself making bulk shifts of data, it's often an offset in the underlay imagery rather than bad data in OSM. The offset should be calibrated in iD with a known-good location prior to making edits. Thanks!

As mentioned in the comments here changeset/75952360, these buildings were apparently the ones under construction, not the ones demolished. I restored these previously after there was no reply.

Hi, I believe crossing=zebra was the correct value for this crossing, unless it's been changed again recently?

Hi,

This is not a sports centre, I have had to fix this once already. Please see tagging guide leisure=sports_centre which states: "The swimming pools themselves are marked with leisure=swimming_pool", or in this case, "paddling_pool"

Hi, this building also already exists as way/4959489, under its formal name: way/4959489

Hi, this building already exists as way/96937598: way/96937598

Of course, I was just considering the eventual options for tags; I’ll leave widespread re-tagging to yourself or others, as you seem to have a better handle on it all.

Interesting, I’d heard the blue paint may be reconsidered, but only rumours. It seems crazy to repaint it all though and, for the sake of partial consistency (with previously published maps etc), I hope the suffix number remains consistent. I’ll keep an eye out for changes on the ground.

Thanks

Ah OK, I hadn't found that part of that press release, I'd presumed there'd be a more specific one. The use of Cycleway 3 is indeed suggestive of their intention to get everything getting renamed at some point.

When eventually retagging the live routes, is the 'proposed:name' -> 'old_name' method the correct way to go? The same looks like it can be done for ref, although it's not yet clear what the new ref might be.

Thanks!

Has this been confirmed as applying retroactively to existing infrastructure and with the naming scheme as now mapped? From the source: "We are checking with the Mayor’s office whether existing Cycle Superhighways and Quietways will have their names changed to Cycleways, or whether the rebranding just applies to future infrastructure."

From the TfL website, the on the on-the-ground infrastructure and the existing consultations for proposed routes, the branding currently remains as 'Superhighway', 'Quietway', 'CS#' etc: https://tfl.gov.uk/modes/cycling/
Looking at the TfL and london.gov press releases, I don't yet see anything concrete about the change, besides that one site used as your source.

I'm not saying this isn't going to eventually be correct, just perhaps a bit early when none of the infrastructure or branding has been updated or formally announced when/how it will be updated? Presently the map now reflects how the network might look based a proposed change, rather than the current nature of the infrastructure and branding.

Perhaps the new names should be tagged as 'proposed:name' (proposed:name=*) and then flipped to 'old_name' (old_name=*) after a more concrete timeline is announced?

Ah, I missed that line from the key:phone wiki page. Non-01/02 numbers have been corrected in 67314927.
Thanks.