Refactor Costing and PathEdge Protos #3506
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
in #3464 we added support for interacting with the service via protobuf. at the time we noted several items for future work. this pr closes out the "refactor" item.
the specific refactoring that was done here is all contained to the "request" (ie options object). inside of the options object there are several output items, which is a bit strange as this is the request object we use to start the service interaction going. there are mainly two places where we actually store output which we would not expect the user to provide. those two places are the ones listed in the title, the costing object and the path edges that loki finds. let me summarize the changes.
PathEdge
Loki takes your input locations and finds candidate edges in the graph that we can use in the algorithms. We currently store this information in the
Location
object which is also where the requester specifies the lat lng etc. In addition to the path edges there are a few more bits of output info about where the location correlated to the graph. Instead of having these all directly in the location object I nested them into a new object called correlation and marked it so that its obvious that its output. I could have done something more radical and moved it completely out of the options object but this didnt feel necessary.Costing
Currently we have a
Costing
enum which must be specified as well asCostingOptions
which are optional. At the moment costing options has both inputs and outputs. The refactor puts all of the proper costing options into their own object and nests that inside of a costing object. In this way we can have the higher level non optional bits of a costing object as well as the output bits separate from the actual user supplied options. ive also changed the naming a bit so that the enum is calledCosting::Type
and costing options are nowCosting::Options
.Thats it. There is no functional change to the code in anyway its all moves and renames to hopefully make the api a bit easier to work with in pbf mode.