Home
One of the core ideas behind ootk is that you can use the pieces that you want without being forced to add the entire codebase. To simplify the process of letting everyone pick and choose what they want and don't want the build script produces ES6 modules for each of ootk's modules. From there you can use imports to decide what you want. If you are using AMD or <script> tags, then you can load the dist/ootk.js file to get everything or load each module individually.
Each module and its features are explained on their respective wiki pages.
For those of you who found this page and are familiar with satellite.js, you are probably wondering if there are any differences between this project and the original. There are some differences and there will continue to be more. The goal is to remove some of the errors in satellite.js and add some of the features that I believe bottlenecked performance.
Currently the satellite.js file included can be substituted 1:1 with the old satellite.js. If you run into any problems, let me know and I will fix them. I am gradually transitioning my own project and this allows me to take advantage of the new features while not breaking legacy calls to satellite.js. If you are new to this library, I highly recommend starting with sgp4.js instead.
- Added support for Alpha-5
- Fixed millisecond issue in invjday
- Corrected gravity constants to use recommended WGS-72 values
- Included support for AFSPC time calculations (see below)
- Fixed parsing errors with nddot and bstar
Satellite.js allowed a margin of error in verification of the sgp4 results when comparing them against the gold standard in Revisiting Spacetrack #3. The margin of error, while slight, was caused by incorrect time and gravity constants. For the hobbyist, this doesn't really matter a bunch, but trying to improve performance or correct timing issues it is better if there is no margin of error in the testing.
The main reason I chose to branch off from the satellite.js vs working on correcting the above issues is my plan to add support for webworkers. Rather than focusing on maintaining the code, I am focused on improving and expanding the library. The first step in that is adding a benchmarking suite to quickly establish current performance - ideally from the command line. Then optional support for 2-8 webworkers will be added to allow performing multi-threaded calculations.
Additionally, the current SGP4 code was designed to maximize performance on 1970s mainframe computers (seriously!). There are likely many ways that performance can be increased in JavaScript - one of the first was removing the variable declarations from inside the functions to allow recycling them for those of us who are propagating the whole catalog on a loop.