again, do not add descriptions as names, please remove

Do not add descriptions as names, please remove

In OSM, places like this are normally mapped as nodes as the boundary is rarely verifiable. Please read
place=*
---

Published using OSMCha: https://osmcha.org/changesets/91222606

Hi Simon270,
There's a nice tool:
https://overpass-api.de/achavi/?changeset=91189397
(keep the link and just change the number on the end to see other changesets) where you can see what all the tag values were before and after, so you can put things back as you need to. You can have a gate as a point on a way, but sounds like a fence is right so you can draw a line across the track (including a node shared with the track) and tag that as fence. You can also usefully divide the track and mark the inaccessible part as access=private if you know how much of it is likely blocked off (or just mark a short length of the track as access=private the other side of the fence) then no-one should get routed along it.
Cebderby (Clive)

Hi Weretom,
Welcome to OSM. You managed to get 2 of my least favourite things about iD in one changeset:
1. In the walkthrough they never mention anything about the background imagery, and nothing about imagery alignment. Unluckily, it looks like the Bing imagery isn't well aligned in your location. You saw the existing buildings were out, but if you look at the roads, paths etc you'll see everything is out by the same amount in the same direction. Whenever you see this, you can assume it is the imagery which is out, not all the existing features. To adjust the imagery, in the Backgrounds tab, scroll down and drag in the grey box until you get the best match for a bunch of roads, existing buildings etc. Then add/move your new stuff to match that. Switching over to the OS OpenData StreetView background is also good as a fixed point of reference - if you seen road junctions etc that match well there, try to get the imagery you want to use to line up to those same features.

2. For some reason, the iD guys think that if a building overlaps a road/path, then putting layer=1 / -1 on one of them solves the problem in some useful way. (Presumably you got a warning when you moved the village hall; it was because the adjacent paths then overlapped). Pressing on the proposed 'fix' button put layer=1 on the hall, which isn't really right for a non-bridge / non-elevated building.

I've reset the hall and church where it looks (to me) that they should be, can you try the Background tab to look at different imagery (some are better aligned but comparatively fuzzy and non-vertical) and then try aligning the nice sharp & vertical Bing imagery to the roads/hall/church, then adjust your houses.

The house shapes look good, don't forget there's a right-click/'square' option (shortcut key Q) available to make the angles 90deg when wanted.

Hope this helps and happy mapping,
Cebderby (Clive).

It's pretty hard to review this changeset as you changed both River Lane in Leatherhead and Mallorca in the same changeset so it's about 1300km tall!

It's not at all necessary to add oneway=no to ordinary roads (despite the choice of wording in iD which rather implies otherwise).

However two of the ways:
way/
97554865
and
way/97554879
had previously been tagged as junction=roundabout which looks wrong as they are turning loops at the ends of roads and is very inconsistent with your oneway=no. Here, asserting oneway=no (or yes as appropriate) is useful, but can you remove the junction=roundabout on each of these?
(and try to keep changesets local to one area).
Cebderby (Clive)

Hi Simon270,
The A36 is divided in the right place, at the moment there only seems to be a restriction without a type (so no effect) with 'from' + 'to' on the NW part of the A36, 'via' on the junction node. Probably best to get rid of this first, so click on the that part of the A36 and bin the 'from' and 'to' entries labelled just 'Restriction' (avoid the bus route and the one currently showing as 'to' for a 'No right turn' as that is for the next junction NW for the opposite side entry). Then, select the junction node and delete the 'via' for the same 'Restriction' entry. Now you're back to a clean junction to start from.

The big choice for blocking entry is either to use a short length of oneway, or have two turn restrictions from each direction of the A36. The short oneway is easier, some may regard the two restrictions as more correct.

For the short oneway option, divide Straight Lane eg at the footpath, and set the end bit as oneway out. Or, for two turn restrictions blocking entry, select the junction node. In iD's left panel you should have a diagram of the junction, in this diagram (not the main map) now click one part of the A36 and then click on the representation of Straight Lane until it goes red. Then click away and select the other part of the A36, and click on Str.La again until red. Once you've clicked away you should be able to hover over a 'from' way and see the choices (green=compulsory,red=blocked)

Whichever of the above options you go for,
to add a no-right-turn coming out of Straight Lane, with the junction node still selected on the main map, on the diagram select Straight Lane, then click on the NW part of the A36 until that goes red. Click away and you should have 1 (or 3) turn restrictions.

If can't make it work or get into a mess don't worry, it can be cleared up or fixed, so have a go.
Cebderby (Clive)

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)