Grid (station, X, Y) does not corresponding to GPS point

[spesavento]

An example, take GPS point 36.626,-121.844

Call
https://api.weather.gov/points/36.626,-121.844

That returns hourly forecast:
https://api.weather.gov/gridpoints/MTR/98,72/forecast/hourly

The result of the hourly forecast specifies a polygon region that does not include the original GPS point? I find this true with many GPS points I've tested. Perhaps I don't understand the polygon return, but lately I've been getting not-accurate weather data from API calls (by not-accurate I mean it is wildly different from several other models).

[StephenClouse]

There is a known issue with the MTR gridpoints being offset from where they should actually be. We are actively working on a fix.

[gerrypez]

I'm not sure if it is related, several MTR grid points give status 500 errors. Some examples:
https://api.weather.gov/gridpoints/MTR/106,127/forecast/hourly
https://api.weather.gov/gridpoints/MTR/69,161/forecast/hourly
https://api.weather.gov/gridpoints/MTR/104,152/forecast/hourly
https://api.weather.gov/gridpoints/MTR/68,163/forecast/hourly

[benghunt]

this is not just an MTR issue, it is approximately 12% of lat / lon city coordinates.

the work around is that it is almost always (56/56) an off by 1,1 error.

i just test to see if the lat / lon is in the polygon using shapely and if it doesn't change the grid endpoint to gridX-1, gridY-1 and use that endpoint

[jah1007]

Correct. The offices impacted are listed in the known issues section of the “Updates” tab at https://www.weather.gov/documentation/services-web-api

[JJKraw]

BOX gridpoints had been off by 1,1 for a while, but sometime recently that changed. I now need to subtract 1, add 12 to get the right forecast box for a given latitude and longitude.