Consider primary roads for long distance routing by default

[metalstrolch]

As discussed in #962, Navit currently has issues to route over long distances if the route contains parts over "only" primary roads. This is really annoying, as Navit doesn't find a route from e.G Kaufbeuren,Germany to Bern,Switzerland because of 7 KM gap in the motorways between Austria and Switzerland south of the Bodensee.

In #962, @mvglasow suggests changing the route_depth value for the vehicleprofile to overcome that limitation, causing higher CPU and memory usage. With that setting, Navit properly routes to Bern.

This issue is about discussing if we should make that change default for all the "not so constrained" platforms like Linux, Android and Sailfish. At least on my dated "Jolla1" the change did not make any really noticeable performance impact giving way better user experience.

[mvglasow]

@metalstrolch you beat me to opening this issue :-) We discussed that as far back as 2011, and it seems the main reason for the limitation was memory usage. However, I have been using this route profile on a regular basis since around 2013 and never had an issue. Munich–Tallinn (more than 2,000 km) works fine even on an old Android device with 1 GB of memory. CPU is also less of an issue than it used to be—by now, even entry-level devices running Navit should be able to handle the extra load.

As mentioned in #962, there used to be some holy war back then regarding whether the national road network should always be trunk or higher—this was not the case in places like Austria, Switzerland, Germany and Poland then, and it has not changed in over eight years.

TL;DR: +1 as I don’t think resource constraints are as tight as they used to be.

[metalstrolch]

I don't know about religious things back then as I wasn't involved. But this setting solves annoying routing limitations I thought are quite harder to fix. At least for sailfish there is no device existing that cannot bear this. And being configurable we can decide not to use it e.g. on wince / tomtom. After all its just navit.xml

Anyone else?

[clarified]

Well, as someone who is currently experiencing problems on a wince satnav (with a "generous" 128M of RAM), please do make sure that that wince continues to avoid inheriting infeasible settings in the navit.xml shipped with wince. I have an older wince satnav with just 64M RAM, and that still worked with navit until quite recently.

[metalstrolch]

Well lets do what can be done. But its getting harder and harder to maintain those old devices. Not so much because we require more resources but because there is almost noone left capable to and owning one of those devices.

[mvglasow]

As a former WinCE user, I ditched my two devices because they were incompatible with SDHC cards, constraining me to 2 GB of map data. Maps get larger as more detail is added, so these devices became impractical to use long ago.

As for memory, a workaround is always to use a custom navit.xml without the proposed update to route_depth. Possibly in a separate profile (e.g. car_low_memory) so you can switch back and forth.

We could also tweak the default navit.xml specifically for WinCE builds. However, that amounts to saying WinCE = constrained memory. What are the specs of the last WinCE devices on which Navit runs? If there is no supported WinCE device with anywhere near 0.5–1 GByte memory, I would suggest that option. Otherwise, we might consider adding a car_low_memory profile on WinCE (and possibly other devices with limited memory—what’s the situation on TomTom?).

[gefin]

The memory problem exist also for Tomtom. I added some notes about RAM, swap and route_depth to the old wiki. TT XL is very restricted usable with navit 5.4. It has only 32M RAM and maximal 2GB sdcard.
TT730 (64 M RAM, 8G sd) is usable with special settings: 100M swapfile, reduced route_depth and a map build with maptool.

[clarified]

Well, as in #953, I have a Wince 7" satnav with a mere 128MB of RAM and it is now running very well with the current navit. The extreme problems I did have were with maps produced by the planet extractor: I now compile my maps locally with maptool which has solved all the problems.

I normally run with two maps. one a contour and the other a country wide routable map. I did have a quirk with the coastline, but that's really a minor (and known?) issue with some versions of maptool.

The point is that there are not many options with a largish 7" screen, and I want to have the context including contours shown on the map, so the large screen is highly desirable. I hate winCE as much as the next person, but there were so few options when I purchased, and the unit was very reasonably priced.

Furthermore it is highly undesirable to scrap perfectly serviceable units like this and increase global pollution and electronic waste. So as far as I can tell, it is far too early to write off existing wince devices. Oh, and mine can handle reasonably large SDHC cards.

I agree that the map size is indeed limited to 2GB, but so far I have not needed more than 1 GB.

I did tune my navit.xml before I discovered that the problems were with the Planet-extractor maps. Now I am back to pretty standard settings in navit.xml, and, as I say things are working very well indeed.

And thanks to the developers for maintaining and improving navit, but please don't drop or ignore wince, painful though it is.