New ImproveOSM tiles are ready to be used!

New ImproveOSM missing road tiles are available! The new data is very helpful as they can help you to target the missing roads, add them to OSM and thus greatly improving the map.

Worldwide, there are 113048 new road tiles.  The countries with the highest number of tiles are: Russia – 38669 tiles, United Kingdom – 8890 tiles, Kazakhstan – 10993 tiles, India –  9418 tiles and the United States- 7560 tiles (see graph below). There are few new tiles in Detroit too so that you are welcome to give us a hand with them! You can find more information about our work in Detroit on our blog (http://blog.improve-osm.org/en/2017/08/lane-number-and-turn-lane-editing-in-detroit/).

 

Facebooktwittergoogle_plus

Lane number and turn lane editing in Detroit

Since we started editing in Detroit, we focused on making OSM navigation ready. We started with the basics: road geometry, road name, turn restrictions, and then we were able to further build on this foundation by adding details like lanes and turn lanes. In the last four months, we focused on adding and updating the lane info (lane number and  turn lane) on motorway, motorway_link, trunk, trunk_link, primary, primary_link, secondary, secondary_link roads in Detroit, Michigan.

For editing lanes and turn lanes we used JOSM, the TurnLanes-tagging Editor plugin and the Lane and road attributes map paint style.

We had two kinds of lane editing: unidirectional road editing, bidirectional road editing. The only difference between those two is the direction tag used in the second case, as you can see in the below table:

For every edited case, we used a simple workflow:

  • we split the way where the number of lanes changes
  • we checked and double checked the aerial imagery to make sure we enter the correct number of lanes and add the appropriate lanes tag
  • we opened the turnlanes-tagging plugin and activated the Lane and road attributes map style
  • using the plugin, we selected the type of the road: Unidirectional road or Bidirectional road
  • we marked the number of lanes for each way needed
  • we marked  the direction on each lane
  • before uploading the data, we checked again that the turn lanes that we had added  were similar to the markings on the road!

The approach of the main cases we’ve met during our edits are exemplified in the next GIFs.

Editing the number of lanes

Adding both ways lane

In some particular cases, when there were doubts, we consulted the OSM community on Github and Talk-US.

While editing, we paid special attention to other already existing features (like route relations, turn restrictions, speed limits, etc). Because all Telenav Mapping team was involved in this project, we established from the beginning some rules, in order to have consistency in our edits:

  • Add a new lane only when you have a line marked on the road (use the satellite imagery, OSC photos  to validate the marks).
  • Links without any marks on road or without one way tag should be edited as a bidirectional road, adding one lane on both driving directions.
  • Never add the turn lane before or after the continuous line mark on the road. The turn lane will be added  starting from the beginning of the continuous line mark on the road.
  • We split and edit lane number even when we have small segments of ways.
  • The location of the junction nodes should be at the beginning of the continuous line marks.
  • We always add the yellow both way lane.
  • We DO NOT add the yellow striped lanes and double marked line lanes.

The main sources used during the project were aerial imagery (Bing, Mapbox, NAIP, Digital Globe) and street level imagery: OSC, Mapillary.

We worked on this issue for 2 months and succeeded to review a large part of motorway, trunk, primary and secondary roads from Detroit area, in order to add or update lane info. During this project, we managed to review 3100 miles and edit 1730 miles of roads.

Here’s how the number of miles of roads with lane information has increased during the project:

The edits we made cover a large area of the Wayne, Macomb and Oakland counties. In the GIF below you can see an evolution (difference between March and July) of our lane info edits in OpenStreetMap.

Heatmaps with our edits during the last four months:

When we finished editing lanes and turn lanes in Detroit, we started assessing the general quality of the lane info by using different approaches. Internally, we call this process quality assurance and we think it is vital to do it after the end of each project.

During the QA process we edited lane info on about 400 miles of roads, and the main issues that we corrected were:

  • incorrect number of lanes and turn lanes
  • duplicated/overlapping ways
  • missing both way lane
  • oneways with lanes:forward/lanes:backward info
  • check roundabouts to have the proper number of lanes

Below you can see some examples of our improvements:

 

Facebooktwittergoogle_plus

Find your MapRoulette Challenge

MapRoulette is a fun way to spend a few minutes (or hours…) improving OpenStreetMap. MapRoulette will present you with a random, easy to solve issue in OSM. MapRoulette is organized in ‘Challenges’, groups of tasks that are of the same nature. For example, there is a challenge to add missing crosswalks in various areas in Switzerland, based on analysis of aerial images.

How do you find a challenge you would like to work on? The MapRoulette home page provides a map of all the challenges, but this has some shortcomings. The challenge ‘centers’ are no

t always representative of where the tasks actually are located. It is also hard to search by topic. MapRoulette also has a search bar that you can use to find a challenge by keyword.

I want to work on making it much easier to find

 interesting MapRoulette challenges, and I would like to hear from you how you think that should work. Please add a comment below with your ideas!

In the mean time, I made a page that lists the most popular and newest challenges. It is a bit of a hack so let me know if it stops working 😉

Happy Mapping!

Facebooktwittergoogle_plus

Help fix up TIGER v1 ways

Old, untouched TIGER ways are still abundant in OSM 🙁 and fixing them up seems to be an endless task.

ugh!

I don’t know why I didn’t do this before, but I finally got around to making a MapRoulette challenge so we can fix them together:

>> Go to the challenge <<

Because the number of old TIGER ways is huge, this challenge covers only a tiny part of the U.S. as you can see here:

Once this part is done, we can reload the challenge with more old TIGER ways.

If you look at the screenshot above, you can also see what the query is that goes into Overpass to create the challenge in the first place. You can easily adapt it to make your own local challenge if you want to start fixing up old TIGER ways with your local mapping friends! (Why not organize a TIGER fixing party? OSM US will pay for pizza!)

If you’re interested in the Overpass details and some ideas for improving it, keep reading. Otherwise, just start fixing! 

Query Overpass for old TIGER

Here is my extremely simplified way to query Overpass for old TIGER ways:

way[highway]["tiger:tlid"](40, -113, 41, -111);
out body geom qt;

It takes the bounding box (40, -113, 41, -111) and searches for ways that have the highway tag as well as the tiger:tlid tag. This query should be a pretty good approximation of a real old TIGER way query, because the tiger:tlid tag is removed automatically when you edit such a way in iD or JOSM. So any way that still has this tag must not have been edited since the import.

This query falls short of a real old TIGER ways query, because the nodes that make up the way may very well have been edited. I am also not 100% sure under which circumstances the editors remove the tiger:tlid and other unnecessary TIGER import tags. It may be safer to look for last edited date or version number. If you have suggestions for improvement, please let me know in the comments.

Happy mapping!

Facebooktwittergoogle_plus

Improving OSM in Canada one day at a time

Ever since we started our mapping project in Canada, nearly 8 months ago, we’ve been continuously working on bringing the OSM data to the level where all elements needed for routing get as detailed as possible.

Whether we are talking about the basics of road networks such as geometry, naming or traffic flow direction, to in-depth details like number of lanes, turn lanes, turn restrictions, signposts and even complex relations referring to highways, we edit everything.

Our main focus is oriented towards the Top 5 metro areas: Toronto, Montreal, Ottawa, Vancouver, Calgary. These are the places where we spent the most of our time researching for open data, adding new features, editing existing ones. In order to make sure that the overall state of OSM throughout the entire region of Canada is in navigable ready state, we’ve also included the first 50 cities based on population.

So, let’s see some numbers and graphs because everybody likes those. If we start looking at the numbers for the entire region we can see a significant rise in road geometry that was added, around 3% (25,330 miles) out of the total numbers of miles. The same goes for roads that previously did not have name tags with a rise of little over 3.5% (16,799 miles).

A more significant change can be noticed for features that weren’t extensively mapped before in the area, such as turn restrictions rising from 5254 to 54891, or signposts which hadn’t been mapped under the same standardized method. With the help of OpenStreetCam and Mapillary pictures, we’ve managed to add relevant signpost information increasing the number of nodes well over 68%.

If we break down the numbers for the Top 5 areas, the most noticeable changes can be observed for both Toronto and Montreal where oneway tags and signpost information have been improved.

One of our main goals is to focus not only on quantity but especially on quality. This is why we have multiple tools for integrity checking that are ran periodically on the entire region of Canada. These tools cover a wide variety of cases that are being corrected weekly, such as: road name flip-flops, unconnected ways, smoothness problems, misnamed road, road names having their suffixes or prefixes abbreviated and many more.

We make use of different QA tools (KeepRight/Osmose) to search and track issues in OSM that have either been added by mistake or have remained unedited after large imports. We’re also on the look out to improve way accuracy and fix alignment issues.

An overview of our edits.

Below you can see some examples of our improvements.

Road geometry updates.
Road geometry alignment.
Missing geometry and minor refinements.
Turning loops updates.
Facebooktwittergoogle_plus

Mapping traffic signals and stop signs using MapRoulette

In our journey of improving  the OpenStreetMap we are constantly searching for  open source data. This search is very important and is done before we start improving the map in a new area.

Currently, part of our team is focused on improving the Detroit area. So, before we started mapping we searched for useful geospatial data and we came across open data about traffic signals and stop signs for Wayne County, Detroit. The data can be found here and here.

Traffic signals mapped in OSM
Stop signs mapped in OSM

We filtered out the traffic signals and stop signs that were already in OSM but there is still a significant amount of data that can be added in OSM. (912 – traffic signals and 8755 – stop signs). Due to this, we thought about creating a MapRoulette challenge.

About MapRoulette

MapRoulette is a micro-tasking tool used to fix bugs in OpenStreetMap and to improve it. A user can create tasks by uploading files which contain the location, ways, points with the error that has to be fixed or files with features that are missing from the map and can be added by other users.

When creating a new task, the user gives specific instructions on what steps have to be followed to edit through this tool. Once a user has logged in, he can see on the map the created challenge and the pins which consists of tasks he can solve.

So, given the available data that we found, we created two challenges – one for traffic signals and the other for stop signs. Some general rules for mapping traffic signals and stop signs can be found on the OSM wiki – here and here.

Tags that we use for mapping
  • Stop signs – highway=stop
  • Traffic signals – highway=traffic_signal
Notes
  • If the traffic signal/stop sign is referring to all the highways entering the intersection, we add the traffic signal/stop sign in the intersection point.

  • If the traffic signal/stop sign is not referring to all the highways entering the intersection we add the traffic signal/stop sign before the intersection, where the sign/signal is positioned.
  • We need to add an additional tag if the road is bidirectional:
    • for traffic signals we use the traffic_signals:direction key with the forward or backward values to indicate the affected direction.

    • for stop signs add direction=forward or direction=backward to indicate the affected direction.

The data has been published under Public Domain license.

Everyone who is keen on mapping is welcomed to help us.

Let’s improve OSM together!

Facebooktwittergoogle_plus

OpenStreetCam JOSM plugin – new features

Last week we had released a new version of the OpenStreetCam JOSM plugin. While we are continuously working on improving and fixing existing functionality, we also keep adding new and exciting features.

Map view improvements

This new release introduces a major improvement to the map view. For small zoom levels, we had adopted a similar visualization as in the case of the web and mobile OpenStreetCam applications. Instead of displaying individual photo locations we display ways that have OpenStreetCam data coverage.Segments are colored with purple and have different transparency based on the data coverage: segments that have many images are opaque while the segments that have only a few images are more transparent.

By changing the initial MapView visualization we were able to display OpenStreetCam data starting with zoom level 10. This way we can indicate areas that have street view coverage at a country view level and possible gave a hint to the user where he/she can find an extra source of mapping support.

Starting with zoom level 18 the map view changes and individual photo locations are displayed similarly as in the previous versions of the plugin.

The displayed data type is user configurable and can be changed from the OpenStreetCam plugin preference settings. You can access the preference settings from JOSM ->Preferences -> OpenStreetCam plugin -> MapView settings or from the OpenStreetCam panel by clicking on the preference icon. 

From the MapView settings section, you can change the minimum zoom level at which image locations are displayed, along with the data type change method. By default, the MapView data type is changed automatically.                                                                                               When the “switch manually between segment and image view” option is enabled a new button is visible in the OpenStreetCam panel.

The “data switch” button is enabled starting from zoom 16 and is represented with different icons based on the displayed data type. For segment map view a photo icon is displayed while for image location view a segment icon.

If you click on the button the map view changes from segment view to image location view and vice-versa.  The type of data can be changed manually for zoom levels bigger than 16.

 

Layer and panel improvements

The OpenStreetCam layer and panel default visibility had been improved and previous open/closed states are remembered for future JOSM sessions. After installing the plugin in order to see the OpenStreetCam data you need to open manually the layer and panel. The layer can be opened from Imagery ->OpenStreetCam menu, while the panel from the left side JOSM menu.

We had changed the OpenStreetCam window button panel actions and removed the actions that were not related to the currently selected image. Feedback and filter actions were added to the OpenStreetCam layer menu:

In case you need a refresher:  OpenStreetCam data can be filtered based on date and currently logged in OSM user. Basically you can visualize images that were uploaded after the specified date. You can also visualize only your contributed data.

Nearby photos

An important feature that we had added to the plugin is the nearby photos functionality. This functionality improves the mapping process especially if the selected photo does not contain all the information or if the selected photo has bad quality or has not the right angle.

A nearby photo of a selected photo can be visualized either by clicking on the “Nearby photo” icon or by pressing ALT+N keys. 

If the “Load track on image selection” preference settings option is selected , than also the track corresponding to the nearby photo is loaded.

Nearby photos are computed based on the currently visible photos, if the user moves the map or zooms in the set of nearby photos is recomputed.

A photo is considered nearby if belongs to a different track and it is located to maximum distance from the selected photo.

Photo load on mouse hover

Another important feature that we had added to the latest release allows users to quickly load photos on mouse hover action.  By default this feature is disabled and can be activated from JOSM ->Preferences -> OpenStreetCam plugin -> Image settings.

If this feature is activated, than the small thumbnail image is loaded in the OpenStreetCam panel and remains loaded only it is explicitly un-selected from the map.

A better resolution image is loaded if you click on the image location icon or if the OpenStreetCam panel is maximized.

Upcoming features

The JOSM plugin is work on progress, we are working on improving the usability and plan to add new features from time to time.

We hope that you enjoy the new features! If you have ideas, suggestions or encounter any issue with the plugin during editing sessions please submit either to the GitHub issue page or to the Feedback forum .

Have fun improving the map by using OpenStreetCam images!

Facebooktwittergoogle_plus

3D Scene reconstruction

From 2D images we can extract a limited range of information like width, height and color. These can be useful to determine the regions of interest in our images: street signs, lanes, or even roads.

However, for a more accurate detection, the depth perception
is crucial. Here comes the 3D reconstruction into play. Extracting a 3rd dimension, the depth, we can determine how far from the
camera the regions of interest are and consequently, their shape. This way we can distinguish the road from the obstacles (cars, pedestrians, curbstones) simply because we know that the road has an increasing distance from the camera while the objects have a constant distance (fig. 1).

fig. 1 Depth Map

Continue reading “3D Scene reconstruction”

Facebooktwittergoogle_plus

More and Updated Data for ImproveOSM

ImproveOSM has been updated with many new roads. We processed recent  GPS data from a number of data partners with some great results. A total of 30,000 new missing road tiles were added, over 17000 in Indonesia alone.

Aside from the missing roads, we added 67000 potential missing one-way roads that we detected with high confidence. Internal testing revealed only 6% false positives.

We are happy to continue providing OSM mappers with high quality data about missing things in OSM based on billions of GPS traces. Because ImproveOSM is based on actual drives from people using navigation or mapping software in their vehicles, and we apply a pretty high threshold for number of trips and quality of the GPS data, you can be pretty confident that every ImproveOSM feature will lead you to something you can add to OSM. Even if the aerial imagery is poor.

You should see the new data in your ImproveOSM plugin or on the ImproveOSM web site very shortly. Happy mapping and let us know what you mapped using ImproveOSM!

Facebooktwittergoogle_plus

New Version Of OpenStreetCam Introduces Points

Late last week, we released new versions of the OpenStreetCam apps and the web site. While we continue to make the platform faster and more reliable, we also like to keep adding interesting and fun features from time to time! This new release introduces points and levels. Every time you drive, you earn points. Earn enough points and you level up.

We went back in and calculated points for all your existing trips, so why not head to the newly designed leaderboard and see how you stack up against your fellow cammers? You can also see the leaderboard in the app:

We also enabled leaderboards by country on top of the daily, weekly and monthly rankings.

Your profile screen in the app and on the site will show you exactly how many points you have, how many you earned per trip, and what your current level is.

The new profile screen

More points for unexplored roads

So as you are driving around, you will automatically earn points for every picture recorded. But not all pictures earn you equal points! The less explored a road is, the more points you get — up to 10x the points for roads that have no coverage at all yet!

(This made it possible for me to gain 11k points on a 50 minute drive last week: most of the roads had no coverage yet, so I was getting 10x points for most of the way. )

11k points!

You can see which roads are less covered, or not covered at all yet, in the app. Just look for the roads with lighter or no purple OSC overlay:

Darker streets have better coverage, lighter streets need more.

We calculate the quality of coverage by the number of trips that cover the way as well as the age of the existing trips. This way we encourage each other to always have the most recent imagery available for OpenStreetMap.

We hope you enjoy the new features! Please let us know what you think by writing us at hello@openstreetcam.org.

Facebooktwittergoogle_plus