Even my old HTC Desire running Froyo can now run Locus again. Incl. vector maps of Germany. Well done.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.Show posts Menu
Quote from: menion on October 15, 2013, 07:36:41
that's correct, no caching if you have enabled "Auto loading". Anyway question wasn't if map are slow (we all know they're in certain levels), but question is whether they're slower then in previous version as @alex_dd wrote. I hope not
Quote from: menion on October 14, 2013, 23:39:10
@alex_dd: online maps will be almost always little faster, mainly if you have area already cached. Anyway there should not be any slowdown of vector maps in last versions. Anyone experiencing some problems with speed of vector maps?
Quote from: KaHeMu on October 12, 2013, 17:01:16
Normally you're right. But next year I'll do a very long hike (about 2000 kms) and first I have to do is looking for a good and interesting way with some fix points for sightseeing or another things. The breaks or accommodation places I'll see from day to day.
Looking for the generally trek is a job where brouter and locus could help.
Quote from: KaHeMu on October 12, 2013, 13:39:44Quote from: michaelbechtold on October 12, 2013, 12:24:32
And for bicycle and foot path search, such single long distance searches do not make sense anyway (and you do not need to optimize for irrelevant use cases). For motorcar, the relevance is obvious. though.
This applies only for that people they aren't moving without a car. For car navigation there are special apps or devices to do very good job.
But there are many people outside which are moving by foot or by bike, often for long distances (>200 kms).
Just my 2 pence,
Quote from: abrensch on October 07, 2013, 13:32:32Quote from: michaelbechtold on October 07, 2013, 12:21:30
Not sure if somebody reported already that 60000 ms (1s) are a too short timeout for brouter.
Just tried with a route from Frankfurt to Praha -> Locus timeout ...
Maybe you could make it a something like: timeout = (geo distance) * (configurable factor)
The timeout is important to protect the device. 60 seconds is the default, but there's a parameter in the aidl-interface, so it can be changed from outside.
However, the long-distance solution I am working on is "fast-partial-recalculation": the idea is that if a route to the same destination-point and for the same routing-profile is already known, a partial recalculation is done and the result is a combination of the old and the new calculation. This way you can do a long-distance calculation by starting the brouter-app, but then have fast recalulations if you follow the route and get off the track.