It is currently July 16th, 2020, 12:37 am

⭐ Searching for weather.com Location Codes (USVA0944)

Our most popular Tips and Tricks from the Rainmeter Team and others
User avatar
jsmorley
Developer
Posts: 21024
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

⭐ Searching for weather.com Location Codes (USVA0944)

Post by jsmorley »

Ok, so I bit the bullet and spent some time figuring out how we can host the weather.com LocID Location Codes.
These are the 8-character codes like USVA0944 that you likely used with the now defunct wxdata.

It's now in a database on the Rainmeter server, and should be quite fast and easy to search.

964,247 records
280 distinct countries / states
823,942 distinct locations

To search the database in your browser, you will use the following URL:


https://admin.rainmeter.net/LocationCodes.php?country=Virginia&location=Fort Hunt


Replace "Fort Hunt" and "Virginia" with the data you want to search for. Or you could move...



Here are the rules...

1️⃣ All searching is case-insensitive.

2️⃣ country is optional. It defaults to "any".
https://admin.rainmeter.net/LocationCodes.php?location=Fort Hunt

3️⃣ location is required, as without it, you will certainly get more than the maximum 100 results I allow. Trust me, if you search for country=USA and nothing else, that would be 34,918 hits if I didn't choke it off at 100. The database would be fine with that, your browser, or WebParser, most certainly would not.

Having said that, using both country and location can be very helpful in zeroing in. Searching for location=Springfield without an entry for country will return a boatload of hits. Searching for country=USA Ohio or even just country=Ohio and location=Springfield should get you a small number of results. Three, to be exact..

4️⃣ country is stored as the full name of the country, using the English spelling / ASCII Characters of the name. You can search for all or part of it.

So it is Germany, not Deutschland.

The exception with country is the United States. That is stored as "USA - StateName", i.e. "USA - Virginia". So in effect, each state is a "country".

USA - Alabama, USA - Alaska ... USA - Wyoming.

If you want to search the entire United States, you search for USA. If you want to search just Ohio, you search for Ohio, and it will use USA - Ohio.

It should be noted that for locations in the UK, the country is always "UK - United Kingdom". There are no country entries for England/Scotland/Wales/Northern Ireland. Probably should be, but the data is what it is. Sorry, we won't be having a referendum on this...

5️⃣ location is stored using the English spelling / ASCII Characters of the name of the city, region or other local area. This can be very, very granular and exact indeed, far more so than if it was just based on city. For example, Albania has about 36 decent-sized cities and towns, but has 4,108 locations in the database.

So it is Munich, not München, and Tokyo, not 東京.

There are no characters having à grave, á acute, â circumflex, ã tilde or ä umlaut accents. Just a-zA-Z and -`'.

6️⃣ All searches are returned sorted by country - state, then location.

7️⃣ All searches are internally bookended by the SQL % (zero or more) wildcard character in the search. So country=Virginia will always and automatically search for %Virginia%, and would find both "USA - Virginia", and "USA - West Virginia".

The Windows * (zero or more) wildcard character can be used in a search. For instance country=S*Korea, would find "South Korea".

The Windows ? (exactly one) wildcard character can be used in a search. For instance country=F????e, would find "France".



When you search in your browser, you will get results like this:
1.png


And if you "View source", you will find:

Code: Select all

<!DOCTYPE HTML>
<html lang="en-US">
<head>
<title>Rainmeter - Location Codes</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="pragma" content="no-cache" />
<style>
  body {
    font-family: Sans-serif;
    font-size: 100%;
    font-color: #2F2F2F;
    background-color: #FFFFFF;
  }

  div {
    width: 95%;
    position: absolute;
    top:0;
    bottom: 0;
    left: 0;
    right: 0;
    margin: auto;
 }
 </style>
</head>
<body>
<div>SearchCountry : Virginia<br />SearchLocation : Fort Hunt<br /><br /><country>USA - Virginia</country> - <location>Fort Hunt</location> : <code>USVA0944</code>
</div>
</body>
</html>
So as you can see, this should be all you need to attack this with WebParser as well...

<country>USA - Virginia</country> - <location>Fort Hunt</location> : <code>USVA0944</code>

Here is an example skin:


⭐ Weather.com


01.png


So you can search by location or location and country, and when you click on the code that is returned, i.e. USVA0944 in this example, that code can be written to any .ini or .inc file you like, and then the config you want to use it in can be refreshed. See the skin for how this works.

The way I might search in this is to first search for country, to get me to the right part of the world. Then start zeroing in on location til I find what I'm looking for.

In this skin, I return and display up to the first 10 results based on your search. Feel free to change this skin or create your own that returns more matches, but do be aware that the code that queries the database is designed to return at most 100 results per search. You won't be able to download a huge list and just scroll through it. There are about 1 million records in the database, and no computer you own is going to be able to deal with that amount of data. We are also just not going to tie up our CPU or eat up bandwidth sending boatloads of data that isn't the purpose of this database.

If you really want all the data for your own purposes, it can be downloaded here:

LocationCodes.zip
You do not have the required permissions to view the files attached to this post.
User avatar
jsmorley
Developer
Posts: 21024
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Searching for weather.com Location Codes

Post by jsmorley »

Added the ability in the skin to click on any returned "location name", and Google Maps will be opened in your browser, pointing to the location defined by the country and location returned from the database.

Code: Select all

LeftMouseUpAction=["https://www.google.com/maps/search/[&MeasureLocation1] [&MeasureCountry1]"]

1.png


That way you can check to be sure you have found the location you think you have... Who you gonna believe, me or your lying eyes?
You do not have the required permissions to view the files attached to this post.
User avatar
eclectic-tech
Rainmeter Sage
Posts: 4044
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: ⭐ Searching for weather.com Location Codes

Post by eclectic-tech »

8-) :D
User avatar
jsmorley
Developer
Posts: 21024
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Searching for weather.com Location Codes

Post by jsmorley »

Changed the skin to use a single 🔍 "Search" button to execute the search, rather than having each of the two 🔤 "input" fields do it, which pretty much meant always searching twice...
Eugeneo
Posts: 3
Joined: February 25th, 2020, 2:48 pm

Re: ⭐ Searching for weather.com Location Codes (USVA0944)

Post by Eugeneo »

It's been a while since I've edited my weather skin. :???: Could you please add a String with a "current city name" to yours?
User avatar
jsmorley
Developer
Posts: 21024
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Searching for weather.com Location Codes (USVA0944)

Post by jsmorley »

Eugeneo wrote:
February 25th, 2020, 2:52 pm
It's been a while since I've edited my weather skin. :???: Could you please add a String with a "current city name" to yours?
This really doesn't have anything to do with this skin that searches for Location Codes. There is no good way, and no real logical reason, to bake into this skin values that are used by a "parent" skin that is calling it.

Feel free to edit whatever weather skin you are using to force it to pass information to this skin, and then edit it to display as you like. I won't be doing that in this skin, as it really reduces the usefulness of this as something that can easily just be dropped into any weather skin without a lot of effort.
Eugeneo
Posts: 3
Joined: February 25th, 2020, 2:48 pm

Re: ⭐ Searching for weather.com Location Codes (USVA0944)

Post by Eugeneo »

jsmorley wrote:
February 25th, 2020, 3:21 pm
can easily just be dropped into any weather skin
I'm quite rusty at this :confused: Sorry
Seems like the city name is stored in WeatherComCodes.ini under InputLocation. But how do I refer to this file and this line from Weather.com.ini?
User avatar
jsmorley
Developer
Posts: 21024
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Searching for weather.com Location Codes (USVA0944)

Post by jsmorley »

Eugeneo wrote:
February 25th, 2020, 5:11 pm
I'm quite rusty at this :confused: Sorry
Seems like the city name is stored in WeatherComCodes.ini under InputLocation. But how do I refer to this file and this line from Weather.com.ini?
The actual location name that Weather.com.ini is using is already there....

It's in the values for the measures [@LocationName], [@LocationAdminDistrict], and [@LocationCountry]



1.png


It doesn't make sense to have Weather.com.ini try to "read" what is in WeatherComCodes.ini, as the values stored there are transitory, and only used to search for the proper LocationCode to use with the weather skin. The order things are done in are:

1) You open the WeatherComCodes.ini skin from Weather.com.ini.
2) You enter some Location and / or Country information in the search fields.
3) You click "search"
4) The values you used to search by, which may be all or part of the actual location name the database has, are written to WeatherComCodes.ini. This is just so it can populate the "starting values" of the search fields with your latest search efforts.
5) When you find the LocationCode you want, you click on it, and the actual Location Name and Country Name information from our database is written to WeatherComCodes.ini. Again, just so it is "persistent" when you refresh or reload WeatherComCodes.ini.
6) Then, the entire point, WeatherComCodes.ini writes just the LocationCode (I.e. USVA0944) to whatever .inc (include) file you define. It then refreshes a skin you define that "uses" that .inc (include) file. In the example skin, that is Weather.com.ini.
7) The weather skin, Weather.com.ini in this case, then uses that LocationCode to go to weather.com and get the weather. Part of what is returned by weather.com to the skin are the ACTUAL fields for location information, as shown above.

The location and country name information used by WeatherComCodes.ini are ONLY useful for finding the right LocationCode (i.e. USVA0944) in the database we host. Those names have nothing directly to do with what the weather.com website has for location information.
You do not have the required permissions to view the files attached to this post.
Eugeneo
Posts: 3
Joined: February 25th, 2020, 2:48 pm

Re: ⭐ Searching for weather.com Location Codes (USVA0944)

Post by Eugeneo »

jsmorley wrote:
February 25th, 2020, 6:01 pm
The actual location name that Weather.com.ini is using is already there....
It's in the values for the measures [@LocationName], [@LocationAdminDistrict], and [@LocationCountry]
I used those measures before. Turns out it won't display several city names, including my own.
Thank you for the detailed explanation. I'll try to get around this problem.
Last edited by Eugeneo on February 28th, 2020, 1:34 pm, edited 3 times in total.
User avatar
SilverAzide
Posts: 887
Joined: March 23rd, 2015, 5:26 pm

Re: ⭐ Searching for weather.com Location Codes (USVA0944)

Post by SilverAzide »

Eugeneo wrote:
February 26th, 2020, 8:12 am
I used those measures before. Turns out it won't display several city names, including my own.
Thank you for the detailed explanation. I'll try to get around this problem.
It looks like the weather.com data is partly to blame. The JSON data normally includes two sections of location data, but in your particular situation, only the first one exists and the second section contains an error:

Code: Select all

"Location": {
            "geocode:62.12,49.83:language:en-US": {
                "loading": false,
                "loaded": true,
                "data": {
                    "location": {
                        "latitude": 62.107,
                        "longitude": 49.903,
                        "city": "Gam",
                        "locale": {
                            "locale1": "Ust-Vymsky District",
                            "locale2": "Gam",
                            "locale3": null,
                            "locale4": null
                        },
                        "neighborhood": null,
                        "adminDistrict": "Komi Republic",
                        "adminDistrictCode": null,
                        "postalCode": "169031",
                        "postalKey": "1690:RU",
                        "country": "Russia",
                        "countryCode": "RU",
                        "ianaTimeZone": "Europe\u002FMoscow",
                        "displayName": "Gam",
                        "dstEnd": null,
                        "dstStart": null,
                        "dmaCd": null,
                        "placeId": "a2ab61a417cec47fd5b8338b2d2e05b5cb114adbcba69b25801e0aece9fe2d26",
                        "disputedArea": false,
                        "canonicalCityId": "194d048ffd58bdc9c82fe07e046f281982a2afbab94f65bb200f1c1fb0976129",
                        "countyId": null,
                        "locId": null,
                        "locationCategory": null,
                        "pollenId": null,
                        "pwsId": null,
                        "regionalSatellite": "eur",
                        "tideId": null,
                        "type": "postal",
                        "zoneId": null
                    }
                },
                "ttl": 86400,
                "date": 1582719989000
            },
            "canonicalCityId:194d048ffd58bdc9c82fe07e046f281982a2afbab94f65bb200f1c1fb0976129:language:en-US": {
                "loading": false,
                "loaded": false,
                "error": "API call error - {\"errors\":[{\"error\":{\"code\":\"LOCATION-SERVICES: 404\",\"message\":\"No data found for your request.\"}}]} - https:\u002F\u002Fapi.weather.com\u002Fv3\u002Flocation\u002Fpoint?apiKey=d522aa97197fd864d36b418f39ebb323&canonicalCityId=194d048ffd58bdc9c82fe07e046f281982a2afbab94f65bb200f1c1fb0976129&format=json&language=en-US"
            }
        }
This is a known issue and is complicated by the fact that the second section usually has the better data as far as names are concerned. The current skin code attempts to grab the "best of both sections", but obviously there are cases that can fail. My suggestion would be to have some backup measures that will grab values from the first section when the second section fails.
Gadgets DeviantArt More...