I found that, although the most frequently used reason to learn WED was to create a new airport, there were things I wanted to do that had nothing to do with an airport. 

Fixing existing erroneous scenery errors in an overlay was my main focus. I was annoyed with houses in weird places, missing buildings, flat 2D-looking landscapes from Ortho mesh photos and so on. I wanted to fly over my subdivision and see my house - and the neighbors - in their correct footprint.

Also, I found that using a 2D orthophoto as the base mesh without any scenery overlay looked flat. It should - it's 2D!! So, I wanted to have 3D objects and forests, along with the orthophoto - but more photo-realistic than what SimHeaven or X-Plane provided with their overlays.

The result is a document that explains how to fix scenery overlay errors and make things look more photo-realistic in 3D. Obviously, it is for people who have little experience in WED, but want to make their sceneries more accurate.

I hope it might help somebody. My thanks to 'Daikan' and 'Triplemon' for their early help - you guys are amazing.

Google docs link to WED primer:

https://docs.google.com/document/d/e/2PACX-1vRHZV1VboiQKYTdcWGk_2gKfLkUkU0JpAp02DDnTTzvpVIlqX-_er7axyacQ_ROcQ/pub

https://wayback.maptiles.arcgis.com/arcgis/rest/services/World_Imagery/WMTS/1.0.0/default028mm/MapServer/tile/10/${z}/${y}/${x}.jpg

June 2020

https://wayback.maptiles.arcgis.com/arcgis/rest/services/World_Imagery/WMTS/1.0.0/default028mm/MapServer/tile/11135/${z}/${y}/${x}.jpg

March 2024

https://wayback.maptiles.arcgis.com/arcgis/rest/services/World_Imagery/WMTS/1.0.0/default028mm/MapServer/tile/60013/${z}/${y}/${x}.jpg

After changing the highlighted parts, use File -> Advanced -> Import DSF in WED. This will add the items to the WED scenery. This import process can also be used to merge multiple lists or sceneries in WED. Review and refine as neccesary, e.g. add exclusions etc.

Finally, export the scenery from WED. That will make WED split the scenery into 1x1 degree DSF tiles and write all required, separate files as usual, ready for use in X-Plane.

This method also works for polygons, facades, lines, object strings etc. Make a SMALL demo scenery, export it as above to get youself a nearly self-explanatory example for any other scenery items supported by X-Plane.

New entity: Shapes

These items create nothing at all in X-Plane scenery. Just like "Reference Images" don't do, either:

Huh ?
Some 3rd party developers use WED to create input data for their addons, like World Traffic paths, Living Scenery Technologies animated routes or O4XP road leveling or runway smoothing polygons. In the past, folks "abused" airport lines for this, which caused all kinds of mixups when the apt.dat meant for these tools were instead placed where the sim finds it.

The new shape entities are written as lines or polygons (closed ways in OSM speak) to industry standard .kml and  .osm format files, that can be directly fed into these 3rd party tools. Or dropped into Google Earth or JOSM. They also allow to specify per-vertex or per-instance properties. These are intended as a stable inferface between Laminar and 3rd party scenery design tools. Very unlike WED's internal .xml format, which changes frequently.

New entity: Polygonal exclusions

Exclusion zones used to be rectangular and N-S aligned only. Its called a "bounding box".

This is an example of a "clever" old-style road exclusion. It takes out the small road inside the airport boundary, but does NOT kill the highway just outside of the airport.
But many folks had issue in realizing that your only need to exclude one vertex to get rid of the whole road. So they did some overkill:

This doesn't do any better, but causes limted harm - it will not kill the highway. Just slows down scenery loading times a bit. At Laiminar that is called "silly".
But often folks use bigger exclusions to "make sure" they catch a road vertex, so they draw them this way:

I circled the vertex where these exclusions accidentially kill the highway. And pointed an arrow where the exclusion just barely misses the highway. In the next scenery recut the highway may move a bit. Or users may run simheaven where roads have more vertices for more precise shapes - in all these cases the above exclusions do really nuke a lot of the scenery adjacent to the airport. This is a very poor design technique.

With WED 2.6 and X-Plane 12.0.5+ (yep, no need for 12.1) polygonal exclusions can better avoid unintended side effects:

BTW - these sceneries will still work with X-Plane 11. DSF files created with these polygonal exclusions will still load without error messages in X-Plane 10 or 11. But over there the polygonal shape is ognored by the sim and the zones essentially behave again the same as the old-style retangular, bounding box exclusions. If WED 2.6 is set to the XP 11.30 or older export targets, this is also visualized in the map:

So the on-airport road will still be excluded in those older X-Plane versions, but the exclusion effect reaches much farther than intended, just as it used to with the old-style exclusions.

I like to repeat here that these polygonal exclusions still do NOT change the way exclusions work: For all items but forests, exclusion work on a per-entity base. I.e. if one vertex of a facade gets caught in the exclusion, the entire facade is eliminated. Same with autogen, roads etc. In addition, if an exlcusion intersects these entities, without an vertex node being inside the zone e.g:

This exclusion will still not change or eliminate the facade, nor will in remove any roads. Neither the old nor the new polygonal exclusions are "exact cutting", i.e. can not "cut a piece off" of sceny entities that are partially outside of the exclsion zone.

The only entity type where exclusions are "exact cutting" are forests. They remove individual trees in the exact shape of the exclusion, not the netire forect polygon worth of tree's. So at first sight - that is where arbitrary shaped exclusions would be really nice. BUT, unfortunately, on forests, even polygonal exclusions still work ONLY as classic rectangular ones.
This is an X-Plane limitation and is not currently planned to be improved on before the next generation scenery engine.
So nice try's like this

will nort work out as hoped for, but rather still cut a giant rectangular chunk out of the forest:


New entity: Terrain objects

This are ordinary 3D objects automatically created by WED to go along with draped orthophoto's. They can be used to depict small scale 3D details and it works with all versions of X-Plane from 10.50 on.


These objects integrate seamless and fully automatic into any draped orthophoto overlay created with WED 


But this has some significant disadvantages over real terrain deforming - no draped content like polgons, roads, run & taxiways or even facades can be placed ontop of it. Only forests can be translated upwards by WED to stay exactly ontop of these terrain objects, .obj need to be manually lifted via set_MSL to stay exactly on top of those.

These new entities are intended as a holdover feature until better terrain forming interfaces are available with the next generation scenery rendering engine. I do intend to keep the WED interface to these functions for the next generation scenery stuff the exact same - so in that "great future" you just need to re-export and the DEM used now to create the 3D objects will then go directly into the rendering engine and deform the actual terrain. At that time all limitations wrt draping will go away and the terrain objects become actual terrain.

I will post a separate tutorial on using these in a few days.

Support for Dual docking jetways

Starting with X-Plane 12,.1.2 jetways can be specified to dock with either pax door #1 or, if specified in the .acf, pax door #2 of any aircraft. The property is set on the very last node of the jetway facades, the same one where the docking / not-docking property was specified before. A door specified to dock with door #2 will for now NOT dock with any other door #1 of any other aircraft nearby.



If there is a 3rd or other jetways present, able to reach the same aircraft, these still need to be set to non-docking. The sim has no abilities to select the "best" jetway able to reach the aircraft, nor any ability to detect collisions between jetways.  in the example below it could result in implausbly crossed jetways if the 3rd jetway were enabled.

Validation will also indicate if there is a door 2 jetway with no jetway serving door 1 at the same ramp start.

Support for non-integer object string spacings

The spacing parameter for these is an integer in the scenery system - so small spacing in e.g. light strings or terminal kit column strings got rounded down the next full meter.
Starting with X-Plane 12.1.2, spacing is using a special encoding scheme to support centimeter accurate spacings up to 400m. This encoding will not cause older versions of X-plane to throw any errors when loading a scenery using this scheme, but rather not show any of the object string items except the very first. Set the export target to X-Plane 12.00 or enter only spacing in full meters to retain the old behavior.

Usability enhancements for newbies

Any scenery package without an earth.wed.xml file was in the past opened as a new, empty scenery. This was frustrating for first time users, as they had to read the manual and learn how to import already exported / dsf format scenery back into WED's own database. The dreaded "empty screen" barrier of entry.

Now WED 2.6 will analyze the existing files in the "Earth nav data" directory and offer to import those. So non-WED sceneries "just open fine". But folks will still need to read the manual or watch the tutorials until they arrive at "Export to Scenery" so they don't "just save and sim".

The new auto-import will re-construct the airport hierachies pretty well, even if there are multiple airports as well as off-airport scenery elements present. Only caveat, WED limits itself to do that for sceneries with less than 10 airports and less than 10 DSF tiles, only. So to keep folks from trying to directly "open" the Global Airports and getting puzzled why this takes half an hour plus and WED is "a bit sluggish" afterwards with 38,000 airports and 22 million scenery entities loaded ... but yes, it would, theoretically, work. I create the Global Airports as a single scenery from WED after all.

Usability enhancements for advanced users

When opening a broken .xml scenery, WED will now look for the earth.wed.xml backup files and offer to open those instead.

Jetways have in the sim a bit more reach as depicted in the past.

That reach also depends a bit on the angle of the cabin. The new depiction now differentiates a bit what is the "save reach" vs what can be reached only if the cabin angle is right. There was also a bug that resulted in the jetways not retracting as much in the sim as the WED animation shows - this is now fixed in X-Plane 12.1+. Existing custom sceneries need to be re-exported (using any WED version) to get these fixes, the Global Airports shipping with XP12.1 already have all those.

Object string (like taxiway edge/centerline lights etc) spacings and positions now match X-Plane 12 down to half an inch, before they were off by a foot at times.

Usability enhancements for experts

The previews in the library pane depict tiled shader effects for draped polygons.

When exporting to X-plane 11 or older targets, runways with XP12 only EASA style markings are backported to the closest looking FAA markings. Validation will also yell that 2-light APAPI are not available back in XP11.

Validation will allow runways with T suffix in Canada's high north, even if Transport Cananda does not put that suffix into their CIFP data. Should affect at least one airport you never heard about 🙄

Airport boundaries are now rendered with different highligthing in the "Exclusions / Boundaries" tab. So its easier to refine complex boundaries with tons of nearby other stuff. And enable more things to come on boundaries, real-soon-now-TM.

During export to scenery WED now remembers any prior written DSF tiles and will clean those out at the next export.
This is needed if e.g. a scenery contains only a few scenery items in a given DSF tile. If ALL these items are moved into the adjacent DSF tile or entirely deleted, the next export has nothing to write to this DSF tile. So it simply stayed on disk as "stale data". This resulted in some surprisng duplication when folks moved that ONE and only items incross the DSF boundary and after the next export got two - one in its "new" location in the "new" tile, plus the leftover old DSF where the items was before.

DEV/ directory.
All files required for WED sceneries must be inside the scenery directory at export time. Orthophoto sources (the .tif file) additionally reside in the same directory as the .pol and .dds generated - this is how WED determines WHERE to create these. This presents some inconveniences to remove source art before scenery distribution. With WED 2.6 any source art can be placed in a subdirectory of DEV/ at the toplevel of the scenery. In those cases all derived files will be created in a path that has the DEV/ stripped from it. E.g. a file in DEV/Orthos/xxx.tif will create .pol and .dds in Orthos/xxx.dds and Orthos/xxx.pol

This allows to use the same convention as Laminar uses internally - all source / blender / gimp / dem files etc for a scenery are in DEV/. For distribution the entire DEV/ directory plus the earth.wed.xml can be removed.
WED 2.6 does also validate the exported scenery does not reference any art from within the DEV/ directory tree - as that would mean removing DEV/ would break the scenery.

Change history

WED 2.6.0r2 10/23/24
   Bug fix:
   - fix crash when reverting to existing scenery
   - support longer X-Plane version strings
   - WED-1524 forests on terrain models not elevated by set_MSL

WED 2.6.0r1 8/16/24
   Bug fix:
   - improve GW upgrade heuristics to change less JW lengths
   - change GW export target to be XP 12.1.2

WED 2.6.0b3 7/5/24
   Features:
   - force default dir for most file open dialogs to be current scenery pack
   - make ToolTips in LibraryList more meaningful
   - support Jetway docking to the 2nd door of the aircraft for XP 12.1.2+
   Bug fix:
   - minor accuracy improvement in map projection for very large objetcs
   - fix duplicated exclusion zones at full scenery import
   - WED-1507 fix exclusion polygons still green when locked

WED 2.6.0b2 6/3/24
   Features:
   - full scenery import menu function
   - new export target 12.1.2 to distinguish string spacing behavior
   Bug fix:
   - minor speed improvements for scenery load, export and upgrade heuristics
   - remove some old XP11 wording in object density menu

WED 2.6.0b1 5/20/24
   Features:
   - polygonal exclusion zones for XP 12.05+
   - new entity: shapes to support 3rd party scenery creation tools
   - new entity: terrain_objects for DEM based, 3D ortho terrain
   - WED-671: delete DSF written at prior export, but now empty
   - polygons in Library Preview pane show tiled shader effects
   - after import from gateway, keep all groups collapsed/closed
   - improved visualizations in Exclusion&Boundaries tab
   - suggest to delete obsolete items when downloading XP11 airports from GW
   - WED-1496 add gw_credits meta tag at gateway export
   - XPD-15016 Disallow circuits at GW export for one-way airports
   - refined preview of safe vs ultimate service range of jetways
   - improved runway light validation warnings
   - auto-import when opening scenery packages w/o .xml file for 1st time
   - option to recover from backup with broken .xml files
   - XPD-15379 validate set_AGL, set_MSL within -1000 ... 10,000m, for GW +/-100m
   - improved string spacing resolution for XP 12.1.2+
   Bug fix:
   - fix Obj8 drawing not recognizing ATTR_no_blend threshold values
   - validate ObjectString spacing parameter to be non-zero
   - validate transition level & altitude meta tags more thoroughly
   - reduce a few artefacts created by grass mowing function
   - WED-1482 backport EASA markings when exporting to X-Plane 11 target
   - in CIFP validation, match runways with T suffix also to CIFP data without T
   - fix "select with list" gateway import
   - WED-1482 fix typo in meta tag allows-circuits, repair at file open/apt import
   - refine validation for trans_altitudes and trans_level, allow flight levels
   - WED-1493 fix airport not validated upon manual trigger and not at toplevel of hierachy
   - WED-1487 improve facades and agp objects shown function of showlevel
   - WED-1501 improve object location accuracy for previews of object strings
   - validate APAPI not exportable to X-Plane 11 and earlier

### end of list ###

Here is an example where KSEA, originally drawn for XP10.00, really went overboard with this. While this seemed initially like a good idea, after a few recuts of the Demo Area Terrain base mesh this showed its ugly face. I reworked the airport for XP10.50 and with the recut Global Scenery in XP11.00 this shows the full improvement:

Others go the other way and have airport boundaries too tight and using excessive detail. This does even more harm, although it only shows after the next Global Scenery or 3rd party mesh updates:

Using too many nodes in the boundary also affects the mesh detail level outside of the airport: The global mesh needs to insert a lot of terrain triangles to follow the airport boundary exactly, as it is not allowed to simplify (aka cut corners) here. This airport included so many nodes in its boundary, nearly 100,000 ground mesh triangles were required for the airport area alone. This reduced the detail level for the whole rest of the 1x1 deg tile by some 30%.

Airport boundaries also do automatically exclude all 3D content like forests/autogen strings/objects when base mesh sceneries are created. So even when it looks like you have enough exclusions for the current Global Scenery and even your favorite 3rd party addons - when these are updated it might not be the case anymore:

So - the airport boundary is NOT a tool to trace political/legal boundaries or to determine where the airport grass should be visible or not. It is to define the area your particular layout needs to have (somewhat) flat and level ground and to be free of 3D autogen/addon scenery items. This also implies - boundaries are ignored for seaports and make no sense for sealanes. Roads are not 3D items - so these are not affected by airport boundaries.

Finally a example of how low detail and tight boundaries could be, along with a few reasons why NOT go any tighter than this:

See also the WED manual at http://developer.x-plane.com/manuals/wed/#creatingairportboundaries

Hey everyone,

Thanks to all the other "how-to" posts on this forum I've been able to make some nice scenery for myself (and others!). To try and give back, I figured I'd do a quick write-up on how to use the JPEG2000 images(mainly from the USGS) for image overlays in scenery packages. I couldn't find a single, definitive, up-to-date source, so here's my compilation...

Shout out to chris k for the great starting point in this whole ordeal, and thanks to Pilot Plus for all his assistance and patience.

1. Try and use GeoTIFFs

If you can find images in the GeoTIFF format, use them! You'll save yourself a lot of trouble. Read the linked post above for that workflow. If you can't find any...

2. Download JP2000 images

Find the appropriate JP2000 images from the USGS National Map Viewer (or the appropriate source for your locale). There are plenty of instructions on how to get the images.

3. Resize the images

Again, refer to the post by Chris K or the WED documentation on how you should be resizing your images. But, when it's actually time to do it, you may notice a problem: the images are huge! I like to use the IrfanView program to do batch resizing. After you download and install the program, you'll need to install the iv_formats.zip plug-in. This adds support for the JP2000 format. Unzip the plug-in ZIP and dump all the files in the "Plugins" folder wherever you installed IrfanView.

Now open the program and select File > Batch Conversion. In the top-right of the pop-up navigate to where you have your images (be sure to change the "Files of Type" to match the JP2000 format), then click the "Add all" button to add all of the images to your queue.

Back on the left side, select "Batch conversion" as the task, select "PNG" as the output format, check the "Use advanced options" box and click on "Advanced". This will open another pop-up where you can add your options. The important thing is to check the "RESIZE" box, select "Set one or both sides" and input your desired image size (e.g. 2048 x 2048). At this point you can add other options, such as changing the gamma correction to add a bit more contrast to your images... run it on an image, see if you like the results, and repeat until you get what you want.

Finally, click "OK", select your output directory and click "Start Batch". Prepare to wait a while...

4. Move all the images to your scenery folder

Your PNGs and the original JP2000 images should be moved to a new folder at X-Plane\Custom Scenery\[YOUR AIRPORT]\Tiles (or somewhere similar).

5. Convert JP2000 to GeoTIFF

Download the GeoJasper utility. This allows you to convert JP2000 images to GeoTIFF images. Navigate to the folder where you have it installed and run the following command in your terminal prompt ("cmd" on Windows, "Terminal" app in OSX):

(Windows example)

geojasper.exe --input C:\..\Tiles\[PNG_NAME].png --output C:\...\Tiles\[NEW_TIF_NAME].tif

This should be run on all the images. Now you have a GeoTIFF for each tile, and you have the tile in PNG format.

6. Place the GeoTIFFs

Open WED and click on File-> Import Orthophoto. Select all GeoTIFF's desired to import; they should pop into the correct location automatically. Selecting multiple files is supported. The image will immediately display in WED, unless the image size in pixels is to large to fit into the available physical memory or VRAM available. SIzes up to ~5000 pixel per side are usually no problem.

Note on WED 1.5: The GeoTiff file (actually, any TIFF format file) needs to have an extension of .tif, .tiff is not recognized. WED 1.6 removes this limitation.

7. Convert the PNGs to POLs (draped polygons)

Run File -> Export Scenery Pack.

WED will check for each DrapedOrthophoto if an image file or a .pol definition is referenced. For image files (like in this example - we placed the image file) it will check for a matching .POL definition in the same directory as as the image file and create a .POL definition with all required entries automatically as needed.

After that, it will also look for a .dds version of the image file in the same location and create one as needed. It does that by rescaling the image to the next larger power-of-2 size for each side (but never larger than 4096 pixels per side) and convert it to a DXT1 (if no alphac channel was found) or DXT5 format. This .dds file is also saved in the same directory as the image file.

You are now done with all steps to see the image as draped ground texture in XP.

On subsequent Export Scenery Pack runs WED will re-check for the presence of the .pol and .dds files and not re-do this conversion, unless you delete the .pol or .dds files.

8. Remove the original .TIF file (optional)

This step is completely optional and only desirable if the original GeoTiff (or whatever other non-DDS format file was used for the Orthophoto) is to be deleted from the directory, while still allowing to use WED to further modify the scenery.

Select the DrapedOrthophoto and edit the "Resource" property which refers to the image. Change the resource name suffix from .tif (or whatever it used to be) to .pol.

Now WED will immediately start using the .pol and .dds files it created to display the image in WED - rather than the original image file. This does not change the scenery created upon export in any way, but allows you to remove the original image without loosing the display in WED.

9. Clean up and final improvements

If you load X-Plane, you should see the tiles in your scenery!

The images may have a hard edge, though. To solve this, open the images in your favorite image editor and feather the tiles where it makes sense. In my latest airport, I picked the roads encircling the airport as my cut-off for the overlay images, so I deleted everything outside of those roads and feathered the edges:

http://i.imgur.com/mGnaXBV.jpg

You can also, at this time, perform any other image improvements. I did a lot of color correction, contrast / brightness changes, etc to get the images to more closely resemble the surrounding auto-generated scenery:

http://i.imgur.com/ful5HsY.jpg

A new version of the tutorial series is under construction. There have been too many updates, added features and new assets in X-Plane since the last version was made - sometimes creating more questions than answers... so I felt a new tutorial series is in order with WED 2.1 and X-Plane 11.33 as the baseline.

Stay tuned, Jan

Keep in mind - road networks were not intended to be "edited", but rather only automatically created for whole DSF tiles from OSM data. So many things seem awkward and limited - that's not WED's fault ... there is lots of "intelligence" (or the lack thereof) inside the sim that creates the exact tull detail from the basic shapes you define in the sctual scenery file. So expect that many attempt sto force certain details will mostly result in the designer cursing - not the sim showing exactly what the designer wants.

This 17 minute video shows how to "edit" the roads that originally exist in the XP11 global scenery and replace them by a modified network that is part of a regular overlay (airport or off-airport) scenery.
 

Get it from the official WED website (might not yet be updated to reflect is stable/final)  WorldEditor (WED) - X-Plane Developer

CHANGE LIST

=======
WED 2.5.1 r1 3/20/23
   Bug fix:
   - WED-1461 fix align function
   - relax some ATC network validations for non-gateway use
   - age pavement function now transforms all XP11+XP12 pavement types
   - fix apt.dat import warning mesaage not showing for XP12 Global Airports
   - WED-1463 fix 'Import Roads' missing some roads

WED 2.5.1 b1 3/2/23
   Bug fix:
   - WED-1454 fix slight shift in world map layer at high zoom levels
   - skip placeholder images ESRI is sending for unavailable slippy maps
   - fix crash with some line type facades that go exactly E-W or N-S
   - WED-1459 fix false positives in runway name validation
   - WED-1455 support case-sensitive filesystems on MacOS
   - use libcurl.so.4 rather than libcurl.so on Linux
   Features:
   - show 10x10 DSF directory names at intermediate zoomlevels
   - WED-1179 support for APAPI (2-light PAPI) starting with X-Plane 12.04
   - XPD-13789 new meta tag is_oilrig, created automatically during GW export heuristics

== end of changes ==

The ATC and Ground Vehicle routes are intended to get traffic close enough to they destination until the XP built-in logic can taxi the vehicles to they final destination as needed. The example above has two problems:

1) The arriving AI will follow the network to the exat point that is closest to its ultimate destination, i.e. the ramp start here. I marked that point bright green. At that very point it starts moneuvering on its own, obeying the actual turn radius specified in that aircraft's flight model. But on the left side - the aircraft would have to turn within a few feet, which the flight model says it can't. So it simply turns only a little bit or goes around in some strange wide circles and come to a rest at the ramp start on a completely different heading.

Ground traffic is better at orienting itself at the parking position - it can and will make tight turns right behind those position to come to a stop at the eaxct right heading - even if it came in from some other direction. But they still need *some* room to maneuver between the taxi network and the destination.

2) While on the network, the "best" route is calculated by taking into account the number of turns that route requires and how sharp these turns are. See https://developer.x-plane.com/2012/01/atc-taxi-layouts . In above image I marked the specified route in purple - its absurdly disorted and angled. So the AI algorithm might either completely stop routing that aircraft or take a very different route than intended.

In the example to the right I show what I verified the actual taxi pattern of the aircraft is. So how much easier to create is that ?

Excessive network detail can also cause AI to taxi along undesired routes, like here:

The A/C gets stuck because the taxi route is determined without checking for any obstruction along the way - that only happens one segment at a time ahead of the A/C. And ATC will not re-route once stuck, just wait it out.

Here is what to do instead:


Ontop of the excessive detail in the taxi networks - these ramp start positions are NOT causing plausible behavior in X-plane in the first place: this are de-iceing pads, normally no aircraft park there. X-plane AI does not have any logic to taxi A/C through de-icing stations prior to takeoff. Nor could any future X-plane version know that these are actually de-icing pads. So I'd rather omit these ramp starts and all taxi networks to support these completely.

Another frequent complaint is that WED's validation is overzealous in flagging "crossed ATC segments" or "Too sharp turns". Here is an example that creates numerous such errors:

The ATC network is not to trace some centerline markings on the surface. Its to "program" the AI system to get aircraft from and to the runway. Once its on the runway, the AI control switches to a completely different system and flies the aircraft, ruled by the AI aircraft's flight model. That switchover only works right when there is as few as possible taxi route segments on the runway except one: The blue "runway segment". That's also why WED validates that blue segment to be very straight (no sudden turns) and close to the centerline of the runway as possible. If you break it up into short segments, you have little chance to line them up to meet that "straightness" criteria.

At intersections there is since ~XP11.40 no need any more to draw extra segments to "round the turn", as the ATC logic will automatically use a optimized radius to make turns - and that radius is A/C size and taxi speed dependent. That is a MUCH better thing than forcing a turn drawn as many, separate steps: If you get the effective radius of that turn not exactly constant - A/C will take the turn at very slow speeds and "stutter" around the corner. Here is an example how at most a single 45 degree segment should be used to make very wide and still perfectly round turns.


So, in short:

Do not put ATC taxi routes where you don't want AI to taxi - as such obsolete routes can lead to surprising taxi behavior:

The departing aircraft here correctly heads to the nearest taxi network location - but its not the one the author intended ... So why draw that taxi route if there is really no valid reason ever to taxi on that old defunct taxiway ? This is a taxi network where the ramp start is set propperly to type "gate" - the aircraft push back and taxi the obvious way:

Ground traffic is routed with the essentially same algorithms as aircraft - which includes avoiding sharp turns etc:

There is really no point for the traffic routes to those areas in the north here - there are no service vehicles parked there, no destinations, no ramp starts for any aircraft to ever be serviced.

Last - also put in enough taxiways so that the "nearest" taxiway isn't behind some obstruction - in the example below the vast majority of aircraft will plow right through the terminal building or the airport grass in between the taxiways:

Summary - the goal here is to "program" the AI system with the preferred routes. The AI system can in most cases not tell non-plausible, obsolete or rarely used routes from the ones where you want it to go.

More examples of what (not) to do can be found at https://developer.x-plane.com/manuals/wed/#specifyingservicevehiclenetworks and

Most in this post also applies to ANY polygon and any taxiway as well, in particular point 3):

1) Every polygon is at scenery load time aproximated by a potentially huge number of individual triangles. As any graphics engine can only display triangles ... So a ground sign letter placed as one rectangle creates exactly 2 triangles. But more complex shapes may require many more, in particular if bezier curves are involved. Every bezier curve is approximated by X-plane with a number of individual straight segments, then filled with triangles:

Creating custom fonts or similar with a patchwork of carefully crafted polygons can easily create thousands of triangles for just a single word. That is about as much of a GPU workload as all taxiways of a medium sized airport together.

2) The visibility range (LOD distance) for the draped sign polygons is as far as the airport is loaded - potentially dozen of kilometers. So the framerate-saving mechanism of not drawing small objects when they are too far away to be noticeable won't help here at all. This is because the visibility distance is set by the art asset - for the purpose and typical physical size of an item the asset was made for. So if you draw a ton of tiny things instead of a single big one with it - there is a mismatch.

3) Small scale items (1m/3' or smaller) created this way will suffer from notable distortions due to the way lat/lon coordinates are compressed in the DSF files. These variations are in the order of a couple of decimeter or a several inches, which is for all other X-plane scenery purposes pretty much negligible, but may become a big problem for small items like this:

If bezier curves are involved - these are usually affected much more as visible in the above example. Small changes in bezier handle headings can multiply over the total length of bezier segments, as these are typically much longer than the handles.

The effect is also not constant, but varies depending on other data content in the same .dsf tile. So what you might get by on your single airport might look worse in the Global Airports, where multiple airports will be in most every tile.

4) The exact part of the texture visible depends on the texture resolution setting. If the edges of the UV coordinates in the TCE window are set too close to a change of texture color, there may be "color bleed though" which looks ugly at lower texture resolution settings:

So as much as I understand the desire for high degree's of detail - please use appropriate technique. Or as Ben worded it - don't paint with polygons.

On the scenery gateway the moderator (and soon WED's validation, too) may pose significant restiction's on what should be done with these uv mapped polygons as well as small, highly detailed polygons in general.

Changes since RC1: a new validation and three changes to adapt to changes in the Laminar libraries that ocurred during the 12.00RC5. This should restore full functionality in the "Convert to" menu function and fix issues with the update heuristics when exporting to the gateway target.

Get it here:
https://dev.x-plane.com/download/tools/wed_win_250r3.zip
https://dev.x-plane.com/download/tools/wed_lin_250r3.zip
https://dev.x-plane.com/download/tools/wed_mac_250r3.zip

Note - seasons, sounds and weather effects are NOT defined in overlay scenery, but by the art assets used. So WED has no functionality for any of that. There are a number of improvements for designing with X-Plane 11 or older, though, so WED 2.5 can be helpful for X-Plane 11 designers as well.

But keep in mind, WED 2.5 nor X-Plane 12 are NOT (yet) acceptable for gateway submissions and there is no full backwards compatibility, i.e. the sceneries will at a minimum loose new X-Plane 12 parameters or features when opening the design later in WED 2.4 or older.
Exporting full featured X-Plane 12 sceneries from WED 2.5 to X-Plane 11 export target is fully supported, though. So when adding X-Plane 12 only features like new runway markings or surfaces, WED 2.5 will automatically map these apt.dat items to the closest alternative that does exist in X-Plane 11. Just as it does with the (back then) new XP11.30+ only lines styles for older export targets. Taxiway pavement may not be that dark asphalt any more - but its still asphalt and a working taxiway. Or docking jetways will still be static jetways. So full custom designers mostly relying on 3rd party libraries (which I presume are available for X-Plane 11 and 12 with the same vpaths) should be able to just re-export their unchanged X-Plane 12 designs with an export target of X-Plane 11.30 and get fully working X-Plane 11 results in no time at all.

New features relevant for all X-Plane versions

Gateway Export w/upgrade heuristics 

The "Export to Scenery" or CTRL-B for the gateway target (and ONLY for this one export target) now automatically applies all X-Plane 12 auto-upgrades done at Laminar when cutting the Global Airports. E.g. adding terrain FX / mow grass, upgrade old-style jetways to facades etc. So the exported scenery will for gateway artists simulator look exactly as it will look when its included in the next Global Airports.

This will benefit artists that choose to NOT manually mow their own grass etc for X-Plane 12 submission to the gateway, but rather continue to rely on the upgrade heuristics run at Laminar when the Global Airports are created. Which is absolutely fine to do !  It has the benefit that after e.g. changing some taxiways or taxis signs there is no need to correct all the grass mowing and concreate patches to fit the new pavement shape.

But these upgrade heuristics also come with a caveat; If any submission includes a single or more items from the "Terrain FX" categorie, the associated auto-upgrades are NOT run at Laminar for that airport. The heuristics will conclude that the artists already manually added his own flavor of Terrain FX and the heuristics are to NOT touch that airport any further in this respect. So if an artists accidentially adds such an terrain FX item despite intending to rely on the upgrade heuristics at Laminar - he will now see the somewhat tragic consequences of his actions when viewing his scenery in the simulator.

See also further down here the section on the Airport->Mow grass function.

Map projection, improves relative position accuracy in map view at higher lattitudes. See the nitty details at

More capable Edit ->. Split function
When splitting polygons, the cut can now go into holes.

More capable Edit -> Convert function
Airport line markings with multiple line styles create separate lines or strings for each style and section, presving all features and shape exacly as they are.
A group of objects can be converted into forests in point mode, usefull to prepare XP11 sceneries using object-based trees for seasons and 3D forests.

Higher resolution ESRI imagery


View -> Terrain
This new layer provides non-editable information about the X-Plane Global Scenery terrain. It shows the actual terrain triangle structure and distinguishes water from land and smoothed airport surfaces. If the airport boundaries are still unchanged compared to what was used when creating the Global Scenery - the airport boundary should for X-Plane 12 exactly match the green colored traingles. For X-Plane 11 its a bit different - as the airport areas were oversized relative to the drawn airport boundaries. Its usefull to check if the boundary has been changed since for some reason:
This allows to e.g. precisely determine the coastline when drawing piers at seaports:

When zooming in further all elevation and other ancillary per vertex data is shown as well. But that is likely, for now, only usefull for hardcore terrain mesh editing folks or developers of base mesh terrain. Salmon colored are the raster DEM elevations. Elevations, if annotated near vertices are explicit height data overriding the DEM interpolated vertex heights. Blue numbers are the explicit water elevations and extra per-vertex data planes used for water depth and other 3D water rendering gunk.


New features relevant for X-Plane 12 only

New run & taxiway surface types.
Thre are now over a dozen differently colored asphalt and concrete types. Most of them come in new or older/worn/cracked looking styles.
All surfaces are also available as exact matching draped polygons.


There is also an addional "Plain" flavor for all asphalt types. These have no visible cracks, seams or other or directionality by themselves. These are intended to have decals from the lib/airport/ground/pavement_FX group added ontop of them - to support curved asphalt.


New runway parameters
Shoulders can now have a user defined with, markings can be in addition to FAA and UK also EASA standard styles. These have touchdown and distance bars at different spacings from the threshold. And a different chevron width on blastbads.
Finally - in X-Plane 12 runways do not get red/green threshold lights forced, if there are no other center or edge lights specified. So rural "no electricity at all" airstrips are really totally dark at night. In the rare cases where a runway would have no edge or any other lights (call it a runway without any sign of electricity), but the threshold light should stil be kept as they were in X-Plane 11 - there is a new option under "REIL strobes" to keep the on.

Auto docking jetways
Auto docking jetways require no changes byt changing the export target 12.00, if the jetways are already drawn using the jetway facdes.

For older, pre-terminal kit sceneries that have jetways created by a chain of individual objects, there is a new menu function Airport -> Upgrade Jetways to automatically convert these into jetway facades. For gateway airports this upgade isn't strictly required, as all older airports that don't use jetway facades yet, get automatically upgraded when the Global Airports are cut. But sometimes that auto-upgrade does not result in the best jetway placement - so if a gateway airport is submitted for X-Plane 12 anyways - its nice to run this function and get it all dialed in perfectly before re-submitting. See alao

Custom auto-docking jetways and airport service vehicles
This an option to make full custom 3rd party jetways auto-docking or specify full custom 3rd party vehicles for the airport service trucks.

Preview 3D forests
This does nothing to the scenery itself, forest are still just forests. But the preview is now switchabe to check out the full 3D trees shown close up vs the panel-mode 2D trees show at larger distances in X-Plane 12. Of course - only if the library happens to include 3D tree models.

Airport -> Mow Grass
X-Plane 12 Global Airports that have ZERO decals from the categorie lib/airport/ground/terrain_FX/  (i.e. that are still plain old X-Plane 11 designs) in it get automatically upgraded when cutting global airports by adding gmoved grass lines in a pavement aware shape around all runways. Plus concrete patches underneath all taxi signs. And its only done around paved runways.
So in many cases it might be fine to NOT draw any of this manually, as it likely would have to be modified every time a run or taxiway gets modified in shape; The mowing tractors turn around at or follow pavement edges and the auto-upgrade nicely mimic that. But, there is a millions ways to mow your lawn and the gateway fully supports that. So short of drawing all that "grass art" from scratch, the same auto-upgrade can be applied via this menu function and then used as a starting point for further manual modification.
As the auto-upgrade at Global Airport export is only run when there are ZERO items from the Terrain FX categoeies present, placing a single unconspicious item like small concrete can inhibit the autmatic grass upgrade, if so desired. See also

Additional library browser info
There is a column with icons that indicate if any vpath include multiple variants (ble test), seasonal objects (leaves) or regional varying art (purple text). All these things are NOT something scenery designers can specify or affect in any way. But it helps figuring what items you want to place or avoid - like vegetation objects that don't (yet) support seasons.

After that there are a few more menu items still greyed out - these don't work yet well enough for general use. These will be documented and enabled shortly - but its all secondary nitty-gritty stuff.

Complete WED 2.5.0 changelist over WED 2.4.1

WED 2.5.0r3 1/7/23
   Features for all X-Plane versions:
   - validate excessive long airline strings at ramp starts
   Bug fix:
   - fix heuristics for gateway export to reliably detect presence of terrain_FX items in scenery
   - change run/taxiway textures to hardcoded map to isolate against X-Plane library changes
   - prevent conversion to taxiways/airport lines for entities outside airport hierachy's

WED 2.5.0r2 12/21/22
   LR internal use only

WED 2.5.0r1 12/23/22
   Bug fix:
   - fix Linux w/Mesa driver not showing Library previews
   - enable KTX2 loader
   - fix ATTR_layer_group ordering for offsets of +5 and larger
   - add one digit precision to tower viewpoint height selection
   - fix regression in gridded preview not always showing all entries
   - WED-1444 improve facade preview offsets from exact locations as shown by structure lines
   - validate meta tag "Country" to be free of extraneous prefixes created by earlier betas
   X-Plane 12 features:
   - submit roads tag to gateway to support special moderation

WED 2.5.0b5 11/27/22
   Bug fix:
   - rendering objects with LINES followd by TRIS in the same LOD caused artefacts
   - fix library list non-expandable items, missing 2nd column on macOS
   - fix white-out in preferences window on macOS
   - fix shading in library preview pane
   X-Plane 12 features:
   - apply the scenery gateway upgrade heuristics when exporting to scenery for the gateway target

WED 2.5.0b4 11/21/22
   Bug fix:
   - some meta data validation messages spelling out wrong names
   - add missing texture for light colored gradients to linux binary
   - fix object rendering for objects with l2D ines, e.g. the baloon.obj
   Features for all X-Plane versions:
   - walk back new facade validation to warnings only for the GW target 
   - let facade height validation pass single-height and low absolute height items, e.g. fences
   - add green groundplane for preview of adjustable height .agp
   X-Plane 12 features:
   - Object scaling in map using WGS84 ellipsoid for improved large object location accuracy.

WED 2.5.0b3 9/3/22
   X-Plane 12 features:
   - add meta tags for ATC fisa and closed circuit ops
   Bug fix:
   - some moving jetway objects not upgraded by GW heuristics 
   Features for all X-Plane versions:
   - auto-upgrade country meta tags ISO3366 code upon import from gateway

WED 2.5.0b2 5/30/22
   Bug Fix:
   - fix .agp scraper display mismatch for some heights
   - fix gridded preview for 3D objects only showing partially on OSX w/AMD graphics
   - WED-1390 fix crash in preview window for .net definitions that reference no textures at all
   - improve GW export heuristics to prevent non-ICAO code airport ID's to be taken as ICAO
   - don't break apart AGP's referencing objects by relative path - those are not public
   - reduce residual heading error for draped polygons by rounding, not truncating at DSF export
   - WED-1413 ATC route validation escape for runways NOT starting with a leading zero
   - WED-1412 fix horizontal distortion caused by map projection in 3D preview
   - validate zero-length segments to 0.1m (apt boundaries to 30m), rather than exact colocation
   X-Plane 12 features:
   - moving default and custom jetways (requires propper jetways .fac w/metadata)
   - runway & taxiways surface styles and markings
   - seasonal objects, showing summer version only
   - preview 3D forests
   - increased precision for draped polygon headings
   - custom airport service trucks
   - validation warning on runway lighting combinations not supported by XP12
   - allow road networks near airport boundaries on the GW
   X-Plane 12 art asset conversion features:
   - jetway objects to jetway facades
   - X11 default pavment to XP12 aged pavement
   - add mowed grass FX based on airport boundaries, runways and pavement
   - add concrete patches under taxi signs
   X-Plane 12 global airports heuristics:
   - convert jetway objects to jetway facades
   - mow grass if no Terrain FX at airport
   - limit to ONE active jetways per ramp start
   - nuke most terrain polygons
   - nuke all grunge objects
   - add regional presets for ramp starts without assignments
   - add iso3166 country codes to 1302 country meta data
   - fix XPD-12676 several chinese airport ICAO codes missing in Global Airports
   - remove road, beach, line exclusions, grunge objects, flatten meta for GW airports < 95000
   - convert 2D only deprecated AG_*.for to current non-deprecated/3D forests.
   Features for all X-Plane versions:
   - use full projection for map display to improve location accuracy of linear features
   - bump resolution for ESRI slippy maps below 60 deg lattitude by one ZL
   - validation warning on TOWER_VIEWPOINT height not matching with #viewpoint_height tags
   - use actual XP textures for run/taxiway and helipd previews in map, if available
   - apply jetway upgrades, remove large terrain polygons at export (tyler_mode only)
   - add 3-letter iso3166 country prefixes to airport meta data (tyler_mode only)
   - validation exeption to make KSEA, LOWI gateway legal
   - validate taxiways for zero-length segments
   - show multi-layered forests correctly in the preview window
   - show ATC tower airspaces in Navaid layer
   - LibraryList has icons indication seasonal/regional variants exist
   - WED-1161 (limited) ability to collapse search results in LibrayPane
   - new map layer "Terrain" visualizes terrain mesh structure, DEM and explicit height vertices
   - menu function 'convert to' now covers object strings and forests'
   - menu function 'convert to' can convert airport lines with multiple, differing markings
   - speed up road display to handle full DSF tiles of roads by adding a caching layer
   - menu function "split"" can now cut into holes in polygons

 ** end of changelist **

WED 1.7.1 also has support for on-map preview and selection of all those for taxilines just like all the other line types we already have. But - some of the required support in XP is delayed, to be included in the second beta XP 11.25 beta 2, hopefully coming out by the end of this week. Ben was interrupted to fly to the fsexpo in Vegas last weekend.

To allow us crossing a few more T's WED 1.7.1 will be made available, right here, together with the XP 11.25 beta 2 once this is all sorted out. Please hang in ....

• validation NOT finding some incorrectly tagged runway (blue) ATC taxi segments on some runways
• 3D preview window getting unresponsive or uncontrollable on some Linux/OSX machines, in particular after re-opening already existing scenery
• gridded library preview being garbled (OSX) or outright missing (certain AMD drivers only, on all OS) for some objects

The 2nd release candidate adds validations for the gateway, only, to prevent more .obj depicting tree's and explains that only forests (in either area, line or point mode) are to be used instead. All existing Laminar tree .obj in existing gateway airports will get auto-autograded to some generic forest tree, though. So there is little point of submitting airports for the sole purpose up upgrading tree's to forests.

Get it here:

https://dev.x-plane.com/download/tools/wed_win_241r2.zip
https://dev.x-plane.com/download/tools/wed_lin_241r2.zip
https://dev.x-plane.com/download/tools/wed_mac_241r2.zip

Because of the validation escape being particularly relevant for the upcoming XP12, we expect the scenery gateway mandating to use this version for new submissions within a matter of days.

Ontop of the hierachy pane is a search box - one could enter a WED item name like "Unnamed Taxiway" or just "Taxiway" and it would only show all items with that expression as part of their name. Clicking the top line of the item list and shift-click the last entry would select all:

After that a new line type an be selected for the column in the "Property Pane" on the bottom. If the "Command/Control/WIndows/Alt key" (depends on the operating system) is held during that click to change the selection, ALL selected items are changed to the exact same setting. So ALT-click is the same as ALT-enter when e.g. entering a numerical parameter - the change is applied to all applicable columns in the property pane. So that works fine for Runway Hold lines, *IF* the items were given suitable names by the original author.

But Line Markings are more complicated - some have some sections set to a particular line style, other sections may be blank or have a different style, so selecting the whole Line Marking and make ALL of it wide yellow isn't so good. One would still have to select all applicable vertices by hand to only change the parts of the taxiway that had e.g. a narrow yellow centerline and make that wide. Otherwise you'll end up like this:

Since WED 1.7 the hierachy filter can not only find names, but also line/light attributes. Here is the line style selection pane that shows those names:

So lets select anything with "yellow". Good thing we didn't name the apron "Yellow Zone", otherwise it would be caught in our search, too. So never seach for "taxi" - almost any item has that in its name:

The nice thing is - the vertices for blank segments are *NOT* selected, neither are the "ILS critical" parts. As these don't have an attribute with the word "yellow" in them.

But its still not perfect - the southern markings are black outlined, i.e. linestyle "Solid Yellow (black)", as opposed to "Solid Yellow". So we only want those styles that end right after "yellow". In the Unix world - there is a symbol for that: $, it denotes the end-of-line in expressions. Similar ^, the beginning-of-line. So let try that - all yellow lines NOT ending in (black):

Voila select, ALT-Click and all done. All narrow yellow lines are now wide ones. We can do a second search for "Yellow (black)" and convert those into propperly black outlined wide lines.

In summary:

The new hierachy filter matches either the name OR line/light style attribute of any Airport Line Marking or Taxiway.

In WED 1.8 it will also match the "Resource" property for items that have such - so ".fac" gets you all facades in the scenery.

"Yellow" filters anything with that word anywhere in the name or attribute

"Yellow$" only matches things ending in "Yellow"

"^Red" would match anything starting with "Red"

"^ILS Hold$" matches the single word "ILS Hold" in the name or attribute. Anything that has any letters before or after that won't. This is at times required to get rid of items that are named like "ILS Hold 12/30" if one really only wants to get vertices with the attribute of "ILS Hold".

Weather (snow, ice, rain puddles), seasonal and environmental sound effects are not defined in overlay scenery at all, so WED overlay scenery designers do not need to, nor can they do anything about these effects. All that data comes from the libraries and art assets used plus the base mesh scenery, only. So in WED and as far as scenery design goes - it continues to be "always dry, sunny and summer". Only once the scenery is run in X-Plane 12 these new effects are visible - if the libaries used have these effects. Needles to say all sceneries using Laminar default libraries, only, get get a full set of all effects automatically - as those libraries have all been fully upgraded,.

3rd party libraries and full custom objects will need to be to have weather masks added to show "wet" or "poddles", but some basic snow depiction comes automatically, though.

A few new X-Plane 12 features require upgrades to existing scenery files before showing up in X-Plane 12. WED 2.5 supports all these and also has several new functionalities to help applying these "upgrades" to existing sceneries very quickly. For the global airports shipped with X-Plane 12, most of those "upgrade heuristics" are automatically applied when that scenery is created from the existing scenery gateway data base. So there is no need to change most of the airport on the gateway to look good in X-Plane 12.

But - without X-Plane 12 and its libraries, none of that can be seen or tied out in WED. The files created by WED 2.5 will in some cases not be readable fully by WED 2.4. Submissions to the scenery gateway with X-Plane 12 and WED 2.5 will only be open for the general public after XP12.00 is declared final, i.e, not very soon.

This is why WED 2.5 is for now only made available to the early alpha and later on to selected X-Plane 12 beta testers. As it is of little use at all for anybody else to justify any support efforts. WED 2.5 has been released since. Get it at WorldEditor (WED) - X-Plane Developer

I will over time add a few articles to this post that explain some of these new features and techniques to upgrade existing sceneries. I fully expect some of these will require good working knowledge of designing X-Plane 11 scenery to be intelligible in the first place.

You have drawn a taxiway, polygon or other area-type feature so that its outer perimeter line is crossing back over itself:

This will causes in WED as well as in X-plane the texturing of the feature to disappear.

Often these self-intersections are caused by curved / bezier segments, which may result in crossings in very small areas only - which are not only hard to see in WED, but be may cause WED zoom or X-plane rendering setting dependent loss of texturing or may appear differently in X-plane vs WED.

It is usually fixed by pulling back a bezier handle just a little bit, so to not point 'out of' the polygon any more.

Road editing
Road networks can now be edited and exported as part of overlay scenery, including automated import from XP11 global base mesh scenery (or any other base mesh scenery).All network types and subtypes including railways and power line networks are supported.
Much of the code for this feature goes back to Ben Supniks initial iattempt on this, dating back several years and now peddled steadily forward by Mathias @mroe.

Road editing goes a bit different than most other things in overlay scenery - road networks were after all never intended by Laminar to be "edited" or even created by humans.So please take 17 minutes and watch the video tutorial at Road editing video tutorial - x-plane.org
Also note - the current support in X-Plane to merge these networks with the existing ones in X-Plane has a few gotchas and a future X-Plane versions will improve on this. Until then - road networks are not (yet) eligible for gateway scenery submission. Once Ben greenlights the X-Plane side - the gateway will accept these networks as part of airport sceneries.
For base mesh or whole dsf tile overlay "autogen" as shipped by most 3rd party vendors - the WED editing support should be complete and ready to use, though.

Autogen editing

WED can now edit and preview autogen string (.ags) and block (.agb) assets. Although none of these resources are currently public items suitable for inclusion in new sceneries (the screenshot was created using a "hacked up" X-Plane installation) - the feature can right away be used to understand how exclusions zones work for these autogen buildings and trees:
Import the Global Scenery DSF tile underneath your airport - it will now show all forests and all autogen areas in it. In the example - the selected autogen polygon will be entirely removed as one or more of its vertices are inside the exclusion zone. The brighter yellow side of the autogen polygon is where the buildings will be created. Theese markings are NOT to scale - as autogen buildings comes in awide variety of sizes and the exact choice depnds on a lot of context - too much for WED to precisely predict. The remaining lighter yellow area of the autogen polygons is usuially filled with sparse trees. So the tree's there are created by autogen strings, NOT forest polygons. Exclusion zones for forests are completly ineffective against any object created by autogen polygons !
Now you can also understand how "far" this autogen exclusion zone reaches - as the full extend of the affected autogen polygon is now directly visble. And yes, any forests in that base mesh tile are also imported with the same mtheod - so the need for forest exclusions can also be precisely determined this way. But usually excluding forests (more precisely: the objects they spawn - which just happen to depict trees, usually) is much less complicated by simply looking at the scenery in X-Plane: Forest exclusion don't remove the whole forest polygon, but only the items within the exact shape of that zone. No risk of "overreach" with those exclusions.

As there are no public autogen art assets available in X-Plane 11 - autogen can effectively not yet be included in gateway submissions. Once suitable objects are made available in a future X-Plane versions, they will immediately be available for gateway use. But for editing 3rd party overlay sceneries, these frunctions are already fully useable.

Understand Exclusions zones

WED's new auto-import function for roads and autogen can also be user to thoroughly understand how to draw exclusion zones in sceneries, even if these to not add these items. I'll have a video tutorial for this up shortly here.

Free-camera 3D preview window
WED now has a real-time 3D preview for the scenery using a dediccated window. You can view the (most of) scenery from any perspecitive you want and it follows you editing in the map window in real time.
This feature is the brainchild and sole work of Martin @YawString, our newest WED contributor:

The map can be controlled by the mouse similar to google earth (drag, and CRTL-Drag) as well as X-Plane like hotkeys  (comma, period, arrow keys, plus SHIFT / CTRL to speedu up / slow down movement)..
Aslo some items have just like in the editing map no 3D previews, yet (forests, autogen, roads).

Library pane gridded directory previews

When selecting a 'directoty' in the library pane - small, gridded previews of ALL public items in that directory are shown. A single mouse click selects that item for placement in scenery and shows the full detail information as already available before.

Draped polygon selector

There is a new virtual' property "= Taxi Surface" for all draped polygon entities. It indicates if the currently set resource is the exact equivalent of one of the X-Plane default run-/taxiway surface textures. It works the same way as the virtual property "= Line Marking" introduced with WED 2.3 for all Lines. It also allows to directly pick the right resource when an exact match for any of the default run/taxiway textures is available and desired.

Improvements for first time WED users
When opening a scenery package with no earth.wed.xml file preset, it shows a list of meaningfull actions to get started with editing scenery. Not just that timeless oh-so-elegant pitch-black empty screen.

Improvements for frequent WED users
WED now remembers the last scenery opened in WED and re-selects that package upon starting - so it can be re-opened by a single click on the "open" button or the <Enter> key.
When creating new/empty sceneries, WED will remember less and always use defaults for some infrequently used settings. E.g. it will start with  "most current X-Plane version" export target and "Visibility/Showlevel default/all" - so there is (hopefully) less confusion for users that get suprised by some "weird' setting persisted into their new, "clean" scenery. Once a scenery has been saved, WED still remembers everything exactly as set, though.

CHANGE HISTORY

WED 2.4.0rc2 5/29/21
   Features:
   - Undo WED-192 remove meta tag "Closed", validate correctly formed [X] in apt name
   - improved automation for cutting the Global Airports
   - renamed gateway import "Checkout until" into "Locked by" for consistency

WED 2.4.0rc1 5/8/21
   Bug Fix:
   - move forest layering in map to above polygons, below roads/objects
   - fix distorted previews for lines with ALIGN and END_CAP attributes
   - WED-1380 clean out orphaned road nodes from .xml database
   - WED-1374 improve libcurl compatibility on Debian/Linux

WED 2.4.0b2 4/13/21
   Bug Fix:
   - fix scaled down window contents on OSX Big Sur with Retina displays
   - disable MSAA for library previews on all Retina macs
   - fixes to editing/splitting/merging closed road loops
   - notable speedups on startup time and in map window when many items are selected

WED 2.4.0b1 3/30/21
   Features:
   - WED-120, 306, 380 edit road networks incl. basic on-map previews
   - true 3D scenery window
   - edit autogen .agb/.ags (but no on-map previews)
   - gridded previews for library pane directories
   - support choosing taxiway equivalent styles for draped polygons
   - preselect last opened scenery at startup
   - show on-map 3D previews for beacons, windsocks, 3D taxi signs
   - use native secure internet connectivity on all operating systems
   - WED-1359: change OOW mouse click for LineEditor from accept to cancel edit
   - automatically change ExportTarget at GW import, avoid inheriting unexpected values
   - support import of text format DSF files
   Bug Fix:
   - Partial fix of long standing OGLE bugs
      - disappearing content when select numeric edit fields,
      - mess with vertical scrolling,
      - errors in multi line text edit fields like in Gateway export dialog
   - WED-1353 GUI_ScrollBar has uninitialized variables
   - WED-1347 stops cursor blink timer in Settings window when loose focus
   - validate ICAO_Code meta tag to meet ICAO nomenclature
   - fix preview for .lin commands with offset layers in preview pane
   - fix endcap not showing for lines with two vertices only
   - refine tesselation to show fill for polygons with colocated nodes
   - XSG-11489: Fix gateway flags for airports with odd ATC taxi/ground_service routes

** end of changes **

The taxiways are only drawn to the shoulder edge, NOT to the runway's edge. This causes

Here is how to avoid this:

This looks so much better ...

Note the taxiways are automatically drawn above the shoulders and below the runways - for a good reason ! The line markings are drawn above all of that - so keep them from showing up on top of the runway edge paint.

A long standing X-plane scenery limitation also requires that taxiways MUST NOT be set to "transparent" to work the way it is described here.

On the other extreme - DO NOT draw taxiways where aircraft are NOT supposed to taxi - in particular not along runway shoulders:

In above example the runway edge lights are replaced by recessed lights on side of the runway, but not on the other. Recessed lights have, very much as in real life, a much narrower viewing angle and limited light output. Over here, this makes the two runway side being lit very differently - something that in real life is being avoided at all costs. So avoid drawing taxiways anywhere near runways where any edge, end or approach lights may be located, unless this is done very deliberate to recess those lights for valid reasons.

WED orthophoto tutorial - YouTube

Disclaimer: These pictures are intended to be motivational - don't expect orthos to turn every airport into a paradise 😉
But it took me half a day to make this from start to finish, including recording the tutorial. So you can do it, too !

Windows: http://dev.x-plane.com/download/tools/wed_win_230r2.zip
Linux:    http://dev.x-plane.com/download/tools/wed_lin_230r2.zip  
OSX:     http://dev.x-plane.com/download/tools/wed_mac_230r2.zip

Note for Linux users:
WED is now using FLTK rather than being a Qt app - it should run on all linux distributions published since ~2016 upto and including Ubuntu 20.04. You may have to manually install the package "fltk13-gl" or "libfltk-13" or whatever the "FTLK library version 1.3" is called in your universe.

The key new features in this release are

- the ability to visualize how Aircraft taxi from the taxi network to ramp starts (yellow dash-dot lines) as well as how Ground Vehicles approach Aircraft from the nearest Road network (white dash-dotted lines)

Note how aircraft as well as service vehicles don't approach their desitinations (the ramp where they park or the doors on the aircraft they service) directly. They rather go first to some special "outer marker" like location, shown as the little circles, and then continue from there on to the final destination. This ensures that they approach from the right direction.
They leave the Taxi/Road networks at whatever location is nearest to these "outer markers' - even if that means going straight through buildings or across open terrain ! The AI logic currently has no  visibility of ANY scenery but the taxiroutes and ramp starts. The exact location of the "outer markers" also varies a lot from one aircraft to the next, so often there is more than one answer to what is that "nearest road". WED tries to give some crude feeling for that uncertainty by drawing in some cases TWO lines from these separate road locations towards the "outer marker" to indicate that the 2nd-closest option is within this uncertainty. But be warned - this no exact science by any ways. Move the aircraft around a bit to get a feeling for which direction the routes snap - avoid placing roads where they would lure the AI vehicles right through walls or worse. Or add a road to give them something that is by a sufficient margin closer than all other roads in the vincinity.

- several new validations target dis-functional ATC taxi networks

* All ATC taxi networks must be a single network - there can be no disconnected parts. Road networks can be multi-part, though.
* All arrival/departure taged segments (red) must be connected to something else, can not dead end.
This is a requirement to prevent dead-locks in the ATC system when taxiway exits end as "red" segments on the apron - as any aircraft getting initial taxi instructions while the runway is "hot" can't even enter the taxiroute system. It additional will prevent gaps in the most critical of all places like this:

The transparencies of ATC routes have been adjusted to allow for better visibility of snafus like this 'not-so-high-speed" turnoff which has two near 90 degree turns just a few meters apart. No aircaft, not even a C-172 could follow such tight turns, so effectively this route will never be used:

A couple of existing validations were fixed to prevet validation escapes as well.

- "set_AGL" for objects

This allows to position scenery object (and only these) at elevations relative to the ground level. This requires XP11.50  and is a much better option than the long existing "set_MSL" option. But its also not a cure for everything: If the ground slopes and this feature is used to e.g. place small objects on the roof of large buildings - these objects will still slope with the ground, i.e. they will NOT align with the roof of that building. So its use is still problematic for gateway airports and should be used VERY sparingly. Sceneries using it are also NOT fully backwards compatible with older X-Plane versions - they run w/o any error messages, but all set_AGL objects will not show at all. The old "set_MSL" is now prohibited from being used for the gateway.

As this is a feature unknown to older WED versions - WED 2.3 created or edited .xml files are NOT SAFELY USEABLE IN OLDER WED VERSIONS. All set_AGL entries will be misunderstood by all older WED versions. You will get an explicit warning message about possible data corruption when opening sceneries saved with WED 2.3 in all previous WED 2.x versions. If you open these in even older WED 1.x - no messages nor warnings, only unpredictable corruption or worse will result.

- a higher quality preview window

Anti-aliased, shaded and using a more natural perspective view, .agp items now also show facades  included in them, like fences around buildings

- WED now creates a logfile

This file WED_Log.txt is being written to the same directory where the WED executable file is located. Its header is very simular to that of X-Plane, PlaneMaker and AirFoil maker. Its contents are NOT intended for users to learn anything from - but it helps WED developers to help pinpoint problems with WED. Sincne this file is overwritten with every new start of WED - its important to close WED (if it hasn't already gone to software nirvana by then) and make a copy of it whenever a problem occurs.
So for future WED bug reports - this file is every bit as important as a concise description how to re-produce the erratic behavior.

See also the complete changelist:

WED 2.3.0r2 10/19/20
    Bug Fix:
    - fix Orthophoto export to only run if image file is newer than textures on disk
    - fix temporary files after gateway import not removed

WED 2.3.0r1 10/7/20
Bug Fix:
    - WED-1324: for XP1000+ targets export has_ATC in apt.dat rowcode 1 always as 0
   - fix validation for far-off-airport items to skip hidden items
   - fix OSX not resolving symbolic links at Orthophoto Import
  Features:
   - WED-1322: Validate apts w/ATC tower have at least one start supporting AI operation
   - Validate only type=misc starts in runway hotzones
   - improved logging of localization status
   - Linux version based on FLTK

WED 2.3.0b3 9/9/20
    Bug Fix:
    - fix facade roof object appearance in facade preview
    - fix facade roofs not showing in map without "pick walls" property
    - fix false warning opening pre-WED 2.0 files in WED 2.0+ after use of WED-2.3 beta
    - fix crash in ATC taxiroute runway segment validation
   Features:
    - WED-338: Write all messages and information to a WED_Log.txt

WED 2.3.0b2 8/26/20
   Bug Fix:
   - fix crash when viewing objects with lines in map
   - fix overzealous ATC taxiway name validations
   - fix some facade roof not showing as expected
   - fix ESRI slippy map not showing at very high zoom levels in some places

WED 2.3.0b1 8/24/20
   Bug Fix:
   - fix endcaps for bezier curved lines not following curve in map
   - fix validation not checking GT routes intersecting runways win some airports
   - WED-1277: make error messages when saving xml files more particular
   - WED-1294: support facades with single wall+roof texture
   - WED-1299: fix CTD in GW validation with orthophotos w/images as resources
   - WED-1311: fix holes in polygon incorrectly wound after "convert to"
   - fix some OpenSceneryX items not shown in library manager
   - fix DSF airport scenery not showing when Airport ID contains lower case letters
   Features:
   - WED-1293: show facades when part of .agp definitions
   - WED-1270: support gateway download driven by Airport ID list from external file
   - "Explode AGP's" can handle any .agp containing only public or local objects
   - validate ATC networks being fully connected and reachable
   - validate Hot-Zone tagged taxi routes not connected to other routes
   - validate all run/taxiways and rampstarts inside airport boundary (GW only)
   - validate all scenery within airport boundary bounds + 0.5 nm (GW only)
   - validate to prevent set_MSL and warn about set_AGL objects (GW only)
   - warn if taxi route name is unusual
   - show aproximate ground truck + AI A/C routes near ramp starts in ATC layer
   - XPD-9302,9240,9243 support "set_AGL" for objects available with XP11.50b1+
   - recognize keyword '#wed_text' to display text in preview window
   - speedup facade object drawing, same way as done for .agp
   - speedup validation for large datasets, for gateway use
   - use lighting and anti-aliasing in preview window
   - use full map projection, if available, with ReferenceImages & at OrthoPhoto import
   - support importing OrthoPhotos at half pixelcount for improved files sizes
   - support new XP11.50 earth_nav.dat format, fixes navaids missing in NAVAID layer

*** end of changes ***

Windows: http://dev.x-plane.com/download/tools/wed_win_231r1.zip
Linux:   http://dev.x-plane.com/download/tools/wed_lin_231r1.zip
OSX:     http://dev.x-plane.com/download/tools/wed_mac_231r1.zip

The beta had a bunch of extra logging for some yet to be pinpointed crash issues on some windows machines - so it would be good to use this in hopes to get a good WED_Log.txt on this. The .xml files are fully compatible with WED 2.3.0.

WED 2.3.1r1 12/22/20
    Bug Fix:
    - WED-1341 fix (linux only) uncommanded exclusion zone changes when canceling edits
    - reload Orthophoto at export when image has changed and new DDS were created 

WED 2.3.1b1 12/12/20
    Features:
    - support metadata 'closed', to be used by some future XP version, auto-created from [X] in airport name
    Bug Fix:
    - improve Log.txt completeness when crashing
    - WED-1332 fix (linux only) selection of ATC taxiroute runway tags
    - WED-1333 fix library preview visibility when AA settings overridden by video drivers
    - WED-1335 fix orthophoto's from windows created DSF re-imported on OSX/Linux using inorrect vpath separator
    - WED-1340 fix validation not recognizing all boundaries of an airport
    - fix false alarms in ramp start validation for export targets older than XP10.45

Windows: http://dev.x-plane.com/download/tools/wed_win_210r1.zip
OSX: http://dev.x-plane.com/download/tools/wed_mac_210r1.zip
Linux: http://dev.x-plane.com/download/tools/wed_lin_210r1.zip

The previews in the library pane can now be scaled in width and height by dragging with the *right* mouse key. Spinning the facade around with the left mouse key will show *all* facade wall types available (even if its more than 4 - its fun !) . The code used for the preview is exactly the same as in X-plane (one intentional excpetion for now: bezier curved segments) - so any idiocracies or limitations in the height scaling will show exactly the same way in WED as in X-Plane now. The individual heights officially supported are also listed at the bottom:

The ground (or water) level is shown as a translucent plane - to easier see "basements" of facades that support placement on sloping ground. Or to visualize the "height" at which some facade hoover above ground - as many terminal kit components do.

The map shows all above-ground facade components in real time, to help with facade placement:

New "2D" or "3D" meta-tag "GUI label"

For export targets of 11.30 or higher - WED 2.1 writes a new meta tag read by XP 11.35+, which tells the X-plane GUI to list the airport as "2D" or "3D".

Before XP 11.35, this column in the X-plane airport selection menu was simply assuming that any airport coming from *any* scenery in a users Custom Scenery directory is 3D, while airport in the Resouces/default scenery/default apt dat/ directory would all be 2D, only. But starting with XP11.33 ALL global airports, even those with 2D only layouts, are now included in the Global Airports - which caused the X-plane GUI to list _every_ airport as "3D".

WED 2.1 will at export time analyze the scenery for 3D content and look for the existence of a meta-tag "GUI label". If the export target is 11.30 or higher - it will warn if the tag is missing or impropperly set (i.e. ultimately leave it up to the designer how he want's the airport to be listed in X-plane). If the target is "Gateway", it will quietly create or update this meta-tag to always be correctly set according to the actual scenery exported - so gateway artists do not have to worry about this new tag, ever.

In order to set the listing as 2D vs 3D in XP11.35+ existing sceneries need this meta tag to be added manually via "Airport->Add Meta Data" and then re-exported to a target of XP 11.30 or higher.

Further changes since WED 2.0 are

WED 2.1.0r1 7/22/19
   Bug Fixes:
   - fix rotation lock acting on unrestricted/normals obj's

WED 2.1.0b2 7/11/19
   Features:
    - WED-1209: validate facades to include walls that exist in facade resource, only
    - increase number of facade walls supported to 40
    - warn if curved segments used in type1 facades
   Bug Fixes:
   - fix broken z-ordering for .agp previews in the Libary Preview Pane
   - fix crashes if facade file can not be found or is no valid facade
   - fix navaid layer locations of seaport and runway-only WEDbot airports
   - fix previews for .OBJ with upper case suffix filenames missing in beta1
   - fix facades with NO_WALL_MESH commands not treated as line-type facades
   - WED-1202: fix string preview not starting at right offset
   - fix apt.dat reading taxi signs with blank name, validate to be not blank
    - WED-1205: allow sealanes with or w/o W suffix to match sealanes in CIFP data

WED 2.1.0b1 6/3/19
   Features:
    - WED-1187: Make wide ILS critical centerline symbolic preview more specific
    - WED-887: Recognize keyword in .obj that lock the objects orientation
    - depict PAPI / VASI / WIGWAG's objects in preview layer
    - export to DSF for large projects 2.5x faster
    - memory size, import/load/save for large projects 35% smaller/faster
    - DDS texture compression for Orthophoto export multi-threaded, 3.5x faster
    - WED-1149: Improve download cache size management, reduces WED startup time
   Bug Fixes:
    - WED-1201: Fix typo in airline code validation error message
    - WED-1199: fix potential segfault when reading files
    - WED-1198: fix approach light depiction to start at threshold of runway
    - WED-1186: Make message box text in moderator mode more specific
    - WED-1165: Fix Slippy Maps not restroring mode from scenery files
    - WED-1163: Fix Error 66 when pressing "Enter" on new packages
    - WED-1162: Create new ground truck routes w/no aircaft (hotzone) attributes set
    - WED-524: Can't recover window if pack was saved on a larger screen
    - WED-432: Fix WED window positioning when using multiple monitors under linux

Its the offially released version now and accepted for gateway uploads as of today.

Windows: http://dev.x-plane.com/download/tools/wed_win_220r3.zip
OSX: http://dev.x-plane.com/download/tools/wed_mac_220r2.zip
Linux: http://dev.x-plane.com/download/tools/wed_lin_220r2.zip

Use the control buttons in the top right map window corner to 'tilt' the view angle:

Note the editing/selection of items is always based on the ground-level footprint. So it might be confusing at first to modify the scenery while the map shows the tilted view - but it greatly helps with vertically stacked terminal kit facades and terminal window/jetway alignment. The example here shows - I should have coded up this feature before I reworked KSEA recently ...

The footprint of the largest aircraft that can park at Ramp Start Locations is now visible in all map layers - but only if zoomed in sufficiently. This should help placing jetways and other items around aircraft parking positions.

Many parts in the GUI have been fine tuned to better scale with the (since WED 2.1) adjustable font sizes, e.g. the "Texture" tab for changing ground painted sign text is now much easier to reach.

The "Lines", which are preferred over "Airport Line Markings" in many cases, can now be selected with the same GUI. The 'Convert to' function is now aware of the line style attribute and preserves this when converting Airport Line Markings to Lines and vice versa as much as possible. See also https://forums.x-plane.org/index.php?/forums/topic/169024-how-to-choose-lines-vslso -airport-line-markings/

For XP10 and FlightGear designers - WED 2.2 will translate the with XP11.26 newly added Airport Line Marking styles to the closest available "classic" style when exporting to targets of XP11.00 or older. This will help porting newer/gateway sceneries to these platforms.

The new XP11.40 capabilty to specify 'endcaps' for lines is now displayed in the map preview. Although no default library art utilized this, yet - an example implementation to help full-custom scenery art designers is attached to this post.

For more advanced users - the 1st segment and exact ground reference point of facades is now indicated by a white circle. To support placing height sensitive facades on (slightly) sloping terrain.

A few validation changes now allow to specify VOR frequencies for AWOS broadcasts and disallow frequencies on which AWOS is in reality never broadcast. Runways with "T" suffix are now validated to have names to confirm to either "True North" or "Grid North" conventions - mostly of interest for gateway submissions of NZFX and other antarctic airfields.

Starting with beta2, you can make WED pop open the side panes auto-magically for you - just size them somewhat narrow and put the mouse cursor over them:

There is a 3rd party addon "Scenery Animation Manager" that modifies LR default Jetways to gain auto-docking capabilities. It also offers other animated scenery elements.

Unfortunately - installing this will also confuse the previews available in WED and causes strange and confusing behavior even for LR default jetway facades in WED. The beta 2 now includes a few hooks that allow 3rd party Library designers to hide these sideeffects from WED and make affected items look and behave "normal" again - like the six-armed marshaller. This also allows library developers to include scenery design relevant alignment markings that will show in WED only.

The fix requires to use updated SAM libraries that should be available very soon - look for a versio updated in 2020 or later at

Last - the startup, scenery load times and the occasional "loading textures" delays were reduced by 2.5x, along with changes to support orthophoto texture creation for mobile platforms or using external converters. See the new checkbox in the preferences for that.

CHANGE HISTORY:

WED 2.2.0r3 2/19/20 (windows only)
   Bug Fix:
   - fix resource names on windows for local objects and orthophotos after import from DSF

WED 2.2.0r2 2/3/20
   Bug Fix:
   - fix crash when .agp specifying non-existent annotations are visible in the map
   - fix some underground scenery parts becoming visible when map is tilted

WED 2.2.0r1 1/16/20
   Features:
   - add searchable column for ICAO/FAA/Local codes in gateway import dialog
   - add cmdline debugging option for gateway testing
   Bug Fixes:
   - fix (Windows only) scenery window changing size when dragged, can't be resized via frame

WED 2.2.0b2 1/03/20

   Features:
   - for library designers - support #object_wed/#obj_wed commands in .agp/.fac definitions
   - fine tune map detail - show aircraft footprints at lower map scale, add lines to ATC mode
   - add ability for Library/Property panes to auto open/close, when set narrow enough
   - map drawing w/large amounts of .agp (e.g. KATL parking lots - 13k cars !!) 5x faster
   Bug Fixes:
   - fix wall for type 1 facades not displayed using specific names, if available
   - fix tall objects, e.g. towers, not centered in library preview window
   - WED-1252: fix severe distortions in all windows when previewing certain .agp
   - fix WED not respecting 2nd of two directly successive SCENERY_PACKS_DISABLED
   - WED-1253: subdue facade structural lines - let tilted previews do the talking
   - WED-1254: fix runways of zero length not caught by runway minimum size validation

WED 2.2.0b1 17/12/19

   Bug Fixes:
   - WED-1225: show apts with only declined submissions in gateway import dialog
   - WED-1235: fix crash when processing OOB indices in bad .agp definitions
   - try harder to keep 1:1 pixel mapping when splitting orthophoto's into tiles
   - fix LineSelector GUI not popping up when style 'None' is selected
   - allow runways with T suffix naming to match either true or grid north heading
   - WED-1248: fix crash when libray.txt rpath includes trailing non-ASCII characters

   Features:
   - add 'birds eye views' for map window
   - startup time and zoom-in delays with more complex airports reduced by 2.5x
   - tighten ATC freq. validation to VHF airband & 200+ MHz, allow AWOS on VOR's
   - increase undo buffer from 20 to 100 operations
   - WED-1232: Support OBJ_DELTA in .agp previews
   - improve marking of facade 1st segment and ground reference point
   - WED-1217: show new 11.35 endcaps for lines in on-map previews
   - XSG-8722: report airport location to gateway server upon submission
   - option to create .png (rather than .dds) during orthophoto export
   - WED-1244: Combine exclusion zones upon import
   - WED-1240: Better visibility for UI mode tabs, ATC route segments
   - visualize ramp start sizes in all modes when zoomed in sufficiently
   - "Convert To" for lines now translates styles to resource paths and vice versa
   - allow GUI based resource selection for "Lines", same as for "Airport Line Markings"
   - WED-1219: Make it more obvious to user when export was aborted due to errors
   - Translate new XP1126+ line styles to pre-XP1126 equivalents for targets < XP1130

test_endcaps.zip

"Airport Line Markings" are intended for aircraft movement related things, like taxiway center/edge lines, runway hold markings etc. Just as Taxiways are for aircraft movement areas, only. They can have lights associated with them and they are written into the apt.dat.

"Lines" can look the exact same, have the same choices (plus many more if you use 3rd party addon libraries), but are closely related to polygons: Intended for everything else, they go just like polygons into the .dsf tiles. They can have lights, too, but these lights have to be placed as separate "strings" then.

The three important things are 

- lines align exactly relative to polygons, as both are subject to the same compression when written to .dsf tiles. This is e.g. important when using a line to outline a polygon like the red/yellow./white striped "safety area polygons".

- airport line markings will NOT exactly align with polygons. They also take up 5-7x as much space in scenery files and end up in a global database: ALL airport line markings at ALL airports globally have to be parsed by the simulator EVERY time X-plane starts. While .dsf tiles are only read if you fly near there. Reading binary .dsf content is about 5-10x faster in the sim as reading the text format apt.dat. So scenery complexity is WAY less of a problem, if that content ends up in .dsf tiles.

- other users of gateway data like FlightGear and OpenStreetMap (yes - they do import our apt.dat's. Its part of why ESRI gives WED free access to their imagery ...) do read the apt.dat, only. So lines important to taxiway structures should be in the apt.dat. OSM and FG both have their own roads/art objects etc. The OSM guys even asked to have the road markings removed from the apt.dat, so they don't have to filter out those lines: They can't tell a yellow dashed taxiway line from a yellow dashed road center.

That is why I strongly recommend to draw items that normally do not require lights AND are not important to the movement of aircraft as lines and not as airport line markings. Its almost an "yellow" vs "all other colors" thing. For example

Apt Line Markings:
- taxiway center, edges - in particular if they go along with lights
- taxiway hatches (wide yellow "don't taxi here" side bars)
- runway holds, other holds

Lines:
- outlines around polygons
- outlines around ground painted signs
- aircraft ramp parking markings
- ground traffic only relevant markings on the apron
- road markings
- anything outside the airport boundary
- anything not on or near a taxi or runway

Airport Line Markings can be converted into Lines and vice versa with Edit -> Convert To in WED 1.7 and newer. Actually - WED shows the real color of a "Line" in the pictorial (zoomed out) preview - while all non-yellow "Airport Line Markings" are always shown as white, only.

Starting with WED 2.2 the "Convert to" will automatically set matching "Resource" or "Marking" properties when converting either way. And allow to use the GUI for selecting Apt Line Marking styles on Lines as well.