Thinking About Weather

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?

 

RSVPed Attending WordPress IndieWeb Online Meetup

Interested in the Indieweb, but you already have a WordPress site? Do you have a WordPress website or thinking of starting one?
Whether you’re a blogger, coder, designer, or just someone who wants to improve their presence on the web, if you have a WordPress site and want to add Indieweb functiona…

During tonight’s online Indieweb NYC Meetup, I asked the question: If in 100 years, all historians had to learn about you was what was on your website…would that be enough?
RSVPed Might be attending ONLINE: Homebrew Website Club San Diego

Now Online Only
Out of an abundance of caution regarding COVID-19 (coronavirus), we have decided to switch the March 18th meetup to an online-only meetup.
We will provide a Zoom video conference link 20 minutes before the meetup here and in the IndieWeb chat.
Homebrew Website Club is a meetup for an…

I’m attending the one on NYC time earlier. Will try for this one too.
RSVPed Attending Online: IndieWeb Meetup NYC

Join us… on ✨The Internet!✨
Join us for an evening of IndieWeb personal site demos and discussions! Any questions? Ask in the chatroom! Your hosts will be Marty McGuire and Jason McIntosh (who are schmarty and jmac in the chat room, respectively).
Normally our meetups happen at a venue in New …

I just pushed the first set of improvements to Parse This to support JSON-LD.  Parse This takes an incoming URL and converts  it to mf2 or jf2. It is used by Post Kinds and by Yarns Microsub  to handle this.

So, assuming the default arguments are set, the parser will, for a URL that is not a feed, look for microformats. If microformats lack a summary, content, or references(for jf2) property, it will try to parse JSON-LD. If this produces no results, it will try OGP and Meta Tags.

Even though I’m not fond of Schema.org or JSON-LD, more sites have rich data in  this format than Microformats and I want to be able to find author names and other properties  to display proper attribution and rich link previews for my replies, bookmarks, etc.

This will be available from the Github Repo for Parse This immediately, and will likely be available in the next refreshed release of any plugin using the library. JSON-LD will not be of much use to Yarns, as it does not parse single pages, only feeds at this time.

The Truth about the Post Kinds Plugin

WordPress has the concept of post types, which are custom content types. The post type, which is the default type in WordPress, is a post of type post. Custom post types are also used to store attachments, menus, revisions, etc…all sorts of things that aren’t traditional posts.

Post Kinds as implemented in the Post Kinds Plugin are not a post type. They are actually a taxonomy…or a tag. This tag tells the system to use a particular template to render the post, and allows for auto-generation of things like feeds and archives. This is based on the Post Formats system built into WordPress.

This means that if you turn off the plugin, all the custom rendering is gone and you get a standard post with all the extra information missing.

However, in the Gutenberg age, attributes are stored in the content field, and parsed out into blocks. In theory, a microformats parser actually could be inserted to parse out the microformats as well into blocks instead of or in addition to their own html comment based markup.

But, this means that some of the data structures of Post Kinds are being rethought.

I mentioned previously I am adding a citation post type…as in, a WordPress custom post type. This means there will be a tab in the sidebar in the WordPress admin for creating just these links. If you want to share them in list form, post them as a reply, etc.

If the post post type reflects an h-entry, I am simply storing the nested type, h-cite(citation), separately. But from the user perspective, it should allow for improvements in the classic UI, a new implementation in the block editor, or a completely new UI that just handles some of the Indieweb types.

So, create a citation, tag it with the Indieweb post kind, and it will render appropriately….similar to how it is done now.

Replied to Identifying Post Kinds in WordPress RSS Feeds (danq.me)

I use the Post Kinds plugin to streamline the management of the different types of posts I make on my blog, based on the IndieWeb post types list: articles, like this one, are “conventional” blog posts, but I also publish notes (which are analogous to “tweets”), reposts (“shares” of thin…

I like the idea of adding the kind of post to the RSS feed to identify it, although not everyone will. I’ve opened an issue to remind myself to explore a version of it in future. Working on a major change to the plugin now.

Planning out the Next Generation of Post Kinds

I’ve been working on the Post Kinds plugin for several years now. It allows the enhancement of WordPress posts into the Indieweb types of posts.

But in the current environment, the question I keep getting asked is: When will it support Gutenberg, the WordPress block editor?

This is something of a problem for me as I do not know how this would work. I really need to talk it out with someone more embedded in the Gutenberg world and see what ideas come.

So, to prepare for that, I need to make a major shift in the way I have Post Kinds set up to disconnect further what happens on the frontend to what happens on the backend. And since Gutenberg uses the REST API to get data, I need to add an endpoint to work with this.

So, there are a few experiments in this regard I am working on. In a previous version of Post Kinds, I switched from storing metadata about a photo in the photo post to storing it in the attachment. WordPress uses a custom post type for attachments to store information about video, audio, images, etc.

This means you can edit the attachment, and separately attach it to the post. So, one of the first things I want to do is enhance that, and add the ‘citation’ post type I’ve been contemplating.

Loosely inspired by the old WordPress links manager, this would store the metadata for individual URLs. It would be necessary as I want to be able to turn my website into a Pinboard-esque bookmark archive. Not every bookmark is to be shared in my feed, or even public.

So, ones that are shared would be attached to a post, similar to the way attachments are. But otherwise could be addressed as simply bookmarks.

Over the last week, I experimented heavily with a simple fields API to generate the forms fields by configuring an array. The idea here is to define the fields I need for any given post kind, and therefore generate them automatically, rather thanm writing templates.

So, both of these ideas are elements of what I want to build. The challenge is the UI to bring these pieces together. It is going to require some trial and error on my part to get it right.

Right now, after having merged in the Fields file, which I will eventually hook up to the form interfaces, I will be finishing the Citation Edit UI, and then seeing how I can link that to posts, taking the attachment model.

Then working on how to properly save and edit the combined post.

Thoughts?