> What’s the reason behind the data sample period of 5-10 per minute? Is it a > tuning to a specific “zoom level” and average vehicle speed (ie car)?
It's 5-10 seconds between samples. So its 6 to 12 samples per minute. > Our bike GPS data is sampled every second You can absolutely down-sample that. 5 seconds between samples is absolutely fine in my experience (even more so for bikes, which move slower). > Would it possible to change the "sample rate" of the algorithm at either > query time or with program options? You can try change the `map_beta` parameter, but higher sample rates like in your case should work. The thing is that 60 samples/minute is pretty wasteful and the request takes much longer than one for 6 samples/minute with gives a similar quality. One thing you need to watch out for is that the result will contain multiple sub-matchings. So in case of a bike trace that runs through some bollards the matching on data prepared by the car profile will most likely contain two matchings: the trace gets split at the bollard node because the algorithm fails to find a sensible connecting route. When you match it on bike data the trace will not get split. In this case the confidence for each subt-race might be high in both case, the defining difference is the splitting of the trace for cars but not for bikes. On Sat, May 9, 2015 at 6:29 PM, Emil Tin <[email protected]> wrote: > > Hi Patrick, > > What’s the reason behind the data sample period of 5-10 per minute? Is it a > tuning to a specific “zoom level” and average vehicle speed (ie car)? > > Our bike GPS data is sampled every second, which makes more sense for bikes > which don’t travel that fast. My guess is we would need this this resolution > to capture many of the details that separate car/foot/bike, like how you turn > in intersections, etc. > > Would it possible to change the "sample rate" of the algorithm at either > query time or with program options? > > > Another challenge could be situations where ways are missing in OSM. But we > might be able to recognize these by lookng for low matching matching > confidence for all modes. > > The approach would require us to run additional OSRM instances for foto and > car - at the moment we only run bike. > > > Emil > > > >> On 09 May 2015, at 15:49 , Patrick Niklaus <[email protected]> >> wrote: >> >> Hey Emil! >> >> yes that sounds like a good application for the map matching API. Good >> catch on the missing documentation, I fixed that. :-) >> The only problem I see is that the classification highly depends on a >> sample periods around 5-10s. >> >> I'm very interested in hearing about the results of this! >> >> Best, >> Patrick >> >> >> On Fri, May 8, 2015 at 8:14 PM, Emil Tin <[email protected]> wrote: >>> Hi, >>> I’m wondering if the new map matching feature could be used for guessing >>> travel mode? >>> >>> We’re currently working on adding a GPS tracking feature to our I BIke CPH >>> ap. Both iOS and Android now come with build-in APIs for automatically >>> detecting the travel mode, but on iOS the results are surprisingly low >>> quliaty. Since we already use OSRM, I’m wondering it it could be used >>> improve the detection quality. >>> >>> For example, suppose I have a GPS track and need to guess whether the user >>> was biking, walking or in a car? Could I use the matching algorithm with >>> different profiles (bike/foot/car), and get values expresssing how well the >>> track fits each network, ie. the probability that the user was >>> biking/walking/driving? >>> >>> It might be useful in siutations where the networks differ slighty due to >>> things like: >>> >>> - Topology. Some ways allow only bikes/walking/cars. Some intersections >>> provide different lanes/ways for turning by car/bike/foot. >>> - Oneway. Streets might be oneway for cars, but not for bikes. >>> - Barriers. You don’t usually pass stairs or bollards by car. >>> >>> >>> At https://github.com/Project-OSRM/osrm-backend/wiki/Server-api is written >>> that you can pass classify=true to get a confidence value for the matching, >>> but it’s not mentioned in the response section? >>> >>> >>> Thanks! >>> >>> Emil Tin >>> CIty of Copenhagen >>> >>> >>> _______________________________________________ >>> OSRM-talk mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/osrm-talk >>> >> >> _______________________________________________ >> OSRM-talk mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/osrm-talk > > > _______________________________________________ > OSRM-talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk _______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
