Closed jjetrifork closed 1 month ago
I am encountering similar mismatch issues. I've noticed the problem is less prevalent for smaller matches. As an aside @jjetrifork I notice you set --max-matching-size 2147483647
. Have you been able to run matches of on the order of 10^4 or 10^5 coordinates? This is something I'm looking to do - thanks!
@rdkt For my use case the mean number of matches is ~1200 and I have to match all in one go :/ However I don't think I have exceeded 50.000 yet, I looked up the datatype for max matching size and chose the maximum for the data type.
This issue seems to be stale. It will be closed in 30 days if no further activity occurs.
I am having trouble understanding the output of the match service.
Every now and then I come across a request where the number of tracepoints is larger than the number of input coordinates even though there is only one match.
Given a prepared and running local server (version 5.20.0):
Consider the following request with
413
input coordinates:Click for full request
Full request:Which yields the following response (and commented with my understanding):
Full response: https://pastebin.com/Nvu8xpcM
There is a surplus of 28 additional trace points. This surplus seems unrelated to the 20 unmatched input coordinates.
The number of legs pair perfectly with the number of trace points... but how do I pair up the orginal 413 coordinates with the 441 trace points?
Curiously the indicies 3 to 416 in the trace points lines up near perfectly with the input coordinates.
I hope someone can provide me with a little insight :)