Idea: Access to quality-controlled Argo floats trajectory data

[lhoupert]

Is there a plan to add an access to quality-controlled Argo floats trajectory data such as ANDRO (https://seanoe.org/data/00360/47077/)?

[github-actions[bot]]

Welcome to the argopy community: thanks for raising this first issue !

[quai20]

Hi Loic, What feature would be (more) important here ? Accessing Andro from an online provider (like Erddap for Argo data), or having the displacement data into xarray object to work with ?

[lhoupert]

Hi Kevin! I would say the more useful would be to be able to get the ANDRO atlas in an xarray dataset using the .float and .region methods. In a second step being able to get the matching profile data (T,S,etc.). For a float with N profiles, I guess you will have N-1 trajectory information from ANDRO if the float is in ANDRO.

Then accessing ANDRO online instead of donwloading the last version of the atlas file locally would be the last priority I think.

[gmaze]

What you ask for is a "simple" collection of lat/lon/time/float, ie a simpler version of the index? This is under the scope of argopy.

But the issue here is that ANDRO is a specific dataset, managed and produced by LOPS with help from Coriolis. YoMaHa could be another request along this line. We don't plan to provide a fetcher for specific datasets. Our priority is to ease access to the Argo dataset as it is maintained by DAC/GDAC. I hope to be clear with regard to the nuance.

Trajectories are in netcdf file in the ftp of GDAC, and are a key product of Argo along vertical measurements. So yes, data from trajectory files could be provided by an argopy data fetcher.

[lhoupert]

ok it's clearer. So the app will only access real-time trajectory data only? The advantage of Andro is all the extra work done to QC control the trajectory.

I am not familiar with all the DAC/GDAC processing chain but is there a way to feed back the quality-control trajectories, as assessed by ANDRO into the Argo dataset maintained by the DAC/GDAC? (or YoMaHA, but in my understanding, the QC done in ANDRO is much higher level),

[quai20]

ok it's clearer. So the app will only access real-time trajectory data only? The advantage of Andro is all the extra work done to QC control the trajectory.

I am not familiar with all the DAC/GDAC processing chain but is there a way to feed back the quality-control trajectories, as assessed by ANDRO into the Argo dataset maintained by the DAC/GDAC? (or YoMaHA, but in my understanding, the QC done in ANDRO is much higher level),

@cabanesc can probably answer to that.

[cabanesc]

This is not straightforward because the displacement information available in ANDRO is not directly available in the RT trajectory files. So we have to reprocess the work done for ANDRO in order to put flags on the right variables in the trajectory files (date/position/pressure/cycle number ...) using intermediate log files. We are working on this to create delayed mode files for trajectories that will be available on GDAC. But there are still some points to define and set up. In any case this will be done only for the coriolis DAC floats, the other DACs (AOML, CSIRO, JMA...) are supposed to handle the QC of the trajectories of their own floats.

[gmaze]

argopy aims to provide real time and delayed mode data, so when delayed mode processing of Argo trajectories conducted to keep ANDRO updated will feed back to the DAC/GDAC dataset, it will be available with argopy.

But are you more interested by:

• [ ] trajectories (lat/lon/time points)
• [ ] measurements sampled during parking drift Managing these two will require very different machinery (and the 1st one is basically already available)

[lhoupert]

Thanks all for your replies! I understand better the subtilities between all these datasets...

Yes, I am mostly interested in trajectories and the "classic" ANDRO database works fine for what I am doing.

[github-actions[bot]]

Stale issue message

[github-actions[bot]]

This issue was marked as staled automatically because it has not seen any activity in 90 days

[github-actions[bot]]

This issue was closed automatically because it has not seen any activity in 365 days

[gmaze]

closing because

the "classic" ANDRO database works fine for what I am doing.