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

[geofflewen]

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

[akrherz]

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]

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:

Gnashing of teeth intensifies...

[sgdecker]

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

[akrherz]

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]

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]

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 akrherz@iastate.edu

[akrherz]

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