Messages

Well, calculation works depending on used and available setting.

Edit - All the thing has 2 aspects
1/ How to get to some point, Navigation calculates the route, Guidance aims there just by straight line.
2/ which point it tries to reach - it mostly depends on seting how to behave if you are off the track more than a threshold distance. Strict route following tries to pass every point of preprepared route.

In the PRO - if recalculation is activated and if you left the route
it recalculates route to final point or next via point in case of point priority,
or it recalculates route to reach the route again, if route priority is selected.

You can - in both navigation and Guidance - use in advanced settings Stract navigation along the route.

Hmm, I forgot it is in PRO version only. But I suppose the whol efeature of route recalculation is available in PRO only.

If you use a dense, generated route file, than try to use Guidance, instead of Navigation.
Navigation uses realtime routing, while Guidance uses point to point approach.
I guess Navigation may try to lead you by route it has calculated, regardless of provided route.

Chck also if you really choose navigation along route, and not just to Final point - but I guess you did.

Check if you have in Navigation settings - Automatic recalculation - Point priority,
and if yes, try to change it to Route priority.

Note that for the basic support there is dedicated Helpdesk forum   http://help.locusmap.eu

I see. It is known that not all elevation data are SRTM based, therefore thanks for explanation.

it's a different source, a 10m grid (just see my attached image in the first post - it's a comparison between my sources and the ones you posted)

my question is:
2. I can apparently export it in SRTM 1" and 3" .hgt files which makes me wonder if this reduces that resolution or if it keeps it?

That is strange, as 1" and 3" are 30 and 90m grid, respectively.  ( 1' is 1 nautical mile 1852 m, 1800/60  = 30 )

The known problem with SRTM artefacts remain ( woods, narrow valleys, urban canyons, rivers, bridges)
as reportedly tested by Brouter author, they have just better details.

Jaká hodnota orientačního filtru je v nastaveni senzoru ?

Zkus do datove slozky Locus - data - srtm  stahnout a rozbalit zazipovane soubory vysek  *.hgt
z http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm

Hlavně je třeba ctít zásadu OSM, aby tagy odpovídaly reálnému stavu a nikoli aby se navigace chovala tak, jak chceme.
muzes tam dat
surface=mud tracktype=grade5
a ja zkusím dat vysokpu penaltu pro iswet.

Problém má dvě části :
1/ Jak to dostat do OSM

Přiznávám, že nejsem zkušený OSM tagger.
Mrkni sem, https://wiki.openstreetmap.org/wiki/Cs:Conditional_restrictions   
na obecnou syntax OSM tagů a Na Podminka-stav silnice.  Melo by to jít

<typ omezení>[:<způsob dopravy>][:<směr>]:conditional   = <hodnota omezení> @ <podmínka>[;<hodnota omezení> @ <podmínka>]

Ve značkách access, které se omezují na určitý způsob dopravy se typ omezení access: obvykle vynechává.

<režim dopravy>[:<směr>]:conditional
  = <hodnota omezení> @ <podmínka>[;<hodnota omezení> @ <podmínka>]


Edit: Může tam být ale háček, že správci OSM mohu požadovat, aby to bylo založeno na oficiálním omezení,
a nikoli na subjevním - jakkoliv praktickém - hodnocení.( tagování pro navigaci ). Najdou se lidé, kteří by se hádali, je-li to průchozí nebo průjezdné...Třeba maxspeed:wet = 60 na zakladě značky "60" s tabulkou "za mokra" a ne na rozumovem závěru, že "při dešti tam nejezděte vic jak 60kou" . Zákaz vstupu / vjezdu na kole zamokra tam není, a Conditional restrictions jsou myšlena jako podmíněná omezení, nikoliv podminena doporučení....

2/ Jak to dostat do Brouteru

Tady může být problém - možná dočasný - protože Brouter do svých souborů RD5 neexporuje automaticky všechny OSM tagy týkající se cest, kvůli designu formatu dat. Tagy nebo jejich hodnoty pouzivane velmi zridka tam nemusi byt, zvlast pokud to je dabelska kombinace jako výše.   Viz tez http://brouter.de/brouter/profiles2/lookups.dat

Soucasny workaround by mohl byt, u kola si pohrat s MTB faktorem., nebo vyhledově implementovat do profilu "silu zamokra". to by pak ale platilo plošně pro včechny cesty daného druhu.

Ja se pridavam ke hlasum po funkcnosti i bez GPS. Myslim, ze lokalizace je uzitecna pro OutDoor stejne jako InDoor. Treba v pripade, ze pratele s koly ci bezkami zalezli do hospudky, kde je wifi ale bez GPS signalu.

Další možnost je vygenerovat GPX trasu znovu z CSV souboru a s nav. pokyny.

Ta by ale byla mnohem ridší než původní GPX ,
takže by byla pouzitelna jen pro navigaci podel GPX, pro navadeni jen s obtizemi.

Co vím od autora Brouteru, tak výhledově s generováním navigačních příkazů počítá, ale kdy se jich dočkáme se zatím neví. Profil sám o sobě je t.č. vygenerovat nemůže.

Co by šlo udělat už teĎ ( ale chtelo by to hodně chytrou hlavu ) je napsat externi utilitu, možná v Excelu chytre VBA makro, která by navigacni prikazy nastrkala do GPX souboru dodatecne, pokud to pak Locus umi pouzit.

Utilitka by vyhodnotila 2 soubory vygenerovaní Brouter Webem: 1/standardní Brouter GPX route ( interne track )  2/CSV soubor, popisujici jednotlive OSM segmenty  cesty. Jednotlive souřadnice GPX route by se porovnaly se souradnicemi v CSV, nejsou-li nahodou hranicnim bodem segmentu. Pokud ano vlozil by se navigační pokyn.

Myslím ale, že konkrétní označení cesty neni v RD5 souborech Brouteru k dispozici, bylo by to spis oznaceni typu cysty, resp tridy cyklostezky, ale uz ne jejiho cisla nebo nazvu.

http://brouter.de/brouter/profiles2/lookups.dat

Viz tez http://help.locusmap.eu/topic/dopln%C4%9Bn%C3%AD-pokyn%C5%AF-navigace-o-zna%C4%8Den%C3%AD-stezek-a-silnic

Já jsem neupravil původní profil, já jsem upravil šablonu profilu, která je ve vývoji. Takže musíš počítat s tím, že se může kdykoliv překopat..     Změna se týká tématu, o kterém jsme se bavili - experimentalní konstantní posun uphillcostfactor/downhillcostfactor vuci costfactor, a to pomoci uphillCFshift / downhillCFshift

Code Select Expand

  assign uphillcostfactor =
max 1.0 
add uphillCFshift
add rawcostfactor2
<promenliva cast>

  assign downhillcostfactor =
max 1.0
add downhillCFshift
add rawcostfactor2
<promenliva cast>


[- když nastavím 0, tak se sjezdy nebudou vůbec omezovat?]

#ekvivalent hills 1 srazeny MTB factorem 2.0             
assign   downhillcost  20 - když nastavím 0, tak se sjezdy nebudou vůbec omezovat?     
    Nebudou ( kromě rozdilů mezi costfactor a downhillcostfactor
assign   uphillcost    23   - když nastavím vyšší číslo, tak se budou více eliminovat výjezdy?
    Budou
assign   uphillcutoff    3.0 tohle je tolerance, která se odečítá od skutečného stoupání (nebo klesání u downhillcutoff)?
    Ano. a zaroven je to tolerance, ve ktere se priority pocitaji podle costfactor, a ne podle uphillcostfactor/downhillcostfactor  ( nasobek, kterym se prodluzuje fyzicka delka trasy )
assign   downhillcutoff  1.5

Code Select Expand

Pocitana delka = fyzicka delka * costfactor
pro rovinu

Code Select Expand

Pocitana delka = fyzicka delka * [ uphillcostfactor  +  ( Stoupani% - uphillcutoff ) /100 * uphillcost ]
pro stoupani

Code Select Expand

Pocitana delka = fyzicka delka * [downhillcostfactor  +  ( Klesani% - downhillcutoff ) /100 * downhillcost ]
pro klesani

Stoupani/klesani neni dano samotnou OSm mapou, ale vyskovymi radarovymi terennimi daty, ktera jsou soucasti Brouter souboru RD5. Stoupani samotne cesty nekdy byva v mape zmineno jako incline=* , je ale velmi hrube, a musi se zpracovavat v ramci costfactoru. V mych profilech zohledneno neni, protože mimo MTB nema moc vyznam a není časté.

Co bych Ti mozna poradil, je nahradit

Code Select Expand


assign   uphillcostvalue switch equal hills 1 70
                                switch equal hills 2 80
                                switch equal hills 3 60
                                0
assign   uphillcutoffvalue switch equal hills 1 3.0
                                switch equal hills 2 1.0
                                switch equal hills 3 0.5
                                1.5
assign   downhillcutoffvalue    switch equal hills 1 1.5
                                switch equal hills 2 0.5
                                switch equal hills 3 1.5
                                1.5
assign   downhillcostvalue      switch equal hills 1 60
                                switch equal hills 2 80
                                switch equal hills 3  0
                                60 


a

Code Select Expand


assign   MTB_hillcostfactor   multiply -0.3333 ( max -3.0 ( multiply -1.0 ( max 0.0 MTB_factor ) ) )
                  # for MTBfactor <=0 is 0, for MTBfactor >=3 is 1, otherwise 0.3333 * MTBfactor
      # progressively decreases hillcosts to be 0.0 at MTB_factor = 3.0
      # if MTB_factor = 1 , then downhillcost decreases e.g. from 60 to 40
 
assign   downhillcost if ( and consider_elevation set_downhill_cost )  then
        ( multiply ( add 1.0 ( multiply MTB_hillcostfactor -1.0 ) ) downhillcostvalue ) else 0

assign   uphillcost   if ( and consider_elevation set_uphill_cost   )  then
        ( multiply ( add 1.0 ( multiply MTB_hillcostfactor -1.0 ) ) uphillcostvalue ) else 0

assign   uphillcutoff    if ( and consider_elevation set_uphill_cost )   then    uphillcutoffvalue else 1.5
assign   downhillcutoff  if ( and consider_elevation set_downhill_cost ) then  downhillcutoffvalue else 1.5


primo pomoci kodu nize, a laborovat primo s konecnymi cisly.
Tak budes mit penalizaci kopcu nezavislou na MTB faktoru.

Code Select Expand


#ekvivalent hills 1 srazeny MTB factorem 2.0  
assign   downhillcost  20
assign   uphillcost    23
assign   uphillcutoff    3.0
assign   downhillcutoff  1.5