Skip to content
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

instrument_feed #35

Open
Bonnarel opened this issue Sep 28, 2023 · 1 comment
Open

instrument_feed #35

Bonnarel opened this issue Sep 28, 2023 · 1 comment

Comments

@Bonnarel
Copy link
Collaborator

Section 4.4 (September 28th version) reads :

We note that instrument_feed could be changed to instrument_beam to account for the number of beams in the case of a beamforming/PAF receiver.

Question to beam_forming fans : is that OK to keep instrument_feed for the number of beams ?

Or reversely : would instrument_beam be ok for multi feed and beam forming ?

@alle-ira
Copy link
Member

Given the discussion on instrumental characterisation (issue #50) instrument_feed may provide too specific information and may puzzle the end user.
First, to properly describe the data content instrument_feed should be given together with another parameter specifying the receiver type (multifeed, PAF/beamforming). In fact, reduction and analysis is different for data coming from multifeed or PAF receivers.
Secondly, if a service exposed multifeed observations with the highest-granularity (that is an ObsCore table lists a multifeed observation as multiple rows, say 9) the user would see in the query output a list of 9 rows. In such a case, which value would be displayed for instrument_feed in each row?
Thus, instrument_feed could be replaced/complemented by an appropriate description of the dataset content by means of dataproduct_subtype.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants