[GraphHopper] adding adaptivity to graphhopper

[Vivek Nallur]

Hi Peter,

Many thanks for the tips.

What I had in mind, was a scenario like this:

1) A web-service pulls pollution data and noise data from some sensor-network or other
source, and writes it to the OSM file (frequency: once-per-day)
2) At request from the user (lets say 'least polluted route'),
GraphHopper calculates a route with the weights on each road-link being
determined  by the amount of pollution
3) The combined route is then presented to the user
4) A new user requests 'least noisy route'
5) GraphHopper calculates a route with weights on each road-link being
determined by the noise-data available
6) The combined route is then presented to the new user

Does CH not allow for this use-case? I asked about caching, because
after a couple of queries, I hand-edited the OSM file that GraphHopper
was using. But GraphHopper seemed to continue to use the values from the
old file. I'm assuming it had cached them somewhere, and was picking
them up (also because it would start up really quickly, as opposed to the first
time)

So, my questions are:

a) Does GraphHopper keep a cached version of the map somewhere? If so,
how do I clear this at runtime?

b) Is the OSM file the correct place to write such sensor data? If not, where
would you recommend I keep it, such that GraphHopper's weighting
algorithm can use it?

regs
Vivek


On Tue, Jun 24, 2014 at 11:22:36AM +0200, Peter wrote:
>Hey Vivek,
>
>first, you'll have to disable CH which is enabled by default to provide
>this kind of flexibility I think.
>
>And instead of putting the logic in the encoder I would probably use a
>customized Weighting which does the things you mentioned:
>1. reads the user demand or
>2. can read a particular information from an edge (like polluted,
>noisy,...).
>
>For this more generic encoding I introduced methods like
>FlagEncoder.set/getLong/getBool/getDouble a few days ago.
>
>
>> Would different users demanding different characteristics screw up any
>caching that GraphHopper does?
>
>Not sure if you refer to CH when you say 'caching'. But yes different
>user demands are not really possible with CH.
>
>Regards,
>Peter.
>
>
>> Hi
>>
>> I'm a researcher working at Trinity College Dublin, and I'm looking at
>> the possibility of adding adaptivity to GraphHopper. To elucidate, I'm
>> looking at multiple kinds of needs of users:
>>
>> a) The user desires a route with particular characteristics (least
>> polluted, least noisy, etc.)
>> b) When multiple users all demand a particular route, during a given
>> timeframe (say for a music concert), the algorithms try to provide
>> slightly different routes to each user, so as to minimize the chance
>> of a traffic jam.
>>
>> For Task (a), I think the key is to add multiple encoders (in the
>> routing/util/ directory) all descended from AbstractFlagEncoder, and
>> have them responsible for adding different weights to different
>> routes/roads. Is this correct? Would different users demanding
>> different characteristics screw up any caching that GraphHopper does?
>>
>> Just wanted to ask the opinion of the list, if they had any
>> ideas/suggestions/stuff-already-tried, etc. Obviously, all successful
>> implementations will be added back to the graphhopper community.
>>
>> regs
>> Vivek
>>
>> _______________________________________________
>> GraphHopper mailing list
>> GraphHopper at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/graphhopper
>
>
>_______________________________________________
>GraphHopper mailing list
>GraphHopper at openstreetmap.org
>https://lists.openstreetmap.org/listinfo/graphhopper