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 ... 26 27 [28] 29 30 ... 41
406
It seems the adaptive time constant  ( TC ) of the exponential filter is good choice for "hesitative adaption" in the early route stages and at the same time for fast adaption for the late route stages.

A good value seems to be TC = 1/5 of estimated remaining time.

Code: [Select]
TC = ( remaining_distance / avgspeed )  / 5
clipped between  100 and 1000 s like

Code: [Select]
TC = min( 1000, max(100, remaining_distance / avgspeed ))  / 5
alfa = 1 - 1 / TC

Code: [Select]
avgspeed(N) = alfa * avgspeed(n-1) + ( 1- alfa) * immediatespeed
can be written as well as

Code: [Select]
avgspeed(N) =  ((TC - 1) * avgspeed(n-1) +  immediatespeed )   / TC
--
for 0709 - context is there is no info about remaining route in advance but the distance. If there is such info, like highway class nominal speeds, or bicycle speed based on elevation profile, much better algorithms can be used.

407
There was added to the graph an adaptive exponential filter, with timeconstant = 1/5 of estimated remaining time.
While it is hasitating to adapt at first, it adapts fast at the end, combining advantages of both big and small constants.


408
I have emulated 60 km long near 1 h lasting real travelling by a  car from my home to a village house of my parents.
There is listed summary of speed profiles of particular route segments and related Excel graph.

There are listied graphs for time constants of the exponential filters 100 s ( alfa 0.99 ), 200 s ( 0.995 ) and 500 s ( 0.998 )

Right axis is for current avgspeed provided by the filter  ( solid lines )
Left axis is predicted ETA in form of number of seconds since departure.( dashed lines )
Horizontal axis is time since departure in seconds.

It seems longer constants - comparable with trip length have general advantage for ETA estimation,
while shorter constants ( much shorter than trip length ) may take advantage if last miles are very different then average..

An idea hit me about an adaptive time constant of the filter,
when the filter response would get faster with approaching the destination.

Like e.g.
timeconstant = (RemaindingDistance/avgspeed) / 5 = Remainingtime / 5
  ( initially 12 min for 1 h trip,  2 min for last 10 min )

alfa = 1 - 1 / timeconstant


409
Discussion/New features / Avg speed filters and ETA estimation
« on: June 15, 2016, 08:33:25 »
This thread is meant as more proper place on ongoing helpdesk discussion.
http://help.locusmap.eu/topic/frequency-of-navigation-hints-settings-confusion

410
[CZ&SK] - diskuze o Locusu / Re: Navádění
« on: June 14, 2016, 21:43:15 »
Muze byt i cesky, ale v EN si to precte vic lidi. Ano , help.locusmap.eu? Do sekce Ideas.

Potrebny pocet hlasu neni dany, autor hodnoti korme zajmu uzivatelu take jak se mu napad libi a jak snadno by se implementoval.  Posledni dobou si styska, ze dobrych napadu je prilis mnoho.

411
Příkazy fungují, jen nechápu, proč je na rovném úseku 1,5 km dlouhém 15 příkazů Pokračujte rovně , a stejně se zachová Brouter, ikdyž použiju tvůj neupravený profil Treking-poutnik.
Tady je odkaz na ten kousek trasy https://drive.google.com/file/d/0B1lVa1EYflOddUJNdUJFaGtUX2s/view?usp=drivesdk

Tak jsem se dival v Openstreetmap v editačním modu, a už je mi to jasné. BRouter se chová přesně tak, jak by podle současných algoritmů měl.

Tvuj GPX rika, ze jsi jel po highway=path ( pěšina ), podél highway=tertiary ( silnice třetí třídy ),
a pokyn Jed rovně byl vydan vzdy na spojce pěšiny a silnice pomocí highway=service

Priorita je  Tertiary > service > path

Pokyn jed rovne je vydan, pokud cesta rovne, kam mas jet, ma mensi prioritu nez alternatitivy.
Coz je tvuj pripad - Brouter se boj9, abys neodbocil na service, ktery ma vetsi prioritu.

Ale rekl bych ze Tvuj pripad vzajemne relace cest je velmi specificky a mne se neco podobneho jeste nestalo.
Holt jezdis po divnych usecich. :-)

Pravda je, ze Ty algoritmy maji jeste detske nemoci  a pilne se na nich pracuje.

Edit: Vznesl jsem na dane tema dotaz na Brouter  Google Group  ( EN ) , ze by se priority cest mely vyhodnocovat v  sirsim kontextu.

412
To je dost zvláštní, protože mně Locus/Brouter hlásí pokyny pouze na křižovatkách, a to jen některých, podle daných pravidel. Brouteru a profilu(priorita),   ne jako dřív v každé větší zatáčce.

Urcite pouzivas Compute Instructions / cesky ekvivalent ?

413
V tom případě měnit turnInstructionMode nemusíš.

ano, nejjednudussi je vyjit z trekking-poutnik a změnit tam MTB factor a smallpaved factor.
Kdyz se podíváš v https://github.com/poutnikl/trekking-poutnik na tabulku dole, tak MTB a MTB-light jsou vlastně Tvoje profily, updatované na poslední verzi.

Navigační instrukce Ti nefunguji ani pri jednom způsobu ( Locus API versus GPX import )?

V každém případě se vždy přesvědč, máš-li v Navigačním dialogu zapnuté Compute Instruction.

414
Zdá se v, pořádku, i když není nejnovější,  verze 2.4.11 by už s instrukcemi měla pracovat..

Jakým způsobem počítáš trasu ?
Přímo Locusem, BRouter aplikací nebo přes BRouter web ?

Pokud locusem, mas zapnuté Compute instructions ?
Pokud importujes trasu, mas zapnute slučování bodu s trasou ?

Pokud Nepouzívas BRouter s OSMAnd ani OruxMaps, doporučuji změnit
assign   turnInstructionMode  = 1  # 0=none, 1=auto-choose, 2=locus-style,..
na
assign   turnInstructionMode  = 2
aby se dal profil primo pouzit i pro BRouter-web

415
Já s velkou oblibou při porovnávání a šibování textu/kodu pouzivam programek WinMerge,
Třeba i pro import nových prvků implementovaných Arndtem do standardních profilů.

416
Ale co uděláš, když bude OSM správně ?

417
Trekking.brf má priority takto

Code: [Select]
assign priorityclassifier =

  if      ( highway=motorway                  ) then  30
  else if ( highway=motorway_link             ) then  29
  else if ( highway=trunk                     ) then  28
  else if ( highway=trunk_link                ) then  27
  else if ( highway=primary                   ) then  26
  else if ( highway=primary_link              ) then  25
  else if ( highway=secondary                 ) then  24
  else if ( highway=secondary_link            ) then  23
  else if ( highway=tertiary                  ) then  22
  else if ( highway=tertiary_link             ) then  21
  else if ( highway=unclassified              ) then  20
  else if ( highway=residential|living_street ) then  6
  else if ( highway=service                   ) then  6
  else if ( highway=cycleway                  ) then  6
  else if ( bicycle=designated                ) then  6
  else if ( highway=track                     ) then if tracktype=grade1 then 6 else 4
  else if ( highway=bridleway|road|path|footway ) then  4
  else if ( highway=steps                     ) then  2
  else if ( highway=pedestrian                ) then  2
  else 0

Učelová komunikace(service) a obytná zona(residental) mají stejnou prioritu 6. Ulice bude asi road s priority 4.
Takže podle algoritmu mlčel.

Řešení je použít v profilu více rozlišené priority.
A nejen podle highway, ale i kvality povrchu ( surface, tracktype, smoothness )





418
Taky jsem si všiml, že pokyny bude třeba trochu doladit. Třeba na křižovatce uprostřed obrázku mi Brouter s profilem treking.brf nenahlásil odbočení. Jel jsem od města po ulici "Nad predmestím" a ta zatáčí vpravo. Jenže rovně je stejně široká silnice a tak když mi navigace nic nenahlásila, pokračoval jsem rovně. Naopak, jak píše Dan, občas hlásí rovně, ale to mi nevadí. Někdy je lepší když má člověk "potvrzení" že jede správně. Je to jako u turistických značek, jak člověk dlouho žádnou nevidí, začíná být nervózní.

Rozhodující je, ne jak vypadají, ale co je v OSM.

Pokud se to v posledni verzi BRouteru  nezměnilo, pokyn Jed rovně je vydán,
pouze pokud má ta silnice nižší prioritu ( např 1. / 2. / 3. tridy / cesta),než ostatní volby, aby nezahlcoval desítkami pokynů.

Je možné, že podle OSM to BRouter vyhodnotil, že ta zatáčející je průběžná a hlavnější, a že by Tě nenapadlo odbočit=jet rovně.


419
Proč při vytváření trasy pomocí Brouteru, vytvořil Brouter tolik příkazů "rovně" za sebou na jednom km trasy? viz prtscr
http://i66.tinypic.com/29fe22v.jpg
http://i64.tinypic.com/1zn5zjt.png

Je možné, že je to proto, že nepoužíváš nejnovější BRouter 1.4.2, nebo že Tvoje profily nezohledňují syntaxi konfigurující nové navigační pokyny BRouteru ? Nejklépe přeinstalovat BRouter a použít aktuální standardní profily, anebo si ty moje odvodit z https://github.com/poutnikl/trekking-poutnik

Donedávna BRouter žádné takové pokyny nevytvářel, a Locus je na pořádání vytvořil podle tvaru trasy. Uřitečnost takových pokynů byla omezená, protože 95% z nich byla prostě jen zatáčka a žádná křižovatka. Locus byl tím pádem dost ukecaný.

Nyní Brouter pokyny vytváří podle křižovatek a definované vzájemné přiority cest. Vydá pokyn, pokud odbočka má stejnou nebo nižší prioritu než ostatní volby. Pokyn jet rovně vydá, pokud má cesta nižší prioritu než ta, co se stáčí.

420
Troubles & Questions / Re: Waypoint time stamp
« on: May 30, 2016, 07:52:50 »
Timestamps are not really needed for proper matching of hints and trackpoints, as they are redundant info even for multipass case. Coordinates and point order should be enough, if Locus uses pointers for both passed trackpoints and navigation points

Edit: If Locus is following the pointers above, no timestamp info is needed. If pointer info is destroyed for whatever reasons,  neither timestamp info helps, if we ended in ambiguous multipass part of the route. For non ambigious part, pointers can be easily reestablished without timestamps.

Timestamps would make sense if used with an added value of estimated point arrival ( relative to start ). For BRouter case, this can be done with the advantage of present elevation info.

Pages: 1 ... 26 27 [28] 29 30 ... 41