Notices

The main issue is that we cannot have any swipe gestures on map view. As soon as you are on map, we cannot support swiping left and right. If we restrict swiping area to the top only, it will feel rather awkward. So, on map view, we have to be limited to buttons, bars, and such. On other screens, we can use native way of interaction

So, according to that line of thought, as soon as you have two points (origin and destination), the route is calculated - no questions asked, no options taken. It becomes uncontrollable by users.

One bad side effect is if you were walking and then suddenly try to calculate walk path for 50 km journey. This will not be rejected (larger distances maybe) and your phone will get huge number of maneuvers. So, maybe on screen 2 we should have some kind of route type selection (above From/To)?

4th screen - agree with name change

Now, we should not think about all these pages as a line. Its a branching structure, with what's drawn as #4, being one of the pages behind map route view.

Few notes regarding navigation bar on #5. X is taken as a dismiss icon on SFOS and Linux. And it has the same meaning for Search, POIs, Nearby, and Navigation - the mode is dismissed. In case of navigation, it is dismissing just the mode and keeping route intact. I plan to drop the route as well in the future - I suggest not to keep the route after you escaped navigation mode. Its similar to other software and I have a feeling its an expected behavior.

Burger menu could be directly linked to Route options.

Navigation bar text could contain the mode (Car, ...), or current displayed maneuver, for example.

I don't like START on #5. I would suggest to add start button that is shown while on #5. Somewhere towards lower section of the screen (left or right). We can also have maneuvers button and then we don't need any link from Route page (maybe should stay Navigation). That navigation page also doesn't need to have link to Route options - these are available via navigation bar through burger menu (and maybe a title).

Note that in future, map scale will be moved to map itself or somewhere where it makes more sense.

What's not covered, are search along route and map layer. These functions should be available while not navigating, I think. In this respect, they can be positioned as buttons (like center, compass) in route overview map mode (page #5).

What's also possible is to have controls on lower panel, shown when you tap on it.

Whether we should keep upper panel clickable - not sure. But it will not cost anything and would keep current users happy.

While navigating (page #7), there is also a proposal to move speed to the right top. Only issue in that case would be finding location for a speed limit sign - which I do expect to be next to the speed.

As soon as we get these links sorted, we will have a pleasure to figure out what to do in landscape mode too. So, we can keep that on a back of the heads as well

I have a question about importing gpx files.

There are 2 options: gpx and gpx smart

Import is working with GPX but not with GPX Smart

With gpx smart i always get "No results".
Is there anything i need to enable?

Routing profile is 'Mixed'...

GPX Smart will take your GPX trace and fit it against routes that Valhalla component in OSM Scout Server knows. This is used to allow you to get navigation instructions (like "turn left on the northern street").

For it to work, you'll need:

* osm scout server with the maps for the area in question
* correct transport mode selected in gpx smart settings

If, OSM doesn't have any roads that can be fitted with GPX, or, if you want to go by car and the street is unidirectional in opposite direction of your movement, or some similar issue, it will not work.

OK, i try to use this track: https://www.outdooractive.com/downlo...SSRWYU&lang=de

Tried with different Maps and have chosen "Bicycle" and "Foot" as Type but it doesn't work. Seems like some roads can't be found by osm scout server.

I think i am fine with pure gpx, thanks for the hints!

@rinigus: Please correct me, if I'm wrong...

I guess, GPX (smart) import of PM is mainly designed for importing waypoints instead of tracks.

If you import GPX with multiple waypoints using "GPX smart", PM will try to create a route connecting all waypoints (as long the waypoint coordinates can be referenced to streets within the used maps).

If you import GPX with multiple waypoints using "GPX" PM will connect the waypints directly (without routing between them and turn-by-turn announcements).

BTW: This is actually the only way to create routes with multiple stops (without possibility to edit these within PM).

Interesting side effect of a smart mode . Smart mode was mainly done since it was easy to make. As for proper waypoints support, its planned, but cannot promise when

Simple speed comparison between Pure Maps 1.19.0 and Poor Maps 0.34.3, both with OSM Scout Server 1.14.1 (all three installed from OpenRepos), OSMscout 1.9 (installed from the Jolla Store), OSMand 3.3.7 and Maps(.me) 9.0.8-2 (both installed from F-Droid) in offline mode (mind to explicitly set that in Pure Maps!).
Note that the map data for all apps are on encrypted SD-card, thus slower and making the apps more I/O-limited (WRT read bandwidth, but also access latency) than on unencrypted SD-card or internal eMMC (which is much faster than an unencrypted SD-card).

Test procedure:
1. Set OSM Scout Server's settings, if it is involved in the test.
2. Clean app caches per Mashka (from OpenRepos) rsp. Cache Cleaner (from F-Droid), except for the "warm" start-up time tests.
3. Restart GUI ("lipstick"; this also shuts down an automatically started OSM Scout Server running in the background and restarts AlienDalvik) rsp. only AlienDalvik (for Android apps), except for the "warm" start-up time tests.
4. Wait 40 seconds after the desktop ("home screen") is fully displayed rsp. restarting AlienDalvik was triggered (better a full minute on Jolla 1 phones).
5. Start GPSinfo and wait until a stable GPS fix (location icon in statusbar permanently lit and > 6 satellites "in use") is acquired, wait for 10 more seconds and let GPSinfo run throughout the test (alongside AlienDalvik which is started on boot-up).
6. For address lookup and routing speed tests, wait 30 seconds after the map is properly displayed, before initiating an address rsp. route search. A short (~ 12 km) and medium (~ 59 km) route were used in car mode.

The tests were carried out on an Xperia X with SFOS 3.0.2 and two Jolla 1 with SFOS 2.2.1, GPSinfo refresh rate set to 1 s, sufficiently free (and "balanced" for BTRFS) space on mass storage (i.e., partitions on eMMC and SD-card), at least three times each (outliers dropped and results averaged) with the primitive stopwatch function of the SailfishOS' Clock app (on a different device). A single offline map provider was used (no overlays etc.). When trying to roughly reproduce these results, mind to have "Allow application background services to start on bootup" switched off (the default) for all Android apps in the SFOS Settings app -> Apps.
No data for Maps on the Xperia X and "Jolla 1 new", because any map download fails consistently.

Note that the three phones are configured slightly different:
- The Xperia X uses couple of multi-Gigabyte country maps (for all apps, except OSM Scout Server using libosmscout, which technically uses only a single map), five languages for address parsing, plus EXT4 as filesystem and AES-128 with XTS for encrypting a Sandisk ultra 128 GB from 2017.
- The "Jolla 1 new" also uses couple of multi-Gigabyte country maps (except OSM Scout Server using libosmscout), five languages for address parsing, plus EXT4 as filesystem but AES-128 with CBC-ESSIV:SHA256 (specifically slows random accesses more than XTS) for encrypting another Sandisk ultra 128 GB from 2017.
- The "Jolla 1 old" uses a single multi-Gigabyte country map (except for Maps, for which only a few smaller maps were downloaded), one language for address parsing, plus BTRFS (slower than EXT4) as filesystem and AES-128 with XTS for encrypting a Sandisk ultra 32 GB from 2017.

Also note that most outliers were too fast, often due to missing to clean a cache, to restart something (e.g. OSM Scout Server, AlienDalvik) or to assure only offline sources were used.
Outliers, which were too slow, were mostly caused by background services of Android apps (missed to disable them all to be started on boot-up or having run Android apps since last reboot) or by not keeping aforementioned setting times (in steps 4., 5. and 6., above).

All values are in seconds; due to manually triggering the stopwatch and app starts, etc. there is at least two seconds variability (i.e., ± 2 s).


Start-up times on the Xperia X ("cold" / "warm" caches for Android apps and OSMscout rsp. "cold" / "cold" & OSM Scout Server still running / "warm" & running):
- Pure Maps: 9, 8, 7
- Poor Maps (libosmscout): 6, 5, 4
- OSMscout: 7, 6
- OSMand: 30, 25

Start-up times on the "Jolla 1 new":
- Pure Maps: 18, 9, 8
- Poor Maps (libosmscout): 18, 7, 4
- OSMscout: 45, 38
- OSMand: 36, 34

Start-up times on the "Jolla 1 old":
- Pure Maps: 20, 14, 12
- Poor Maps (libosmscout): 22, 12, 8
- OSMscout: 12, 8
- OSMand: 65, 50
- Maps: 40, 30

Note that all Android apps have a disadvantage under the Android 4 runtimes, because they have to use Davlik (ART was introduced with Android 5) etc.


Address lookup speed on the Xperia X ("cold" caches, OSM Scout Server running, address simply "Vorm Baum 6" pasted into the search field):
- Pure Maps (geocoder-nlp; results are only from a single, wrong country!): 14
- Pure Maps (libosmscout; mediocre results): 3
- Poor Maps (geocoder-nlp; same results from a single, wrong country!): 8
- Poor Maps (libosmscout; mediocre results): 2
- OSMscout (first result / all hits; few, but good results): 1, 2
- OSMand (first result / all hits, good results): 9, 23

Address lookup speed on the "Jolla 1 new":
- Pure Maps (geocoder-nlp; single, perfect result): 3 (first test series; single, mediocre result!?!: 15)
- Pure Maps (libosmscout): 2
- Poor Maps (geocoder-nlp; same results from a single, wrong country!): 126
- Poor Maps (geocoder-nlp; a different address, single, correct result): 60
- Poor Maps (libosmscout): 4
- OSMscout (no result!): 23
- OSMand (first result / all hits): 22, 175

Address lookup speed on the "Jolla 1 old":
- Pure Maps (geocoder-nlp; good results): 40
- Pure Maps (libosmscout): 6
- Poor Maps (geocoder-nlp; good results): 45
- Poor Maps (libosmscout): 5
- OSMscout (first result / all hits): 2, 3
- OSMand (first result / all hits): 12, 30
- Maps (first result / all hits): 30, 35

Observations:
- Some apps are much faster on subsequent searches for similar search terms, seemingly due to different caching strategies: While some apps seem to evaluate the the search history (needs location to be saved together with the search term, there), OSMand seems to cache former search suggestions (with their location) and to evaluate them first (or in parallel to querying the geocoder) on subsequent searches.
- Furthermore the usability of the "search while typing" function and the quality of the results do vary (e.g. their order/ "how far up is the intended location?").
- The search issue with geocoder-nlp on the Xperia appeared while using its settings "Search all available maps", "Use libpostal parser", "Use primitive parser", five languages selected and eleven maps in use. The "Jolla 1 new" uses exactly the same settings, languages and seven maps, while "Jolla 1 old" uses the same settings but only a single language and map, and both do not show this bug (but PoorMaps does!?!).


Routing speed on the Xperia X (~ 12 km / ~ 59 km):
- Pure Maps (Valhalla): 2, 7
- Pure Maps (libosmscout): 4, 14
- OSMand (also provides height profile): 26, 28

Routing speed on the "Jolla 1 new" (~ 12 km / ~ 59 km; numbers in brackets are for redrawing the map):
- Pure Maps (Valhalla): 2 (+ 1-2), 3 (+ 1-2)
- Pure Maps (libosmscout): 4 (+ 1-2), 5 (+ 1-2)
- Poor Maps (Valhalla; without address lookup): 26 (+ 2-5), 30 (+ 2-5)
- Poor Maps (libosmscout; without address lookup): 9 (+ 2-5), 21 (+ 2-5)
- OSMand: 84 (+ 3-7), 115 (+ 3-7)

Routing speed on the "Jolla 1 old" (~ 12 km / ~ 59 km, only a single map):
- Pure Maps (Valhalla): 26, 42
- Pure Maps (libosmscout): 13, 25
- OSMand: 22 (big variation), 125
- Maps: 8 (plus for a preceding map redraw: + 14), 20 (+ 8)

Observations:
- One cannot set OSM Scout Server as routing engine in Poor Maps anymore, but routing with it works, if it has been set before; hence no results for Poor Maps on the Xperia X and "Jolla 1 old".
- Routing with OSMscout 1.9 failed for me on all devices (with a symlinked data directory), emitting "Can't open routing service", but worked before (tested on the Jolla 1s a long time ago).
- The test series with the "Jolla 1 new" were carried out many weeks later, but with exactly the same software versions; still Pure Maps (and maybe also Poor Maps) seemed to behave a bit differently than the "Jolla 1 old"; a forgotten "Mixed mode" setting (instead of "Offline mode") in Pure Maps might partially explain this.


P.S.: Performing benchmarking manually in a reproducible manner turned out to take more proper preparation and was much more tedious than expected, but ultimately finished yesterday.

Thank you very much!

I tested the search for "Vorm Baum 6" and it actually gave me a correct hit on the desktop. I had to download europe/germany/nordrhein-westfalen for it. Which makes me wonder whether a correct region was downloaded - seems like this particular region is close to the border of map regions.

Would you mind to check the output for

http://localhost:8553/v2/search?limi...ch=Vorm+Baum+6

on your device with OSM Scout Server installed? Mine is

Search with your url did not bring Raxevormwald until I recognized the limit (having lots of results from the Netherlands). After setting it higher I saw also the one result.
Search in PureMaps immediately brought the exact result!