considering elevation on a way-basis

[Zossebart]

Hi,

first of all, thanks again for this great app!

I'm trying to create a routing profile for mountainbikes right now.  This works very great already. However, sometimes the routes are not quite perfect for me (or mountainbikers in general). The problem is, that mountainbikers like to ride small paths ('singletrails') downhill, but most of the time hate to go such paths uphill. Uphill, minor roads or tracks are often preferred.

As the elevation parameters of brouter are global, it is not possible to create a routing profile that avoids uphills on specific way-types, but adds no penalty for riding them downhill.
Thankfully, brouter is on github now. Therefore, I cloned it and 'hacked' this behaviour by myself for testing purposes. I added the parameter 'uphillcostfactor' in the way-context, as well as some code to incorporate it in the routing-algorithm.
This seems to work very well. Now the router adds a penalty for going up a highway=path (for example), but routes through it when going downhill. The routes look most of the time perfect for me now, especially in mountain regions.
For completeness, the same could be implemented for downhills (e.g. 'downhillcostfactor'.)

However, I think the whole thing possibly demands more memory, as well as more processing time. So I'm not shure if it should be included in the "official" brouter app. After all, it accounts for a very specific need of mountainbikers, but should not be necessary for other bikers at all.

Any opinions?

Greatings,
zossebart

[Volker]

Hi

I'm working on a profile for fast velomobiles. Downhill you easiely get speeds from 60 up to 100 kilometers per hour. With such speeds primary roads are good but tracks are bad. Uphill with speeds like a normal bike you don't like primary roads.

So I'm intrested in elvation based way penalty too.

Greetings,
Volker

[abre...@googlemail.com]

Hi,

and sorry for answering late.

Yes I also know the requirement, at least from the motivation mentioned by Volker (searching fast surfaces when going downhill), but the MTB case is of course the same problem, just with different preferences.

There are 2 pitfalls where you have to be careful when implementing this:

- if you extend the context for evaluating the profile-expressions, you must make sure to also feed this additional context into the crc32-calculation for the hach-cache within BExpressionContext, otherwise you would break this cache. This is no problem when adding just 2 more bits to the context (is-uphill/ is-downhill), but it would be a problem when adding a continues variable, because this would lowe the cache-hit-rate too much, leading to a performance problem.

- the other thing to consider is the concept on how to detect uphill and downhill in the presence of SRTM-elevation-noise. The simple approach of just looking at ths sign of "delta(elevation)" would lead to random signals distorting the routing in flat regions. Probably not a problem for the MTB-case (where there is no fkat country),  but in general it needs a concept that:

• is invariant against elevation noise in flat regions
• is invariant against dividing a way section into two by adding an intermediate point

I would appreciate a pull request on github to add that, and of course we could review that together to ensure the above  features.

regards, Arndt

[Volker]

Hi,

I think "is-uphill" and "is-downhill" in the waysection with your 10 meters filter and the cutoff would be good enough for my purpose. Eventually different cutoff parameters and elevation filter value for the waysection could be usefull. A continues variable is in my opinion on this elevation data no use. The irregularaties can be handled by the turncost value.

Regards, Volker

[Zossebart]

Hi,

sorry for the late answer, but I was very very busy with other things in the last few weeks.

As I mentioned, I quickly hacked the functionality into the existing code for evaluation purposes. 

I have to look into the hach-cache you mentioned, because I think I haven't considered this yet. I also think, only simple is-uphill/is-downhill bits are needed.

For uphill/downhill detection I simply reused the values calculated for the global elevation penalty. I think you already accounted for SRTM-noise there?

I will try to complete the implmentation considering your tips and issue a pull request when done. However, I don't know when I will have time for this, because the weather is already great outside, and I'm getting a new MTB this week :-)

Regards,

zossebart

[Zossebart]

Hi,

after a long time (with lots of nice mtb tours), I recently had some spare hours to look into this topic again.
First, I fetched the current brouter source from GitHub (v 1.0.3). However, I had problems building the brouter android app. The other tools built without issues, but the android app failed due to some error with the maven android plugin. Eventually, I gave up on this and worked with the brouter-server for now.

Looking into the source, I discovered that the tag-specific uphill/downhill costfactors were added by Arndt just one or two days before I fetched the new code! Nice!
Since the parameters in the profile are named exactly like the ones I used in my hack, I just had to do minor adjustments to my mtb profile (mainly to account for the new profile format) to test the feature.
After some tweaking, the server returns almost the same mtb routes as with my hack some months ago (btw.: the new brouter-web with profiles upload feature was very helpful for testing).

Unfortunately, I can not test it on my phone right now, as the android app build fails on my machine and the current official brouter version (v1.0.2) does not include the feature.
When is the release of v1.0.3 android app planned? I hope I can test the new version on my phone before winter :-)

Again, thanks for the great app!

Regards,
zossebart

[Volker]

Hi,

there are also new parameters in context:global:

elevationmaxbuffer

This is the maximum size of the elevationbuffer in meters. Everything that doesn't fit in this buffer gets penalized. If not set the value is 10, exactly as in the previous versions.

elevationpenaltybuffer

If the elevationbuffer exceeds the elevationpenaltybuffer the waysegment is recognized as uphill or downhill. By default the value is set to 5 meters.

elevationbufferreduce

With this parameter set, the elevationbuffer gets an additional reduction of this percentage (of the distance) if it is above the elevationpenaltybuffer limit. This reduction gets penalized for the amount the elevationbuffer is reduced. By default the value is set to 0 to get an identical behavior to the previous versions.

In my velomobil profile with low cutoffs (and high elevationcosts) I set:

assign elevationpenaltybuffer 8
assign elevationmaxbuffer 13
assign elevationbufferreduce 0.3

This gives for me similar elevationcosts and good results for the uphill and downhill recognition of the segments.

Regards, Volker

[Zossebart]

Hi,

thanks for your detailed description of the global parameters.

If my understanding is right, elevationmaxbuffer lets you configure the hysteresis for the filtering of SRTM noise (which was until now hardcoded to 10m)?

elevationpenaltybuffer is a cutoff to avoid penalties for small elevations (smaller than this value)?

I do not understand the meaning of the elevationbufferreduce parameter right now. What would be the practical implications for setting this parameter >0?

At the moment, I have set the new global parameters to the following values:

assign elevationpenaltybuffer 10
assign elevationmaxbuffer 10
assign elevationbufferreduce 0

[abre...@googlemail.com]

Hi,

and sorry for being lazy on deploying this patch. It's actually Volker's patch, I just added the defaults to get the uphill/downhill costfactors functional without tweaking Volker's new parameters.

So the defaults are (see RoutingContext.java)

  assign elevationpenaltybuffer 5

  assign elevationmaxbuffer 10
  assign elevationbufferreduce 0

that means everything is as before (10m hysteresis), but if if the uphill-buffer is above 5, then "uphillcostfactor" is used instead of "costfactor" if it has a value != 0, same for the downhill logic.

So what you quoted above (elevationpenaltybuffer = 10) disables the new feature.

I will try to deploy the 1.0.3 version shortly at least on my server (not on Play). I plan to spend some work again on that subject on Karlsruhe OSM hack weekend in October, and use Geofabrik's coffee+pizza to speed up software development....

regards, Arndt

[Volker]

Hi,

elevationmaxbuffer and elevationpenaltybuffer work on the same elevationbuffer. The elevationbufferreduce is in my opinion necessary to get a reasonable space for the elevationbuffer. I think 5 meters for uphill/downhill recognition is to less to get the artefacts filtered out and just setting elevationmaxbuffer to a higher value to get more space leeds to bad overall elevation minimizing. The solution is to penalize not only what doesn't fit in elevationmaxbuffer but also what's above elevationpenaltybuffer. The elevationbufferreduce is the amount it is penalized and everything that is penalized has to leave the buffer. Otherwise it wouldn't be possible to keep track of the penalties.

Regards, Volker

[Zossebart]

Hi,

thanks again for the explanation. I will play around a little bit more with the global parameters.
For the moment, I set them to

assign elevationpenaltybuffer 5
assign elevationmaxbuffer 10

assign elevationreduce 0

I tweaked my MTB-profile again, and the resulting routes look even better now! Can't wait to try some of them in reality!

Thanks for updating the android app to newer version on your server. Finally I can use it on the phone again!

Regards,
zossebart

[Hans Dampf]

Hi Zossebart,

It sounds very interesting what you wrote. I'm also interested in a working routing profile for MTB, but now I'm not familiar in changing the profiles to my desires.
So I would appreciate it, if you can post your profile here.
I'm really curious if it serves the results I hope to get.

regards hans

[Zossebart]

Hi Hans,

I am still fine-tuning the profile at the moment. After adding some downhill costfactors, it seemed to result in nice routes at first. But in some cases, the routing favoured major roads more after this (despite penalizing them).
I haven't found the "perfect" balance between the parameters yet. Also, I plan to modify the profile in order to make some parameters easily switcheable using variables at the top of the file. The profile also needs some cleanup work, because there are lot's of commented-out sections in it.
As soon as I'm happy with the routes and the profile I'll post it here.

In what regions do you plan to calculate mtb routes? Because at the moment, I'm tuning my profile for the countryside around my home in germany (low mountain range). Do you plan to do mtb routing in high mountain ranges (e.g. the alps)?

regards,
Zossebart

[Hans Dampf]

Hi,
finally I came to testing the new parameters for mountainbiking and the routes calculated are looking pretty good, but does not exactly fit to my preferences,
especially for going uphill. There I have a partly different approach to zossebart:
-> I would like to get a route for uphill, that is "ridable". I do not make a distinction between tracks and paths.
If an uphill is ridable depends on the following:
-> surface + slope (in %)

For example I would like to define the following combinations as ridable, that means: no penalty:
-> surface: asphalt (hw=service, hw=track/tracktype=grade1,hw=

unclassified), uphillcutoff: 20%
-> surface: gravel (hw=track/tracktype=grade2), uphillcutoff: 15%
-> surface: ground (hw=track/tracktype=grade3), uphillcutoff: 12%
-> surface: grass (hw=track/tracktype=grade4), uphillcutoff: 10%
-> hw=path, uphillcutoff: 8%

I think to setup something similar like this, it is necessary to add the uphillcutoff to the way section, instead of having it in the global section.

For downhill I do not plan to implement this, but perhaps some other people would like to do that, so the downhillcutoff in the way section colud be also useful.

In addition I would like to introduce a second uphill penalty when the slope is very high eg > 30%, meaning that you probably have to carry your bike.
At least it is very hard to go uphill such ways and it needs more time than usual.

Greetings
Günter

[Volker]

Hi,

in the current design the variables for the way section are evaluated before the elevation information and you can't use the slope of a (short) way segment without a buffer because of the bad quality of the SRTM elevation data. I think the best solution for this is to have more global elevation parameters (with separate buffers) and up-/downhillcosts in the way section. I did some testing with up to 6 sets just for the elevation penalties (with no significant improvement for my purpose) and got a slowdown of a few percent. The calculation of the way costfactor would get more tricky and the routing profile more bulked.

Greetings, Volker

[abre...@googlemail.com]

Am Montag, 29. Dezember 2014 11:38:12 UTC+1 schrieb Hans Dampf:

I think to setup something similar like this, it is necessary to add the uphillcutoff to the way section, instead of having it in the global section.

Did you notice the "current design" that Volker invented: it introduces "uphillcostfactor" and "downhillcostfactor" as alternative expressions that can by used to calculate the costfactor when going uphill or downhill. This is a new concept that go's beyond the old scheme (uphilllcost/uphillcutoff). It is not exacltly the same than having way-dependent elevation-parameters, it's more the other way round (elevation dependent way-parameters) but serves the same purpose.

[Poutnik]

I may do not understand exactly ,what was the reason for implementing up/downhill costfactors as triple redundancy of quite complex costfactor algebra.  I suppose it may be performance related or easiness to duplicate it, but I cannot evaluate it from end user point of view.

Future maintenance of potentially complex profile may lead easily to unexpected behaviour, when related code parts are different, but should be the same, or vice versa. Also, changing of a common code  has to be done 3times.

From profile code design point of view, I would prefer generally avoiding of redundancies, using switches for minor number of elevation dependent terms. Obviously, this would  make sense only if the terms of 3 costfactors do not vary much. If they do vary a lot, current independent costfactors sections are better. 

For elevation dependent parameter X, like .e.g for costfactor of  track grade 5 with gravel or ground in wet weather I would use something like  
 
        switch isuphill  XUH switch isdownhill XGH XNORMAL


Alternative way to deal with redundances, requiring extension of syntax, would be something like defining a code macro, and reusing of macro code, as known from some programming languages. ( e.g. Z80 processor assembler language M80 under ancient CP/M OS I worked with in 80's.)

[Poutnik]

Perhaps, that all may be matter of order when various parameters are evaluated, and when and for what profile parts they are available.
This is what I am not aware of as an end user.

[Volker]

Hi,

if you have just a minor difference between up/downhillcostfactor and costfactor you can write something like this:

assign uphillcostfactor add costfactor myadditionaluphillcost

Greetings, Volker

[Poutnik]

Well, it makes sense, and it should come to my mind, but did not :-)

But, hm, at home I have to verify, if syntax supports negative numbers a/o variable.
E.g. if I wanted to decrease penalty for up/downhills......

[Volker]

Hi,

Yes, you can use negative numbers, but the costfactor should not get below 1. Maybe you should add a "max 1 ..." to your profile in this case.

Greetings, Volker

[Poutnik]

Well, in fact, I knew it, talking about it with Arndt previously. Thanks for reminding.

[Poutnik]

Dne čtvrtek 18. září 2014 4:20:04 UTC+2 Volker napsal(a):

Hi,

there are also new parameters in context:global:

elevationmaxbuffer

This is the maximum size of the elevationbuffer in meters. Everything that doesn't fit in this buffer gets penalized. If not set the value is 10, exactly as in the previous versions.

elevationpenaltybuffer

If the elevationbuffer exceeds the elevationpenaltybuffer the waysegment is recognized as uphill or downhill. By default the value is set to 5 meters.

elevationbufferreduce

With this parameter set, the elevationbuffer gets an additional reduction of this percentage (of the distance) if it is above the elevationpenaltybuffer limit. This reduction gets penalized for the amount the elevationbuffer is reduced. By default the value is set to 0 to get an identical behavior to the previous versions.

I may still, (or not anymore  again) understand details about elevationbufferreduce.

Let suppose values from you profile
elevationbufferreduce = 0.3
elevationpenaltybuffer = 8
elevationmaxbuffer=13

Let suppose elevationbuffer = elevationpenaltybuffer and then the road mildly climbs  4 meters on 1 km segment.

I understand it as

1/ elevationbuffer value(12) > elevationpenaltybuffer(8), then uphill/downhillcostfactor usage is triggered, instead of costfactor.

2/ elevationbuffer value(12) is decreased by (1000 * 0.003)=3 m to 12-3 = 9m

3/ it is said these 3 metres are penalized, but how ?
    By normal uphillcutoff/uphillcost ? if values are e.g. 3.0/70, it would need 30 m / 1 km.
    IF elevationbufferreduce <  uphill/downhillcutoff, does it mean that there is no penalty, just buffer is reduced and up/downhillcostfactors are considered ?

[Poutnik]

Dne sobota 9. května 2015 16:25:09 UTC+2 Poutnik napsal(a):

3/ it is said these 3 metres are penalized, but how ?
    By normal uphillcutoff/uphillcost ? if values are e.g. 3.0/70, it would need 30 m / 1 km.
    IF elevationbufferreduce <  uphill/downhillcutoff, does it mean that there is no penalty, just buffer is reduced and up/downhillcostfactors are considered ?

Or, it the key to keep  elevationbufferreduce >  uphill/downhillcutoff,
to get penalized relatively small but steeper "bumps" on the road,
at buffer levels between elevationpenaltybuffer and elevationmaxbuffer ?

And as I remember, your cutoffs are like 0.1, or so.

[Volker]

Hi Poutnik,

in your example the uphill/downhillcostfactor wouldn't be triggered and the elevationbufferreduce wouldn't be used because your uphillcutoff is 3 and everything under the cutoffs is ignored.

If the elevationbuffer is between elevationpenaltybuffer and elevationmaxbufffer, elevationbufferreduce reduce the elevationbuffer by distance * elevationbufferreduce in %. The amount the elevationbuffer is reduced gets penalized by the uphill/downhillcost.

Here an example with easier to calculate values:

uphillcutoff = 1

uphillcost = 100

elevationbufferreduce = 0.5
elevationpenaltybuffer = 10
elevationmaxbuffer=20

First we start with empty buffer and go 1km distance and 19 meters uphill. We get no penalty because the first 10 meters are ignored by the cutoff, the second 9 meters fill the elevationbuffer below the elevationpenaltybuffer value and therefore costfactor will be used. If we go another 1km distance and 19 meters uphill, 10 meters are ignored, 5 meters will be penalized by the elevationbufferreduce with 500 meters distance and subtracted from the buffer, 13 meters remain in the elevationbuffer and uphillcostfactor will be used. If we go another 1km distance but 10 meters uphill, the 10 meters are ignored, another 3 meters will be penalized by the elevationbufferreduce with 300 meters distance and subtracted from the elevationbuffer, 10 meters remain in the elevationbuffer and uphillcostfactor will be used for 600 meters distance and costfactor for 400 meters. If we go another 1km distance and 9 meters uphill, the 10 meters are ignored, 9 meters remain in the elevationbuffer and costfactor will be used. If we go another 1km distance but 30 meters uphill, 10 meters are ignored, 9 meters will be penalized with 900 meters distance because they don't fit in the elevationbuffer, 20 meters remain in the elevationbuffer and uphillcostfactor will be used.

[Poutnik]

Dne 10/05/2015 v 01:04 Volker napsal(a):

......

Here an example with easier to calculate values:

uphillcutoff = 1

uphillcost = 100

elevationbufferreduce = 0.5
elevationpenaltybuffer = 10
elevationmaxbuffer=20

First we start with empty buffer and go 1km distance and 19 meters uphill. We get no penalty because the first 10 meters are ignored by the cutoff, the second 9 meters fill the elevationbuffer below the elevationpenaltybuffer value and therefore costfactor will be used.......

Hi Volker,

Thanks for the explanation.

I may stay confused, thinking about original implementation, that should apply, aside of elevationbufferreducing.

I may be wrong, but I have thought, that those 10 metres are ignored by the cutoff just for penalty calculation,
but they stay in buffer anyway,  as the buffer is IMHO used also as a hysteresis buffer for filtered ascend.

I.e. that all slopes gets accumulated in the buffer,
but eventually gets penalized
only that part that overflows the buffer
and only that part above cutoff. 

Therefore filtered ascend should be function just of elevationbuffermax, but not of cutoff value. 
Otherwise climbing 100 km with elevation 1 km would still end with empty buffer,  saying filtered ascend is 0 m. 

Is the filtered ascend calculated by other way that I think, before the buffer is updated by increment decreased by the cutoff value ?
Or, does affect elevationbufferreducing feature affect filtered ascend calculation ?
As this parameter is important for trip planning for time and effort estimation.

[Poutnik]

Dne neděle 10. května 2015 1:04:52 UTC+2 Volker napsal(a):

First we start with empty buffer and go 1km distance and 19 meters uphill. We get no penalty because the first 10 meters are ignored by the cutoff, the second 9 meters fill the elevationbuffer below the elevationpenaltybuffer value and therefore costfactor will be used. ................. If we go another 1km distance and 9 meters uphill, the 10 meters are ignored, 9 meters remain in the elevationbuffer and costfactor will be used. ......................

Does the cutoff discrimination work differently, if elevationpenaltybuffer is empty or full ?
As under impression of the first part, the 9 metres in the 2nd part should be ignored as well.

Or , is it rather matter of hysteresis, and elevationpenaltybuffer overtakes original role of buffersize for hysterezis evaluation ?

[Poutnik]

Dne neděle 10. května 2015 1:04:52 UTC+2 Volker napsal(a):

...... If we go another 1km distance and 9 meters uphill, the 10 meters are ignored, 9 meters remain in the elevationbuffer and costfactor will be used.....

It looks like 10 m in the buffer is emptied, before adding new 9m. Why ?

[Poutnik]

I may be still confused, how cooperate in new implementation

Filtering ascend with hysteresis management of elevation based cutoffs
and
penalty management with slope based cutoffs.

[Volker]

Hi Poutnik,

filtered ascend is always calculated with 10 meters buffer and without the cutoffs after the searchrun just for information.

The cutoffs are subtracted from the buffers until the buffer is empty or new elevation is added.

If you set elevationmaxbuffer = 10 and elevationbufferreduce = 0 the calculation is as before the update.

[Poutnik]

Thanks, Volker, for clarification.

I did thought calculation of filtered ascend should be done like that, and do know it is for the information only.
I was  just unsure, if hysteresis calculations were done in 1 step, or in 2 steps - for penalties and for ascend..

All things seem to fit know...

Dne neděle 10. května 2015 11:38:37 UTC+2 Volker napsal(a):

[Andrew Heard]

This is probably a separate topic but are there plans for considering gradient, not just elevation in a route calculation? I have seen a case where a steep road was chosen in the route whereas I would have chosen a slightly longer but less steep route. In both cases the elevation cost was the same because they only ascent or are flat.

[abre...@googlemail.com]

Am Montag, 18. Mai 2015 00:01:53 UTC+2 schrieb Andrew Heard:

This is probably a separate topic but are there plans for considering gradient, not just elevation in a route calculation?

Hi Andrew,

we had that topic in the past, see e.g. here: https://groups.google.com/forum/#!msg/osm-android-bikerouting/suIs8XBlAMQ/yy9eYeOCANUJ

the short answer is:

- you do not get gradients from SRTM data

- the lookup table includes the "incline" tag, so where that exists, it can be used to avoid very steep up/downhills

- you can have some success by using the uphill-component, which is unused (uphillcost = 0) in the standard profiles with a large cutoff, e.g. uphillcost = 70 / uphillcutoff  = 3.0

[Andrew Heard]

Very interesting. I will experiment with those two settings. As always thanks for all your help.

[Pallai Roland]

Andrew,

I did some experiments with gradient calculation based on SRTM data to avoid steep uphills in Brouter. Incline calculation is inaccurate and you can't really get rid of that without drawbacks (except manual "incline" tagging in OSM) - but not hopeless for this purpose IMHO.

One can check calculated inclines on my map* in a few countries around Central Europe: http://mtdev.dap.magex.hu:3003/#zoom=15&lat=47.53745&lon=18.99926&scope=varosban

..and you can see the quirks at the bank of the rivers (for example): some flat ways that perpendicular to the river are tagged as "red" due to low resolution of SRTM 90. It's a problem for gradient calculation (but Brouter logic can handle it nicely with elevationbuffer). SRTM 30 would be a huge advantage here.

On the other hand, I found that the SRTM noise is not really an issue, it can be the cause of fake gradients only up to 4-5%.

The algorithm is very simple: works on bi-linear filtered SRTM 90 data and checks the elevation at every 100 meters (actually at the closest node to that). Shorter ways are checked from end to end. It has a buffer that tolerates small incline fluctuation over the segments, and tags the segment with the most higher calculated gradient value.

After I integrated it into my Brouter profile, I found it does a better job to avoid steep gradients at the hills than the high uphillcutoff/uphillcost values. There is quirks, but much less than with the uphillcutoff/uphillcost hack. So I ended up use this preprocessed data in my profiles.

* The gradient is the colorful arrow on the road: purple: 8-9%, purple-blue: 10-11%, blue: 12-13%, blue-red: 14-15%, dense red: 16%+. You can turn on the contour lines on the left bar. The map used for Brouter profile development, slow and temporary.

2015-05-18 18:38 GMT+02:00 <abre...@googlemail.com>:

Am Montag, 18. Mai 2015 00:01:53 UTC+2 schrieb Andrew Heard:

This is probably a separate topic but are there plans for considering gradient, not just elevation in a route calculation?

[abre...@googlemail.com]

Am Samstag, 6. Juni 2015 19:04:40 UTC+2 schrieb Pallai Roland:

After I integrated it into my Brouter profile, I found it does a better job to avoid steep gradients at the hills than the high uphillcutoff/uphillcost values. There is quirks, but much less than with the uphillcutoff/uphillcost hack. So I ended up use this preprocessed data in my profiles.

Hi Roland,

so you managed to modify the brouter-mapcreator to inject an incline pseudo-tag into the rd5-data ? Wow.

I'm currently working on a traffic-load pseudo-tag, so maybe pseudo-tags are the way to better routing...

As for SRMT30: it is available, and I already did a long way to integrate it in brouter, but I did not yet commit the patch and I did not make the map-creator job to use it.

At the 2015-Fossgis talk I had two slides about SRTM30 and especially about the new filter, a combination of an disk-area and a central value filter. It's a german talk, the elevation part is at the end, maybe you want to have a look: https://www.youtube.com/watch?v=Eba4fcYI4h4

[Pallai Roland]

2015-06-08 18:10 GMT+02:00 <abre...@googlemail.com>:

Am Samstag, 6. Juni 2015 19:04:40 UTC+2 schrieb Pallai Roland:

After I integrated it into my Brouter profile, I found it does a better job to avoid steep gradients at the hills than the high uphillcutoff/uphillcost values. There is quirks, but much less than with the uphillcutoff/uphillcost hack. So I ended up use this preprocessed data in my profiles.

so you managed to modify the brouter-mapcreator to inject an incline pseudo-tag into the rd5-data ?

The incline tagger script written from scratch (in Ruby) and works on the .pbf files and writes the result ("incline" tags/new ways) also into .pbf and I feed Brouter with that. I have no Java skills so it was the simpler solution.

I'm currently working on a traffic-load pseudo-tag, so maybe pseudo-tags are the way to better routing...

Pseudo-tags are cool. IMHO a great advantage that it's easy to generate them with third party preprocessors. The most trivial use case is on the ways but I see great opportunities in pseudo-, turn restiction-like relations too in the future.

For example: taking turn restrictions very seriously is not a good idea for bike routing because you can easily trick them sometimes, but sometimes not. Hard to do it well, a lot of code in Brouter. But this job could be passed to a preprocessor that creates turn restriction-like relations (with from/via/to members) and simply feed that into Brouter. This way Brouter only has to support that simple relation to handle a complex situation at the junction. Brouter stays simple, the preprocessor just doing it's (complex) job. I think it's a good compromise and another way to better routing in the cities.

 

As for SRMT30: it is available, and I already did a long way to integrate it in brouter, but I did not yet commit the patch and I did not make the map-creator job to use it.

At the 2015-Fossgis talk I had two slides about SRTM30 and especially about the new filter, a combination of an disk-area and a central value filter. It's a german talk, the elevation part is at the end, maybe you want to have a look: https://www.youtube.com/watch?v=Eba4fcYI4h4

Thanks, I'll have a look!

[Jozef Matejička]

Hi Pallai,

this route is nearly flat:

http://mtdev.dap.magex.hu:3003/#zoom=19&lat=49.21962&lon=18.74577&scope=varosban

To the south there is hospital on mountain, route is below it and nearly flat.
See:
https://goo.gl/maps/As8aI
Are you interested in more wrongly classified cases?
Will you share your preprocessor?

Thanks for sharing,

Jozef

> --
> You received this message because you are subscribed to the Google Groups
> "OSM Android bikerouting" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osm-android-biker...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Pallai Roland]

Hi!

2015-06-08 22:14 GMT+02:00 Jozef Matejička <matej...@gmail.com>:

this route is nearly flat:

http://mtdev.dap.magex.hu:3003/#zoom=19&lat=49.21962&lon=18.74577&scope=varosban

To the south there is hospital on mountain, route is below it and nearly flat.
See:
https://goo.gl/maps/As8aI
Are you interested in more wrongly classified cases?

The problem here is also the low SRTM resolution. No one can say that this hump is after or under the street by SRTM so it's included into the gradient of the street. The same problem applies for the river banks.

Calculated gradient for way 30375695 by the script:

 0m-  93m  93m* (z:337.67m-345.41m) incline:   8.3%

I'm aware of this issue and a possible solution is the SRTM30 data.

 

Will you share your preprocessor?

It's a part of a longer processing chain and undocumented, needs time and some advanced IT skills to get it to work. Do you still interested in? I can share but it's not designed for end-users.

[Jozef Matejička]

Hi Roland!

On Tue, Jun 9, 2015 at 6:11 PM, Pallai Roland <pal...@magex.hu> wrote:
> It's a part of a longer processing chain and undocumented,

As always ;)

> needs time and
Oops, you got me on this one. I can spend 5 hours/week max, in the
long run even less..

> some advanced IT skills to get it to work.

Great way to learn new stuff.

> Do you still interested in?

Definitely

> I can share but it's not designed for end-users.

I understand that.

I also understand that it takes huge effort to publish something. I do
not want to waste your time, that you can utilize for other things,
e.g. tweaking your approach. Your preprocessor AND MAP seems to be
nice new toy I can play with.

I am actually searching for something where I can contribute. I would
understand if you would not share your preprocessor.

Cheers,
Jozef

[Pallai Roland]

2015-06-09 18:11 GMT+02:00 Pallai Roland <pal...@magex.hu>:

2015-06-08 22:14 GMT+02:00 Jozef Matejička <matej...@gmail.com>:

this route is nearly flat:

http://mtdev.dap.magex.hu:3003/#zoom=19&lat=49.21962&lon=18.74577&scope=varosban

To the south there is hospital on mountain, route is below it and nearly flat.
See:
https://goo.gl/maps/As8aI
Are you interested in more wrongly classified cases?

The problem here is also the low SRTM resolution. No one can say that this hump is after or under the street by SRTM so it's included into the gradient of the street. The same problem applies for the river banks.

Calculated gradient for way 30375695 by the script:

 0m-  93m  93m* (z:337.67m-345.41m) incline:   8.3%

I'm aware of this issue and a possible solution is the SRTM30 data.

I've inspected SRTM 30, but does not help, just makes things worse in the city, fake gradients up to 10% because of the more contrasted buildings.

[Pallai Roland]

2014-12-29 17:56 GMT+01:00 Volker <volke...@googlemail.com>:

in the current design the variables for the way section are evaluated before the elevation information and you can't use the slope of a (short) way segment without a buffer because of the bad quality of the SRTM elevation data. I think the best solution for this is to have more global elevation parameters (with separate buffers) [...]. I did some testing with up to 6 sets just for the elevation penalties (with no significant improvement for my purpose) and got a slowdown of a few percent.

 

Multiple elevation buffers with different penalty scores sounds like a good solution against too steep slopes. Does it work in practice? What are the drawbacks except the few percent slowdown?

[Volker]

Am Mittwoch, 10. Juni 2015 23:41:59 UTC+2 schrieb Pallai Roland:

Multiple elevation buffers with different penalty scores sounds like a good solution against too steep slopes. Does it work in practice? What are the drawbacks except the few percent slowdown?

 Hi,

with the default elevation buffer with 10 meters a 10 percent slope with 100 meters length can go without punishment if the buffer was empty and with higher cutoff even more. If you use a smaller buffer you will get more artifacts. I don't think you can get good slope limitation with the SRTM data. First I would just try higher uphillcost with uphillcutoff lower than the maximum slope you want, because you need high enough uphillcost to get the alternative routes cheaper. If there are any without to much detour. My testing was with higher buffers to filter bigger hills but it wasn't better than my high penalties with one buffer. I can build a build a test version of BRouter with more elevation buffers for you so you can test it yourself.

Greetings, Volker