Open geofflewen opened 6 months ago
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
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...
The station is marked on the VFR sectional chart, so at least some part of the FAA is aware of GVW's existence:
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
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>
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
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
What went wrong?
METAR parsing functions (_parse_metarfile, _parse_metar_todataframe) 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
Errors, Traceback, and Logs
No response