Re your comment above , by “intemperate” language I didn’t mean “bad” language; I just meant what you probably describe as being “direct & to the point”. As I’ve said elsewhere if you’re trying to persuade people to a particular point of view then you need to try and persuade them; calling them “fools” is unlikely to win any friends or influence people.

The truth is, geocoding and reverse geocoding are complicated. In $dayjob I’ve used a few commercially, and it’s normal to have to be very careful to structure the request going in or to pay careful attention to the data coming out. A statement such as “All the evidence suggests that no admin_level=10 BoundaryLine area means no accurate LSN in OSM” sounds very simple and straightforward, whereas in reality life’s a little more complicated than that.

The first problem is it assumes that there’s only one geocoder that works with OSM data. Nominatim does an excellent job (one customer that I was working for chose Mapquest’s instance of it over the one native to the OS they were using because it produced better results and was easier to use), but it doesn’t get everything right - as you say above it works better with areas rather than nodes. Other Geocoders do exist for OSM data (Photon’s the first one that springs to mind, but I’m sure there are others).

Secondly it’s not clear to me that adding “unparished” areas at admin level 10 actually helps in all cases. Just to take a couple of examples, here’s a location in Forest Town, Mansfield, and here’s Hyson Green Asda.

Nominatim gets the latter “correct” (after deletion of the admin_level=10 unparished area) and the former “wrong” (the admin_level=10 unparished area that you added still remains for Mansfield).

Thirdly however it suggests that we should only add data to OSM that can be understood by Nominatim (or change data already there so that it can). There’s an old saw that’s been around almost as long as OSM itself “don’t tag for the renderer”. For “renderer” read “router”, “geocoder” or any other data consumer. If the standard rendering style on osm.org doesn’t understand a particular form of tagging, or Nominatim doesn’t understand an address, it’s not an excuse to map things differently - there’s always the expectation that better renderers, routers and geocoders will come along, and it’s good to have the “correct” data there for when they do. You could argue of course that it’s “correct” to have an admin_level=10 for Mansfield at the same level as the admin_level=8; I’m somewhat skeptical personally, but would certainly listen to arguments behind something saying “here’s an area for which there’s no admin_level=10”.

In the case of the Nottingham and Mansfield suburbs, it’s always going to be complicated. As TomH said in the first comment above, “no two people will agree on exactly where one suburb ends and another one begins”, and as you said Nominatim really works better with areas rather than nodes. in the Forest Town example that’s a problem - Forest Town is clearly a suburb of Mansfield, but I’m not sure I could clearly draw a line between “Forest Town” and “Not Forest Town” (even though I’m probably the most active OSMer to the area).

@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).