The holiday season finally freed my hands and let me to report on some new features implemented into both the OGN logbook web and engine. You’ve surely noticed the biggest and most valuable addition already: By following the little 🔍 symbol one can explore a track of a particular flight in detail!
There is one limitation, however. The flight-tracks can be accessed for only up to 24 hours after landing as there is a limitation imposed by the data retention policy. This (probably) prevents the logbook to keep the data any longer as I am not really certain how the handle interpretation of the “data redistribution”. Moreover retention of so much flight data for extended periods of time would quickly take up all the available server’s storage anyway, so it gets all dumped after that timeout automatically. It might be a nice to see our older flights but it could also cause harm when used inappropriately. Could somebody advise?
Second quite useful feature can be discovered when selecting a date in the header. For the date field to appear you need select an airfield or an airplane first.
Originally, this should have been a versatile date-range selection tool but apparently I am not as good web-designer as I needed or hoped to be. The possibility of selecting range of days, i.e. a weekend or an even entire week, had been here for some time now but is still not accessible with no bother from straight the UI. Nonetheless, you still have the opportunity to tweak the URL manually like for example this https://logbook.ibisek.com/loc/LKSU/2021-06-13/2021-06-16. Just be aware the maximum date-span is set to 14 days at most to ease the raspberry’s database load .. at least a bit.
Another big thing on the back-end, especially from the performance point-of-view, was to abandon the python threads in favour to the multiprocessing module. I might have known (but never realised that before) the python GIL (global interpreter lock) does not allow to run the python threads on multiple CPU cores in parallel (as one’s experience from other programming languages would suggest, right?). This was then a significant bottleneck causing long delays in beacons processing, typically when the season was at its peak. The processing capability topped at around 168k beacons/minute while all extra incoming beacons might have been queued for another (up to) 10 hours for being processed. Now the multiprocessing, on the other hand, would prevent us from stepping through the code in a debugger. For that reason, both of threads and multiprocessing are now used in the codebase depending on the mode of execution. You can get more of the details on GitHub.
The front page now shows traffic from all over the world. Initially, it was limited to the region you come from based on locale of your web-browser. The folks from Finland might not really been into flights in Italy, Swedes interested about traffic in Slovakia and Frogs about Britain. But in the end some us still might want to peek into what is going on in Chile, Namibia or New Zealand, particularly now in winter.
The airfields database has been extended to the incredible number of 25262 records by adding some extra Australian, NZ, south- and especially thousands of north-American airstrips. Thanks a lot, John! 🙂
Finally, besides the OGN, ICAO and FLARM the SafeSky beacons are now accounted for This traffic seems to be gaining some traction and we’ll see how that goes on in the next season. And also if it is of any use for us.
That would be all about the OGN logbook for now. News and updates about the CUBEs will come hopefully soon. Because there is also something going on! 🙂