Put the idea in its own blog post for better visibility.

I should really start using the preview button. One more try:

Sorry, correct image link:

!(challengeidea)[https://www.dropbox.com/s/u5nc2nl492gon9b/Screenshot%202015-09-17%2009.14.21.png?dl=1]

I put together a MapRoulette challenge idea to fix these:

What do you think? Feedback on instructions?

Harry - yes, it is really just a slimmed down mapping party :)

I am hoping that it will appeal to the more casual type mapper, the folks who have 100 other hobbies and OSM just blends into their focus from time to time. For those folks, a quick ‘flash mob’ style party with immediate results may make more sense to participate in. And who knows, they may catch the bug.

k1wi wrote a follow up blog post showing there are now as many destination as exit_to tags in the US - let’s continue the discussion there.

Really interesting. Thanks for pulling those metrics!

For reference, here’s my diary entry on this topic. The timing happens to coincide with destination taking off as a tag in the U.S. :) Note that some of my colleagues at Telenav spent a bunch of time adding destination tags to exit ramps in the US following that post, affecting ~9000 exits.

I am wondering if we can design a good transition away from exit_to - perhaps a combination of a scripted update for the simple cases, and a MapRoulette challenge for the remaining ones?

Thanks for sharing your insights, EdLoach!

Sounds like a great recommendation, SimonPoole and ItchyDemon. Thanks. The default iOS camera supports geotagging and a very limited number of other controls (‘HDR’, flash yes / no / auto, timer and front/back camera.) This is exactly why I like it, and the default settings usually produce usable images. There are tons of 3rd party camera apps on iOS as well, but I haven’t had a good reason to try one yet.

I broke my Android phone a while ago, but what does OpenCamera do that built in camera apps do not offer?

Do you think a mobile editing tool that is friendly to new and casual mappers is possible at all? What should it look like?

SimonPoole - do you think Pushpin OSM is a bad, destructive tool?

From the perspective of a large scale data user (Telenav) - in the end we will just do whatever it takes to get the best coverage for our users. If this means supporting two competing conventions for a while, we will do that.

That said, we will always try to get wider support for a single tagging convention that ensures ease of use and consistency for mappers, but also covers more complex situations that simplified tagging schemes just cannot.

A good example is the exit_to versus destination discussion we had in the US last year, where I actively promoted switching to the much more flexible destination based tagging scheme for tagging motorway / freeway exit signposts.

If it means creating new JOSM plugins, or other tools, we will consider that. Message me if you have anything specific in mind that you think we may be able to help with.

The one case that I can’t see would be supported well by the simpler scheme is the complex intersection of the type Aury88 drew. This is where you would need a clearly defined relation between origin lane and destination way or even lane. From an application perspective, I would rather support one scheme that covers all possible cases. From a mapper’s perspective, I am all for keeping it simple however. Sometimes these two sides of me don’t come to an agreement.

My observations:

1) Whatever is used significantly more should be the de facto standard. The turn:lanes schema wins here (turn:lanes on TagInfo versus turnlanes:turns on TagInfo)

2) Whatever is easier to map and maintain should be preferred, again, turn:lanes wins - BUT the fact that the relations proposal has JOSM plugin support makes it really attractive, so there is not a clear winner here.

3) From a routing engine perspective, the relations approach would be much preferred because it defines a clear from –> to relation, removing ambiguity on complex intersections.

I favor the relations approach, mainly because I deal with the routing engine dimension every day.

I received a few comments about the source code not being published - I just wanted you all to know that we are working on getting this out into the open. Thanks for your patience!

malenki - this is something that we plan to address in a future release. As always ‘armchair’ mappers should be careful with any information that is not based on own survey, just like with Bing imagery etc. So it’s not really plugin specific - otherwise I would consider adding a notice.

In the mean time, we added Mapillary support in the latest release - let me know what you think.

A great idea! Thanks for sharing!

I was wrong - there were nodes missing from our file, which explains the missing way display. Still, there is something not quite right about the way JOSM handles these ‘incomplete’ files. I would say either accept them but display a warning that there are missing nodes (there is such a warning in the console output, but not in the UI), or enforce full referential integrity for JXML files.

I also pointed to this entry on the josm-dev mailing list and there are some thoughtful responses there.

Thanks for looking bdhurkett - All existing nodes are actually in the change XML file, so all information needed to reproduce the way are present. And as I mentioned the way is actually there - if you click in the right place, it is selected. We even made sure to order the elements so that there are no forward references in case the contents are read using a SAX-like parser. I did check the map paint / rendering settings, I am using the defaults which I believe should render the indicated ways visibly.