utype for STC region in SIAP query response

Jonathan Fay jfay at microsoft.com
Fri Dec 16 11:54:18 PST 2011 

Dear Thomas, Alberto and All,

I have been following this thread from afar since September, I too have an interest in see the expanded use a regions to allow visualization of footprints. WWT already supports footprints for HLA (using ucd as "phys.area;obs.field" and stc-s as content), but I had hoped a more wide spread standard might evolve since it helps improve the user experience when they can identify, select and preview images by their coverage in a more intuitive and less ambiguous way. Even HLA defines two *different* types of footprints in their SIA responses.

I am aware that discussions regarding footprints have been going on for years and even now there are a few competing proposals right now, but since the interest and activity has suddenly jumped in this subject it would be really worthwhile to converge on a consensus. All this standards discussion will mean little if we can't translate it into useful features and get it in to the hands of real users.

Converging on a de-facto standard that we could all implement in interoperable viewers and publish as a IVOA note might get some traction in the short term.

Even if this is not a single one-size-fits-all standard, but a collection of  recommended ways of expressing footprints currently in common use so that users could see them across a wide range of software.

I know if this can happen I would definitely want to add support for it immediately on both WWT clients.

Jonathan Fay


-----Original Message-----
From: dal-bounces at ivoa.net [mailto:dal-bounces at ivoa.net] On Behalf Of Alberto Micol
Sent: Thursday, December 15, 2011 5:43 AM
To: Douglas Tody
Cc: dal at ivoa.net
Subject: Re: utype for STC region in SIAP query response


Dear All,

On 2 Sep 2011, at 01:40, Douglas Tody wrote:

> This would be a fine solution, considering only STC; however it is 
> perfectly legal for a DM to be based upon other models (in a way 
> defined by the new model such as Char or SIA) and define new, more 
> application-specific Utypes.  There is an especially strong argument 
> for this for essential elements of the new model so that we have a 
> well defined and self consistent model.  "Falling through" to 
> reference arbitrary elements of another model, with its own externally 
> defined namespace, is fine for extension but could significantly 
> expand the complexity of the new model as a client application might 
> then need to fully understand multiple models to be able to deal with 
> the data.

There are two kinds of clients: it seems to me that Doug here above refers to client applications that deal with a specific data model, while what I'm going to describe is the case of a generic client.

Let me consider a well known client application (Aladin), and four quite common use cases:

- As a user, I want to take the VOTable generated by a ObsTAP service and display the contained footprints.

- As a user, I want to take the VOTable generated by a SIAP service and display the contained footprints.

- As a user, I want to take the VOTable generated by a CharDM compliant service, and display the contained footprints.

- As a user, I want to take the VOTable generated by an archive query form and display the therein contained footprints


What is the magic bit that will allow Aladin to recognise a given FIELD as a footprint?

It cannot be the UTYPE, if every data model uses a different UTYPE for a footprint.

It cannot be the FIELD name, given that only one of the three services above (ObsTAP) guarantees the name to always be "s_region".

Could it be a new UCD?
(Btw, when is that a client should look for a UCD, and when for a UTYPE, to know what to do?)

The only logical possibilities I see, with different levels of technical or political difficulty to implement,
are:

1.- to standardise the footprint UTYPE across all data models
2.- to standardise the FIELD name of a footprint field, a la ObsTAP
3.- to create a new UCD for a footprint
4.- to use xtype="adql:Region" (is that acceptable? xtype is really meant to represent the storage units)


Would you suggest other ways, or the "good enough" way is already listed above?

Note: In the years we have had the same discussion again and again, this is just the first time it happens for footprints. It would be nice to solve the originating problem not just the footprint problem.

Alberto

PS: I would love to suggest a 5th possibility, that is, to create a new FIELD attribute, called stdname,
    which hosts an IVOA standard name for all those quantities that are really common across
    all data models, e.g. "footprint", "telescope", "instrument", etc.,
    as in <FIELD name="myFootprint" stdname="footprint"  
utype="u.name.it" xtype="adql:Region">,
    but I won't,
    unless asked.
;-)


>  In
> the case here, Char defines strong and consistent concepts for the 
> measurement axes, Coverage, Support, etc. which are important to the 
> Char model, and merely uses STC-S to represent the datum in question.
>
> Regarding UCDs for representing footprints in SIA-1, this can only be
> done by extension and there is no standard way to do it at present.   
> We
> really need SIAV2 to address this sort of concern.
>
> 	- Doug
>
>
> On Thu, 1 Sep 2011, Arnold Rots wrote:
>
>> Here is what, in my view, is the correct utype for a footprint
>> region:
>>
>>    stc:ObservationLocation.AstroCoordArea.Region
>>
>> Pretty simple; though one might quibble whether it should be:
>>
>>    stc:ObsDataLocation.ObservationLocation.AstroCoordArea.Region
>>
>>
>> - Arnold
>>
>>
>> Francois Bonnarel wrote:
>> [ Charset ISO-8859-1 unsupported, converting... ]
>>> Hi Thomas,
>>>    To complete my answer to Markus
>>>     we could have something like
>>>
>>>    <FIELD name="fov" unit="deg" xtype="STC-s" datatype="char"
>>> arraysize="*" utype="sia:Char.SpatialAxis.Coverage.Support.Area" >
>>>
>>>       I think something like this can be proposed (if not yet the
>>> case)
>>> in SIA2...
>>>       this will be consistent with ObsTap... and could also be 
>>> included in the next version of SSA et al.
>>>
>>>       For current SIA services, maybe we could have a short 
>>> recommendation or note to propose using the same as an additional 
>>> field in the SIA1 Query response Cheers Fran?ois
>>>> To illustrate my request, here is is how the STC-S FIELD is 
>>>> described in the query response of three different SIAP services :
>>>>
>>>> Service 1 : <FIELD name="position_bounds" unit="deg"
>>>> xtype="adql:REGION" datatype="char" arraysize="*">
>>>>
>>>> Service 2 : <FIELD name="stcs" datatype="char" arraysize="*"
>>>> ucd="phys.area;obs.field" unit="deg">
>>>>
>>>> Service 3 : <FIELD ID="regionSTCS" name="regionSTCS"  
>>>> datatype="char"
>>>> arraysize="*">
>>>>
>>>> 3 different services, 3 different ways to express the same thing.
>>>> Having a unique unambiguous way to detect the STC-S field would be 
>>>> very helpful for client consuming these services.
>>>> Cheers,
>>>>
>>>> Thomas
>>>>
>>>> Thomas Boch wrote:
>>>>> Fran?ois,
>>>>>
>>>>> I wish this is something that could be standardized in a 
>>>>> forecoming revision of the SIAP document, so that clients can 
>>>>> easily find out which FIELD support the STC-S description.
>>>>>
>>>>> Thomas
>>>>>
>>>>> Fran?ois Bonnarel wrote:
>>>>>> Hi Thomas,
>>>>>>   Obstap has obs:Char.SpatialAxis.Coverage.Support.Area
>>>>>> for this . We have something similar in the SIA2 prototypes
>>>>>>   I guess eventually for sia we will have something like
>>>>>>            sia:Char.SpatialAxis.Coverage.Support.Area
>>>>>>   although the problem of the name space is still to be 
>>>>>> discussed...
>>>>>> By the way you can write this field as an STC-S feature ...
>>>>>> Cheers
>>>>>> Fran?ois
>>>>>> Le 29/08/2011 12:02, Thomas Boch a ?crit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> Embedding a STC region in the SIAP query response is becoming 
>>>>>>> more and more widespread, and we would like to support this 
>>>>>>> feature in Aladin.
>>>>>>> I would like to know if there is a standard (or de facto
>>>>>>> standard)
>>>>>>> utype to characterize the FIELD holding the STC region 
>>>>>>> description.
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> To illustrate my request, here is is how the STC-S FIELD is 
>>>> described in the query response of three different SIAP services :
>>>>
>>>> Service 1 : <FIELD name="position_bounds" unit="deg"
>>>> xtype="adql:REGION" datatype="char" arraysize="*">
>>>>
>>>> Service 2 : <FIELD name="stcs" datatype="char" arraysize="*"
>>>> ucd="phys.area;obs.field" unit="deg">
>>>>
>>>> Service 3 : <FIELD ID="regionSTCS" name="regionSTCS"  
>>>> datatype="char"
>>>> arraysize="*">
>>>>
>>>> 3 different services, 3 different ways to express the same thing.
>>>> Having a unique unambiguous way to detect the STC-S field would be 
>>>> very helpful for client consuming these services.
>>>> Cheers,
>>>>
>>>> Thomas
>>>>
>>>> Thomas Boch wrote:
>>>>> Fran?ois,
>>>>>
>>>>> I wish this is something that could be standardized in a 
>>>>> forecoming revision of the SIAP document, so that clients can 
>>>>> easily find out which FIELD support the STC-S description.
>>>>>
>>>>> Thomas
>>>>>
>>>>> Fran?ois Bonnarel wrote:
>>>>>> Hi Thomas,
>>>>>>   Obstap has obs:Char.SpatialAxis.Coverage.Support.Area
>>>>>> for this . We have something similar in the SIA2 prototypes
>>>>>>   I guess eventually for sia we will have something like
>>>>>>            sia:Char.SpatialAxis.Coverage.Support.Area
>>>>>>   although the problem of the name space is still to be 
>>>>>> discussed...
>>>>>> By the way you can write this field as an STC-S feature ...
>>>>>> Cheers
>>>>>> Fran?ois
>>>>>> Le 29/08/2011 12:02, Thomas Boch a ?crit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> Embedding a STC region in the SIAP query response is becoming 
>>>>>>> more and more widespread, and we would like to support this 
>>>>>>> feature in Aladin.
>>>>>>> I would like to know if there is a standard (or de facto
>>>>>>> standard)
>>>>>>> utype to characterize the FIELD holding the STC region 
>>>>>>> description.
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> Thomas Boch a ?crit :
>>>> To illustrate my request, here is is how the STC-S FIELD is 
>>>> described in the query response of three different SIAP services :
>>>>
>>>> Service 1 : <FIELD name="position_bounds" unit="deg"
>>>> xtype="adql:REGION" datatype="char" arraysize="*">
>>>>
>>>> Service 2 : <FIELD name="stcs" datatype="char" arraysize="*"
>>>> ucd="phys.area;obs.field" unit="deg">
>>>>
>>>> Service 3 : <FIELD ID="regionSTCS" name="regionSTCS"  
>>>> datatype="char"
>>>> arraysize="*">
>>>>
>>>> 3 different services, 3 different ways to express the same thing.
>>>> Having a unique unambiguous way to detect the STC-S field would be 
>>>> very helpful for client consuming these services.
>>>> Cheers,
>>>>
>>>> Thomas
>>>>
>>>> Thomas Boch wrote:
>>>>> Fran?ois,
>>>>>
>>>>> I wish this is something that could be standardized in a 
>>>>> forecoming revision of the SIAP document, so that clients can 
>>>>> easily find out which FIELD support the STC-S description.
>>>>>
>>>>> Thomas
>>>>>
>>>>> Fran?ois Bonnarel wrote:
>>>>>> Hi Thomas,
>>>>>>   Obstap has obs:Char.SpatialAxis.Coverage.Support.Area
>>>>>> for this . We have something similar in the SIA2 prototypes
>>>>>>   I guess eventually for sia we will have something like
>>>>>>            sia:Char.SpatialAxis.Coverage.Support.Area
>>>>>>   although the problem of the name space is still to be 
>>>>>> discussed...
>>>>>> By the way you can write this field as an STC-S feature ...
>>>>>> Cheers
>>>>>> Fran?ois
>>>>>> Le 29/08/2011 12:02, Thomas Boch a ?crit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> Embedding a STC region in the SIAP query response is becoming 
>>>>>>> more and more widespread, and we would like to support this 
>>>>>>> feature in Aladin.
>>>>>>> I would like to know if there is a standard (or de facto
>>>>>>> standard)
>>>>>>> utype to characterize the FIELD holding the STC region 
>>>>>>> description.
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> =
>>> ====================================================================
>>> Fran?ois   Bonnarel           Observatoire Astronomique de  
>>> Strasbourg
>>> CDS (Centre de donn?es        11, rue de l'Universit?
>>> astronomiques de Strasbourg)  F--67000 Strasbourg (France)
>>>
>>> Tel: +33-(0)3 68 85 24 11     WWW: http://cdsweb.u-strasbg.fr/people/fb.html
>>> Fax: +33-(0)3 68 85 24 25     E-mail: francois.bonnarel at astro.unistra.fr
>>> --------------------------------------------------------------------
>>> -
>>>
>> --------------------------------------------------------------------------
>> Arnold H. Rots                                Chandra X-ray Science  
>> Center
>> Smithsonian Astrophysical Observatory                tel:  +1 617  
>> 496 7701
>> 60 Garden Street, MS 67                              fax:  +1 617  
>> 495 7356
>> Cambridge, MA 02138                             arots at head.cfa.harvard.edu
>> USA                                     http://hea-www.harvard.edu/~arots/
>> ---------------------------------------------------------------------
>> -----
>>

More information about the dal mailing list