LiveOpenRiverCam: Open-Source, Web-Based Climate Service for River Monitoring with Cameras

Author: Hessel Winsemius

River discharge can be monitored with cameras through computer vision methods such as Particle Image Velocimetry. With existing software packages, you can load a video, perspective information, a cross-section, some processing choices which then results in an estimate of surface velocity, and discharge. But imagine you can do this in real-time, with results automatically flowing into a web-based administration environment with a powerful API that allows a direct connection with your own data services or forecasting systems such as Delft-FEWS? Perhaps this is also not new. But what if we take this one step further? What if you could set up your own service for your own organization, or even your own clients with a free and open-source software stack. Starting today and thanks to our innovation project TEMBO Africa , this is possible with LiveOpenRiverCam: the first ever entirely free and open-source administration and API front end for real-time video-based monitoring of river flow, with a fully scalable back-end including cloud database and storage options and as many cloud computation nodes or field devices with on-site processing as you may require for your operations and clients.

Velocimetry as a Service

Image and video-based estimation of river flow using cameras has been around for a while now. Several image-based velocity approaches have been developed in science, jointly referred to as “velocimetry” methods. These techniques have now evolved so much that not only interesting software packages have evolved around the techniques such as FUDAA LSPIV, KLT-IV and Hydro-STIV, also services for real-time data collection and sharing have been developed. The business model may be the selling of a hardware solution, which then comes with a use of the web platform included in the price, or selling of a license to use a Live web platform, where you have to organize your site set up and hardware yourself. A recent example of this is Hydro-STIV real-time, developed around the nowadays well-known software Hydro-STIV, which uses Space-Time Image Velocimetry as a backbone.

So what then is LiveORC?

In essence LiveORC is quite comparable to real-time services such as mentioned above, but with one very large difference: the software with all its underlying components is entirely open-source, and very easy to deploy for a starting user. See also our earlier blog on pyOpenRiverCam, the engine behind all this. This opens doors to local users in any country, be it low or high income, to start developing their own service, be it on-premise or in the cloud, or even on your own desktop computer for smaller projects. In summary, once deployed it delivers the following:

• An administration-style front end for managing sites, configuration, videos and time series.
• Visualization of time series and video analyses.
• Fully automated data streaming from operational camera/water level feeds in the field with "edge processing".
• Per-video processing through "cloud processing".
• A very fast and easy start to this all, through convenient virtualization of services and a very easy to use set up script.

And all of the data is entirely geographically referenced which will open doors to future geospatial applications as well. More on that in later developments!

Ease of deployment: start small and gradually expand

We mentioned ease of deployment as one of the essential things. This was one of the choices made in the establishment of the service stack: ensure that any user can very quickly start with the service, even on a local desktop or laptop. which then gives you a local storage, local database and a (or multiple) local compute nodes.

Let’s spend a few more words on the set up script. This seems like a small thing, but in fact it is not! With one single command you can start a interconnected database, file server, back-end front-end and one or more compute nodes on your own laptop or computer. This means that also for smaller projects for one client, it is perfectly feasible to set up LiveORC on your own desktop or laptop.

But the cool thing is, that once you familiarize yourself, you can also set up your own database and S3 file server, for instance on a server computer, or a hosted database and storage from a cloud-provider, and simply connect to that database by adding a few arguments and environment variables in the original command. With a few arguments more, you can directly make the API and front end available on the internet with secure SSL certificate and automated renewal included. Usually this is a complex and messy thing to do with setting up web services and requesting certificates. But the script does this all for you without any intervention. Need more compute nodes than one because your clientele is increasing? Just raise it with additional arguments (and ensure your server is large enough :-)) and you can continue providing and expanding services. This means that you can start small, and gradually expand and increase what you are offering.

Stop reading or…?

If you want to start trying it and are not curious about why we created LiveORC you can stop reading here. Go to https://github.com/localdevices/LiveORC and check how to get a Dockerized service set up on your own laptop or desktop and follow the “Getting started” tutorial. This will give you a good impression of what LiveORC does. Note that while you will upload a video in the administration front end, any video can be pushed via the API and processed in the service, but also can be processed on the site itself using a NodeORC installation on a compute unit on the site. This makes the service scalable to field deployments anywhere, also in places with low connectivity.

So why LiveORC?

Now let’s go a little more into the reasoning behind LiveORC. We already mentioned that similar services already exist. And likely, in terms of functionalities they may at this moment be more advanced. For instance, currently we only offer an administration dashboard, and no fancy interactive tools to configure the perspective of a camera on sight with things like control points (on the wish list, but we need funding also!). Currently, camera configuration must be done offline using a separate PyOpenRiverCam installation and the resulting configuration uploaded into the platform.

But, while these existing services are extremely useful, as they are now reliable, provide a non-contact means of continuous observation of river flow, and have a continuous development team, they are hardly uptaken and successful in low income countries. Upon discussion with users, friends and colleagues, I believe this is likely due to the following reasons:

• License costs are likely quite high. Don’t get me wrong. This is totally fair. Naturally any service, developed and sold to customers will require revenue, in order for it to be continuously developed and maintained, and therefore I consider this a very viable and logical business model. It does however limit the possibility for a local organization in a low income country to buy and/or keep up the service. The price-performance ratio may well be positive in a high income country, where the service provided weighs well against prevented costs from e. g. extensive field work to collect discharge measurements or costs of traditional station equipment that gets lost in a flood. But in a low-income country, these benefits, although they may be similar or even higher in a relative sense, compared to a country’s GDP, are in absolute terms much lower.
• Maintenance issues: with technologically complex and highly specific equipment, lack of knowledge and local capacity to maintain devices in the field may easily result in their failure. Also vandalism is a significant issue for developing sustainable monitoring stations. For instance, the SADC-HYCOS project, which was meant to provide continuous hydrological observations in the Okavango and Zambezi basin, in order to inform flood early warning, already started crumbling after its first year after delivery due to lack of maintenance.
• The sustainable innovation paradox a.k.a. “Eroom” (Moore’s law spelled backwards) effect: although innovations may deliver a promise for sustainable development, downstream uptake, especially in small and public organizations, may easily be hindered by regulatory approval, and more burdens compared to established and larger deliverers of services. The proverbial marble of innovation needs to be pushed up the mountain of regulatory burdens and get through the first period of uptake. That may be a hard proposition, even if the innovation in the end will prove highly cost and personnel effective. I would argue here that this expands to barriers related to initial lack of local knowledge and capacity for uptake of innovations. For instance, a hydrologist at a water agency, may currently collect stage-discharge relationships with a well established, yet highly labor intensive method, but simply does not have room in his/her everyday work to start adopting and maintaining an innovation which in the end may lead to a large saving in time and effort.

Local People, Local Devices, Open Knowledge

What then is the alternative? To be very brief, I strongly believe that environmental services should somehow be delivered as locally as possible. The mantra of the LocalDevices network that I am a proud part of splits this up in three parts: “Local People, Local Devices and Open Knowledge”. This means:

• Local people should deliver the service. In a very direct sense, this will reduce costs because the service sits in the local economy (with local costs of living), but in a much broader sense, it will ensure that the knowledge built up through delivery of services will be sustained locally thus leading to more jobs and a more longer-term engagement with the technology.
• Local devices basically means devices that can be locally sustained. Simple yet apt for the job may prove more effective than complex with lots of bells and whistles. This part is not yet fully solved with LiveORC, but certainly on the radar. My partner Photrack AG for instance, is building a small footprint (in size, weight, and power requirements) camera module called “PtBox”, that can be easily carried around and can be configured to regularly take and process videos.
• Open Knowledge can be delivered by building software platforms entirely Free and Open-Source, well documented, and such that it can be deployed very easily without much prior knowledge of server and cloud systems.

LiveORC fulfills Local People and Open Knowledge.

With LiveORC, local entities can now start building their own web environment to host, maintain and share data from camera systems. Due to the fact it is free and open-source, and its easy of deployment, they can start doing this tomorrow. LiveORC may alleviate the above-mentioned problems of costs (a local entity can price this according to his/her own local living expenses), and maintenance (a local service provider can much quicker and more easily resolve problems with stations in their own country that they themselves maintain).

Does it also alleviate the “Eroom” effect? This remains to be seen and will be much dependent on the specific country of implementation. But the flexibility in possible business models is huge! Currently, Rainbow Sensing, Photrack AG and local entrepreneur Hubert Samboko are investigating if services around LiveORC, and with the aforementioned PtBox solution as a local hardware solution could be delivered by a local entrepreneur instead of a direct user of the data. An entrepreneur can much more flexibly approach a larger customer base and thus make a service profitable and sustainable much faster.

So what about the sustainability of OpenRiverCam?

So am I here barking up the wrong tree and risking that I can’t sustain my own business by giving away free knowledge? I have a lot of faith. My revenue model is different from existing vendors of the technology. Rainbow Sensing intends to keep on doing research on new innovations, expand functionalities of the software based on use cases, and especially train and facilitate users that want to set up their own services through ICT training, fieldwork and business development around the technology. It requires one thing: many users! I strongly hope that the readers of this blog start working with my software to make this happen!

So a little bit of final insight on how we will move from here. Ok here goes:

• Allowing for an interactive camera calibration in the web interface. No more use of PyOpenRiverCam in the back.
• Allowing for making or choosing recipes for your river cases interactively. Also no PyOpenRiverCam fiddling or making .yaml files in text editors necessary anymore.
• Adding Space-Time Image Velocimetry to the mix of methods. Really?? Yes, why not! For uniform river cross sections this is an excellent velocimetry method so we should support it.
• Making a web accessible interface for NodeOpenRiverCam, so that you can configure your device using a simple web interface. No more logging in to a command-line interface!
• ...

Should I continue??

For information, support in using the software, sponsoring us to expand its functionalities, or just specialist projects where you need our knowledge? Please contact the author at [email protected]

Acknowledgements

LiveOpenRiverCam has been created in the TEMBO Africa project. The TEMBO Africa project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101086209.

The opinions expressed in this document reflects only the author's view and in no way reflect the European Commission's opinions. The European Commission is not responsible for any use that may be made of the information it contains.