Last time around I mentioned the plasmoids I finally decided to write to show information from the Australian Bureau of Meteorology, or BOM as it's lovingly known in some circles. I have put in place a few more touches to make it useful and have been experimenting with it since the last post. Shown below is the updated radar view which uses a custom background image and a modified locations overlay. The sat images are from Google Maps.
This gave me the idea that this particular plasmoid should be "Environmental" instead of just weather. If there is a crash on the north bound road that you use, seeing a little red dot there would be great. Having it pulse when you animate the radar would also be good so you have a much greater chance of seeing it. Likewise, for bus and train services, seeing which lines of interest are inactive due to track work or where delays are. It is more about showing things that are of interest today than just the weather.
I'm thinking that using Marble and Nepomuk (RDF) here would be the way to go. Telling marble that the doppler radar images are for dlong/dlat and extend to dlong/dlat should be OK for overlaying them. Nepomuk would be the way to go for harvesting the other information, like the delays or traffic reports and if they are properly geotagged, perhaps geo84, then a sparql should be able to bring them to the map. Of course, a timeline slider would then live on the top so you can see things that might have happened but been already resolved.
My mind's eye could see the benefit to the gust / average wind speed vs time plot plasmoid, but now that I have had it running for a while I can also show folks that I wanted... as you can see, looking at the plasmoid on the right, the red is the average wind speed and the blue extends to the gust speed. It becomes obvious not only if it is breezy, but if there is a large amount of variability in the wind. This metric is very important to some activities that are sensitive to wind. For weather geeks, the drop in wind should also show in the temp graph on the left because the apparent temp will alter as well. Though at 16C with winds < 10km/h it is to small to really see. BTW I know that the times are wrong in the title, there is an erroneous UTC offset happening to that epoch somewhere along the lines it seems.
I am not fully happy with the Forecast view. The icons and max temps for today and tomorrow are shown on the left and the detailed text on the right. It is very hard to show the detailed BOM text graphically, as things like "Chance of a late storm" require strange combinations of the "Fine" and "Storm" icons from the KDE set, and that doesn't take into account the "chance of" part in the text forecast.
These will likely be shoved into KDE's svn as aaron suggested. If anyone feels strongly _against_ that choice then please ping me, otherwise I'll assume sunshine and lolly pops.
C++, Linux, libferris and embedded development. Yet another blog from yet another NARG.
Tuesday, April 27, 2010
Monday, April 26, 2010
Plasma: It's an abomination I tell's ya...
Now that I have your attention and defences up, abomination is the name of my new plasmoids for showing the Australian Bureau of Meteorology (ABOM) National weather info, thus it is an ABOMiNation. Yes, my humour is offered for free, though you die a little with each joke.
Things are split up into Perl scripts, data engines, and plasmoids. Its still version 0.0.1 so expect a reading of the README and a bit of tinkering to get going.
One of the nice things is that the radar image loop can be offered on the desktop with just the latest doppler radar overlay. As the background, topographic and locations are all separate PNGs you can easily get a custom look and feel or theme for your version too.
Observations are downloaded for your nominated cities. The observations plasmoid can show the ambient and apparent temperature, wind average and gust speeds, and rainfall on a rolling graph. These screenshots were taken with a sample time of 1 second and a random multiplier to test, in reality you should see nicer bell like curves for temps and less sporadic curves for wind. Seeing the gust as a cumulative on the same graph is handy for motorbike riders so you can see how "choppy" things are at a glance. Especially if you have observations for other places that you are heading towards which might be 100-200km away from your abode. For temps as shown below the -1 as the offset to apparent temp from ambient temp. The time is always when the latest observation was taken.
As you see below, the blue area is the gust speed above the average. So a variable wind will show up graphically. The direction is shown in the title along with the average and gust relative to avg speeds. I particularly hate the weather applets that show the direction as an arrow, and wind speed as a smaller number. Chewing up screen for something I don't care about and not showing detailed wind observations.
As this was my first foray into KDE applets, I found the many tutorials on DataEngine and Applets to be a good start, but there are still times when you have to RTFS and grep the subversion to work out how to do things. I still have another plasmoid to write but a release will happen very soon. I infact tried kde-apps.org today but its interface is annoying so I'll likely shove it up on sf.net in the next few days.
Things are split up into Perl scripts, data engines, and plasmoids. Its still version 0.0.1 so expect a reading of the README and a bit of tinkering to get going.
One of the nice things is that the radar image loop can be offered on the desktop with just the latest doppler radar overlay. As the background, topographic and locations are all separate PNGs you can easily get a custom look and feel or theme for your version too.
Observations are downloaded for your nominated cities. The observations plasmoid can show the ambient and apparent temperature, wind average and gust speeds, and rainfall on a rolling graph. These screenshots were taken with a sample time of 1 second and a random multiplier to test, in reality you should see nicer bell like curves for temps and less sporadic curves for wind. Seeing the gust as a cumulative on the same graph is handy for motorbike riders so you can see how "choppy" things are at a glance. Especially if you have observations for other places that you are heading towards which might be 100-200km away from your abode. For temps as shown below the -1 as the offset to apparent temp from ambient temp. The time is always when the latest observation was taken.
As you see below, the blue area is the gust speed above the average. So a variable wind will show up graphically. The direction is shown in the title along with the average and gust relative to avg speeds. I particularly hate the weather applets that show the direction as an arrow, and wind speed as a smaller number. Chewing up screen for something I don't care about and not showing detailed wind observations.
As this was my first foray into KDE applets, I found the many tutorials on DataEngine and Applets to be a good start, but there are still times when you have to RTFS and grep the subversion to work out how to do things. I still have another plasmoid to write but a release will happen very soon. I infact tried kde-apps.org today but its interface is annoying so I'll likely shove it up on sf.net in the next few days.
Labels:
bom,
kde,
meteorology,
nature-sire,
plasmoid,
weather
Friday, April 23, 2010
Looking for some coding work...
If you are on the lookout for a C++, GTK+2, Qt, Linux developer with a PhD and experience in persistent storage and indexing then I'm looking for you!
For those who don't know me, I am "the libferris guy". Which means I have played with virtual filesystems for many many years and implemented a good handful of ways to index and search diverse filesystems. Some of the articles I did for Linux Journal and linux.com will give an impression of the sorts of things libferris can do, and in the next months the Linux Format includes information on Web services as a filesystem, eg, mounting flickr, youtube, and facebook.
After hacking RDF support into KOffice earlier this year, I would very much like to work more with Soprano and RDF technologies. But anything involving indexing and storage is also of huge interest. In fact one of the things I like about RDF at the low level is that it overlaps these desires too, for example, my custom model partial implementation for Soprano which is targeted at great performance on embedded devices.
I have implemented some GIST trees for PostgreSQL and worked with C++ and development on a Linux platform for over 10 years. If you are interested in these things or just want a Qt hacker for a while then please drop me a line using the nick for this blog at gmail or sourceforge as email address.
For those who don't know me, I am "the libferris guy". Which means I have played with virtual filesystems for many many years and implemented a good handful of ways to index and search diverse filesystems. Some of the articles I did for Linux Journal and linux.com will give an impression of the sorts of things libferris can do, and in the next months the Linux Format includes information on Web services as a filesystem, eg, mounting flickr, youtube, and facebook.
After hacking RDF support into KOffice earlier this year, I would very much like to work more with Soprano and RDF technologies. But anything involving indexing and storage is also of huge interest. In fact one of the things I like about RDF at the low level is that it overlaps these desires too, for example, my custom model partial implementation for Soprano which is targeted at great performance on embedded devices.
I have implemented some GIST trees for PostgreSQL and worked with C++ and development on a Linux platform for over 10 years. If you are interested in these things or just want a Qt hacker for a while then please drop me a line using the nick for this blog at gmail or sourceforge as email address.
Thursday, April 8, 2010
Nepomuk & Social Networking: The Golden Opportunity
After reading an article on Boxee recently which described it's social network integration it occurred to me how wonderful this would be to have for KDE. Having tags and ratings on the desktop is a really nice thing, but having tags and ratings coming through for arbitrary pieces of information from your "friends" makes things quite interesting.
From the Boxee example, why can't I see that Fred has also scheduled to watch Program-X. At the moment such recommendations are handled by many folks through IM or email, which is quite kludgey to say the least. There is no simple click to record or accept a recommendation, you have to mentally context switch to the TV schedule and update.
One thing that makes this all come together is not thinking of tags or ratings as binary or a single 1-5 range. To quote my own code, if a tag is able to also record the thoughts of many actors as a range, say a double from 0-100, and each actor has a level of trust associated, then the system itself can infer that if Fred is watching something and it is rated SciFi then automatically I want to take a peek too. By allowing tags and ratings to capture more complexity behind the scenes, the computer can infer more for us, and part of that can be a traditional 1-5 rating or whatever... hey, I work on virtual filesystems, is it really that strange that I would want to virtualize file ratings too?
The big gain here is if KDE itself can provide the spine for this. In my own system I stopped short of being able to automatically distribute these tag and file ratings. Surely they can be sent to other libferris systems and integrated, but that process, and the one of tracking friends and assigning privileges to them is not 100%.
Combining RDF with the social network element is an interesting chance here IMHO. Perhaps a central server of sorts is only really needed for tracking the privileges and assigning friends, and a p2p protocol can then be used to actually transmit the RDF you have decided to share to your associates. Though a fully central server implementation would probably provide a quicker starting point. As an upside, this would allow syncing RDF between many of your own devices -- tags from the desktop appearing on mobile devices when the VPN is up.
Of course, information sharing would have to be explicitly condoned by the user, and public key crypto would be needed to ensure integrity, privacy, and authenticity etc.
This sort of thing extends nicely to audio and image apps like Amarok and KPA. If I give somebody a copy of some images I took of London, when I add tags, they should also trickle through the system to them. If they are looking at a photo of the Wigmore Hall I took, they might like to know more about that place, and perhaps which CDs I have of chamber music from that trip.
This is something I'd love to hack on when I get the chance. In the meantime I thought I'd drop the idea here in case there are other folks who are also interested and we can combine forces.
From the Boxee example, why can't I see that Fred has also scheduled to watch Program-X. At the moment such recommendations are handled by many folks through IM or email, which is quite kludgey to say the least. There is no simple click to record or accept a recommendation, you have to mentally context switch to the TV schedule and update.
One thing that makes this all come together is not thinking of tags or ratings as binary or a single 1-5 range. To quote my own code, if a tag is able to also record the thoughts of many actors as a range, say a double from 0-100, and each actor has a level of trust associated, then the system itself can infer that if Fred is watching something and it is rated SciFi then automatically I want to take a peek too. By allowing tags and ratings to capture more complexity behind the scenes, the computer can infer more for us, and part of that can be a traditional 1-5 rating or whatever... hey, I work on virtual filesystems, is it really that strange that I would want to virtualize file ratings too?
The big gain here is if KDE itself can provide the spine for this. In my own system I stopped short of being able to automatically distribute these tag and file ratings. Surely they can be sent to other libferris systems and integrated, but that process, and the one of tracking friends and assigning privileges to them is not 100%.
Combining RDF with the social network element is an interesting chance here IMHO. Perhaps a central server of sorts is only really needed for tracking the privileges and assigning friends, and a p2p protocol can then be used to actually transmit the RDF you have decided to share to your associates. Though a fully central server implementation would probably provide a quicker starting point. As an upside, this would allow syncing RDF between many of your own devices -- tags from the desktop appearing on mobile devices when the VPN is up.
Of course, information sharing would have to be explicitly condoned by the user, and public key crypto would be needed to ensure integrity, privacy, and authenticity etc.
This sort of thing extends nicely to audio and image apps like Amarok and KPA. If I give somebody a copy of some images I took of London, when I add tags, they should also trickle through the system to them. If they are looking at a photo of the Wigmore Hall I took, they might like to know more about that place, and perhaps which CDs I have of chamber music from that trip.
This is something I'd love to hack on when I get the chance. In the meantime I thought I'd drop the idea here in case there are other folks who are also interested and we can combine forces.
Subscribe to:
Posts (Atom)