Messages

@Menion: On levels 9 to 13 Vector maps are still pretty slow. In particular as there seems to be NO caching for ALL of those levels.

...
@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?
...

WOOOWWWW !
You set the bar high for brenche ;-) !!

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.

Kind regards,
KaHeMu

I go by all three ;-)
My failed situation was > 500 km, and in all fairness, neither walking nor bicycle will allow 500 km IN ONE GO.
Even 200 km is pretty extreme for both, again, without a "via" target. You would typically target some place in between, right ? Drink, food ?
While for car, going to a place 100s of km away where you need directions is not unusual.
There are workarounds, yes. But why not have a proper solution rather than a workaround.
And why using yet another app in addition when it can be in one solution (Locus+brouter) ?
Cheers
Michael

...

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.
TXs
Michael

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,
KaHeMu

Well, one more question then: does brouter have a notion of highways ? So this partitioning would be INSIDE your app, not manual ! I.e. first search highway connections only near to start and end points, then get from those points to/from the valid entries to the highway system. Do not mind about "optimal" connections - this is an NP-complete problem beyond reach on smartphones ... ? By above searchtimes will really collapse automatically. For motorcar search.

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.
TXs
Michael

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.

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)

All this is brand new, and nobody knows yet, so this would allow to gain experience.

All three modes documented above do work for me - however, bicycles and walkers are all sent to use HIGHWAYS ...
As Menion confirms he relays the selected mode to brouter via API, this should be a brouter problem then. I will try to report it to brouter support.

Hi Michael,
please read in this thread
http://forum.locusmap.eu/index.php?topic=3434.0
there are some posts from today

Thank you Balloni55, for this successful hint to the other thread.

Hi all, tried brouter today, fed tons of rd5 to the right directory, put profile from 0.9.4 brouter zip in place and started 2.16.1 beta.
Which the tells me that the brouter service cannot find motorcar-fast config (neither the others).
I did configure the motorcar, bicycle and foot configs in the service tab of brouter. but do not see any new files in the brouter config folder.
brouter folder resides on /storage/extSdCard, BTW.

Did anyone try brouter so far ?

Hello Menion,
how did you set this up ? I trust it worked for you ;-)
Thank you !

Michael

Last option, Menion: Points-Icon, Tracks-Icon - and an Items-Icon (so nothing is lost).

And looking forward to the 2.16.X beta with the POI-DB back ;-)

@michael and others: "data" problem - I'm not sure I understand. You don't like two separate screens for points and tracks (so you want just one that unite both) or you don't like word "Data" and it's icon (so you suggest to separate it into two buttons "Points" + icon and "Tracks" + icon? Then what about "Items" tab?

And offline POI's will be in Locus in future. This feature is here just for testing in testing versions, not in public version.

Yes, you did - I am well aware of the icons in a POI definition.
My point was to give POIs and Tracks individual, separate function on the uppermost level (which implies they get an icon other than th eold "Data")

i hope i do not missundersand you

quick POI categories could have their own icon assigned so that they appear in the map with real sign instead of generic "i"

You can change the POIicon ore the foldericon by long click on the grey underlaid icon and select anotherone
Much more icons you can download
http://docs.locusmap.eu/doku.php/shop:item:category_icons:user_sergey_01
store this zip to
locus/icons

PS: and I have not lost hope to see the offline OSM POIs come back. What I saw in earlier Betas was definitely useful !
Cheers
Michael

I definitely like the "More" over the "Modules" approach - it is the way non-IT-users understand Apps (I personally can live with both easily). To walk this way further I propose (like some others) to drop the "Data" layer of menues - this again is a pure technical category (as you store these infos in databases).
In your philosophy of "More", the "Tracks" and "POI" (the own ones, not the new DBs) are simply two items they want to deal with. What do you think ?
TXs
Michael

One thing that has been mentioned in a similar kind, I'd like to stress: "Data" is just an additional layer that does not add any value, nor is it intuitive. Why not offer "Tracks" and "POI" (the own ones, not the new DBs) as separate buttons ?
If you prefer, then in addition to "Data".
TXs
Michael

Well, did anybody COMPLAIN ??
And mind: there are different sizes of Androids, i.e. on a Galaxy Note the buttons in the old versions are already bigger than the new buttons on a 4" phone may be. In other words: on larger screens they get simply HUGE now. Simply give the Information section the same space as before, and divide the remaining space by the number of buttons chosen (typically between 3 and 6) by the USER (not you, not a shitstorm or vote, simply the USER ;-)
Cheers
Michael

I'm sorry guys, but I do not agree with any of suggested abilities. Understand that you use top label panel, but usability of buttons is by me much more important. So I suggest to reduce number of buttons in top panel and use main menu or right panel for most used functions

Done

Choice of UI theme is state of the art today - not the fancy stuff like BW or FW, just light and dark.
So it should not be a question of votes. If you count still: you have mine PRO UI theme choice.
Cheers
Michael

Michael,
Please vote here if you didn't do yet:
https://getsatisfaction.com/locus/topics/support_amoled
Thanks