Notices


Reply
Thread Tools
carlosgonz's Avatar
Posts: 80 | Thanked: 225 times | Joined on Jul 2018 @ GT
#61
cool feature presented by @mosen. [ Hybrid Navigation ] could be realistic using magnetometer GPX OBD or inertia data? @osmo? @martink? @rinigus?
__________________
debian os
nokia n900 + nokia n9 + jolla 1 + jolla c + xperia x sf
ti chronos + lg d asteroid + samsung w3 tizen

Last edited by carlosgonz; 2018-08-29 at 01:31.
 

The Following 4 Users Say Thank You to carlosgonz For This Useful Post:
mosen's Avatar
Community Council | Posts: 1,034 | Thanked: 6,277 times | Joined on Nov 2014 @ Kitchen
#62
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

Last edited by mosen; 2018-08-28 at 22:18.
 

The Following 7 Users Say Thank You to mosen For This Useful Post:
carlosgonz's Avatar
Posts: 80 | Thanked: 225 times | Joined on Jul 2018 @ GT
#63
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).
__________________
debian os
nokia n900 + nokia n9 + jolla 1 + jolla c + xperia x sf
ti chronos + lg d asteroid + samsung w3 tizen

Last edited by carlosgonz; 2018-08-29 at 13:30.
 

The Following 4 Users Say Thank You to carlosgonz For This Useful Post:
Posts: 940 | Thanked: 1,726 times | Joined on Jul 2010 @ Brittany, France
#64
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?
 

The Following 6 Users Say Thank You to Kabouik For This Useful Post:
carlosgonz's Avatar
Posts: 80 | Thanked: 225 times | Joined on Jul 2018 @ GT
#65
@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.
__________________
debian os
nokia n900 + nokia n9 + jolla 1 + jolla c + xperia x sf
ti chronos + lg d asteroid + samsung w3 tizen

Last edited by carlosgonz; 2018-08-30 at 20:53.
 

The Following User Says Thank You to carlosgonz For This Useful Post:
Posts: 644 | Thanked: 3,398 times | Joined on Aug 2016 @ Estonia
#66
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
 

The Following 8 Users Say Thank You to rinigus For This Useful Post:
Posts: 644 | Thanked: 3,398 times | Joined on Aug 2016 @ Estonia
#67
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)
 

The Following 11 Users Say Thank You to rinigus For This Useful Post:
Posts: 1,493 | Thanked: 7,155 times | Joined on Apr 2010 @ Czech Republic
#68
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. ).
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 10 Users Say Thank You to MartinK For This Useful Post:
Posts: 644 | Thanked: 3,398 times | Joined on Aug 2016 @ Estonia
#69
Originally Posted by MartinK View Post
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)
MartinK, I think that they met hybrid == inertial_nav_system.

Originally Posted by MartinK View Post
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.
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.

Originally Posted by MartinK View Post
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.
Good point. They might, have to check the build in nav system when I get into the bigger tunnel.

Originally Posted by MartinK View Post

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. ).
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).
 

The Following 6 Users Say Thank You to rinigus For This Useful Post:
Posts: 235 | Thanked: 1,081 times | Joined on Dec 2014 @ Earth
#70
Originally Posted by mosen View Post
Some pages back (or was it in OSM thread?) i suggested to look into OBDfish for reliable speed data when gps is not available.
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.

Originally Posted by mosen View Post
It would be so cool if pure maps could pick up some data from a running obd fish instance and do magic no nav app has done so far(?).
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)

Originally Posted by mosen View Post
Taking exits in tunnels is much more complicated though, i concour.
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.

Originally Posted by mosen View Post
Sadly the turn indicator is not hooked to any ECU even in modern cars, so it is not accessible via obd2.
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).

Originally Posted by mosen View Post
But it is mostly not necessary because i rarely remember having to take multiple exits in one continuous tunnel.

The most common situation are tunnels with some exits that leave out of the tunnel so the the signal would be picked up again when leaving and then correct the displayed position.
Most vital is the info when to exit/turn for the first time.
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).


Originally Posted by mosen View Post
Why does no nav app display the distance to a speed limit?
For "fuel conservation" it is quite nice to know there will be a speed limit around the corner and it thus makes no sense to give full throttle for an overtake you will not finish. Or going fast and not having to waste precious brakes but gently roll out to allowed limit some hundret meters earlier (e.g.).
I checked in all common android apps, no one is doing it. I would love to see info about speed limits ~1km before reaching them. Or depending on speed, some sane amount of seconds before.
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.
 

The Following 9 Users Say Thank You to DrYak For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 10:35.