CoordsRFC2 < IVOA

---+ STC2:Coords Proposed Recommendation: Request for Comments #2

   * [[CoordsRFC#STC2_Coords_Proposed_Recommendat][ STC2:Coords Proposed Recommendation: Request for Comments]] 
      * [[CoordsRFC#Summary][ Summary]]
      * [[CoordsRFC#Implementation_Requirements][ Implementation Requirements]]
      * [[CoordsRFC#Validators][ Validators]]
      * [[CoordsRFC#Links_with_Meas][ Links with Meas]]
      * [[CoordsRFC#Comments_from_the_IVOA_Community][ Comments from the IVOA Community during RFC/TCG review period: 2019-09-17 - 2019-10-21]]
      * [[CoordsRFC#Comments_from_TCG_member_during][ Comments from TCG member during the RFC/TCG Review Period: 2019-09-17 - 2019-10-21]]
      * [[CoordsRFC#RFC_Close_out_Response][ RFC Close-out Response:]]
      * [[CoordsRFC#TCG_Vote][ TCG Vote:]]

---

<span style="color: orangered;"> *WATCHOUT*: This RFC page has been replaces <a target="_blank" href="CoordsRFC">RFC#1</a> </span>

*Rationale for a second RFC round:*
   * Many comments have been collected after RFC #1. Some of them just required text improvements but some others implied significant model changes, especially for Coords.
   * A global RFC answer has been sent to WG mailing list in February 2020: &lt;a target="_blank" href="http://mail.ivoa.net/pipermail/dm/2020-February/005975.html"&gt;answer&lt;/a&gt;
   * These data models should support the description of datasets and DAL responses, by defining fundamental elements which are commonly used in many contexts. The intent is that they be imported as components in these more complex models so that they all build from the same basis, thereby enhancing interoperability.
   * They should NOT be expected to fully support any use-cases outside of the described set. For example, they cannot currently support the complex error types found in various Catalogs. These use-cases are to be considered in future updates to the models.
   * Measurements cannot be used without Coords because the latest is imported by Measurements but Coords can be used in some other contexts e.g. Transform.
   * The nature of the changes in Coords, that impacts Measurements thus, led the TCG to decided on 2020-10-8 a second RFC round for both models.
---

---++ <a name="Summary"></a>
---++ &lt;a name="Why RFC #2"&gt;&lt;/a&gt; Summary

TBC

Many comments were collected after RFC #1. Some of them just required text împrovements but some others implied significant model changes, especially for _Coords_.

A global RFC answer has been sent to WG mailing list in February 2020: <a target="_blank" href="http://mail.ivoa.net/pipermail/dm/2020-February/005975.html" title="Global RFC answer">answer</a>.

Theses models do not aim at being used as such to describe dataset classes or DAL responses. They must be seen as component boxes for top level models such as _CubeDM_ or _Mango_.

This is the reason why _Measurements_ and _Coords_ have been split. _Measurements_ cannot be used without _Coords_ because the lastest in imported by _Measurements_ but _Coords_ can be used in some other contexts e.g. _Transform_.

The nature of the changes in Coords, that impacts Measurements as well, led the TCG to decided on 2020-10-8 a second RFC round for both model.

---++ <a name="Summary"></a> Summary

Version 1 of [[STC]] was developed in 2007, prior to the development and adoption of vo-dml modeling practices. As we progress to the development of vo-dml compliant component models, it is necessary to revisit those models which define core content. Additionally, the scope of the [[STC]]-1.0 model is very broad, making a complete implementation and development of validators, very difficult. As such it may be prudent to break the content of [[STC]]-1.0 into component models itself, which as a group, cover the scope of the original.

This effort will start from first principles with respect to defining a specific project use-case, from which requirements will be drawn, satisfied by the model, and implemented in the use-case. We will make use of the original model to ensure that the coverage of concepts is complete and that the models will be compatible. However, the form and structure may be quite different. This model will use vo-dml modeling practices, and model elements may be structured differently to more efficiently represent the concepts.

This model describes the Coordinates model and covers the following concepts.
   * Description of single and multi-dimensional coordinate space, and coordinates within that space.
   * Coordinate Frames, providing metadata describing the origin and orientation of the coordinate space.
   * Definition of simple domain-specific coordinate types for the most common use cases.
   * Coordinate Systems, a collection of coordinate frames.
The latest version of the model and supporting docs:
   * Model document: <a target="_top" href="http://www.ivoa.net/documents/Coords/index.html">here</a>
   * VO-DML/XML representation: <a target="_top" href="http://www.ivoa.net/xml/STC/STC_coords-v1.0.vo-dml.xml">here</a>
   * XML Schema: <a target="_top" href="https://volute.g-vo.org/svn/trunk/projects/dm/STC/Coords/vo-dml/Coords_v1.0.xsd">here</a>
---++ <a name="Implementation_Requirements"></a> Implementation Requirements

(from [[IvoaDataModel#Specifications][DM Working group twiki]]):

The "IVOA Document Standards" standard has a broad outline of the implementation requirements for IVOA standards. These requirements fit best into the higher level standards for applications and protocols than for data models themselves. At the Oct 2017 interop in Trieste, the following implementation requirements for Data Model Standards was agreed upon, which allow the models to be vetted against their requirements and use cases, without needing full science use cases to be implemented.
   * VO-DML models must validate against schema
   * Serializations which touch each entity of the model. These serializations may be 'fake' (ie: not based on actual data files), and are to be produced by the modeler as unit tests/examples.
   * Real world serializations covering use cases, produced by others following the model, in a mutually agreed upon format.
   * Software which interprets these serializations and demonstrates proper interpretation of the content.
---+++ <a name="VO_DML_Validation"></a> VO-DML Validation:
   * The Coords model was developed using the Modelio UML tool, and exported to xmi format.
   * The xmi model description was then processed using an xslt script into VO-DML/XML format.
   * This VO-DML/XML format file was then validated against the vo-dml schema with no reported violations. 
      * the xml file is available in the IVOA document repository, <a target="_top" href="http://www.ivoa.net/xml/STC/STC_coords-v1.0.vo-dml.xml">here</a>.
---+++ <a name="Serializations"></a> Serializations:
   * Modeler Generated Examples: 
      * using home grown python code, the modeler has generated <a target="_top" href="https://volute.g-vo.org/svn/trunk/projects/dm/STC/Coords/examples/">example serializations</a> which span all elements of the model. The examples are generated in 4 formats: 
         * VOTable-1.3 standard syntax; Validates using votlint
         * VOTable-1.3 annotated with VO-DML/Mapping syntax; Validates using xmllint to a VOTable-1.3 schema enhanced with an imported <a target="_top" href="https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/xsd/votable_ext/VOTable-1.4_vodml.xsd">VO-DML mapping syntax schema</a>
         * XML format; Validates against the model schema
         * An internal DOC format; XML/DOM structure representing the instances generated when interpreting the instance templates.
   * Real world serializations: 
      * jovial: A set of example serializations of various Coordinate and Measurement instances generated by Omar Laurino using his Jovial DSL package 
         * <a target="_blank" href="https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/03/Coords.html">https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/03/Coords.html</a>
         * <a target="_top" href="https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/02/STC-current.html">https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/02/STC-current.html</a> - examples of Measurement and Coords based on earlier versions of the models
      * TDIG: Working project of Time Series as Cube. 
         * Example serializations have been generated using various annotation schemes to identify the model elements: <a target="_top" href="https://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/standardized_votables/">here</a>. 
            * these include elements from the Measurement and Coordinates models
      * VOTable: COOSYS 
         * this represents a standardized serialization of a Coordinate model <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SpaceFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SpaceFrame (this topic does not yet exist; you can create it)">SpaceFrame</a> 
            * COOSYS =&gt; <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SpaceFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SpaceFrame (this topic does not yet exist; you can create it)">SpaceFrame</a>
            * COOSYS.system =&gt; <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SpaceFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SpaceFrame (this topic does not yet exist; you can create it)">SpaceFrame</a>.spaceRefFrame
            * COOSYS.equinox =&gt; <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SpaceFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SpaceFrame (this topic does not yet exist; you can create it)">SpaceFrame</a>.equinox
            * COOSYS.epoch =&gt; would map to epoch of a particular measurement set, outside the scope of <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SpaceFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SpaceFrame (this topic does not yet exist; you can create it)">SpaceFrame</a>
            * NOTE: COOSYS lacks the 'refPosition' present in <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SpaceFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SpaceFrame (this topic does not yet exist; you can create it)">SpaceFrame</a>.. this is on the list as a probable enhancement to COOSYS
      * VOTable TIMESYS 
         * recently adopted into VOTable 1.4, this is similarly, a standardized serialization of Coordinate model <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/TimeFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="TimeFrame (this topic does not yet exist; you can create it)">TimeFrame</a>
         * TIMESYS =&gt; <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/TimeFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="TimeFrame (this topic does not yet exist; you can create it)">TimeFrame</a>
         * TIMESYS.timescale =&gt; <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/TimeFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="TimeFrame (this topic does not yet exist; you can create it)">TimeFrame</a>.timescale
         * TIMESYS.refPosition =&gt; <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/TimeFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="TimeFrame (this topic does not yet exist; you can create it)">TimeFrame</a>.refPosition
         * TIMESYS.timeorigin =&gt; <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/TimeOffset?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="TimeOffset (this topic does not yet exist; you can create it)">TimeOffset</a>.time0; centralizing this information high in the serialization
---+++ <a name="Software"></a> Software:
   * vodml Parser: Notebook developed by Omar Laurino parses vo-dml/Mapping annotation to generate instances of TimeSeries -Cube-Meas-Coord using <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/AstroPy?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="AstroPy (this topic does not yet exist; you can create it)">AstroPy</a> and generates plots of the content using Matplotlib. Note: this was developed and presented in 2017 using earlier drafts of the models. These vary only in detail, and the demo could be updated to the current model suite. 
      * <a target="_top" href="https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/10/PythonParserDemo.html">https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/10/PythonParserDemo.html</a>
   * TDIG: Working project of Time Series as Cube. 
      * An ongoing project is underway to enhance SPLAT to load/interpret/analyze TimeSeries data. This was most recently presented at the IVOA Interop in Paris 2019 (see <a target="_top" href="https://wiki.ivoa.net/internal/IVOA/InterOpMay2019TDIG/splat_timeseries.pdf">PDF</a>)
      * The tool currently uses a combination of TIMESYS, table column descriptions, UCDs and UTypes to identify and interpret the data automatically. Each of these are annotation schemes which tie directly to model components.
      * Delays in resolving on a standard annotation syntax has delayed progress on this project to fully realize the possibilities. This is a high-priority for upcoming work.
   * pyVO: extract_skycoord_from_votable() 
      * Demonstrated at the IVOA Interop in Paris 2019, this product of the hack-a-thon generates <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/AstroPy?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="AstroPy (this topic does not yet exist; you can create it)">AstroPy</a> <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SkyCoord?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SkyCoord (this topic does not yet exist; you can create it)">SkyCoord</a> instances from VOTables using various elements embedded in the VOTable. 
         * Interrogates a VOTable-1.3 serialization, identifies key information and uses that to automatically generate instances of <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SkyCoord?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SkyCoord (this topic does not yet exist; you can create it)">SkyCoord</a>. 
            * UCD: 'pos.eq.ra', 'pos.eq.dec'
            * COOSYS.system: "ICRS", "FK4", "FK5"
            * COOSYS.equinox
         * The COOSYS maps directly to <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SpaceFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SpaceFrame (this topic does not yet exist; you can create it)">SpaceFrame</a>, and the value of the system
         * The UCD 'pos.eq' maps directly to meas:EquatorialPosition; with 'pos.eq.ra|dec' identifying the corresponding attributes (<a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/EquatorialPosition?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="EquatorialPosition (this topic does not yet exist; you can create it)">EquatorialPosition</a>.ra|dec) as coordinates coords:Longitude and coords:Latitude.
         * This illustrates that even with minimal annotation, this sort of automatic discovery/instantiation can take place. With a defined annotation syntax, this utility could be expanded to generate other <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/AstroPy?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="AstroPy (this topic does not yet exist; you can create it)">AstroPy</a> objects very easily.
   * AST: Starlink's library for handline World Coordinate Systems 
      * An ongoing project to exercise the Transform model is being worked, which includes pulling in elements from the Coordinates model to define the 'Frames' on either end of the transform.
      * This work is being done with YAML serializations, annotated to the model elements
      * Currently includes the <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/CoordSpace?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="CoordSpace (this topic does not yet exist; you can create it)">CoordSpace</a>, <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/PixelSpace?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="PixelSpace (this topic does not yet exist; you can create it)">PixelSpace</a> and <a rel="nofollow" href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/SpaceFrame?topicparent=IVOA.CoordsRFC;nowysiwyg=0" title="SpaceFrame (this topic does not yet exist; you can create it)">SpaceFrame</a> elements. There is a high level of correlation between the AST Frame objects and the Coordinate model elements.
   * 
      * 
         * 
---++ <a name="Validators"></a> Validators

As noted above, the serializations may be validated to various degrees using the corresponding schema
   * VOTable-1.3 using votlint: verifies the serialization complies with VOTable syntax
   * VOTable-1.3 + [[VODML]]: verifies the serialization is properly annotated
   * XML using xmllint with model schema: verifies the serialization is a valid instance of the model.
   * NOTE: The modeler examples undergo all levels of validation, showing that the VOTable serializations are also valid instances of the model.
I don't believe there are validators for the various software utilities. Their purpose is to show that given an agreed serialization which can be mapped to the model(s), the data can be interpreted in an accurate and useful manner.

---++ <a name="Links_with_Meas"></a> Links with Meas

The Coordinates model a base component, primarily used to support the development of other models. Most significantly is in support of the Measurement model, which is the core model of interest to most use cases. Information about the relation to that model, how the use case requirements divide up, etc. can be found on the <a target="_top" href="STC2">STC2 page</a>

---++ Comments from the IVOA Community during RFC/TCG review period: 2020-10-26 - 2020-12-07

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

   * Sample comment by TWiki.WikiName 
      * Response (by TWiki.WikiName)

---+++ Comments by Markus Demleitner

(1) I'm really unhappy with what the document gives as "use cases". To me, a use case says something like "User is doing X, client can do Y because of what we're specifying here". Only from something like that one can reliably derive requirements -- and avoid discussions like "should features A and B be in there at this moment?" Contrast this with "exercise the transform model" -- I can derive anything or nothing from that. Can we have use cases that actually describe uses, as in "Bring two catalogues on the same epoch" or "Overplot objects from a catalogue on a calibrated image"?

(2) As in the STC1 days, I still disagree quite strongly with treating JD, MJD, and ISOTime at the modelling level. It's true that ISO time is a bit special in that it's not just a float continuing on and you certainly don't want free offsets on that, but still: that's container-level serialisation, and JD and MJD aren't special in any way over any other sort of floating-point time. Can't we just follow what TIMESYS in VOTable does?

(3) The cardinal sin of any data model is trying to do too much; since polarisation sticks out as not really related to anything in this model and it's only mentioned in a single requirement the source of which remains unclear: Can't we take it out and save it for later, when we have real use cases?

(4) What would the ~coordSys of a !BinnedCoordinate be? Talking about !BinnedCoordinate: I don't think it's a good idea to talk about pixels too much here -- most people will encounter pixels as a coordinate system on their CCD frames, and there, they normally don't look at integral pixels, and they very certainly shouldn't use !BinnedCoordinates. Come to think of it: When would they use them anyway? Perhaps that's another thing we can postpone?

(5) Since all times are offsets (from what's called their epoch in timekeeping), I fail to see why we would have !TimeOffset and !TimeInstant as separate classes.

(6) Since we know about !TimeInstant: Why would Epoch not just use that but rather uses an ad-hoc time serialisation?

(7) I still think it's a bad idea to consider temperature or flux as "coordinates". If you want "coordinate" to mean anything, it's linked to vector spaces, and neither temperature nor flux make sense as a vector component as such. Why would you want to do that?

(8) What's the use case for your Axis objects? For instance, is it expected that RA is explicitly marked as a cyclic axis? I see requirements coords.001 and coords.002 referenced, but I, really, still can't tell what a client would do with this information.

(9) I'm afraid I don't find any of the "reference implementations" terribly convincing. There's far too much "work in progress" or "previous version". At least having one thing where we could see as many of the (IMHO too many) features of this model at work as possible would help mollify my concerns that very little of what is written in the spec has actually been tried out.

-- IVOA.MarkusDemleitner - 2020-11-25

---
---

---++ Comments from TCG member during the RFC/TCG Review Period: 2020-10-26 - 2020-12-07

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

---+++ TCG Chair & Vice Chair

---+++ [[IvoaApplications][Applications Working Group]]

---+++ [[IvoaDAL][Data Access Layer Working Group]]

---+++ [[IvoaDataModel][Data Model Working Group]]

After having tested the model on different Vizier tables (see the _globals_ section [[https://github.com/ivoa-std/ModelInstanceInVot/blob/master/python_workflow/data/annotated_data/vizier_propermotion.annot.xml][here]]). I suggest a modification in the sky coordinates .<br />Sky coordinates are now reprensented by a 3D vector (coords:Point).<br />The role of the 3 axis (lon/lat or xyz) is given by the axis descriptions that is part of the coordinate system (coords:SpaceSys).<br />It would be quite more simpler to have an abstract class (e.g. Point) with 4 concrete sub classes:
   * The current Point (renamed as GenericPoint?)
   * CartesianPoint (x,y,z)
   * SphericalPoint (r, theta, phi)
   * CelestianPoint (lon, lat) &lt;-- Not sure about the name, could be LonLatPoint.
The wouldn't break anything since the abstract class Point could be used everywhere in replacemement of the current one.

This keep the independance of the sky coordinates and the sky frames.

This change would significantly simplify the data annotation.
---+++ [[IvoaGridAndWebServices][Grid & Web Services Working Group]]

---+++ [[IvoaResReg][Registry Working Group]]

---+++ [[IvoaSemantics][Semantics Working Group]]

Two spots in the current PR are spots of trouble for Semantics:

(1) You shouldn't include the vocabularies (as in appendix C) in the specification -- that'll only tempt people to use exactly what's mentioned there in their software. A brief comment to the effect that software is encouraged to regularly update their lists or so would of course be welcome, as would be comments on the general architecture or quirks (like the old VOTable COOSYS names). The complete list, however, will just be outdated after a while, and people will curse us because we apparently publish contradicting information. Plus, it'll shave off a few more pages, which might lessen peoples' aversion against takeup.

(2) The vocabulary http://www.ivoa.net/rdf/refframe definitely isn't good for REC yet. In particular:

   * I'm rather sure that we either need to re-define GENERIC_GALACTIC or make SUPER_GALACTIC independent of GENERIC_GALACTIC (did I really do this?)
   * figure out what barycentric was (I fear it's a conflation of ICRS and refpos BARYCENTER -- what do we do then?) It's one of the VOTable legacy terms. Perhaps we're lucky and nobody has ever used it?
   * figure out what geo_app was in VOTable COOSYS -- or drop it.
Volunteers for cleaning this up?

-- IVOA.MarkusDemleitner - 2020-11-25

---+++ [[IvoaDCP][Data Curation & Preservation Interest Group]]

---+++ [[IvoaTheory][Education Interest Group]]

---+++ [[IvoaKDD][Knowledge Discovery Interest Group]]

---+++ [[IvoaSS][Solar System Interest Group]]

---+++ [[IvoaTheory][Theory Interest Group]]

---+++ [[IvoaVOEvent][Time Domain Interest Group]]

---+++ [[IvoaOps][Operations]]

---+++ [[IvoaStdsDocsProc][Standards and Processes Committee]]

---

---++ TCG Vote : Vote_start_date - Vote_end_date

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

| Group | Yes | No | Abstain | Comments |
| TCG | | | | |
| Apps | | | | |
| DAL | | | | |
| DM | | | | |
| GWS | | | | |
| Registry | | | | |
| Semantics | | | | |
| DCP | | | | |
| KDIG | | | | |
| SSIG | | | | |
| Theory | | | | |
| TD | | | | |
| Ops | | | | |
| &lt;nop&gt;StdProc | | | | |

---

<br /> &lt;!--&lt;/p&gt; &lt;ul&gt; &lt;li&gt; &lt;ul&gt; &lt;li&gt; Set ALLOWTOPICRENAME =&lt;span class="WYSIWYG_PROTECTED"&gt; IVOA.TWikiAdminGroup&lt;/span&gt; &lt;/li&gt; &lt;/ul&gt;&lt;/li&gt; &lt;/ul&gt;--&gt;

<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
This topic: IVOA > WebHome > IvoaDataModel > CoordsRFC2
Topic revision: r4 - 2020-11-25 - MarkusDemleitner