Avoiding noise and air pollution from close-by highways

[sjakobi]

When cycling I usually try to avoid ways that are next to busy roads such as highway=primary or downwind, say 1km, from a highway=motorway. Is there a way to express such preferences in profiles? If not so, what would it take to add such a feature?

Currently, I'll manually add no-go-areas to adjust routes to my liking, but this is rather tedious.

[polyscias]

Yes, that is something I also would like to see.

Implementing it in BRouter is not that easy, first you need some source that gives the data on noise/air-pollution and for me greenness. Then you need to add it to each of the roads the .rd5 datafiles and finally you need to incorporate it in a profile.

Things are already discussed in #258.

[sjakobi]

Thanks for the quick response and the reference to #258! :)

Regarding the avoidance of nearby highways, I wonder whether a "good enough" solution would be to have penalties on ways that are within a certain distance (and optionally a certain direction) of certain types of ways.

For example:

• add cost 123 on any way within 100m to the east of a highway=primary
• add cost 234 on any way within 1km to the east and south of a highway=motorway

Unlike most(?) appproaches discussed in #258, this approach wouldn't require additional data sources.

[poutnikl]

I can imagine it could be extremely demanding on computation resources, and partially on suitable algorithm too.

IMHO, better is not to blindly create routes, nor using nogos, but using visual route planner, e.g. in brouter-web,or LocusMap planner.

[sjakobi]

I can imagine it could be extremely demanding on computation resources, and partially on suitable algorithm too.

Yes, this seems likely. An implementation might need a good level of sophistication to be suitable even for simple routing tasks.

I wonder whether there are algorithms from computational geometry or computer graphics that could be adapted for this feature. For example, I think that there is a similarity with shadow-casting.

IMHO, better is not to blindly create routes, nor using nogos, but using visual route planner, e.g. in brouter-web,or LocusMap planner.

Visual route planning via manually added waypoints certainly has its place. But I think it can be tedious, and also difficult when one is unfamiliar with the territory.

I also like to use brouter for "route discovery": Tweak some parameters and see what routes brouter may come up with. Penalties on nearby highways would make this approach much more powerful IMHO.

[poutnikl]

I also like to use brouter for "route discovery": Tweak some parameters and see what routes brouter may come up with. Penalties on nearby highways would make this approach much more powerful IMHO.

My profiles, or their template in the first place, are based on the idea of tweaking. :-)

[EssBee59]

Implementing it in BRouter is not that easy!

Yes, I agree, such an enhancement (if possible at all) is very complex, many big changes are prerequisited, but a lot of users liked to get it! In the same way as "avoiding noise" I liked to become able to prefer "pleasant routes" (mid of green, river side, parks, sights etc..).

258 was the first of many issues in this domain, Norber created a new one in last summer ( #460 )

Further links:

https://github.com/nrenner/brouter-web/wiki/Round-trip-suggestions

https://trailrouter.com/blog/how-trail-router-works/ (interesting as it give an example for computation)

A basic idea is to extend the rd5 file with the new properties (nearly the same way the elevation is calculated)

But again, the effort to enhance the Brouter could get very high... Are developpers interested? I would help as I can

Regards

[sjakobi]

I realized that the cost of noise pollution ought to be scaled by the time spent in it. E.g. when climbing a way next to a noisy motorway the cost of noise pollution should weigh heavier than when we're looking at the descent in the opposite direction.

For air pollution, the cost should probably be scaled by the physical power expended on the affected way. My reasoning is that the health damage due to pollutants may be roughly proportional to the total volume of pollutants breathed in, which in turn I'd expect to be roughly proportional to the physical power expended.

[EssBee59]

the cost of noise pollution should weigh heavier than when we're looking at the descent in the opposite direction.

Hello,

Of course no contradiction! but, is it a limit in the requirements? (To limit the noise nights, some highways habe a limited maxspeed between 22::00 and 06:00 hours....)

anyway: assuming a "noise" factor/tag becomes soon available, then you can easyly inject this parameter in the "elevatation penalty" and so implement your whish!

example in the script: insted assign uphillcost 100

you can set

assign uphillcost switch estimated_noise_class=1 110 switch estimated_noise_class=2 130 ...

You can test this on my test-instance (a prototype with only Germany routing map):
http://brouter.de/essbee/#map=13/49.9949/8.6406/osm-mapnik-german_style

regards

[sjakobi]

Thanks for the example and for pointing me at your test instance, @EssBee59!

In order to understand the impact of the new tags, it would be great if the analysis panel could include them. E.g. in addition to the surface types it could show the estimated_noise_class etc.

[EssBee59]

In order to understand the impact of the new tags, it would be great if the analysis panel could include them.

Hello, The new tags (noise, river, forest and town) are displayed in the panel in the same way as the standard tags! if not so.... -remember, only 2 profiles are prepared to use the new tags (racebike-verylowtraffic and trekking_SB) (with other profiles you can set "assign processUnusedTags = true" to show all available tags, even when not used in the profile)

-if problems still exist you should clear the cache of your browser (or F5 ctrl + F5 etc...)

[quaelnix]

you can easyly inject this parameter in the "elevatation penalty"

assign uphillcost
switch estimated_noise_class=1 110
switch estimated_noise_class=2 130
...

@EssBee59, that won't work because uphillcost is not parsed in the way context.