Messages

ok skusim si teda stiahnut  inu mapu ale co, konkretne odporucas pre  Zahorie, aby bola podla moznosti co najpodrobnejsia a dobre navigovala pre turistiku a pre cyklo?

No, je to na hranicich CR a SR, tak asi CR a SR. Ktere mapy z LoMaps / Paws / OAM pouzijes zalezi na tobe, lisi se v detailech, licencnich podminkach a frekvenci updatu.
LoMaps jsou placene za kazdy update, updatoveny ctvrtletne ale zase poskytuji offline hledani adres a POIs.
OAM jsou zdarma, updatovany nejmene  mesicne, maji vyborny style Elevate pro vysokohorskou a MTB turistiku, pro Alpy skvele rozliseni vysek.
Paws jsou zdarma pro Cr , Sr a blizke okoli, updatovane kazdych par dni.

To je zvlastne, myslel som ked hlas Eliska  odporuca priamo Locus, tak ze  je pre nu vhodny. Co by si teda odporucal aky navigacny hlas nahrat,  myslis tento na google play: Hlas Vocalizer TTS (Slovenský) mam skusobnu verziu uz nahratu ale v Locuse mi ho neumoznuje vybrat, alebo poradis nieco ine?

No vsak, je vhodny. Ale Eliska nebo jakykoli jiny je pouze hlas. Sam o sobe nema s navigaci/navadenim nic spolecnoho. Je to pouze funkce Androidu umoznujici prevadet text na hlas. Zrovna tak se da pouzit na predcitani knih.

toto myslis pri navadeni, ze? Ak ano vcera som sa pokusil v navadeni, v nastaveniach  pomenit nejake parametry, screen poslem vecer

Ano, myslel jsem navadeni.

pri navadeni som sa dostal zatial len k tomu ze mi ukazuje supka kam mam ist, ziadne ine navadzanie, myslim zvukom negunguje , pri navigaci, ma naviguje hlasove velmi nepresne, ked zmenim smer vobec mi to neoznami, akurat vidim ze sa mi vzdialenost k bodu neodpocitava , ale pripocitava, to je asi tou mapou, ze?

V tom bude asi jadro pudla, ze ocekavas od hlasoveho navadeni neco jineho, nez nabizi. Jinak u navigace i navadeni vse zalezi na nastavenych parametrech. Bez nich je to tapani ve tme. Tez zalezi, je-li trasa "ridka" nebo "husta", a jaka je typicka vzdalenost bodu ve srovnani se vzdalenostnimi parametry.

S problémy a žádostí o podporu je nejlépe obracet se na http://help.locusmap.eu. Dále doporučuji neházet všechny problémy na jednu hromadu, která se pak obtížně rozebírá. Je lépe je oddělit do samostatných témat, nebo alespoň odstavců, aby bylo možno se každému dílčímu problému věnovat samostatně.

Výrazně, prosím, odlišuj, používáš-li zrovna funkci Navigovat nebo Navádět. U Navigace vždy uváděj jakou službu používáš.

Pro práci s navigací ( vypočítaná trase s navigačními instrukcemi )  je obvykle nejlépe používat vektorové mapy. Bud placené mapy Locusu LoMaps, nebo třeba mapy  PAWS nebo OpenAndroMaps. Rastrové mapy z MOBAC nemají vždy dostatečné rozlišení. Navíc, pokud nejsou založeny na OSM mapách, nemusí se s navigací shodnout, kde je nebo není cesta.

Mapou Slovenska v BRouteru zřejmě myslíš čtverec 5x5 zem. stupňů, který obsahuje navigační data i pro Slovensko.

Eliška není hlasová navigace, ale hlasový modul pro Android TTS , který se pouze stará o převod textové informace na hlas.

Jsi si jist, že se navigace nechová tak, jak ji máš nastavenou, aby se chovala ? Nejlépe, když detailně vypíšeš konfiguraci Tvého nastavení, nebo poskytneš snímky obrazovky, a detailně popíšeš, jak se chová.

S jízdními pruhy v lese si nedělej starosti, to je specialita navigace MapQuest, ona není na les moc zvyklá. Ber to jako "Drž se vlevo/vpravo". Locus pouze přebírá, co mu MapQuest řekne.

No však, pri cieli, jako poblíž cíle. Nevím jak Locus, ale třeba OSMAnd má 3-4 varianty, jak moc předem má cíl ohlásit.


Osobně používám Navigaci podél trasy, nikoli Navádění.. Způsob, jakým funguje navádění, možná nebude fungovat tak, jak očekáváš. Podle toho, jak tomu rozumím já ( ale na to jsou tu jiní experti ) se chová takto:

• Upozorní při udané vzdálenosti ns přiblížení k bodu trasy
• Upozorní při udané vzdálenosti změnu směru na příštím bodě
• Přepne se při udané vzdálenosti k bodu na další bod
• Upozorní při udané vzdálenosti od trasy na odchylku, ev. udá směr k trase.

Co z toho Ti nefunguje, a jak to máš nastavené ?
Navíc, může se stát , že se přepne na další bod dříve, než Tě na něj stihne upozornit, když Locusu řekneš, aby se tak choval.

Tak to asi nevím, jak Ti poradit, když to není reprodukovatelné...  Osobně jsem nikdy nepotřeboval předem extra spouštět BRouter, abych jej mohl použít v Locus.  Kdoví, jestli příčina neleží MIMO Locus a BRouter.

Je rozdil, jestli pouzivas stary zpusob s BRouter mode-profile mapovanim
nebo novy zpusob prime volby profilu v Locus ( Locus BRouter configurace vypnuta ), ?

BRouter pokud vím žádnou iniciaci nepotřebuje.
Jediné, co mě napadá je, jestli to závisí na zvolených bodech, nebo BRouter přeinstalovat.

Aktuální verze BRouteru je dobré sledovat na http://brouter.de/brouter/revisions.html,
tak je lze mit s predstihem oproti Google Play, kam navic prijdou jen Release verze.

Leda pak otevřít problem na http://help.locusmap.eu  pro Locus
eventualne.https://groups.google.com/forum/#!forum/osm-android-bikerouting
nebo https://github.com/abrensch/brouter/issues    pro BRouter ( EN, DE )
.

You should get does not mean you get :-)  For random placement of the lights, and for both directions simulataneously, it is near imposible to maintain green wave.

And even if it was possible, it cannot work simultaneusly for both straight ahead and turning directions.
Unfortunately, BRouter cannot detect your course at the traffic lights.

Imagine 2 otherwise comparable 15 km long primary roads. Once goes around the city, the other across the city with 10 traffic lights. You are cought by 3 of them, whaty costs you waiting, breaking and acceleration. Are you sure you do not prefer the former one ?

It is obvious that traffic light do not delay you always. But there is need to caunt with probability. As illustrative example, if it delays you e.g. 1 km ( you would be 1 km farther without it ) with probability 0.2, there is need to take as avg penalty 200 m.

There is another thing yet.

The supposed optimal route has 3 traffic signals nodes, while the tertiary alternative just one.They are penalized as causing time a/o money cost ( least by Fast, the most by Eco ). So the Eco profile is not really bad in trying to avoid them.

See v1.0.23 archives https://github.com/poutnikl/Car-Profile

See the new profile set based of template v2.5.5
https://github.com/poutnikl/Trekking-Poutnik

The above mentioned bug is fixed, and there is introduced new parameter

Code Select Expand

assign   StrictNOBicycleaccess  0 # 0 allows but penalizes foot only access / 1 forbides foot only access.

there is n ot yet an extra profile set to use the flag, will be introduced later.
It must be changed manually for now.

Ahoj Menione,

I have realized that the FastEco profile based on not yet published 1.0.23 already chooses the same route as the Fast one.
Only the Eco uses the small streets as FastEco of v1.0.22, as turn penalization increases Fast < FastEco < Eco.
But I do not recommend the Eco profile much.

Edit> Additionally, I have noticed there is low difference in max speed for the particular primary ( 50 km/h ) and tertiary ( 40, resp 30 ),so there is low pressure for preferring the primary.

Note that addressing your objection is very tricky. Profiles miss much of the context of reality,  OSM data or of your speed time profile. It is programmed to penalize  turns of fast roads more than turns of slow roads, as turns on fast roads cost more time and money. But it may not be always the case in the city. Particular scenarios can fool the profile logic.

Thank you, I understand.
On the other side, if you plan a mountain bike tour in the region, without having a map, that shows you the paths, but not the "forbidden" tag, you may be a bit disapointed at start.
Is it possible to create a profile, that considers this tag (analog to "no maut" or "no ferries")?

Sure, it is possible, as it is quite simple.
For now, you may tweak the profile code as below. Then bicycle=NO will be forbidden.

But, be aware of it, as you can be hunted 10 km for 300m of forbidden path.
It may as well make sense just to raise the penalty, rather then being forbidden absolutely.

Bear in mind the MTB usage is rather like "bending the trekking rod", and native MTB profiles may be better..
You may want to try the native MTB profile by Zossebart, that I share with his permission on my Github rep .
https://raw.githubusercontent.com/poutnikl/Brouter-profiles/master/mtb-normal.brf
Edit: Note that Zossebart marks it as very outdated, but has not published the update yet.

Code Select Expand

assign accesspenalty =
       if bikeaccess then 0
       else if footaccess then 4
       else 100000
to

Code Select Expand

assign accesspenalty =
       if bikeaccess then 0
       else if footaccess then 100000
       else 100000

Hi Jusc,

Yes, it is ( partially, as I have realized later) correct, as both the standard and my profiles do not consider a bicycle as a biker riding a bicycle.

They take a bicycle as a biker WITH bicycle. Leading a bicycle is a perfectly valid bicycle transportation mode, just slow. Such a way, where a riding a bicycle is forbidden, but pedestrians are allowed, the bicycle routing is still allowed.

Allowed, but with a penalty according to the speed ratio. A way segment with bicycle=NO is taken as if it was 5times longer.

Otherwise it could lead to serious not justified detours. Liker 600 m along the road network versus 15 m of a footway.

Special cases are addressed with flags allow_stairs usefule e.g. for handicaped bikers,  and in special profiles like recumbent/velomobile ones.

Edit: I have realized, that because of wrong evaluation order, profiles with positive MTB_factor  decrease the bicycle=NO penalty for way classes and surfaces preferred by MTB-like profiles.

Will be fixed in next profile release.

OK, so Locus scans each profile for exposed parameters & displays as list . This would explain the Locus delay in changes with the UI - reading/ writing the (pro)file. Clearly, absolute avoidance of unpaved roads is not desirable, and may result in huge detour, although it could be argued the user can also view the proposed route from each checkbox state and make own decision, but surely hint from user for increased cost to selection of unpaved roads would be nice, and operates with similar logic/ consistency to Wet Conditions.

AFAIK, Locus for now uses just a priori chosen set of exposed parameters, so it is not dynamic.
The user has wider options to choose profiles with predefined numeric parameters, or tweak the parameters directly if he wants. It provides much finer tuning of profile behaviour than flipping flags. It is like the continuous tuning of radio volume being better than High/Low volume switch.

There is missing TTS option in Settings - Guidance - Notification  Doc page
http://docs.locusmap.eu/doku.php?id=manual:user_guide:functions:guidance

3.18.9.4 beta: Locus/ BRouter Fast & Short car profiles have Unpaved checkbox, but Fast/ Cycle/ Walk profiles only have Wet Conditions checkbox. Unpaved checkbox is absolutely desirable for these latter 3 profiles too. And maybe Walk profile could use Wet Conditions checkbox. Why inconsistency?

Andrew, Locus GUI config for BRouter profiles can offer only parameters, that are exposed by the chosen profiles. Neither standard, neither my bike profiles offer absolute avoidance for unpaved roads like car profiles, for quite good reasons. You may want to stay with Fastbike profile, or my template e.g. with MTB_factor -2.0.

Walking in urban/near urban mixed surface network could make use of Wet Conditions, but generally, the parameter is probably less useful for hiking. See also https://github.com/poutnikl/Brouter-profiles/wiki/Iswet_flag. The parameter is exposed, so it can be used.

Jde to, ale ted otazka, co je u tebe spatne.....

Hlasova navigace ( vypocitani trasy pro 2-4 body ) např s online navigacni sluzbou Mapquest nebo OSRM Ti funguje ?
Hlasave navadeni ( vede o bodu k bodu, i mimo cesty ) s trasou vytvorenou primo v Locus Ti funguje ?

Jak přesně nefunguje ? Protože mně funguje....
Jaký profile, jaká vzdálenost ?
byl jsi nucený použít timefree vypocet ?