The title says it all. When the user gets warned on startup that updates are available, an estimate for the download size would be valuable information.

This seems a standard feature in almost all apps, so we should also support this.

On Android 11, you have to explicitly ask for permissions to receive position information when the app is not on top. If we do not do that, the user needs to go to some complicated "android settings" page -- few users will do that.

A very selfish suggestion, but if Enroute could read the GPS data broadcast by Xplane it would be the perfect companion moving map.

Thank you for this great app.

My display on android Huawei 10 mobile phone is too small. I can't see the whole content.
Enclose I sent you a file with the view I have.
Maybe you can adapt the view?

See attached screenshot.

Great work with the App so far!

I'd like to see traffic beeing displayed from a source, such as Stratux.
The team ofthe Stratux Europe Edition, is doing an awsome job, gaining the information via ADS-B and Flarm, to provide it to a Map App, like enroute.
As Straux is also Open Source, I'd prefere this over any other commercial solution.

There exist circumstances where the basemap is not drawn, even if it is installed. This seems to happen when the device has a connection to the network, but when no data is delivered from the internet.
I believe this issue happens because the MapBox style file still contains references to the outside internet. These should be deleted.

It's not very practical that the display goes to the OFF Mode after some time and the Handy has to be unlocked via code or fingerprint.
My proposal for improvement : whenever the Handy is connected to external power (…… is loaded) , the display is in Always ON mode. Goggle Maps has the same function when navigating

In version 1.0.3, the app generally renders the map twice on startup, which makes it less responsive and also uses battery. This issue goes away when "Flight Mode" is set on the device, so the issue is presumely related to the downloading of the "maps.json" file.

LFZ und Wind:

(1) die Eingabe der unteren Werte ist tlw. mühsam, da sich die Anzeige nur um eine Zeile hochschieben lässt. Man muss also (zumindest auf meinem Handy) die Tastatur ausblenden, das nächste Feld antippen, schreiben, die Tastatur wieder ausblenden ...

Hi,

the altitude seems to be systematically wrong, compare for example with the known altitude of your current location or other apps like gps status. For my home location the offset is about 45 m which corresponds to the geoid correction.
Do we need to apply a geoid correction?

In principle, the app should suggest map updates on startup. I am unsure if that ever happens. The current code is too complicated. Recommended simplification:

• Check for new "maps.json" after seven days of last download, but only on startup (perhaps with a little lag to improve perceived performance) and not while the app is running.

• Recommend map updates on startup (if not already in flight mode).

When updating maps via the "map update dialog", the user receives no feedback that the update actually takes place. An Android Notification could solve this issue.

… title says it all

… this should help with testing.

Hello everyone,

I plan to start implementing a new feature allowing to get METAR and TAF weather data.
Here is a description of the proposed implementation. Note that I am not familiar with the code, so the implementation I describe here might change as I code. I look forward to reading your comments or suggestions, should you have any.

QML
An entry "Weather" will be added to the drawer. On click, it will open a new Weather page with:

• a scrolling list showing the different aerodromes
• a search bar allowing to filter the aerodromes by name or ICAO code

All in all, this page should look similar to the FlightRouteAddWPDialog dialog.
When an aerodrome is selected, a new Weather dialog will be opened. This dialog will consist of three sections:

• Epheremis: two rows showing the sunrise and sunset time
• METAR: one row showing the raw METAR data
• TAF: one row showing the raw TAF data

The dialog will have two buttons: Refresh and Close.
Additionally, a colored badge displaying the flight rules (VFR, MVFR, ...) and a row showing the time at which the data was fetched will be added.

C++
The logic powering the Weather page and dialog described above will be held in the class Meteorologist.
The class will be constructed using a Waypoint (an aerodrome). It will have the following members:

• file, the file where the weather data will be saved to disk (Appdata/weather/icao.json, where icao is the ICAO code of the aerodrome)
• sunrise, the sunrise time
• sunset, the sunset time
• metar, the raw metar data
• taf, the raw taf data
• rules, a pair containing the flight rule and its associated color
• fTime, the time at which the weather data were fetched

Each of these members will be private and accessible through dedicated getters.
Additionally, the class will have the following methods:

• read(), read the weather data from disk and set the members accordingly
• computeTimes() compute the sunrise and sunset times and set the members accordingly
• fetch(), fetch the weather data from NOAA, set the members accordingly and save to disk

A Meteorologist object will be constructed when an aerodrome is clicked on the Weather page, and destroyed when the Close button is clicked.
The constructor will call read() and computeTimes(). A click on the Refresh button will call fetch().

Users find it confusing that the route is not shown at high zoom levels. Also, there is a possibility for confusion because routes and traffic circuits are drawn in the same green colour. Following the design of visual approach charts, traffic circuits should better be drawn in blue.

This is obviously useful for flying home…

The following behaviour is a bug.

• Create route by double-clicking on waypoints, then selecting "Add to Route" in the dialog

• Obtain waypoint info by double-clicking on one of the waypoints again. Find the the dialog window is empty.

The app could be made more responsive by using multi-threading.

• The GeoMapProvider class could use multi-threading when compiling GeoJSON files

• On low-end devices, the app becomes temporarily unresponsive when downloading files.

Okay, so this might be a little controversial.

I'm using the routing functionality more than anything else and I feel that it is too far away at two taps. I would love to have it at one tap, with a shortcut button right under the menu button in the upper left corner of the map view.

Happy to discuss!

Paramotors are so slow that the current threshold speed is not useful for them. Modify app the serve their needs.

Hello, I have an issue with Android Enroute app installed on Samsung Galaxy A8 (EditText is not displaying when user wants to edit route data). It works on Samsung Galaxy S7.

Steps to reproduce (on Samsung Galaxy A8):

• clean install app
• open navigation drawer menu
• click "Route"
• swipe to "Aircraft and ..." tab
• try to edit anything

It does not work even if you specify waypoints.

Can you please make the App available not only on googles Playstore?

It would be a nice benfit if you could provide it on f-droid for example or as an APK download,within the Github Releases. Not for the average user but at least for those that know what they are doing with that.
I hope once it is compiled an published on the playstore, it will be no big deal to distribute it elsewhere.

When in flight mode, the aircraft symbol is centred on the screen. This is not really good, because the route that's ahead is more important than the route section behind the aircraft.

The title says it all.
Markus Sachs also suggest: "Wegpunkte allgemein: Das Angebot "auf Karte anzeigen" wäre eine schöne Ergänzung. Ein per Antippen zur Strecke hinzugefügter Wegpunkt lässt sich nicht sinnvoll benennen und nicht als Favorit abspeichern. "

The title says it all. When no basemap is installed, the maps are not rendered properly, and the following debug message is emitted:

[ ERROR ] "{QSGRenderThread}[Setup]: loading style failed: HTTP status code 0"
[ ERROR ] "{QSGRenderThread}[Style]: Failed to load glyph range 0-255 for font stack Open Sans Regular,Arial Unicode MS Regular: HTTP status code 0"

Request to add a log of starting and landing times, as well as duration of flight.

It might look very similar to the flight route view. For simplicity, it should be only one list ordered by time, with the latest flight on top of the page. There could be horizontal dividers to separate flights on different days.

Starting and landing times might be determined by the mode-switches of the app (from stationary to flight mode and vice versa).

In the waypoint description dialog, the abbreviation for "elevation" should be "ELEV", not "ELE"

… the title says it all.

The title says it all…

No support for fonts used in some European countries that include support for letters that use caron( ̌ ).
For example ľ č ť ž and more. This issue breaks a names for a lot of cities in balto-slavic countries.

Title says it all. GitHub should generate warning messages when code in the master branch fails those checks.

The current GUI allows to add waypoints to a route. Steps to reproduce:

• open Route page
• Click on "ADD WAYPOINT"
• Enter "xxx" in the text field, so list of waypoints becomes empty
• Hit return

An invalid waypoint is then added.

in Czech base map I see missing characters in town and willages names when this are czech characteristics characters like ž, š, č, ř, č etc. Instead of Kroměříž it is visible like Kromí, instead of Přerov>Perov etc etc. Most of towns and willages names are bad.

Rotating the direction of the map can only be changed by rotating by two fingers. It's hard to find a Northern oriented direction again.

Proposed solutionb
Clicking on the compass card orients the map Northern

Flugstrecke:

(1) abspeichern liefert offenbar nur einen guten Namensvorschlag, wenn alle Wegpunkte ICAO-Kennungen haben. Dolmar-EDQN zB liefert "Flugstrecke", obwohl da mangels Kennung "Dolmar-EDQN" ja nicht schlecht wäre. Betrifft sicher etliche UL- und Segelflugplätze.

This could be done by hiding system icons etc

Would be nice if a route could be stored for further use.

The following behaviour of the app is counter-intuitive and might confuse users:

• Open the app
• Double tap on the map, in order to open an info dialog with airspace information
• Tap on the Android "back" button to close the dialog
• The app exits.

Similar issues probably exist elsewhere in the GUI. This should be amended to make the GUI more intuitive.

(1) hier noch ein Vorschlag für FlightRoute::suggestedFilename() in FlightRoute.cpp:

...
QString start = _waypoints.constFirst()->get("COD").toString();
if (start.isEmpty()) // kein ICAO-Code vorhanden
// NEU: mit Namen versuchen
start = _waypoints.constFirst()->get("NAM").toString();

if (start.isEmpty()) // und wenn das auch nix wird (aber einen Namen müsste es doch immer geben?) ...
    return result;

// Endpunkt analog:

QString end = _waypoints.constLast()->get("COD").toString();
if (end.isEmpty())
    QString end = _waypoints.constLast()->get("NAM").toString();
if (end.isEmpty())
    return result;
... 

I noticed that this app uses quite a lot of battery in flight, even when the app is running but not shown on top of the device. This can probably be improved by reducing the number of GPS fixes to "one on 20sec" as long as the app is not visible. Perhaps we can also avoid invisible map updates in these situations.

Title says it all.

If you want to add a waypoint into the middle of a long route, it's quite cumbersome at the moment, using the three-dot-menu.

Title says it all.

At present, the app always shows "TC up", which is not always desirable. Perhaps one could turn the north arrow into a button that allows to switch between the various modi.

The enroute binary contains too many fonts. We should check the MapBox style file, see what fonts are really used and only include those.

This might be useful for people using power gliders in Germany, where instrumentation is usually metric.