Station names for repeated deployments

[KaseyAderhold]

The standards.md document currently states:

Station names for repeated deployments [REC` {/}] If OBSs are deployed repeatedly at one site (to make a long series), use an incrementing alphanumeric character at the end of the station name (i.e., A01A, then A01B then A01C for subsequent deployments at the same approximate location). This may be a de facto "standard", but I haven't seen it written down

On our July 10th call when voting on this item, Takehi brought up that in practice ERI will reoccupy sites and designate a new epoch under the same station name, with no incrementing character. We had some discussion of location uncertainties during redeployment. I suggested we reference existing standards or conventions, where if the uncertainty in reoccupying the same site is greater than the standard for renaming the station versus starting an epoch.

[KaseyAderhold]

The ~1km convention I was referencing is from the IASPEI Station Coding Standard, specified as a "guideline":

It is strongly recommended that station and/or location codes should be changed if the associated sensors are moved far enough to result in a significant teleseismic travel-time residual discrepancy (e.g., more than 0.2 s or about 1.2 km).

Considering the location uncertainty of the first deployed sensor, plus the location uncertainty of a follow on sensor, with the usual deployment methods and conditions for OBS, it seems that this guideline would apply in many case but not all. Adding a note that with more precise reoccupation of a site or in less difficult conditions (e.g. shallow lake deployments), using the same station code is appropriate.

[joelsimon]

We face this issue with MERMAID because our floats constantly drift in the ocean but maintain a single station name. The current approach is to write so-called GeoCSV files that capture all "rapidly changing metadata" ("RCM"). GeoCSV is not ideal; users must know they exist and where to find them in the metadata aggregator (currently EarthScope tags all MERMAID data with a single deployment location).

The active development within StationXML will be able to intake and process those changing metadata by tagging them with an RCM flag, e.g. (positions changing only):

NETWORK STATION CHANNEL & LOCATION GEOCSV HEADERS GEOCSV COLUMN HEADERS GEOCSV COLUMN NAMES Metadata Units (degrees, degrees, meters, meters) Field Type (e.g. float, float, float, integer) Field name (e.g. RCM_latitude, RCM_longitude, RCM_elevation, RCM_depth, etc.)

RCM.latitude=“-14.433683” RCM.longitude=“-179.489853” RCM.elevation=“0” RCM.depth=“1500” RCM.latitude=“-14.453000” RCM.longitude “-179.505203” RCM.elevation =“0” RCM.depth=“1375” etc. (and, e.g., a changing tilt sensor might be an "RCM-ORIENTATION" subfield within an "RCM-Method-Time," etc.) So, like many issues discussed in this group, going forward hopefully tagging metadata as RCM when distributing to data centers will be sufficient to maintain logic and allow them to serve up the data without users having to correct/interpolate themselves.