Show Posts

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.

Messages - poutnikl

Pages: [1] 2 3 ... 26
Troubles & Questions / Re: Time at Arrival
« on: November 21, 2017, 07:16:34 »
[...] Currently it's used exponential filter that use latest +- 1 hour of average speed for every activity separately. [...]

I see. I may have confused it with the old time span for the navigation hints. They use rather seconds than minutes now, after our discussion,AFAIK. 

The solutions that perform all of a/route calculation, b/route following and c/ETA estimation have an advantage. As they can calculate a nominal route speed profile and provide very good ETA estimation based on nominal and real-time profile comparison.

Troubles & Questions / Re: Time at Arrival
« on: November 19, 2017, 14:15:30 »
Hmm. the ETA ( Estimated Time at/of Arrival ) topic was discussed in last about 2 years quite a lot, either here or on the Helpdesk.  You may guess the proper ETA calculation is very tricky.

As the first step you could provide the procedure to reproduce the above results.

As you may know, LocusMap does not have its own routing feature.  It relies on the online or offline 3rd party routing services. The ETA can be either calculated by the routing service and returned to the LocusMap ( not sure if this happens as I am not a developer ), either LocusMap has to calculate it somehow.  But LocusMap has no idea about the quality and speed of particular route segments.

One option is to use hard coded nominal values, as some navigation software use.  E.g. 4 km/h for pedestrians, 15 km/h for bicycles, 60 km/h for cars. In average, they are neither very bad,  neither very good. There are many cases with significant bias to both sides.

Another option is to calculate ETA from the real time motion and motion history. This gives usually better results than nominal values, but can provide extremely wrong values in some cases. And here come the tricky part.......

If one gives too high weight to immediate speed, or uses too short history record, the ETA fluctuates, depending on short time variability of the speed history.
If one gives too low weight to immediate speed, or uses too long history record, the ETA gets too big bias, depending on long term variability of the speed history.

As far as I know, LocusMap currently uses ETA calculation based on the mean speed in last 3 or 5 minutes, based on the sliding exponential averaging. This is valid for real time navigation. If it generates a GPX navigation track, it puts there, AFAIK, some formal and funny time stamps.

jak tak koukám,je to založeno na starém profilu. Nějak jsi zkombinoval pěší profil s cykloprofilem. Chybí tam definice proměnné onewaypenalty pro vyhodnocení jednosměrek..

Co jsem to tak porovnával se současnou Hiking templatou , tak se mi jako jediný podstatný rozdíl zdá Tvoje nastaveni Offroad factor na 1.0.  Takže by sis to tam mohl znova nastavit a měl bys to.

Další možnost je ve starém profilu vyhodit
Code: [Select]
assign isbadoneway = not equal onewaypenalty 0
assign isgoodoneway = if reversedirection=yes then oneway=-1
                      else if oneway= then junction=roundabout else oneway=yes|true|1

a nahradit
Code: [Select]
assign isbadoneway = 0
assign isgoodoneway = 0

Ale druhý způsob moc nedoporučuji.

Versions / Re: [APP] - version 3.25.+ ( 9. 8. 2017 )
« on: October 03, 2017, 11:53:15 »
Generally for me a NOGO is only needed for the life of the route. No longer. As my cycle touring is always to a new area.

I see. But imagine everyday bicycle commuting in big cities with regular municipal announcements about short and long term road closures. There is even Android application to monitor them for my country. They are often not updated in OSM, or with delays, or routers generally do not deal well with time restrictions.

I have a nogo folder in Locus and put their nogos there with target date in name, periodically purging them.

Versions / Re: [APP] - version 3.25.+ ( 9. 8. 2017 )
« on: October 03, 2017, 11:38:01 »
They should not be used as "negative viapoints/shapepoints".
I sometimes find nogo's very convenient for negative viapoints/shapepoints. Sometimes it is the fastest method for shaping my route.
I mean - description of what I want is easier by expressing what I want, not by what I do not want. If I would try to order my dinner by nogo approach.....

The admitted advantage of nogos for route shaping is that it bypasses eventual viapoint count restrictions. Personally I prefer to use the profile that follows my priorities and eventually I choose viapoints that I do want visit or go through.

It not at all about users should act this way, I am just describing my way. That is all.

Versions / Re: [APP] - version 3.25.+ ( 9. 8. 2017 )
« on: October 02, 2017, 21:16:46 »
IMHO when I use the clear route button if I have a pop up to choose to: clear all nogo/profile nogo/current visible nogo points or something similar should be helpful.
I used the nogo points to avoid some sections of a track for a hike but next time  I do not want the nogo still there and to give them all an expieration of a week is tedious.

I do not agree with Arndt - the BRouter author - on nogo usage philosophy. IMHO, nogo points should serve as really nogo points, permanent(e.g. really bad road or always traffic jams or whatever) or temporary ( e.g. road fixing).  They should not be used as "negative viapoints/shapepoints".

Versions / Re: [APP] - version 3.25.+ ( 9. 8. 2017 )
« on: October 02, 2017, 19:34:11 »
Perceptions of using NOGO points.
1) The "ignore NOGO" option should be added to the route planning menu. This option would also be saved with the route. The point is that NOGO will be used mainly where you can not go by car or bike. However, if I plan a hiking trail, I can go through the NOGO areas through the pavement.

Note that the original BRouter nogo system can activate nogos separately for each profile, resp. transportation mode. E.g. all nogos for cars, some for bikes, none for pedestrians.
And yes, they are considered globally, so not limited to a particular route.

Na OSM je to už opravené. Takže nezbývá než počkat na aktualizaci LoMaps.

Anebo si stáhnout mapu z, kde je updatují  cca každé 3-4 dny.

Versions / Re: [APP] - version 3.25.+ ( 9. 8. 2017 )
« on: September 27, 2017, 07:42:00 »
@Taras - I'm certainly not fixed on the term "Shaping" point. It is more meaningful & appeared on the face of it to be a more widely used term than "Definition" point. You & @0709 (& like the idea) observe a Shaping point is simply a silent, unnamed, unannounced Via point. So maybe this 3rd type of point doesn't even need a separate name? It's just an unnamed Via point? That could solve the next point...

In some sense, shaping points aka unnamed viapoints are just viapoints, to just go through.
In some sense, viapoints aka named viapoints are not really viapoints, but route POIs to visit..
Both are worthy to be kept when route is saved or exported.

[DE] - deutschsprachiger Forumsbereich / Re: BRouter Version 1.4.8
« on: September 26, 2017, 08:50:50 »
1.4.9? neueste Version ist 1.4.8?

Version 1.4.9 ist wohl noch nicht auf dem Google Play, sondern nur auf
Beachten Sie die @utack auf GitHub berichtet ein Bug, verursacht das Hängen der letzten benutzerdefinierten Fahrrad-Profile, die explizit verwendet Turn Restriktion Auswertung (standardmäßig OFF für Fahrrad). @Arndt fixiert für die nächste Version.

Version 1.4.9 is probably not on the Google Play yet, only at
Note the @utack on GitHub reported a bug, causing hanging of recent custom bicycle profiles, that explicitly uses turn restriction evaluation.( by default OFF for bicycle ). @Arndt fixed it for next version.

LoMaps jsou založené na mapových datech otevřeného  projektu    Tvůrci mapy nejsou uzavřená omezená skupina profesionálů, ale může se jím stát každý, kdo se zaregistruje a nastuduje, jak na to. Projekt obsahuje též nástroje, jak zamezit, aby tam někdo nědělal neplechu.

Pro začátečníka může být nejjednodušší použít online ID editor ( EDIT ).

Edit: pomoci může též

Navigation & Guidance / Re: Offline navigation - BRouter v1.2+
« on: September 24, 2017, 08:51:46 »
Hmm, I do not think it was discussed, aside of the nogo iniciative at Locus side and private discussion of LocusMap and BRouter developers. I do remember Arndt, the BRouter author, once mentioned he was working on the new kinematic routing model.

A big part of changes are rather BRouter internal things. For an end user, the important features are these:

- completely new kinematic routing for cars(car-fast, car-eco)(*). It looks like a big thing. This routing  does not use the costfactor, so It currently bypasses the profile developer effort based on costfactor calculation. The routing is tuned by the parameter of maximal target speed vmax(90 for eco, 160 for fast, probably 130 or 110 for non Germans ).It could be tweaked by changing of max default speed for highways classes to change priorities..  I see I will have to rename my car profiles to avoid confusion. Probably by adding P as Poutnik.

- compatibility with the new LocusMap nogo point interactive management   ( for now in Locus beta)

- 2 minor things for profile developers

(*) seems to me as optional, depending on presence of the kinematic model context line in a profile. So in my understanding, both new kinematic car profiles and my old car profiles should be, after renaming, usable side by side.

Navigation & Guidance / Re: Offline navigation - BRouter v1.2+
« on: September 23, 2017, 18:02:23 »
Published new BRouter release 1.4.9  -  may not be in Google Play yet.

(current revision, 24.09.2017)

    tweaked distance calculation
    new car profiles, kinematic model based
    basic travel-time/energy support
    modular cost models
    lookup extensions (+conrcete:lanes/plate code-side-hack)
    fix for interface provided nogos
    access to way-context vars from node-context
    removed size limit for encoded tags

[CZ&SK] - diskuze o Locusu / Re: Místo v telefonu
« on: September 15, 2017, 17:16:32 »
OK, beru zpet, chtel jsem rict, ze Locus umoznuje mit na karte vektorove a offline rastrove mapy, ne nutne ze je tam umi sam zapsat. Ja osobne stahuji ( vektorove ) mapy ( Paws, OpenandroMaps ) pres script na mem PC, a pak si je prekopiruji  synchronizaci pres lokalni WiFi.

[CZ&SK] - diskuze o Locusu / Re: Místo v telefonu
« on: September 15, 2017, 11:33:42 »
No, však on neříká, že 5 GB zabírají listingy.

Locus umožnuje vektorové a vlastně i rastrové offline mapy uložit na kartu. Co potřebuje v interní jsou cachované online mapy a některá metadata. Další možnost u Android  6+ je nakonfigurovat kartu jako interní úložiště.

Pages: [1] 2 3 ... 26