addressing inconsistent lat long formats

[wwieder]

we need to pull out information on the experimental levels (block/plot/rep) from the dropdown choices already provided by data providers

[wwieder]

@piersond and @srearl few questions on how we handle lat-lon data with homog 2.0:

1. Bring in the lat-lon corrections that Derek made into the homog script so we have clean L1 data to work with?

2. keep doing post-homog as we're doing now, or

3. force data providers to include decimal coordinates, with drop downs for N,S,E,W.

[wwieder]

More features for the homog script that could be helpful would be if we:

add network, site_code, and location_name information from the key-key to the _Key_Key_HMGZD_NOTES files produced so users can track down appropriate notes more easily. Maybe this can smooth out some of @bsulman 's concerns about details of experimental protocols.

[piersond]

@piersond Add clean.coords code block to homog. Looks at both location value from keykey, and raw data columns referenced in keykey profile sheet. FAIL QC if unable to convert value to decimal degrees (logical on is.numeric(value) after DMS convert to DD)

---> Send code to Stevan

[srearl]

Very sorry @piersond, I finally went to use this code but the conversation was no longer available in Slack (would be so nice if NCEAS would get the paid plan). Can you send it again? Looking through your SOM_clean_coords.csv file, it seems that there is a lot of variation to consider - I wonder if it might be best to accept only degrees?

[piersond]

@srearl Just returning from vacation today, now have three days to prep for SSSA presentation, thus not much time for SOM code this week. I looked at building the lat-long fix into the harmonization script, but then got to thinking that the new QC checks will confine all future keykey coordinates values to decimal degrees. So perhaps we don't have any further need for this feature...? Thoughts?

[srearl]

Thanks @piersond, yeah busy days. I like that as there is really no way to convert things like, for example UTMs (without knowing the projection). So, restricting input to lat long in decimal degrees is a reasonable approach - the investigator can do this. I guess then we should remove the drop-down option to provide the data in degrees, minutes.?.

[piersond]

@srearl Agree. While possibly creating some tedious conversion work for data providers, I think the downstream homog flow will benefit by requiring ALL coordinate values in decimal degrees.

[wwieder]

I think we're up to date with corrected lat-lon coords provided for each site for all the data in the current tarball. @piersond , we'll likely need to generate an updated list of sites that are missing Key_V2 and then run new tarball to work from soon @srearl .

[piersond]

@wwieder I'll do my best to remember to set loose the key crawler when I get home tonight

[srearl]

is this one done?

[piersond]

yes, now constrained to decimal degrees in the keykey and homog QC