Initial draft.

.github/workflows/rust.yml

@@ -0,0 +1,64 @@
+on:
+  push:
+    branches: [ main, develop ]
+  pull_request:
+    branches: [ develop ]
+
+env:
+  CARGO_TERM_COLOR: always
+
+name: GitHub actions
+
+jobs:
+  check:
+    name: Check
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install Rust
+        run: rustup update stable
+      - name: Unit test
+        run: cargo check
+
+  test:
+    name: Test Suite
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install Rust
+        run: rustup update stable
+      - name: Unit test
+        run: cargo test
+
+  clippy:
+    name: Clippy
+    runs-on: ubuntu-latest
+    env:
+      RUSTFLAGS: "-Dwarnings"
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install Rust
+        run: rustup update stable
+      - name: Run Clippy
+        run: cargo clippy --all-features
+
+  coverage:
+    name: Code Coverage
+    runs-on: ubuntu-latest
+    env:
+      CARGO_TERM_COLOR: always
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install Rust
+        run: rustup update stable
+      - name: Install cargo-llvm-cov
+        uses: taiki-e/install-action@cargo-llvm-cov
+      - name: Generate code coverage
+        run: cargo llvm-cov --all-features --workspace --lcov --output-path lcov.info
+      - name: Upload coverage reports to Codecov
+        uses: codecov/codecov-action@v4.0.1
+        env:
+          CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
+        with:
+          files: lcov.info
+          fail_ci_if_error: true

.gitignore

@@ -2,6 +2,7 @@
 # will have compiled files and executables
 debug/
 target/
+lcov.info
 
 # Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
 # More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html

CODE_OF_CONDUCT.md

@@ -0,0 +1,45 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behaviour that contributes to a positive environment for our
+community include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behaviour include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behaviour and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behaviour.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviours that they deem inappropriate, threatening, offensive, or harmful.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behaviour may be
+reported to the community leaders responsible for enforcement at:
+[codeofconduct@via-technology.aero](mailto:codeofconduct@via-technology.aero).  
+All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/),
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct/).

CONTRIBUTING.md

@@ -0,0 +1,100 @@
+# How to contribute
+
+First off, I'm really glad you're reading this, because we need volunteer developers to help improve this project and make it more useful to other developers.
+
+The following is a set of guidelines for contributing to this repository  which are hosted on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
+
+## Where do I go from here?
+
+If you've noticed a bug or have a feature request then please raise a [new issue](https://github.com/kenba/icao-wgs84-rs/issues/new).
+It's generally best to check the [issues](https://github.com/kenba/icao-wgs84-rs/issues) and [pull requests](https://github.com/kenba/icao-wgs84-rs/pulls) (open and closed) to ensure that someone else has not noticed it before you. I recommend that you wait for confirmation of your bug or approval for your feature request in this way before starting to code.
+
+Please abide by our [Code of Conduct](CODE_OF_CONDUCT.md) in all issues and pull requests.
+
+## Fork & create a branch
+
+If the issue is something you think that you can fix, then [fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) this repo and create a branch from the `develop` branch with a descriptive name.  
+E.g. a good branch name would be (where issue #42 is the issue you're working on):
+
+```shell
+git checkout develop
+git checkout -b 42-fix-some-bug
+```
+
+## Get the test suite running
+
+Run the unit tests:
+
+```shell
+cargo test
+```
+
+and integration tests:
+
+```shell
+cargo test -- --ignored
+```
+
+To ensure that you haven't broken anything.
+Please feel free to add tests, especially where the new test(s) demonstrates a bug that you noticed.
+
+Note: a new test that demonstrates a bug that you've described in an issue is always welcome in a PR, even if you haven't developed the code to fix it yet.
+
+## Implement your fix or feature
+
+At this point, you're ready to make your changes!  
+Feel free to ask for help; everyone is a beginner at first.
+
+## Get the style right
+
+Your patch should follow the same conventions & pass the same code quality checks as the rest of the project.  
+Please instal and run `clippy`, `fmt` and `llvm-cov` before submitting your pull request:
+
+```shell
+cargo clippy
+cargo fmt
+cargo llvm-cov
+```
+
+## Make a Pull Request
+
+At this point, you should switch back to your develop branch and make sure it's up to date with opencl3's `develop` branch:
+
+```shell
+git remote add upstream git@github.com:kenba/icao-wgs84-rs.git
+git checkout develop
+git pull upstream develop
+```
+
+Then update your feature branch from your local copy of master, and push it!
+
+```shell
+git checkout 42-fix-some-bug
+git rebase master
+git push --set-upstream origin 42-fix-some-bug
+```
+
+Finally, go to GitHub and make a [Pull Request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request).
+
+Github Actions will then build your PR.
+
+## Merging a Pull Request
+
+A maintainer will review your PR and determine whether it's Ok to merge it into the `develop` branch.
+
+If it is, he/she will approve and merge the PR. If not, they may comment on the PR to request changes before they are willing to approve and merge it.
+Note: at this stage you should only change the PR to resolve the maintainer's comments.
+
+You should *not* introduce a fantastic new feature that you've just thought of! That should be raised as a new issue instead.
+
+## Rebasing a Pull Request
+
+If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
+
+Github have a good guide about [rebasing in Git](https://docs.github.com/en/get-started/using-git/about-git-rebase) here's our suggested workflow:
+
+```shell
+git checkout 42-fix-some-bug
+git pull --rebase upstream develop
+git push --force-with-lease 42-fix-some-bug
+```

Cargo.toml

@@ -0,0 +1,31 @@
+[package]
+name = "icao-wgs84"
+version = "0.1.0"
+authors = ["Ken Barker <ken.barker@via-technology.aero>"]
+description = "A library for performing geometric calculations on the WGS84 ellipsoid."
+repository = "https://github.com/kenba/icao-wgs84-rs"
+readme = "README.md"
+keywords = ["geometry", "ellipsoid", "wgs84", "icao", "navigation"]
+categories = ["aerospace", "mathematics", "no-std"]
+license = "MIT"
+edition = "2021"
+publish = false
+
+[dependencies]
+angle-sc = "0.1"
+icao-units = "0.1"
+libm = "0.2"
+unit-sphere = "0.1"
+
+[dev-dependencies]
+csv = "1.1"
+serde_json = "1.0"
+
+[lints.rust]
+unsafe_code = "forbid"
+
+[lints.clippy]
+enum_glob_use = "deny"
+nursery = "deny"
+pedantic = "deny"
+unwrap_used = "deny"