Style OSM turn restrictions better

[planemad]

Showing existing OSM turn restrictions on the map help to easily compare with Mapillary restrictions and add/update the data onto the map.

Current styling of OSM turn restriction from via and to members in red

@rasagy can you review the issues with this styling from a reviewer perspective and post your notes on how it should ideally look?

cc @andreasviglakis

[rasagy]

Summarising the insights from the design sprint that I will try to take forward:

• Splitting of tasks across mappers/reviewers, as being discussed in #47.
• Highlighting which areas are potentially unmapped, similar to what is being discussed in #55.
• Using verified orbs smartly — marking all photos of the detected signage to avoid confusion.
• Catering for red-green blindness

The proposed design that we can explore further, since data-driven styling is now available for icon-rotate:

Specific feature requests in this design: (Will sync up with @ajithranka & @planemad on what to prioritise)

• Update color palette and stroke details to differentiate from, via, to and highlight no vs only ways.
• Show TR as icons close to the via node that have been added already on OSM.

To do on this design:

• [x] Add the Mapillary layer (photos, estimated signage location) and style that.
• [ ] Explore interactivity & states for the verified/unverified signages.
• [x] Work with the Mapillary sprite shared in #38 instead of custom iconset.
• [ ] Design the filter & image thumbnail UI.

You can play around with this map style here.

[rasagy]

I spent some time with @srividyacb in observing how she is mapping/verifying Turn Restrictions. Key insights:

• More time is spent on JOSM, with OSM Nav map currently just used to jump quickly to next possible TR.
• A lot of time is spent loading images, finding signages and reading road signs. Even a minor improvement in this flow will multiply into a good amount of time saved.
• Just visually showing mapped TR as icons isn’t enough, since there have been cases of incomplete/broken TR on OSM.
• Street names are valuable to maintain context when switching apps, and should be focused on in the design.

I’ll be looking back at this again with fresh eyes to explore what can be the actionable steps from the observation.

Here are the details that I noticed during the shadow exercise:

1. Sri finds a cluster of detected signages on the OSM Nav map, and checks the image thumbnail on one of them.
2. Most often, the image in Nav map is opened in a new tab (by clicking on it) to quickly zoom into one part (verify TR is visible, and spot road name signage if possible), then JOSM is opened.
3. On opening JOSM, she sometimes toggles to the OSM view (instead of satellite view) to confirm if she is on the correct junction (by verifying street names)
4. She uses the Mapillary picture plugin and hovers on the photo locations to guess if the photo will have the TR & street info based on the thumbnail.
5. She opens images (and switches next/back) to confirm which restrictions are where — changing (loading) images here takes a lot of time, and there is quite a bit of back and forth to find legible street names.
6. The Mapillary pictures plugin tends to cover the map, so she sometimes drags the map around to keep a track of where the photo is taken on the map.
7. The icons in JOSM generally help in quickly noticing if a TR is mapped. However, sometimes icons get overlapped (like No-U-Turn & No-Left-Turn on same street), so this isn’t always reliable.
8. Even if the relation is already mapped (as above), she still double checks the relation details to confirm if the from, via, to are mapped correctly. She edits the relation and clicks on each member to see it visually highlighted (red blur) on the map.
9. If the TR is not mapped, she adds them on JOSM.
10. Sometimes, the TR is correctly detected but is for a one-way street (these are marked redundant).
11. She removes the layers (for Mapillary, OSM etc.) from JOSM before continuing.
12. She switches back to the browser, closes the image tab that was opened.
13. She marks the particular node/photo as valid/redundant/invalid on Nav map. She doesn’t do that for every node that detects a signage, only the one that was the most clear (at times multiple).

[planemad]

Some prior art: http://restrictions.morbz.de/# which helps visualize OSM turn restriction. Its not very clear which are the from and to members at junctions with multiple restrictions.

[rasagy]

Based on voice w/ @planemad & @ajithranka.

We need to style the following restrictions visually to implement the original style, however the properties in bold aren’t available for data-driven gl-js:

way

• from: line-color, line-width, line-gap-width
• to (no_restriction): line-color, line-width, line-dasharray
• to (only_restriction): line-color, line-width, line-dasharray
• via: line-color, line-width, line-dasharray

node

• via: circle-color, circle-opacity

For now, we’ll use two layers for way (one layer for from and one layer for to_no, to_only and via — differentiated by color) and one for node

Design tasks that I’ll be looking at today:

• [x] Adapt the old design for restrictions with gl-js constraints
• [ ] Rethink the colors for the whole map (colors for valid + mapillary + restrictions)
• [x] Style mapillary icons better (relevant ticket here).

[rasagy]

Updated the style to a simpler one which has the same properties for all to & via ways as discussed above:

However, @ajithranka felt that we can retain individual layers for each case, so we’re sticking to the older style (with a few tweaks).

[planemad]

@rasagy we now have turn restrictions loaded dynamically after z14. The style is not really legible against the dark background.

Spot the OSM restrictions

cc @ajithranka

[rasagy]

@planemad Agreed, synced up with @ajithranka on the same. I’ll be reworking the style since I was using Mapbox Light as a base map & this map is a mix of dark + satellite view. Also need to sync up on prioritising some features, will put down my ideas and then chat further on this.

[planemad]

👍 on using light

[rasagy]

Based on the discussions, these were the action points:

• [x] Style the restrictions with a darker base layer in mind.
• [x] Make Mapillary icons brighter and more visible.
• [x] Reduce emphasis on Mapillary trails at high zooms.
• [ ] Hide restriction description till Mapillary object is clicked.
• [x] Allow overlapping restrictions to not get hidden.
• [ ] Change styles for the validation panel & orbs on map.

[rasagy]

Based on discussion with @bsrinivasa, hiding the old TR style on zoom>14, and for zoom<14 showing only the via node styled in the new color scheme so we still get an overview.

• [x] @rasagy to update base map style
• [ ] @ajithranka to hide the TR nodes coming from overpass on zoom<14

PS: Once the new styles are pushed, we’ll share a documentation of the style with the team and add it to the wiki for the tool.

[rasagy]

Hi @mapbox/india-office,

We’ve been working on updating the osm-navigation-map style to reduce the clutter & noise.

Specifically:

• Reducing the Mapillary trails when zoomed in
• Showing the turn restrictions differently for only and no restrictions
• Showing the Mapillary estimated positions, photos detecting signage and other photos in a better way.

Here’s how the new design is looking:

Overview:

Zoomed in view:

No left turn (from: yellow, via: red node, to: thin dashed red)

Only right turn (from: yellow, via: blue node, to: dashed blue)

Would love to hear if this is working or not, and what is hindering our workflow on this map. :)

[planemad]

@rasagy loving this, definitely makes it visually simpler.

• A big help will be a small graphic legend to help interpret turn restriction representation. Since it is new, the colors and symbology are not really intuitive for a mapper (This could be on the readme for now)
• Did not notice the dashes in the blue, seems to have a smaller gap spacing than the red

[rasagy]

@planemad Thanks!

A big help will be a small graphic legend to help interpret turn restriction representation. Since it is new, the colors and symbology are not really intuitive for a mapper (This could be on the readme for now)

Makes sense. If there are no other changes by tomorrow, then I’ll update the instructions.

Did not notice the dashes in the blue, seems to have a smaller gap spacing than the red

The idea was that the red way is something you can not drive to, so it is dashed, however the blue way is something you can only drive to, so it has minor gap. I was hoping to keep all three way line styles different (not just color), hence this approach. If this is more confusing than helpful, then I can see if increasing the gap or removing gap altogether helps.

[rasagy]

@bsrinivasa pointed out how at high zoom levels, the validation orbs clash with the via nodes (red & blue). Updated the map so the via nodes are enlarged only after z12. Thanks Bharata!