robfitzgerald
commented
1 month ago it probably makes sense to elevate the rtrees into the search app (rather than being input plugins) and then we can easily provide the constructed frontier model to the rtree at query time
totally. something like a MapMatchingService should be part of the CompassApp... aand, the FrontierModel would be passed into InputPlugin.process. huh, that could be a little tricky, but, possible. CompassApp's SearchApp has the FrontierModelService but the FrontierModels still need to be built to be used. so, it's like we would want to call FrontierModelService.build() inside CompassApp.apply_input_plugins.
building two frontier models per query is not ideal but should be cheap, it shouldn't take a ton of CPU/RAM. but it turns out to build only one, we would need to apply input plugins at the same time we are running search, and that breaks how we are chunking the jobs and could miss out on performance optimizations for chunking heterogeneous grid searches. </rant>
nreinicke
Adds in a new frontier model for truck specific restrictions like: maximum weight or maximum trailer length, adding a couple of new units along the way to support this.
Also ties the truck restrictions into the edge based rtree which should work for now but I think this raises the point again that the edge rtree should really have the frontier model in scope when it does an edge search instead of duplicating the process between the frontier model and the edge rtree search. To do this, it probably makes sense to elevate the rtrees into the search app (rather than being input plugins) and then we can easily provide the constructed frontier model to the rtree at query time.