Hi,
It isn't possible to switch to the foot encoder. There are two issues, the first is from the web service, the value passed in the http request doesn't get passed through. I didn't track this one down because I won't be using the web service for my application.
The next issue is that there are so many places where the vehicle/encoder could be specified. Firstly I specified it on the request:
VehicleEncoder algoVehicle = new FootFlagEncoder();
.
.
.
GHResponse rsp = hopper.route(new GHRequest(start, end).
vehicle(algoVehicle).type(algoType).
algorithm(algoStr).
putHint("douglas.minprecision", minPathPrecision));
and before the load:
hopper.forServer();
hopper.acceptWay().car(false).bike(false).foot(true);
hopper.load(osmFile);
This still resulted in car like times being calculated for the route...
I then specified it in the route method:
if (chUsage) {
prepare.graph(graph);
((PrepareContractionHierarchies) prepare).vehicle(request.vehicle());
if (request.algorithm().equals("dijkstrabi"))
algo = prepare.createAlgo();
At this point I can see that the correct encoder arrives in the Path instance (where the time gets calculated), but the distance then evaluates to 0, and therefore so does the time. At which point I decided to discuss this with you.
There seems to be a few concepts mixed, first there is acceptWay, then there is encoder, then there is vehicle. They seem to be used semi interchangeably. My suggestion is to use one, and then stick with it.
Then it needs to be clear at which point in time such a setting should be supplied by the API user. Is it at load time? In which case I would assume from this that it effect the graph gen/load/contraction in some way (which doesn't seem to be the case from the code). Or is it at request time, in which case the value needs to be taken into account during the route request.
Part of the problem also seems to the preparation abstraction which creates the algorithm instances, because it is also created in different ways, and so the encoder sometimes doesn't get passed along, or does in a way that is hidden by the preparation interface (in the case of the PrepareContractionHierarchies
) .
So, like I said, when I got to this many variables I decided to log an issue before I make a mess of your code or having to fork it away completely, either of which is obviously bad.