Proposal: Removal of Relative Location/Reverse Geocoding (City) Info

[StephenClouse]

Since the beginning of API, we have had relative location info on the /points endpoint, showing the lat/lon's vector from a recognizable populated place:

{
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [-94.974, 39.064]
    },
    "properties": {
        "relativeLocation": {
            "type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-95.035813, 39.002474]
            },
            "properties": {
                "city": "Linwood",
                "state": "KS",
                "distance": {
                    "unitCode": "wmoUnit:m",
                    "value": 8678.1351645144
                },
                "bearing": {
                    "unitCode": "wmoUnit:degree_(angle)",
                    "value": 37
                }
            }
        }
    }
}

However, there have been a lot of lingering problems with this data. The main one is that this database is built off a US Census database, and the data is point-based using city centers rather than 2D city boundaries. So your point may be in the city but still give you something like "3 Miles NW of City".

We've looked into solutions for this — there are many internal data sets with boundaries that NWS uses for things like warnings — but these are all very purpose-built and not really suited for the general use cases that API needs.

We have also considered partnering with a third-party API like Esri or Google, but this is both prohibitively expensive and would make API dependent on another service that we can't control.

Finally, someone asked the question: do we even need this in API? There are a lot of reverse geocoding services out there, both free and commercial. Anyone with a serious geospatial application is probably already using one. Is there actually value in us providing and maintaining this data?

So, we'd like to find out.

Please let us know if you're using relative location (or not) and what you're using it for, and whether it's useful to you. This will help us make a decision on what to do with this data going forward.

[netbymatt]

I'm using relative location in both of my applications. Strictly speaking I pull out the city and state from it for display. I do not use the distance/direction portion of the data.

Both of my applications run on mobile as well as desktop. Mobile users typically have their forecast app set to always show info for their current location when they open the app. Since it's on mobile I generally have access to latitude and longitude and can feed that right into this API to get a point, and then the point endpoint is the gateway to the rest of the data I display in the app. Having the point endpoint also return a human-readable city name, even if it's "the next town over," gives the user good and quick feedback that their forecast and observations are updated for where they currently are.

I think people have come to accept that their weather app may not be 100% spot-on with their location. The built-in weather app on my android device (which I would assume uses Google's much more precise geospatial database) very frequently gives me a forecast for the next town over. But it still gives me enough confidence that it's pulling the right data.

[Orcazephyr]

I use relativeLocation for the same thing in my mobilie app.

[branmh]

Are you referring to removing the entire /points endpoint or just the relativeLocation dataset from its response?

I use the latitude and longitude for any called-in location, and rely on the /points endpoint to retrieve key values such as city, state, gridId, gridX, gridY, forecastZone, timeZone, and radarStation.

[scadergit]

Just the relative location property.

[branmh]

ok thanks.

[wsamoht]

I don't use relativeLocation.

[hnabbasi]

We use relativeLocation to get City and State and verify coordinates. Are you planning on moving these around or completely removing it? I do think there is value in showing the matched city and state for given coordinates. Not sure if the distance related properties are useful.

[paulnadler]

I use relative location in my app for the reasons mentioned by others, but also so that it matches what users would see if they were looking at forecast.weather.gov and were to click on a point on the map.

[JJKraw]

Similarly, I use the text to display the location for a forecast.