Simple Location 4.4.0 was released early today, and I’m already working on 4.4.1, as there are things I’ve noticed in production that I did not in testing.

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.