Error in the WD-STC-S-1.0-20130918 document?
Francois-Xavier PINEAU
francois-xavier.pineau at astro.unistra.fr
Thu Nov 30 17:55:00 CET 2023
Hi Markus,
Thank you very much or your answer.
I was not aware of your parser:
* what do you mean by 'halfway complete'?
* what about using it in astropy regions
(https://github.com/astropy/regions/issues/21) ?
> Do you have a strong reason to do that? Several users have been
asking for MOC creation from a STC-S string, and we have been thinking
to add this features to MOC Lib Rust (and hence, to MOCPy). And: 1 - I
was not aware of the subset (for geometries) defined in the TAP document
(again, thank you); 2 - STC-S could be used as an input to create
ST-MOCs, F-MOCs, ... in addition to S-MOCs.
There are others possibilities (STC-S based queries in QAT2S, more
general STC-S parser in Aladin Lite, ...).
> The operationally (still) relevant subset for specifying geometries
is in section 6 of TAP 1.0
Grrr... I see that:
* the 'frame' is mandatory in the STC-S document and optional in TAP,
* the vocabulary is not exactly the same:
CART[123] vs CARTESION[123]
SPHER2 vs SPHERICAL2
It 's easy to support both inputs, but an option is needed in
output (to choose between the STC note and the TAP standard).
FWIW, I just published a first version of the Rust STC-S parser:
https://github.com/cds-astro/cds-stc-rust
For non-Rust users the main interest so far may be to transform STC-S
string into JSON, back and forth.
> Let's move that WD to the "Obsolete IVOA documents" Since it has been
asked by users, it seems that STC-S is used, right? Do Coords and Meas
offer an ASCII-Stringserialization? (Laurent?) (Maybe I am old school,
but I kind of like ASCII-String serializations)
fx
Le 29/11/2023 à 11:09, Markus Demleitner a écrit :
> Hi FX,
>
> On Tue, Nov 28, 2023 at 04:58:34PM +0100, F.-X. Pineau wrote:
>> I am implementing a STC-S parser (in Rust, obviously) from the
>> WD-STC-S-1.0-20130918 document:
>>> https://www.ivoa.net/documents/STC-S/20130917/WD-STC-S-1.0-20130917.html
> Do you have a strong reason to do that? You see, I've once written a
> halfway complete one (if you're interested:
> https://gitlab-p4n.aip.de/gavo/dachs/-/tree/main/gavo/stc), and I've
> regretted it, as there is little use for it.
>
> The operationally (still) relevant subset for specifying geometries
> is in section 6 of TAP 1.0
> <https://ivoa.net/documents/TAP/20100327/REC-TAP-1.0.html>.
>
> Even there, there's no formal specficiation, and really, nobody wants
> to touch the whole mess; in our DALI discussions, there was zero
> enthusiasm for moving that material into that spec (where it could
> become normative). See the current DALI 1.2 WD for the sort of types
> we would like to use in the future.
>
> But, well, the TAP 1.0 STC-S subset at least is (still) in active
> use.
>
>> Is the grammar wrong?
>> Is there an 'official/original' STC-S parser that could be used as a
>> reference?
>> Should an erratum be issued?
> The document is a (fairly rough) working draft, so there wouldn't be
> an erratum but a new working draft.
>
> But nobody has touched the WD in a decade, and I don't see that
> change, in particular since the underlying data model (STC 1.03) has
> been superseded by Coords and Meas in the meantime.
>
> My take would be: Let's move that WD to the "Obsolete IVOA documents"
> section in the doc repo. It keeps confusing people who are actually
> looking for the TAP 1.0 geometry specification.
>
> -- Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20231130/22808052/attachment.htm>
More information about the dm
mailing list