Notices

It seems there's a small oversight in my regular expression – it doesn't work for negative coordinates. Also, if you're typing in manually, you can skip the "geo:" part, any of "LATITUDE,LONGITUDE", "LATITUDE, LONGITUDE", "LATITUDE LONGITUDE" should work.

There have been a number of occasions when I was not navigating to any specific place, just a general area "somewhere around the centre".

Who runs the heuristics and makes assumptions depends on the agreed interface, does it not? You can have a dumb client and a smart server or the other way around. I am mostly leaning towards a dumb server and rely on the client to formulate the query properly. It makes for a more flexible design as the server can be more easily reused in different clients, but it's up to you.

Regarding the "geo:x.xxx,y.yyy" notation, it seems to work after all but only for positive numbers. "geo:55,1" works fine, "geo:55,-1" gives "no results". It must be a limitation on the input field because all destinations I've tried so far have been on the western hemisphere with negative longitudes and they all worked fine, so the backend must be alright.

EDIT: I see we cross-posted. Kewl. Thanks for answering.

I have started looking into the styles which would be better suited for car navigation and I would like to outline few points to continue the discussion on it over here.

Before getting into the technical aspects, let's review how we use the navigation app while in the car. There are two modes of operation, road selection/review and navigation. In the first mode, we can hold the phone in the hands and would be great to have detailed maps. In the second one, with the device significantly further away than in the hands, there is only fast glance that should provide sufficient information. I think that switching between the modes is needed for proper operation and that can be provided only if the software and styles work hand-in-hand. Its somewhat similar to the situation of the day/night mode switching, which is needed for longer car trips as well. Same arguments go for cycling.

From technical aspects, I would suggest to approach it as follows:

* Define not a single style, but style families. So, in https://github.com/otsaloma/whogo-maps/tree/master/maps, we would have Cartago grouping Cartago and Cartago Car. Similar would be for Mapbox Traffic (Day and Night) and OSM Scout (Day, Night, Car Day, Car Night). Users would have to just select Cartago, Mapbox Traffic, or OSM Scout for these combinations. These groups should be easy to define by extending current JSON definition.

* Car styles in the group, when defined, would have larger fonts and wider roads. As an alternative, each style in the group could have "Zoom factor" defined that would use zooming feature of Mapbox GL to blow up the map. This zoom factor should be multiplied by the factor selected in the Preferences.

* Day and night modes are swapped automatically or via Preferences by user.

* Car and regular modes are swapped by pressing Start/Resume and by Stop in Navigation.

Note that while Mapbox zoom can help with the transition, it does effectively reduce your map DPI. One can argue that it doesn't matter much when navigating, its probably should be a choice for developers.

Thoughts?

Sounds good to me.

I wouldn't call the styles families though as I see that consisting of maybe street, car navigation, satellite, outdoors and maybe some others that don't fit binary navigation on/off classification. So, I see it more as an optional link which defines the corresponding navigation map. But, that's just a detail, the idea sounds good and matches existing art as far as I can tell.

A funny thing happened today. I was driving to meet someone at a designated spot, using WhoGo to get me there. Suddenly, my Jolla went dark. Strange, as I have it set to keep the screen on while navigating.

The reason was that I was driving past a known WiFi hotspot that pops up a browser with a login page. The browser took the focus while I was not looking and then the screen timed out and went blank.

An even stranger thing happened about an hour later, when WhoGo was safely closed - or so I thought. I unlocked the phone for some other, unrelated reason, and it started speaking navigation instructions. I checked and then checked again and yes, all applications were closed. I started WhoGo but it shut down instantly. I eventually had to restart Lipstick from Sailfish Utilities.

your second experience is not new to me. Unfortunately that happens quite often to me. Especially after using WhoGo for longer navigations.

Fellfrosch, pichlo: do you both have J1 or something beefier in terms of RAM? I would expect OSM Scout Server to be autostopped for longer navigation, unless rerouting kicks in. So it's probably Mapbox GL memory consumption. I haven't experienced it myself, but I have 3GB RAM as well and maybe my trips were not long enough.

rinigus, my trip was very short, about 20 minutes. But when I arrived at the designated spot, the other party was not there. It turned out they gave me a wrong address. I knew where the correct address was and drove there without navigation. It is possible that WhoGo was still trying to reroute me to the original address when I was closing it.

All on J1.

No J1 on my side. Xperia X.

Yes, if you haven't turned it out, it will keep rerouting (if I didn't miss a case where WhoGo maps stops navigation automatically, but I doubt it). So, that may fire new server which could stress RAM somewhat, if it was stopped in between.

pichlo, do you run systemdatascope by any chance? It's data collection daemon collectd is very light (50MB RAM virtual) and would tell whether free memory is exhausted in your case.

If it is too low on RAM, unless its our bug, its rather limited we can do, unfortunately.