I'll have a go at sorting out the duplication in Old Cleeve itself.

Re the A39, where the "name" of a road starts and ends is often an interesting question, and sometimes what the locals think isn't the same as what the council thinks. Assuming that you're local, I'd say that you and other people in the village were best placed to say where "Station Road" starts and ends.

You can have a look at what the council thinks by looking here:

http://ris.dev.openstreetmap.org/oslmusicalchairs/map?zoom=16&lat=51.1680&lon=-3.3758

They think that Station Road extends further - but that could be a slip of the mouse on their part. If there's a section that definitely isn't called "Station Road" but the council think is, it's usual in OSM to add a tag such as "not:name=Station Road" to let other mappers know that whatever the council think, it's not really called Station Road.

I can revert them if you like (just the ones that duplicate names presumably, not the ones that remove the road name from the A39)?

Something seems to have gone wrong here - way/318394755 (a residential road) is a duplicate of a number of others, including way/28614477 (a tertiary road). If you're wondering why the name display in the village is wrong, it's this duplication that is causing it.

I presume that the path way/318375088 shouldn't join the aqueduct way/309142169 (because one is underground and one isn't)? I suspect that the join was automatically added by the editor (which is usually a good idea, but not in this case).

The changeset comment here is just "fix cycleways". Can you describe in a bit more detail what you've actually done? In the case of way/237210198/history you just seem to have removed one tag. Have you contacted the mapper who originally added that tag explaining what you've done, so that they know who best to tag cycleways in the future?

It'd be a shame if the OpenSeaMap renderer couldn't render "ordinary OSM tags", if there already a form of tagging for that thing in OSM already. Tagging something as both "foo=value" and "seamark:foo=value" is obviously a duplication when the value is the same, and leads to the possibility of contradictions (if e.g. a value changes, will ordinary mappers know to change "seamark:value" as well?). Is there a bug tracker for the seamark renderer anywhere where these issues can be discussed?

There is (and has been for many years) debate about tagging of woodland - whether "natural=wood" means "there are trees" or "this is a primeval forest". The problem is even documented on the wiki page:

natural=wood

What about way/76823138/history - did you survey that yourself to see that the trees were indeed broad-leaved? The mapped trees don't really match the imagery, so I suspect that more surveying might be needed here in any case.

Looking at the imagery, that does look quite a stretch. What's certainly true is that the ways that are mapped there don't really match the imagery at all well. In cases like this, perhaps an OSM note would be the better option, rather than just arbitrarily changing the tagging? That way local mappers can see that something there "isn't quite right" and go and have a look on the ground.

That just means that someone who was following a proposal through on the wiki decided to stop doing so (back in November 2008, as far as I can see). It doesn't mean that it's OK to change the tags on all the features that people have mapped in the last 6 years.

There are a number of reasons why osm.wiki/Mechanical_Edit_Policy says "Discuss" as the first step - one is so that mappers are aware of alternate taggings for something (and just because someone's updated a wiki page it doesn't mean that it's "accepted" tagging).

Also note that you changed "parking=park_and_ride"; the wiki page that you refer to was actually about "amenity=park_ride" - a completely different tag.

Note that this appears to be one of a series of mechanical edits, in some or even most of which information has actually been lost. See changeset/27658932 as an example.

In way/176939271/history you seem to have removed all indication that there was a grassy area between the hotel buildings and the car park. Was this deliberate?

Also, in your change to way/76823138/history you seem to be under a misapprehension that a deciduous tree is necessarily broadleaved. It isn't - see http://en.wikipedia.org/wiki/Larch .

You've changed way/191683850/history from "natural=woodland" to "landuse=forest". How do you know that landuse=forest is the appropriate tag here and not, say, natural=wood?

You have removed the "natural=swamp" tag from way/134760983 . Was this as a result of a survey?

Your changeset comment here suggests that the parking sub-tab is obsolete. Can you point to where the discussion about that took place, please?

Re way/47328415/history how did you know that "landuse=forest" and not "natural=wood" was the appropriate tag here?

Re the second point (presumably you were referring to way/120036342/history ) there are two reasons why it is important than mechanical edits are discussed before being carried out. One is so that the previous mapper knows that they've used a tag that means the same thing as another key but is spelt differently (e.g. video_game vs video_games). The other is that people do actually use this data - they might have code somewhere that looks for "video_game", and if you change the tag without telling people, things will disappear from their extracted data or map without them knowing why. That is why osm.wiki/Mechanical_Edit_Policy has "Discuss" as the first requirement.

Re the "manual editing" - have you actually surveyed (i.e. visited) each of these shops to make sure that they're part of the same video game shop chain, and are not e.g. an unrelated toyshop called "GameStop"?

Hello, this appears to be a mechanical edit of a large number of shops based on shop name. In some cases the shop tag has been changed, for example:

node/1784628850/history

In the cases where you've changed the shop tag from one perfectly valid shop tag to another, have you verified by an on site survey that the new shop tag is correct?

In cases where you've changed the spelling such as way/120036342/history have you discussed the spelling change with the previous mapper so that they know to update their maps? This is not a theoretical question; in this particular example the previous mapper _does_ maintain a map of the area and one of the overlays is local retail.

What possible extra information does "seamark:type=cable_submarine" add to something like way/78434602/history that is already mapped as "communication=line; submarine=yes"