Hi Jacky,that sounds cool. I assume, that Delphi source is copyright, correct? In case it's not: soccy @ fsxtools.de So far, I would not give out my sources and I really 100% understand, if you don't. You spent much time for coding that, I'm sure.That bgl pdf is really well done. I'm still more likely fighting with getting a C# reader to work, that matches that pdf. The C# coding is not the problem, too, more like to work with the datas Im reading.My proggy can read it out like that (all from Kavieng Airport APX*.bgl, beginning always at offset 0):a) (Normal Byte Array):1 2 146 25 56 0 0 0 0 97 70 168 182 189 198 1 3 24 5 8 5 0 0 0 10 148 9 0 10 148 9 0 11 148 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 0 0 0 1 0 0 0 156 0 0 0 16 0 0 0 44 0 0 0 1 0 0 0 1 0 0 0 172 0 ...So far, that doesnt match too much of the PDF structure, does it? Or I didnt get the clue yet.:( (Strings)8...That doesnt help anything^^c) (Bits)00000001000000101001001000011001001110000000000000000000000000000000000001100001010001101010100010110110101111011100011000000001000000110001100000000101000010000000010100000000000000000000000000001010100101000000100100000000000010101001010000001001000000000000101110010100000010010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001100000000000000000000000000000001000000000000000000000000000000010000000000000000000000001001110000000000000000000000000000010000000000000000000000000000001011000 ...Doesnt look helpful too :(d)(Hex) 0102921938000000006146A8B6BDC60103180508050000000A9409000A9409000B94090000000000000000000000000000000000000000000300000001000000010000009C000000100000002C0000000100000001000000AC00000010000000220000000100000002000000BC000000200000002A0000000400000001000000DC00000010000000270000000300000001000000EC000000100000000A94090001000 ...Well ... hmm ... I don't know, if thats helpful.Well, all in all, I still don't have really found the way to interprete the things. But I think I need to spend some more time with this stuff, I'm simply completely new to this.Thanx for all your support & help,Greetings,Chris.

>>My proggy can read it out like that (all from Kavieng Airport>APX*.bgl, beginning always at offset 0):Shame you don't give the filename, as I couild have checked further, but comparing a typical APX*.BGL in a Hex Editor with your decimal (ugh) rendition, just the 1st 16 bytes:01 02 92 19 38 00 00 00 70 D1 22 CD B1 BD C6 01compared to yours (converting your decimal bytes to a hex representation):01 02 92 19 38 00 00 00 00 61 46 A8 B6 BD C6 01looks pretty likely to be right to me. Looking at the PDF for interpretation:Offset 0, length 2: you have 01 02"New BGL ID" = 0x0201. Correct. (remember Lo-Hi order on all Intel processors).Offset 2, length 2: you have 92 19"probably version": 0x1992. Correct.Offset 4, length 4: you have 38 00 00 00"size of header" = 0x00000038. Correct.and so on.I don't understand why you think you read it wrong. You are just not interpreting it according to the PDF!Define some structures, use the correct sizes and types. It'll all come much more easily. If you don't understand that much programming you do really need to read up more first.RegardsPete

Hi ChrisAs I wrote in another post earlier, it's pretty easy (well, at least I think so) to read the data from the file using a System.IO.FileStream and a System.IO.BinaryReader. Following the PDF-file, it really shouldn't be much of a problem to get the information you want. The FileStream has methods for going to the offset you want, and the BinaryReader has methods for reading the kind of values that should be in that position. In case you don't know, a WORD is the same as an UInt16 (ushort) in C#, and a DWORD is the same as an UInt32 (uint). Other than that, I think all types are called the same in the BGL documentation and in C#. I wrote a small program to try it out, and here's the beginning, if that's any help to you. Pretty much what I do is I check the first three values to see that they match what's specified in the PDF-file, and then move the stream position to the next interesting value, which is the number of section pointers, located at offset 20, after which I read the value.

private FileStream fs;private BinaryReader br;(...)this.fs = new FileStream(this.openFileDialog1.FileName, fileMode.Open);this.br = new BinaryReader(fs);(...)if (br.ReadUInt16() != 0x0201)   MessageBox.Show("Error (new bgl ID)");if (br.ReadUInt16() != 0x1992)   MessageBox.Show("Error (version)");if (br.ReadUInt32() != 0x0038)   MessageBox.Show("Error (headersize)");fs.Seek(20, SeekOrigin.Begin);uint numberOfSectionPointers = br.ReadUInt32();...

I hope this helps you,Klas

Wahhh, I used an old version of Orthmanns PDF. The new one is clearer.One last newbie-question: What does that "0x" mean, thats always shown there, i.ex. 0x03c? I.ex. he's once giving the offset like "0,2,4,...", next time it's "0x00, 0x04, ..."Or in the lat/lon calculation he's also using a 0x... value.(I know, that this must be a really basic question - anyways, "don't ask, stay stupid" ^^)Also I did not understand, Pete, why u said "dont convert to hex". Would it be easier to use plain byte reading? Isn't Orthmann's doc some way referring to a hex-visualisation, too?Thank you once more, you guys are good teachers, explaining really step by step. Really appreciated!Sincerely,Chris.

Klas,that is really a big help. It's a good way to learn from some working code. Thank you really very much,Chris.

0x just means that the number is in hexadecimal form (base 16) instead of the regular decimal form (base 10). You can use that way of writing when writing your code too, so you don't have to convert anything. E.g.,int number = 0x1F;is the same asint number = 31;Klas

>Also I did not understand, Pete, why u said "dont convert to>hex".That was some way back, wasn't it? I can't even find it. But going on memory, you were talking about a hex representation in character format, using characters '0'-'9' and 'A'-'F'. You don't particularly want to convert anything in the BGL into any particular numerical form, it IS in the form it should be in already! i.e Binary. You don't "convert" the binary value 0x1992 to the character "0x1992" except to print it or show it for humans to read -- your program is surely meant to understand and use the values as they are, i.e. in binary. Whether you want to write them down or print them out in hex, binary, octal, decimal or whatever is irrelevant.RegardsPete

Hey Klas, Pete,thank you very much once more. I really start to understand that stuff, wow^^ As soon as I have the time to code the runway lat/lon proggy I will show you the result, so that you see, how far your patient explanations brought me.I really need to say, that thanks to you dudes this forum is a really great resource. If I get asked by MS to propose a MVP, you're my choice^^Thank you very very much,sincerely,Chris.

Hi again,I had a little bit of time and made big steps forwards understanding (and successfully reading) .bgl files. Actually I reached my original goal to read out lat and lon of runways. But I also need to read out the ICAO ...So, my new problem: Calculating ICAO.I don't understand Orthmann's description there.Let's take Kavieng Airport again.ICAO for Kavieng is AYKV.Following Orthmanns description:A = 12, Y = 36, K = 22, V = 33So my calculation: (((12*38 + 36) * 38 + 22) * 38 + 33) * 38 = 27030046 ( = 19c721E)27030046 * 32 (= 0x20) = 864961472 = 33 8E 43 C0 So far, the .bgl contains at ICAO position: a1 52 5b 01 :) *gg*Now beat me, I know that I do something incredibly wrong here ... Also I would like to go the other way around, like going from a1 52 5b 01 to the ICAO, since normally I do not know that its AYKV.Has someone experience how to calculate that special format?Regards,Chris.

Hi Jacky,you solved that in a smart way (you actually seem to be that way hehe). It's incredible, but it's working! It also included the answer to my question, that I need to calculate things other way around if I go from encoded ICAO to string one.Well, what can I say, once more you made my day :)Found ICAO:ada95 Decoded: 33 --> VFound ICAO:491e Decoded: 22 --> KFound ICAO:1ec Decoded: 36 --> YFound ICAO:c Decoded: 12 --> AIcao = AYKVThanx alot!!Cheers,Chris.

LOL - funny conincidence I've been stuck with the very exact same thing just recently. Completely prevented me from making any progress. Together with the lat/lon conversion functions, which had some small error in the doc, I believe... Kept me busy for some, indeed. *:-*Cheers, :-beerchugEtienne :-wave