Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outdated NEXRAD location database #1594

Open
gewitterblitz opened this issue Jun 4, 2024 · 9 comments · May be fixed by #1595
Open

Outdated NEXRAD location database #1594

gewitterblitz opened this issue Jun 4, 2024 · 9 comments · May be fixed by #1595

Comments

@gewitterblitz
Copy link

  • Py-ART version: 1.18.3
  • Python version: 3.9+
  • Operating System: MacOS/Windows/Linux

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')
@gewitterblitz gewitterblitz linked a pull request Jun 4, 2024 that will close this issue
1 task
@mgrover1
Copy link
Collaborator

mgrover1 commented Jun 5, 2024

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

@mgrover1
Copy link
Collaborator

mgrover1 commented Jun 5, 2024

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
Copy link
Collaborator

mgrover1 commented Jun 5, 2024

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
Copy link
Contributor

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
Copy link
Collaborator

mgrover1 commented Jun 5, 2024

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
Copy link
Contributor

@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
Copy link
Collaborator

mgrover1 commented Jun 5, 2024

@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
Copy link
Author

@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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants