asdf-format / asdf-transform-schemas Goto Github PK

Part of issue astropy/asdf-astropy#6.

This is a catch all ticket for documentation bugs/fixes.

• One example in the remap_axes documentation is not correct - suggest removing it.
  It claims the two examples below are equivalent:

!transform/remap_axes-1.3.0
  mapping: [0, 0, 1]

!transform/concatenate-1.2.0
  forward:
    - !transform/remap_axes-1.3.0
      mapping: [0]
    - !transform/remap_axes-1.3.0
      mapping: [1]

• The "direction" field in the projection schemas has no description.

• The order of inputs and outputs in the projection schemas should be specified in the documentation.

• rotate2d should specify the direction of rotation - counterclockwsise.

• inputs and outputs of rotations:

  • Rotate2D: the inputs and outputs are always Cartesian (x,y)
  • Rotate3D: the inputs and outputs are always spherical (lon,lat)
  • RotateSequence: the inputs and outputs are Cartesian or spherical
    depending on the value of "rotation_type".

  If this is correct, it may be an idea to say this explicitly in the schemas.

• In

  https://asdf-standard.readthedocs.io/en/1.5.0/file_layout.html

  under "Tree", it says "The tree must contain exactly one YAML
  document, starting with --- (YAML document start marker) and ending
  with ... (YAML document end marker), each on their own line." But then
  the following example shows the start marker NOT on its own line:

  --- !core/asdf-1.0.0

The new release fails a unit test with release versions of dependencies:

[   13s] python39-asdf-3.1.0-52.1              ########################################
...
[   13s] python39-asdf-coordinates-schemas-0.3.########################################
...
[   15s] python39-pyerfa-2.0.1.1-30.29         ########################################
[   15s] python39-asdf-astropy-0.5.0-29.11     ########################################
[   16s] python39-astropy-6.0.0-121.1          ########################################
...
[   22s] + pytest-3.9 --ignore=_build.python39 --ignore=_build.python310 --ignore=_build.python312 --ignore=_build.python311 -v -v
[   22s] ============================= test session starts ==============================
[   22s] platform linux -- Python 3.9.18, pytest-7.4.4, pluggy-1.3.0 -- /usr/bin/python3.9
[   22s] cachedir: .pytest_cache
[   22s] rootdir: /home/abuild/rpmbuild/BUILD/asdf_transform_schemas-0.5.0
[   22s] configfile: pyproject.toml
[   22s] testpaths: tests, resources
[   22s] plugins: asdf-3.1.0
[   24s] collecting ... collected 892 items
...
[  102s] 
[  102s] self = <asdf_astropy.converters.transform.compound.CompoundConverter object at 0x7f29590b2d00>
[  102s] node = {'forward': [{'mapping': [1]}, {'offset': 6.0}]}
[  102s] tag = 'tag:stsci.edu:asdf/transform/compose-1.2.0'
[  102s] ctx = <asdf.extension._serialization_context.ReadBlocksContext object at 0x7f2958bf98e0>
[  102s] 
[  102s]     def from_yaml_tree_transform(self, node, tag, ctx):
[  102s]         from astropy.modeling.core import CompoundModel, Model
[  102s]     
[  102s]         oper = _TAG_NAME_TO_MODEL_METHOD[get_tag_name(tag)]
[  102s]     
[  102s]         left = node["forward"][0]
[  102s]         if not isinstance(left, Model):
[  102s]             msg = f"Unknown left model type '{node['forward'][0]._tag}'"
[  102s] >           raise TypeError(msg)
[  102s] E           TypeError: Unknown left model type 'tag:stsci.edu:asdf/transform/remap_axes-1.4.0'
[  102s] 
[  102s] /usr/lib/python3.9/site-packages/asdf_astropy/converters/transform/compound.py:80: TypeError
[  102s] ----------------------------- Captured stdout call -----------------------------
[  102s] Example: Map a number within a range of numbers to transforms which return labels.
[  102s]  From file: /home/abuild/rpmbuild/BUILD/asdf_transform_schemas-0.5.0/resources/stsci.edu/schemas/label_mapper-1.3.0.yaml
[  102s] =========================== short test summary info ============================
[  102s] FAILED resources/stsci.edu/schemas/label_mapper-1.3.0.yaml::test_example_2 - ...
[  102s] =================== 1 failed, 891 passed in 79.76s (0:01:19) ===================

I guess this is a similar sitation as asdf-format/asdf-coordinates-schemas#59

Currently, there is no tag for the fix_inputs-1.1.0 schema in any of the provided manifests. This will begin to cause problems when astropy 5.1 is released as the old-style CustomType extensions for the transforms are being deprecated in favor of the Converter extensions in the asdf-astropy package.

• The schema says the default for the lambda parameter of the CEA projection is zero, but FITS-WCS paper 2 says the default should be 1.0.
• The mu and lambda parameters for CYP should have default 1.0 but the schema gives a default of zero for both.
• The theta1 parameter of the BON projection has no default in the paper but has default zero in the schema.
• FITS-WCS paper 2 says that the first parameter for a conic (theta_A or sigma) has no default, but the schema gives it a default of zero.
• A fairly minor point but the names used in the schemas for the parameters of the conic projections
  (sigma and delta) do not match the names used in FITS-WCS paper 2 (theta_A and eta).

rotate3d enumerates the possible combinations of axis. We should check they are all listed and possibly improve documentation. "xyz" is missing.

It improve the documentation for the asdf-astropy package, documentation of the schemas in this package should be generated.

As it stands now the converter code serializes Model attributes which are not in the schema. This means other libraries have no way of knowing that they exist and how to interpret them. Attributes like bounding_box, inputs, outputs, etc. should be added to the base Transform schema.

astropy writes the following bounding box-related properties when serializing a model:

bounding_box
selector_args
cbbox_keys
cbbox_values

but these aren't documented in any of the schemas.

The Schechter1D model was introduced to astropy in astropy/astropy#13116, a schema needs to be added for this model.

It is unclear why the ZPN projection is not implemented in astropy.modeling or the schemas. There may be a good reason why it's missing but it's not documented anywhere.
If this was a simple omission it should be implemented.

astropy serializes the following properties:

fixed
bounds

but these are not documented in the schemas.

The current schemas for compound transforms allow an array of transforms with no limit on the number of arrays. The python library implementation and AST work on two transforms at a time.
Consider modifying the schemas to specify only two transforms are allowed. This should be explained in the documentation.

After upgrading the asdf package to 3.0.0, the unit tests errors with

ImportError while importing test module '/tmp/autopkgtest-lxc.ikfr6p4l/downtmp/build.W9D/src/tests/test_invalid.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
../build.W9D/src/tests/test_invalid.py:3: in <module>
    from asdf.tests import helpers
E   ModuleNotFoundError: No module named 'asdf.tests'

Full test log here.

Just replacing asdf.tests with asdf.testing makes all tests in test_invalid.py fail:

_ test_failing_schema[\n    !transform/shift-1.2.0\n      offset: 1\n      bounding_box: [1.0, test]\n    ] _

yaml = '\n    !transform/shift-1.2.0\n      offset: 1\n      bounding_box: [1.0, test]\n    '

    @pytest.mark.parametrize("yaml", purposefully_failing)
    def test_failing_schema(yaml):
        buff = helpers.yaml_to_asdf(f"example: {yaml.strip()}")
>       with pytest.raises(asdf.ValidationError, match=r"Failed validating *"):
E       Failed: DID NOT RAISE <class 'asdf._jsonschema.exceptions.ValidationError'>

tests/test_invalid.py:324: Failed

I didn't check the unreleased "main" branch. If this is supposed to be fixed: could I ask to make a new release then? Or can you point me to the fix?

Some schemas already support this, for example affine.

Astropy normally writes out these as numpy arrays. However, a different library may be writing them out as arrays.

Part of Roadmap 2.0.0 discussion

The SIN projection is defined by two parameters.
The schema does not define them.
See WCS Paper II for reference.

astropy serializes model inputs and outputs when writing a model file, but these properties are not documented in the schemas.