Thanks, I didn’t realise that. To get it running I had to increase the maximum allowed nodes to 100000. Unfortunately, it now takes over 2 seconds to run. Maybe that’s not too bad given that standalone routing takes about 0.1s (on a specified route - interestingly CH is not the fastest), and this is an unusually long route. I’ll have to performance test (and see whether anyone has any ideas about Spark).
We are aware of the risks etc., hence why this will only ever be used for detection of aggregate traffic flows, with a bunch of error detection on top. We’re not aiming for 100% accuracy - but even 50% is infinitely better than not using the data at all (providing no systematic errors).
Not exactly. It’s more that in some cases we only know that the mobile was on a radius e.g. ‘10km from X’. (The equivalent GPS fuzziness would be “at some radius R from X, with standard deviation of d” - here we already know R.) There’s inherent fuzziness on top of that (i.e. it’s actually a fuzzy radius), as well as in the points that are trilaterated … probably of a hundred meters or so.
Agreed it’ll be better - as long as it runs fast enough. I’ll do some more testing, but off the top of your head, how much faster do you think the map matching could be made? And likelihood of this happening? (I could probably help, with some direction.)