Would it be possible to describe what the "impossible angle" was before here? http://osmhv.openstreetmap.de/changeset.jsp?id=33101616 doesn't really show a lot of difference. The resulting roundabout still looks a bit overnoded and too big for the imagery.

I'm not sure what "Highways were aligned" means - which highways were aligned with what?

Is way/360068810 perhaps a duplicate of node/286729671 here or are there really two separate lighthouses very close together?

way/343968534 seems to be a duplicate of node/1843715253 here I think?

I'm guessing that perhaps way/360312015 could do with leisure=pitch so that everyone (including renderers) know that it's a basketball court (if that is indeed what it is)?

Just checking - is way/285616183 really named "Tunbridge Wells Circular Link Route"? It's already part of relation/3788347 ("Tunbridge Wells Circular Walk (Speldhurst Link)"). If it doesn't have its own, separate name there's no need to create one for OpenStreetMap.

Hello - if way/364200996 is Part of West Deane Way, then I'd create a route relation for it and add this footpath to it, rather than giving it a name "Part of West Deane Way". That way when the other parts of West Deane Way are mapped it'll show up on sites such as http://waymarkedtrails.org/en/?zoom=12&lat=51.04377&lon=-3.14052&hill=0# (you can see bits of West Deane Way there already). Also, it doesn't quite join the road at node/3682657825 .

Hello! You've recently added way/333321438 to the map. In order that it gets recognised as what it is you'll need to give it some sort of tag. Currently it's just a building type of "Playgroup". Perhaps "amenity=childcare" or one of the alternatives described on
amenity=childcare would work? In the editor if you type "playgroup" into the search box at the left it'll sort it out for you.

Thanks.

Re "But to a piece of software they look exactly like your sub-woods!":

According to http://osm.mapki.com/history/relation.php?id=5353764 the osm.org/browse/changeset/32539732 version of the relation clearly shows one multipolygon relation with multiple way members with the role "outer". If whatever QA software you're using can't tell that from missing relation roles, (which are indeed a genuine issue) then you need to fix it.

To be clear - previously what was mapped was Cuckney Hay Wood (a relation) consisting of multiple non-overlapping polygons, each with role "outer", so your "specific example" does not apply here. Humans (as SK53's comments above confirm) had no problem understanding what had been mapped; osm2pgsql with the -G flag set either way also had no problem; once the data was in the database, the renderers also had no problem.

The basic relationship of different sections of trees forming part of one wood has been removed by your edits, and no we no longer have a model in OSM of what is actually there on the ground.

Currently the way that you've mapped these simply doesn't represent the situation on the ground. If I don't hear a _specific example_ of the problems caused by the original mapping here I'll change Walton Wood and Cuckney Hay Wood back as they originally were when I next need to edit them. Because you've used exceptionally wide changesets, this may affect other items.
As I've said before, (and many other people have said before me) OpenStreetMap's scarsest resource is mappers - changes like this to Cuckney Hay Wood and also to Walton Wood prevent mappers from mapping and are actively harmful to the project. Please, before making any changes such as these, ask yourself "how does my change help mappers to continue mapping this area"?

Hello - is node/3672160848 part of any other way (I'm guessing it's at one end of the steps)? Currently as mapped it's a "free floating" stile that's not part of anything else.

There's lots of "mays" and "coulds" above - like I mentioned previously on the "Walton Wood" changeset ( changeset/32932368 where I explained the usage of osm2pgsql's --multi-gemetry flag ) I'm reasonably familiar with osm2pgsql's historical behaviour with multipolygons* - can you provide a _specific_ example of a real-world problem caused by the previous mapping here?

* see recent osm2pgsql github discussions for chapter and verse - multipolygon handling is by no means a "solved problem" there.

Hi - just wondered what the actual change was here - http://osmhv.openstreetmap.de/changeset.jsp?id=33113079 shows the road being straightened a bit - is that what "Fixing kinks Roads" means? Also for info a look at the underlying GPS traces suggests that the imagery might be out a couple of m n-s in at around Craggon Drive.

Re "For a valid multipolygon, two rings *must not* overlap" - can you explain why not? What real-world problems does it actually cause?

(re JOSM) I regularly use it for tasks that it can manage, but its waypoint support is abysmal (see https://help.openstreetmap.org/questions/7675/josm-is-it-possible-to-convert-an-individual-waypoint-in-a-gpx-file-to-a-node ) so it simply isn't an option for most of the survey-based mapping that I do. Also, its rendering of route relation memberships is very poor compared to e.g. P2, and it doesn't render duplicate nodes at all well (I regularly have to "bucket and shovel" local areas edited by JOSM users of dupe nodes before adding what I came to map in the first place).

Also, I'm not sure what happened, but here you created relations such as relation/5347057/history with no tags and no members.

Any idea what the access rights on way/341760687/history etc. are? Also is the surrounding woodland still extant?

I'm not convinced that there really is a footpath entirely separate to the service road here. I suspect that it might be a public footpath (i.e. a foot right of way) along an otherwise private road. Also FWIW the stream doesn't match OS_OpenData_StreetView here (it's from NPE). I'm not sure how many mappers there are local to here, but its prime holiday season and half the population of London will whizz down the A30 at some point in the next few weeks - maybe one of them could be persuaded to take a look? :)

Like you did with Walton Wood elsewhere, you've also broken Cuckney Hay Wood in this changeset, so that it's impossible to edit. way/359674431/history was previously a polygon of a specific type of trees; you've made it into one edge of a relation. Similarly there's no indication now that way/359674428/history forms part of Cuckney Hay Wood at all - this was present (see http://osm.mapki.com/history/relation.php?id=5353764 ) until your edit.

I would at some stage like to continue mapping both of these areas but it will be impossible to do so until you undo your changes. Maybe since you have made it impossible for other people to edit these areas your are going to do the surveying yourself?