For reference see:
I would start this very simple by allow setting 2 types on waypoints in the app:
- Stopover points (visible in instructions / navigation) – current implementation
- Shaping points (invisible in instructions / navigation)
More advanced properties, colors, etc. will be examined in future in separate topics.
Garmin uses the “shaping point” term and we can use it for the UI texts:
- Garmin BaseCamp: Shaping points are any position along a route that will not alert you when you arrive. Shaping points do not contain arrival time or distance between points information.
stopover(optional) indicates whether this waypoint is a actual stop on the route (
true) or instead only a preference to route through the indicated location (
false). Stopovers are
- HERE Maps: A waypoint can be either a StopOver (for example, start or destination) or a PassThrough. A valid CalculateRoute request must include at least two StopOver waypoints.
One thing I want to mention that we should avoid in my opinion. Google Maps makes you CONFIRM a stopover on the screen. That is terrible UX in my opinion, because it distracts you from driving and actively interrupts your navigation if - for any reason - you decide to not stop at that point and drive on
Stopover or shaping points are intended for UI use in route planning.
Navigation (like the turn instructions) can use only the stopover points.
So its workflow does not change, just the types of waypoints it parses.
All good. Just wanted to make sure to mention it
See HERE WeGo, it has an intuitive implementation of waypoint types (vs Google Maps):
Absolutely. In HERE WeGo you’re using different waypoints types (shaping point and waypoints to be visited) without even thinking too much about it. Google Maps offers a similar function but the usability is a little bit weird.
Google Maps uses the same symbol for both waypoint types, which is confusing.
Also interesting is how the waypoint types are handled in GPX import and export.
Yes, and it seems that you can’t convert a shaping point directly into a visit/stopover point because then this waypoint is suddenly your final destination point. Not very intuitive or logical.
They both provide a simple and intuitive approach, that most users expect.
I could see waypoint type conversions afterwards, as a more exotic feature.
Let’s start with the basics, include stopover / shaping points in all functions.
A teaser for new things to come?
It’s about waypoint types (shaping dots) – not waypoint names.
You will be able to also switch waypoint types [stopover vs shaping] in next (beta) release.
Waypoint type changes can be done via their long press menu and in waypoints list (like their names).
Looks great. I’m really looking forwards to test the new features (didn’t appear in my app updates yet) .
One question prior to my first tests: will the options of the rerouting mode distinguish between regular waypoints and shaping points?
I mean: will the option “next unvisited waypoint” automatically omit shaping points and focus only on the next regular waypoint in the route?
If so: will there be an additional rerouting option considering both types (something like “next unvisited way- or shaping-point”)?
And of course: by introducing shaping points you created a new challenge for the Kurviger website to support a corresponding feature (with an appropriate integration into the app) .