David Shanske

The smaller items:

• Add MapQuest’s own API in addition to the existing OpenMapQuest Geo Provider, which is a hosted Nominatim.
• OpenMapQuest and LocationIQ are now descendants of the nominatim provider, as they all use the same output format.
• Add Pelias Provider. OpenRoute is a hosted instance of Pelias, so the OpenRoute class inherits its workings from this class, but allows for using a self-hosted Pelias provider, though I didn’t test that.
• Fixed an issue with the Google geo return.
• Reviewed all geolocation APIs and updated the returns.
• Standardized the country codes returned on all APIs to the ISO2 2 letter country codes.
• Standardized the addition of region codes, special casing US and Canada.
• Added a Home Country setting to allow omitting the home country from location displays. Example: If you live in the United States, it won’t say New York, NY, US. It will just say New York, NY.
• Support generating street addresses for countries where the house number appears after the street name, instead of assuming it will always be before.
• Tried to put labels on the weather form fields for accessibility.
• Added historic weather lookup to Micropub enhancements.
• Add a bulk action to lookup and add location(private by default) for multiple posts.

The biggest piece is the introduction of the location taxonomy. This is different from the proposed venue taxonomy. Location is a coarse location, whereas venue is a fine location.

The new Location taxonomy is designed with three levels. Country, region, and locality. Locality is the city, village, or town. So, the system is not designed to go down more than 3 levels. By default, this allows for archive pages like /location/us/ny/new-york for all posts in the locality or city of New York. Or /location/us/ny for all posts in the region or state of New York.

When you look up any location, it should automatically create the terms reflecting that location. This is where the problem comes in. Despite my attempts to standardize the returns from the reverse geolocation lookup, not only will the returns vary by provider(if you switch), but the return will not always match what you’d expect.

For example, Rome sometimes shows up as the Italian, Roma. So, I am already working to try to improve matching different versions of the same location. But this may require some manual action(merging, marking, etc not sure yet) to garden. But you have this same problem when trying to organize your digital music collection, or anything you categorize. The goal is to make the need as infrequent as possible.

What might be next? Other than 4.4.1, which will address some of the more obvious issues I discover as I use the feature myself(or from others), possible features related to this include:

• Displaying the location taxonomy instead of the location text.
• Functions to improve the archive experience, possibly if the theme is aware

Curious to see opinions as people have them.

IndieAuth 3.6.0 was started after the latest refresh of the IndieAuth spec(summary of the changes to the spec here). It actually made things a lot simpler, by eliminating many complexities and fixing some minor issues.

• street-address – house/apartment number, floor, street name
• extended-address – additional street details
• locality – city/town/village
• region – state/county/province
• postal-code – postal code, e.g. ZIP in the US
• country-name – full name of country or country code.

The problem is, returns are not so consistent.  Not only will the same coordinates not always produce consistent results, but the fields always change. So, the logic to map to the above properties isn’t always consistent or easy to write.

The second part of the problem is display. How to actually display the information. This isn’t the same as traditional address issue, this is how to display it in context on posts.

For example, for the White House…

• • Nominatim – White House, 1600, Pennsylvania Avenue Northwest, Washington, Washington, D.C., 20500, United States
  • Mapquest – 1602 Pennsylvania Avenue, Washington, District Of Columbia, United States
  • OpenMapquest and LocationIQ – White House, 1600, Pennsylvania Avenue Northwest, Golden Triangle, Washington, District of Columbia, 20500, United States of America
  • Google – 1600 Pennsylvania Avenue Northwest, District of Columbia
  • HERE – 1600 Pennsylvania Ave NW, Washington, DC 20500-0005, United States, Washington, District of Columbia, United States
  • Bing – 1600 Pennsylvania Ave NW, Washington, DC 20006
  • Geonames – District of Columbia, District of Columbia, United States
  • OpenRoute – 1600 Pennsylvania Avenue NW, Washington, DC, USA, White House Grounds, Washington, District of Columbia, United States

Reverse geocoding…taking coordinates and returning a location name, will never be 100% consistent, But I decided I needed to do better than this, and am working to adjust to be more consistent. Unfortunately, with 9 different providers, it takes a while to figure out what I’m going to do. Redundancy is good, but has its challenges.

Measurements in Simple Location have been stored in scientific units(celsius, meters, etc) since 2019, with an option to display in imperial on the frontend. With 4.2.2, the admin will now show in imperial units if you set the setting. This can be overridden on any page by adding the ?sloc_units=metric or ?sloc_units=imperial to the end of the URL.

4.3.0 introduces Meteostat and Visual Crossing as weather providers. Visual Crossing is the first provider that not only offers 1000 queries per day, but pay per use at a fraction of a cent after that. All of the other providers offering a free tier require a monthly fee after that point that well exceeds justification for the amount of posts even the most dedicated poster makes.

Meteostat is a historic only provider. It offers not only an API(key required), but the ability to download all data on a specific weather station(which requires no key). A future version of the plugin could download and cache the weather stations you use the most. For now, only the list of stations is bundled with the plugin, which it uses to determine the closest station.

The National Weather Service, the Met Office(UK), and the Custom Station plugin also cycle through lists of stations to find the closest one.

Expect more enhancements in the weather station category, with so many different ways to get weather stations data.

4.3.0 introduces historic weather support, for providers who offer this without a premium account. This includes Dark Sky(if you still have an API key), Meteostat(which only offers historic data), and Visual Crossing. If someone is paying for premium service on OpenWeatherMap and wants to talk me into adding this, send me a note.

The Fallback Weather provider feature introduced in 4.2.0, which allows for a secondary provider, will be checked if the primary provider does not offer historic weather.

Please remember, somewhere on your site, to provide attribution to the services you use. I’m off to backfill weather on my old posts.