Miscellaneous issues wrt offline matching and "id" in input

[GeoCrunch]

Hi, first thank you greatly for this package, it has made my life much easier and is very easy to implement.

My issues are already resolved to the extent things are working, but I want to clarify why they're working lest I have problems later.

By background, I am matching a large amount of data - currently 19 million points for 1500 vehicles (with more in future) covering a continent with heterogeneity in frequency and gps accuracy because the sources are varied. My main purpose is determining information about the road network.

After small scale testing and rewriting of sections to return desired information (thanks for your comments elsewhere here) I started feeding Barefoot json files (with the batch.py script), each representing a separate vehicle. However the 'id' variable in the json represented a "trip", which I had designated through earlier processing. This removes stationary periods from the data, but also separate groups of pings distinct in time and space. Sometimes these gaps occur because there were a long string of erroneous values which I had to filter out.

Most vehicles processed fine, but a number would always time out, even with server properties allowing very generous intervals (up to half an hour). I did not reduce the max search distance below 6 km because the lower frequency of data from some sources likely meant vehicles were travelling further than that between pings.

Eventually I started feeding individual trips so I could pin point exactly where problems were occurring - and everything worked!

So, what I think is happening

1. The id variable is only used to identify output, but not change processing - this is hinted at in the documentation but wasn't entirely clear, and a user, like me, may have expected they could feed a bunch of vehicles in one json file.
2. Barefoot was failing where a vehicle had jumped a large distance, particularly from a point in an urban area. Whilst the jump was between two trip ids, barefoot was still trying to route between them subject to max distance, but with a very large number of options.

Does this seem plausible? If so everything is fine. I'm assuming I am an unusual case, but this leads to two suggestions.

1. Slight clarification of what the "id" value does and does not do.
2. A switch that first checks if the "crows' fly" (great circle) distance between two points is greater than the max route distance, at least for points with a larger than normal time interval. Since the shortest route can't logically be less than the straight line, this would avoid trying to find a route in these circumstances.

Once again, thankyou!

[smattheis]

Thanks for the feedback. You described the behavior exactly as it is. The id is rather used for online map matching case where the "tracker" receives some number of GPS positions per from various vehicles every second and must assign all GPS points to the right vehicle. The id is not used in the offline matching case and handles traces on a per request basis. It's the question here, if it should be a feature to process multiple vehicles/trips with one request, which adds a new level in the JSON structure of the output and makes processing a bit more inconvenient for the simple case, or if it's sufficient to keep it like that but highlight this limitation in the documentation. Therefore, the question: Do you think it is a large detour to feed multiple vehicles with multiple requests? To the second point, that's so straigh-forward and effective, I will add that check. Thanks.

[GeoCrunch]

Hi I agree that any gains from making possible multiple requests in a single file would be modest compared to the complications, especially since the switching thing would solve the main problem here.

Thank you again for this marvellous package

[smattheis]

Thanks again for the feedback! :)