Kind: Articles

Simple Location has been updated. There is more I wanted to do, and will do to finish this, but this is what was released today.

• AerisWeather is now a provider
• A lot of code cleanup and documentation
• Improvements to Airport data, adding of airline data, and additional data sources to avoid on demand download.
• Standardization and documentation of units
• Addition of the ability to set a custom icon instead of the location arrow.
• Lots of improvements if you use Compass to what it can derive
• Airport location provider now supports IATA and ICAO airport codes.

I did want to add local weather stations and a few other features, but I decided to release and work on those features later.

Version 4.0.6 of the Simple Location plugin has been released. A lot of the under-the-hood improvements involved the development environment…working on some automations for code testing that I’m going to add to my other projects.  User facing, the following features are now available

• HERE Maps is joined by using HERE as a Weather and a Reverse Geocoding provider. While doing this, I discovered they switched to an API key system, and updated the code appropriately. HERE Maps also has a new endpoint, so I switched to that as well.
• I went through the API documentation for all of the existing weather endpoints and made some changes to standardize the units of measurement being stored.  Did you know a millbar and a hectopascal are essentially the same thing?
• I added support for the Met Office, which offers several hundred stations in the UK. Like the US National Weather Service, it provides the closest one, and if there isn’t close, it returns nothing. Working on another station-based weather provider interested me in trying to add better support for personal weather stations.
• If you have WP_DEBUG enabled, a new tab appears on the Location Settings page to allow you to see what data is returned by your provider. This is used mostly by me as the developer, but I’ve kept it in in case someone wants to troubleshoot the information they are getting.

 

Much to my annoyance, at the end of March, Dark Sky announced it was now part of Apple and was immediately shutting down its Android app and would be shutting down its public API at the end of 2021. So, Dark Sky, my favorite weather service, is going to be dead to me.

However, this is not the first time an API has shut down on me. I created a WordPress plugin called Simple Location. It uses map APIs to show maps of location, reverse geocoding APIs to turn coordinates into location data, and of course, Weather APIs to get the weather for a location at the time of a post.

I like adding weather to my posts, and I maintain my own weather stations at two locations. So, I went through all of the Weather API I have integrated  to note some of the pros and cons.

• HERE – The newest provider I’ve added. It returns some info none of the other providers do: Descriptor values for air, sky; a textual description of the air, temperature, and precipitation; Snow cover as well as amount that has fallen; wind speed on the Beaufort scale; UV index; Barometric trend And their free tier offers 250,000 transactions per month. Does not offer historical data.
• National Weather Service – No API key or limits as government data. Doesn’t keep more than a few days of historic data. Good general data. You are also limited to NWS Observation and forecast stations.
• OpenWeatherMap – The free tier limits you to 1000 calls per day, and a limited subset of their APIs. However, in response to the Dark Sky situation, they just added a new API endpoint that is included, which mirrors the Dark Sky API offering. It offers the current weather, hourly forecast for 48 hours, daily forecast for 7 days, and historical weather data for 5 previous days. It also offers a Stations API for retrieving data from a user supplied weather station. UV Index is available, but that is a separate API call.  They’ll also sell you 40 years worth of weather data for a single location for 10 cents.
• Weatherbit – Daily forecasts and current weather data is free for non-commercial use. Offers UV Index and Air Quality Index.  Allows for historical data.
• WeatherStack – Free tier limits you to 1000 calls per month, so this is the one I’m least likely to use. Does include historical data.
• Met Office UK – The UK’s service has the most basic of all the data provided. Behind a free API key, you can get information for several hundred stations in the UK. However, the Data Point API is set to be replaced in future, but the replacement does not currently have an observation API, only a forecast one.
• Accuweather – Free tier limited to 50 calls per day, and referred to as a trial. And you cannot lookup by location, you need to query for a location key…which means if you look it up every time, that’s only 25 calls per day. Didn’t even bother to implement this.
• Weather Channel – only opened its API for a Call for Code challenge period.
• Weather Underground – While Weather Underground shut its API down, it does still offer one for Personal Weather Station contributors. This appeals to me. I still send my weather data to Weather Underground…as well as 5 other places. But I would only be able to search current conditions for Personal Weather Stations.
• AerisWeather – Same as Weather Underground, free access to their APIs and weather reporting stations if you contribute. Might implement this in future.

Anyone have any other weather sources for current conditions?

 

Yesterday, version 4.0.3 of the webmention plugin for WordPress was released. Notably, this includes fixes for two issues.

• The auto approve functionality was not functioning for some time. Props to Jeremy Felt for identifying where the issue was.
• The Avatar code was not identifying scenarios where Semantic Linkbacks turned a webmention into a comment, due to the fact that the comment type for comments is actually an empty string.

As always, thanks to Matthias Pfefferle for being the project author. I do not think he gets enough credit for dealing with all the pull requests I send him, or for the many Indieweb or Indieweb adjacent plugins he has created.

I’ve been working on a patch for WordPress that involves fixing the incorrectly stored timestamp stored as part of WordPress image metadata. I already do something like this in my Simple Location plugin, but I’ve found a way that works more simply.

To summarize the issue, there are multiple datetime properties stored in your photos. The creation time of the file(DateTime), the time the image was created(DateTimeOriginal), and the time it was digitized(DateTimeDigitized. There are two separate properties for the GPS time and date.

The problem being that the GPS time and date, which may not reflect when the picture was taken, but the last GPS lock, is in UTC, but the rest have no defined timezone. With photos taken on a cell phone, if you have GPS time and date, you also have location, which can be used to figure out timezone as well.

Offset fields for the three datetime stamps mentioned were introduced in EXIF version 2.31, which came out in July of 2016. PHP returns these with its exif_read_data function as ‘UndefinedTag:0x9010’, ‘UndefinedTag:0x9011’, ‘UndefinedTag:0x9012’, reflecting DateTime, DateTimeOriginal, and DateTimeDigitized respectively.

I don’t support these, and just learned about them, and intended to support them…until I read EXIF version 2.32, which just came out last year and no one is using yet. They are retiring all of those offset formats they introduced in 2.32 and switching all their date properties to ISO8601. They are also changing GPS Coordinate storage, if you use that.

So any code has to check the EXIF version, and if 0231, check the offset. If 0232, use just the properties, and if less than 0231, try to derive from the GPS location or timestamp.


function exif_gpsdatetime( $datestamp, $timestamp ) {
return new DateTimeImmutable(
$datestamp . ' ' . sprintf( '%02d:%02d:%02d', (int) $timestamp[0], (int) $timestamp[1], (int) $timestamp[2] ),
new DateTimeZone( 'UTC' )
);
}
function derive_exif_timezone( $datetime, $gmtdatetime ) {
$seconds = $datetime->getTimestamp() - $gmtdatetime->getTimestamp();
return new DateTimeZone( timezone_name_from_abbr( '', $seconds, 0 ) );
}


Here are the two functions that I’m using to calculate timezone offset without using geo coordinates. You can also use a timezone lookup database for the location, but this adds another dependency.

If you want to go solely using built-in PHP functions, you can get the datetime stamp(whichever of the properties you are using), set to assume it is UTC, figure out the difference between the two times, and use that to calculate a timezone, which you apply to the original.

WordPress takes the digitized property and converts it to a timestamp using strotime, which is usually an inaccurate timestamp and therefore useless. I am trying to get this fixed.

The issue of finding feeds to subscribe is a challenge that I have explored in my attempts to implement code in support of the Yarns Microsub Server. I want to publish feeds in a way that others can find them, not just users, but automated systems that present them to users.

So, let’s start with the homepage. Given someone’s homepage, they may link to one or more additional feeds that contain content other than what is visible on the page.

To explore this, I’m looking at link types represented by rel values. This exploration is partly for my own notes, and partly for comment.

Rel-Home

Let’s start with rel-home. By adding rel=”home” to a hyperlink, a page indicates that the destination of that hyperlink is the homepage of the site in which the current page appears.  Rel-home should be used with rel-alternate to link from a permalink page to the feed for the site.

Rel-values combine, and they also combine with other attributes. So rel=”home alternate” would not mean something is both home and an alternate, it would mean it is to link from a permalink page to the feed for the site (home page).

Rel-Alternate

Rel-alternate does by itself mean that the destination is some alternate representation or version of the current page, however it combines in special ways with other rel values and other attributes to provide different more specific meanings.

When used in combination with the type attribute (with a value other than that of the document itself; e.g. other than “text/html”), rel=”alternate” means a link to a representation of the contents of the current document in a different format, as designated by the type attribute.

Rel-Feed

According to the Microformats wiki, rel-feed is for publishing and discovering a feed of the current page.  This is somewhat confusing, because many feeds currently use rel-alternate and type for this.

The entry cites a 2006 blog entry, which notes that the rel-alternate usage must be maintained due adoption, but indicates the fact the feeds are not always alternative representations of a page.

Rel-feed, in this entry, is suggested as an explicit statement something is a feed.

If combinations create additional meaning, feed could also be combined with alternate and home to create the meanings to indicate different relationship.

POSSE Post Discovery

The original rel-feed proposal was only supported on <link> elements, and not on <a> elements. There was no literature forbidding it, so in 2014, Bridgy began to search for the property on both elements.

This all encapsulated in the POSSE Post Discovery algorithm.  It notes that rel-feed on an element of type text/html would be considered an h-feed and if not found, consider the page to be their unfiltered feed.

Feed Discovery

The IndieWeb Wiki discusses a proposed way to determine a primary feed.

• Namely, if you cannot subscribe to a URL, as it itself is not a feed, does it advertise a rel-feed?
• If not, does the main object of the page contain a feed nested inside it?
• Are there multiple feeds on the page, or multiple rel-feeds?
• Identify which of the feeds has a url property set to that of the page and declare that the primary.
• If there are multiple feeds on the page, and the URL has no fragment identifier in it, then there is no clear canonical version.

I’d like to modify that idea as follows. This is just a rough work in progress.

• Is this a feed?
  • Yes – This is the primary feed for the URL.
    • Is there a link on this page to itself with the property rel-home
      • If yes, then this is the primary feed for the site.
      • If no, it is merely the feed for that URL of the site.
    • Are there additonal rel-feed entries on the page that point to different URLs? If so,
    • To determine the primary feed for the site, the main site page should be linked with rel-home.
  • No
    • Does it have a rel-alternate on the page? This would indicate an alternative representation of the page.
    • Does the rel-alternate have a type of application/rss+xml, application/atom+xml, or application/json+feed? Alternatively, if there is application/json, you can probably assume a jsonfeed.
    • Does it have a rel-alternate home on the page? This would indicate the main feed of the site
    • Does it have a rel-feed on the page? This would indicate links to alternative feeds. For example, a feed for a category or date archive of which this page was a part.
  • Are there multiple feeds on the page?
    • If so, assume the first is the primary

Conclusions and Musings

Researching this brings me to several questions and conclusions.

1. Who is actually checking for multiple rel values on the same property and deriving different meanings for them?
2. I should publish the home rel and consume it in regard to feeds
3.  Would a link with a rel=”feed tag” indicate a tag archive? According to the rel-tag draft, the last path element of the URL indicates the actual tag, not the text.
4. Would a link with a rel=”feed” and a datetime property indicate a date archive?
5. Would a link with a rel=”feed author” indicate an author archive?

Speaking as someone who continues to try to improve feed discovery, being able to, from a page, identify tag feeds, home feeds, date feeds, and author feeds would address the recently noted desire of Chris Aldrich to have these links.

The difference being, instead of them being side files, such as RSS or JSONFeed, they would be links to marked up h-feeds, and human readable as such. I already have links to tag and date archives, and the title of the link is clear on what those items are.

But when a feed reader tries to do discovery on the page, should it find the primary feed, and any feeds a post is a part of and offer those?

Example in plaintext.

• View All Posts by John Doe
• View All Posts tagged with ‘indiewebcamp’
• View All Posts made on November 12.

 

Still thinking about this, but welcome feedback.

I attended an event that I heard about while attending Friday night services at Chabad here in Sofia, in commemoration of the 75th anniversary of the liberation of Auschwitz.

In my walking tours of Sofia, the tour guides touched on the history of Bulgarian Jews during World War 2. At the event, one survivor spoke…the individual translating for me did not cover everything, but the same individual spoke the day before, and it was covered here.

If I got the gist correctly, he said that the idea that all Bulgarian Jews were saved was not true, there were victims. Either way, it’s complicated.

The documentary featured a survivor returning with school age children to tell them about what she experienced at Auschwitz and was very powerful.

As someone who has been to a fair number of Holocaust remembrance events, this was very meaningful to me, especially that I could be a part of it even though I was far from home, even though I did not understand everything that was said.

 

When I joined the Indieweb community in 2014, the first work I did was thinking about how to improve displaying webmentions. The specification was being developed and there were a lot of ideas floating around.

The specification for Webmentions became a W3C recommendation three years ago, on January 12, 2017. The whole idea of a webmention, like its predecessors, is it is a way for one site to notify another that it is linking to it.

The receiving site gets to decide what to do with the notification…display it, store it, use it for stats…etc.

Now, in recent times, with additional Indieweb protocols being developed, webmentions are not getting the attention they once did in discussions. That is the sign of maturity.  But there are still areas to explore.

On the development front, I have been slowly submitting improvements to  the webmention plugin in WordPress. The webmention functionality in WordPress is bifurcated into two plugins, Semantic Linkbacks and Webmentions. They are being merged, piece by piece, each piece being improved and redesigned as it is merged.

The webmentions plugin now has the MF2 Parser, which it hasn’t since its early days. In future iterations, it will be hooked up and start parsing microformats, gradually moving this away from Semantic Linkbacks.

Released some minor bugfix editions today.

Simple Location

• • Rounds all numbers to a maximum of two decimal points, as I introduced a bug in the last version that would fail to fill in numbers in the post editor due form validation requirements.
  • Extracts additional location information from Compass…mostly the information I store when I’m on a plane, to generate a better description of the location. It also passes this info to WordPress more effectively so it could do more in future.
  • I also introduced a new location provider. If set, if you enter a 3 letter airport code in the location name box, it will replace it with the location and name of that airport, as well as the weather. In future, I may add a similar reverse address lookup for people.
  • Misc bug fixes

Syndication Links

• • Some bug fixes introduced in 4.2.0
  • Due to the request to allow syndication provider checkboxes to be checked by default, I introduced two new filters: syndication_link_checked and syndication_link_disabled. The first parameter of each is a boolean that if true, will set either checked or disabled on that Syndication Provider. The second and third parameter is the uid of the provider and the post_id of the post.

I have been very reluctant to add an auto-post feature that just syndicated everything. I wanted some more granularity around this feature. But I’m not ready to implement it at this time. So, as a compromise, I’ve added a filter if someone does not want to wait for me.

This coming weekend I will be attending IndieWebCamp SF. I enjoy attending IndieWebCamps for my time off from my day job.

I am once again co-organizing and once again volunteering to handle the  video for the intros, sessions and demos. This means I will be bringing the equipment to record the sessions, which will be ultimately available online. You can watch our last event, in Berlin Germany, here. The intros, demos, and keynote are not yet up, but I’ve added most of the sessions. You can see examples of those at the prior event in Brighton UK, available here.

IndieWebCamps are a great place to talk about creating or updating your own website and the technologies or ideas around it. The first day involves sessions, the topics for which are chosen by the attendees. The second day is when you build and demo something you built the previous day.

It is a fun event at a minimal cost. If you are in the area, why not stop by?