Holy Moley! I didn't realize what I was getting into when I started this. Thank you everyone, and now I must sit down and digest all this. Some (perhaps all) of you grossly overestimate my skill in this area. I did revert to Notepad instead of Notepad++ and find it much easier.MH

Is it possible to put multiple "exclude rectangle" statements in the XML you provided above?I tried it but bglcomp didn't create the expected bgl file. The command prompt window opened and closed, so I assume it identified a problem, but it closed too fast to see any error message. I double-checked the code and didn't see an error, but maybe another set of eyes can find one.I tried to attach the XML file but the forum refused to accept it, so I made a copy with a txt file-extension and it likes that. So keep in mind that I'm really working with an XML file. What can I do?

Yes, one can have multiple exclusions in an xml file. The problem with your file is that the longitudes are negative and you have the minimum and maximum reversed:

 Q:>bglcomp "Exclude KRDU Autogen 1.xml"Parsing document: Exclude KRDU Autogen 1.xmlINTERNAL COMPILER ERROR:  #C2344: LongitudeMinimum MUST be less than LongitudeMaximum!INTERNAL COMPILER ERROR:  #C2031: Failed element parse <ExclusionRectangle>INTERNAL COMPILER ERROR:  #C2032: XML Parse Error!  Element tree follows:ERROR: <FSDataERROR:  version = 9.0ERROR: >ERROR:  <ExclusionRectangleERROR:		  latitudeMinimum = 35 53.03ERROR:		  latitudeMaximum = 35 53.08ERROR:		  longitudeMinimum = -78 45.99ERROR:		  longitudeMaximum = -78 46.04ERROR:		  excludeAllObjects = TRUEERROR:  >ERROR:INTERNAL COMPILER ERROR:  #C2607: Compilation errors detected, compilation failed!Parse complete! 

Georgeps. It is better not to have spaces in the filename, use underscores.

I must not understand the correct notation for lat/long.I tried to emulate the sample code provided by GaryGB above, so in my first effort at an Exclude I used his notation: -78 deg for longitude values (with the larger number, -78.7441, specified as the min value), and it compiled ok. So why do you say that negative longitudes values are a problem? I know I've gotten old and addle-brained but please - as Desi Arnaz used to say: "esplain it to me Lucy" - why do GaryGB's -78 values work and mine fail? In fact, what is the negative value in reference to? Prime meridian?To explain my logic: GaryGB's lat_min is 35.9185... and lat_max is 35.9189..., so numerically the max is greater. Makes sense - the larger the value the more northerly the lat.His long_min is -78.7441... and long_max is -78.7436..., so numerically the min is greater in value. That seems flipflopped to me. Which value is more westerly? The long_max looks to me like a more positive value (less negative) so maybe that makes it logically larger. So I'm wrong but I don't get this. How should I have coded this and why?MH

The minimum longitude is that which is more westerly, ie. more negative.

Thanks GHD. So the values are correct but I still have the two questions that I don't have answers for, or if someone did answer them directly they didn't reach my brain cell.How should I have coded this? Why not express latitude as negative values? GaryGB's sample code (repeated below, arithmetic signs highlighted red)) does just that and no one has said yet that it's incorrect, and it did compile without error.version = "9.0"xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'xsi:noNamespaceSchemaLocation="bglcomp.xsd" >latitudeMinimum = "35.9185547804854"latitudeMaximum = "35.9189870814866"longitudeMinimum = "-78.7441805861611"longitudeMaximum = "-78.7436195141788"excludeAllObjects = "FALSE"excludeBeaconObjects = "TRUE"excludeEffectObjects = "TRUE"excludeExtrusionBridgeObjects = "TRUE"excludeGenericBuildingObjects = "FALSE"excludeLibraryObjects = "TRUE"excludeTaxiwaySignObjects = "TRUE"excludeTriggerObjects = "TRUE"excludeWindsockObjects = "TRUE"/> MH

If the latitude is negative, it would be in the southern hemisphere :Shocked:Gary's minimum longitude is less than the maximum longitude, your minimum longitude is greater than the maximim longitude. Just swap the min and max values and it should be ok.George

Edited January 1, 201214 yr by GHD

Arrgghhhh. I meant to say: "Why not express longitude as negative values?" Anyhow now I understand what will work for me. Thanks!I just realized that the XML longitude values do not indicate West or East. I've always seen it specified as either W or E. So I've learned something else new!But I'm naturally curious and looked deeper. I found that the longitude values expressed in XML code start at 00.0000000000000" (13 decimal places? really!) at the Prime Meridian in Greenwich, and... going Eastward... increase as positive values until just east of Semisopochnoi Island in the great frozen North Pacific (long 179.3533280000000), and then change to a decreasing negative value, becoming 00* 00' 00.00 when arrilving at Greenwich again. Just wait until the next Jeopardy TV show!MH

I just realized that the XML longitude values do not indicate West or East.

Of course they indicate west or east otherwise we would be in a right pickle.Negative is west of the meridian, positive is east, the range being -180 to +180. Similarly, latitude negative is south of the equator, positive is north of the equator, with a range of -90 to +90.

GHD,Please read the third paragraph in my post very carefully. I said: "I just realized that the XML longitude values do not indicate West or East. I've always seen it specified as either W or E." Look again at the XML code. Do you see either a W or an E there? Of course not. I was simply pointing that out. And in my last paragraph... I said: " ...the longitude values expressed in XML code start at 00.0000000000000" (13 decimal places? really!) at the Prime Meridian in Greenwich, and... going Eastward... increase as positive values until just east of Semisopochnoi Island in the great frozen North Pacific (long 179.3533280000000), and then change to a decreasing negative value, becoming 00* 00' 00.00 when arrilving at Greenwich again."Also, please notice that I did not ask a question, requiring an answer. The post was merely an observation of something new I had learned. There is no need to submit a post either to repeat me or to attempt to make me look foolish. I very much appreciate your help and the help of everyone else who has posted here, but it is rude to be sarcastic. I am, after all, as my user icon indicates - a Newbie. Patience is required with newbies.MH

Arrgghhhh. I meant to say: "Why not express longitude as negative values?" Anyhow now I understand what will work for me. Thanks!I just realized that the XML longitude values do not indicate West or East. I've always seen it specified as either W or E. So I've learned something else new!But I'm naturally curious and looked deeper. I found that the longitude values expressed in XML code start at 00.0000000000000" (13 decimal places? really!) at the Prime Meridian in Greenwich, and... going Eastward... increase as positive values until just east of Semisopochnoi Island in the great frozen North Pacific (long 179.3533280000000), and then change to a decreasing negative value, becoming 00* 00' 00.00 when arriving at Greenwich again. Just wait until the next Jeopardy TV show!MH

That's the spirit ! :(BTW: I standardize all my FS Lon-Lat coordinate data on 13 decimal places in all log files and spreadsheets, so that when I perform certain terrain conversions, I will derive precise placement of special types of scenery content accurately at FS Quad Matrix ID (QMID) vertex locations (often referred to as "Area Points").FYI: We may expect that geographic Lon-Lat input data is used for all FS scenery content creation or exclusion coordinates, but the FS terrain scenery rendering engine actually works internally with several types of data formats... stored in its own default files, and in ex: 3rd party add-on BGL files ...within the framework of a specially modified quad tree matrix or grid system.There are several FS SDK compilers, most of which use "XML" code types, others use special "Assembler" code types, and AFAIK, there is a few proprietary FS file types used which are not yet publicly documented by MS.Although I often use 13 decimal places with the FS SDK compilers which require conversion of "geographic Lon-Lat" input data to FS' own "vector" coordinate system for precision placement of some types of terrain content at run time, FSX SDK SP2 / Acceleration BGLComp may... or may not.... utilize all the decimal places I submit in my coordinate input data; but as you have seen, it does compile my data properly.Based on your statement above, I'd be curious if during your recent inquiries, you had encountered anywhere else, an online reference to use of "13 decimal places" when expressing Lon-Lat coordinates in XML coding ?Thanks, and keep up the good work with the learning process ! :(PS: If you'd like to see some example XML code that can be compiled in BGLComp to replace the above default "water tank" with a "water tank on a narrow base" type scenery object (ex: "gen_watertower02" which actually exists at the real world location under discussion in this thread), just ask... and we can expand your scenery-building horizons a bit further. :wink:For a visual gallery of these FSX default scenery objects, see: http://lc0277.gratis...ards/index.html ; other default FSX objects can be browsed via the main web site link here: http://lc0277.gratis...r/sceneobjects/Regards,GaryGB

Edited January 2, 201214 yr by GaryGB

I thought I had XML code to exclude autogen nailed, but evidently not. I got the excludes done correctly for the watertank issue, but I'm on tosomething else that's not working for me.I'm aware that Courchevel, France (LFLJ) is considered a dangerous airport. My resources tell me the rwy is 1756 feet long, elevation is 6417 ft,one way in and one way out. (See video at

) I'd like to give it a try but FSX has a lot of veryannoying trees that I want to exclude. As the video shows, no trees are really as close to the rwy as FSX has them.Also, FSX doesn't correctly display the rwy, which is not entirely level - has a vertical kink in it to permit aircraft to slow enough to avoid overrunning therwy when landing - and to gain speed when taking off. I tried the following code to exclude. It compiles ok but the trees are still there! I've concluded that my coordinates are wrong,but I've triple-checked them and can't see a problem. What am I doing wrong?<?xml version="1.0"?><FSDataversion = "9.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="bglcomp.xsd" ><ExclusionRectanglelatitudeMinimum = "45 24.00"latitudeMaximum = "45 24.50"longitudeMinimum = "6 37.20"longitudeMaximum = "6 38.39"excludeAllObjects = "TRUE"/></FSData>

Hello again !Although non-autogen objects can be excluded in FSX via XML-derived BGLs compiled with BGLComp, if you wish to eradicate "autogen" tree objects in FSX, a "CVX vector type" Autogen Exclude Polygon BGL compiled via SHP2VEC is required... as initially alluded to in my post above within this same thread: :(http://forum.avsim.n...ost__p__2190703

ADE Manual, section 15.2 et.seq. on "Terrain Polygon Tool" shows in the illustration where one clicks on "Add Polygon" to begin making one's Exclude object entirely within ADE itself.Additionally at the end of ADE Manual 14.3 - "Exclusion Rectangles", one is instructed as to what attributes should be used when following the procedure in Section 15.2 et.seq. on "Terrain Polygon Tool"...to make an Exclude for Autogen.After drawing ones desired coverage area as a Polygon, applying the "Airport Background" > "Exclude Autogen" attribute in the Polygon Properties dialog, one would click "OK" to keep that Exclude Polygon object, save the ADE project, then "Compile Airport": a Exclude BGL would thus be created by ADEThat BGL found in your specified output folder would then be moved or copied to either of 2 folder locations as described in my post above according to what scenery generated the autogen object: FSX default scenery, or a 3rd party add-on.The work-flow presented above is so you know what to do when you opt to make the Exclude "exclusively" using ADE.

When the appropriate "CVX vector type" Autogen Exclude Polygon BGL is placed in a FSX Scenery Library Area layer in the physical stack of layers at a position "higher" than the default FSX scenery (ex: [FSX install path]Addon SceneryScenery), your offending tree(s) should not display. :Idea:If you have further difficulty with achieving your goal, please post back here with a screen shot of the problematic area of trees showing in a top-down view, and include coordinates for an area of persistent tree(s) closest to the airport itself.Hope this helps ! :smile:GaryGB

GaryGB,The forum sent an email to me notifying me of a post I think you made yesterday. I can't find it here so am replying to this much earlier post of yours. Perhaps if I provide a little more background on my environment that will help you understand my dilemma. And actually there are two issues, not one. If you use FSX my issue should be easy for you duplicate. I wanted to use the very odd airport at Courchevel (LFLJ). The real rwy has a sort of stairstep in it. Default FSX renders the rwy as being level. In addition, FSX has some autogen trees right at the only approach. The strip is very short and 600+ feet elevation so it's a challenge to get over the trees. My intention was to exclude them but I haven't been successful. If you'll have a look, you'll see what I mean. It is not a trivial thing for me to learn to use ADE while fixing this. Besides....I found an addon Courchevel that renders the rwy much more realistically. However, when I start a flight, the plane is positioned northwest of the addon rwy. I assume that means that the addon is not positioned correctly but I'm not positive. And there's another grove of trees in the way. It appears that besides eliminating the trees, I must either relocate the addon airport or the position at which I start a flight. The addon is in the avsim library - altiports_alpesxv2.zip. Would you mind taking a look while I doing the same?Thanks, MH

Hi "MH":I have examined both the default and the add-on version in altiports_alpesxv2.zip for Courchevel in FSX, with my scenery and autogen density sliders maxed (with NO UTX or GEX "Europe" active, and with NO FSX.Cfg "TERRAIN_MAX_AUTOGEN_TREES_PER_CELL" autogen attenuation tweak active).I do not see any trees of significant height that would impede one's approach to LFLJ... as they are farther downhill at an effective lower elevation well below the altitude of the RWY threshold.Also, I see little more than sparse lower height vegetation in the immediate vicinity of the airfield and terminal itself.The location of LFLJ in altiports_alpesxv2.zip for Courchevel has been placed into an alignment closer to real life than the FSX default LFLJ.Google Earth 'Jump' coordinates: 45.397395°N, 6.634884°EWhen that add-on LFLJ in altiports_alpesxv2.zip for Courchevel has been placed into a position in the FSX scenery library stack of layers ABOVE that of the default FSX scenery, it will exclude the default LFLJ.Thus if the add-on scenery is installed and configured properly, your aircraft will load correctly at the LFLJ in altiports_alpesxv2.zip... and the default FSX will no longer be visible.I also think it is likely you may then no longer have interfering trees on the approach and within the vicinity of the airfield itself.I suggest that you try this:1.) Remove the present installation of any add-on airports and/or scenery for Courchevel area2.) Un-ZIP the contents of altiports_alpesxv2.zip into a subfolder created in the [FSX install path]Addon Scenery folder chain.3.) Follow that authors instructions in his ReadMe file to add the specified parts 0, 1, 2, 3, and 4 via the FSX Scenery Library GUI "Add Area" function.4.) Be sure UTX and/or GEX Europe are disabled during initial testing.Please follow up here to let us know how that worked for you. :Nerd:GaryGB