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

Potential new entries for Metadata + other comments/ideas #3

Open
chad-earthscope opened this issue Nov 14, 2024 · 0 comments
Open

Comments

@chad-earthscope
Copy link
Member

Submitted by @Judape

Request new features

Feature request:

Hi everyone, I wanted to propose a few additional entries for the metadata. I grouped them according to the categories agreed until now. Most of them should not be always required, I think. I leave it up to you to decide. Feel free to change/adapt/etc..

-- Overview

  • Environmental conditions --> Weather/Ocean state/Air temperature or pressure/Rain... during acquisition or any other special environmental situation that might be worth mentioning for a given application (e.g. for oceanography,..)

  • Data Storage/Transmission --> some info about the protocol through which the data is being stored, sent to somewhere, converted,... this could help identify sources of gaps or corrupt files, speed transmission issues,.. I don't know much about the specifics here, so I'm guessing a lot.

-- Cable and Fiber:

  • Cable owner/manager --> Perhaps I missed it, but I didn't see this one in the current Metadata.

-- Interrogator:

  • Room temperature/other site-specific remarks --> where the interrogator rests. I'm not sure if useful, but this may say something about the performance of DAS and partially explain the data quality?

-- Acquisition:

  • Noise sources --> Remarkable urban noise, machinery, construction sites, rivers, etc. nearby that might be worth reporting.

  • Simultaneous recordings --> I've seen recent test of DAS interrogation along fibers transferring independent data simultaneously. This may become common in the future. Also, perhaps other DFOS (DTS, DSTS,..) might be active on other fibers on the same cable, which may become handy for a given campaign at a later stage.

  • Dedicated Geometry --> If experiments are done using cables as arrays with particular geometrical layouts, it may be good to label them accordingly for quick query, although this is obvious from the channel coordinates as well.

-- Channel

  • Geographic horizontal cable distance --> The distance along the XY-plane projection of the cable. This is generally not the same as the distance along cable, and could actually be computed from the geographical coordinates as well, but it may be also nice to know the true cable spread on a map when it has notable vertical variations.

  • Distance along fiber uncertainty --> just a measure of how accurate the Distance along fiber estimate is, as I'm never sure of how accurate it really is.

  • First/Last channel distance relative to interrogator --> an independent measure to accurately know where the cable begins or ends, as I've had problems in the past to georeference the cable when channel coordinates are missing or have notable uncertainties

Other comments/ideas:

  • Saving a number of free metadata slots for custom/optional entries with descriptions can be helpful for specific cases. I guess the extra volume increase for a few extra entries is not dramatic. A custom name could be given to these entries (e.g. Feature1, Feature2,..), or alternatively one of these could be assigned for each broad category (Overview, Interrogator,...). Some of these may need to be customized during processing, and not always previous to acquisition

  • I also think that it may be a good option to allow for coordinate reference frames that are not geographical, such as a user-defined Cartesian system with units of choice, for example, for small cables, geotechnical applications,...

  • As proposed in the meeting today, I also agree to generate a new category for pre-processing. It may even become customary to apply several procedures (perhaps even not yet popular...) to the raw data during acquisition.

  • Would a single, separate file for all the metadata make sense in the end? It could also include an overview with warnings about acquisition parameters changes during a given campaign. However, this may be a bit tricky to agree upon.

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

1 participant