search

eurec4a / eurec4a-intake

Intake catalogue for EUREC4A field campaign datasets
17 stars 19 forks source link

SWIFT buoys treated as individual platforms. #63

Closed RobertPincus closed 3 years ago

RobertPincus commented 3 years ago

This reorganizes data from the SWIFT drifting buoys to address #62

At present there are two sources of SWIFT data: cat.SWIFTNN.track points to the track data assembled by Bjorn and cat.swifts.SWIFTNN points to the complete data including the track, as produced by the data providers.

This PR adds cat.SWIFTNN.all to point to All The Data and removes cat.swifts.SWIFTNN.

I am not convinced, though, that it makes sense to have a .track entry with just the track data and .all for the complete data, which include the track data. Would it make more sense to simply have cat.SWIFTNN point directly to all the data?

RobertPincus commented 3 years ago

@observingClouds I would be curious for your ideas.

observingClouds commented 3 years ago

I think this is the best solution for now until we have overcome some of the hierarchical access questions by e.g. specific functions or/and search functionality.

The only issue I still see here is the accessor-name all. This is very inclusive and basically questions every other dataset that is already connected with a SWIFT buoy ( track) or any additional data that might still come. Can we come up with a different name? My best suggestion is Level_1, although it is only a bit more satisfying than all, especially because I cannot recall that we have defined what each level means in this community.

observingClouds commented 3 years ago

Would it make more sense to simply have cat.SWIFTNN point directly to all the data?

Not sure, if I understand your question correctly @RobertPincus. Are you proposing to bann the track data? I think it will be good in the long run, if we don't have cat.<thing> directly point to a dataset, but always have an additional accessor to be able to add further datasets without changing the access structure.