ARM-DOE
update NEXRAD location data using latest NCEI database
This PR takes care of the NEXRAD location discrepancy by pulling the latest information from the NCEI Historical Observing Metadata Repository directly. Interested users/developers can find the latest NEXRAD location database by clicking on the NEXRAD station list file view.
- [ ] Closes #1594
@mgrover1 Do we need any other changes except for the linting issues? For example, raising an error?
@gewitterblitz I just found this PR while needing to find out the NEXRAD locations. And I noticed that you should use skiprows=2 instead of skiprows=6, otherwise you don't get the info for the first 4 radars ('KABR', 'KABX', 'KAKQ', 'KAMA' ).
FYI:
- in the table there is not the info for
'KILM', 'KJAN', 'KRMX', 'KUNR'radars and the ROC testbeds (DAN1, DOP1, FOP1, NOP*, ROP*). - elevation is reported in feets although pyart already converts to meters in
get_nexrad_location.
Thanks for the heads up @ghiggi I have updated the pull request. I think the mismatch may have been due to the nexrad location file being updated from NOAA's end. It's a dynamic URL that they can update anytime they wish.
Yes, I realized that the get_nexrad_location function takes care of the unit conversion.
Regarding 'KILM', 'KJAN', 'KRMX', 'KUNR' radars: I don't think these radars are operational anymore. As all of these served for short terms (and went out of service before the dual-pol upgrade), I highly doubt anyone uses their data for research purposes. However, I could be wrong and it may be worthwhile adding their info to the list.
From what I have heard, the ROC testbeds have variable identifiers and are not meant for operational purposes. It may be better to add their geolocation manually while analyzing data and perhaps that's why the PyART team decided to not include those here. Happy to be corrected though!
Regarding
'KILM', 'KJAN', 'KRMX', 'KUNR'radars: I don't think these radars are operational anymore. As all of these served for short terms (and went out of service before the dual-pol upgrade), I highly doubt anyone uses their data for research purposes. However, I could be wrong and it may be worthwhile adding their info to the list.
This is correct from my understanding as well!
From what I have heard, the ROC testbeds have variable identifiers and are not meant for operational purposes. It may be better to add their geolocation manually while analyzing data and perhaps that's why the PyART team decided to not include those here. Happy to be corrected though!
Agreed - we should refrain from storing those shorter term locations as that could be dangerous in terms of analysis; users can specify that on their own!
@gewitterblitz - thinking about this more - what happens if the user is using a machine that does not have internet access? Within high-performance computing clusters, this would be common limitation...
We should store a copy of the table just in case. Otherwise, one would not be able to read/work with NEXRAD data if they are on a compute cluster without outside internet access...
@mgrover1 That's a valid point. Is there a way to create (or update) a NEXRAD geolocation look-up table from the NCEI URL every time there's a new PyART release? Perhaps a Github action task?