Code Monkey home page Code Monkey logo

xcscore-js's Introduction

xcscore

Cross country league flight scoring for paragliding.

Introduction

xcscore computes the highest scoring flight from an array of coords according to the World XContest and Swiss Cross Country Cup rules. It is designed for use in XC flight planning software like XC Planner. It uses crude brute force algorithms that support only a small number of coordinates and is not suitable for scoring flights from GPS tracklogs.

API overview

xcscore exports two functions:

  • scoreWorldXContest for scoring flights according to the World XContest rules.
  • scoreCHCrossCountryCup for scoring flights according to the Swiss Cross Country Cup rules.

Each function takes a single object as an argument with two properties:

  • coords: an array of coordinates.
  • distKMFunc: a function that returns the distance in kilometers between two coordinates.

Each function returns a single object describing the highest scoring flight found with five properties:

  • flightType: the type of the flight, e.g. "openDist", "flatTri", or "faiTri". For a full list of flight types see the documentation.
  • dist: the scoring distance of the flight.
  • multiplier: the scoring multiplier for the type of flight.
  • score: the score of the flight. Note that this is not necessarily equal to the product of dist and multiplier due to rounding rules.
  • coords: the coordinates of the start, up to three turnpoints, and end of the scoring part of the flight.

If no scoring flight can be found (e.g. because there are fewer than two input coords) then the returned object will have flightType "none", dist, multiplier, and score 0, and coords [].

For a full description of the API, consult the documentation in the dist/docs directory.

Performance

xcscore uses simple brute force algorithms for implementation simplicity and minimal code size. CPU usage increases with O(N^5) and memory usage with O(N^2) so xscore is heavily CPU bound.

The package includes benchmarks to measure performance, the results of which depend heavily on the CPU. As a rough guide, 25 coords is fine on any machine (scored in approximately less than 2ms on a single core of a 2014-era MacBook Pro), whereas 50 coords is a reasonable upper limit (taking 60ms on the same machine).

More sophisticated algorithms are used for scoring real GPS tracklogs with tens of thousands of points. Contact the author for details.

Use with popular JavaScript mapping libraries

xcscore is independent of the coordinate format and the function to compute the distance between two coordinates. As such, it can be used with any mapping library.

Google Maps JavaScript API

coords can be an array of google.maps.LatLngs and you can use the following function as distKMFunc:

function distKM(latLng1, latLng2) {
    return google.maps.geometry.spherical.computeDistanceBetween(latLng1, latLng2, 6371);
}

LeafletJS

coords can be an array of LatLngs and you can use the following function as distKMFunc:

function distKM(latLng1, latLng2) {
    return latLng1.distanceTo(latLng2)/1000;
}

License

MIT

xcscore-js's People

Contributors

dependabot[bot] avatar peterbraden avatar twpayne avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar

xcscore-js's Issues

Fix npm install warnings

Currently running npm install emits a couple of warnings:

$ npm install
npm WARN @fimbul/[email protected] requires a peer of tslint@^5.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN [email protected] requires a peer of tslint@^5.0.0 but none is installed. You must install peer dependencies yourself.

added 2 packages from 4 contributors and audited 249476 packages in 5.588s

11 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

It would be nice to fix these.

Add benchmark infrastructure

The code uses simple brute force algorithms that are O(N^5) in the number of coords, and are CPU bound. Memory usage is O(N^2). It would be good to get a feel for what the practical maximum number of coords is by running some benchmarks.

This should use an existing, established benchmarking package like BenchmarkJS.

Initially, benchmarks should be run for (say) 10-15 coords, and more can be added once the infra.

Here are some input data for , to be used with the cartesianDist function used by the existing tests.

13 coords:

const score = scoreWorldXContest({
	coords: [
		[6, 0],
		[3, 0],
		[0, 0],
		[1.5, 2],
		[3, 4],
		[4.5, 6],
		[6, 8],
		[7.5, 6],
		[9, 4],
		[10.5, 2],
		[12, 0],
		[9, 0],
		[6, 0],
	],
	distKMFunc: cartesianDist,
});
if (score.flightType != "faiTri" || score.score != 51.2) {
	// fail somehow
}

Ideally the benchmark should be run with npm run benchmark or similar, and ideally as part of the GitHub action defined in .github/workflows/main.yml.

Separate tests into their own directory

Currently tests are in src/index.spec.ts, which is the same directory as the source code. The TypeScript compiler also currently generates several files from this in the dist/ directory, which are unwanted:

dist/index.spec.js
dist/index.spec.js.map
dist/types/index.spec.d.ts
dist/types/index.spec.d.ts.map

It would be nice to move the tests into their own subdirectory, say tests/, and not have these test-related files generated in dist/.

Note that the tests also run both the TypeScript tests and the JavaScript tests generated from the TypeScript tests:

$ npm test

> @twpayne/[email protected] test /Users/twp/src/github.com/twpayne/xcscore-js
> jest

 PASS  src/index.spec.ts
 PASS  dist/index.spec.js

Test Suites: 2 passed, 2 total
Tests:       70 passed, 70 total
Snapshots:   0 total
Time:        2.077s
Ran all test suites.

Note that both src/index.spec.ts and dist/index.spec.js are both run. It would be nice if separating the tests also meant that only src/index.spec.ts was run.

Review project for best practices

This is @twpayne's first TypeScript code and first npm module.

Please review the project configuration and code and suggest any changes needed to ensure that the project follows TypeScript and npm best practices.

As already discussed, the use of JSDoc /** */ comments is for use with typedoc.

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.