Notices

cool feature presented by @mosen. [ Hybrid Navigation ] could be realistic using magnetometer GPX OBD or inertia data? @osmo? @martink? @rinigus?

hmm, thinking a bit more about the tunnel exit problem even if speed is read from obd2.
The main difficulty is to detect position while driving freely without route.

If a route is set and displayed, why not simply assume the driver took the correct turn and happily display the position along the route until gps is ready again?

Yes, it might be "false info", but a good one to ensure the driver and continue the route without hickups.

If i could choose between exact representation of data that does give no info, and one that shows the most likely position but could be wrong. I am with the latter.
This could maybe shown by a blinking position marker to indicate: "Your exact position is unknown but along the route you should be here"

Even leaving out OBD/CAN, another way to detect speed change could be the phones sensors, or not? I mean isn't it possible to measure some kind of "g force" and conclude speed changes from last know speed?

Or maybe i am overthinking...

EDIT:
and heck yeah stepping it down a bit, i would also succumb a solution that simply assumes i am driving with constant speed just to continue the route display and give exit direction based on that vague assumption. Still better than no info.
I would know how to use it, drive with constant speed already 500 meter before the tunnel and be happy.
Wrong display = user error in that case

the track position could be tracked by speed & gpx(like virtual navigation) i guess. so the maps motion still will showed like online gps only with offline data. i do not know how much work will to rinigus.

edit: another way to detec speed without OBD(speed dinamic) is by inertia(speed static).

Where I live, there is a massive tunnel with several round-abouts inside, and even a parking lot. It passes through the whole city. Although I now know my way inside the tunnel, I guess GPS in there could be useful.

The thing I miss is multiple routes when starting a navigation. I seem to remember it was possible, either in Poor Maps or WhoGo. Probably Poor Maps since I didn't drive much since WhoGo was released. Not sure what was the router being used, probably the default one for online navigation.

I have got a lot of "No results", even for street names I double checked, or even the hospital. Only Stadia found my destination (but recommended a *very* weird route, 100% sure it was suboptimal, and my search was allowing everything), yet I had Internet, and I'm not using offline maps currently.

Also, speaking of hospitals, it turned out "hospital" didn't work in Norway, even in Stadia, and I had to write the exact Norwegian word for it to be found. Shouldn't it be found in English as well?

@Kabouik ¨ automatic multi routes preliminary view ¨ will the next late PR, manual multi routes is already.
@mosen other solutions perhaps could be something like this with high RX sensitive.

I have published a new version with:

* updated translations
* new API access keys

Please update, I will revoke the old keys in near future.

Now back to the discussion and points raised last night

I guess we should be relaxed regarding mixing the subjects of Pure Maps and OSM Scout Server. I hope all read the relevant threads, including the ones related to the map clients they don't use.

Slow searches using OSM Scout Server.

Its, indeed, a problem. I assume that you are using default profile (Mapbox GL, GeocoderNLP, Valhalla). In particular, search is done via GeocoderNLP. When you use libosmscout as a geocoder, I would expect many missed results.

GeocoderNLP has rather complicated library behind it to parse the address - get from your free text input the hierarchy with house nr, street name, city is rather non-trivial task. Originally with 2GB+ RAM requirement, I managed to get it down to the mobile by splitting the planet into countries. After parsing, it has to search in hierarchies for the object. This part I wrote for the geocoder specifically and there could be bugs due to limited testing. When RAM is not squeezed, you would expect much faster response times. On my phone, geocoder usually takes about less than a second per country / region (Estonia, Sweden, Denmark, Finland). When the same country is split into the regions, geocoder should parse the string only once and then proceed with the same parsed result to search in the splitted by region databases. This is in great contrast to what you observe.

The last big contribution by Osmo was working on autocompletion. This allows you to start typing the request and see autocompleted results. I have added OSM Scout Server support for autocompletion on WhoGo side, but the server itself doesn't have any fancy algorithms made for such scenario specifically. It just runs the full search on every new input. So, maybe it has queued some searches before you get to the last of it. To test the speed of one search:

1. open OSM Scout Server in GUI and set its log level to log info messages (Settings/, towards the end). You could later examine the logs and see what takes time

2. start typing in Pure Maps a string using online geocoder. When the string is ready, select OSM Scout Server and hit Enter. Time how long did it take.

As for optimization, for larger countries, you could try to download smaller parts of the country. Then, in GeocoderNLP settings (Settings/GeocoderNLP), disable "Search all available maps". This will add country/region selector at OSM Scout Server main screen that you will have to set. Just remember to change it if you want to search in another region. For most of us its not needed, but, maybe it will help you.


OBDfish and the tunnel problem

I am sorry, but while it sounds cool, I think there are many other things that have to be done before that. We cannot save POIs properly, for starters. Find hospitals in Norway. Search using postal codes. Update / tune map styles, search by more generic types. I would prefer to look on those and many other issues before getting into the tunnel issue.

Its a cool sounding feature, I admit that. Just too far for me right now.


Distance to speed limit

Good idea and very relevant. Its possible (thnx to map matching) to get it in advance as well. Corresponding issue is at https://github.com/rinigus/pure-maps/issues/30 , would have to also think how to implement it and show on the screen. [we can make a sign, as on the street, with meters below it]. Also, there is an option to just use voice for it.


Multiple routes

Valhalla doesn't support it yet, I think. For me, the main issue with the multiple routes is how do I recalculate one on rerouting? That's why, I prefer to expose router options and allow you, through changing them, to tune it for what you want.


Geocoder, again, and missing streets

Check that you do use GeocoderNLP. If you cannot find some street and its there on OSM, file a bug (https://github.com/rinigus/geocoder-nlp/issues). When searching for a type (hospital), use Nearby search and specify the type and the distance from your point of reference. For OSM Scout Server, types can be entered in multiple languages, please choose one of the autosuggested types (start typing and select a type from the list, don't deviate from it).

hopefully, haven't missed anything

feel free to move relevant discussion bits between the threads (pure maps and osm scout server)

Adding some more points in the same format.

Hybrid navigation
Isn't that just "rotate map according to heading" ?
I can image this to have two configuration options:
- active: always/in navigation mode only/never
- heading source: magnetometer/direction of travel (IMU, some custom hardware, etc.)

For the record I plan to support this in modRana on the MapBox GL native widget (once usable)

Navigation in tunnels
What you are describing is basically dead reckoning or inertial navigation you take an initial known position and then try to compute position fixes later on via data you have available (absolute speed, compass, acceleration, etc.).

Ideally this would be something generic that works with the smartphone sensors (accelerometer, magnetometer, gyroscope, barometer) or any other available hardware (data from car sensors). This could be part of the location API, or something sitting on top of it, like the map matching API recently added to OSM Scout Server. That way all location using application could use this, possibly without even being aware the position fix came from inertial navigation and not actual GPS data.

Yes, in some cases having data about an upcoming tunnel & it's properties could help with the estimation, but then the logic would have to be much more wired to the app & it is still questionable if it would really help.

On a related note, do some of the commercial navigation applications, especially those integrated inside cars (so supposedly having all the car sensors at their disposals) do something like that (eq. GPS less position estimation) ? That could help answer the question how hard or even doable this is.

Multiple routes
I think the idea is you get multiple routes during route search, possibly even from multiple offline/online sources. Then you select one, forget about the others and follow it, including rerouting. (Yet another thing on the modRana TODO Matterhorn. ).

MartinK, I think that they met hybrid == inertial_nav_system.

Great links, thank you! Agreed, it should be then generic and usable from everywhere. Now, there is a small issue with permissions that may bite us in future. Originally, I wrote map matching with GPS location determined by the server and, on security basis, I decided to kill that code and let the clients feed the position (through provided QML widget). That way I don't have to think which app has permission to get location or not.

With some suggesting following the route, that would mean that every map client will have to provide the route as well. Anyway, it looks rather far fetched at this stage for me.

Good point. They might, have to check the build in nav system when I get into the bigger tunnel.

Well, the problem is if you have to reroute before the routes branch. Then you would need to know how was the selected
route different from the rest (if its the same provider, what are the algorithm parameters).

Great to see I'm not the only crazy one with ODB in mind.

Note that (on purpose) speed won't be reliable.

In several jurisdiction, it's illegal to under-estimate the speed.
If you go 81km/h but your car says 80km/h, the garage that did the setting will definitely get into trouble.
Thus it's common to put a (usually -5 km/h) bias in the reported speed to be on the safe side.

I would strongly suspect that the ODB reports the "corrected safe" speed.
(Haven't been hacking ODB, so I can't confirm. But any other car instrument such as adaptive cruise control seem to rely on the same speed).

So it might be useful to either give an opposite correction, or have the smartphone compute the correction while GPS is up.

Technically some of the embed satnavs *do* use the speedometer and compass as a fall back (random example, my parent's Volvo).
And on some cars, the satnav is an actually Android app running on Android Car (in my experience: on some Renault Zoé I've rented).
So there are other apps that do it, but it's a very specific exception (the app is running on a special platform that provide this), definitely not something that smartphone can provide.

(Well, maybe the comma.ai's openpilot would, in theory)

Some of the integrated satnav tend to try to guess from the car's compass heading.

In the specific case of Sailfish Apps, on platforms where it is supported, it could be possible to use the smartphone compass, provided that :
- it got calibrated during the time when GPS was available (i.e.: app sees that GPS reports the car driving straight ahead, but smartphone's compass is a bit "off" because apparently the driver has turned the smartphone toward them to have better visibility).
- the driver (or passenger) hasn't fumbled with the smartphone's stand while in the tunnel.

Shouldn't the turn lever be hooked on cars with Lane Departure Alarm System (LDAS), so it is communicated to the camera and the camera knows if a (dashed)-line crossing is expected or not ?
(If you change lane and put the turn signal, the LDAS is silent.
If you forgot to put the signal, or are slowly veering out of your lane, the LDAS sounds).

On non-hooked LDAS (such as some aftermarket dashcam, or satnav/dashcam combo like Garmin), the alarm only sounds on non-dashed (non-crossable) line crossing.
(LDAS never sounds on lanes, only when you reach the highway's borders).

Obviously, you haven't lived in a city with an underground and/or tunnel-bridge highway network. Great for reducing noise and traffic in the city, but can get a bit confusing when you need to take complex/multiple exits.
(I am currently living in Basel, CH - had something much simpler but still in Neuchâtel)

Luckily, in CH it's *clearly* indicated.
- satnavs that try to simulate the indication image (Tomtom) usually guess it right.
- satnavs that have a real-world picture of the actual indication use those successfully (Garmin).


I also think it's a great feature (I've seen it on the Garmin I installed in my mother's car):
"Speed limit change to {new speed} in {countdown} meters" showing up in the top warning box.