allow queries with filters to use fast-lane reducers #511
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.
Currently, every query which is using a filter (either via an ohsome filter or a custom filter predicate) is using the slower backend routines, because the actual filtering is implemented using
flatMap
which has a larger overhead than the more streamlined routines which know that noflatMap
operations have to be performed.This has the small side-effect that the
NullPointerException
from #159 is back (yet, in a different place). But I'd say this is acceptable, as usingnull
values for actualmap
results should be avoided anyway.Todo
type:way and building=*
in a country-sized bbox like Germany)Checklist
I have made corresponding changes to the documentationI have adjusted the examples or created an issue in the corresponding repositoryI have adjusted the benchmark or created an issue in the corresponding repository