Fix 53: Zero Pad Depth Field in Convertion from Stationxml to Dataless SEED

[timronan]

This solves the local depth issue #53 by 0 padding the depth field when it does not fit into the dataless SEED convention. Data output from this pull request pass manual inspections, rdseed, and pdcc.

Here is an example from rdseed:
Depth stored in /src/test/resources/depthcheck.xml
<Depth>-250</Depth>

Depth stored in output dataless:

052014900BDF0000002~001002+47.661570-122.313320+0250.0
-0250359.0+00.00001122.0000E+010.0000E+000000CG~2018,218,00:00:00.0000~2500,365,23:59:59.0000

Rdseed output:

#		+                  +---------------------------------------+                  +
#		+------------------|   Station TPASS   |    Channel BDF    |------------------+
#		+                  +---------------------------------------+                  +
#		
B052F04     Channel:                               BDF
B052F03     Location:                              00
B052F05     Subchannel:                            0
B052F06     Instrument lookup:       2             GEM (Infrasound), 0.2-50 Hz, 0.4 V/Pa-null
B052F07     Comment:                               (null)
B052F08     Signal units lookup:     1             PA - No Abbreviation Referenced
B052F09     Calibration units lookup:     2        V - Volts
B052F10     Latitude:                              47.661570
B052F11     Longitude:                             -122.313320
B052F12     Elevation:                             250.000000
B052F13     Local depth:                           -250.000000
B052F14     Azimuth:                               359.000000
B052F15     Dip:                                   0.000000

[yazan-iris]

Please follow language naming convention. You have been asked several times to do so, but you keep forgetting.

Has the local depth issue been approved by Casey?

[timronan]

@yazan-iris I fixed the variable name. I added @rcasey-iris as a reviewer as well. Please let me know if I should make any other changes.

[rcasey-earthscope]

Thanks for bringing me in. This change would appear to do the trick. I can understand wanting to truncate the number of decimals in the case of too many of them, but what benefit is there to zero-padding a string that then gets converted to a double? I might be missing something, but the conversion would seem to do away with zero padding. -Rob

…

On Jul 21, 2021, at 10:18 AM, timronan ***@***.***> wrote: @yazan-iris <https://github.com/yazan-iris> I fixed the variable name. I added @rcasey-iris <https://github.com/rcasey-iris> as a reviewer as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFL4VN7BQCRWOI7KAGEDGPTTY36NFANCNFSM5AWMRW3A>.

[timronan]

@rcasey-iris that formatting is undone by the double and should likely be removed. The formatting is actually occurring in java-4-seed. yazan-iris/java-4-seed@a78cb93

[timronan]

The circular logic was removed and the same test were conducted successfully.

Rdseed output:

B052F13     Local depth:                           -250.000000

Manual inspection in dataless:
052014900BDF0000002~001002+47.661570-122.313320+0250.0-0250359.0+00.00001122.0000E+010. 0000E+000000CG~2018,218,00:00:00.0000~2500,365,23:59:59.0000~

The lessthanzerodepth unit test also checks for this issue.

[rcasey-earthscope]

Hi Tim- Are you seeking approval for this version? -Rob

…

On Jul 21, 2021, at 2:35 PM, timronan ***@***.***> wrote: The circular logic was removed and the same test were conducted successfully. Rdseed output: B052F13 Local depth: -250.000000 Manual inspection in dataless: 052014900BDF0000002~001002+47.661570-122.313320+0250.0-0250359.0+00.00001122.0000E+010. 0000E+000000CG~2018,218,00:00:00.0000~2500,365,23:59:59.0000~ The lessthanzerodepth unit test also checks for this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFL4VNZO5OFCWH6BDK2VCJDTY44SVANCNFSM5AWMRW3A>.

[timronan]

Hi Rob,
Yes, if you think think version is ready to merge please let us know. Or please let us know further changes we can make. Thanks for the review.

[timronan]

@rcasey-iris thanks for the confirmation.

[timronan]

@yazan-iris are there additional changes that should be performed? Thanks

[rcasey-earthscope]

Are will still blocked on Yazan's approval on this issue?