ARM-DOE / pyart

The Python-ARM Radar Toolkit. A data model driven interactive toolkit for working with weather radar data.
https://arm-doe.github.io/pyart/
Other
501 stars 264 forks source link

Outdated NEXRAD location database #1594

Open gewitterblitz opened 3 months ago

gewitterblitz commented 3 months ago

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 the nexrad_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:

pyart.io.nexrad_common.get_nexrad_location('KTLX')
mgrover1 commented 3 months ago

Great point @gewitterblitz - thanks for raising this issue! And for adding a PR!!

mgrover1 commented 3 months ago

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).

mgrover1 commented 3 months 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).

kmuehlbauer commented 3 months ago

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.

mgrover1 commented 3 months ago

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?

kmuehlbauer commented 3 months ago

@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.

mgrover1 commented 3 months ago

@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).

gewitterblitz commented 3 months ago

@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.

gewitterblitz commented 3 months ago

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.