I'm just looking at a rough average of all the underlying GPS traces (and knowing from survey there that they're likely to be more accurate than Bing). Unfortunately the offset varies every 100m or so so you really do need to keep nudging imagery to traces (and keeping an eye on paths that have moved and discounting traces from those old paths).

You'd want a bit more evidence that a road actually was a roman road beyond the name, though surely?

For an example, not far from me way/145006134 is called "Roman Way". There's obviously a roman naming theme going on there (Fosse Close and Dere Croft are nearby), and it's adjacent to the A6005 (actually a roman road), but "Roman Way" isn't itself one.

Are you sure that way/187303525/history#map=16/51.2519/7.6026 is an actual Roman Road as suggested by https://www.wikidata.org/wiki/Q194029 ? Also, what does "name:etymology:wikidata" mean in this context (and what's the relationship to the Queen Fabiola mentioned in the changeset comment)?

This is a huge changeset. Would it be possible to describe in more detail (for the benefit of local mappers) what you changed and where, and what the source was?

Also, would it be possible to use a more descriptive changeset comment than "POI changing" so that other mappers know what's happening?

What was the problem that you fixed? "Fix hardwick road" doesn't really describe what you did here. Also, be aware that roads and car parks have been moved relatively recently here and therefore old GPS and imagery information may not be correct.

Is way/369938352 a real power line? Note that tagging on the adjacent way/358412474 - I'd suggest talking it through with SK53 (who mapped that).

Unfortunately the imagery's offset here so you've moved the road south of its actual position. Also do be aware that the paths around the canal basin have moved recently to accommodate canal works and Bing may not have those up to date either.

Where was the kink in the road? It might be easiest to revert this changeset and fix manually.

The change to way/166727689/history looks wrong to me. Just using semicolons to combine values is often not the best way to decide how things should be tagged. If something is both a pub and a restaurant I won't tag it as "amenity=pub;restaurant", I'll survey it to see which tag best fits - is it a restaurant or is it "amenity=pub;food=yes"? In the case of way/166727689/history did you either survey it or contact the original mapper to find this out?

Hi - I've changed the tag here back to a note. Have a look at the other ways nearby to see the context and what's recorded in notes (e.g. way/358505254 ). Once all the area has been covered (which would need to happen in winter to sort out any patches of larch) then there may well be more tags to add, but until then it makes sense to keep all the notes separate.

Hello and welcome to OpenStreetMap!

What does "dfspbofv" (the changeset comment) mean? Normally what people add there is something that describes the changes that they are making so that other mappers can see what's happening. In this case that's made more difficult by the size of the change (covering a very wide range of longitudes) too.
Cheers,
Andy

Hello and welcome to OpenStreetMap!

I think that something went wrong with buildings such as way/369965052 in here. Also, what was the source - it clearly wasn't traced from Bing, as there is no Bing imagery in most of the area covered by the building?

Which router were you using? I'm guessing that it might be just a matter of time before it updates its data (things will appear on map tiles before the router data updates)

Also adding Cuckney Hay Wood as "landuse=forestry" (to distinguish the managed area, including cleared sections, from the area covered in trees)

Thanks. Can you link to where in the forum it's been discussed? It doesn't seem to be searchable by forum, and of course "geoportal" is something that exists in lots of places in lots of language forums.

I don't think that it's necessary to revert (from amenity=fitness_center to leisure=fitness_centre isn't a change of meaning, just fixing a typing error), but I'd certainly recheck the items in the changeset. If someone's got one thing wrong then they might have got others wrong too (for example, way/254447913 looks like it is missing a building tag). I'd also explain to mappers who are still current mappers what you've done (in a polite and friendly way), so that they know what the correct tag is and will use it next time.

If it helps, here's an example of what I've done nearer to home:

way/250738518

Survey and map all the field boundaries, gates, stiles, hedges and fences first, then reuse the fence / hedge nodes for a separate farmland way. It's not the only way to do things - just providing it as an example.

relation/5494099#map=19/51.42139/-2.44548 certainly looks a bit problematic, in that there seems to be an unfeasibly thin bit of the natural=wood to the east of the stream. I'd suggest that it doesn't make sense to use a multipolygon for this area of woodland at all - it just looks on the imagery like one area. If there's a choice between using a multipolygon to represent something and not using a multipolygon, using a multipolygon is almost always the wrong answer for all sorts of reasons, including ease of maintainability going forward.

For info, the buildings on Sowters Row and Palmersgate didn't overlap the road as much as previously mapped. See changeset/33896631 .

For info, I've fixed the buildings on Sowters Row and Palmersgate from survey in changeset/33896631 .