Hello,
as part of our project we may end up seeing some inexperienced people attempting to add data to OSM for the benefit of Visually impaired users. The POIs will be mainly as follows:
Crossings near traffic lights
Some local shops (that have not been entered already)
Many of the POIs that have been created so far have been rejected.
Is there a dummies guide that can be recommended for inexperienced OSM users before I try and create one myself?
Thanks
Steven
What do you mean by “have been rejected”? The only way that things get rejected is if a human sees them and reverts the change, which they shouldn’t do without telling you why they did it.
If you mean that they don’t render on the standard version of the map, that could be either because rendering them would have conflicted with rendering something else, or because that rendering does not render the sort of object you added. Rendering everything would just produced too much clutter.
There’s the beginners’ guide https://wiki.openstreetmap.org/wiki/Beginners’_guide , but I’m not sure if that’ll be specific enough for what you’re doing.
What I would suggest is to try and be as open and descriptive about what you’re doing as possible - use descriptive changeset comments and use accounts with descriptions explain what you’re doing.
When you say that “POIs have been rejected” do you mean that someone’s deleting them, or that some QA software thinks that they’re mistagged, or duplicate or something? If they’re being deleted by another mapper, try and engage with that mapper to ask why (changeset discussion comments are normally the easiest way to do that, but I’m not sure how straightforward that process is for visually impaired people as it involves navigating osm.org itself.
If someone adds a POI as a node (a cafe, perhaps) and that tag is already present on a building, then it’s reasonable to merge the an extra tags from the node onto the building and delete the node. Maybe this is what’s happening?
Another suggestion would be to try and talk to local mappers (maybe there’s a mailing list, forum, slack channel, pub meet, etc.).
You haven’t submitted any edits yourself, so it would be useful to have the user name of someone who has submitted and had problems, or at least an indication of where to look for problems on the map.
Generally, with the default editor (iD) people have no problem adding shops. The typical newbie problems were accidentally changing too much, rather than failing to add features.
To add a shop with iD, as a point, rather than an area, select point mode, click on the location, type shop into the search box at the left, fill in the name, select a type from the type drop down, or enter the type directly, and add other known details. If the type is known, you can search directly for it rather than going through shop.
For a crossing, double click on the road, then single click on the new point. Select Street Crossing, in the left hand panel. Use Street Crosswalk, if it has zebra stripes.
It is possible that the lights are part of the crossing, which is another reason this may be more complex.
There is a show all tags option, in which you can add tags from, for example, the wiki, that aren’t in the templates.
I found crossings with lights to be difficult. I looked at the wiki, did what it said (and what somebody had previously done before me for one of the crossings), and no lights appeared. So I looked harder at the wiki, found suggestions for different combinations of tags, and no lights appeared.
After several attempts, I found that:
highway=traffic_signals
crossing=traffic_signals
traffic_signals=pedestrian_crossing
made traffic lights show up without triggering errors from any of the validators. Although there may be better ways of doing it. And maybe somebody will point out that what I did is horribly wrong, but it works.
You can then add other things depending on how the signals operate. Such as button_operated=yes (if it is), crossing_ref=pelican (or other traditional, region-specific tag for type of crossing, although only UK ones have been defined at present), kerb=lowered (if it is), tactile_paving=contrasted (or whatever), traffic_signals:sound (if there’s an audible alert). There are other traffic_signals:whatever defined, depending on what features are present, such as a tactile arrow. Oh, and I introduced traffic_signals:rotating_cone=yes for UK use, but it’s not documented anywhere.
Oh, and don’t assume that all crossing lights in your area have the same features. Most UK pelican crossings have audible alerts, but there are situations where an audible alert is legally prohibited (such as independent lights to a traffic island in the middle of the road). In the UK, where the audible alert is legally prohibited then a rotating_cone must be present; where the audible alert is present fitting a rotating cone is at the discretion of the local authority. There’s only one way to know for sure what features a crossing has, and that’s to go and try it.
The typical way to tag crossings with pedestrian-controlled traffic signals is:
highway=crossing
crossing=traffic_signals
Using a crossing=* tag without highway=crossing isn’t enough to be meaningful. It could be either a highway=crossing or railway=crossing (or maybe even something else).
I’m not quite sure what you mean when you say “no lights appeared”. Do you mean in a specific editor?
Hi all. Excellent feedback which I will note and share with my colleagues.
To address a few questions:
@hadw and @SomeoneElse
With respect to my comment:
The user that made the changes is totally new to OSM and probably doesn’t know what they are doing. They made some “changes” but they were reverted by “someone” because they were entered or created incorrectly. I will take the feedback by everyone in this thread and share it and hopefully all will become better.
Note: I have a few accounts on OSM and I have personally made a number of changes without any issues because I am now more familiar with how to do it.
Thanks again everyone. This has been a good response. If I have any further questions on this, I will post it.
Steven
I mean that, when viewed on openstreetmap (not in an editor) there were no lights shown. No indication of a crossing at all. At least not without using the query feature near to where I knew there was a crossing to find out that there was a crossing.
I think the “correct” way that you quoted was one of those that I tried. If it was, then either no lights appeared or one of the validators complained about it (for at least one of my tries I got both problems). As I said, it took me several attempts to find a combination (which I think was in the wiki somewhere) that satisfied both of those criteria.
You could argue that, because those particular crossings are on a straight length of road and not at junctions, showing the lights is unnecessary. However, I’m aware of a light-controlled junction in the area that is also a crossing (I need to make a trip there to verify the exact details because it’s a long time since I was last there and am only sure of one of the possibilities being a crossing).
If you’re sure your way works I’ll give it another try, but I’m a bit reluctant to add yet another changeset. 
With regard to “highway=crossing” (or any other feature for that matter) what each map style shows is down to that map style. For example if you look at this area in the “cycle map style”: https://www.openstreetmap.org/node/4060160032#map=18/53.18332/-1.41322&layers=C you’ll see three crossings, but swap to the “standard” style and they’re not shown. In the issues list for the standard style there’s at least one issue for it: https://github.com/gravitystorm/openstreetmap-carto/issues/1943 (there may actually be other related ones too).
However, please don’t let the fact that crossings aren’t currently rendered by a particular map style put you off mapping them with as much detail as you can! Renderers will catch up (they’re always playing catch-up) and there are many, many different map styles, some of which probably already render all the detail you want.
If you want to move things on a bit, you could perhaps try suggesting a change to the rendering via a pull request to whichever map style you want to change. In order to do that you’d need to have a working local copy of that map style, but that’s not as hard as it sounds.
As an aside, it would also be useful to me if you could explain exactly what tags you added and what you expected to appear - I maintain a map style (mostly for my own use) that covers the UK and Ireland and I’m fully aware that the way that I currently show highway=crossing is not very good: http://map.atownsend.org.uk/maps/map/map.html#zoom=22&lat=53.183319&lon=-1.4125871 . If you could explain what you’d expect to see for different sorts of crossings it’d be really useful.
It seems possible you come across someone who is trying to own part of the map, which is wrong. However, without having details of the edits in question, it is difficult to know what has really happened.
One thing I would encourage you do do is to get your colleagues to provide quite long changeset comments, so that it is clear what they were trying to do and how they obtained their information. In particular, if they actually went out and looked at the place in person on the day, that is more reliable than a few years old aerial image, and recording that fact will help resolve conflicts with such images.
That might be the intended behaviour. Modifying the tags to obtain the behaviour you want is tagging for the renderer, and should not be done.
True enough about not mapping for the renderer, but the wiki gives conflicting answers. Yes, I know, documentation always lags behind reality. But the problem is that it is true that highway=crossing and it is also true that highway=traffic_signals. Which one should be used? If I use highway=crossing with crossing=traffic_signals then mapnik doesn’t show any obvious indication it’s a crossing and doesn’t show traffic signals either. That’s flawed rendering whichever way you look at it.
Those lights don’t just control pedestrians, they also control traffic. Arguably it could be “highway=traffic_signals; crossing”.
Not showing the lights isn’t a gigantic problem on the 3 sets I’ve done so far (the crossings aren’t at junctions), but is on the other set of lights in town. They control a junction on the town bypass, and before the lights were installed a few years ago there were many accidents there. Those lights are important. They also control pedestrian crossings. So if I map them the “correct” way those lights vanish from an important junction on some renderers.
I know, don’t map to the renderer. But what I used isn’t (to me) obviously wrong, even after alester’s comment, because in that situation there’d be a railway=crossing.
In those cases, you’ll probably want to use separate nodes. Tag the intersection with highway=traffic_signals, and then tag a separate node at the actual location of the crossing(s) with the relevant crossing tags.
The crossing=* tag is meant to add detail to an object already tagged with highway=crossing or railway=crossing. Many data consumers are unlikely to look only at the crossing=* tag on its own. They’ll look for highway=crossing first, and only then use crossing=* to further improve things. Without highway=crossing, you’ve effectively omitted the crossing entirely.