OpenStreetMap

mvexel's diary

Recent diary entries

New Telenav Mapping Project: Dual Carriageways

Posted by mvexel on 27 January 2015 in English (English)

Dual carriageways, divided highways... Whatever you call them, this is what they look like:

dual carriageway Image: Wikipedia

In OSM however, they are often mapped like this:

single mapped Screenshot from JOSM, showing Bing imagery

This is surely better than nothing, but what we really want to see is an accurate representation of the road as it is in reality. Not only because we're perfectionistic OSM mappers :) but also because there are practical implications to this simplified representation.

Here is an obvious example. Say you need to be at the place by the pink arrow, and you're coming from the southeast there:

confusion Annotated screenshot from JOSM, showing Bing imagery

If this road were mapped as a single way, any navigation app would tell you to just turn left, which is clearly not an option. Also, turning on to the main road, navigation could tell you to turn left which is equally impossible.

There are still a lot of roads in the United States that are mapped as single ways but are in reality divided highways. Here at Telenav, where we use OSM for the Scout navigation app, we want all these roads to be properly mapped as dual ways. This is pretty tedious work (perhaps I will spend a separate diary entry on some of the mappy-grappy details) which is probably why it is not done in the first place, so our internal editing team has taken this on themselves.

fixme-memphis Plenty of fixme=dual carriageway around Memphis, Tenn. (Overpass Turbo). Map ©OpenStreetMap contributors

We don't use any magic to identify the candidate ways. We just search the OSM database for fixme tags that have a value of dual carrigeway or some variation thereof. This gave us a total of around 6,000 ways to look at. Prioritizing trunk and primary, we were able to limit this to around 1,500 ways to look at for now.

We expect to complete this work by mid-February, and once we do, anyone using OSM data for navigation will see much improved results for the affected areas!

As always, if you encounter our work on this project in your area, please share your feedback, using the great new changeset comment feature for example. Or just drop me a line!

Battlegrid update

Posted by mvexel on 14 January 2015 in English (English)

Hi folks,

The Battlegrid had been down for a while and I have had no time to look at it really. Until today! The Battlegrid is back up. And it now compares with the latest TIGER 2014 data, so bright cells should more often be a treasure trove for real problems.

battlegrid

If this is the first you hear about the Battlegrid, read much more about it in the original announcement blog post.

What are you waiting for!? Fix some cells, head over to battlegrid.us!

Telenav Signpost Mapping Project Completed!

Posted by mvexel on 12 December 2014 in English (English)

signpost example

Image credit: AARoads

Here at Telenav, our editing team has been working tirelessly on adding signposts to OSM for the past months. Today, I am happy and excited to report that we have completed this major editing project! We added signpost information to over 9,500 exits across the United States, covering more than 25 major metropolitan areas and a few important connecting freeways as well:

coverage

Wait - that is not 'complete', is it? Well, you are right. We haven't covered every exit in the United States, not by a long shot. We have only a limited number of in house mappers, and a lot of things we want to achieve. So we prioritize the areas where we believe most people will benefit from our work. (On a personal note: that leaves me empty-handed out here in Salt Lake City - I guess I have to go out and map myself!)

We have learned a lot in the process, and we hope to contribute some of these learnings back as well. We already made quite a few improvements to the wiki pages for the exit_to and destination tags. Now that this project is complete, we will sit down and revisit these pages and add more clarification where needed. If you are interested in more tagging specifics, please see my earlier blog post on exit_to versus destination. (And don't forget to read through the comments!)

congrats

I want to thank a few folks for making this happen. First and foremost our Telenav Mappers team, with lots of guidance from our resident road geek Robert. But also all of you in the community for giving feedback, calling us out on the occasional errors, and working with us to improve signpost mapping conventions. I feel proud to be a member of a great mapping community!

Now Live: Notes Posted By Scout Users

Posted by mvexel on 11 December 2014 in English (English)

Scout (USA) has been powered by OpenStreetMap data for about 5 months now. From day one, Scout users have been able to report navigation errors to us:

scout

We have since received thousands of reports and we have worked hard to review them and learn from the feedback we get from our users. We have manually submitted OSM notes where we could not resolve the issue ourselves, and we have fixed dozens of map issues based on the incoming reports. But we felt that we could do a better job closing the feedback loop between Scout users and the OSM community. We have now taken another big step towards this goal with direct OSM Notes creation from Scout US.

Some Scout Feedback will automatically become OSM Notes

As of last week, certain kinds of feedback we get from our Scout US community will be posted to OSM Notes automatically. We apply a smart filter to make sure that only reports that we think the OSM community can fix get posted. For example, 'Destination Incorrect' reports will not make it to OSM, because Scout does not use OSM data to locate addresses and businesses. And we will only forward reports where the Scout user entered a sensible looking comment.

What happens when a Scout user posts a note that passes our filter? Let me walk you through the process. The screenshots are from an actual note posted by a Scout user a few days ago.

Post to OSM

The report is translated into an OSM note and posted to OSM immediately. We take the location of the report as the note location, and add the report comments as the note text.

osm note

The note will also contain a link to another page that contains more information that may help you resolve the issue. We include the a part of the GPS trace of the user before and after they submitted the report (anonymized to remove any personally identifiable information of the user) and the OSM map data version used when the Scout driver submitted their report:

detail page

Confirmation Email

As soon as the report is posted to OSM, we send the Scout user an email telling them that their report is being reviewed by the OSM community. Of course, we also encourage them to fix the problem themselves and include a link to the note.

initial email

Note Resolved!

The Scout report system monitors the OSM notes it posted and kicks in as soon as they are closed. (In this case, I resolved the problem myself by adding a turn restriction and tagging a link road as such.) We will send another email to the Scout user telling them that their note has been closed.

resolved mail

What's next?

Our objective with this new feedback loop is for the Scout and OpenStreetMap communities to connect. With Scout's switch to OSM last April, all of a sudden we gained many more eyes on the OpenStreetMap data. This is an important step in feeding the intelligence we get out of that back to the OSM community. We plan to continue down this road and find more ways for the Scout community to help out in keeping OSM in great shape!

The Magic MapRoulette Machine

Posted by mvexel on 2 December 2014 in English (English)

Making a MapRoulette challenge has always been a bit of a, well, challenge. I wrote a tutorial in an attempt to explain the process, but in the end, it is still more work than I would like it to be, and more technical than I would like it to be, too.

So I made something new: the Magical MapRoulette Machine!

The MMM lets you create a MapRoulette challenge interactively. Just answer a few simple questions and your own challenge can be live in minutes. The key component, the part that actually defines which OSM ways or nodes you want to have fixed, is an Overpass API query. If you are not familiar with writing queries in the Overpass Query Language, that would be the only thing you would need to learn a little bit about.

How do I use the Machine?

First download and install it using the instructions on the project page.

Once you have the Machine on your machine, you can just run it in interactive mode by calling it like this: ./mmm.py. It will then ask you a series of questions about things like the Title, Instruction, Help text, etcetera. All those bits are explained in the MapRoulette Tutorial.

questions_1

Next, it will ask you which MapRoulette server to use. It will default to the dev server, which is a great place to start. It is publicly accessible so you can use it to 'battle-test' your Challenge idea. It will also ask if this is a new Challenge or not. Unless you are uploading your Challenge for the first time, you should accept the default, which is to update an existing challenge.

questions_1

(By now you will have noticed that there are default values for each question. These represent an example challenge for shops and restaurants without opening hours around Salt Lake City, Utah, USA. They are just meant to give you some more guidance.)

Next up is the most interesting question: which OSM nodes / ways will actually represent your tasks? You tell the Machine by way of an Overpass query.

overpass-question

Let's look at that a little more closely. Consider this simple example. Say I am a Dutch mapper and I want to create a challenge to fill in all missing lanes on motorways in and around the Netherlands. The Overpass query for that is fairly straightforward.

The Overpass QL looks intimidating at first, but the basics are easy to learn. And for the Magical MapRoulette Machine, you only need the part that actually queries the nodes (or ways). The rest is taken care of internally.

query stub You only need the highlighted part

Once you have the Overpass Query, you are 95% of the way there!

The Machine will now talk to the Overpass API and retrieve your tasks. Depending on the size of the area you are querying, and the complexity of the query, this could take a little while. The machine will eventually respond, and ask you to confirm one more time:

final

At the bottom it will give you the link to your new challenge! Yay! (The example one is online as well to prove that it really works!

Give it a try and let me know what you think!

Location: De Guigne Drive, Sunnyvale, Santa Clara County, California, 94086, United States of America

Argentina Money Advice - is this any good?

Posted by mvexel on 4 November 2014 in English (English)

I am headed to Buenos Aires for SOTM 2014 tomorrow, and reading up on money and general travel tips. I found this page on bringing and exchanging money. Some of the tips in there:

  • Bring cash, preferably in US$50 / US$100 bills
  • Pay in US$ whenever you can.
  • There is an unofficial 'blue dollar' rate that is much better than the official US$ / Peso rate.

I have never been to Argentina before, and I have no idea if these are good tips. Perhaps an Argentinean mapper can shed some light on this?

See you at SOTM!

New MapRoulette challenge: TIGER Mismatched Ways

Posted by mvexel on 7 October 2014 in English (English)

I know, I've written about TIGER before...Quite a few times. I've pointed out problems from time to time, but I have also attempted to come up with solutions, like the Battle Grid.

battlegrid

Today is another being-part-of-the-solution kind of day. We (a few colleages at Telenav were involved in this) took the output of the Battle Grid comparison we use to generate the Battle Grid cells, divided them into more and less severe cases based on the road class and amount of difference between TIGER and OSM, and created a MapRoulette challenge out of the more interesting cases. This will make it easier for anyone to help fix antiquated, bad TIGER data anywhere.

This is what a typical case would look like in MapRoulette:

mr-case

Loading this case in iD, it's plain to see that this road is mis-aligned pretty badly:

case-in-id

Easy to fix! Just drag the nodes that make up the misaligned way to match the aerial image:

fixed

Non-errors

To point out these errors, we compare TIGER 2014 against OSM data. This gets us mostly good results, but it's not perfect. In most cases where MapRoulette will point out a non-error, the TIGER data is still wrong. This is the case in Alaska more than anywhere else, it seems.

alaska TIGER is wrong here, even though it's hard to see with the low resolution satellite imagery...

The number of non-errors is small enough to not be too annoying, I hope. If it is let me know, and I can see what more we can do to improve this challenge.

Not all at once

There are a lot of Mismatched Ways. A lot. Most of them, way more than 90%, are local and low speed roads, mapped to residential in OSM when TIGER was imported. Of course, these all need to be fixed eventually, but let's focus on the more important roads first. Based on how it goes, I will gradually add more cases.

I look forward to hearing from you about this new challenge! I am pretty excited about it!

To the TIGER Mismatched Ways challenge!

MapRoulette Challenges 'Ways Needing Smoothing' and 'Crossing Ways' Completed

Posted by mvexel on 3 October 2014 in English (English)

If you have logged in to MapRoulette today, you may have noticed that the Ways Needing Smoothing and Crossing Ways challenges are now gone. There is a simple reason: they are done!

Congratulations!

Together, we resolved more than 100 thousand suspected 'sharp angle' errors in the Ways Needing Smoothing challenge, and just under 25 thousand crossing ways in the Crossing Ways challenge.

So at least for the United States, we now have much less of this:

smooth

.. and many less situations where two ways cross but should really have an intersection node. (Sorry, in this case an image does not say more than a thousand words..)

Not all suspected cases turned out to be real errors. For the crossing ways, about two thirds of the cases were eventually marked as 'fixed' by MapRoulette users:

cross-res

For the Ways Needing Smoothing, the fixed rate was much lower, about 40%:

smooth-res

This low rate can be explained in part by MapRoulette users fixing more than they are asked to fix! What I heard a lot is that mappers would load a smoothing task in their browser, and ending up spending a lot of time cleaning up the area around the error - often resolving other MapRoulette tasks without even knowing it. So it's not as bad as it looks, and I received mostly really positive feedback about this challenge.

I have a new challenge in the pipeline that also has to do with TIGER fixup - a separate diary is forthcoming about that!

As always, if you have a good idea for a challenge, don't hesitate to get in touch with me so I can help you get started! Better still, subscribe to the MapRoulette mailing list and share your ideas with the MapRoulette community!

State Parks and National Parks

Posted by mvexel on 23 August 2014 in English (English)

There is a well-established definition for tagging National Parks in OpenStreetMap.

Hoge Veluwe Nationaal Park Hooge Veluwe National Park Image credit: Wikipedia

The definition,

A national park is a relatively large area of land declared by a government (just as boundary=administrative are declared/recognised by governments), to be set aside for human recreation and enjoyment, animal and environmental protection

would also apply to the many State Parks in the United States, and perhaps provincial and state parks in other countries as well. However, the boundary=national_park page does not give any specific guidance. I am about to map some state parks in my home state Utah, and I will tag them with boundary=national_park for now because they fit the definition.

How do you map state or provincial parks in your area?

OpenStreetMap Sister Towns

Posted by mvexel on 23 August 2014 in English (English)

Playing MapRoulette, you get dropped in all these random locations on earth. This really makes my mind wander sometimes.

Here is Cambridge, Ohio:

Cambridge, Ohio Image credit: Wikipedia

A nice enough town. Probably friendly people. BUT NOT VERY MANY MAPPERS AMONG THEM:

Cambridge on OSM

A fellow mapper suggested this simple & brilliant idea: OSM Sister Towns. Why don't we team up towns (and cities) in need of mapping help with towns elsewhere in the world that have mapping forces to spare? They could use the Tasking Manager, MapRoulette, or just iD / JOSM with aerial imagery to help out the town in need. I foresee face to face meet-ups at SOTM and new global bonds of mapping friendship!

Oh TIGER...

Posted by mvexel on 22 August 2014 in English (English)

Sometimes I wonder if those TIGER surveyors were just having a grand old time making up things as they drove past and casually looked out of the window of their cars...

TIGER...

This whole area needs lots of work - if you want to help out, that would be great!

(I have no personal or other connection to the area, but got dropped there by the MapRoulette 'Ways Needing Smoothing' challenge - freshly cleaned up, so most cases you get should now be real things to fix!

Then and now

Posted by mvexel on 26 July 2014 in English (English)

I joined OpenStreetMap in June 2007. A lot has changed since then!

Amsterdam

amsterdam

Birmingham

birmingham

Silicon Valley

silicon valley

Aw, snap!

Posted by mvexel on 24 July 2014 in English (English)

I'm seeing this all the time now when trying to use iD on my Mac!

snap

What's up? There's a recent bug that seems related. If you're experiencing the same thing, see if you can weigh in there.

It looks like there's a more recent version of iD up here, give it a try if you get crashes as well.

New MapRoulette feature: Select your local area!

Posted by mvexel on 22 July 2014 in English (English)

MapRoulette silently added a new feature a while ago: the ability to select an area you want to work in. This is one of the most requested features in MapRoulette and I am pretty excited to publicly announce it!

Here is how it works. Go to MapRoulette and select a new challenge. You will see this screen:

select challenge

Notice the button at the top? It says what it does on the tin - it lets you select a work area that will be remembered until you cancel it. (I will show you how to do that later.) When you click the button, the challenge selection window disappears and you will get this notification:

notification

It tells you to click on the map to set the center of your work area. It will then draw a circle that defines your work area. The initial radius of the circle is determined by the current map zoom, so if you want to define a large area, try zooming out first. Here, I zoomed out to the United States and clicked somewhere in Utah. This gives me a work area of about the size of the state:

utah

Right now, only circular areas are supported.

You can change the radius using the + and - keys on your keyboard. You can click anywhere else on the map to set a new center for your area.

Once you're satisfied with the area you have set, click the notification in the top left to confirm your selection. The challenge selection window will re-appear, but will show only challenges that actually have work in your area, and tell you how much:

challenge filtered

(Right now, there is an annoying little bug that will cause MapRoulette to first tell you that everything is done and you need to pick a different challenge. I hope to squish that really soon. Just click OK.)

As you see, there are only two challenges in my area that need work! Yay. If I select one of them, sure enough the next task I get is in Utah:

task in utah

Resetting your work area is pretty much the same process. Instead of selecting an area like I described before, just click the notification without doing anything on the map, and you will be back to the old behavior where your work area is the entire world.

I hope you enjoy this new feature! Let me know if you have any questions.

Location: Central City / Liberty-Wells, Greater Avenues, Salt Lake City, Salt Lake County, Utah, 84111, United States of America

Scout update: new data and signpost tagging

Posted by mvexel on 22 July 2014 in English (English)

Let me update you on some of the goings on at Telenav related to OSM.

Scout OSM data update

First off, we released new OSM data for the US Scout app on July 15th. The OSM data is from July 3rd. No app update is required; just launch Scout and it will automatically use the latest data. We are currently updating the OSM data that drives Scout about every other week.

If you haven't tried Scout yet, you can download the latest version for Android here, for iOS here.

Note that the Scout International app (formerly the Skobbler GPS Navigation app) has its own data update regimen that is independent from the US version of Scout.

Signpost tagging

We continue to improve OSM data for the United States as well. We are focusing on signpost information right now (the information that you see on the freeway exit signs).

signpost

Image from AARoads

We are adopting the well-established destination= convention instead of the US-specific, limited and poorly documented exit_to convention. We are using AARoads as our primary source, for which they kindly gave permission. We are starting in Texas. Let me know if you have any questions about the editing work we are doing!

recent changeset

screenshot from the awesome achavi diff viewer

If you are interested in the background of exit_to versus destination, please see my previous diary entry about this topic.

Alright, that's it for now. I will write up updates like this one more often going forward!

Time for a 'Map Your Outdoors Adventure' party!

Posted by mvexel on 21 July 2014 in English (English)

Reality

reality

OpenStreetMap

osm

:(

Location: Gold Hill Road, Summit County, Utah, United States of America

Opening Hours

Posted by mvexel on 17 July 2014 in English (English)

Mapping opening hours correctly can be a pain; the format for the opening_hours key can be hard to remember. I didn't use to do it much for that reason. Until I recently discovered that there's a JOSM plugin for that! It works really well, let me show you how I added hours of a local restaurant in seconds.

First, of course, make sure you have the plugin installed:

install

Then, select the thing you want to add opening hours for:

select

And select 'Edit Opening Hours' from the Data menu (or use the keyboard shortcut).

menu

If the plugin detects an existing opening_hours tag, it will offer to edit that, or you can create it. It will then offer a graphical interface for setting the hours:

interface

You can move and drag blocks as you would expect. The plugin will parse it in the expected format. A nice little extra is that it supports the 'open end' hours in the format 17:00+ - useful for places that don't have a set closing hour but instead say 'open till late' or something similar.

Perhaps old news to y'all, but it made me happy :)

A Word Of Caution

Several people have pointed out (link is to the German forum) that the plugin is limited in what it can do. It will not cover most complex cases, like exceptions for public holidays and month to month variations) and does not seem to properly cover some of the simpler cases.

I still feel that it is good for a lot of basic opening hours tagging, but please review the opening_hours specification.

There is also a validator tool that I don't quite understand how to use, perhaps someone can explain in the comments?

Watching the Watchlist

Posted by mvexel on 12 July 2014 in English (English)

I like the Watchlist on the wiki - it helps me keep track of changes to pages I care about. When you are logged in, you will see a link to your Watchlist in the top right corner:

watchlist link

If you click on it, you get an overview of changes to the pages you added to your watchlist:

watchlist

You can filter the output in various ways to make the result less cluttered.

Adding pages to your watchlist is simple - just click the star at the top of a page:

star

The biggest drawback is that you actually have to go to the page. I would rather be notified of changes on my phone.

This is where the Atom feed comes in. On your Watchlist page, you will find it in the left margin:

watchlist atom

The Atom link provides the latest items on your watchlist as a feed, meant for software to do something useful with. Much like RSS. Actually, if you use an RSS reader, you can probably add the Atom link to your reader.

I don't use RSS readers, but I do use IFTTT, or If This Than That. IFTTT is a very smart web site that you can feed all kinds of information from the internet, and perform actions on it based on triggers. For example, it can send you a text message whenever it is going to rain, based on weather data it gathers. IFTTT calls these things Recipes. People have come up with tons of useful recipes, and IFTTT is constantly adding interesting input options.

Let me show you how I created a simple IFTTT Recipe to get a notification on my phone every time someone updates an OSM wiki page I am watching.

First, if you don't have an account with IFTTT yet, create one.

Once you are logged in, you will be able to create new Recipes:

createrecipe

The first step in creating a Recipe is defining your 'this' or input:

this

Click 'this' and choose 'Feed' from the list:

choose feed

You can choose to pull this trigger on each new Feed item or just one that matches a certain string.

choose each or filter

Choose 'new feed item'. In the next step, you paste the Atom URL:

copy link

paste link

Then click to Create the Trigger.

This is the 'this' step that takes care of the input. IFTTT will monitor your Watchlist through the Atom feed and pull this Trigger every time it sees something new. I am not quite sure how often it goes and looks, but it's about every 10-15 minutes in my experience.

Next is the 'that' step, or what do you want to do when the Trigger is pulled?

that step

options that

There are a lot of options, most of which you will need to 'activate' by downloading an app for your phone, linking another account, or something similar so that IFTTT knows what to talk to on your end. IFTTT has native apps for iOS and Android that it can talk to to send you notifications. This is probably your easiest option if you want notifications on your phone.

notifications apps

You activate these 'Channels' by downloading the app from your app store and linking it to your IFTTT account. I use a third party notification app called Pushover myself, because it has an API that can receive notifications from elsewhere as well. If you don't care about that, go with the IFTTT apps or even the SMS Channel option. The example here assumes Pushover, but the steps are the same.

Once you have selected a 'that' Channel, you may need to choose between various output options. Pushover for example has two, normal and 'high priority'. In the app, you can have these two types trigger different alert types / sounds.

pushover prio

In the next step, you get to craft what your notification looks like:

notification definition

The text with a grey background will be replaced by text from the feed when the notification gets sent out. There are some more of these placeholders available under the + button:

plus

Unfortunately, there is no 'preview' available, so sometimes it takes a little guess work to see what the results will look like.

I ended up with this:

notification result

The final step is to create the Recipe.

Now, when someone edits a wiki page on the OSM wiki that is on your watchlist, you will know right away!

notifications in action

(Note that these notifications are not about editing wiki pages :) I did not take a screen shot of those yet. The notifications you see here show whenever someone edits OSM in your area - something I wrote about on my old blog a while ago.

Which camera for capturing 'Street View'?

Posted by mvexel on 4 July 2014 in English (English)

I have been following Mapillary with a good deal of interest, because they provide an open 'street view' platform that is explicitly aimed at improving OpenStreetMap.

Here's an example of a Mapillary image and map context:

example

I have created an account and did some test shooting from my car, using the iPhone app Mapillary provides. This is OK, but I want better quality images. So I am looking at an action camera I can mount in my car and on my bike.

After doing some research, I narrowed the field down to two contenders: the Garmin VIRB / VIRB Elite and the GoPro Hero 3.

The Garmin VIRB (Elite edition shown): VIRB

The GoPro Hero3 (White shown): GoPro Hero3

Some observations:

  • The VIRB seems to have better battery life (important! but could not find any side by side comparisons)
  • The basic GoPro Hero3 is less expensive than the basic VIRB
  • The Elite edition of the Garmin VIRB has lots of built in sensors: GPS, altimeter, accelerometer - nice, but I am already carrying a GPS wherever I go anyway.
  • Both can do automatic time lapse photos at set intervals, which is crucial.
  • The VIRB can do 16MP stills, the most expensive Hero3 can do 12MP. This does not necessarily mean better pictures, of course.
  • The most expensive Hero3 comes with a remote, which can be convenient if you don't want to time-lapse. For example on long freeway drives where you just want to capture the signs. The VIRB can be remote controlled by certain Garmin devices like the Fenix 2 watch. Both come with smartphone apps that can control the camera as well. Convenience factor is much less though.
  • The VIRB has a built in screen. Not sure if that is actually an advantage. What would you use it for?
  • Both have wide angle lenses which is important to capture as much in one shot as possible. Specs are sketchy but it looks like the GoPros have a slightly wider angle.
  • GoPro has been at this for a lot longer than Garmin.

Here's a comparison of the video side by side. I wouldn't use video mode as much so this is of limited value, but anyway:

(The iframe embedding does not seem to work - is there a way?)

From what I can see the GoPro wins out by a small margin: sharper and better colors.

What do you use? Any other cameras to consider?

Complex Intersections, or Why We Should Get Rid Of exit_to

Posted by mvexel on 3 July 2014 in English (English)

Here in the U.S., we have been using the convention of tagging exit information on the highway=junction node using the poorly documented exit_to tag. The rest of the world has been using destination=, and now that I start to think about this problem more, I can see why.

Let's take this example of the junction of I-70 and the Baltimore beltway I-695.

Example situation

(Have you used Mapillary? It's pretty awesome and unlike Google Streetview, OpenStreetMap explicitly does have permission to map from the images. It's pretty easy and fun to contribute your own, too.)

How to tag this so that navigation and other software could make sense of it?

Currently, the only relevant tags on the junction node are ref:left=91B and ref:right=91A indicating the exit / junction numbers. There is nothing on the `_link' ways to indicate destination.

tags

One way I have seen people map this information in the US is roughly exit_to:left=I 695 N;New York;Towson and exit_to:right=I 695 S;Baltimore;Glen Burnie. This is not great for a number of reasons:

  1. There is no way to distinguish the ref information (I 695 S etc) from the names reliably.
  2. The US seems to be the only jurisdiction where exit_to on the junction node is used, the rest of the world uses destination= on the _link ways.

If we were to adopt destination= in the US like everywhere else, most of the signpost information would be on the _link ways after the junction node. Here is the situation in OSM:

situation

The (first part of the) top way is 11830056. The bottom way is 11830053.

According to the destination documentation, the first way would get destination=New York;Towson and the second way would get destination=Baltimore;Glen Burnie.

So far so good. But there's a few pieces of information that are not captured yet:

1) The exit (junction) numbers 91A and 91B. Oh wait - these were already on the junction node as ref:left=91B and ref:right=91A. This works, but intuitively it would make more sense to have this information on the _link ways as well. I am not sure how and the wiki does not give any guidance. (Actually it suggests using ref on the junction node for exit numbers.) 2) The road numbers the exits connect to, in this case I-695 N/S, leading to I-95 N/S. destination:ref seems to be used for that quite a bit. That would work for I-695 but I don't know how to capture the connection to I-95. destination:ref:to?

Following the documentation as best I can, this is what I come up with for the highlighted _link ways:

first tags

second tags

I think this system makes more sense than the exit_to convention that is poorly documented, doesn't scale well to cover complex cases, and is used nowhere else in the world. The only good reason I can think of why people use it is because it's used much more (about 18,000 times) than destination= in the U.S. Elsewhere, from what I can see in TagInfo, destination= is more popular.

Older Entries | Newer Entries