Andi

Another list taken from here: https://github.com/graphhopper/graphhopper/pull/2561#issue-1205880236: * [ ] Remove special handling of VehicleTagParsers in ~~TagParserBundle~~OSMParsers (acceptWay method) * [ ] Remove default encoded values from EncodingManager and default tag...

Almost eight years later issue #1 got closed :smile:

Uh yeah there was a commit in the navigation repo that closed issue number 1 of the **navigation** repository:  and now we had this commit here it closed issue...

Yes, but in the navigation code there weren't any. For map-matching we should not forget about this. But actually we should be a bit careful because I think we decided...

> We cannot change commit messages without changing the history that could break other things. I meant we should change comments in the code. But even if there is something...

Ok sure its probably also not a real problem. If some issues are auto-closed we can just re-open them. But do the commit hashes really stay the same even when...

Almost forgot, but another problem is that we use the random node ids to get the gps coordinates. But this means that all query graph snaps are always tower nodes,...

Yes we need the location index lookup. But we can just build a list of valid points upfront. To use block area we can then just take points from this...

Let's see how this affects measurement, but in any case I think this is the more 'correct' way to do it: d111819426692536021b833c47fda31b4652a78a

> we'd need to figure out how we want to store parsed access restrictions for multiple transportation modes in the graph. We already store access flags for each vehicle. Do...