Mivot writer #627
Mivot writer #627
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #627 +/- ##
==========================================
+ Coverage 82.30% 82.76% +0.46%
==========================================
Files 72 75 +3
Lines 7430 7608 +178
==========================================
+ Hits 6115 6297 +182
+ Misses 1315 1311 -4 ☔ View full report in Codecov by Sentry. |
Forced pull after having squashed tiny commits dues to CI errors
docs/mivot/index.rst
Outdated
| ********************* | ||
| MIVOT (``pyvo.mivo``) | ||
| ********************* |
There was a problem hiding this comment.
typo
| ********************* | |
| MIVOT (``pyvo.mivo``) | |
| ********************* | |
| ********************** | |
| MIVOT (``pyvo.mivot``) | |
| ********************** |
pyvo/mivot/writer/annotations.py
Outdated
| blocks into VOTable files. The MIVOT block, represented as an XML structure, is used for | ||
| data model annotations in the IVOA ecosystem. | ||
|
|
||
| Features: |
There was a problem hiding this comment.
While I see the motivation for including some narrative docs with the source code, this section is not at all included in the rendered documentation as is not being part of any testing. So any information listed here likely need to be repeated and then kept in sync with the narrative docs. So my suggestion would be to remove the details from here and only have the narrative docs, as well as docstrings in any user facing functionality.
MIVOT items put together.
default pyvo.mivot content code stye add license
optional with mandatory keyword
|
The 3.11 step failed on a Simbad TAP server error |
|
The simbad failure is unrelated and I see it in This is ready for review for @astropy/pyvo-maintainers |
|
(on the current SIMBAD list of tables failure, the new table |
docs/mivot/index.rst
Outdated
|
|
||
| This module contains the new feature of annotations in VOTable. | ||
| This module contains the new feature handling model annotations in VOTable. |
There was a problem hiding this comment.
This sounds better IMO.
| This module contains the new feature handling model annotations in VOTable. | |
| This module contains the new feature of handling model annotations in VOTable. |
| - MIVOT module: If the MIVOT annotation block contains a valid instance of the | ||
| ``mango:EpochPosition`` class, the dynamic object describing the mapped | ||
| data can generate a valid SkyCoord instance. [#591] | ||
|
|
||
| - RegTAP constraints involving tables other than rr.resource are now |
There was a problem hiding this comment.
I'm wondering what happened here since this is not your change.
There was a problem hiding this comment.
I do not understand the issue, this relates to 1.6.
docs/mivot/viewer.rst
Outdated
| ------------------ | ||
| The ``ModelViewer`` module manages access to data mapped to a model through dynamically | ||
| generated objects (``MivotInstance``class). | ||
| The example below shows how can be consumed a VOTable resulting from a cone-search query which data are mapped |
There was a problem hiding this comment.
| The example below shows how can be consumed a VOTable resulting from a cone-search query which data are mapped | |
| The example below shows how a VOTable result of a cone-search query can be parsed and data mapped |
docs/mivot/viewer.rst
Outdated
| xml_view = mivot_viewer.xml_view | ||
| # do whatever you want with this XML element | ||
|
|
||
| It to be noted that ``mivot_viewer.xml_view`` is a shortcut |
There was a problem hiding this comment.
| It to be noted that ``mivot_viewer.xml_view`` is a shortcut | |
| It is to be noted that ``mivot_viewer.xml_view`` is a shortcut |
| value="BARYCENTER", | ||
| ) | ||
| space_frame.add_instance(ref_position) | ||
| space_sys.add_instance(space_frame) |
There was a problem hiding this comment.
I feel like this is too low level API for it to gain traction. My idea of this (as I probably mentioned to you in the past) would be to have the supported models part of this library. Users only have to define the mapping to the column names, maybe the units and the global values and a utility generates the corresponding json that goes into the header and the rest of the result content is streamed from the database. The utility can take an optional VOTable header to check if the columns in the mapping exist in the table. But all the other details (dmrole, dmtype, etc) are internal to the Model classes and not exposed to the user.
I would have preferred a simple example of a writer for SkyCoords where a utility requires the mapping of SkyCoords fields to column names but can generate the other details the MIVOT uses. Can that be a goal? Is it possible to implement?
There was a problem hiding this comment.
Providing a user-friendly API is the final goal of this work but it requires a low-level API allowing to build annotations step by step which is the object of this PR.
I've another PR on the track allowing to add in one callback time frames, space frames and photometric filters, defined as instances of classes of Coordinates DM and PhotDM respectively.
I propose to first merge this incoming work with #627, but this not enough to build annotations on the fly as you suggest.
I'll add another endpoint(s) allowing to add MANGO objects even if MANGO is not a REC yet. I assume that possible requested changes won't alter too much the code.
I propose to start with the 6 parameters EpochPosition, the Brightness (mag or flux) and the Color.
The API will look like:
votable = parse(votable_path)
annotations = Annotation()
annotations.add_epoch_propagation(sky_position, space_frame, time_frame, correlation, errors)
# something similar for the magnitude/color
annotations.build_mivot_block()
annotations.insert_into_votable(votable)- the parameters of
add_epoch_propagationare basically dictionaries containing tuples connecting model leaves with columns identifiers or literal values. - this API could be extended with an automatic column discovery at least for columns having unambiguous UCDs
This work will take a bit of time however.
If you agree, the PR can be frozen meanwhile it is merged with that future code.
There was a problem hiding this comment.
Thanks. It makes sense. Maybe just mention in the documentation that this is intended for developers of DM classes that want them to be annotated to VOTables and not for the end users.
API for creating and writing MIVOTY annotation
#. Create individual instances (INSTANCE) using the
MivotInstanceclass#. Wrap the annotations with the
MivotAnnotationsclass#. Insert the annotations into a VOtable by using the Astropy API (wrapped in the package logic).
The annotation builder does not check whether the XML conforms to any particular model.
It simply validates it against the MIVOT XML Schema if the
xmlvalidatorpackage if is installed.The documentation has been split in 2 separate sections (reading and writing MIVOT)