Making OSM navigation ready in Phoenix, AZ

GPS technology is growing fast along with the mapping industry. There are a lot of navigation apps on the market, trying to step forward using different technologies and map data. As you know, behind all its routing processes and algorithms, a good routing application must have a good quality map.

Our team, Telenav, is developing an Open-Street-Map (OSM) based app, called Scout. Why Open-Street-Map? In my opinion OSM is a good choice because it’s an open, fast growing and well built-up community map. With its great involvement and commitment, the community is constantly trying to keep all the map features from OSM up to date.

For the purpose mentioned above, Telenav decided to improve the quality of the OSM map features, used for navigation, in Phoenix, Arizona.

From September until now, the whole project workflow was realized in 3 main steps:

Step #1. Research and get in touch with local community (research on local open source data, keep in touch with local OSM users, official traffic signs and driving rules, research on HOV and toll roads, roads under construction, other specific road features of Arizona State).

Step #2. Build-up process:

  1. Road geometry, Road Name, One Way, Gates and Other Geometric Feature (turning circles, turning loops, etc.)
  2. Signpost
  3. Turn Restrictions and Traffic Lights
  4. Lane and Turn Lane Info, including HOV Lanes and Toll Roads
  5. Speed Limit Editing

Step #3. Quality Assurance (QA for every feature edited by our team in OSM, some road name special issues, repairing broken relations, final edits and corrections based on Improve OSM plug-in, Osmose and Keep Right errors, tile-by-tile verification).

The first step was a very important one because the team had to get in touch with the local community and mapping rules. Also, we researched other open source and free of charge data beside the already well-known sources used by OSM users (TIGER Roads, Bing, Digital Globe, Open-Street-Cam, Mapillary). The under-construction roads found in this step were permanently monitored, to be edited later.

The second step was the most time consuming and it included the editing and reviewing of all the most important navigable OSM features, starting from motorway, trunk, primary, secondary, tertiary, residential and service ways. The whole editing process lasted for about 3 moths and the workflow was mainly based on a tile-by-tile method. We also edited based on way category or route reference. During this period, we helped the community to increase the OSM quality as you can see below:

The third step was the last but not the least important. Because we wanted to have good quality features in OSM, we had to make a closure check on our edits, already made in the build-up process and where it was necessary, to fill the gaps. So, we used different QA procedures, queries, other plug-ins, error identifiers and even tile by tile verification.

For the queries based QA, we ran some predefined scripts based on OSM datasets, using pgAdmin and PostgreSQL. The queries were aimed mainly at finding:

  • Wrong one-way direction
  • Wrong number of lanes
  • Untagged roads
  • Long relation members
  • Turn Restrictions with unusual number of members
  • Ramp has name or reference number
  • Similar names and destinations
  • Detect possible roundabouts, etc.

The main JOSM plug-in used to complete the missing roads was Telenav ImproveOSM (also available on https://improveosm.org). The plug-in focuses especially on missing roads, one ways and turn restrictions.

Also, a good source of errors to be checked can be found on these error identifier sites: http://osmose.openstreetmap.fr/en/map/ and https://keepright.at/.

Doing the QA, we had an important overview of all our edits, especially of our wrong ones. In this step, we resolved also a name tag issue we’d came across during step #2. Step #3 represents confidence of a good quality editing process for the Telenav team.

When we needed a double check of our work, the community was a good help, giving us important feedback. For the next months, we’ll surely keep in touch continuously with the local OSM users, looking forward for their feedback to keep up a good maintenance work. The top editing users were the most helpful users, giving us precious and pertinent feedbacks.

In the GIF below you can see an evolution of Telenav mapping team edits during the last moths, in Phoenix, Arizona. Darker colors indicate high density and brighter colors low density.

Facebooktwittergoogle_plus

Turn restrictions editing in Phoenix, AZ

Looking from a map analyst point of view, turn restrictions are some of the most important features a map can have. Turn restrictions influence a lot the way a route is made. If they are wrongly edited, they can cause bad routing, having big consequences on travel time, travel directions, maneuvers and so on. That’s why we decided to talk a little bit more about this case: editing turn restrictions.

We worked on this issue for 3 months, starting from November 2017. We succeeded to review a large amount of intersections between motorway, trunk, primary, secondary, tertiary, residential and service ways from Phoenix area.

During our project we accomplished:

  • to add new turn restrictions
  • to correct some of the damaged ones
  • to remove some of the wrong ones.

The main sources of adding or editing turn restrictions were open-source:

  • Satellite imagery: Digital Globe, Bing, Esri World Imagery
  • Street level imagery: Open-Street-Cam (OSC), Mapillary.

The software used in editing OSM was JOSM, an extensible editor for Open-Street-Map for Java 8. Also for a better visualization we used different Map Paint Styles (MapCSS) and thematic Layers (Open-Street-Cam, Mapillary, Mapillary object layer).

With a self-developed procedure, we identified all that could be a turn restriction sign in all the OSC track photos, overlapping our area. In the first part of our project we looked over 1723 turn restriction signs identified in Open-Street-Cam, spatially distributed as in map below. Before adding any turn restriction, every detection or sign found in Open-Street-Cam was first validated based on the open sources first mentioned.

In the second part, we managed to identify turn restriction signs also based on Mapillary Imagery and Mapillary Object Layer.

All the reviewed turn restriction signs summed in the end 3289, from which 350 turned to be missing from Open-Street-Map. During this task we also reviewed 11932 and added 376 new traffic lights.

The final step for our task was to do some QA testing. Firstly, we used a query based QA to verify the quality of all turn restrictions from OSM Phoenix area. For this, we ran some predefined scripts based on OSM datasets, using pgAdmin.

The queries aimed mainly:

  • Long relation members
  • Turn Restrictions with unusual number of members
  • “Odd” tagging in existing turn restrictions
  • Conditional turn restrictions with old tagging scheme

Example of query used to identify unusual turn restrictions from OSM:

We wanted to make sure we’re covered all turn restrictions. So, we used the Telenav ImproveOSM plug-in in JOSM. The plug-in highlights the possible turn restrictions locations based on road geometries and other probe data.

These kind of errors identified by us during the query based QA can also be found on http://osmose.openstreetmap.fr/en/map/ and https://keepright.at/ sites. These two sites contain datasets with all kinds of errors from OSM. The datasets were downloaded, extracted using some Python scripts, clipped after our bounding box and filtered using some SQL queries in pgAdmin. The results were exported and compared with the initial errors resulted in the first QA step and where it was necessary, the turn restrictions were modified or corrected.

The heat map below presents all the turn restrictions edited by the Telenav team, from November until now, in Phoenix. Darker colors indicate high density and brighter colors low density.

Facebooktwittergoogle_plus

Telenav presence in State of the Map Latam 2017

It has been only two years since the Latin American OSM community decided it was necessary to have a regional event. The first event took place in Santiago the Chile and the second one in Sao Paulo, Brazil. At the end of the second edition there were a few places considering to organize the third edition of the event. When I found out Lima was chosen I was very happy. Lima is one of the cities you never get tired to visit and you always discover new things, specially new amazing food 😉

This year Telenav had the chance to be sponsor. Every State of the Map is a gathering of different efforts that combining together keeps improving the data of the largest geospatial database in the world. This sponsor supported the attendance of Juliana Hernández (Peasent mappers- Tools for learn, teach and strengthen cartography) and Daniel Quisbert (Installing and configuring Offline OSM in Linux).  Both conferences where highly appreciated by the attendees.  Also Mapbox and Telenav co-hosted the first anniversary of Geochicas, it was a lovely evening in an historic bar from Lima in the one new geochicas from Perú and Colombia joined the group. We expect more companies collaborating together to reduce the gender gap in OSM. There are many ideas for what Geochicas will be doing in 2018, please check the full information here.

The keynote was given by Philipp Kandal (A journey with OSM from the past into the Future) In the one Philipp shared his experiences over the years with OSM data and how probe data and using machine learning tools the map its being improved in a tremendous way.

From my side I had  the chance to show the mapping efforts in Canada and the preliminary mapping results from Ecuador, a pilot project we are currently developing to improve road data in one LATAM country. By using Satellite imagery and OpenStreetCam data we started improving the OSM data in roads since September this year. Find the slides here. So far the results we have are the following:

Stay tuned for the updated results in the following months!

This is just the beginning of future collaborations Telenav would like to keep doing with Latam communities by providing tools and guidance in previous projects we have done.

Thanks to the organization team and attendees of SOTM LATAM 2017, see you in other place in Latam in 2018!

Facebooktwittergoogle_plus

Is OpenStreetMap Big Data ready?

This article was written by Adrian Bona as a draft for a talk at State of the Map US in Boulder, Colorado this past month. The talk did not make it into the program, but the technology lives on as a central part of our OpenStreetMap technology stack here at Telenav. We will continue to deliver weekly Parquet files of OSM data. Adrian has recently moved on from Telenav, but our OSM team is looking forward to hearing from you about this topic! — Martijn

Getting started with OpenStreetMap at large scale (the entire planet) can be painful. A few years ago we were a bit intrigued to see people waiting hours or even days to get a piece of OSM imported in PostgreSQL on huge machines. But we said OK … this is not Big Data.Meanwhile, we started to work on various geo-spatial analyses involving technologies from a Big Data stack, where OSM was used and we were again intrigued as the regular way to handle the OSM data was to run osmosis over the huge PBF planet file and dump some CSV files for various scenarios. Even if this works, it’s sub-optimal, and so we wrote an OSM converter to a big data friendly columnar format called Parquet.The converter is available at github.com/adrianulbona/osm-parquetizer.Hopefully, this will make the valuable work of so many OSM contributors easily available for the Big Data world.

How fast?

Less than a minute for romania-latest.osm.pbf and ~3 hours (on a decent laptop with SSD) for the planet-latest.osm.pbf.

Getting started with Apache Spark and OpenStreetMap

The converter mentioned above takes one file and not only converts the data but also splits it in three files, one for each OSM entity type – each file basically represents a collection of structured data (a table). The schemas of the tables are the following:

node
 |-- id: long
 |-- version: integer
 |-- timestamp: long
 |-- changeset: long
 |-- uid: integer
 |-- user_sid: string
 |-- tags: array
 |    |-- element: struct
 |    |    |-- key: string
 |    |    |-- value: string
 |-- latitude: double
 |-- longitude: double

way
 |-- id: long
 |-- version: integer
 |-- timestamp: long
 |-- changeset: long
 |-- uid: integer
 |-- user_sid: string
 |-- tags: array
 |    |-- element: struct
 |    |    |-- key: string
 |    |    |-- value: string
 |-- nodes: array
 |    |-- element: struct
 |    |    |-- index: integer
 |    |    |-- nodeId: long

relation
 |-- id: long
 |-- version: integer
 |-- timestamp: long
 |-- changeset: long
 |-- uid: integer
 |-- user_sid: string
 |-- tags: array
 |    |-- element: struct
 |    |    |-- key: string
 |    |    |-- value: string
 |-- members: array
 |    |-- element: struct
 |    |    |-- id: long
 |    |    |-- role: string
 |    |    |-- type: string

Now, loading the data in Apache Spark becomes extremely convenient:

val nodeDF = sqlContext.read.parquet("romania-latest.osm.pbf.node.parquet")
nodeDF.createOrReplaceTempView("nodes")

val wayDF = sqlContext.read.parquet("romania-latest.osm.pbf.way.parquet")
wayDF.createOrReplaceTempView("ways")

val relationDF = sqlContext.read.parquet("romania-latest.osm.pbf.relation.parquet")
relationDF.createOrReplaceTempView("relations")


From this point on, the Spark world opens and we could either play around with DataFrames or use the beloved SQL that we all know. Lets consider the following task:

For the most active OSM contributors, highlight the distribution of their work over time.

The DataFrames API solution looks like:

val nodeDF = nodeDF
    .withColumn("created_at", ($"timestamp" / 1000).cast(TimestampType))
    .createOrReplaceTempView("nodes")

val top10Users = nodeDF.groupBy("user_sid")
    .agg(count($"id").as("node_count"))
    .orderBy($"node_count".desc)
    .limit(10)
    .collect
    .map({ case Row(user_sid: String, _) => user_sid })
    
nodeDF.filter($"user_sid".in(top10Users: _*))
    .groupBy($"user_sid", year($"created_at").as("year"))
    .agg(count("id").as("node_count"))
    .orderBy($"year")
    .registerTempTable("top10UsersOverTime")


The Spark SQL solution looks like:

select 
    user_sid, 
    year(created_at)) as year,
    count(*) as node_count
from 
    nodes
where 
    user_sid in (
        select user_sid from (
            select 
                user_sid, 
                count(*) as c 
            from 
                nodes 
            group by 
                user_sid 
            order by 
                c desc 
            limit 10
        )
    )
group by 
    user_sid, 
    year(created_at)
order by 
    year


Both solutions are equivalent, and give the following results:

alt tag

Even if we touched only a tiny piece of OSM, there is nothing to stop us from analyzing and getting valuable insights from it, in scalable way.

If you are curious about more advanced interaction between OpenStreetMap and Apache Spark, take a look at this databricks notebook.

OpenStreetMap Parquet files for the entire planet?

Telenav is happy to announce weekly releases of OpenStreetMap Parquet files for the entire planet at osm-data.skobbler.net.

Facebooktwittergoogle_plus

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

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

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

OpenStreetCam JOSM plugin

The OpenStreetCam JOSM plugin helps the community to improve the map by displaying up to date street view images. Street view images are collected by the OpenStreetCam platform and are available also via the OpenStreetCam web application and map editor.  

Having an extra source of free and open imagery ease the process of remote mapping and allows the users to reflect the reality also in the map. Street view images are helpful for editing map features that are not visible on satellite imagery like traffic signs, house numbers, bus stops, points of interests.

Installation

Install the OpenStreetCam plugin the familiar way, through the JOSM plugin Preferences menu item. After you install the plugin and restart JOSM, you should see the OpenStreetCam layer and panel.

OpenStreetCam layer

After a successful installation the OpenStreetCam layer is available in the layer menu panel and on the main map the image locations are displayed. Image locations are illustrated with blue icons, each icon indicating the image heading.

An image location can be selected by single mouse click action as long as the layer is visible. You can select images even if the OpenStreetCam layer is not the active layer.

OpenStreetCam layer displays data starting with zoom level 14, so in order to see the data you need to zoom in into the desired mapping area.

For Imagery layers the data is loaded as you move the map and zoom in/out. In the case of OSM data the OpenStreetCam layer data is loaded only for the downloaded area.

The plugin saves the open/closed state of the layer. So if you delete the layer then at the next JOSM session the OpenStreetCam layer will not be loaded by default. A previously deleted OpenStreetCam layer can be activated again from the Imagery menu.

OpenStreetCam panel
In the OpenStreetCam panel you can interact with the currently selected image.

The panel along with the image displays basic information such as: OSM username and date of creation.

The panel also has a number of action buttons on the bottom. These are for filtering, next/previous image loading, centering the map, opening image web page and giving feedback. Image related actions are enabled only when the image is showing in the panel.

These features will be discussed in the next sections.

The plugin saves the open/closed state of the panel. So if you delete the panel then at the next JOSM session the OpenStreetCam panel will not be opened by default. If you don’t see the panel you should be able to open it by selecting the OpenStreetCam icon from the left side panel.

Image filtering

The displayed data can be filtered based on the creation time and JOSM user. In order to view only your uploaded images, you need to authenticate in JOSM using OAuth login.

 

By default no filter is set, custom filters can be removed by clicking the Clear button.

Visualizing an image and corresponding track
Individual images can be visualized by clicking on the image icon displayed on the map. The corresponding image is loaded in the OpenStreetCam panel and the corresponding track is displayed on the map.

An OpenStreetCam track is illustrated with a blue directed line. Images belonging to the selected track are illustrated with opaque icons; while other images along the track are illustrated with transparent icons.

Image zoom in/out

The displayed image can be zoomed in and out using the mouse wheel. In an already zoomed in image details can be observed by moving the image left, right, up and down.

Next/Previous image

You can navigate between the previous and next image of a track either from the OpenStreetCam panel by clicking on the Next/Previous button or by pressing Alt-Left arrow/Alt-Right arrow.

If the next or previous image is not visible in the current view, the map is moved automatically and images near the track are downloaded.

Center map to selected image

The map can be re-centered to the selected image location by clicking on the “Location” button from the OpenStreetCam panel. This feature is useful when the map was moved and the selected image location is not visible on the map.

Image web page

The selected image web page can be opened by clicking on the “Globe” button from the OpenStreetCam panel.

Upcoming features

We are working on improving our JOSM plugin and plan to add new exciting features. In the near future we plan to:

  • improve image loading speed by adding caching mechanism
  • allow the user to select easily nearby images to an already selected image
  • improve the map view and suggest street view coverage by displaying OSM ways instead of individual images. We will implement something similar as in the case of the web and mobile applications.

Source code

The source code for the plugin can be found on GitHub .

 

Feedback

Ideas, suggestions and bug reports can be submitted either to the plugin’s GitHub issue page or to the Feedback forum. Other mapper’s idea can be voted there.

We take a look at all incoming ideas, so be sure your input is heard and very much appreciated!

 

Have fun adding missing map features using OpenStreetCam images.

Facebooktwittergoogle_plus