brandonwillard / open-tracking-tools

Open source Java library for on-line vehicle tracking, path estimation and parameter learning.

This library contains a set of tools for tracking objects through GPS data real-time.
Specifically, it contains implementations of Bayesian particle filters for on-road and off-road 2D motion and state-parameter estimation.

The generic api uses a graph and some observations to produce sequential filtered results, which infer the true location, velocity, their variances, the street it's on/the path it took. Extensions in this library include the ability to estimate parameters, like GPS and acceleration errors. See https://github.com/openplans/open-tracking-tools/wiki for a better description.

To get started, you can build an OpenTripPlanner graph by specifying coordinate boundaries for OpenStreetMap data, then running the TraceRunner in open-tracking-tools-otp over a CSV file. (See https://github.com/openplans/OpenTripPlanner/wiki/GraphBuilder for more information about OTP graph building.) An example xml build file for an OTP graph can be found in the open-tracking-tools-otp project, as well as an example TraceRunner config file.

Another example of a graph is GenericJTSGraph.java, which takes simple JTS geometry objects.

There is also a simulator that will produce observations for testing. See RoadTrackingGraphFilterTest.java for a complete example of graph construction, simulation and filtering.

open-tracking-tools's Issues

fix "backward" movement along edge

Build graph builder stage for converting OTP to Cartesian space

[18:21] I think this will end up being a separate GraphBuilder stage which lives in tracking tools.
[18:23] <novalis_dt> Right now, the spherical distance functions are in DistanceLibrary, and are static
[18:23] <novalis_dt> We would just make that dynamic

short-circut overlaping paths

Problem:
[17:34] in our search for paths, where we won't return [[edge1], [edge1, edge2]]
[17:34] but instead [[edge1, edge2]]
[17:35] and in the filter, where we computations for those edges are are reused

Solution:
<novalis_dt> kpw, here's a sketch, I think.
[17:40] <novalis_dt> Insert each path into a trie-like structure
[17:41] <novalis_dt> If, when inserting a path, you stop at a node that has children, mark the current path as unused
[17:41] <novalis_dt> Store with each node a list of paths that use it
[17:41] <novalis_dt> If, when inserting a path, you go past a node that previously had no children
[17:41] <novalis_dt> then for each path in that node's list of paths, mark that path as unused.
[17:42] <novalis_dt> Pretty sure that's O(n*m), where n is the number of paths and m is the avg number of edges in a path.

Update OTP integration to use the latest OTP (and build via maven only).

The maven-pulled OTP 0.7.10 jar doesn't appear to have the necessary getters (getModes, specifically) so it won't build via maven alone. It seems to work if one pulls everything--including OTP source--into Eclipse, then adds Lombok to Eclipse and compiles.

Hopefully updating the OTP dependency will resolve some of that.

Different projections not lining up

The projections of the graph are not lining up with the projections of the gps observations.

Create Integration Tests For Edge Projections

The title says it all, but, more specifically, for convertToGroundBelief etc.

Using open-tracking-tools library

hi every one,
is there any help or wiki to understand how to compile this library and use it .

actualy i use ubantu 12 sts
.

Improve throughput

Determine a throughput goal/requirement.
Inspect profiled runs and determine/prioritize where the changes need to be made.

Fix PathEdge.marginalPredictiveLogLikelihood and PathEdge.predict

I don't think these actually predictive likelihoods, it's either that or they should be using more information from the current observation. Essentially, the first resample step is not as good as it should be. Investigate.

Off-road path tracking

We want to track the locations and paths of off-road travel.

Tests for OTP path finding

Need to make tests for common and interesting path search scenarios.

short-circut overlaping paths

Problem:
[17:34] in our search for paths, where we won't return [[edge1], [edge1, edge2]]
[17:34] but instead [[edge1, edge2]]
[17:35] and in the filter, where we computations for those edges are are reused

Solution:
<novalis_dt> kpw, here's a sketch, I think.
[17:40] <novalis_dt> Insert each path into a trie-like structure
[17:41] <novalis_dt> If, when inserting a path, you stop at a node that has children, mark the current path as unused
[17:41] <novalis_dt> Store with each node a list of paths that use it
[17:41] <novalis_dt> If, when inserting a path, you go past a node that previously had no children
[17:41] <novalis_dt> then for each path in that node's list of paths, mark that path as unused.
[17:42] <novalis_dt> Pretty sure that's O(n*m), where n is the number of paths and m is the avg number of edges in a path.

Running TraceRunner

I need two files to run traceRunner
3905-detour-labeled_ott.csv
3905-detour-labeled_ott-filtered.json

Particle edge-velocity distributions

We need to keep edge velocity distributions for each particle, not globally.

Add State and Observation Covariance Estimation to PL Filter

Add sufficient stats for these parameters, updates and sampling to PL filter.

Switch tracking lib to use PlainStreetEdge throughout

Path Search Issues/Questions

Paths are not being found for the vehicle 861785000283626 on 2012-04-06 (2012-04-12_test_small.csv) at observation/record 61.

put a limit on search distances for paths

[13:13] <novalis_dt> The quickest fix to getPaths will be to use a max search radius
[13:14] the most direct/reasonable thing we can provide is expected distances to travel
[13:14] which i imagine works similarly
[13:18] well, we can make a reasonable upper bound from it
[13:18] it is a mean and variance
[13:18] so we can just say that we want the upper 99% of the distribution

Fix OTP path finding

The default graph in OTT is from Geotools and all the search & path code is built around that. There is old code for an A* search performed directly on the OTP graph, but it's not up to date.
There are two approaches we can take:

• Create a Geotools graph from the OTP graph
  • Pros: might be quicker to implement and get working properly
  • Cons: will probably ignore some road constraints unless some extra checks are put in place, construction overhead (memory/time)
• Update the old OTP path-finding code.
  • Pros: leverages existing OTP search capabilities, easier to use and include road restrictions
  • Cons: more time to convert code, which involves refactoring to consider road segments