Additional check for ph5_validate, remove location warnings for ph5tostationxml

[damhuonglan]

What does this PR do?

Solve #410: All the warnings for station's location includes:

• [x] location/X,Y,Z/value_d = 0

• [x] Not found location/Y/units_s

will be excluded for ph5tostationxml.

Solve #433:

• [x] Experiment_t's nickname_s: 'Nickname was not found' changed to error

• [x] Array_t's id_s : add warning for 'Station ID is more than 32767. Not compatible with SEGY revision 1.'

• [x] Array_t's sample_rate_i: error for sample_rate <0, warning for sample_rate=0

• [x] Array_t's sample_rate_multiplier_i: error if it isn't an integer greater than 1

• [x] Event_t not found: change to warning. (It warns in both terminal and in ph5validate.log

• [x] Event_t: remove check for location/coordinate_system_s, projection_s, projection_s , ellipsoid_s , description_s because they aren't required

• [x] Event_t: check for location/Z,Y,Z/unit_s: changed to warnings

Checklist

• [ ] This PR is not directly related to an existing issue (which has no PR yet).
• [ ] All tests pass.
• [ ] Any new or changed features have are documented.
• [ ] Changes have been added to CHANGELOG.txt .
• [ ] First time contributors have added your name to CONTRIBUTORS.txt .

[damhuonglan]

This is related to issue #443

433

[timronan]

After reviewing this issue it seems like we should flag missing units r location/X[Y,Z]/units_s = '' or location/X[Y,Z]/units_s = in both the event and array tables as errors.

The fields "location/coordinate_system_s, projection_s, projection_s , ellipsoid_s" should remain as trigger warnings. Noven seems to be the issue in not populating these fields. These fields could still be manually populated and segdtoph5 populates these fields.

[timronan]

What does everyone think about my last comment? How do we feel about this issue?

[hrotman-pic]

For location/Z/unit_s=unknown, that hasn't caused a problem yet with creating the stationXML. Should we assume that will continue to be OK?

[timronan]

@hrotman-pic how are location/Z/unit_s fields populated with the value "unknown". Could this be fixed and have a more descriptive answer injected?

[hrotman-pic]

@timronan This is a bug that happens with Fairfield nodes & segdtoph5. In the meeting it sounded like Alissa was planning to open an issue to request a fix so it is correctly populated as location/Z/unit_s=m, but I am thinking of the Fairfield PH5s already in the archive: will it cause a metadata extraction problem later, even though it doesn't seem to now? I wonder if we should flag this case as a warning so we can catch those archives.

[hrotman-pic]

Apologies for commenting on a merged PR.

@timronan should the last commit you added catch a case with location/Z lines in the array table: location/Z/value_d=1.0 location/Z/units_s=unknown and issue a warning for each channel with location/Z/units_s=unknown, in ph5_validate.log? I am on our server that auto-updates so I think I'm on the most up to date commit. ph5_validate didn't issue a warning. (If this isn't the right place to comment, please let me know.)

[timronan]

@hrotman-pic good catch. That last commit only looks for location/Z/units_s=unknown in the event table, and not the array table. We can start another PR go catch this warning in the array table as well.