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

METAR Site ID data for KGVW (Galveston 209B) is incorrect #3447

Open
geofflewen opened this issue Mar 20, 2024 · 7 comments
Open

METAR Site ID data for KGVW (Galveston 209B) is incorrect #3447

geofflewen opened this issue Mar 20, 2024 · 7 comments
Labels
Type: Bug Something is not working like it should

Comments

@geofflewen
Copy link

What went wrong?

METAR parsing functions (parse_metar_file, parse_metar_to_dataframe) are returning Site ID data for the now-defunct Grandview, MO site (as per Ryan May) instead of Galveston 209B. This creates anomalies in surface analyses when data for the current KGVW site (off TX coast) is plotted in Missouri. Dropping the record for KGVW from the dataframe removes the anomaly, but this is far from an ideal solution.

Operating System

MacOS

Version

1.5.0

Python Version

3.9.15

Code to Reproduce

from metpy.io import parse_metar_to_dataframe
KGVW = 'METAR KGVW 132355Z AUTO 13017KT M1/4SM FG OVC003 21/20 A2987 RMK A01='

df = parse_metar_to_dataframe(KGVW)
print(df[['station_id','latitude','longitude','elevation']])

# returns:
#            station_id  latitude  longitude  elevation
# station_id                                           
# KGVW             KGVW     38.83     -94.57        337

Errors, Traceback, and Logs

No response

@geofflewen geofflewen added the Type: Bug Something is not working like it should label Mar 20, 2024
@akrherz
Copy link
Contributor

akrherz commented Mar 20, 2024

Thanks for raising this metadata issue and something is very wrong with this situation as I checked the FAA metadata and it has GVW in Missouri... Great gnashing of teeth ahoy

@mzuranski
Copy link

Interesting, airnav doesn't seem to have it, and the below site is also getting it wrong:
https://airportnavfinder.com/airport/KGVW/

Meanwhile:
https://metar-taf.com/airport/KGVW-galveston-209b-weather-station
So that's closer, but those coords put the site in the ocean:
image

Gnashing of teeth intensifies...

@sgdecker
Copy link
Contributor

The station is marked on the VFR sectional chart, so at least some part of the FAA is aware of GVW's existence:

vfr

@akrherz
Copy link
Contributor

akrherz commented Mar 20, 2024

This is crazy, GEMPAK and AWIPS appear to be wrong too. Check out the NBE even

FEUS16 KWNO 201500
NBEUSA
KGVW    NBM V4.1 NBE GUIDANCE    3/20/2024  1500 UTC
   THU 21 |FRI 22 |SAT 23 |SUN 24 |MON 25 |TUE 26 |WED 27 |THU 28  CLIMO
TXN    35| 61  44| 63  30| 52  40| 60  49| 62  30| 49  30| 55  35  37 58
PSN     0|  0   0|  0   0|  0   0|  0   0|  0   4|  2   2|  0   1

@dopplershift
Copy link
Member

Just wanted to capture that we have both the old and MO ones:

❯ grep KGVW *
airport-codes.csv:KGVW,closed,Richards-Gebaur Air Force Base,38.84420013,-94.55999756,1093,NA,US,US-MO,Belton,KGVW,GVW,
grep: nids: Is a directory
sfstns.tbl:KGVW     999999 GRANDVIEW                        MO US  3883  -9457   337  0
stations.txt:MO GRANDVIEW        KGVW  GVW          38 50N  094 34W  337   X           A    7 US

I'll note that this is what Boris Konon sent to the Unidata data-curation list:

KGVW - Galveston 209A US TX
29.13 -94.55  37m

Note the "209A".

Beyond getting it correct, which it appears we're not quite there yet, there's also a question of if we have the capacity to deal with this for parsing old data, or if we just replace and move on. I will say at an API level it's simple enough to have methods that lookup with a datetime, but I don't know who wants to curate/add date/time to our station tables. Not to mention that I don't think that's even the biggest curation issue in our station tables.

<rant>
Table-based data formats suck. This is why data should have lat/lon info directly encoded. My kingdom for 20 bytes of information.
</rant>

@akrherz
Copy link
Contributor

akrherz commented Apr 2, 2024

I continue to effort straightening this out with upstream metadata sources, but have no progress to report yet. I do have a NCO ticket now of INC0463229 , in case others wish to be added it to. let me know at [email protected]

@akrherz
Copy link
Contributor

akrherz commented May 2, 2024

At least MOS has now been fixed

Effective on Monday, April 29, 2024, beginning with the 1200-UTC model run, the NWS NCEP Central Operations implemented an update to the NBM v4.1.  NBM v4.1 was implemented on Jan. 17, 2023 -
https://www.weather.gov/media/notification/pdf2/scn22-131_nbm_v4.1.pdf

This change updates the latitude and longitude of sites in the tables used to create blend text messages from the NBM gridded forecasts.

The following sites were corrected in the NBM table dictionary:

MMML:	MEXICALI_INTL_ARPT    N32.6306, W115.2414
KGVW:	GALVESTON 209A OIL PLATFORM :TX: :N29.1303, W094.5466

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Something is not working like it should
Projects
None yet
Development

No branches or pull requests

5 participants