Tag Archives: river

Posted on
by

For me, getting to many of the activities I enjoy, involves crossing a river.

Normally, this is about 35-40 minutes on bike, but if the crossing is flooded, I have to take a ~20 minute detour. What’s more, it’s dark, and this often involves me suddenly getting very wet feet.

Thankfully, it’s the 21st century, and I can do something about this!

Flood sensors

The UK Environment Agency, thanks in a large part to the wonderful work being done by the Data.gov.uk, has made the data for their network of flood sensors available on the internet.

I can tell, by visiting a webpage, more or less whether I need to take the short or long way round.

This wasn’t enough for me, because I’m lazy, and I want to be able to either ask the question “Is sandford flooded?” in a console window, or have my computer send me an alert if I need to allow extra time to get in. Unfortunately, there’s no feed of this data immediately available, but this was nothing a bit of Script-Fu wasn’t able to sort out!

The first step was getting the current levels. Looking at the markup, you can see that the current level is a nice two digit number between two <strong> tags, so this was pretty easy to regex for.

The second was to get a value for what the environment agency considers “flooding” for this sensor. This was a little bit more tricky, but it’s marked on the graph, and it would seem that the source for this is a JSON blob in the html, so again, relatively straightforward.

Putting this together, I was able to build a nice little script that, when given a sensor’s webpage, compares these two values and gives you a simple yes or no as to whether it’s flooded. For bonus points, and because the surrounding low areas may flood before the sensor does, I took a 90% value for a given sensor and use it to return an “Almost” if reached… kindof a “proceed with caution”.

This was pretty much to scratch my own itch, but since the flood sensor network is nation-wide, I figured it might be useful to someone else out there!

» Visit the project on Github...

Posted on
by

It has been a busy few weeks. Those of you who have been following the cut and thrust of development and tracking SVN will have noticed a fair few extra features and functionality and a lot of core code changes – extra tools, new activity viewing code, many speed improvements, a central entity icon API, bug fixes etc.

A lot of people have been picking up the code and contributing. The Community site we launched earlier this month seems to have been a big hit with people and we are seeing some really quite useful stuff fall out of the mix.

As we approach the release of Elgg 1.1 I thought it would be a good time to talk a little bit about what I call “doing things the Elgg way”.

Elgg is built to be modular and pluggable, so this means always thinking about how you can let others safely hook in and extend the way your code works.

We make extensive use of the events system, so for example when an entity is created or updated it triggers an event. Other bits of code can chose to listen to this event and do something.

This is for example how logging works.

The Elgg system log simply listens to events in the system, and when an event is triggered on an object which can be logged it writes the appropriate entry in the system log.

This can be then further processed by the River or Activity viewer, which brings us rather nicely into the subject of views (which we have talked a bit about before).

The activity stream and the river both work off the system log and use the views system. What happens is that when either of these is displayed the code looks to see if it has a view to render a given item in the log, and if so it renders the event.

This is very flexible, since it means that any plugin can come along and add and extend the river or activity stream – adding custom views for its own entities or extending other entities – all of which without touching a single line of core code.

This is a pretty big win, and this is part of what it means to develop the Elgg way.

Posted on
by

The lesson this week has got to be “Profiling is a Good Thing”. While working on the new Elgg community site this week, it quickly became clear that the way the River code was written was horribly inefficient.

So, I had to optimise it.

Unfortunately this necessitated a schema change to the system log (a good test for the Elgg update scripts). It also required some changes to the way the river views are constructed.

The details of these changes are documented over here. Turns out to be a bit of a blessing in disguise; letting us speed up the river while at the same time increasing the number of events a plugin can hook into as well as standardising the views hierarchy.

The down side is that after the upgrade site rivers will appear to be blank – this is because while the system log is still there, the format of the log and the way the river code hooks into it has changed.

The change also means that plugins which hook into the river will also need to modify their views hierarchy slightly.