Hi,just today I found what I think should be a bug in bglcomp. I used two xml-sourcefiles which you find below. Both compile ok with bglcomp. But if you look at the generated BGL with a hex editor, you find a difference: whereas the file generated from Test2 is regular, in the file generated from Test1 the code is repeated for the 2nd airport. I tried the same with adding some other detail to both airports, but the result was the same. So we probably have to be careful when we want to write code for more than one airport. - osmanTest 1:<?xml version="1.0"?>Test 2:<?xml version="1.0"?>

What I think you are indicating is the delete airport element is working outside of the airport element vice a sub-element of the airport element.Since you have the files already, try putting a third airport below aiport 2 in test 2 and see if the delete airport is assigned to airport 3.Generally, I would think most designers would only be working on one airport scenery at a time. Secondly, it may be more prudent to separate the airports and not combine them into one file.W. Sieffert

Hi Winfried.I agree, this is not a good thing. There is a work-around:<?xml version="1.0"?>That will compile... I checked it with BGLXML:As you can see, it reverses the order, so the problem would not occur in the BGL. I'm not sure if this is just BGLXML's interpretation, or if the actual hex-compilation is arranged this way.Dick

Hi Dick,the order in which bglcomp puts the airports into the code probably depends on their location in space, but up to now I did not understand how it works. The go-around you propose works indeed. BTW I uploaded today a disassembler for bgl-files in the new format,which allows to analyze more features than bglxml does (approaches, taxiway-signs etc.) and which puts terminal waypoints and terminal ndbs in their proper context within the relevant airport record.Winfried

Hi Winfried.The disassembler is great news! :)Dick