@Korina
Hi Korina,
I found out I used the insertion in a different way than what you did. After tapping + you get the marker sentence “select a location in the map”. I follow that saying literally, without tapping that sentence first, so I don’t get a red marker on the screen. If I do it the way WindyMaps expect me to do, it works perfectly. So now you probably can replicate what I did “wrong”.

Having said that, I find tapping the marker sentence a superfluous and therefore inefficient action. Why would you need it if the app can find out that by itself easily, it knows you want an insertion, so why a tap ‘n hold not enough?

By the way, I have/had some other route planners (among Garmin), but I’m switching to WindyMaps. I just would like to see the app becoming more efficient in some aspects (see my suggestions, in which the waypoint insertion does not make part yet), so that it becomes at least equal to or better than other route planner tools.

I would be really surprised, having seen the wonderful Windy app, that the Windy team wouldn’t be thinking of making it as efficient as possible... ;o). I’m switching to Windy because one can feel the tremendous drive behind it.

When I try to insert a waypoint via the route planning list (whee you can tap the green +), for example the addition of a new waypoint between waypoint 2 and 3, I get a new End waypoint (on iPad). The route gets messed up.

Yesterday, I was planning one hiking route after the other. At that point some small nuisances become gradually more accentuated and feel like inefficiencies.

1. First waypoint = user choice instead of the default = your location

When planning hikes or bike or road trips, WindyMaps assumes the current location is the starting position. When planning routes this is often not the case. Then the current location becomes a (small) nuisance. Certainly when you’re planning routes far away from your current location. You get a superfluous zoom out and zoom in.

May consider putting the option per type of transport (car, bike, feet).
In short:

route start option, start new route from:

• my location
• first waypoint setting

2. Less taps to define a route:
   The GoTo feels like a superfluous action when you don’t make use of predefined waypoints. Why not assume that each tap ‘n hold is a new waypoint? Now you need one tap ‘n hold + GoTo tap. It’s a larger nuisance then the one mentioned above. When afterwards you consider a waypoint to be wrong, you can always delete it.

The nearest hospital also includes hospitals with a special purpose. They won’t help, and will send you to a general hospital.

The route weather & time option is really very interesting when hiking in mountains, especially when weather or corporal conditions start to play a role in considering what to do next: return, continue, rest, or hopefully not the need to call for help.

Here are some suggestions to improve this interesting feature.

• I suggest to put a weather toggle icon on top of the navigation list instead of the switch with (imho superfluous) explanation. It’s faster, and self explaining when you hit the icon.

• An extra toggle icon, let’s call it for now waypoint info, to display the same info, next to height on waypoint level. Height is sometimes difficult to derive from contour lines. The first icon remains interesting though when there are few waypoints.

• Maybe join both icons into one. Tap once for route weather & time, tap once again for route waypoint weather & time & height, tap once again to put it off.

• Consider to let the user adjust the gap between route weather points for example every 500 m in distance or every 100 m in height.

• Consider to add a “tap a waypoint on the map to get more info”. In fact the same brief data, as above (including height of course :) ), but only for the tapped waypoint. Tap again and the info disappears.

• Please add height to what I call info waypoints, showing now the weather forecast next to gps info. I suggest to display the same data as the route weather, next to height of course next o the info waypoint.

• Finally, I support an earlier suggestion to add current height (maybe as an option) somewhere at the bottom or on top of the screen.