47 50 00 05 34 6c 00 00 50 b8 1e c5 2c 75 23 41
As per the spec, the first two are 0x4750. The version number is 0 which means version 1 which is what I would expect.
Next comes 05 - or as I said previously, this is 00000101
The bits correspond to RRXYEEEB - where EEE defines the envelope. So that is 010 = 2 which gives the envelope as being 2: envelope is [minx, maxx, miny, maxy, minz, maxz], 48 bytes. Also from this, B = 1 tells us that it's Little Endian.
The SRSID I worked out late last evening using 'V' to unpack it. It is 27700 which is the SRSID for OSGB 1936. That passes the sanity check as the data I am decoding comes from the Ordnance Survey.
This is where I got lost...
The 6 components of the envelope I tried to unpack with 'd6' and got:
637590.385
642426.601
309577.58
310361.391000001
0
0
The last two seem reasonable as I am not expecting height data although I would not be surprised if it were included. However, the first and third give a location inland from the east coast (near Norwich if you know your UK geography) and not off the west coast as I would expect for a minimum bounding coordinate.
If I ue '(f<)6' I get even less sensible results:
-2539.51953125
10.2161064147949
8.48770014272304e-08
10.2253313064575
126443847680
9.18094444274902
I have no idea of how many BLOB's you need to decode or what the performance implications are. I would try to get something functionally working and then worry about performance tweaks later. It could very well be that such tweaks are not necessary
There are 1.4 million BLOBs that need decoding! However, the decode process will be done once every few months (the dataset is updated monthly but doesn't change massively). The decoding process is not time critical. If it needs to run overnight then so be it. |