biodranik commented

(Migrated from github.com)

Currently, only the distance until the next turn or exit is displayed in navigation mode.

👍 20

jm355 commented

2021-07-13 03:11:30 +00:00

(Migrated from github.com)

That and showing the exit number for the highway would be a huge improvement

👍 14

AverageHelper commented

2021-08-10 23:02:53 +00:00

(Migrated from github.com)

Agreed. I've missed or nearly missed or thought I'd missed several turns when I couldn't calibrate to the name of the road I'm turning onto. Distance is nice, but I also need to know the name so I can spot the road irl.

Are street names collected with turn points when the route is generated? If that information is readily available, it shouldn't be difficult to extend the turn info area, and possibly move the current-road label to the bottom.

EDIT: This appears to be the case. If I'm reading NavigationController.java correctly, the distance info comes from a RoutingInfo object, which seems to have a nextStreet property that is meant to contain "the next street name."

Whether that object actually contains the next street name I don't know yet. If it does... the hardest part of this change should be the UI hooks.

Agreed. I've missed or nearly missed or thought I'd missed several turns when I couldn't calibrate to the name of the road I'm turning onto. Distance is nice, but I also need to know the name so I can spot the road irl. Are street names collected with turn points when the route is generated? If that information is readily available, it shouldn't be difficult to extend the turn info area, and possibly move the current-road label to the bottom. EDIT: This appears to be the case. If I'm reading [NavigationController.java](https://github.com/organicmaps/organicmaps/blob/9c33fa2de7f785cb12097fca6da6aae8816a2381/android/src/com/mapswithme/maps/routing/NavigationController.java#L243) correctly, the distance info comes from a `RoutingInfo` object, [which seems to have a `nextStreet` property](https://github.com/organicmaps/organicmaps/blob/9c33fa2de7f785cb12097fca6da6aae8816a2381/android/src/com/mapswithme/maps/routing/RoutingInfo.java#L23) that is meant to contain "the next street name." Whether that object actually contains the next street name I don't know yet. If it does... the hardest part of this change should be the UI hooks.

❤️ 4

AverageHelper commented

2021-08-10 23:15:12 +00:00

(Migrated from github.com)

I suppose a change like this would need to be tested on both Android and iOS, which might make things difficult.

zyphlar commented

2021-11-14 06:35:35 +00:00

Member

I just did a deep dive on debugging why navigating highways is so awful for me with OSM (OrganicMaps and OsmAnd), and it turns out that it boils down to this. The data is in OSM to render real-world-accurate exit signage and even lane destination/turn signage, but OsmAnd's UI is obtuse as always and OrganicMaps basically ignores it in favor of "feet until turn."

In America at least, the exit number (junction ref) comes first, and usually the destination name is the next most critical piece of info. Destination ref or street is often "would be nice."

OsmAnd makes the mistake of making destination ref/street one of the most prominent things you see, hiding the exit number in a blue box in the corner. (Exit signs are not blue in America, "would be nice" info signs are, so it just becomes more visual clutter.)

Ironically MapFactor otherwise has awful UX but they display all the info in a big exit style sign. Google emulates the green exit signs and highway shield iconography as well as highlighting the junction point with the exit number repeated.

Each country has different hierarchies and iconography so I think it would be amazing if in America we got a green overlay saying:

Exit 123 ↗️

🛡️ I-10 🛡️ Route 66

DestinationName

and appropriate localized versions for other regions. Drivers have maybe a tenth of a second to match the phone screen with the road sign, the closer the visuals are the better. Bigger routes like interstates are more important and recognizable than the smaller local routes that may overlap them.

What I absolutely can't deal with in the middle of a major interchange is reading non-highlighted 10 point font on the moving map to see the exit number (I actually didn't realize OrganicMaps rendered exit numbers until I was preparing this issue and stared and squinted for many minutes) or OsmAnd's "more text means better" version:

`123` (HWY 202) » RO 66, I 10 ...

I just did a deep dive on debugging why navigating highways is so awful for me with OSM (OrganicMaps and OsmAnd), and it turns out that it boils down to this. The data is in OSM to render real-world-accurate exit signage and even lane destination/turn signage, but OsmAnd's UI is obtuse as always and OrganicMaps basically ignores it in favor of "feet until turn." In America at least, the exit number (junction ref) comes first, and usually the destination name is the next most critical piece of info. Destination ref or street is often "would be nice." OsmAnd makes the mistake of making destination ref/street one of the most prominent things you see, hiding the exit number in a blue box in the corner. (Exit signs are not blue in America, "would be nice" info signs are, so it just becomes more visual clutter.) Ironically MapFactor otherwise has awful UX but they display all the info in a big exit style sign. Google emulates the green exit signs and highway shield iconography as well as highlighting the junction point with the exit number repeated. Each country has different hierarchies and iconography so I think it would be amazing if in America we got a green overlay saying: **Exit 123** ↗️ ### 🛡️ I-10 🛡️ Route 66 # DestinationName and appropriate localized versions for other regions. Drivers have maybe a tenth of a second to match the phone screen with the road sign, the closer the visuals are the better. Bigger routes like interstates are more important and recognizable than the smaller local routes that may overlap them. What I absolutely can't deal with in the middle of a major interchange is reading non-highlighted 10 point font on the moving map to see the exit number (I actually didn't realize OrganicMaps rendered exit numbers until I was preparing this issue and stared and squinted for many minutes) or OsmAnd's "more text means better" version: #### ` 123 ` (*HWY 202*) » RO 66, I 10 ...

❤️ 7

biodranik commented

2021-11-14 13:37:55 +00:00

(Migrated from github.com)

Thanks for the details! You're right, using as close iconography as possible is the best way. Is Google the winner now in it?

Are there any reliable sources of all icons for all or most countries? Ideally in a vector format.

Thanks for the details! You're right, using as close iconography as possible is the best way. Is Google the winner now in it? Are there any reliable sources of all icons for all or most countries? Ideally in a vector format.

zyphlar commented

2021-11-15 19:19:45 +00:00

Member

@biodranik I know @1ec5 has been doing a ton of good work in this area and is also heavily involved in American OSM UI projects: https://github.com/1ec5/rebusurance

Even MapFactor has very poor UI but wins in this category by simply prioritizing the destination name over the destination roads. A first version of this feature could simply use nicely formatted text.

As @1ec5 says in one of his blogs, a big hurdle is knowing which graphic goes with what ref, because simple regex can be insufficient. ("State Route 66" means what, at the border between two states?). Google does do a "standard" job of this and just uses white ovals/lozenge shapes for state highways (which is a federal standard, just a standard no states use) and that is also obviously more than sufficient as a first step.

@biodranik I know @1ec5 has been doing a ton of good work in this area and is also heavily involved in American OSM UI projects: https://github.com/1ec5/rebusurance Even MapFactor has very poor UI but wins in this category by simply prioritizing the destination name over the destination roads. A first version of this feature could simply use nicely formatted text. As @1ec5 says in one of his blogs, a big hurdle is knowing which graphic goes with what ref, because simple regex can be insufficient. ("State Route 66" means what, at the border between two states?). Google does do a "standard" job of this and just uses white ovals/lozenge shapes for state highways (which is a federal standard, just a standard no states use) and that is also obviously more than sufficient as a first step.

biodranik commented

2021-11-15 22:09:57 +00:00

(Migrated from github.com)

It would be a great help and can speed up the development if someone helps us by providing some example routes (with exits) in GPX format that have all necessary OSM tags. Ideally also in Europe, so we can change the code and then quickly test/debug if it works in a simulator.

It would be a great help and can speed up the development if someone helps us by providing some example routes (with exits) in [GPX format](https://medium.com/swlh/simulating-dynamic-locations-with-xcode-c72ccfacef9e) that have all necessary OSM tags. Ideally also in Europe, so we can change the code and then quickly test/debug if it works in a simulator.

zyphlar commented

2021-11-16 19:24:24 +00:00

Member

@biodranik what do you consider to be "all necessary OSM tags?" at first I thought all of my area was lacking tagging, but it turns out that all mobile apps available to me either ignore turn:lanes or they ignore destination names near a motorway_junction or both -- which is to say that most major routes should have both, though I'm happy to double check and provide test cases for you. (Aside from a GPX track, what format should the test conditions be documented in? Screenshots, recordings, text descriptions..?)

@biodranik what do you consider to be "all necessary OSM tags?" at first I thought all of my area was lacking tagging, but it turns out that all mobile apps available to me either ignore `turn:lanes` or they ignore `destination` names near a `motorway_junction` or both -- which is to say that most major routes should have both, though I'm happy to double check and provide test cases for you. (Aside from a GPX track, what format should the test conditions be documented in? Screenshots, recordings, text descriptions..?)

biodranik commented

2021-11-16 20:53:56 +00:00

(Migrated from github.com)

For each example a GPX track, start + end coordinates, and expected "the best possible" texts (and other signs) you want to see on the screen (extracted from existing OSM tags, of course) would be enough.

zyphlar commented

2021-11-16 21:36:36 +00:00

Member

OK gotcha

suhridkhan commented

2021-12-30 18:00:08 +00:00

(Migrated from github.com)

Does it make sense to make the next turn/exit information always visible? It only shows up when the turn is pretty close, which is not often very useful. Specially driving on a highway, it will be useful to be able to see the next turn/exit information about a km ahead on highways.

👍 3

AverageHelper commented

2021-12-30 19:08:23 +00:00

(Migrated from github.com)

@suhridkhan I agree. If having that info always visible begins to clutter the UI, we may instead consider hiding that info until about 10mi/15km close.

suhridkhan commented

2021-12-31 06:21:18 +00:00

(Migrated from github.com)

@suhridkhan I agree. If having that info always visible begins to clutter the UI, we may instead consider hiding that info until about 10mi/15km close.

Agreed, on autohide until becoming relevant. The ideal information to display would be the next turn/exit info and how far that is. To keep the screen less cluttered, in horizontal mode the info can be on top portion as is now, and for landscape mode, the info can be on the left/right side.

> @suhridkhan I agree. If having that info always visible begins to clutter the UI, we may instead consider hiding that info until about 10mi/15km close. Agreed, on autohide until becoming relevant. The ideal information to display would be the next turn/exit info and how far that is. To keep the screen less cluttered, in horizontal mode the info can be on top portion as is now, and for landscape mode, the info can be on the left/right side.

zyphlar commented

2021-12-31 08:09:17 +00:00

Member

@biodranik it only took a month for me to compile the GPX and screenshots into a usable format! Here you go. It's a slideshow with street imagery, OsmAnd screenshots, and ideal US-english voice guidance written out phonetically (eye ten instead of I-10). As you can see OsmAnd does a pretty okay job, but the GUI is so dense and cluttered (and, maybe, the OSM data isn't very clean) that it can very easily have you confused. (I left out plenty of intermediary screenshots where the destination text would flip between helpful and unhelpful within a few hundred feet, but I left enough in that you can probably see for yourself.)

The ideal visual indication would match the street signage almost exactly, although I've written the voice guidance in order of importance so "take exit 153A" is most critical, followed by "for I-10", followed by "towards Phoenix" depending on how much space you have.

I've turned on commenting so if there are questions about a specific slide feel free to use the Google comment feature, I should be notified.

https://drive.google.com/folderview?id=1eYv2NCZw-WboMFzwGb01qVrVw2weNw87

@biodranik it only took a month for me to compile the GPX and screenshots into a usable format! Here you go. It's a slideshow with street imagery, OsmAnd screenshots, and ideal US-english voice guidance written out phonetically (eye ten instead of I-10). As you can see OsmAnd does a pretty okay job, but the GUI is so dense and cluttered (and, maybe, the OSM data isn't very clean) that it can very easily have you confused. (I left out plenty of intermediary screenshots where the destination text would flip between helpful and unhelpful within a few hundred feet, but I left enough in that you can probably see for yourself.) The ideal visual indication would match the street signage almost exactly, although I've written the voice guidance in order of importance so "take exit 153A" is most critical, followed by "for I-10", followed by "towards Phoenix" depending on how much space you have. I've turned on commenting so if there are questions about a specific slide feel free to use the Google comment feature, I should be notified. https://drive.google.com/folderview?id=1eYv2NCZw-WboMFzwGb01qVrVw2weNw87

❤️ 1

biodranik commented

2021-12-31 08:13:47 +00:00

(Migrated from github.com)

Wow, awesome, thanks! You did a lot of work. It may really help in designing something better. OSMand's UI is so bad, that I can't even find a polite word to describe it )

😆 1 🚀 2

zyphlar commented

2021-12-31 08:36:08 +00:00

Member

@suhridkhan @AverageHelper I find it most useful to know in how many miles I'll have to make a major turn or exit (and not just the "oopsie the road split a little bit so let's announce it" silliness OsmAnd does) and then have the info displayed more completely when it's within a reasonable distance. Maybe something like "Exit 143, 50 miles" is enough for a road trip and then "Exit 143, 750 feet, for I-10, towards Phoenix" is the full expanded version.

👍 4

AntonM030481 commented

2022-05-25 11:04:38 +00:00

(Migrated from github.com)

@biodranik @vng
Do we have any progress for this task?

AFAIK we read only "name" and "ref" tags for roads now.

For navigation display we use "name" only.
FeatureType::GetName() => LoadedPathSegment.m_name => ... => FollowingInfo.m_targetName => FollowingInfo.m_displayedStreetName

Current logic is like this:
After junction we go forward through segments to find fist named one (but this is limited to 400m).
If such segment will be found - it's name will appear in navigation.

Usually links have no "name" tag, so their segments are considered unnamed.

This works nice in the city, when road are named and links are unnamed and short.
Display name of next road after link is OK.

But for out of city, if link is long or next road has no name (e.g. ref only) - nothing will be shown in navigation.
BTW currently we show name of next road (if any) only during last 500m before junction.

Hotfix is:

Use "ref" tags in navigation (in addition to "name")
Increase 400m limit for looking forward for named/tagged road.

Full solution involves reading for links following tags:
"junction:ref", "destination:ref", "destination".

@biodranik @vng Do we have any progress for this task? AFAIK we read only "name" and "ref" tags for roads now. For navigation display we use "name" only. `FeatureType::GetName() => LoadedPathSegment.m_name => ... => FollowingInfo.m_targetName => FollowingInfo.m_displayedStreetName` Current logic is like this: After junction we go forward through segments to find fist named one (but this is limited to 400m). If such segment will be found - it's name will appear in navigation. Usually links have no "name" tag, so their segments are considered unnamed. This works nice in the city, when road are named and links are unnamed and short. Display name of next road after link is OK. But for out of city, if link is long or next road has no name (e.g. ref only) - nothing will be shown in navigation. BTW currently we show name of next road (if any) only during last 500m before junction. Hotfix is: - Use "ref" tags in navigation (in addition to "name") - Increase 400m limit for looking forward for named/tagged road. Full solution involves reading for links following tags: "junction:ref", "destination:ref", "destination".

dead10ck commented

2022-05-25 12:03:37 +00:00

(Migrated from github.com)

I agree ideally a full solution is to make use of all of those tags, although in my experience, destination and destination:ref are the most immediately useful, as they show what is "on the exit sign", which can sometimes not be the same as the ref on the road that the junction leads to.

These used together with the ref of the junction are the ideal in most cases I've seen. The exit number, destination freeway ref, and the city displayed on the sign, are the 3 that most often exactly match what to look for on the road. e.g. "exit 2e, 787 North, Troy"

I agree ideally a full solution is to make use of all of those tags, although in my experience, `destination` and `destination:ref` are the most immediately useful, as they show what is "on the exit sign", which can sometimes not be the same as the ref on the road that the junction leads to. These used together with the ref of the junction are the ideal in most cases I've seen. The exit number, destination freeway ref, and the city displayed on the sign, are the 3 that most often exactly match what to look for on the road. e.g. "exit 2e, 787 North, Troy"

👍 3

AntonM030481 commented

2022-05-25 12:42:07 +00:00

(Migrated from github.com)

Guys from Apple agree with such approach.
This is the turn from the picture.
(here this is not link highway=motorway and it has it's own ref="CA 85").

Icon for destination:ref (here "South" - second part of destination:ref="CA 85 South")
Big destination.
optional junction:ref

Guys from Apple agree with such approach. [This](https://www.openstreetmap.org/way/8924268) is the turn from the picture. (here this is not link `highway=motorway` and it has it's own `ref="CA 85"`). - Icon for `destination:ref` (here "South" - second part of `destination:ref="CA 85 South"`) - Big `destination`. - optional `junction:ref` ![](https://www.apple.com/newsroom/images/product/apple-maps/Apple_Apple-Maps_Navigation_09272021_inline.jpg.large.jpg)

👍 1

AntonM030481 commented

2022-06-21 14:21:33 +00:00

(Migrated from github.com)

Reference from Waze

Reference from Waze ![image](https://user-images.githubusercontent.com/85622715/174822545-8d397cea-9a5e-4b8b-9354-4bb7a79894c6.png)

AntonM030481 commented

2022-06-22 15:15:01 +00:00

(Migrated from github.com)

Waze is a good reference

Information is displayed with automatic wrapping to the next line

Previously they tried to use full phrases before and stopped it.

Now they use minimalistic approach:
Full case: Exit number E1, Road Number R1, Road_Name, Destination1 and Destination1 are present.

Exit E1: R1 - Road_Name > Destination1 / Destination2.

Short versions:

Exit E1
Exit E1: R1 - Road_Name.
Exit E1 > Destination1 / Destination2.
to Destination1 / Destination2.
R1 - Road_Name
R1 - Road_Name > Destination1 / Destination2.

In some locations/versions they use local graphic (instead of text) road/exit shields

Current implementation in OM

Usage of [ ] was inspired by typical road/exit shields.

[E1]: [R1] Road_Name > Destination1; Destination2.

Short versions:

[E1]
[E1]: [R1] Road_Name.
[E1] > Destination1; Destination2.
> Destination1; Destination2.
[R1] Road_Name
[R1] Road_Name > Destination1; Destination2.

### Waze is a good reference Information is displayed with automatic wrapping to the next line Previously they tried to use full phrases before and stopped it. Now they use minimalistic approach: Full case: Exit number E1, Road Number R1, Road_Name, Destination1 and Destination1 are present. ``` Exit E1: R1 - Road_Name > Destination1 / Destination2. ``` Short versions: ``` Exit E1 Exit E1: R1 - Road_Name. Exit E1 > Destination1 / Destination2. to Destination1 / Destination2. R1 - Road_Name R1 - Road_Name > Destination1 / Destination2. ``` In some locations/versions they use local graphic (instead of text) road/exit shields ### Current implementation in OM Usage of [ ] was inspired by typical road/exit shields. ``` [E1]: [R1] Road_Name > Destination1; Destination2. ``` Short versions: ``` [E1] [E1]: [R1] Road_Name. [E1] > Destination1; Destination2. > Destination1; Destination2. [R1] Road_Name [R1] Road_Name > Destination1; Destination2. ```

AverageHelper commented

2022-06-22 15:46:58 +00:00

(Migrated from github.com)

Oh good, I see Waze has updated since last I used it. Those exit descriptions then were a pain to read on the road.

I'd prefer the exit number to be a bit more separated, since I'm not yet accustomed to parsing out the Exit E1: R1 syntax quickly, rather like what Apple Maps does in the screenshot above.

One step at a time though, I guess. I'd happily use OM if it approached Google Maps' usability on the road, even if the UI looked and worked like Waze does now.

Oh good, I see Waze has updated since last I used it. Those exit descriptions then were a pain to read on the road. I'd prefer the exit number to be a bit more separated, since I'm not yet accustomed to parsing out the `Exit E1: R1` syntax quickly, rather like what Apple Maps does in the screenshot above. One step at a time though, I guess. I'd happily use OM if it approached Google Maps' usability on the road, even if the UI looked and worked like Waze does now.

pm4rcin commented

2022-07-04 19:33:10 +00:00

(Migrated from github.com)

Guys from Apple agree with such approach. This is the turn from the picture. (here this is not link highway=motorway and it has it's own ref="CA 85").

* Icon for `destination:ref` (here "South" - second part of `destination:ref="CA 85 South"`)

* Big `destination`.

* optional `junction:ref`
  ![](https://camo.githubusercontent.com/152ea38909df30f14e3209cfd0c5c11197d676b8265e809eebe300e52aaaf70e/68747470733a2f2f7777772e6170706c652e636f6d2f6e657773726f6f6d2f696d616765732f70726f647563742f6170706c652d6d6170732f4170706c655f4170706c652d4d6170735f4e617669676174696f6e5f30393237323032315f696e6c696e652e6a70672e6c617267652e6a7067)

Wow! that rendering of bridges and lanes in 3D is mind-blowing but I guess it requires a lot of work.

> Guys from Apple agree with such approach. [This](https://www.openstreetmap.org/way/8924268) is the turn from the picture. (here this is not link `highway=motorway` and it has it's own `ref="CA 85"`). > > * Icon for `destination:ref` (here "South" - second part of `destination:ref="CA 85 South"`) > > * Big `destination`. > > * optional `junction:ref` > ![](https://camo.githubusercontent.com/152ea38909df30f14e3209cfd0c5c11197d676b8265e809eebe300e52aaaf70e/68747470733a2f2f7777772e6170706c652e636f6d2f6e657773726f6f6d2f696d616765732f70726f647563742f6170706c652d6d6170732f4170706c655f4170706c652d4d6170735f4e617669676174696f6e5f30393237323032315f696e6c696e652e6a70672e6c617267652e6a7067) Wow! that rendering of bridges and lanes in 3D is mind-blowing but I guess it requires a lot of work.

zyphlar commented

2022-08-08 23:02:28 +00:00

Member

I noticed a "bug" which prevents highway=motorway_junction nodes from displaying their exit number in our latest OrganicMaps despite having a ref -- it appears that exit numbers are only displayed if we are turning onto a new way with a junction:ref (usually the same as the junction node's ref.)

I've edited my area to add junction:ref tags to exit ways, but is it possible/desirable to show the junction node ref as a fallback? I wonder how many exits only have node tags without associated way tags, coverage could be slim...

I noticed a "bug" which prevents `highway=motorway_junction` nodes from displaying their exit number in our latest OrganicMaps despite having a `ref` -- it appears that exit numbers are only displayed if we are turning onto a new way with a `junction:ref` (usually the same as the junction node's `ref`.) I've edited my area to add `junction:ref` tags to exit ways, but is it possible/desirable to show the junction node `ref` as a fallback? I wonder how many exits only have node tags without associated way tags, coverage could be slim...

👍 1

1ec5 commented

2022-08-09 01:32:01 +00:00

(Migrated from github.com)

Mapbox’s implementation of this for OSRM rewrote the junction nodes’ ref tags onto the link ways as junction:ref (and I think Valhalla does something similar). Project-OSRM/osrm-backend#4467 tracks doing the same for numbered intersections.

Mapbox’s implementation of this for OSRM [rewrote](https://github.com/mapbox/osrm-tag-rewriter/) the junction nodes’ `ref` tags onto the link ways as `junction:ref` (and I think Valhalla does something similar). Project-OSRM/osrm-backend#4467 tracks doing the same for numbered intersections.

👍 1

vng commented

2022-08-09 03:56:16 +00:00

(Migrated from github.com)

Routing index knows nothing about motorway_junction nodes, it works with ways. Yes, seems like we should make the same trick as OSRM or Valhalla.
organicmaps/organicmaps#3134

Routing index knows nothing about motorway_junction nodes, it works with ways. Yes, seems like we should make the same trick as OSRM or Valhalla. https://git.omaps.dev/organicmaps/organicmaps/issues/3134

👍 2

Rows
Columns

Navigation: show the street/road/exit name for the next turn #849

🛡️ I-10 🛡️ Route 66

DestinationName

123 (HWY 202) » RO 66, I 10 ...

Waze is a good reference

Current implementation in OM

`123` (HWY 202) » RO 66, I 10 ...