Multistate release changes needed following reviews

[lindsayplatt]

Overall

• [x] Clarify naming conventions when our site_ids use { }, as it caused quite a bit of confusion. "These are a mix of characters and can sometimes include special characters, such as {}".
• [x] ~Make the relationship of site_id across all files to the location information in lake_metadata.csv more obvious. Maybe in the “Summary”?~
• [x] Check lake counts across various parts of the data release. The 2_config metadata file says there are 7144 lakes, but there are 7151 pb0 nml files. The lake_metadata.csv has 7150 lakes and the pb0_config.json has 7150 sites. Should be using 7,150.
• [x] Delete child item called “intermediate_files”?
• [x] Fix issue with FGDC violation – related to us using “descgeog” to describe the metadata. The error says the value for Geospatial Data Presentation Form (geoform) cannot be empty. Wonsook suggests that it can be easily fixed by choosing an appropriate category from the given examples such as tabular digital data, vector digital data, raster digital data, spreadsheet, remote-sensing image, application/service, and publication. -- Make sure that all references and cross-references have geoform (which appears to be the file-format field in our yml files).

1_spatial

• [x] Add note to metadata description of group_id in 01_lake_metadata.csv to let people know that there are some leading 0s and this column should be treated as character.
• [x] Update metadata ranges for centroid_lon and centroid_lat

2_config

• [x] Investigate why “nhdhr_59746189” has a pb0 nml file but does not appear in the pb0_config.json file. @jread-usgs to look into this. Maybe a model we created a config for but ultimately failed because it couldn't be run. Remove the nml file for this site (see bad_segfault_lake target)
• [x] Add the naming convention used for pb0 nml files to the metadata

3_observations

4_inputs

• [x] Update naming conventions declared in 4inputs for NLDAS files (inside `inputszips). They do not currently match. They look likeNLDAS_time[0.359420]_x[284]_y[164].csvbut the metadata says they follownldas_meteo_N{minN-maxN}_W{minW-maxW}.csv. Similarly, the 1_spatiallake_metadata.csvfile column calledmeteo_filename` follows the metadata convention but doesn’t match the actual filenames stored in the inputs zips. @jread-usgs find the function from mntoha that rewrites these filenames and apply here.
• [x] 04_group_meteo.png should have embedded metadata info to meet 508 compliance requirements. Add "alt text" -like text within the file description.

5_predictions

• [x] 05_group_lakes.png should have embedded metadata info to meet 508 compliance requirements. Add "alt text" -like text within the file description.

6_habitat

• [x] Update the maximum range for year from 2018 to 2019.

[jordansread]

Let's also make sure we cite LAGOS for depth data if we aren't doing that already.

[lindsayplatt]

In morphometry: "some depth data came from [LAGOS CITE]" Add to 2_config cross sites. Ask Sam Oliver

[jordansread]

For this

Update naming conventions declared in 4inputs for NLDAS files (inside inputs zips). They do not currently match. They look like NLDAS_time[0.359420]_x[284]_y[164].csv but the metadata says they follow nldas_meteo_N{minN-maxN}_W{minW-maxW}.csv. Similarly, the 1_spatial lake_metadata.csv file column called meteo_filename follows the metadata convention but doesn’t match the actual filenames stored in the inputs zips. @jread-usgs find the function from mntoha that rewrites these filenames and apply here.

I adjusted the file names in the metadata file to match the actual file names (the time range was off, which is an issue we had elsewhere too) and uploaded that file. Then I modified the metadata yaml text which was copy-pasta from mntoha, which had updated templates for the meteo file names that we're not using here. That should take care of this one. The xml was manually uploaded. The csv for the metadata was uploaded w/ scmake (I didn't what to scmake more than that since this repo has connections to the lake-temperature-model-prep repo, and we recently changed max depth values in some of those lakes).

[jordansread]

For

investigate why “nhdhr_59746189” has a pb0 nml file but does not appear in the pb0_config.json file. @jread-usgs to look into this. Maybe a model we created a config for but ultimately failed because it couldn't be run. Remove the nml file for this site (see bad_segfault_lake target)

I removed this file from the zip and got it back up on sciencebase. So now that lake isn't included. Verified the lake counts match our expectations now.

[lindsayplatt]

Re FGDC missing geoform issue. While the meddle template does have this templated for larger-cites, it is missing it for cross-sites. When we get this error for the larger-cites it is because we are truly missing the form: field (see here).

To fix:

1. Update meddle so that cross-cites also has form.
2. Add form: to ymls for larger-cites

[lindsayplatt]

I can update some but not all SB metadata items because some are still tied to the other data files.

• [x] out_xml/00_parent.xml --> run scmake("log/00_parent_sb_xml.csv")
• [x] out_xml/01_spatial_sb.xml --> run scmake("log/01_spatial_sb_data.csv")
• [x] out_xml/02_config_sb.xml --> run scmake("log/02_config_sb_data.csv")
• [x] out_xml/03_observations_sb.xml --> run scmake("log/03_observations_sb_data.csv")
• [x] out_xml/04_inputs_sb.xml --> run scmake("log/04_inputs_sb_data.csv")
• [x] out_xml/05_predictions_sb.xml --> run scmake("log/05_predictions_sb_data.csv")
• [x] out_xml/06_habitat_sb.xml --> run scmake("log/06_habitat_sb_data.csv") @lindsayplatt will complete but has to wait to update meddle on Yeti before she can use the new version and complete this task

@jread-usgs will need to complete 01 through 05 but will need to make sure that my general metadata changes are added to the pipeline (so blocked until this gets merged) & meddle gets updated first (so blocked until this is merged).