Code Monkey home page Code Monkey logo

probematch's Introduction

@mapbox/probematch

Match a single GPS measurements (probe) or line of sequential GPS measurements (trace) to a road network.

probematch creates an flatbush index of a road network to allow you to quickly match probes or traces to the roads using configurable distance and bearing filters.

terms

  • probe - a single GPS measurement, represented by a Feature<Point>
  • trace - a collection of sequential GPS measurements, represented by a Feature<LineString>
  • road - a Feature<LineString> representing a road, which we may attempt to match probes and traces to
  • roads, network, road network - a FeatureCollection of roads
  • segment - a single edge of a road. For road A -> B -> C, there are two segments: A -> B and B -> C. Segments always have only 2 points.

install

npm install @mapbox/probematch

configuration

var probematch = require('@mapbox/probematch');

var roads = {
  'type': 'FeatureCollection',
  'features': [
    // Linestring features representing the road network
  ]
};

var matcher = probematch(roads, {
  compareBearing: true,
  maxBearingRange: 5,
  bidirectionalBearing: false,
  maxProbeDistance: 0.01
});
key type default description
compareBearing boolean true Should bearing of probes be used to evaluate match quality?

If true, the bearing of the probe is compared to the bearing of each possible matching road segment. This ensures probes don't match cross-streets that obviously aren't the same as the probe's direction of travel
maxBearingRange number 5 Maximum amount in degrees that a probe's bearing may differ from a road segment's when using compareBearing
bidirectionalBearing boolean false Should bearing matches allow for probes to be moving in the opposite direction of a road segment's bearing? This should be true if the road network includes 2-way roads.
maxProbeDistance number 0.01 Maximum distance in kilometers that a probe may be from a road segment in order to consider it a possible match. Prevents matching probes to segments that are too far away from them.

usage

match

var probematch = require('@mapbox/probematch');

var roads = /* FeatureCollection of road geometries */;
var matcher = probematch(roads, {/* configuration */});

var probe = {
  type: 'Feature',
  geometry: {
    type: 'Point',
    coordinates: [0, 0]
  }
};

var probeBearing  = 57; // probe's direction of travel in degrees

var results = matcher(probe, probeBearing);

The result of matching a single proble is an array of possible matches to the road network. Results are ordered by the probe's distance from the candidate road.

Each possible match represents a road that is likely to have matched the probe.

key type description
road Feature<LineString> The geometry of a road that may have been matched
index Number The start index of the segment closest to the probe may have matched (in the road's coordinates)
distance number Distance (in kilometers) between the probe and the road
bearing number The bearing of the road at the location that matched

matchTrace

var probematch = require('@mapbox/probematch');

var roads = /* FeatureCollection of road geometries */;
var matcher = probematch(roads, {/* configuration */});

var results = matcher.matchTrace(line);

matchTrace returns an array of match results. The order of results is the same as the order of the coordinates in the input trace. This means that the zeroeth element in the matchTrace result is an array of possible matches for the zeroeth coordinate, and so on.

probematch's People

Contributors

aaronlidman avatar annapetrone avatar lily-chai avatar tcql avatar tmcw avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

probematch's Issues

Index whole ways, not segments

Right now we are indexing individual segments. While this probably yields faster matching, we are creating many segment objects that reference the parent way, which is very inefficient in terms of memory.

To implement this, we need to use the index property of cheap ruler's pointOnLne method in order to do the bearing comparison.

Other than that, we should make sure that performance stays good.

cc @mapbox/telemetry

include bearing in match output

distance from segment is included, but bearing difference should also be included. Potentially we should also allow for sorting results by bearing instead of distance, or some combo of distance + bearing.

npm publish

It appears that v1.1.0 may not have been published to npm.

cc @tcql

vocab / doc quest

In light of #5, and general confusion around what probematch does and returns, terminology and descriptions should be extremely consistent.

  • Document outputs and terminology - draft
  • Consistify terms in docs AND code:
    • line -> road, in the context of results returned from matching
    • line -> trace in the context of a trace being matched to the road network, as in matchLine ( -> matchTrace)
    • point -> probe
    • featurecollection -> road network anywhere that this makes sense

Fail on invalid input, don't fix it

I'm finding normalizing and flatten GeoJSON taking ~60% of CPU time on very large arrays. My input is valid so ideally all this work is never done.

We should rely on the user providing valid data and failing if it's invalid, rather than incurring a performance penalty everywhere.

cc @tcql

allow specification of oneways in road network

Right now it's possible for probes to be incorrectly matched to known oneways when using the bidirectionBearing flag. It'd be preferable for us to allow individual roads to be flagged oneway: true | false so we never attach opposite bearings to a oneway.

With this feature, we could probably remove the bidirectionalBearing option - since you always (?) want it right now - and instead rely on one-way specification to prevent invalid reverse bearing matches.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.