Certainly a good learning opportunity and from the (cursory) read over the linked docs it looks like those should well serve. Having something “tangible” to use for practical samples is great; I’d just rather (for $work purposes) defer to off the shelf and play with things on the back burner.

I don't want to get into the idea of "real" vs "fake" OS. Windows is certainly "real". I've worked with several variants of MS O/S's and several variants of Unix, one IBM mainframe OS and several real time O/S's. They are all "real" and have their own jobs.

Your question is interesting and a little bit different than what I normally deal with. Worst case, I believe that I can write an inline C subroutine that will do what you want (as long as we are both on 64 bit little endian architecture). Although I don't think that is necessary.

I still would like binary dump as I request in here.

Sorry - I thought I'd given you this in Re^4: Geo Package files

Here you go, this is hex dump of the entirety of $geo from this script...the lengths are vastly different. I added the random order to see how varied the data actually is.

use DBD::SQLite;
use Data::Dumper;

use strict;
use warnings;

my $dbh = DBI->connect("dbi:SQLite:uri=file:osopenusrn_202203.gpkg?mod
+e=rwc");

my $tab = $dbh->prepare("SELECT * FROM openUSRN ORDER BY RANDOM() LIMI
+T 1");
$tab->execute;
my $data = $tab->fetchrow_hashref;

my $geo = $data->{'geometry'};

print join ' ', unpack '(H2)*', $geo;
exit;

47 50 00 05 34 6c 00 00 a0 70 3d 0a a6 be 14 41
00 2b 87 96 97 c9 14 41 20 b2 9d 6f 1a 03 1b 41
e0 ce f7 53 e7 0d 1b 41 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 ed 03 00 00 04 00 00
00 01 ea 03 00 00 0a 00 00 00 40 8b 6c e7 16 c1
14 41 20 87 16 d9 12 07 1b 41 00 00 00 00 00 00
00 00 90 6e 12 83 bf c1 14 41 40 62 10 d8 35 07
1b 41 00 00 00 00 00 00 00 00 90 ed 7c bf 18 c2
14 41 40 35 5e 3a 64 07 1b 41 00 00 00 00 00 00
00 00 a0 c4 20 b0 79 c2 14 41 00 fe d4 78 c3 07
1b 41 00 00 00 00 00 00 00 00 a0 9b c4 a0 1a c3
14 41 a0 47 e1 fa ab 08 1b 41 00 00 00 00 00 00
00 00 40 60 e5 d0 86 c4 14 41 c0 cc cc 4c 3e 09
1b 41 00 00 00 00 00 00 00 00 50 37 89 41 87 c6
14 41 00 2b 87 96 a0 0a 1b 41 00 00 00 00 00 00
00 00 a0 45 b6 f3 a5 c6 14 41 00 ac 1c da da 0a
1b 41 00 00 00 00 00 00 00 00 90 ed 7c bf a0 c6
14 41 00 d5 78 e9 a9 0b 1b 41 00 00 00 00 00 00
00 00 80 6a bc f4 61 c7 14 41 80 be 9f 1a 38 0c
1b 41 00 00 00 00 00 00 00 00 01 ea 03 00 00 04
00 00 00 40 8b 6c e7 16 c1 14 41 20 87 16 d9 12
07 1b 41 00 00 00 00 00 00 00 00 c0 20 b0 72 61
bf 14 41 e0 fb a9 f1 78 05 1b 41 00 00 00 00 00
00 00 00 90 97 6e 92 a7 be 14 41 20 5c 8f 42 5f
03 1b 41 00 00 00 00 00 00 00 00 a0 70 3d 0a a6
be 14 41 20 b2 9d 6f 1a 03 1b 41 00 00 00 00 00
00 00 00 01 ea 03 00 00 02 00 00 00 a0 70 3d 8a
8d c8 14 41 80 95 43 8b ea 0c 1b 41 00 00 00 00
00 00 00 00 00 2b 87 96 97 c9 14 41 e0 ce f7 53
e7 0d 1b 41 00 00 00 00 00 00 00 00 01 ea 03 00
00 02 00 00 00 80 6a bc f4 61 c7 14 41 80 be 9f
1a 38 0c 1b 41 00 00 00 00 00 00 00 00 a0 70 3d
8a 8d c8 14 41 80 95 43 8b ea 0c 1b 41 00 00 00
00 00 00 00 00
[download]

At least the envelope on that one makes more sense.
<Reveal this spoiler or all in this thread>

I get a decoding of the first 8 bites plus envelope of:

0x4750 v=0 f=00000101 srsid=27700
envelope#2 -> 6 elements, mode=little-endian => 'd<6'
339881.51, 340581.897, 442566.608999999, 443257.832, 0, 0
[download]

And the minx,miny are smaller than maxx,maxy -- so whether that's a good thing or not, I don't know.

The main takeaways of my input is that you need to use the < for litte-endian and > for big-endian, and that way you won't be guessing in the future whether your system and/or perl have native big- or little-endianness. (Also, even if you'll always be on the same processor, having those directions explicit in the code will make future development/maintenance so much easier.)