Point->Gridpoint returns geo coords very much outside the point lat/long

[ktrue]

I make a query like:

https://api.weather.gov/points/37.2747,-122.0229

which returns the Gridpoint of

https://api.weather.gov/gridpoints/MTR/97,101/forecast

But... that Gridpoint geometry is shown as

    "type": "Feature",
    "geometry": {
        "type": "Polygon",
        "coordinates": [
            [
                [
                    -122.0508671,
                    37.773563799999998
                ],
                [
                    -122.045287,
                    37.751746599999997
                ],
                [
                    -122.0176567,
                    37.756160999999999
                ],
                [
                    -122.02323150000001,
                    37.777978699999998
                ],
                [
                    -122.0508671,
                    37.773563799999998
                ]
            ]
        ]
    },

As you can see, that polygon does not contain the requested point of 37.2747,-122.0229 The longitudes would bound the requested longitude, but the latitudes are all about 0.5 degree high.

Is there something wrong with the point->gridpoint mapping by the API??? I'm definitely getting the WRONG FORECAST because the forecast returned is not for the area requested.

[ktrue]

This problem appears to be happening for MTR gridpoints only. Tests show that LOX, STO, EKA are all working as expected. Only the gridpoints in MTR seem to be off by 0.5 degrees North latitude.

[ktrue]

I found an older return for MTR/97,101 geometry that was correct:

    "type": "Feature",
    "geometry": {
        "type": "Polygon",
        "coordinates": [
            [
                [
                    -122.0385572,
                    37.275548000000001
                ],
                [
                    -122.0330058,
                    37.253687900000003
                ],
                [
                    -122.00547899999999,
                    37.258113200000004
                ],
                [
                    -122.01102499999999,
                    37.2799738
                ],
                [
                    -122.0385572,
                    37.275548000000001
                ]
            ]
        ]
    },

[ktrue]

Checking this morning shows somebody must have reloaded the point->gridpoint cache lookups for WFO MTR as now it's only one gridpoint off (gridpoint bounds do not contain the actual point requested).

https://api.weather.gov/points/37.2747,-122.0229 request now returns
the gridpoint forecast as https://api.weather.gov/gridpoints/MTR/94,80/forecast and that has a bounds of

    "type": "Feature",
    "geometry": {
        "type": "Polygon",
        "coordinates": [
            [
                [
                    -122.0165981,
                    37.301800399999998
                ],
                [
                    -122.01105439999999,
                    37.2799598
                ],
                [
                    -121.9836361,
                    37.284362399999999
                ],
                [
                    -121.9891745,
                    37.306203500000002
                ],
                [
                    -122.0165981,
                    37.301800399999998
                ]
            ]
        ]
    },

As before, the point is outside the bounding box, but MUCH closer (probably only one gridpoint off now) so the forecast is MUCH better.
Still needs adjustment to have the point->gridpoint lookup produce a bounding box that ENCLOSES the point requested.

[chaunceygardiner]

Another data point, same result, now MUCH closer but still the wrong grid.

The call:
https://api.weather.gov/points/37.4315,-122.1109
Returns the 92,88 grid. I believe it should return 91,87.
I believe this may be a simple off by one error. In ktrue’s example above, he’s getting the grid 94,80 returned and 93,79 appears to be the correct grid.

Details for my case of https://api.weather.gov/points/37.4315,-122.1109

https://api.weather.gov/gridpoints/MTR/92,88/forecast returns polygon (which does not contain 37.4315,-122.1109):

"geometry": {
"type": "Polygon",
"coordinates": [
[
[
-122.1160977,
37.467745899999997
],
[
-122.1105197,
37.4459011
],
[
-122.0830553,
37.450318099999997
],
[
-122.088628,
37.472163299999998
],
[
-122.1160977,
37.467745899999997
]
]
]
},

The 91,87 grid returns the following polygon:
https://api.weather.gov/gridpoints/MTR/91,87/forecast
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
-122.13802870000001,
37.441464000000003
],
[
-122.13245160000001,
37.419633300000001
],
[
-122.10489700000001,
37.42407
],
[
-122.11046870000001,
37.4459011
],
[
-122.13802870000001,
37.441464000000003
]
]
]
},

[ktrue]

Now the https://api.weather.gov/points/37.2747,-122.0229 lookup returns
https://api.weather.gov/gridpoints/MTR/94,80/forecast which is (I think) Off-by-one as cited above.

https://api.weather.gov/gridpoints/MTR/93,79/forecast

does properly include my point in the rectangle bounds:

   "type": "Feature",
    "geometry": {
        "type": "Polygon",
        "coordinates": [
            [
                [
                    -122.0385242,
                    37.275553299999999
                ],
                [
                    -122.0329728,
                    37.253693200000001
                ],
                [
                    -122.00545919999999,
                    37.258116299999998
                ],
                [
                    -122.01100519999999,
                    37.279976999999995
                ],
                [
                    -122.0385242,
                    37.275553299999999
                ]
            ]
        ]
    },

As I said before, this only seems to be happening for the MTR data .. sure would like it fixed...

[chaunceygardiner]

I’ve requested that the bug I reported be reopened (INC0310812). It was closed as resolved, but the example I provided still does not work (although it gives a closer grid). Hopefully, it will be reopened.

[chaunceygardiner]

I got a reply. They know there is still a problem. I got added to another issue (INC0304072) which contains this comment:

“There is a bug here that is not yet fixed, however the displacement should only ever be one grid square, never more.
-- I suggest we close this ticket as we are tracking this in Jira for development of a future release of API. Date currently unknown.“

[jah1007]

We have purposefully consolidated all tickets that are the same symptom such that we only need to be updating one ticket. You should receive information when this consolidated ticket is updated. This was done to reduce the amount of tickets being tracked for the same issue. I have updated the Known Issues section of the documentation to reflect which offices will have points outside the bounding box.

[jah1007]

The change that has been running in the preview environment will be promoted to the operational environment on February 2nd and should be available by noon provided a Critical Weather Day is not declared. Please be advised, once the change is live and verified the preview site will be turned off to the public. A service change notice will be issued on February 2nd, outlining the successful completion of the update. You can monitor by going to weather.gov/notification

[jah1007]

A Critical Weather Day has been declared for February 2nd. We will be delaying the implementation until no sooner than February 7th.

[jah1007]

The change has gone live on api.weather.gov.

[jah1007]

We have identified a secondary change that needs to be made. We are working to get approval to make the change next week.

[jah1007]

We have just pushed what should be the final change required for this. Please let us know.

[ktrue]

The green box outlines the area for /gridpoints/MTR/94,80/forecast that is the return for a /points/37.2747,-122.0229 query.

It should return /gridpoints/MTR/93,79/forecast to make the forecast area actually around the point at 37.2747,-122.0229

Still off-by-one on the points->gridpoints lookup for MTR

[jah1007]

This is a known issue that is being worked in a separate ticket. We are unsure why but it only impacts some offices. They are listed in the Known issues section in the documentation on the "Updates" tab.

[JJKraw]

This is now happening with BOX gridpoints, which used to return valid data.

https://api.weather.gov/points/42.4399,-71.2405

    "gridId": "BOX",
    "gridX": 65,
    "gridY": 80,
    "forecast": "https://api.weather.gov/gridpoints/BOX/65,80/forecast",
    "forecastHourly": "https://api.weather.gov/gridpoints/BOX/65,80/forecast/hourly",
    "forecastGridData": "https://api.weather.gov/gridpoints/BOX/65,80",
    "observationStations": "https://api.weather.gov/gridpoints/BOX/65,80/stations",

[jah1007]

As mentioned above there are several Weather Forecast Offices that this impacts. The full list is available in the documentation. tl;dr BOX is one of them.