@alexkemp On osm.org/changeset/41428333 and elsewhere I asked if you could “please tone the comments down a bit”. This doesn’t seem to have happened.

I really don’t understand what you are trying to achieve here; are you trying to work together with other people towards a solution or are you just trying to have an argument? Comments such as “So, you are someone unable to admit openly/publicly to your mistakes. Very foolish” unfortunately suggest the latter.

If you really are trying to work towards a consensus then I’d suggest that an apology for some of the intemperate language used here and elsewhere (e.g. your comments on osm.org/user/alexkemp/diary/39062) is in order.

For brand new local mappers, I tend to wait a week or so before commenting on any minor issues that they’ve caused (although if it’s something major, like the deletion of a major road, it tends to make sense to fix it immediately and let them know that “something went wrong” in their edit). A large number of new note-adders and editors are mobile apps users (not just MAPS.ME) who may not know that they’re updating a shared map at all; in those cases it makes sense to me to react more quickly. Basically, let new mappers make mistakes, and let them find and fix them too.

However after any comment I absolutely don’t think that you should “plunge into fixing” (to use your words) if you don’t get a reply from a new OSMer. By necessity Mapbox editors are mostly remote mappers - in many cases the best action will be to add a note so that someone who’s actually local can resolve the issue. I tend to wait a week or two between a non-answer to a question and taking the next step (usually adding a note).

https://github.com/openstreetmap/operations/issues/99

(now deleted from the main site)

At least one of the accounts that caused the issues in Thailand that were discussed in http://forum.openstreetmap.org/viewtopic.php?id=54635 and http://forum.openstreetmap.org/viewtopic.php?id=54648 also edited in Egypt (a different account to this one I believe). In the second of those threads someone from Facebook explains a bit about what they’re doing.

My comment at http://forum.openstreetmap.org/viewtopic.php?pid=593266#p593266 explains where I’d go from here - if you see a potentially problematic changeset, ask the user about it directly, don’t just write a diary entry that they’re unlikely to read :)

I notice that a couple of people have commented on osm.org/changeset/41096427 including Ethan from the DWG, so we’re aware of at least part of the problem, but if there are issues with other changesets it’s always good to comment on them and point out specific problems with each one. That way the users concerned can understand the full range of the issues that they’re causing, and people looking at changeset discussion comments via http://resultmaps.neis-one.org/osm-discussions can see the issues that are being raised.

I wouldn’t make any assumptions about who’s working for whom yet or on what basis, though I guess that there’s no harm in asking…

• Andy (like Ethan, a DWG member)

Hi Alex, Personally, I tend to report spammers in the #osm-dev IRC channel on OTRS - see osm.wiki/IRC for details. It normally gets acted on pretty quickly. Cheers, Andy

Today I updated the “FAQ” wiki page osm.wiki/w/index.php?title=FAQ&type=revision&diff=1328469&oldid=1310918 with “what imagery you could use” (just changing MapQuest to Mapbox). Perhaps it would make sense to say “… and there may be other local imagery sources available for you within your editor”?

@GOwin If their email in OSM is properly configured, they should see that. However if they used a throwaway email address to sign up, or one that they don’t check often, then they won’t. For lots of people today email isn’t the default communications mechanism.

If you want to suggest an explicit check for OSM messages within MAPS.ME, then you’ll need to suggest that to MAPS.ME (via github and/or email).

Personally I tend to use changeset discussion comments over PMs as they’re public, and other people can see what’s been commented on, but obviously that depends on working email.

Thanks - it’s always useful to get some actual numbers and examples to look at rather than the “truthiness”-based opinions that have been expressed so far.

It’s a known problem unfortunately - some of the problem on this help question might be useful:

https://help.openstreetmap.org/questions/50567/wiki-accountpage-creation-error

My experience of logging bugs against JOSM (core) has that they tend to get dealt with pretty quickly, actually. Certainly faster than certain other maintainers… However, with plugins they’re at the mercy of whoever wrote the plugin in the first place, so you can’t really blame the JOSM devs here.

From memory, haven’t other people had a go at “terracer” alternatives in the past? Might be worth asking on the help site or #osm to see what recommendations people have.

In these cases was there any reason why you didn’t mention the problem to the users concerned? Most or all look like “cockup rather than conspiracy” - just genuine user mistakes, or perhaps inexperience (either in general or with a new editor - such as the maps.me POI in the middle of the road).

Obviously it’s great that “highway=yes” gets set back to the previous highway value but isn’t there a risk that they’ll do it again if they don’t know of the mistake that you’ve corrected?

Best Regards, Andy

You’ve said “It seems like a huge majority of the issues need to be carefully revieved by hand and cleaned up” and I think that you’re absolutely right. As Mateusz Konieczny says above, even in “straightforward” cases you need to check that any resulting tagging makes any geographical sense, even if there’s only one topological interpretation.

I’d also suggest that where a problem is fixed that it’s explained to the person who added the erroneous data in the first place what the problem is - if they don’t know that there’s a problem they’ll keep doing it.

I’d also suggest that any “fixing” changeset comments explain the problem in terms that a mapper that might have created the problem in the first place, so don’t say things like “remove self intersection of area outline” or similar.

“a new evil”?

The news headlines from around the world over the last couple of weeks have been pretty miserable for lots of reasons, but apparently the thing that really matters is some people mislabelling “tourist attractions” on an online map.

There’s also information over at osm.wiki/Import and osm.wiki/Import/Guidelines .

Pretty much any non-contradictory combination of tags is “valid”. If that’s the best way of describing a real-world object, then that’s what I’d use.

I think they’re breeding - the same ones exist at least as far north as Sutton.

As far as rendering highway=crossing nodes, it would be a relatively simple change to the “standard” style (I made the same change to a version of that style here. There’s probably a github issue or three already logged for it.

Years ago, there used to be a map style on OpenStreetMap.org called “osmarender” which tried to show almost every feature (but in the process didn’t look very pretty). It went away for various technical / support reasons, and there hasn’t been a replacement for it. Part of the reason for that is that query mechanisms have improved markedly - things like the “?” icon at the right of the main site that allow you to click and see what’s there and display details such as osm.org/node/3964948498 even though it’s not rendered in the “standard” map style at all.

http://taginfo.openstreetmap.org/ might also be useful - type “office” into the box at the top right of that and click through to “Overpass Turbo” zoom in and run the query - you will get a screen like http://overpass-turbo.eu/s/gOJ showing you all of the offices nearby.

With regard to actual map tiles, I do try and render lots of the office/man_made infrastructure in a style that I maintain for my own use (no public tiles alas) - see http://i.imgur.com/NCkW98m.png for an example. Sirens, Pipelines and Flagpoles I’ve never thought of doing though - I’m sure that everyone has a list of things that “should be rendered on a standard map style but aren’t”. the problem is that everyone’s list is different.

Most “international boundaries” discussions take place over at http://forum.openstreetmap.org/viewtopic.php?id=53173 - a trawl through the history there might find some prior discussion.

Currently in OSM it’s not a “country”, though it has been recently:

http://osm.mapki.com/history/relation.php?id=4112727

As ever with discussing actual changes, comments on the discussion on changesets that changed the state are the best way to try and understand what’s happening, such as happened with osm.org/changeset/37389042 .

@marczoutendijk It would indeed be great if there was a way to easily define your own map layers at osm.org, rather than using the 5 canned ones (but as Richard says above just wishing won’t make it so; you actually need to sit down and write some code to do it).

There are a couple of cludgy ways to do that sort of thing currently - see osm.wiki/User:SomeoneElse/Your_tiles_from_osm.org for an example. Essentially if you can figure out a way of converting something like http://a.tile.openstreetmap.org/7/58/53.png into http://korona.geog.uni-heidelberg.de/tiles/roads/x=58&y=53&z=7 you should be able to replace one set of tiles with another (terms of use etc. notwithstanding).

I think your “pipeline” isn’t quite complete…

What happens next is that on-the-ground mappers familiar with an area spot a remote edit, and go and check it. Sometimes the correction is valid, but often the “error” being corrected wasn’t actually an error at all - perhaps it was a bit of an edge case, like osm.org/way/53054452/history , where any OSM tagging would be a bit of a compromise.

In areas where there is a reasonable concentration of mappers, and it’s really not clear how things really are, it’s better to try and ask people to check the real situation rather than guessing, and the best way to do that is either a changeset discussion comment on a previous editing changeset or an OSM note.

It’s important to remember that OSM isn’t just data - it’s a representation of things in the real world, and the real world is sometimes shades of grey rather than black and white.