-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
extend the science case section or appendix #47
Comments
\subsection{Use case - s_resolution_min} |
\subsection{Use case - s_resolution_max} |
\subsection{Use case - s_fov_min} Show me all datasets satisfying: |
\subsection{Use case - s_fov_min} |
The above queries can be run with s_resolution_min and s_fov_max instead of s_resolution_max and s_fov_min respectively, to obtain results in which at least part of the dataset satisfy the condition. |
\subsection{Use case - dataproduct_type} |
\subsection{Use case - f_resolution, f_min, f_max} Show me all datasets satisfying: |
\subsection{Use case - f_resolution, f_min, f_max} \textit{Select any cube with spectral resolution better than 1 MHz and spectral range inside the 1 to 1.5 GHz band.} Show me all datasets satisfying: |
This use case should be rephrased according to the introduction of a user-defined function to convert from frequency to wavelength values. |
does it mean that you want a coverage ( s_fov) big enough to include source + emission ? or : did you mean s_resolution_min < 0.017 ??? |
as there is no dataproductype =map , we could rephrase as |
OK , very appropriate. FB & ML |
Ok well done ML &FB |
'map' is not allowed as dataproduct_type value , but it seems that scan_mode can be used as a constraint like : ML |
to be completed , if we want to use user defined fonction for frequency conversion . ML |
frequencies are expressed in Hz so f_resolution < 1000000 AND f_min > 1.0 e+9 AND f_max < 1.5 e+9 |
@Bonnarel We noted that in the latex document you changed the syntax of this query, which instead should remain as it was originally written. Specifically: |
@Bonnarel if frequency must be expressed in KHz, this science case should be changed accordingly, since now em_min and em_max are intended in MHz. Note also that the query use frequency instead of wavelength: either we reformulate the query syntax by converting from frequency to wavelength, or we use f_min and f_max. |
@Bonnarel if KHz must be the unit for any frequency attribute, this query should be modified as: f_resolution < 1000 AND f_min > 1000000 AND f_max < 1500000 |
No, eventually after november comments the chosen unit is Hz.
Le 08/05/2024 à 15:23, Alessandra Zanichelli a écrit :
…
\subsection{Use case - f_resolution, f_min, f_max} \textit{Select
any cube with spectral resolution better than 1 MHz and spectral
range inside the 1 to 1.5 GHz band.}
Show me all datasets satisfying: I. Product type is cube II.
spectral resolution better than 1 MHz f_min and f_max are computed
by means of a user defined function. \begin{verbatim} SELECT *
FROM ivoa.ObscoreRadioExtended WHERE dataproduct_type = 'cube' AND
f_resolution < 1000000 AND f_min > 1000000 AND f_max < 1500000
\end{verbatim}
@Bonnarel <https://github.com/Bonnarel> if KHz must be the unit for
any frequency attribute, this query should be modified as:
f_resolution < 1000 AND f_min > 1000 AND f_max < 1500
—
Reply to this email directly, view it on GitHub
<#47 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMP5LTDVIZYYBO7LSVE5ZGDZBIRL3AVCNFSM6AAAAABD76YSICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBQGU3DOMBZHE>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
With this science case we intended to focus on investigating the diffuse emission more than on having the whole source in the field of view. In fact, diffuse emission is washed out in case of a too high spatial resolution, hence we put the constraint on s_resolution_min which must be larger than 0.017. |
This use case actually uses scan_mode for the query. |
This could be in principle possibile provided we include also "cube" as a value for dataproduct_type. However, dataproduct_type=spatial_profile would include also skydip datasets which are not useful in this case. In any case, switching from ObsCore radio extension to vocabulary, what should we write in dataproduct_type for raster or otf maps in continuum observations? Do you think we should discuss this topic further? |
We should agree on the frequency units for the various attributes. We see that in Sect 4.2 of the current version of the working draft it is said that f_resolution,f_min and f_max must be in kHz. |
Ok for Hz. Do you want us to modify all the science cases accordingly? |
OK. I have seen your answer on the scientific rationale. We didn't catche the intent |
OK, that's clear now. Maybe you could add a sentence to the phrasing of the science case at the beginning. Something
|
Yes. But we rephrased the initial text of the use case accordingly. |
I have a PR still open. I can easily make the changes (including in section 4.2) in it to fix this. I think the conversion in Hz has been done in most of them. |
This is still undecided. Should we vote ? in case we go to user defined functions we should have :
|
cube is a data_product type since a long time. spatial_profile has been recently accepted by the TCG. we can still discuss if we really need a map product type or if the scanning mode is enough. Will you attend the radio session remotely ? It's at 6 AM UTC (8 AM central europe time) ? |
@alle-ira : you can have a look to the PR which I updated today. The result pdf can be seen in preview artefact under this action : https://github.com/ivoa-std/ObsCoreExtensionForRadioData/actions/runs/9029833282 |
Dear Francois,
Cheers, |
Dear Alessandra,Vincenzo,
OK. done
OK done
Yes I will probably add this text at the beginnig of the Appendix
OK done !
Unfortunately during the interop almost everybody asked to remove f_min, f_max. (I was actually the only one in favor of that). So I ahev to rephrase everything accordingly.
OK done
Thanks for everything. |
This issue is there to start writing science cases expressing the need of an ObsCore extension for radio data.
Suggestion is to describe each science case in a separate "comment" of this issue. The other people feedback on each specific science case can be done by "quote replying" to this comment.
The text was updated successfully, but these errors were encountered: