Please note that the Bing imagery is not well aligned in this area. Whenever you see every way and building offset by the same amount in the same direction, it is the imagery not the existing OSM features that needs to be moved. (Scroll down on Backgrounds tab in iD to see the adjustment tool). The background OS_OpenData_StreetView is also useful as a point of reference.
Also please note that a significant use of OSM is for routing, this requires paths etc to be properly connected, do not disconnect ways that you can walk (etc) along.
Also please find out about 'relations' and how things like walking routes are mapped, eg see:
relation/6143527
Be aware of these (same approach is used for bus routes etc) and try to avoid breaking them, and do not put names that belong on these on the paths/roads etc that make them up.
Also try to avoid merging nodes eg dragging post boxes onto a road line, merging footpath with fence, iD will merge close nodes without really telling you, if in doubt zoom in and check what is really present near your changes and make sure the right things are joined, and others not.
I've had to reverse quite a few of your changes, hopefully things are in a good state now.

Hi, the imagery OS_OpenData_StreetView does show the tunnel line under the main road if it helps. I'm guessing there are two footways, one on top of the other on the line you now have, one ramps down to the tunnel, a second ramps up the other way to the bridge to the car park roof grass?

NO, deleting existing data is not ok, the station serves both lines and is correctly labelled. You've added underground lines and are currently interested in them, but that does not mean that they are the only lines. I mentioned that there would be other values like Overground etc in the list in almost every comment I made.

Please take care to notice if all the roads and buildings all appear to be off by the same amount in the same direction, then it is likely the imagery that is off, not the OSM features. As an example, please note that even the nice new Bing imagery is quite poorly aligned around here, eg look at the roundabout and buildings at the north end of this changeset. If in doubt, a quick look at the OS_OpenData_StreetView layer if mapping in the UK is useful - if you see good alignment of OSM ways/buildings with that, then move imagery to match these features not the other way around.

Again, imagery used labelled as "Esri World Imagery;Bing Streetside;Mapillary Images;Mapillary Map Features;Mapillary Signs;OpenStreetCam Images",
but service way added with source=maxar
and grossly misaligned as using unaligned Esri imagery.
Is there any reason why all of your changesets should not be reverted?

In this changeset, the imagery used is labelled as "Esri World Imagery;Bing Streetside;Mapillary Images;Mapillary Map Features;Mapillary Signs;OpenStreetCam Images;Esri World Imagery (Clarity) Beta;Mapbox Satellite", yet you have added 2 ways with source=maxar, and positioned then aligned with unaligned Esri imagery which is clearly way out.
Do you have the slightest control over what you are doing?

NO the node you indicate looks perfectly tagged.
I would start at:
osm.wiki/Public_transport
for information on public transport tagging.

I do not know where that page you refer to has come from. Looking at the history it seems to be the work of a single individual, before that a different? (or same with different account?) individual.

OSM has consistent mapping across the world, there should be nothing conflicting in any local advice, just expected standards or maybe making a choice if there are different possible ways of doing something.

I see a few some tram places mapped as if they were railway stations which I think is wrong. It is my understanding that there should be a stop_position on the track. There is no direct equivalent of railway=station for tram stopping places.

All done, actually used the normal JOSM upload command rather than the 'upload selected' I'd meant so all went in one go, but all is well. All the 'tflLine' is gone and looks like every station has 'line', any existing data that had comma separation was adjusted to semicolon so should be good to use.

The tool http://overpass-turbo.eu/
is nice (but complicated!) for querying data, best thing is to start by running the wizard on something simple like railway=station. Once you have a working query it's possible to hand edit the content. adding extra conditions on the line acts as a filter ie 'and' logic, adding extra lines (in the right places!) is additive ie 'or' logic.
I was playing with various combinations of
node["railway"="station"] ["station"="subway"] [!"tflLine"] ["line"]
where '!' means logical 'not', to see underground stations with or without line and/or tflLine (by adding one or both of those last two conditions with or without '!'s)

The other tool I used is JOSM which is an editor with all sorts of capabilities, and I did a certain amount of (careful, manual) text search-replace and cut and paste.
The most important thing with editing other than completely manually within an editor user interface is to follow what is intended in osm.wiki/How_We_Map
including the bottom-most link on automated edits - which this comes close to, but the important issue is that each change here has been manually checked - I've looked through (actually twice) a list of the data changes to ensure no surprises. What's not allowed is to apply an automated process to data, check it for a few cases and then hope for the best with all the rest.

I'll apply the rest of the changes, I'll do it in a few chunks so each changeset is not too large, either spanning too large an area or numbers of stations.

No need, I have the data. Can you have a look at changeset/91010652, I find this tool useful:
https://overpass-api.de/achavi/?changeset=91010652
If you look at changed dot markers, the tags are in alphabetical order so 'line' is near the top above 'name', not always highlighted if no change, the 'tflLine' down the bottom so you may have to click the dot and scroll down too see it, left=old, right=new obviously.
This contains 10 of the stations including some that had 'line', some where it wasn't there. Any reason this wouldn't work for you if done for all?

Thanks for the reply Aman Saraf. Sorry that my message yesterday was a bit abrupt, I was primarily hoping to stop you doing a lot of editing we may have had to undo. But the added data seems very precise and consistent so I'm sure it will be useful however it ends up.
Yes, a lot of the choices in OSM are based on consensus and consistency not on any written rules.
For me the big choice now is whether you can happily use the data if we were to make it consistent with the existing OSM data, ie under key 'line' with semicolon separated names with upper case eg "Circle;Hammersmith & City" etc. If so, I am prepared to move the data over (actually this can be done in little time). Then we have merely made an existing tag have more complete and consistent data which is unconditionally a good thing. But then your interface between OSM and TFL has to provide a mapping of identifiers (but perhaps this is exactly what the interface should do?).
Alternatively, if you really want to store more/different data in OSM then we can either just leave the data there and see if you get other feedback/questions/challenge to it, or can put a message onto the talk-gb mailing list and see what people think. You guys would need to be ready to describe what extra benefit you'd get from having this data under a special key and with particular values, but I think the similarity with 'line' and using nearly-but-not-actual names would require some convincing argument. There are tags for other systems' ids - eg wikidata and fhrs come to mind - but they tend to be reference numbers not nearly-the-names, and stored once on the object they map to/from.

If 'line' is going to work for you (provided the data is complete and consistent) then that is is direction we should go, and move the new information you've added (but with uppercase and semicolons) over from 'tflLine' to 'line' where missing.
There will be some with "Overground" in the list and "Northern City" as previously mentioned is currently there. This last one confused me as I thought it referred to a branch of the Northern line but I see at https://en.wikipedia.org/wiki/Northern_City_Line
that it is something different.

Sorry, my comment on abbreviations wasn't a good example, I only meant to avoid your "hammersmith-city" values and use "Hammersmith & City".

Regarding bulk editing: for most purposes, it's important to use the normal editors in the normal manual fashion, it stops people getting into too much trouble and ensures every edit is checked not automated. However I think I can see a way I could carefully edit this data without another 270 changesets once we're happy.

Thanks for your prompt reply. Sorry if this reply gets a bit long, quite a few things to mention here.
First I should say that if the data is as consistent and accurate as it appears it is a valuable addition and is not doing anyone any harm by being there for the time being, but may need to be adjusted to match OSM practise. I did comment to Aman Saraf (after the first ~106 edits I think) but no reply and the edits continued.
The key tflLine is a problem due to duplicating 'line' and not following OSM naming conventions. 'line', while undocumented as a regular tag for railway=station seems to be in use in Kiev,Berlin,Denver and a few others as well as London.
Regarding the values, pretty much all the data in OSM (with obvious exception of 'description','note' etc free text) is potentially machine readable, with semicolon the usual separator for multiple values. The existing 'line' values match this (but not the one you added here). Also OSM uses names with upper case first letters, unabbreviated in almost all cases eg "Hammersmith & City". So the 'line' values are semicolon-separated lists of line names, potentially exactly what you are looking for.
You didn't directly comment on the purpose of adding this data, if you are looking to integrate OSM data with other systems/data can you cope with a lookup table from OSM names to TFL ones? I did note some stations with existing line values of "Northern City" which you could also map to your "northern" if the branch is not useful for you?
Other thoughts: you are at the margins of being involved with what OSM refers to as 'organised editing' see osm.wiki/Organised_Editing_Guidelines
and also skirting close to the description of data imports in osm.wiki/How_We_Map
If you are not just personally adding data for benefit of OSM and its user community, (or if this discussion gets any more complicated than I've just made it!) can I point you at the 'Talk-GB' mailing list https://lists.openstreetmap.org/listinfo/talk-gb
where a wider group of the OSM community can advise on any of this stuff. When its decided what's best to do, the data can potentially be manipulated without having to re-edit each station individually.
regards
Cebderby (Clive)

No reply; reverted

No reply; roundabout merges reverted, non divided way and alignment improvements reapplied.

What is the purpose of adding the unrecognised key "tflLine"? It is clear from this edit that you have seen the key "line", which is already present on 80 or so stations. How does this relate to the approx 270 subsequent edits of user Aman Saraf to add tflLine to each station?

Stop the vandalism
기물 파손 중지

Stop the vandalism
기물 파손 중지

이 사용자의 모든 수정 사항 검토

You should stop now as all these changes will have to be reverted.
tflLine is not a recognised key, nor is it correctly capitalised for a key.
The values you are adding are also not acceptable for capitalisation or multiple value separator.
A key does exist for this concept, but you have not bothered to look for it, even when it exists on stations you have edited.