Retrieving Historical Weather Data Using Azure Maps Weather API

Question

I'm experiencing difficulties with the Azure Maps Weather API when trying to retrieve historical weather data for a specific location. Despite using the city and state in the query, I consistently receive a '400 BadRequest' error, indicating invalid or out-of-range coordinates.

I've reviewed the documentation and attempted various formats, but the issue persists. Here’s my API endpoint and query:

https://atlas.microsoft.com/weather/historical/actuals/daily/json?api-version=1.1&query=New+York%2C+NY&startDate=2022-07-25&endDate=2022-07-25&subscription-key=1234567890abcdef

Interestingly, I've discovered the https://atlas.microsoft.com/search/fuzzy/json endpoint, which can provide coordinates for a given location.

The question is: Why must two separate URLs be used to achieve this goal? Is there a single URL that can accept location names (city, state) and return historical weather data? Any guidance on resolving this issue or clarifying the API's usage would be appreciated.

Answer 1

It sounds like you discovered the weather service takes in a latitude, longitude value, and not raw location strings (as noted in the documentation). So, I suspect that you managed to get successful responses from the service and aren't blocked in that regard.

I'm not on the Azure Maps team, but have a pretty good idea as to why this service doesn't take in raw location strings:

• The weather service is provided by a third party (AccuWeather) who's primary focus is weather data, not geocoding locations. Geocoding data is provided by another company (TomTom).
• In most scenarios location information would already be geocoded for other purposes in the app, such as displaying the location. When it comes to historical data services which are most often used for analysis (e.g. machine learning), it is common to pre-geocode all location data for performance reasons. Generally, it is a best practice to pre-geocode your dataset and store the coordinate information with your records. The terms of use of Azure Maps allow you to store the coordinate information in Azure for as long as you have an active Azure Subscription. This can significantly save on costs, provides a good performance boost, and also enables spatial analysis to be done on your location data using code or built in tools in Azure (e.g. most of the database options in Azure have spatial calculations built in).
• To keep costs low. If this service supported passing in raw location strings, the price of this service would need to be increased to account for that cost. This would mean it would be more expensive for those who already have their location data geocoded.
• Accuracy! In that past I have used services that wrap geocoding into another service and often found this caused a lot of issues. When geocoding there are often several options you can add to help tailor your request to ensure you get the result you want (e.g. limit the results to a single country, like Poland, that way when you type in 90210 you get the postal code in Poland as the top result and not the US zip code). You may also want to choose from one of multiple results. This separation also allows for these services to evolve independently. You mentioned the fuzzy search service, which is actually an old geocoding service in Azure Maps, there is a newer service that is generally more accurate here: https://learn.microsoft.com/en-us/rest/api/maps/search/get-geocoding?view=rest-maps-2024-04-01&tabs=HTTP