The git-latest PDL (not yet released as 2.078) has, as a new part of its "3d" demo, a 3D model of the Earth (using PDL's OpenGL support), with shading, and shape information. It also has a bug-fixed version of the 3D graph-evolving code added in the late 1990s, which animates the evolution of a molecule-like graph structure, using a form of publish/subscribe.

Having just looked at https://www.lightningmaps.org/, it uses a websocket to get a live feed of lightning strikes every few seconds, updating a flat Leaflet/OpenStreetMap world map.

It occurs to me that a module that connected a Mojo::WebSocket to such a live feed, could create a live-updating ndarray to display lightning strikes on our shiny new 3D Earth globe, in a decently eye-catching demo module (using PDL's new plugin-based demo system). What would such a module be called? PDL::WebSocket?

Replies are listed 'Best First'.
Re: Module name: PDL::WebSocket?
by Discipulus (Canon) on Apr 07, 2022 at 07:42 UTC
    Hello etj,

    just some sparse thoughts.. naming is hard but we can agree on the fact that in the name, moving from left to right we go from general to particular.

    If your module brings to PDL the ability to open websockets then PDL::WebSocket should be correct, but there is also the possibility that you module enhances Mojo::WebSocket with the ability to create live ndarray, so i'd dont exclude something like Mojo::WebSocket::PDL or Mojo::WebSocket::PDLarray

    In my opinion this depends on the point of view of the developper and how the module is created: if more stress is put on generalising the Mojo::WebSocket part or the PDL one.

    Just my humble opinion

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
      Interesting so far! If I had a solid answer, I wouldn't need to ask for help. Also, to state the obvious: if anyone wants to beat me to it and prototype this (maybe posted on here?), that would be amazing!
Re: Module name: PDL::WebSocket?
by etj (Priest) on Jun 06, 2024 at 03:28 UTC
    I thought the relatively easy part of this would be to make a script that connected to the lightningmaps server and printed out the events. I haven't done the PDL/3D side yet, but 4 hours of agony wasn't incredibly easy. This was mainly due to lightningmaps "proper" having a somewhat complicated protocol you have to keep sending it, and the quasi-underlying blitzortung service doing some overly-clever compression on its messages (see https://github.com/mrk-its/homeassistant-blitzortung/issues/74 for a Python decoder, and my Perl port). Nevertheless, here is a script that will spam your terminal with JSON messages about lightning strikes around the world:
    use strict; use warnings; use Mojo::UserAgent; use Mojo::JSON qw(decode_json); use Encode qw(encode); my $ua = Mojo::UserAgent->new; $ua->websocket("wss://ws1.blitzortung.org/" => sub { my ($ua, $tx) = @ +_; print "WebSocket handshake failed!\n" and return unless $tx->is_webs +ocket; $tx->on(message => sub { my ($tx, $chars) = @_; $chars = blitz_decode($chars); my $bytes = encode('UTF-8', $chars, Encode::FB_CROAK); my $hash = decode_json $bytes; use Data::Dumper; print "message ", Dumper $hash; }); $tx->send({json=>{a=>111}}); }); Mojo::IOLoop->start unless Mojo::IOLoop->is_running; # code from https://github.com/mrk-its/homeassistant-blitzortung/issue +s/74 sub blitz_decode { my ($data) = @_; my %e; my @d = split //, $data; my @g = my $f = my $c = $d[0]; my $o = 256; for my $ind (1..$#d) { my $ord = ord($d[$ind]); my $str = $ord < 256 ? $d[$ind] : exists $e{$ord} ? $e{$ord} : $f +. $c; push @g, $str; $c = substr $str, 0, 1; $e{$o++} = $f . $c; $f = $str; } join('', @g); }
    Edit to add: actually, the user-facing lightningmaps protocol is revealed by reading the JS (see https://www.lightningmaps.org/min/index.php?f=js/realtime.js&1687455813), which isn't overly minified, and with text-search for data.ws. shows what's being sent and received. The blitzortung JS on the other hand goes all in on minification, including actually obfuscating var names with randomised hex numbers.
Re: Module name: PDL::WebSocket? (No. )
by Anonymous Monk on Apr 07, 2022 at 09:18 UTC
      The point of my post isn't one demo. The module-names of the existing demos aren't really visible, instead the interface is roughly:
      $ perldl perlDL shell v1.357 [snip] Type 'help' for online help Type 'demo' for online demos Loaded PDL v2.077 (supports bad values) Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended) pdl> demo Use: demo pdl # general demo demo 3d # 3d demo (requires TriD with OpenGL or Mesa) demo 3d2 # 3d demo, part 2. (Somewhat memory-intensive) demo 3dgal # the 3D gallery: make cool images with 3-line scr +ipts demo 3dtk # Tk graphics (requires Tk) demo bad # Bad-value demo (Optional: PGPLOT) demo cartography # Cartographic projections (Req.: PGPLOT) demo gnuplot # Gnuplot graphics demo pgplot # PGPLOT graphics output demo pgplotOO # PGPLOT OO interface demo transform # Coordinate transformations (Req.: PGPLOT) pdl>

      The point of my post was about a new PDL capability of live updating from (in this case) a websocket. The naming of a demo module for that is not something I was asking for help on ;-)

      However, while it's not really entirely a Cartography thing (it's as much a 3D, and also live-updating thing - the mash-up/synergy are equally what I want to show off), the name "Thunderstruck" is so good it will definitely be involved - thank you!