Details (encoded_values) are missing when using Docker?

Hi,
First and foremost thanks for this awesome library and endless giving!
I’m trying to get details on a route I’m requesting.
The following is the GET request:

http://localhost:8989/route?instructions=false&points_encoded=false&details=road_class&details=max_speed&elevation=true&point=31.971396577420734,35.24470233230383&point=31.926065209376176,35.00963707334776&vehicle=foot

The following is my config file:


The following is the docker compose I’m using:

Seems like I’m defining the details (encoded_values) correctly yet the response I get is:

{"message":"You requested the details [road_class, max_speed] but we could only find []","hints":[{"message":"You requested the details [road_class, max_speed] but we could only find []","details":"java.lang.IllegalArgumentException"}]}

Am I missing something out? are details not supported for foot flag encoder?

Thanks ahead! any help will be appreciated.

As you use the path details here there is likely some configuration problem. Once this is available you’ll get this information independent of the flag encoder.

The configuration file is almost identical to the example-config.yml file (commented in some stuff).
What do you suggest I should do? The graph is building and working as expected and I get a route between any two points, I also get directions if I set the query to get it.
What should I try? remove flag encoders? remove encoded values? Which part of the configuration can cause this?

Which GraphHopper version are you using?

The one from dockerhub 0.12 I think it is.

We do not publish GraphHopper to docker hub, only our docker containers. And as you said

The following is the docker compose I’m using:

you build your docker container on your own (if I understand this properly). So only you know which GraphHopper version you use. At start up it is also printed:

GraphHopperOSM - version 1.0|2020-03-30T09:22:02Z (5,15,4,3,5,5)

Make sure you use the latest stable 0.13 where the path details you tried where introduced:

I see, thanks for the clarification and quick response!
The version I’m using is: version 0.12|2019-01-31T16:58:02Z (5,14,4,3,3,2)
How can I make sure I’m using a stable version?
In any case, I’ll see what I can do in order to rebuild graphhopper image.

I’m not sure I built the image locally. I’m using the following image as far as I understand which is a year old image:
https://hub.docker.com/r/graphhopper/graphhopper/
from docker image ls:
graphhopper/graphhopper latest 3c42f9a7011d 14 months ago 757MB

Ah, I see. Looks like people build their docker image based on the current version they need.

Have created: https://github.com/graphhopper/graphhopper/issues/1985

I see, I probably mixed the config example with the wrong version of graphhopper and so ended up with this issue - which is basically a compatibility issue as far as I understand.
It would be extremely helpful if you could push a new version to docker hub when creating a release in github. If there’s anything I can help with let me know.
Please, please, please, pretty please don’t choose the option to just add a deprecate comment instead. Even pre-release docker container are useful instead of rolling out my own…
Thanks again for all the hard work!

Everything comes for the price of maintenance: https://github.com/graphhopper/graphhopper/issues?q=is%3Aissue+docker+is%3Aclosed

So it is rather unlikely that we include it again as our build process is already complicated and lengthy enough.

If there’s anything I can help with let me know.

Sure, you could set up a repository that fetches from our repo and publishes the docker container for every tag or commit and we could then point to this docker image as the official one.

graphhopper/graphhopper is probably where people would look for a docker image, I don’t suppose you’ll give me the permission to update this image, right?
I don’t mind setting up a fork that will automatically gets updated and set some CI to upload it to dockerhub when a new tag is defined and see how this plays out, but I am concerned about the image name…
This is an interesting tool to keep a fork up-to-date:


So the only thing I need to implement is the CI which shouldn’t be too hard and make sure the dockerfile is up-to-date.
I’d love to help out. Been using graphhopper for a long time and I would really like to contribute back.

From there we can easily link to your image (and remove the rest of the readme).

So the only thing I need to implement is the CI which shouldn’t be too hard and make sure the dockerfile is up-to-date.

You can use travis (have a look into our .travis.yml for an example) or github actions which is now also without costs.

Been using graphhopper for a long time and I would really like to contribute back.

Nice, great to hear that :+1: !

I don’t suppose you’ll give me the permission to update this image, right?

Yeah, it is probably even better if we give you direct access to graphhopper/graphhopper at docker hub.

I’m not sure if I understand you last comment - will it be possible to give me access to this dockerhub image settings so I can maintain it?
In any case, I should probably prove myself to be worthy of maintaining this dockerhub image first :-).
I’m comfortable with appveyor for CI which is what I’m currently using, but I can probably look at what Travis has to offer. I’ll look for a repo that builds docker images and see what are the required steps, shouldn’t be too hard as creating a docker image is pretty straight forward if you have a dockerfile, which graphhopper has :-).
Where would you like me to report my progress? Here or in the issue you have opened?

Sorry, I was not clear enough. We will give you access to docker hub, will contact you via pm. The only thing we would require is that the code for building the image is done in an open source repo, so that everyone can see what is included and we are 100% transparent.

In any case, I should probably prove myself to be worthy of maintaining this dockerhub image first :-).

I trust you based on the previous contributions and once you pushed the image I can easily test and we improve from there.

I’m comfortable with appveyor for CI which is what I’m currently using

Sure, we also use appveyor to test our windows compatibility.

Where would you like me to report my progress? Here or in the issue you have opened?

We can keep discussion here and if code changes are required open a pull request. But as you are already in the contributors file there is probably not much we need :slight_smile:

Ok, seems like the docker build had finished successfully! :slight_smile:
Can be seen here:
https://ci.appveyor.com/project/HarelM/graphhopper/builds/32176974
The repository I’ve used for my tests can be found here:


The only file I added was the appveyor-dockerhub-deploy.yml and used the appveyor settings to run it instead of the default one.
I haven’t tried to deploy it to dockerhub yet, It will probably be my next test.
It takes about 2 minutes to build the docker image and just a few build script commands (when using a linux environment and not windows as I think the default docker container settings for windows are windows containers, which do not work obviously…).
I’m not sure if I want to keep this as the official repository instead of using the more familiar IsraelHikingMap github account, but I already have a version there which is worth storing, I think, I’ll need to think about it and update where the “official” docker graphhopper github repository is planned to be, unless you are willing to reconsider pulling this in to your build script, which I have to say is pretty straight forward, and it shouldn’t complicate it much.
of course there are more tests to be made before I can call it a day…

BTW, regarding the issue described in the begging of this thread, I was able to use another docker version while playing to make mine work: noamgal/graphhopper and it uses version 1.0…
I’m not able to see road_class and track_type but when I plan a route (Yay!!) using the foot flag encoder over a footway and a path (OSM highways tags) I’m unable to distinguish them - I get other for both track_type and road_class. Should I open an issue about it in Github or should I use another encoded_value? is this a know issue?

over a footway and a path (OSM highways tags)

This was added only very recently: https://github.com/graphhopper/graphhopper/pull/1907
I.e. it should work with master.

which I have to say is pretty straight forward, and it shouldn’t complicate it much

Ok. And if it fails could we assign the issue (to resolve it) to you :slight_smile: ? The problem I see with this is really just the maintenance.

Since I volunteered to create a repository to keep the docker image up to date, and I was planning on opening the issues there for docker issues I think it would only be fair to assign docker issues to me.
I don’t see a lot of maintenance once this is up and running, but I’m up for the challenge nevertheless :-).
Once I’ll finish all my tests and changes I’ll submit a pull request to resolve #1985 using either the appveyor or the travis CI files (Probably the appveyor as I’m more comfortable with it, later we might change it to travis since it should run on linux. BTW, appveyor can do both if you want to unify the build process to one file).

1 Like