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.

Martijn here from Telenav. I am not developing the plugin but working closely with Bea who does!

First off thanks for taking the time to beta test. Because it is still beta, we hadn’t gotten around to creating a proper wiki page yet, but I have at least created a stub now. Feel free to use the talk tab there to provide feedback and suggestions as well. There should also be a link to this page in the JOSM description shortly.

I really like the suggestion for (optionally) hiding the signs where maxspeed is already present on the way - or perhaps only when OSM and the sign agree. We will look into this after we get the initial version out.

The CV algorithm processing the signs into speed limits is definitely not fail-safe - there is no such thing, unfortunately :) We did not see a lot of mistakes so far, but it’s definitely possible. (This is one of the reasons it’s a JOSM plugin and not some sort of automagical data processing / importing machine).

The offset from the actual sign position is perhaps confusing initially but expected if you reckon that the camera position is recorded at the time the picture is taken, and not the sign position (which is unknown). I don’t think it’s a huge deal, but if it turns out to be an issue we can look at ways to mitigate.

As Skippern mentions, a collaboration with Mapillary would make sense, and we have that in the works, so expect to see that sometime soon.

Feel free to drop me a line (or ask on IRC) if you have any other questions or feedback. Excited for this plugin to go live!

This is an excellent improvement Richard! I am guessing it could be used with any Overpass Turbo GeoJSON export as well?

I am currently working on direct GeoJSON support for MapRoulette (as required by the Magical MapRoulette Machine) so I am hoping that geoJSON can grow to be some sort of microtask format standard for OSM.

I have been using smile.amazon.com to shop and automatically have Amazon donate a fraction of the price of my purchases to the Humanitarian OpenStreetMap team. I don’t know if this is Amazon US specific, but it seems to be a similar setup. I believe the donation is 0.5% of each purchase.

Thanks kerosin! Well, to be honest, at first we are seeing some ‘unfixable’ things come through our filters, but we expected that to happen, and are monitoring the notes closely.

Scout GPS Navigation (formerly Skobbler) is not affected by this change yet. We are working on this! I will post diary entries whenever I have Scout-related news to report.

SanderD: Currently it can be up to 4 weeks, but we’re working to refresh more often. TomH: I will see that that gets fixed.

Yes, you could change the query to include a bigger bounding box or loosen other query parameters without creating a brand new challenge.

This is an amazing tool!! I can’t believe I didn’t know about it.

After using it for a few minutes I am just amazed by how well it works and how well designed it is.

A couple of questions I have:

• I see you are displaying exit_to tags in green, is that suggesting that exit_to is a good way to tag motorway exits? In the U.S., we have been discussing moving to destination= and I am personally not a fan of exit_to.
• Is there a way to get a permalink with a specific freeway pre-loaded?

Thanks!