I built public data radars to see what is actually changing
I wanted to turn scattered data into something you can understand at a glance There is no shortage of data on the web. The harder part is often figuring out what that data actually means right now. Energy production
I wanted to turn scattered data into something you can understand at a glance
There is no shortage of data on the web.
The harder part is often figuring out what that data actually means right now.
Energy production can be found in one place, gas storage levels in another, fuel availability somewhere else, and cybersecurity indicators across several different sources.
The information exists.
But accessing information and understanding a situation are two different things.
So I started building a small collection of public data radars for Palks Studio.
The idea is simple:
take useful data, remove as much noise as possible, and make changes visible at a glance.
No account.
No complex dashboard.
No giant analytics interface.
Just a few indicators, their recent history, and enough context to understand what you are looking at.
Three radars, three very different subjects
The collection currently covers three areas:
- energy
- fuel availability
- cybersecurity
They use different data and measure different things, but they share the same philosophy.
Each radar tries to answer a very simple question:
What is happening now, and how does it compare with the recent past?
That second part matters.
A number on its own is rarely enough.
If an indicator says 72%, for example, the interesting question isn't only whether 72% is high or low.
It is also:
Where was it yesterday?
Where was it a month ago?
Is it stable?
Is it moving quickly?
Is what we're seeing unusual?
This is why I wanted the tools to combine current indicators with historical views rather than simply display the latest value.
Energy Radar
Energy is probably the clearest example of why this approach can be useful.
There are many individual indicators available, but understanding the broader situation often means looking at several of them together.
The Energy Radar brings together indicators around electricity, gas consumption, gas storage, and the electricity generation mix.
Instead of reducing the situation to a single number, it exposes several parts of the system.
You can see the current indicators, follow their recent evolution, and look at how electricity generation is distributed between sources such as nuclear, hydro, wind, solar, gas, bioenergy, fuel oil, and coal.
The objective isn't to predict what will happen next.
It is simply to make the current situation easier to inspect.
Fuel Radar
Fuel availability creates a different problem.
A national average can look perfectly normal while local difficulties are appearing elsewhere.
The Fuel Radar is therefore designed around availability indicators and their evolution over time.
It provides a compact view of the current situation and makes it easier to distinguish between an isolated number and an actual movement in the data.
Again, the important part isn't adding more information.
It's reducing the effort required to read it.
Cyber Radar
Cybersecurity is different again.
There is a constant stream of vulnerabilities, alerts, incidents, and technical information.
For most people, simply adding another feed of cybersecurity news wouldn't solve much.
So the Cyber Radar follows the same principle as the other tools: extract a limited number of useful indicators and present them in a consistent interface.
The result is not intended to replace security monitoring tools or professional threat intelligence platforms.
It is a public radar designed to provide a quick view of the current situation and its evolution.
I deliberately kept the interface small
One thing I wanted to avoid was accidentally building another giant dashboard.
It is tempting when working with data.
Once you have the information, you can keep adding filters, cards, charts, tables, options, and settings.
But every additional component also increases the amount of work required from the person looking at the page.
So the radars share a deliberately constrained interface.
A few primary indicators.
A few secondary indicators when they are useful.
Recent history.
Simple period controls.
Tooltips for details.
A short methodology explaining what is being measured.
That's essentially it.
The charts themselves are rendered directly as SVG rather than relying on a large charting library.
For these tools, I didn't need an entire visualization framework.
I needed lines, points, labels, hover zones, and tooltips.
Native SVG was enough.
The interesting part is not the dashboard
Building the visible interface is only one part of the work.
Behind it, the data still has to be collected, normalized, stored, checked, and transformed into something the interface can use.
Different sources don't necessarily update at the same frequency.
They don't necessarily expose data in the same format.
Historical series can become unnecessarily heavy if every raw measurement is displayed.
Missing data also needs to be handled without turning the page into an error screen.
That means the actual pipeline looks more like:
source → collection → validation → normalization → storage → aggregation → visualization
The radar is simply the last layer.
And in many ways, that's the part users should have to think about the least.
A small analytics system behind the tools
I also wanted to know whether these resources were actually being used without turning the project into another third-party analytics integration.
So I built a small internal tracking system for the tools.
Each radar records a minimal visit log.
A collector processes those logs, filters known bots, calculates human page views and unique visitors, and stores daily statistics in SQLite.
A private dashboard then gives me a consolidated view across the different public tools.
Nothing particularly exotic.
But it follows the same philosophy as the radars themselves:
collect what is useful, process it, and present only what helps answer the question.
Why build these as public tools?
Because sometimes a small tool is more useful than another article.
An article can explain an energy situation at a particular moment.
A radar can still be there tomorrow.
And the next day.
The data changes while the interface remains the same.
That makes these projects somewhere between a web application, a data pipeline, and a publication.
They aren't static content, but they aren't large applications either.
They're small systems built around one job:
making a changing situation easier to read.
Explore the radars
All three radars are publicly available and can be used without an account:
I'll keep developing the collection as I find other datasets where a small, focused interface can make the information more useful.
Because sometimes the problem isn't that we don't have enough data.
It's that we still have to turn it into something people can actually read.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.