Open gewitterblitz opened 3 months ago
Great point @gewitterblitz - thanks for raising this issue! And for adding a PR!!
This does raise a good question though - do users always need the most updated locations? In some cases, it might be wrong with the updated information (someone running a case study from a few years ago).
I think dynamically loading the metadata makes sense here - but we should at least throw a warning that it could not find the location in the metadata, and is using the most recent latitude/longitude of the radar (and it is on the user to pass in the lat/lon if it is older).
but we should at least throw a warning that it could not find the location in the metadata, and is using the most recent latitude/longitude of the radar (and it is on the user to pass in the lat/lon if it is older).
I'd vote for raising in that case, better safe than wrong.
but we should at least throw a warning that it could not find the location in the metadata, and is using the most recent latitude/longitude of the radar (and it is on the user to pass in the lat/lon if it is older).
@kmuehlbauer Raising a warning, or an error here?
@mgrover1 As we all know, warnings might be swallowed by any user code.
The error message should point the user to some code/ docs, where he can find the radar location of that radar scan.
@gewitterblitz - is this a recent file you are trying to load?
The locations were written here to support older files that were missing this critical metadata... if we load the recent locations when trying to read older data (prior to 2014).
@mgrover1 Yes, I noticed that the backend doesn't really use the hard coded locations if more recent NEXRAD files are read through PyART. However, we may still need these for older files and/or files with corrupted metadata.
I am unsure if the hard-coded location data became outdated over time or had issues from the beginning. The KTLX radar elevation likely hasn't changed between 2014 and 2024, though it's worth verifying. The values in the dictionary may have been copied from an inaccurate source, and the NCEI team might have updated their database to correct these errors since then.
I agree with @kmuehlbauer about raising an error when the user specified station is missing in the location database.
Fun fact: I discovered this issue while searching for a reliable WSR-88D elevation data source. It was surprisingly difficult to locate through a simple Google search.
Including the updated WSR-88D location information in PyART could help users in quickly retrieving radar locations for their specific needs.
Description
The static NEXRAD location data in the
pyart/io/nexrad_common.py
script seems outdated. There are considerable differences in the radar elevation between the static dictionary in thenexrad_common.py
script and the official database.For example, the location information for the KTLX radar in the nexrad_common.py file is noted as:
"KTLX": {"lat": 35.33306, "lon": -97.2775, "elev": 1213}
However, the NCEI database describes the KTLX radar location as follows: "KTLX": {"lat": 35.333361, "lon": -97.277761, "elev": 1278}
The radar elevation seems to have the maximum difference, but latitude and longitude values are affected as well. Elevation in both examples is specified in feet.
What I Did
I used the following command to retrieve the static data for KTLX radar in PyART: