It is always the case that services are responsible for converting spatial queries to the system they use.Thanks for the reminder, Patrick. I think this should be stressed more in ObsTAP and in the corresponding DAL protocols. But at least use case of solar system body observations could be nice. |
It is always the case that services are responsible for converting spatial queries to the system they use. | ||||||||
Changed: | ||||||||
< < | Thanks for the reminder, Patrick. I think this should be stressed more in ObsTAP and in the corresponding DAL protocols. | |||||||
> > | Thanks for the reminder, Patrick. I think this should be stressed more in ObsTAP and in the corresponding DAL protocols. But at least use case of solar system body observations could be nice. | |||||||
<--
|
| ||||||||
Changed: | ||||||||
< < | accept ADQL queries that use that column. It is always the caes that services | |||||||
> > | accept ADQL queries that use that column. It is always the case that services | |||||||
are responsible for converting spatial queries to the system they use. s_ra and s_dec are allowed to be NULL in the database, even if s_region is not null. The s_ra is and s_dec columns are there as a convenience only; they are not actually required for any of the use cases and, if the s_region was in ICRS the values could be trivially obtained in ADQL with coord1(centroid(s_region)) and coord2(centroid(s_region)), although one might also want to select coordsys(s_region) as well, or - even better - coordsys(centroid(region)) just in case other transformations are going on and they really want to be careful. AnitaRichards 09/03/2011 Thanks, that solves the problem. I think. DougTody 10 Mar 2011 A target name query should still work in this case. | ||||||||
Added: | ||||||||
> > | -- JuanDeDiosSantanderVela | |||||||
Added: | ||||||||
> > | PatrickDowler said:
It is always the case that services are responsible for converting spatial queries to the system they use.Thanks for the reminder, Patrick. I think this should be stressed more in ObsTAP and in the corresponding DAL protocols. | |||||||
<--
|
| ||||||||
Added: | ||||||||
> > | PatrickDowler 09 Mar 2011 | |||||||
Added: | ||||||||
> > | The s_region column allows ANY STC region; the service has to be able to accept ADQL queries that use that column. It is always the caes that services are responsible for converting spatial queries to the system they use. | |||||||
Added: | ||||||||
> > | s_ra and s_dec are allowed to be NULL in the database, even if s_region is not null. | |||||||
Added: | ||||||||
> > | The s_ra is and s_dec columns are there as a convenience only; they are not actually required for any of the use cases and, if the s_region was in ICRS the values could be trivially obtained in ADQL with coord1(centroid(s_region)) and coord2(centroid(s_region)), although one might also want to select coordsys(s_region) as well, or - even better - coordsys(centroid(region)) just in case other transformations are going on and they really want to be careful. AnitaRichards 09/03/2011 Thanks, that solves the problem. I think. DougTody 10 Mar 2011 A target name query should still work in this case. | |||||||
<--
|
<--
|