Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Edge flags refactoring #1447
Mainly this PR avoids the 64 bit limitation of getFlags and makes working with edge properties much easier (direction-dependent or not):
// definition of the EncodedValue: registerNewEncodedValue.add(averageSpeedEnc = new DecimalEncodedValue("some_name.average_speed", speedBits, defaultValue, speedFactor, speedTwoDirections)); // for the import: edge.set(averageSpeedEnc, 60).setReverse(averageSpeedEnc, 30.0); // in the Weighting: edge.get(averageSpeedEnc); edge.getReverse(averageSpeedEnc);
It is now very easy to enable direction-dependent values, just with a boolean flag in the constructor. One can now easily introduce FlagEncoder-independent values like we did already with the roundabout boolean. One can now easier use external edge data as there is no need to define a direction bit and one uses the reverse property of the EncodedValue (see REVERSE_STATE or graph.getEdgeIteratorState returns stored direction). And also the EncodedValues are independent of any OSM tags, interesting for other data sets like GTFS. This change also reduces the usage of getFlags until we can make it private at some point.
The goal was to make a 'minimal' version of #1112 without introducing new features like TagParser and also we did not yet remove FlagEncoders. Also performance seems to be the same. All other features could be introduced later.
Ok, I'm now happy with the scope of the change and I think this PR is in a good shape. All tests are green and performance is also ok, so we have something we can work on.
Before a merge we would need to test this on a world wide instance and also I need to know if it satisfies some of the use cases we had before (like external edge data etc). So I would need feedback regarding the EncodedValue-API, maybe @ammagamma & @michaz can have a look and already work a bit with it?
Another question is if we should use IntsRef or LongsRef. Currently we have not implemented a cross-int EncodedValue i.e. if you have two EncVs with 20 bits then the second one will be in the next int and 12 bits are unused. Maybe one can implement a cross-int solution (like we partially had before via ints-merging) or maybe we reduce problems with a LongsRef? The best thing would be to hide this decision as much as possible and make it trivial to change it later. Maybe we can then keep using IntsRef as also the underlying DataAccess for edges is of type
What do you mean? btw: the underlying implementation could be easily changed (have several experiments done but as a start simplicity is more important), so that e.g. the value and its delta are stored like we do now for landmarks instead forward+backward values.
referenced this pull request
Sep 20, 2018
@easbar Do you think this change makes this PR a bit cleaner or at least more consistent of CH and none-CH stuff? There are two tiny advantages: the weight is 1 bit more precise and setWeight and access handling is independent, i.e. you do not need to call one before the other or something. I wasn't able to measure any performance difference but will do again with some improved measurement stuff. After we decided this I would finally merge this PR.
There is also this lazy loading commit, but I do not like this pattern that much.