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 ... 33
1
Typické SRTM artefakty:

Městská zástavba
Les, hranice lesa
Úzké údolí, soutěsky
Blízkost řeky se strmými břehy
Mosty, Tunely ( pokud vím BRouter toto upravuje interpolací )


Sent from my Xiaomi MI A2 / Android 9, via Tapatalk


2
Implementoval jsem TooSteepUphill do Tveho profilu ( možná pridam do templaty 2.7 nebo 2.8, pokud se osvědčí )

Edit: můžeš přepínat pomocí Hills = 2 (původní ) a Hills = 6 ( TooSteepUphill )

Podstatné je,  že budeš muset experimentovat s parametry  níže, protože se to může a nekdy i bude bít s malými ale prudkými stoupáními vyskovych SRTM artefaktů.

Dole je výtah z parametrů, zkopirovany z prilozeneho profilu:

Například, pokud je použitý přílis nízky TooSteepPenaltybuffer  ( elevationpenaltybuffer ),
může profil preferovat cestu přes kopec, místo kolem řeky/zeleznice, protože u řeky/zeleznice jsou příkré artefakty, jak se SRTM ne a ne pořádne strefit do nadmořské výšky cesty.

Dole je link na ukázkový příklad  "Obrany to Bilovice at NE border of Brno, Czech Republic",
kde pokdu snizís parametr z 12 na 10 ( BRouter default je 5 ), tak Tě to požene přes kopec,
protože cesta podél řeky je  :příliš prudká".  Něco podobného může být v zástavbě.

Bude se muset zvolit kompromis mezi potlacenim artefaktu a nepotlačením realných, krátkých ale strmých stoupání.

Quote
# BEGIN  - Internal parareters for hills = 6 - experimental avoiding of too steep hills via strongly penalizing uphillcostfactor

# slope below this uphill limit ( % ) has no penalization

assign   TooSteepUphill         6.0 

# hilly penalization is done by uphillcostfactor and downhillcost, not by uphillcost.
# can be used optionally, but is rather overrun by the uphillcostfactor.

assign   TooSteepUphillCost     0.0

# Implemented as BRouter variable uphillcostfactor for uphill scope > TooSteepUphill + TooSteepbufferreduce                                     
# with the transient zone TooSteepUphill .. TooSteepUphill + TooSteepbufferreduce
# There is normal costfactor for  uphill scope <= TooSteepUphill
# and  costfactor = TooSteepCostFactor for uphill scope >= TooSteepUphill + TooSteepbufferreduce

assign   TooSteepCostFactor     200
                                 
# The width of the uphill scope transient zone                                       
assign   TooSteepbufferreduce   2.0

# Altitude buffer to catch steep SRTM artefacts
# It has to be high enough, otherwise it may suggest an over the hill route
# instead of a flat route along the river, with very steep SRTM artefacts,
# like the route From Obrany to Bilovice at NE border of Brno, Czech Republic
# if TooSteepPenaltybuffer  = only 10.0  ( BRouter default is 5.0 )
# http://brouter.de/brouter-web/#map=14/49.2412/16.6745/standard&lonlats=16.649287,49.227407;16.674995,49.245971

assign   TooSteepPenaltybuffer  12.0

# Altitude buffer for downhills, does not affect uphill penalization with zero uphillcost.
assign   TooSteepMaxbuffer      20.0

# END  - Internal parareters for hills = 6 - experimental avoiding of too steep hills via strongly penalizing uphillcostfactor

3
Tu část kódu co je v citaci rámečku mohu vložit nad část # bstart /global?

No, ne tak úplně.  Je tam obousměrná návaznost na zbytek profilu, musí se to sešít správně. Později se na to mrknu.

4
Díky moc, já na plánování v naprosté většině případů používám vlastní profil - přikládám. Je to už sice starší kousek, ale plánuje velmi vyváženě pro dálkové cykloturistické trasy. Pokud to neznamená velkou zajížďku tak se vyhýbá nezpevněným cestám i kopcům.Preferuje cyklostezky, ale už trochu méně cyklotrasy.

To je zajímavé, já si pamatuji, že jsem Ti tento profil vytvářel, a pak jsem myšlenky z něj použil pro template v2.7. Nedávno jsem jej hledal, ale nenašel.

Tehdy se Ti ale nakonec pro plánování tras cyklopoutí víc líbil výše uvedený,  založený na fastbike.

Takže ses k němu zase vrátil. :-) ( nebo používáš oba pro různé účely ? )

Quote
Myslíš, že by šel ten parametr na omezení stoupání vložit do něj?

Samozřejmě, že by šlo, klidně jej do toho profilu přenes.

Quote
Zkusil jsem ten Tebou přiložený profil na rovinnáté trase Veselí n. M. - Kroměříž a chová se divně. Všimni si jak na snímku ...16 zbytečně ignoruje cyklostezku podél vody a na snímku ...49 zase vede trasu po rozbité cestě lesem i když podél železnice vede naprosto po rovině pohodlná cyklostezka.

No, ono se očekává, že se profil bude  chovat s vysokými penalizacemi divně, a ještě divněji by se choval, kdy tam byl tvrdý zákaz.

Screenshoty tras mohou být zavádějící, důležitější jsou tabulky s hodnotami pro konkrétní úseky, pro trasu, kterou navrhuje profil, a pro trasu, kterou bys očekával.

Až tam se totiž pozná, odpovídají-li data z RD5 souborů  realitě, a jestli profil pracuje tak jak má, nebo ne.

Taky šlo jen o první nástřel, je potřeba hodnoty parametrů doladit, kompromis mezi vyhýbáním se nežádoucím cestám a nenecháním se zastrašit výškovým artefaktem nebo krátkým úsekem bez asfaltu.

Sent from my Xiaomi MI A2 / Android 9, via Tapatalk

5
Zkus profile   FB-LT-tertiaries-paved-notsteep  z přílohy.

Je postavený na původním Fastbike-lowtraffic-tertiaries, který používáš.

Úpravy:
  • Trochu  zpřísněná pravidla pro nezpevněné cesty.
  • Zvýšená penalizace nezpevněných a "nejistých" cest
  • Zvýšený práh penalizace uphillcutoff
  • Zrušena penalizace uphillcost -  kvůli značně zvýšenému uphillcutoff by BRouter mohl dělat umělé kličky, aby si snížil průměrné stoupání.
  • Implementovaný uphillcostfactor =  SteepHillsCostFactor  ( 200 ) pro stoupani větší než  TooSteepUphill   (7.0)


Patřičné konstanty jsou vypsané v úvodu profilu, pro případné experimentování v BRouter-web/LocusMap a v reále.

Záměrně jsem nepoužil natvrdo zákaz >7% a nezpevněných cest, jen vysokou penalizaci.

U stoupání je tam navíc problém, že se tam můžou dostat artefakty ze SRTM, třeba náhlý vestup výšky o 10-20 m kvůli lesu, strmým kopcům nebo vysokým stavbám.

Quote
assign   UnpavedCostfactor      50.0
assign   PavingUnsureCostfactor 8.0
assign   TooSteepUphill         7.0
assign   SteepHillsCostFactor   200  # Implemented as BRouter variable uphillcostfactor for uphill > TooSteepUphill

assign   validForBikes        1

# the elevation parameters

assign downhillcost switch consider_elevation 80 0
assign downhillcutoff 0.5
assign uphillcost 0
assign uphillcutoff TooSteepUphill

assign elevationpenaltybuffer  = 2.0
assign elevationmaxbuffer      = 10.0
assign elevationbufferreduce   = 3.0

6
 I confirm the Locus update for selected BRouter parameters in the release works, i.e.
assign  parameter = false # %parameter%
works as well as with " = 0 "

Sent from my Xiaomi MI A2 / Android 9, via Tapatalk


7
@john_percy   Try also lookups.dat file from the GitHub, the same folder as profiles. As I remember I had had the same error, until I updated the file some time ago.

Sent from my Xiaomi MI A2 / Android 9, via Tapatalk

8
@Žajdlík Josef  Takže když dáš vzdálenost pro přepočet trasy 100m, tak při 300m deviaci od původní trasy Locus toho vracení nechá, aspoň tak tomu rozumím.

Sent from my Xiaomi MI A2 / Android 9, via Tapatalk

9


Díky. Není to sice ideální, ale lepší než nic. Mnohem lepší by byla nastavitelná vzdálenost zákazu otočení v možnostech navigace.

Myslíš odchylka od trasy nebo ujetá vzdálenost po sjetí z trasy ? Protože to může být paralelní ulice/cesta pár set metrů bokem.



Sent from my Xiaomi MI A2 / Android 9, via Tapatalk


10
Zdravím nazpět.

To vůbec není otázkou profilů, ale Locusu samotného.

Nemá to konkrétní nastavení, jako vzdálenost od trasy pro upozornění sjetí z trasy, přepočítání trasy nebo přepnutí na navádění.

Menion, pokud jsem to správně pochopil, naprogramoval přepočítávání trasy ( pro prioritu trasy, nejsem si jist, jestli i pro prioritu bodu ), že Tě nejdřív 2x pobídne se vrátit ( pokud se mu zdá návrat lepší ), a napotřetí to vzdá a dynamicky návrat zakáže.

Pokud si pamatuji, tak určí nejbližší bod původní trasy a zkoumá, vychazi-li návrat na něj lépe kupředu nebo zpátky. Pokud zpátky, tak tak to na Tebe 2x zkusí, jestli to otočíš, a pak tam interně hodí nogo bod.

Takže to vlastně bude nepřímo souviset se vzdáleností pro varování/přepočet a s frekvencí opakování varování o sjetí z trasy.

Když je nastavíš nakrátko,  Locus se vykašle na návrat o něco dřív.

Matně si pamatuji, že někde je nastavené natvrdo opakování po 30s, možná je to zrovna tady. Takže možná "vzdálenost pro přepočet + 2x30s".

Jinak nezbývá než v Locus ručně přidat nogo na návratovou trasu.

@menion Můžeš upřesnit ?

Sent from my Xiaomi MI A2 / Android 9, via Tapatalk

11
[CZ&SK] - diskuze o Locusu / Re: Problemy s GPS na mobile
« on: October 02, 2019, 08:12:06 »
GPS mojí bývalé mašinky Sony Xperia M Dual s Android 4.3 zase po asi 3 letech pravidelně vytuhla asi 1 minutu po GPS fixu, který byl sám o sobě rychlý.

Tvůj problém může být kombinací drobné nekompatibility LineageOS / A9 s daným modelem a  stárnoucího hardwaru, který může být už "nahluchlý" a "unavený, když se zahřeje".

Sent from my Xiaomi MI A2 / Android 9, via Tapatalk


12
Troubles & Questions / BRouter profile %parameter% true/false values
« on: September 29, 2019, 23:20:53 »
Some time ago, there have been implemented syntax

assign parameter = 0/1 # %parameter%

for chosen set of parameters of my embedded car/bike/hiking profiles.

is_wet
avoid_toll
avoid_motorways
avoid_unpaved

It works well even for external BRouter profiles.

The problem is, Locus does not detect the parameter, if it's value is defined

assign parameter = false

instead of

assign parameter = 0

Would it be possible to extent Locus profile parsing analysis to Brouter values true/false, that were implemented later?

Current implementations of the new car profiles by Arndt, based on very good kinematic model, prefers true/false for logical values, even if Boolean type is not implemented yet.

BTW, I recommend these car profiles, instead of mine.

See also https://github.com/abrensch/brouter/issues/197


Sent from my Xiaomi MI A2 / Android 9, via Tapatalk

13
Another candidate is the Waymark v2a theme. It is together with Elevate
 invaluable for long distance bike trekking along international a/o national cycle route network.

As most themes render cycleroutes  too late and often do not distinguish well the route classes ( ICN,NCN,RCN,LCN).

E.g Native Locus hiking/bicycle touring theme shows routes at zoom 13+ what is too late for big picture with ICN or NCN only. Additionally, all have the same colour.

Elevate cycling renders ICN/NCN at Z8-9, other routes at Z12. Similar for Waymark theme.

Waymark theme has additionally a great feature to turn on/off route classes independently.


Sent from my Xiaomi MI A2 / Android 9, via Tapatalk

14
Versions / Re: [APP] - version 3.39.+ ( 25. 7. 2019 )
« on: September 26, 2019, 12:42:57 »
Just quick thoughts:

The only idea coming to my mind is error propagation via sums of variances ( squares of standard deviations ).

But to get a model how these propagate via Kalman filtering may be very challenging.

Some info could be extracted from Kalman filtre variance matrices.

Another aspect, that may nullify the above effort would be  nature of position errors.

They are not random either in time, either in space, but there is strong both space and time correlation of errors.

By other words, following a road, there may be e.g. for 10-15 seconds a systematic position bias few meters to the right, and after a short while, a systematic bias to the left. If these biases are long enough, Kalman filtering cannot say difference between the bias and true deviation, as it is designed against random variations.

A filter addressing biases would need a feedback from a real life, like systems evaluating position errors of known positions, what is out of ordinary GPS abilities.

Sent from my Xiaomi MI A2 / Android 9, via Tapatalk

15
Versions / Re: [APP] - version 3.39.+ ( 25. 7. 2019 )
« on: September 26, 2019, 07:47:12 »
@Žajdlík Josef
Perhaps, it may be related to the recent fixed issue of escaping the route planner if Locus was brought back by clicking on its icon, versus staying in route planner if Locus was restored from the list of recent applications.

Sent from my Xiaomi MI A2 / Android 9, via Tapatalk


Pages: [1] 2 3 ... 33