Simple Cone Search 1.1 - (new) internal WD
Marco Molinaro
molinaro at oats.inaf.it
Wed Oct 11 09:50:22 CEST 2017
Dear Jerome, all,
2017-10-11 0:59 GMT+02:00 JBerthier <jerome.berthier at obspm.fr>:
> 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.
I may be wrong, but I don't remember getting many
reports on things that needed to be changed in SCS
before Sydney's interop, when the DALI inconsistency
was raised.
Same for additional features.
That's probably because the mandates in SCS-1.03
are really a minimal set, so working on optional ones
is quite easy.
And this may explain also the compliance issue,
as far as OPS-WG reports on that.
So, minor vs. major is a point (even if we're not all
on the same lines) while I would consider EPOCH
a valid feature request to be discussed. That's why
I was asking form more details.
One point a disagree is that on "CS services didn't
wait to be updated...".
We're a community, building interoperable standards.
We are of course free to work on our custom preferred
solutions, starting or not from the above standards.
But then, if we don't report back our needs or work,
it makes hardly sense to complain the standards
are old because they don't speak about what we
didn't ask for.
> - 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 ;) )
I have no way to tell what efforts and resources are needed
at each data providers' side. That's why there's discussion
on how to move on and that's why I'm asking for requirements
and participation in the task.
As for EPOCH, it's been there 10 years in Skybot ... only(?).
Having it as an _optional (SHOULD) but standardized query
parameter_ is different than not having it there at all.
It's different because it tells service providers to think about it.
- 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.
>
So, I badly explained myself.
You're really asking that server-side the response positions
are re-calculated based on the EPOCH value in the query.
This is the additional effort that would be required to data providers
if we add and/or mandate this parameter.
Thanks for the added information!
Cheers,
Marco
>
>
> 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/ --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20171011/b46e5da9/attachment.html>
More information about the apps
mailing list