Messages

All the above implies the routing is able to assess the route about correctly, based on available OSM data. E.g. and just illustratively, it takes 3 min/km for one part on an easy road and 20 min/km for other part on a steep woody trail.

I repeat my comment about the extremalities. You do not really expect the planner would consider the muddiness, unless there is tag surface=mud. If you do not evaluate in advance yourself the ETA in extreme conditions would not match, is it yours fault when they do not match and you are surprised.

You would also use different profile configuration for short sportive rides and long trips or expeditions.
Thinking is required. ETA calculation is not magic, it is simple calculation, that can be easily fooled. If one does not count with it, it is his fault.

So I'm wondering if it makes sense to provide data that can be subject to such a high variation? IMHO wrong information is worse than no data. The ETA at this point only makes sense for road routes by bike or car, it makes no sense on foot and on paths.

It makes still sense to provide ETA, if you provide also information, what you can and should expect and the range of applicability. Applying it in extreme circumstances and expecting standard behaviour would be rather an extreme than standard state of mind.

I remember it was also discussed, not sure if implemented, that the "nominal" ETA, calculated at route planning, would be in real time updated by comparison of partial values of nominal versus real time for the passed part of the route. (whole or last x km/minutes ).

E.g. a route has estimated ETA in 100 minutes. After passing the first half ( by expected spent time ), i.e. with the nominal  ETA 50 minutes, you realize you have spent 55 minutes, i.e. 5 minutes more. So for the rest nominal 50 minutes, you should expect rather 50*55/50=55 minutes  as well. Or, it could be evaluated for the last nominal 10 minutes, instead of the whole 50 minutes. So 50*11/10=55 min.

@zossebard
The set o profiles we currently work with is and will be available here:
https://github.com/asamm/brouter/tree/asamm/locus-routing-profiles
Some of them are default profiles from parent brouter repository and we rather want to keep them as they are validated by the previous usage in the app. Some of them are by Poutnik. We also consider your mtb profiles, of course. The modifications we made so far are rather minor. Feedback and improvement are welcome, just let us keep in mind that this set should be a safe set of defaults for all users. Regarding all profile parameters: I think we got your point, Menion will do that.

Hmm, hmm.. Deriving LoMTB profile from my (to be experimental)Trekking-hilly-paths profile could be considered rather crazy. As I consider this my profile rather crazy myself, making it on demand of a "crazy" MTB user. It was not  really intended for wide use for possibly less experienced bikers. It would give good results for really hardcore up to crazy purposes, but far less than optimal ones for more reasonable or recreational ones.

I would rather call it LoMTBPlus or like that, and as LoMTB I would use MTB profile from Zossebart or my one.  All responsibility lays on the profile user and LocusMap developers. You have been warned. 

Edit: The similar is valid for Trekking-No-Flat profile, that is intended for the same purposes, but with a different approach.

I am afraid tweaking of foot profiles will not help in tweaking hiking/running ETA. ETA calculation for foot profiles is AFAIK hardcoded to BRouter, perhaps some variant of Naismith or Tobler formula.

You could experiment to pretend during running you are a bike, with some experimental tweaking of the to-be-for-bike parameters.

thats weird you don't have the roads at all. I know I draw them much thinner than Elevate theme but I want to also see the type of road on which the cycling road is on.

Elevate uses transparent color for very high zooms, I guess 13+, so you can see the type of the road. I have modded it to use the transparency much sooner. You can see the thin magenta/violet lines of regional/local cycleroutes on ( very downsized pictures due free version of Tapatalk ), that are transparent where Elevate have them thick and solid violet.

Using your today latest theme version, looking for the international cycleroute GWKMW ( Greenway Krakow Vienna ) along the Svitava river from Brno toward Adamov, its line and name appears at zoom level 14 on the Czech OpenAndroMap MFv4. It is quite strange.

Most of themes draw long distance cycleroutes since zoom 8-10.

See the forum discussion thread with the Elevate LS2 theme mod zipped XML on OpenAndroMaps forum.

Just for illustration. comparison with the Elevate theme, cycling,  mod LS2

Note that Cycling option was erroneously not chosen, so the theme works correctly.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

Hi,
How can I set up the ETA in the planner?

The ETA on the map using planner is not the same on the stat of the panel.

AFAIK, ETAs on the planner are those reported by BRouter according to its internal algorithm, affected by BRouter profile configuration of the Brouter profile kinematic model ( cars or recent ones for bikes ). 

Stats in the panel are calculated by Locus from its builtin activiity profiles for horizontal/vertical speed, according to the route altitude profile and chosen activity, independently on BRouter.

IMHO, both have their place, but perhaps the user could choose either of them as the planner default.

Using a brouter profile for ETA has an advantage - when using an external profile - that one can tune the profile according to his physical conditions or intended effort. E.g. you can set the biker's steady mechanical power, tyre rolling resistance, aerodynamical drag or the total bike mass. It becomes handy for planning long distance trips/expeditions, where a bike is heavy and affordable mean sustained power is rather low.

Most of these parameters can be well estimated but the power. My advice here is to tune the estimated mean power up/down, until its prediction for the relevant scenario matches the reality. E.g. I use for myself for 4+ hours trips 85 Watts.

Just the clarification, they are not cycling roads, they are  just  OSM cycleroute waymarking, similar like marking of hiking routes by the Czech tourist association KČT, but more hierarchical.

International cycling network ( See e.g. Eurovelo routes ).
https://wiki.openstreetmap.org/wiki/Tag:network%3Dicn

National cycling network
https://wiki.openstreetmap.org/wiki/Tag:network%3Dncn

Regional cycling network
https://wiki.openstreetmap.org/wiki/Tag:network%3Drcn

Local cycling network
https://wiki.openstreetmap.org/wiki/Tag:network%3Dlcn

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

I generally like your theme very much, and also those similar to one used by mapy.cz, as it is  great for hiking with Check waymark specifics. It is great to have it for MFv4 maps.

But there is one exception they all share, but significant one, for medium/long distance bicycle route planning.

Marking of cycleroutes appear and/or is well noticeable too late at high zooms. Distinguishing of route classes ( Longe discance ICN, NCN and short distance RCN, LCN) and listing their numbers/names  is rather shy.

Good thing is the theme v4 way of "inline naming", similar as in Voluntary or my Elevate mod for cycling, borrowing code from Voluntary"

But there is no universal theme and one can choose his number one for each purpose.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

@martin - can you please explain the difference/ advantages of your theme compared to other existing themes?

It reminds me UniGCcz theme for MFv3 maps from PAWS site.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

Where routes profile "river"?

As the names gives the hint, it routes along  OSM mapped waterways. But it is rather experimental and cannot be used for serious navigation in sense of desired navigation line.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

Navíc hodně pomáhá, že nové Androidy mají vyhledávání v nastaveních, což hledaní toho pravého místa hodně ulehčuje.

This probably applies to both LM3+4, but  I mostly use LM4 as I got used to it.....

I have set ON the map scale switch in Settings/Maps/Auxiliary graphics.

The scale is displayed on the main map screen, but not during navigation, where I often miss that. Should not navigation screen honor the settings as well ?

I remember there was a similar issue with the planner screen in past. The scale was on the bottom, in contrary to the main screen, and there it was covered by the stats bar.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

[@poutnikl]

@poutnikl
... I personally prefer to download less data & spend a little more time by merging than the opposite.

I cannot agree more.



Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

As far as I known from the client side experience, Arndt probably chose good time threshold 7 days, having updates daily 1-7 days old.

As on client side, processing of older incremental data can be  slower than downloading the full file even at throttled speed of BRouter application.( even on Xiaomi MI A2 6 GB RAM and 8 cores.)

But this processing speed issue is rather inconvenience  solely of the BRouter application, than must be running foreground with display on. ( my script can run on background )

The server side optimum may be a different case, though.

I suppose there will be nonWiFi download limitation/warning.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk