Share your profiles

瀏覽次數:336 次
跳到第一則未讀訊息

Jozef Matejička

未讀,
2014年6月13日 凌晨2:53:042014/6/13
收件者:osm-android...@googlegroups.com
Hi!

It might be good idea to share your profiles.

Here is mine.

It has for me good balance of using cycleways and save routes in cities, and normal roads for fast&comfortable road rural travel.

I cycle recumbent highracer.

It is modified velomobiel forum profile.
recumbent.brf

Kilian

未讀,
2014年8月15日 清晨7:50:032014/8/15
收件者:osm-android...@googlegroups.com
Hi,

I share my profile for walking.

In contrast to the profile 'shortest' it disadvantages big streets and prefers paths and footways.

I would be happy to get feedback or improvements.



Greetings from Germany

Kilian
walking.brf

abre...@googlemail.com

未讀,
2014年8月16日 下午3:09:392014/8/16
收件者:osm-android...@googlegroups.com


Am Freitag, 15. August 2014 13:50:03 UTC+2 schrieb Kilian:
 
I share my profile for walking.

In contrast to the profile 'shortest' it disadvantages big streets and prefers paths and footways.

I would be happy to get feedback or improvements.


I would really appreciate somebody developing a good hiking profile. That should probably be based on the new versions lookup-table, where the hiking relations are available.

I had a look at your version. Some issues I noticed: It seems incomplete in the access rules (avoiding access no/private on nodes, but not on ways?). The elevation cost for a walking profile I would expect to be lower than the downhillcost=60 from the bikers profiles.Costfactor 20 on primary roads I think is too high.

And a noticed a technical problem: by starting the costfactor term with:

assign costfactor
  add switch foot 1 1.1

and then continue to add at least another "1", your costfactor is at least 2. But for efficient calculation, the costfactor should be close to 1 for the type of way you are looking for, otherwise the processing times for large distances go up.

So to make a pure technical adjustment for that problem, you could divide all numbers by 2, including the downhillcost and you should still get the same results. (That relates my above remark on the downhillcost...)

regards, Arndt

Kilian

未讀,
2014年8月16日 下午5:16:392014/8/16
收件者:osm-android...@googlegroups.com
OK, thank you for your feedback. In the next two weeks I haven't time to improve the profile, but then I will do that.



Greetings,

Kilian

Poutnik Fornntp

未讀,
2014年8月17日 凌晨2:17:442014/8/17
收件者:osm-android...@googlegroups.com
And a noticed a technical problem: by starting the costfactor term with:

assign costfactor
  add switch foot 1 1.1

and then continue to add at least another "1", your costfactor is at least 2. But for efficient calculation, the costfactor should be close to 1 for the type of way you are looking for, otherwise the processing times for large distances go up.

If I would like by a dirty trick involve for some roads route prioritization, instead of penalty,
would be possible to set baseline cost factor e.g. to 2, with prioritized ways with cost in interval 1..2,
and to use pass1parameter >2 and pass2parameter=2 ?

Would it break routing algorithm, or just make it time inefficient ?

You guess well, route time optimization attempts.

E.g. current trekking/fastbike profiles with 1.5/60 downhill paramaters
would prefer

           18 km road with 1.5% descend - cost 18
to
           10 km road with 3% descend - cost 19

I want to give 3% descend road lower cost than 1.5% descend , with lower cost than for flat road.
This is not possible for baseline cost 1.0








Poutnik Fornntp

未讀,
2014年9月7日 清晨6:24:212014/9/7
收件者:osm-android...@googlegroups.com
I have realized that  avoid_unsafe  with decreased unsafe penalty ( I use 0.8 instead of 2 ) + ignore_cycleroutes
is interesting alternative to default trekking profile

It often founds general ways not marked as cycleroutes, but suitable for trekking. While still avoiding traffic, it decreases rather aggressive road discrimination of default avoid_unsave.
Default avoid_unsave may try route rather along circle instead across its diameter.

I am currently using atteched customizing trekking profile template, that I set to be user flag values driven.  I suppose flags may be added later.
Trekking-custom.brf

Zossebart

未讀,
2015年1月11日 中午12:02:252015/1/11
收件者:osm-android...@googlegroups.com
Hi,

attached is my attempt on a mountainbike profile. I tuned it to my own needs (tours in the low mountain range). I have no experience in high (alpine) mountain ranges, so it might not be suitable for this kind of terrain.

It tries to avoid height-metres to a certain degree and favour trails (paths) downhills. At the opposite, it avoids paths for uphills. It also avoids major roads, which sometimes leads to a zigzag-route but is ok for me (i hate interfacing with cars on a mountainbike tour). The penalty for going uphill on major roads is reduced by a certain factor, if the road has a cycleway or sidewalk.
I tried to make some of the parameters easily modifieable using variables on top of the profile.

I plan to develop a "mtb-hard" version based on this profile with (among other things) less height-metres avoiding and more aggressive downhill trail favouring.

Regards,
Zossebart
mtb-normal.brf

Zossebart

未讀,
2015年1月11日 中午12:10:132015/1/11
收件者:osm-android...@googlegroups.com
Sorry, I forgot to mention that the mtb-normal profile is only useable with minor version 3 (or higher) of the lookup table. This is currently not available in the packages or PlayStore versions of brouter. So please use the current github-version of lookups.dat and the latest routing files.

See https://groups.google.com/forum/#!topic/osm-android-bikerouting/hVRgvEjYd_Y
回覆所有人
回覆作者
轉寄
0 則新訊息