The documentation is on the SiteTesting GitHub page.

Wishlist

Goal: Develop map indicating physical location of field testing, and point where the data is stored/curated.

Concerns: Multiple testing methods with varying number of sensors, records, levels of analysis, and differing appropriate locations for results. The most complex example is a combined MASW/MAM surface wave test. Data from lots of sensors (with many individual records) are processed together to generate a suite of 1D VS profiles which are attributed to a physical location in the centre of the array. 

Start with a simple testing method: Horizontal-to-Vertical Spectral Ratio of ambient vibration recordings. A single station is placed at a single station (lon and lat), records a 3-component record, the data is processed to generate an H/V curve. The result is hopefully is an estimate of the fundamental period of vibration (mean and standard deviation). There may be multiple reported periods, each associated with a different peak in the H/V curve (e.g, bedrock, BPV, and Riccarton Gravels in Christchurch).

Goal create a point for each HVSR test with metadata and potentially raw data and processed results.

Metadata Fields:

• Location/Test/Site ID (often a test ID is designated in the field and entered into a spreadsheet)
• Longitude (decimal degrees)
• Latitude (decimal degrees)
• Site Period
  • Mean Value (seconds)
  • Standard Deviation (seconds)
  • Bedrock/T0 Flag (true/false): Is the experimental H/V peak period associated with bedrock (thus an estimate of T0)??
• Electronic Location of Raw Data and/or Results
  • Some data/results may be stored externally (e.g., on Design-Safe). If so provide a reference URL.
  • Some data/results may be stored with the mapping system (on a server managed by QC SW team?)
  • Some data/results may not be available online. In this case provide contact information for who has the data?
    
    
• Important Personnel (optional but maybe useful to track changes to map)
  
  • Data Archivist — Name (who uploaded to map database?)
    • Date and Time Stamp
  • Data Reviewer — Name (who reviewed submission to map database?)
    
    • Date and Time Stamp

HVSR Data/Results (for now map is separate from data curation, do don't worry about this):

• Raw Data Input: In the form of (1)  miniseed file (common compressed file format for geophysics and the output of our broadband seismometers), (2) seg-2 or seg-y (another common geophysical format), or (3) a text file.
• Output Results: H/V curve in form of text file or perhaps a image file with curve plotted.
• Numerical values of period(s) mean and standard deviation.

Each test type (e.g., HVSR, Surface Wave Testing, SCPT) should have it's own pin, icon, token. The colour of the pin indicates the status of test results (e.g., data has been submitted, but not yet reviewed (grey, faded point), data has been reviewed/vetted (black?, solid point). Perhaps use additional colour to indicate data availability (e.g. blue == on design-safe, green == on NZGD, yellow == on database server?, and red == not online (seek contact))

Users should be able to view points on a map, click on the point, look at the point's metadata, and potentially retrieve the data and results). Contributors should be able to add a new test with appropriate metadata. Reviewers should be able look at new tests pending approval, provide feedback if needed, and formally upgrade the point to a solid colour (full approval).