For info, I've added note/409387 about this - current tags don't make a lot of sense.

Please don't create "fantasy maps" - use something like OpenGeoFiction if you want to do that. I've removed this in changeset/33126582

node/3019369831 seems to be in the middle of a construction site. Is the construction now completed?

Presumably you've visited all these to verify that these are all in fact operated by Apple and branded as you claim :)

I fixed the key that you deleted in changeset/33109758 .

For info - I re-added the source:postal_code tag that you deleted in changeset/33109391 . Previously it had been misselt, but it was obvious what was meant.

Hello and welcome to OpenStreetMap! Thanks for adding these footpaths in Gainsborough (I don't think that there are too many mappers in that area). One thing that I noticed - way/363050624 isn't joined to way/363050621 . This means that routing software won't be able to get from one to the other. In the editor, if you just click in aproximately the right area it should join the paths automatically.

Hi - just to let you know, I've changed the MMU car park to a car park from a generic area named "Car Park" (click on the thing to change in the editor, type "car park" in the search box, and it comes up at the top of the list). The renderers that display the map need to know the type of something in order to know what to display it as. way/363324872 show what it is now - the tag "amenity" with a value "parking".
Oh - and welcome to OpenStreetMap!

Re way/158177904/history , what is a "building=hut; designation=shed"? "designation" is supposed to be for legal classifications (see designation=*?uselang=en-GB ).

Hi - just for info in changeset/33095500 I change the stiles that you added so that it was actually on the path, not near it, and also so that the stiles were actually part of walls and boundaries, not just near them. That'll give routers a chance to understand whether a particular path has a stile on it or not.
Cheers,
Andy

Thanks for fixing note/400215 !

Thanks - I also had a go at patching up the A580, and also added a note at note/408568 to check the oneways there.

As I understand it, "Mapnik" (the software) just selects data from the database that it is presented with. What gets in there depends on the flags that osm2pgsql is passed when it populates the database, specifically "--multi-geometry". Of the layers on the osm.org site, the "standard" layer has this unset and the "humanitarian" layer has it set. It's that that causes the "multiple labels" thing. Have a look at Paul Norman's blog post about it; that's probably the best description I've seen. I've not seen rendering "problems" due to adjacent multipolygon ways, just the expected label duplication without the --multi-geometry flag and the "only the largest one gets labelled" effect with it, both of which are expected and as documented. Where were you seeing a problem?
For completeness, I have a tile-server set up with --multi-geometry that also renders leaf_type, and that did show Walton Wood OK at least as woodland.
There is an issue logged against osm2pgsql to say "should --multi-polygon be the default"; I'm not aware of an "operations" one to say "reload the "standard" layer with it set", though I think there's been some discussion in github. There are known issues with osm2pgsql/osm carto where a tag causes an item to have a multipolygon created from it but the sql doesn't support it (see the help question mentioning highway=raceway recently), there's a know issue that can sometimes affect roundabouts, and I suspect that when some tags are common and some not we perhaps ought to look at which tags osm2pgsql promotes (but i'm probably best placed to do that and haven't had chance yet).
My problem with the "individual edges making up one or more relations, which in turn form part of a larger relation" is that as things stand it's essentially impossible to edit, even by someone familiar with osm data. A newcomer to osm just wanting to record that "these trees are conifers" would have no chance.
OpenStreetMap's most precious commodity is mappers; anything that we do that makes it less likely for them to edit the map is detrimental to OSM as a whole.

I occasionally check lat 0 long 0 to see if anything has appeared there :)

Oops - something went a bit wrong here. node/3669249923/history was at latitude 0, longitude 0 - I've deleted it.

Also, node/3663553421/history was at latitude 0, longitude 0 - I've deleted it.

Oops - something went a bit wrong here. node/3665217196/history was at latitude 0, longitude 0 - I've deleted it.

(typo - that should be "might need checking" of course).

As you've spotted, changeset/32832749 changed some tags on "Priština International Airport" so that some tags such as "is_in:country=Србија" appeared (and also re-added 3 extra "Priština International Airport" nodes). You've deleted 3 of the duplicates here but some of the remaining tags might checking.

Would it be possible to explain what the problem was with Walton Wood? You've split the outlines of the various patches of woodland into lots of individual ways such as way/362775405, so it's effectively impossible to edit now. Could you possibly explain how what you've done here is an improvement?