Because nobody submitted any challenges for Poland, perhaps? MapRoulette has global reach but relies on people submitting challenges for their countries. Like members of the France and Italy communities have already done. If you are not in a position to contribute challenges yourself, talk to your community and come up with fun local challenges!

It does, Harry, and I apologize! There is something going on either on the challenge provider’s end or on MapRoulette’s end and my mission for today is to figure out what it is!

And to all US mappers: WHY USE A DIFFERENT TAG FOR MOTORWAY EXIT DESTINATIONS THAN THE REST OF THE WORLD?

jgpacker - wow, I never knew that was possible! Thanks.

I also added a comment to the Discussion section of the highway=motorway_junction page, where exit_to is still referenced in a few places. I want to move to de-emphasize exit_to in preparation for a plan to deprecate this tag altogether, if the community feels this is the right thing to do.

I edited the exit_to wiki page to reflect that usage of this tag is being discussed here.

imagic: In the case I highlighted in the blog post, there is a destination further down the route (I-95 North / South) that the beltway connects to. You could compare it to control cities There is no way to derive that information from the data. This is why I was looking at specifying that as destination:ref:to as a suggestion, but in general I am not in favor of many levels of colons in the tags.

Re: the blurred signs, this is an unintended side effect of the anonymization image processing, I assume. I have just raised it with them.

Russ: The documentation issue is only one of the problems with exit_to, but it shows that nobody has cared enough about this tag to properly document it so far. It likely has contributed to inconsistent usage. I don’t know. I haven’t found any inconsistent use of exit_to myself, and my issues with the tag are not that it is used inconsistently.

Thank you for your contributions! Drift and Contour seem like great candidates. I opted for the GoPro because of the form factor and accessories available, and the reportedly good image quality.

When I got it, I turned off sharpening, auto-white-balancing, and other pre-processing I could find to get the purest possible reading from the sensor. Here is a result from a test shoot. This is - obviously - taken with the camera mounted inside the cabin. I am getting a suction mount (and some fishing line as backup :) so I can mount the camera on the hood instead.

Here is detail at 100%:

I don’t think this is all that impressive. Perhaps it’s the image compression. Perhaps I need to tweak the settings a little more.

The post-processing was a little more tedious than I had hoped. I recorded a GPS track using my Garmin Dakota 20. This delivers a standard GPX format track. My first thought was to use the JOSM geotagging plugin to write the location information to the images. This works great, but it does not write the GPSImgDirection tag, which is required by Mapillary. (This should not strictly be necessary, as they can calculate the direction based on the GPS track, given user input of the relative heading of the camera to the driving direction. I am talking to them to get that resolved.)

The tool I settled on for now is a pretty smart Ruby script called gpx2exif. It does calculate and write the GPX location and heading, so the images are ready for upload to Mapillary straight after processing them through this tool. I still use the JOSM plugin to determine the offset between GPS time and camera time.

The main issue with gpx2exif is that it wraps the great but excruciatingly slow exiftool. Processing a few thousand images - which is a pretty typical use case - takes hours. This could be improved a lot if they would switch to exiv2. I filed a ticket with them and got a prompt response from one of the maintainers, Craig Taverner - who incidentally also wrote a great blog post about this very process. I also looked at doing it myself but my limited Ruby skills and the lack of a decent exiv2 ruby wrapper made me give up for now.

Then, when I finally had my first sequence ready for uploading, Mapillary’s web uploader did not like my 700+ image sequence very much - at least not on Firefox. After a lengthy wait and a lot of ‘Unresponsive Script’ alerts I finally decided to force quit the browser, but it seems that the process had magically completed in the background.

So, to make a long comment short, it all works, but I need to play with the image preprocessing and quality dials in the camera, it takes forever, and it would be cool if Mapillary would just let me upload GPS + image sequence in a robust web uploading environment. Or better still, offer a bulk upload API that developers could go to town with.

Here’s a situation I would like some advice on:

(If it is too small to see, here is the full size image.

The left two lanes are a continuation of I-80 Eastbound. The right two lanes are the start of I-215 Southbound. Neither are _links. Currently, the only relevant tag is on the junction node: ref=128 indicating the exit number.

Here’s how I would tag this with destination:

• The way branching left would get destination=Cheyenne
• The way branching right would get destination=Belt Route.
• Both ways already have ref tags indicating the freeway number.

Because neither branches are _link ways, the ref on the ways, or the relationship membership, should be sufficient to infer the full signposting, right? If either or both were _links, would they require a destination:ref?

Also, destination=Belt Route is a little strange intuitively, but it is what is on the sign, so that is what would end up in the tag, correct?

(I am disregarding the more sophisticated variant of using destination:lanes as described on the Lanes page, an example can be found here).

@RussNelson - I tried to describe the problems with exit_to that are solved by destination in the post. Let me summarize and add some insights shared in previous comments. destination is a more generic solution for signpost information - as Maarssen Mapper pointed out, destination can also be used on non-link ways to indicate control cities; it allows for a clear separation of named and ref parts of the destination; it can be combined with :lanes to add lane level granularity; and finally, it is better documented and has wider support globally.

For ‘simple’ motorway exits, the transition could be as simple as copying what is now on the exit_to tag to a new destination tag on the exit _link. There may be an opportunity for a mechanical edit, but that would require additional discussion.

For more complex situations, the tagging needs to be reviewed manually, and ideally, destination tags should be added on the main motorway ways (and perhaps trunk as well) to indicate the control cities.

Thank you everyone for adding your insights and opinions to this article. It’s a day off here and a particularly nice one here in Utah, so I intend to spend the rest of it playing outside, but I will come back and respond over the weekend!

FWIW, for Scout we currently only support exit_to mainly because it has the most extensive coverage in the market it serves (the US). We are currently embarking on an effort to add more signpost information to the U.S. interstate systems, and I want to make sure that we adhere to the best possible tagging convention. If that turns out to be destination= we are quite happy to (help) make that transition, both in the app and in the data.

Thanks for sharing these insights!

AndiG88 - correct. I still want to get closer collaboration with KeepRight, and have been in touch with the author before, but due to a lack of time on my part, I haven’t been able to follow up.

Pieren: You have discovered a bug. bridge=viaduct was not processed and will appear as false positives. We are working on a fix! This is less than 1% of bridges in the US, most are just bridge=yes. We discovered another bug where we did not recognize _link ways that are also tagged as bridge (or tunnel). This is also being fixed.

Thanks for reporting!

Thanks @Alan, fixing…

jumbanho - those are excluded for now, but it’s a good idea for a followup challenge.

Thanks for this write-up - Osmium and the tools that use it can be a little tough to get into, and articles like these help.

I have used osmjs, the Javascript v8 interface to Osmium, for a few projects that may be of interest to you - see this diary entry for a discussion.

Sorry for the intermittent problems, folks! I hope everything works well again now.

We actually added a new feature, more about that in a new diary entry soon. It’s already live on MapRoulette.org - can you find it? :)

Fantastic job, Werner. Thank you for taking on this big effort of closing out all these ‘forgotten’ OSB’s.

Katie: there’s no strict rules! As many as you think makes it look decent. Be sure however that you are zoomed in far enough to really see the road well on the aerial image. (You should be able to see the markings on the road, and cars, if there are any.) I would also suggest that that it’s not necessary to put any additional nodes on straight parts of the way, as those do not add any useful information.