-
Notifications
You must be signed in to change notification settings - Fork 273
findNClosest fails for large measurementErrorSigma #65
Comments
Increasing the underlying "cell width" of the location index could fix this:
Be aware of the slower lookup. Also I would rather avoid using an endless loop here. |
OK, didn't realise that. However, the issue still stands:
You've kind of got one already. E.g. if the user sets Of course, it's an edge case, and unlikely to benefit most people directly. (Unless, of course, only one iteration is needed instead of two - which would mean 9x less lookups?) Will leave it to you if you wish to close this. |
It is not too many loops. It is more complicated than one thinks, see graphhopper/graphhopper#221 and graphhopper/graphhopper#232 |
Ah, right. If it was just finding the closest, you could optimise it further (i.e. only check nearby tiles with r_min < distance to closest point in current tile). As an aside, isn't |
That is what we do for normal LocationIndexTree search. What I meant is the problem regarding 'line rasterization' algorithm which requires neighbor search currently.
Yes, indeed. You can create an PR or issue for it |
Just something I noticed while trying to understand
findNClosest
(as I'll be refactoring it for another use) - it won't find all matches ifmeasurementErrorSigma
is too large. That is, it will at most only ever find all matches within +-deltaLat
/deltaLon
.Not sure if this is intended behaviour or an actual bug. If it is a bug, I think it should be a simple fix to replace
with
(from here).
The text was updated successfully, but these errors were encountered: