Open luciazarauz opened 4 years ago
Thanks for creating an issue, the Core Group meet once a week to answer questions. Please use the link below to follow the status of your issue.
We have been discussing a similar question in issue #15 - can you take a look at that issue and see if it answers your question?
I have labelled this with selectionMethod, in order to make sure we have a look at it at the WGCATCH intersession work. I think the clarification of the non-probabilistic selection methods should make clear if it in some cases is OK to consider samples with selection probability 0 as part of the sampling frame, and how that can be documented in the RDBES.
thank you very much for your answer. I have read issue #15 and I think we have a similar situation than @jsrodriguezieo.
I got your advice: In the case of @jsrodriguezieo this could mean: totalN=7 ports, n=7 ports, method = NPEJ, probInclusion=1 (Though 20 ports)
But it is still not clear to me:
In which table shall I report that port selection (ie 7 ports selected from 7 total ports by NPEJ)? I am using H5, and reporting only sampled portdays in table OS. I was reporting SRSWOR becasue the portday is selected randomly (among the grup of sampled ports)
Shall I leave the the ports with selection probability 0 out of the system? I see that this si going to be handled intersessionally (https://github.com/ices-tools-dev/RDBES/issues/52#issuecomment-653515949). At the moment I think I will leave them out...
For the data call we advise to not include the ports that are out-of-frame in the OS table. For the ports that are in-frame your total number should be the number of port-days that you could have sampled, and the number sampled is the number of port-days that you did sample e.g. if you had 10 ports, but only 5 of those ports are in your sampling frame, and each port only opens 2 days a week then your total number would be 5 ports x 2 days/week x number of weeks in stratum. We think you should carry on reporting the selection method as SRSWOR in this case. As you say, this question will be reviewed by WGCATCH intersessionally.
Great. Thank you David. It is clear now :-) :-)
Ok, I will put this issue on hold until the WGCatch intersessional work.
Analysis of issue done at WKRDB-EST2
We agree with WKRDBEST (link above) that we should update the current guidelines to “when some components of the target population of each sampling level in RDBES are excluded from the sampling frame, they should be declared and, whenever possible, also quantified”. We need to update the guidance to include out of frame example and associated text.
Discussion at estimation subgroup 2021-06-24
The code have been added: Code | Description OutOfFrame | Used in cases where not all sampling units are included in sample selection
THe code OutOfFrame will be deleted from the code type SelectionMethod, according to agreement in issue #142. (OutOfFrame will be added to code type ReasonForNotSampling)
Hello,
I have read in the documentation that out of frame strata should not be declared. And I have doubts about how to report my data. I will try to explain the situation.
In my sampling design, I have considered different fleets as strata (each of them defined with non-overlapping vessel lists). Some strata (fleets) are out of my sampling frame. They are never sampled. I understand that these are not reported in the RDBES. No problems with this.
But in every sampled strata, I have some ports which are sampled, and some other ports that are not included in my sampling frame (due to practical constrains) and therefore will never be sampled. I thought that these should be reported with sampling = 0, because they will be need in order to know the total PSU in the strata. But somehow I also think that it would be needed to indicate that they are out of the sampling frame and therefore their sampling probability is zero.
Shall include information of these ports out of my sampling frame?
Thank you!