Messages

Myslíš stéblová metoda určování pozice ? Nahodit GPS bude asi rychlejší...
Bez GPS se emapa da tez pouzit. Oboji ma svoje vyhody a navzajem se doplnuji.

Standa tam jede taky, tak se třeba potkáte.

Zajimave je, ze M dual mi nekdy vydrzi navigovat hodiny, a nekdy se zakuckává už po 1-nekolika minutach, a to casto i na popredi pri zapnutem obrazovce, takže to nemusi byt jen diky agresivnimu powersaving modu.

Něco mi to jméno říká, nemá něco společného s vysokou školou? Já jel Cyklopouť zatím jen jednou a protože se jede po malých skupinkách, tak se s mnohými člověk vidí jen chvíli ráno a večer. Jaká byla cyklopouť? Příští rok by se měla zahraniční a česká varianta sloučit do jedné Santiago - Fatima, takže jestli pojedeš, tak se tam potkáme.

Standa - viz Soukroma zprava.
cyklopout byla bezva. 2x cca 1000m sjezdy, 4000 m převýšení ( Brouter filtered ascend ) na 320 km.
Ale byla to soukroma cyklopout, oficialni cyklopout se do Santiaga jede dle Standy v srpnu.

Omlouvám se za pozdní odpověď po dovolené - cyklopouť z Leonu do Santiaga. ( mimochodem neznáš Stanislava Trtka od Uh Brodu/Nivnice ? Jezdí s cyklopoute.cz uz 5 let a jel tam s námi. Pracuje v Brně).

Ona to není tak úplně chyba, jako záměr, který má někdy nežádoucí důsledky. Je to dáno parametrem turnInstructionCatchingRange. Struktury cest mensi nez jeho velikost se bere jako jediný uzel.
Jeho default hodnota je 40  ( metru ), můžes to snizit treba na 10-20

---context:global
....
assign   turnInstructionMode  =   1       # 0=none, 1=auto-choose, 2=locus-style, 3=osmand-style
assign   turnInstructionCatchingRange  20 # V1.8.5 / default=40, but foot paths may be more distingushed, especially in cities.

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 Expand

TC = ( remaining_distance / avgspeed )  / 5

clipped between  100 and 1000 s like

Code Select Expand

TC = min( 1000, max(100, remaining_distance / avgspeed ))  / 5

alfa = 1 - 1 / TC

Code Select Expand

avgspeed(N) = alfa * avgspeed(n-1) + ( 1- alfa) * immediatespeed

can be written as well as

Code Select Expand

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.

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.

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

This thread is meant as more proper place on ongoing helpdesk discussion.
http://help.locusmap.eu/topic/frequency-of-navigation-hints-settings-confusion

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.

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.

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 ?

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.

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

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ů.

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