bradsease / oem Goto Github PK

Per the specification, an OEM may only contain one object, even though each metadata field has its own OBJECT_NAME and OBJECT_ID entry. Constrain these fields to be consistent across all segments.

From section 5.1.3 of the specification:

The OEM shall be a plain text file consisting of orbit data for a single object.

Implement an interface to build and write an ASCII OEM to a file.

Currently all epochs are represented by basic DateTime objects. Instead, epochs should be astropy Time objects with the correct timescale.

It would be great if the documentation would include the correct methind to create an of OEM file starting from existing epochs, position and velocity vectors data.

I tried to do it using the classe interfaces description, but at some point I get stuck.
First, for each state vector I create a State object, and I collect them in a list.
Then I proceeded by creating Metadata, EphemerisSegment, HeaderSection.
Finally I try to bring all together creating an OrbitEphemerisMessage.

At this point I get an error message complaining about State objects not being iterable, when the OrbitEphemerisMessage constgructor parses the list of state_data in the EphemerisSegment object.

...
    for entry in zip(*self._state_data)
                 ^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'State' object is not iterable

After many attempts, and trying to do it right by reading the source code, I think the problem might be that the classes are not designed to support the creation of objects via code, rather just from importing from text files.

It could be very a very interesting feature to support the creation of OEM files via code, essentially adding the inverse of what this super nice library is doing so far.

Dates can be represented in two ways in an OEM (spec):

YYYY-MM-DDThh:mm:ss[.d→d][Z]

or

YYYY-DDDThh:mm:ss[.d→d][Z]

The oem package currently only supports the first format. Add support for this epoch format.

Reference documents have moved.

Implement an interface to build and write an XML OEM to a file.

Current implementation uses xml.etree and could be vulnerable to maliciously constructed XML files.

The current implementation assumes version 2.0. Adapt the code to handle 1.0 and possible future versions.

Document the use of OrbitEphemerisMessage.save_as for both KVN and XML formats.

Describe the bug
I've originally came across your samples folder in a google search when looking for other example OEM other than the ones provided in ccsds2czml: https://gitlab.com/jorispio/ccsds2czml/-/tree/master/example

All OEM files in samples/real threw a generic datetime microsecond error, but i could not discern any differences between your OEMs and the sample_OEM generated by ccsds2czml. Their sample_OEM worked fine. Below is the traceback error:

C:\Users\khoohuibo\Desktop\ccsds2czml-master>python -m oacmpy -i LEO_10s.oem -o one_sat.czml -v
Input File : LEO_10s.oem
Output File: one_sat.czml
  File:  LEO_10s.oem
Traceback (most recent call last):
  File "C:\Users\Hubert Khoo\.conda\envs\arcsim\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Users\Hubert Khoo\.conda\envs\arcsim\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\Hubert Khoo\.conda\envs\arcsim\lib\site-packages\oacmpy\__main__.py", line 5, in <module>
    main(sys.argv[1:])
  File "C:\Users\Hubert Khoo\.conda\envs\arcsim\lib\site-packages\oacmpy\oem2czml.py", line 78, in main
    _ccsds2czml(inputfile, outputfile, verbose)
  File "C:\Users\Hubert Khoo\.conda\envs\arcsim\lib\site-packages\oacmpy\oem2czml.py", line 35, in _ccsds2czml
    print(" Simulation time span: {} - {}".format(start, end))
  File "C:\Users\Hubert Khoo\.conda\envs\arcsim\lib\site-packages\oacmpy\datetime\Date.py", line 297, in __str__
    return self.strftime(ISO8601_FORMAT_Z)
  File "C:\Users\Hubert Khoo\.conda\envs\arcsim\lib\site-packages\oacmpy\datetime\Date.py", line 291, in strftime
    return self.datetime.strftime(fmt)
  File "C:\Users\Hubert Khoo\.conda\envs\arcsim\lib\site-packages\oacmpy\datetime\Date.py", line 251, in datetime
    self._datetime = datetime(year=year, month=month, day=day, hour=h, minute=m, second=s, microsecond=ms)
ValueError: microsecond must be in 0..999999

I have attached the sample_object.oem file generated for easier reference
sample_object.zip

Steps to Reproduce

1. Download both repositories
2. Run the following code in the root directory of ccsds2czml-master to generate a sample_OEM file

python -m example.single.simple_oem

3. Generate CZML file using sample_object.oem file generated in root directory of ccsds2czml-master, using the code below

python -m oacmpy -i sample_object.oem -o one_sat.czml -v

4. Visualize using Cesium Viewer
5. Attempt to generate CZML file by using OEM file from oem-master/samples/real, (Used LEO_10s and GEO_20s)
6. Obtain traceback error as described

# Insert reproducing code snippet here

Python/Package Version Information
Python: [e.g. 3.5.1]
oem: [e.g. 1.0.0]

Describe the bug
When converting a KVN to XML, all timestamps are rounded to milliseconds. In the attached KVN, there are two states with very similar timestamps:

2024-02-08T19:46:03.597928Z 1333.6205090564652 -6664.216903368751 1161.3835966195354 -0.7481968331279982 -1.4443848679898943 -7.428717332913011
2024-02-08T19:46:03.597932Z 1333.6205060636762 -6664.216909146293 1161.3835669046564 -0.7481968396231843 -1.4443848355343534 -7.42871733858515

oem.kvn.txt

This causes error when loading the XML, because the timestamps get rounded to the same value:

2024-02-08T19:46:03.598
2024-02-08T19:46:03.598

Steps to Reproduce

from oem import OrbitEphemerisMessage
OrbitEphemerisMessage.convert("oem.kvn", "oem.xml","xml") # succeeds
ephemeris = OrbitEphemerisMessage.open("oem.xml") # fails

Python/Package Version Information
Python: [3.10.14]
oem: [0.4.2]

Describe the bug
When importing an OEM file in KVN format with a size of 450 MB which contains about 7 years of trajectory data the regex match statement in _from_kvm_oem() immediately hogs > 16GB RAM and gets killed. Maybe a transition to a slower, but more stable state machine processing line by line as in https://gitlab.com/jorispio/ccsds2czml. Although the parsing algorithm there is also behaving poorly with multiple segments.

I've tried to use google/re2 python wrappers for a more efficient processing of the file, but still fails.
I'll take a look on rewriting the parser.

Edit: only the match() call seems to create issues, find_all() and running the match for the header section separately works fine.

Describe the bug
Hey, great library! I am hoping to use this as part of the framework for a library I'm working on to easily interact with the various SSA providers. So far it's a great experience. Very clean and readable. Kudos!

I noticed while testing with it that, while I am able to load a KVN file in general, I am not able to load one of the KVN files that is produced from the OrbitEphemerisObject itself. It fails with the error:
ValueError: States in data section are not ordered by epoch
Example below. The initial input OEM file is attached. Let me know if I'm just doing something wrong and this is not a real issue. Thanks!

Steps to Reproduce

from oem import OrbitEphemerisMessage

ephemeris = OrbitEphemerisMessage.open("oem_file_ccsds.txt") # works
ephemeris.save_as("oem_output.kvn") # by visual inspection, looks like a correct OEM
ephemeris = OrbitEphemerisMessage.open("oem_output.kvn") # fails

oem_file_ccsds.txt

Python/Package Version Information
Python: [3.11.3]
oem: [0.4.1]

KVN ephemeris parsing is still fairly inefficient. Streamline the parser to reduce processing time and memory used.

EphemerisSegment do not currently check if a particular epoch is contained within before calling the interpolator.

The current setup.py is configured for CI/CD use only and does not properly support local builds. Find a solution that works for both.

Issue noted in PR #69

Implement a simple interface for accessing segments in an OEM without iterating. The current architecture requires something like:

segments = [entry for entry in ephemeris]

Set up Gitlab testing for multiple versions of Python. Current testing is limited to Python 3.8.

The OrbitalEphemerisMessage object should provide a method that samples the ephemeris at a particular time.

The OrbitalEphemerisMessage object should constrain its segments to all use the same TIME_SYSTEM.

From the OEM specification:

The TIME_SYSTEM value must remain fixed within an OEM.

Add function to compare two OEM objects that use the same frame and central body.

Implement a tool to facilitate OEM generation from a TLE.

This warning appears when interpolating OEMs:

__main__:1: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16 and will raise an error in the future.

The sources are np.vstack calls with generators on lines 103 and 122 of oem.interp.

The spec is flexible on floating point vs fixed and precision, so it could be helpful if output was configurable

The oem module should be capable of parsing both KVN and XML ephemerides.

Describe the bug
In the parse_kvn_oem method, if the CCSDS_OEM_VERS keyword is missing as the first line, the err method is called but is missing the line_number parameter value. This results in a TypeError being thrown.

https://github.com/bradsease/oem/blob/main/oem/parsers.py#L53

PR for fix: #81

Steps to Reproduce
Provide any OEM file that does not have the CCSDS_OEM_VERS keyword as the first line

Python/Package Version Information
Python: [e.g. 3.5.1] 3.11.6
oem: [e.g. 1.0.0] 0.4.0

Describe the bug
Using an existing OEM file the string (header key) "USABLE_START_TIME" was found to be invalid: an error on that string was raised. Apparently all corresponding keys found in the metadata.py module to contain a typo ("USEABLE_...") need to be corrected to "USABLE_..."; a performed test (changing key in metadata.py) was resulting in the code to successfully accept the corrected key.

Steps to Reproduce

• introduce test header items "USABLE_START_TIME" (and USABLE_STOP_TIME) plus a suited/valid value into any OEM sample file;
• check for error messaging;

# Insert reproducing code snippet here

#
# not needed, please see description of the proposed reproduction steps
#

**Python/Package Version Information**
Python: v3.9.5
oem: v0.3.3