pyIntensityFeatures 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- pyintensityfeatures-0.1.0/.readthedocs.yml +24 -0
- pyintensityfeatures-0.1.0/.zenodo.json +35 -0
- pyintensityfeatures-0.1.0/ACKNOWLEDGEMENTS.rst +4 -0
- pyintensityfeatures-0.1.0/CHANGELOG.md +17 -0
- pyintensityfeatures-0.1.0/CODE_OF_CONDUCT.md +75 -0
- pyintensityfeatures-0.1.0/CONTRIBUTING.md +177 -0
- pyintensityfeatures-0.1.0/LICENSE +28 -0
- pyintensityfeatures-0.1.0/MANIFEST.in +8 -0
- pyintensityfeatures-0.1.0/PKG-INFO +360 -0
- pyintensityfeatures-0.1.0/README.md +283 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/__init__.py +30 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/_main.py +500 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/instruments/__init__.py +9 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/instruments/satellites.py +137 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/proc/__init__.py +10 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/proc/boundaries.py +420 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/proc/fitting.py +374 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/proc/intensity.py +251 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/__init__.py +1 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_instruments_satellites.py +210 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_main.py +734 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_proc_boundaries.py +613 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_proc_fitting.py +218 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_proc_intensity.py +205 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_utils_checks.py +933 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_utils_coords.py +197 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_utils_distributions.py +236 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_utils_grids.py +189 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/tests/test_utils_output.py +433 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/utils/__init__.py +13 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/utils/checks.py +420 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/utils/coords.py +157 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/utils/distributions.py +199 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/utils/grids.py +113 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures/utils/output.py +276 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures.egg-info/PKG-INFO +360 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures.egg-info/SOURCES.txt +41 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures.egg-info/dependency_links.txt +1 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures.egg-info/requires.txt +21 -0
- pyintensityfeatures-0.1.0/pyIntensityFeatures.egg-info/top_level.txt +1 -0
- pyintensityfeatures-0.1.0/pyproject.toml +95 -0
- pyintensityfeatures-0.1.0/setup.cfg +15 -0
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# .readthedocs.yml
|
|
2
|
+
# Read the Docs configuration file
|
|
3
|
+
# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
|
|
4
|
+
|
|
5
|
+
# Required
|
|
6
|
+
version: 2
|
|
7
|
+
|
|
8
|
+
build:
|
|
9
|
+
os: ubuntu-22.04
|
|
10
|
+
tools:
|
|
11
|
+
python: "3.13"
|
|
12
|
+
|
|
13
|
+
# Build documentation in the docs/ directory with Sphinx
|
|
14
|
+
sphinx:
|
|
15
|
+
configuration: docs/conf.py
|
|
16
|
+
|
|
17
|
+
# Declare the Python requirements required to build your docs
|
|
18
|
+
# This method includes a local build of the package
|
|
19
|
+
python:
|
|
20
|
+
install:
|
|
21
|
+
- method: pip
|
|
22
|
+
path: .
|
|
23
|
+
extra_requirements:
|
|
24
|
+
- doc
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
{
|
|
2
|
+
"license": {
|
|
3
|
+
"id": "bsd-license"
|
|
4
|
+
},
|
|
5
|
+
"keywords": [
|
|
6
|
+
"aurora",
|
|
7
|
+
"aurora australis",
|
|
8
|
+
"aurora borealis",
|
|
9
|
+
"boundaries",
|
|
10
|
+
"imager",
|
|
11
|
+
"ionosphere",
|
|
12
|
+
"heliophysics",
|
|
13
|
+
"magnetosphere",
|
|
14
|
+
"northern lights",
|
|
15
|
+
"intensity",
|
|
16
|
+
"southern lights",
|
|
17
|
+
"features"
|
|
18
|
+
],
|
|
19
|
+
"creators": [
|
|
20
|
+
{
|
|
21
|
+
"orcid": "0000-0001-8875-9326",
|
|
22
|
+
"affiliation": "Naval Research Laboratory",
|
|
23
|
+
"name": "Angeline G. Burrell"
|
|
24
|
+
},
|
|
25
|
+
{
|
|
26
|
+
"affiliation": "KPMG",
|
|
27
|
+
"name": "Nicola S. Longden"
|
|
28
|
+
},
|
|
29
|
+
{
|
|
30
|
+
"orcid": "0000-0003-1151-5934",
|
|
31
|
+
"affiliation": "British Antarctic Survey",
|
|
32
|
+
"name": "Gareth Chisham"
|
|
33
|
+
}
|
|
34
|
+
]
|
|
35
|
+
}
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
Changelog
|
|
2
|
+
=========
|
|
3
|
+
|
|
4
|
+
Summary of all changes made since the first release
|
|
5
|
+
|
|
6
|
+
0.1.0 (2025-03-28)
|
|
7
|
+
------------------
|
|
8
|
+
* Added option to specify maximum dayglow
|
|
9
|
+
* Updated `as_datetime` to remove timezone information
|
|
10
|
+
* Added a unique function that rounds to a specified significance level
|
|
11
|
+
* Extracted code that identified the parameters for Gaussian fitting into a
|
|
12
|
+
separate function
|
|
13
|
+
* Added publication release statements
|
|
14
|
+
|
|
15
|
+
0.0.1 (2024-03-01)
|
|
16
|
+
------------------
|
|
17
|
+
* Alpha Release
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# Contributor Covenant Code of Conduct
|
|
2
|
+
|
|
3
|
+
## Our Pledge
|
|
4
|
+
|
|
5
|
+
In the interest of fostering an open and welcoming environment, we as
|
|
6
|
+
contributors and maintainers pledge to making participation in our project and
|
|
7
|
+
our community a harassment-free experience for everyone, regardless of age,
|
|
8
|
+
body size, disability, ethnicity, gender identity and expression, level of
|
|
9
|
+
experience, nationality, personal appearance, race, religion, or sexual
|
|
10
|
+
identity and orientation.
|
|
11
|
+
|
|
12
|
+
## Our Standards
|
|
13
|
+
|
|
14
|
+
Examples of behavior that contributes to creating a positive environment
|
|
15
|
+
include:
|
|
16
|
+
|
|
17
|
+
* Using welcoming and inclusive language
|
|
18
|
+
* Being respectful of differing viewpoints and experiences
|
|
19
|
+
* Gracefully accepting constructive criticism
|
|
20
|
+
* Focusing on what is best for the community
|
|
21
|
+
* Showing empathy towards other community members
|
|
22
|
+
|
|
23
|
+
Examples of unacceptable behavior by participants include:
|
|
24
|
+
|
|
25
|
+
* The use of sexualized language or imagery and unwelcome sexual attention or
|
|
26
|
+
advances
|
|
27
|
+
* Trolling, insulting/derogatory comments, and personal or political attacks
|
|
28
|
+
* Public or private harassment
|
|
29
|
+
* Publishing others' private information, such as a physical or electronic
|
|
30
|
+
address, without explicit permission
|
|
31
|
+
* Other conduct which could reasonably be considered inappropriate in a
|
|
32
|
+
professional setting
|
|
33
|
+
|
|
34
|
+
## Our Responsibilities
|
|
35
|
+
|
|
36
|
+
Project maintainers are responsible for clarifying the standards of acceptable
|
|
37
|
+
behavior and are expected to take appropriate and fair corrective action in
|
|
38
|
+
response to any instances of unacceptable behavior.
|
|
39
|
+
|
|
40
|
+
Project maintainers have the right and responsibility to remove, edit, or
|
|
41
|
+
reject comments, commits, code, wiki edits, issues, and other contributions
|
|
42
|
+
that are not aligned to this Code of Conduct, or to ban temporarily or
|
|
43
|
+
permanently any contributor for other behaviors that they deem inappropriate,
|
|
44
|
+
threatening, offensive, or harmful.
|
|
45
|
+
|
|
46
|
+
## Scope
|
|
47
|
+
|
|
48
|
+
This Code of Conduct applies both within project spaces and in public spaces
|
|
49
|
+
when an individual is representing the project or its community. Examples of
|
|
50
|
+
representing a project or community include using an official project e-mail
|
|
51
|
+
address, posting via an official social media account, or acting as an
|
|
52
|
+
appointed representative at an online or offline event. Representation of a
|
|
53
|
+
project may be further defined and clarified by project maintainers.
|
|
54
|
+
|
|
55
|
+
## Enforcement
|
|
56
|
+
|
|
57
|
+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
|
58
|
+
reported by contacting the project team at angeline.g.burrell.civ@us.navy.mil.
|
|
59
|
+
The project team will review and investigate all complaints, and will respond
|
|
60
|
+
in a way that it deems appropriate to the circumstances. The project team is
|
|
61
|
+
obligated to maintain confidentiality with regard to the reporter of an
|
|
62
|
+
incident. Further details of specific enforcement policies may be posted
|
|
63
|
+
separately.
|
|
64
|
+
|
|
65
|
+
Project maintainers who do not follow or enforce the Code of Conduct in good
|
|
66
|
+
faith may face temporary or permanent repercussions as determined by other
|
|
67
|
+
members of the project's leadership.
|
|
68
|
+
|
|
69
|
+
## Attribution
|
|
70
|
+
|
|
71
|
+
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
|
|
72
|
+
version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
|
|
73
|
+
|
|
74
|
+
[homepage]: https://contributor-covenant.org
|
|
75
|
+
[version]: https://contributor-covenant.org/version/1/4/
|
|
@@ -0,0 +1,177 @@
|
|
|
1
|
+
Contributing
|
|
2
|
+
============
|
|
3
|
+
|
|
4
|
+
Bug reports, feature suggestions, and other contributions are greatly
|
|
5
|
+
appreciated! pyIntensityFeatures is a community-driven project and welcomes
|
|
6
|
+
both feedback and contributions.
|
|
7
|
+
|
|
8
|
+
Short version
|
|
9
|
+
-------------
|
|
10
|
+
|
|
11
|
+
* Submit bug reports, feature requests, and questions at
|
|
12
|
+
[GitHub](https://github.com/aburrell/pyIntensityFeatures/issues)
|
|
13
|
+
|
|
14
|
+
* Make pull requests to the ``develop`` branch
|
|
15
|
+
|
|
16
|
+
Issues
|
|
17
|
+
------
|
|
18
|
+
|
|
19
|
+
Bug reports, questions, and feature requests should all be made as GitHub
|
|
20
|
+
Issues. Templates are provided for each type of issue, to help you include
|
|
21
|
+
all the necessary information.
|
|
22
|
+
|
|
23
|
+
Questions
|
|
24
|
+
^^^^^^^^^
|
|
25
|
+
|
|
26
|
+
Not sure how something works? Ask away! The more information you provide, the
|
|
27
|
+
easier the question will be to answer. You can also search the closed issues
|
|
28
|
+
for potential answers to your questions.
|
|
29
|
+
|
|
30
|
+
Bug reports
|
|
31
|
+
^^^^^^^^^^^
|
|
32
|
+
|
|
33
|
+
When [reporting a bug](https://github.com/aburrell/pyIntensityFeatures/issues)
|
|
34
|
+
please include:
|
|
35
|
+
|
|
36
|
+
* Your operating system name and version
|
|
37
|
+
|
|
38
|
+
* Any details about your local setup that might be helpful in troubleshooting
|
|
39
|
+
|
|
40
|
+
* Detailed steps to reproduce the bug
|
|
41
|
+
|
|
42
|
+
Feature requests and feedback
|
|
43
|
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
44
|
+
|
|
45
|
+
The best way to send feedback is to file an
|
|
46
|
+
[issue](https://github.com/aburrell/pyIntensityFeatures/issues).
|
|
47
|
+
|
|
48
|
+
If you are proposing a new feature or a change in something that already exists:
|
|
49
|
+
|
|
50
|
+
* Explain in detail how it would work.
|
|
51
|
+
|
|
52
|
+
* Keep the scope as narrow as possible, to make it easier to implement.
|
|
53
|
+
|
|
54
|
+
* Remember that this is a volunteer-driven project, and that code contributions
|
|
55
|
+
are welcome :)
|
|
56
|
+
|
|
57
|
+
Development
|
|
58
|
+
-----------
|
|
59
|
+
|
|
60
|
+
To set up `pyIntensityFeatures` for local development:
|
|
61
|
+
|
|
62
|
+
1. [Fork pyIntensityFeatures on
|
|
63
|
+
GitHub](https://github.com/aburrell/pyIntensityFeatures/fork).
|
|
64
|
+
|
|
65
|
+
2. Clone your fork locally:
|
|
66
|
+
|
|
67
|
+
```
|
|
68
|
+
git clone git@github.com:your_name_here/pyIntensityFeatures.git
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
3. Create a branch for local development:
|
|
72
|
+
|
|
73
|
+
`git checkout -b name-of-your-bugfix-or-feature`
|
|
74
|
+
|
|
75
|
+
Now you can make your changes locally.
|
|
76
|
+
|
|
77
|
+
Tests for custom functions should be added to the appropriately named file
|
|
78
|
+
in ``pyIntensityFeatures/tests``. For example, custom functions for the grid
|
|
79
|
+
utilities are tested in ``pyIntensityFeatures/tests/test_utils_grids.py``.
|
|
80
|
+
If no test file exists, then you should create one. This testing uses
|
|
81
|
+
unittest, which will run tests on any Python file in the test directory that
|
|
82
|
+
starts with ``test``. Classes must begin with ``Test``, and methods must
|
|
83
|
+
begin with ``test`` as well.
|
|
84
|
+
|
|
85
|
+
4. When you're done making changes, run all the checks to ensure that nothing
|
|
86
|
+
is broken on your local system, as well as check for flake8 compliance:
|
|
87
|
+
|
|
88
|
+
```
|
|
89
|
+
python -m unittest discover
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
5. You should also check for flake8 style compliance:
|
|
93
|
+
|
|
94
|
+
```
|
|
95
|
+
flake8 . --count --select=D,E,F,H,W --show-source --statistics
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
Note that pyIntensityFeatures tests for uniformity in docstring formatting.
|
|
99
|
+
|
|
100
|
+
6. Update/add documentation (in ``docs``). Even if you don't think it's
|
|
101
|
+
relevant, check to see if any existing examples have changed.
|
|
102
|
+
|
|
103
|
+
7. Add your name, affiliation, and ORCiD to the .zenodo.json file as an author
|
|
104
|
+
|
|
105
|
+
8. Commit your changes:
|
|
106
|
+
```
|
|
107
|
+
git add .
|
|
108
|
+
git commit -m "AAA: Brief description of your changes"
|
|
109
|
+
```
|
|
110
|
+
Where AAA is a standard shorthand for the type of change (e.g., BUG or DOC).
|
|
111
|
+
`pyIntensityFeatures` follows the [numpy development workflow](https://numpy.org/doc/stable/dev/development_workflow.html),
|
|
112
|
+
see the discussion there for a full list of this shorthand notation.
|
|
113
|
+
|
|
114
|
+
9. Once you are happy with the local changes, push to GitHub:
|
|
115
|
+
```
|
|
116
|
+
git push origin name-of-your-bugfix-or-feature
|
|
117
|
+
```
|
|
118
|
+
Note that each push will trigger the Continuous Integration workflow.
|
|
119
|
+
|
|
120
|
+
10. Submit a pull request through the GitHub website. Pull requests should be
|
|
121
|
+
made to the ``develop`` branch. Note that automated tests will be run on
|
|
122
|
+
GitHub Actions, but these must be initialized by a member of the
|
|
123
|
+
pyIntensityFeatures team for first time contributors.
|
|
124
|
+
|
|
125
|
+
|
|
126
|
+
Pull Request Guidelines
|
|
127
|
+
-----------------------
|
|
128
|
+
|
|
129
|
+
If you need some code review or feedback while you're developing the code, just
|
|
130
|
+
make a pull request. Pull requests should be made to the ``develop`` branch.
|
|
131
|
+
|
|
132
|
+
For merging, you should:
|
|
133
|
+
|
|
134
|
+
1. Include an example for use
|
|
135
|
+
2. Add a note to ``CHANGELOG.md`` about the changes
|
|
136
|
+
3. Update the author list in ``zenodo.json``, if applicable
|
|
137
|
+
4. Ensure that all checks passed (future checks will include GitHub Actions,
|
|
138
|
+
Coveralls and ReadTheDocs)
|
|
139
|
+
|
|
140
|
+
If you don't have all the necessary Python versions available locally or have
|
|
141
|
+
trouble building all the testing environments, you can rely on GitHub Actions to
|
|
142
|
+
run the tests for each change you add in the pull request. Because testing here
|
|
143
|
+
will delay tests by other developers, please ensure that the code passes all
|
|
144
|
+
tests on your local system first.
|
|
145
|
+
|
|
146
|
+
|
|
147
|
+
Project Style Guidelines
|
|
148
|
+
------------------------
|
|
149
|
+
|
|
150
|
+
In general, pyIntensityFeatures follows PEP8 and numpydoc guidelines. unittest
|
|
151
|
+
runs the unit and integration tests, flake8 checks for style, and sphinx-build
|
|
152
|
+
performs documentation tests. However, there are certain additional style
|
|
153
|
+
elements that have been adopted to ensure the project maintains a consistent
|
|
154
|
+
coding style. These include:
|
|
155
|
+
|
|
156
|
+
* Line breaks should occur before a binary operator (ignoring flake8 W503)
|
|
157
|
+
* Combine long strings using `join`
|
|
158
|
+
* Preferably break long lines on open parentheses rather than using `\`
|
|
159
|
+
* Use no more than 80 characters per line
|
|
160
|
+
* The pyIntensityFeatures logger is imported into each sub-module and provides
|
|
161
|
+
status updates at the info and warning levels (as appropriate)
|
|
162
|
+
* Several dependent packages have common nicknames, including:
|
|
163
|
+
* `import datetime as dt`
|
|
164
|
+
* `import numpy as np`
|
|
165
|
+
* `import pandas as pds`
|
|
166
|
+
* `import xarray as xr`
|
|
167
|
+
* When incrementing a timestamp, use `dt.timedelta` instead of `pds.DateOffset`
|
|
168
|
+
when possible to reduce program runtime
|
|
169
|
+
* All classes should have `__repr__` and `__str__` functions
|
|
170
|
+
* Avoid creating a try/except statement where except passes
|
|
171
|
+
* Provide testing class methods with informative failure statements and
|
|
172
|
+
descriptive, one-line docstrings
|
|
173
|
+
* Block and inline comments should use proper English grammar and punctuation
|
|
174
|
+
with the exception of single sentences in a block, which may then omit the
|
|
175
|
+
final period. Both British and American spelling is permitted.
|
|
176
|
+
* When casting is necessary, use `np.int64` and `np.float64` to ensure operating
|
|
177
|
+
system agnosticism
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
Copyright (c) 2025, Angeline G. Burrell (AGB), Gareth Chisham (GC), and
|
|
2
|
+
Nicola Longden (NL)
|
|
3
|
+
All rights reserved.
|
|
4
|
+
|
|
5
|
+
Redistribution and use in source and binary forms, with or without
|
|
6
|
+
modification, are permitted provided that the following conditions are met:
|
|
7
|
+
|
|
8
|
+
* Redistributions of source code must retain the above copyright notice, this
|
|
9
|
+
list of conditions and the following disclaimer.
|
|
10
|
+
|
|
11
|
+
* Redistributions in binary form must reproduce the above copyright notice,
|
|
12
|
+
this list of conditions and the following disclaimer in the documentation
|
|
13
|
+
and/or other materials provided with the distribution.
|
|
14
|
+
|
|
15
|
+
* Neither the name of ocbpy nor the names of its contributors may be used to
|
|
16
|
+
endorse or promote products derived from this software without specific
|
|
17
|
+
prior written permission.
|
|
18
|
+
|
|
19
|
+
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
20
|
+
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
21
|
+
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
22
|
+
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
|
|
23
|
+
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
24
|
+
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
25
|
+
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
|
|
26
|
+
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
27
|
+
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
28
|
+
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|