Data structures

The core processing component of the OS-Matcher is, of course, the router. To perform the routing it needs data which it gets from input filters and intermediate filters. The input filters may also depend on each other. An example: to be able to load the map from a database, the track is needed to define the boundaries.

Processed data

Each processing component is designed as a filter with a well defined set of input data (requirements and optionals) as well as output data (fulfillments).

See also

See filter to learn how to implement and plug in a filter.

Example: Router

The router mandatorily needs data about the street topology and the track point projections onto street segments. For each track point, there might exist more than one candidate (see Candidate search or Sampling point router).

It may optionally process the track point’s timestamp and velocity, if present. In contrast, it does not need the track point’s coordinates.

The output is the route along with additional data to help reason about the found route.

Type listing

It follows an overview about all the data types that are passed along the filters.

For each track point:

• coordinate pair, as PointList

• heading, as HeadingList

• timestamp, as TimeList

• velocity, as VelocityList

For each street segment:

• coordinates, as SegmentList

• junctions, as NodePairList

• travel direction, as TravelDirectionList

Street graph:

• street graph, as Graph

• mapping from graph edge to street segment, as GraphEdgeMap

• mapping from graph node to street junction, as NodeMap

• mapping from street segment to graph edge, as StreetIndexMap

Routing:

• resulting route data, as RouteList

• additional routing data per sampling point route data, as RoutingStatistic

• projected track points, as SamplingPointList