Graphhopper: Add a hash value for profiles

[easbar]

Right now its very easy to:

1) setup some profiles and do the import/preparation of the graph data
2) shut down the server
3) change the profiles in config.yml again
4) restart the server but 'forget' deleting the graph-cache folder
5) get bad routing results because the profiles no longer 'match' the preparations

One easy way to detect this error would be calculating and storing some kind of hash code for each profile.

See this discussion: https://github.com/graphhopper/graphhopper/issues/1999#issuecomment-618910167

[easbar]

This could be a valuable improvement to be included in 1.0?

[karussell]

Yes, sure. I'll have a look into it!

[karussell]

Do we need to store and ensure hash values only for every profile listed in profile_lm/ch?

And can we skip the check for all LM profiles that reuse another preparation?

[easbar]

Do we need to store and ensure hash values only for every profile listed in profile_lm/ch?

Yes I think so. All we want to do is recognize if a profile that we keep some preparation for was changed (without updating the preparation). And without ch/lm we do not store any kind of prepared data so nothing can go wrong?

And can we skip the check for all LM profiles that reuse another preparation?

Hm it could happen that such a profile changes and no longer works for the chosen preparation_profile. Then again we do not do any kind of check whether or not a preparation_profile works for a given profile either.

[easbar]

Hm it could happen that such a profile changes and no longer works for the chosen preparation_profile. Then again we do not do any kind of check whether or not a preparation_profile works for a given profile either.

Sorry this was probably not very clear. I mean this: We have profile A and calculate landmarks for it and profile B that uses the landmarks we have for profile A as well. If we later change profile A we should get an error (because the hash changed without calculating new landmarks). If we later change profile B it could happen that this is no longer compatible to the landmarks we got for profile A. But then again we never checked that is was compatible before this either.