Closed kkebo closed 2 years ago
Thanks for bringing this up! You're right that I mixed up the endianness of the integer interpretation, but in the other direction. It's the integer values of the middle bytes that I messed up.
Because of LittleEndian (LE) interpretation, the following should be true:
Raw Hex Type Integer (LE hex) Integer (LE base 10)
[33 22 11 00] ui32 0x00112233 1122867
[55 44] ui16 0x4455 17493
[77 66] ui16 0x6677 26231
I've attached a binary GUID encoded as described in hopes that'll clarify. Note that it's not actually a txt file... I just had to give it that suffix for GitHub to allow the upload.
I'll update the wiki shortly.
It seems that I made the same mistake in the other example. Thanks for bringing this to my attention. I'll upload sample GUIDs for both.
The wiki has been updated and now also includes LAS and bin samples.
https://github.com/ASPRSorg/LAS/wiki/LAS-ProjectID-Encoding-and-Representation
@kkk669 Would you mind double-checking my examples?
Thank you so much. Your changes look good to me.
If I had to say, the word "integers" in the following line can be a little confusing.
LAS Project ID (integers): [1122867 ][17493][26231][136 153 170 187 204 221 238 255]
How about this?
LAS Project ID (integers): [1122867 ][17493][26231][136 153 170 187 204 221 238 255] <-- note the first three sections are interpreted as LE
Done! Sorry for the delay.
On this page, it shows that the first part of
00112233-4455-6677-8899-AABBCCDDEEFF
is represented as33 22 11 00
in raw hex and as1122867
(=0x00112233
) in integer.However, I think it must be
857870592
(=0x33221100
). Because the second and third parts are represented as21828
(=0x5544
) and30566
(=0x7766
) in integer on the page, unlike the first part, though it explains that the first three parts are all encoded in Little-Endian.If I'm wrong, please close this issue. Thanks.