Almost Realtime Live Data Visualization in QGIS – Air Traffic Use Case
geodose.com
geodose.com
It's fun to visualize these patterns, but the business case soon ran out. People don't really care about absolute numbers. Diff is what matters the most.
Most of the analysis is "OK, how does this value compare with one week ago". Can't really do that in QGIS/ArcGIS... no matter how pretty the visualization.
In the end, time series always emerges victorious in capturing the right information/visualization ratio.
As an example of another approach that doesn’t need the intermediate csv file and has a much cleaner “refresh”, I made an adapter plugin that accesses real-time robot data via ROS: https://github.com/locusrobotics/qgis_ros
The ability to extend QGIS because of the C++ and Python APIs is immensely powerful.
It's a bit bewildering that there hasn't been any traction for the robotics community to use more GIS. It's a match made in heaven.
There's examples in the presentation linked in the git repo if you're interested.
Can it send commands back to the app from which it's receiving position data? Things like pause/play and adjusting the time being displayed?
QGIS is kind of the go-to app if you want to do serious geospatial data analysis. As for _visualization_, I'm not sure. There's probably better options for many domains. For ROS there's RVIZ, but the ROS community's spatial analytical tools are fairly immature.
If you could however do some number crunching using historical data to display things like average air traffic density and routes, it might become useful.
This article makes it clear that I've only scratched the surface of what you can do with it.
* Vector layers are fast but you cannot easily query attributes for a shape within the esri web apps.
* Feature layers are dead slow for large datasets.
* The API sometimes relies on you submitting form encoded JSON documents which may or may not actually do what you want on the backend.
* API error message are not always descriptive.
* The API documentation is not great. For example try finding the correct string formatting for a date.
And the ecosystem has value all on its own. No single product is the best. But taken together it is the least bad option. Particularly when you want the same team to be able to construct lots of fairly dis-similar pieces of technology.