Recent diary entries
Here's an example of a Mapillary image and map context:
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.
The Garmin VIRB (Elite edition shown):
The GoPro Hero3 (White shown):
- 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:
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?
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.
(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:right=91A indicating the exit / junction numbers. There is nothing on the `_link' ways to indicate destination.
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:
- There is no way to distinguish the
I 695 Setc) from the names reliably.
- The US seems to be the only jurisdiction where
exit_toon the junction node is used, the rest of the world uses
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:
According to the
destination documentation, the first way would get
destination=New York;Towson and the second way would get
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: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.
Following the documentation as best I can, this is what I come up with for the highlighted _link ways:
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.
We created a new MapRoulette challenge over at Telenav: Crossing Ways. As always with the Telenav-generated challenges, this one is US only, because we currently only process OpenStreetMap data for the United States. We are working on extending support for other regions.
TL;DR --> On to MapRoulette!!
The Crossing Ways challenge is pretty straightforward and should make for an easy challenge for novice mappers looking for something to fix. It detects ways that cross, but neither way is tagged as a bridge or tunnel. Here is an example:
If you open this up in iD or JOSM, you will be able to tell the required resolution from the aerial imagery:
In this case, the ways should be connected as there is clearly an intersection. Another possibility is that there actually should be a bridge or tunnel tag on either of the ways.
In this particular case, you can see that there actually is a node at the intersection, but it does not connect both ways. In JOSM, it displays as a 'skinny node':
In this case, you can use JOSM's 'Join' function (shortcut 'J') to connect both ways. In iD, a node connecting two ways will be grey, and a regular node will be white:
If you use iD, you can just drag an existing node to the intersection to snap the two ways together, or drag a virtual node to the intersection to create a new intersection node. (Virtual nodes appear between two existing nodes and allow you to quickly create a new node on a way, an example shown below.)
There are currently around 19,000 cases in the US alone, so let's get on fixing these annoying bugs in OSM!
From time to time someone will ask me: 'How do I find out who my fellow local mappers are?'
That can be a surprisingly hard question to answer. You can go to your user page and see a few people who have indicated their 'home location' to be near yours. That does not work so well for a variety of reasons:
- Not all people set their home locations. My guess is most people don't.
- People don't update their home locations when they move.
- The home location is not necessarily where that person is mapping.
You can also have a look at Pascal Neis's wonderful 'Overview of OpenStreetMap Contributors aka Who's around me?' map, which gives you a visual impression of mappers in your area based on actual mapping activity. This is much better! But it still does not always give you the complete picture. For example, if I navigate to Salt Lake City, where I have lived and mapped for three years now, I can't find myself on that map. I guess I am mapping too much in other places for Pascal's algorithm to detect me as a local mapper.
Dennis Zielstra's engaging talk 'Where Are The US Mappers At' at State Of The Map US 2014 made me revisit this problem (and dig up some old code, more on that in a bit). He presented an in-depth analysis on user engagement and community activity for top US cities. Following that talk, I had a few interesting discussions focusing on questions like
What to do about those cities that do not have an active local community?
How can we make it easier for people to start organizing their community locally?
If we're going to address these questions, we need a better way to identify who active mappers in our area are, and contact them.
For contacting, we will need the groups functionality on OSM.org that has been under development for a while. Being at SOTM US and catching up with lots of mappers from all over made me eager to get this project going again.
For identifying, I think I can contribute something. I wrote some code on top of osmjs a couple of years ago that I dusted off. It processes a full history planet file for an area and outputs stats for all users who have ever contributed in that area, things like:
- First and last edit
- Total number of edits
- Number of edits still visible in today's data
I ran it on Los Angeles county and this is what came out. As a list, it is already pretty insightful, but you can roll nice visualizations with it as well. Enter the Brave Mappers Of Wherever You Are project that was sitting under the same layer of dust. I ran it on the LA county output with this result.
Brave Mappers shows a timeline of mappers for your area based on historical OSM data. A long bar is a mapper who has been active for a long time, like techlady here:
The users are sorted by how long they have been active in this area. Scrolling down, there are some interesting outliers to be seen. Here is DaveHansenTiger, the original TIGER import account:
As expected, active for a short time right at the beginning of the timeline. The green color of their bar means that they mostly created things (rather than modifying or deleting). The transparency indicates most of their work is no longer in the current data. In this case that is probably a good thing!
Finally, clicking on a user's bar gives some more details on their contributions:
If you want a Brave Mappers page (or just the spreadsheet) for your area, that can be arranged! If you feel up to it, you can clone the OSMQualityMetrics repo and run
UserStats.js yourself on a full history planet for your area, then process it with the script in the bravemappers repo. Or you can send me an OSM POLY file and I will try and make some time to do it for you!
Over at Telenav we have been busy comparing the GPS traces of drivers using our navigation apps against OSM data. This is fun work and sometimes leads to really useful results. One of our recent studies involved comparing what we think are one-way streets to the corresponding OSM ways. The process is quite simple: count how many traces following a given street go in one direction, and how many go in the other. If the number for one direction is close to zero, the street is probably one-way. The outcome depends on the confidence level you apply, but it turns out that there are more than 100 thousand OSM ways that probably should be marked with a oneway tag, but aren't.
One. Hundred. Thousand.
I don't know about you, but I think that would make for a really great MapRoulette challenge. So that's what I did, and here it is.
But how do you know if a street should be one-way without having eyes on the ground? It turns out the aerial imagery provides helpful hints. Let me show you what I look at to verify the one-way-ness of a street using just JOSM and the Bing layer.
Let's look at this case here:
Notice the arrowhead? That is the direction we found the vast majority of trips followed, so we think that is the one-way direction of this street. Let's look in JOSM:
In this case, there is really only one hint that this is in fact a one way street, but it's a pretty convincing one: The markings on the road. See the stop line? It goes all the way across, which it wouldn't if traffic were allowed to enter from the right. Also, it is a little blurry, but there is what appears to be a left arrow painted on the road as well. So all in all, I am convinced that this way should be marked oneway=yes.
Be careful though! OSM ways can be very long, and the one-way restriction may not apply to the entire way. So always be sure to check the entire length of the way before you tag and upload, and split the way as necessary! The Telenav detection works on smaller segments internally, so the suggested one-way-ness does not always apply to the entire OSM way.
Lets' look at another case.
Looks like a residential area. Let's load it up in JOSM:
In this case, it's really hard to see. There's no obvious stopping line that I could see, and there's too much shade to see if there are parked cars on the left side of the street that are parked facing west - which would be another good indication that it is a one-way street, because it is illegal in the United States to park in the opposite direction of the flow of traffic. So this one I would mark as 'Couldn't See'. Perhaps someone else sees something I don't? Here is the permalink to the task in MapRoulette. (Neat eh, permalinks - makes it easy to share a task you want to discuss or highlight. They remain valid even after a task is fixed or even deleted.)
Oh and yes, I am afraid this is another United States only challenge... We are working hard to get more international challenges in, and we already have some interest. I am sure I mentioned this before, but MapRoulette now has an API that lets 'third parties' submit their own challenges. On top of that, we're also making it really easy to deploy your own MapRoulette server. If you're interested in any of that, just let me know. I will be hosting a session on MapRoulette at State Of The Map US this weekend, and Serge and are also planning to run a BoF session for a deeper dive into MapRoulette challenge making. If you don't make it to SOTM US, don't feel left out - there will likely also be MapRoulette sessions at SOTM EU in June!
Those first few MapRoulette challenges did not keep you busy very long: most tasks in the Zorro / Tangled / Wrong One Ways challenges were fixed within the first few days. Dang! We were not prepared for that and had to take MapRoulette down for a little while because there was nothing to do...
But now we're back! This time with Ways Needing Smoothing. We detect ways that have suspiciously sharp angles and ask you to smoothen them out. Here's a great example:
Opening this task up in JOSM reveals that there's more to fix than just the one sharp angle that was detected:
This is typical for the US TIGER data - poorly aligned ways that are either under- or overnoded. And there's still a lot of them! We detected over 100,000 cases, not all of which are loaded for this challenge yet.
This challenge is bound to have some more tasks than usual that are not 'real' errors - that is the nature of challenges of this type. Just skip over them and mark them as 'not an error'. They will not show up again.
Oh and finally - a cool new little feature is the permalink: you can now link to any task you encounter and want to discuss or share. The link for this one is http://maproulette.org/#t=ways_needing_smoothing/527470359108565095470769424325999623764196595999
Happy mapping :)
We are about to launch the new version of MapRoulette! Finally! The most obvious changes are that you now sign in using your OSM account - so you can track your and other mappers' progress, and multiple challenges being available to choose from! We will launch the day after tomorrow with four new challenges to start with: the familiar Zorro Ways, ways with overlapping parts, wrong one way ways (if you know a better name, let me know..) and tangled ways. More to come!
Behind the scenes much more has changed. There is now an API for challenge providers to post their own challenges (let me know if you want access), challenges can have an area associated with them so you will be able to choose a challenge that is local to you, and they also have difficulty levels. The entire application has also been rebuilt from the ground up to be more stable, scalable, and allow more flexibility for different types of challenges in the future. If you want to see how MapRoulette is built, check out MapRoulette on Github.
So, on March 12, head on over to maproulette.org and start fixing!
I keep coming across beautiful OSM-based maps! Here is one for Poland:
Go explore for yourself here.
We are trying out something new here in Salt Lake City, Utah: Saturday Mapternoons. The next one is tomorrow, and I am looking forward to it. Saturday Mapternoons are a mix of mapping, catching up with fellow local OpenStreetMappers and geeking out over all things geo. If you're in the area, join us!
Check out all upcoming OpenStreetMap Utah events on our meetup page.
(This was originally posted on my blog. I want to start posting here more instead. This is a start.)
If you follow the blog at openstreetmap.us, you will have heard about the Battle Grid. It is a map that shows you where recent TIGER data is different from OpenStreetMap data. Because TIGER has improved a lot over the years, and has kept up reasonably well with new road construction, a big difference between TIGER and OSM tells us that OSM likely needs some love. Here is how the battle grid looked until today:
Cells with a lot of difference between TIGER and OSM are brighter, and as a simple way of prioritizing the cleanup and update work, I colored the cells that are within a Census CDP orange, and the rest green.
As of today the Battle Grid will look like this, instead:
The brightest cells are still the most different. What is new is a color spectrum ranging from green to red, indicating how many people drive in and through each cell. This is based on Telenav logs. Because lots of people use Telenav apps such as Scout every day, it should be a fair representation of interestingness.
Let me show you a few examples of bright Battle Grid cells to whet your appetites.
Here’s a bright red cell in Greenville, NC:
Look at this! Missing subdivisions, and poorly aligned streets. A mess!
If I weren’t writing this blog post I’d be fixing this…
The green cells are usually no less, ehm, interesting. Here’s one in Saint Louis, MO:
I guess someone had a plan for this area, and the someone with more money / power came along with a different plan, and nobody ever told Census:
What I generally find is that the bright cells on the fringes of urban areas are most gratifying. These usually represent either poorly aligned OSM data, unmapped new subdivisions, or a combo of both.
Speaking of fringes, I think Atlanta has a great visual Battle Grid story:
The city itself is well mapped with very few bright cells. (And whatever there was is mostly black, so people have already marked them as done.) The fringes still show a lot of, well, let’s call it mapping potential!
What are your favorite Battle Grid finds? Share them below!
I was just looking at my user map to see what's going on with OpenStreetMap users who are in my area. It turns out many of them have zero edits. They signed up for OSM, even put in the additional, optional effort of setting their home location, but never edited. Why?
That is the Big Question we want to try and answer in the Welcome Working Group. That, and trying to come up with solutions for the 'retention problem'. Simply said, provide a warmer welcome to new users. Our focus will not be on editors. Rather, we want to look into documentation, welcome messages, incentives to map.. You could say: the social and educational dimensions of welcoming newcomers to the community.
Do you think you have something to contribute to this process? Helping (re-)write documentation? Research new user behavior? Another angle you would like to explore? All it takes is constructive ideas and some time to act on them. We meet on #osm-strategic every Thursday at 1900 UTC.
I'm back in Amsterdam for a bit. I haven't really have time to do any mapping yet but I'm happy to see that the area where I'm currently staying is now littered with POIs - bars, restaurants, shops, all the goodness that the Leidseplein area is well known for. Even the recently started Starbucks Invasion into the Netherlands is already reflected. Most places have URL and/or phone number data associated with them. It looks like we have user stroet43 to thank for most of the recent improvements in this area. Great work! I don't think I've met him or her. Maybe at the upcoming New Year's Drinks in Utrecht? I don't see a link to it anywhere on the OSM wiki, but they're in Utrecht this Sunday. Inquire on talk-nl if you want to know more I guess. See you there?
I got on the remapping train. It looks like Salt Lake is pretty severely affected because of a small number of decliners. I approached one of them, and he is not changing his mind. Approaching the other few soon. In the mean time, I'm focusing on the main road network. There's even a few miles of interstate that will need to be remapped. A lot of work, and not the most fun job. On the other hand, I get to (re)visit some places that could use some improvement.
You can reliably measure how bored I am on any given day by counting how many trees I have mapped on that day.
to set up a local Amsterdam OSM mapping clubje
did IJplein this afternoon and some Java-eiland
We had a good first day of the Amsterdam Mapping Party. I made my very first contribution to OSM: my oen lovely neighborhood Staatsliedenbuurt. And because the weather was super, I took the dog for an extra long walk around the garden complex 'Nut en Genoegen' ('Purpose And Joy').