Simple Cone Search 1.1 - (new) internal WD
JBerthier
jerome.berthier at obspm.fr
Wed Oct 11 00:59:32 CEST 2017
Dear all,
I understand to not break back-compatibility, but after 10 years waiting
for an update of CS, I think we can (must) move forward to open the
protocol to time domain applications, such as solar system science. Even
if you were thinking to a minor release, I think this should be a 2.0
release to prepare the future (e.g. big data catalogs). Not to change
the protocol in depth with theoretical things, but to be pragmatic and
just add what is missing to do science with the protocol.
On 10/10/2017 09:28 AM, Marco Molinaro wrote:
> Dear Jerome,
> can you expand a bit on this?
>
> I mean. I know epoch is critical, but having EPOCH
> as a query parameter may mean:
>
> - asking it to be a mandatory one: break back-compatibility
yes in the framework of a minor release. But is a minor release really
useful ? I guess the old CS services didn't wait to be updated to
implement modern stuff in order to be usable. Thus actual CS services
may already not be fully compliant with the old specification.
> - letting it be optional: will this be enough for your use cases?
yes, it's enough. But is it so breaking for an old service to not take
care of a new parameter? I think no more than a service that uses an
unspecified parameter (e.g. Skybot uses the EPOCH parameter for 10 years
and no human complained, just machines ;) )
> - require service to transform internal epoch to client required one?
no, the client provide an epoch (ISO format or julian day) to the
service which uses it to compute the positions of the celestial objects
(planets, stars, ...) in order to select those which actually belong to
the FOV, so that the client can cross-match the sources and then
identify them. In the output the epoch is just recalled in a param element.
cheers
jerome
>
> While, if you simply ask to have epoch information
> in the response I thought the VOTable-1.3 erratum 1
> went that way, so maybe that's something to
> enforce.
>
> Cheers,
> Marco
>
>
> 2017-10-10 1:41 GMT+02:00 JBerthier <jerome.berthier at obspm.fr
> <mailto:jerome.berthier at obspm.fr>>:
>
> Dear all,
>
> From my point of view of CS provider (Skybot service), the key
> point is the addition of the EPOCH parameter. Without this
> parameter, a solar system CS service is unusable, as Skybot is in
> the next release of Aladin. Moreover, with the coming of big
> catalogs such as Gaia, this parameter will become mandatory to query
> the sky at a given epoch. One of my ongoing project is to seek for
> solar system objects in the "Carte du ciel" plates, thanks to the
> Gaia catalog which will allow one to get star positions at the
> beginning of the XXth century with an accuracy equivalent to
> Hipparcos today. Without the EPOCH parameter it will not be possible
> to cross-match stars 100 years back from the reference epoch of the
> catalog.
>
> cheers
> jerome
>
>
>
>
>
> On 10/09/2017 02:26 PM, Marco Molinaro wrote:
>
> Dear all,
> at the oncoming Interop in Santiago I will give a quick status
> report
> on the Simple Cone Search revision task.
>
> I just fixed a couple of sentences and typos in the internal WD
> built
> in July and I attach it here for you.
>
> Discussion points are still the same.
> I would say that
> 1 - ReST vs. query_param access_url
> 2 - RESOURCE type="results" and multiple RESOURCEs
> 3 - minor vs. major revision
>
> are the main ones, while
> 4 - trying or not to use UCD1+
>
> can be left out until/if we tackle number 3.
>
> As for the "§2.3b INFO element error validation" issue, I set up an
> Erratum that should take care of it
> (http://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Err-1
> <http://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Err-1>).
>
> The full view on Cone Search is available starting at
> http://wiki.ivoa.net/twiki/bin/view/IVOA/ConeSearch
> <http://wiki.ivoa.net/twiki/bin/view/IVOA/ConeSearch>
>
> Every comment and contribution is welcome and appreciated.
> I especially ask cone search providers and apps developers
> to join this task to update this block of the DAL landscape.
>
> Cheers,
> Marco
>
> PS - this is a DAL internal WD, but Apps is alerted for obvious
> reasons
> PPS - detailed revisions can be followed also on volute
>
>
> --
> --- Dr. Jerome Berthier ------------------ Phone: +33 (0)14051 2261
> <tel:%2B33%20%280%2914051%202261> --
> Institut de mecanique celest
> <https://maps.google.com/?q=itut+de+mecanique+celest&entry=gmail&source=g>e
> Fax: +33 (0)14633 2834 <tel:%2B33%20%280%2914633%202834> --
> 77 av. Denfert Rochereau Mailto:jerome.berthier at imcce.fr
> <mailto:jerome.berthier at imcce.fr> --
> --- 75014 Paris - France --------------------- http://www.imcce.fr/ --
>
>
--
--- Dr. Jerome Berthier ------------------ Phone: +33 (0)14051 2261 --
Institut de mecanique celeste Fax: +33 (0)14633 2834 --
77 av. Denfert Rochereau Mailto:jerome.berthier at imcce.fr --
--- 75014 Paris - France --------------------- http://www.imcce.fr/ --
More information about the apps
mailing list