As the name already implies, everything that is needed for configuration goes into here. This is currently three required files, the Definitions and the two euroscope headers.
This file is at the heart of the exporter as it defines, what features go where, how they should be named and how they shold be layered, what color they take and a few other items. Let's dig into this a little bit.
In this category everything related to colors is defined.
In here, all the colors in your sector file should be defined. These are needed to create the stub sectorfile for testing, but also to check whether there's any undefined colors that are used anywhere in the generated sectorfile, which can lead to hard to trace issues in the Euroscope loading process. The result of that check is appended to the end of the logfile generated by the exporter.
Each item is an object with a Name and a Hex attribute, these have to match the values in GNG to make the stub sectorfile look like the production / GNG one.
{
"Name": "APP",
"Hex": "#0000ff"
}In here a few shorthand color tags can be defined for use with the color attribute of a geoJSON feature, however we generally don't recommend the use of this feature, instead we'd advocate the use of more diverse definitions in the category mapping.
Each item is an object with a Tag, Name, Hex and a Color attribute, the tag is the shorthand used in the geoJSON, the name is a human readable name, the hex is the hex of the color, currently not used, and the color attribute defines the GNG named color it uses.
{
"Tag":"bl",
"Name":"Blue",
"Hex":"#0000ff",
"Color":"TaxiwayBlue"
}This is the color that will be assigned to any hole in a Polygon feature when it is converted to a Euroscope Region, the reason for this hack is that Euroscope natively can't deal with holes, and procedurally cutting the polygon isn't just hard, it also tends to lead to jagged edges as I can't control the cut and / or insert an overlap without risking that the resulting polygon looks different to what we intended. This is a singular color name formatted as a string as the value to the attribute.
"Hole Color": "AoRground1"In here, the real magic happens. Each one of these entries defines a category that the converter then uses to interpret the geoJSON data so it can assign the features the correct attributes for Euroscope to read it.
Each sub-attribute of Category Mapping constitutes a main category, how you set these up is up to you and your VACC, I have included our definitions as an example of how we work with this, however it is fairly configurable to suit your needs.
One limitation to this system is that currently the minimum length of a category is 1 item, and the maximum length is 3 items, separated by an underscore. This means you could have lbl_prkg_old, where lbl is the category (Labels), prkg is the suffix (Parkings), and old is the additional, or Level 2 suffix (Old parking layout), or you could have just lbl-prkg-old as a category without suffixes. How you want to work with this is up to you again, however I'd suggest making use of the layering abilities as you only need to define the differences of the suffix to the category in the suffix definition, instead of defining the entire thing again in a new category.
This is all very theoretical so let's take it apart.
This attribute takes the shorthand of whatever you want it to, we recommend grouping things with similar attributes into one category
Any of the following items are mandatory and must be defined for eac category in order for the converter to function. Currently this only affects the Default attribute, however as features expand more items might be added here
One level below the Category you find the Default attribute. This defines the basic characteristics of this category, and they will be applied to all sub-categories below that unless overwritten by the suffix definition. There are four required attributes here, which are:
GroupThis defines the name of the item as it would appear in the Euroscope Display Settings Dialogue. There are currently two defined tags that can be used to dynamically adjust this group name, one being the$airporttag, which inserts the airport ICAO into its position, so$airport GroundlayoutbecomesEHAM Groundlayout, and a non-specific$1tag, that is currently used for the TORA labels to insert the Runway Name, soTORA $1will becomeTORA 18Rin Euroscope.ColorThis defines the default color of all itemsES CategoryThis defines which Euroscope Category the features will be mapped into, the acceptable values here currently are only"geo","regions"and"freetext"as this converter is really meant for ground layouts.Feature TypeThis tells the converter, what feature type to convert the feature to, if it finds a polygon feature but it expects a line it will convert that feature down. Acceptable values here are"Polygon","Line"and"Point"PriorityMandatory only for Regions. This defines the priority of a feature within the region, higher numbers get higher priority, items of equal priority will be sorted in the way the converter read them which is not directly controllable, so specific priorities for required layering is highly recommended.ignoreOptional. This is an attribute with boolean values, eithertrueorfalse,"Ignore" = truewill make the converter ignore any feature with this category
These items may be added (in Order!) within the category to add parseable suffixes and assign any number of attributes to the category-suffix combination different from the parent attribute.
This defines the basic suffixes, in our previous example this would be prkg. The value of the "suffixes" attribute will be an object, the attributes of which will be the suffix names. The value of the suffix itself will be another object with the same attributes as the Default object, additionally an attribute "Additional Suffixes" may be defined, which again works basically the same as the suffixes we're currently in. The properties of the additional suffix will overwrite the properties of the suffix, which in turn will overwrite the properties of the category.
This was all very theoretical, let's look at a maximally complicated example now.
"rwy":{
"default":{
"Group":"$airport Groundlayout",
"Color":"HardSurface2",
"ES Category":"regions",
"Feature Type":"Polygon",
"Priority":41
},
"suffixes":{
"sb":{
"Group":"$airport Groundlayout Stopbars",
"Color":"Stopbar",
"ES Category":"geo",
"Feature Type":"Line",
"Additional Suffixes":{
"1":{
"Group":"$airport Groundlayout Stopbars Cat I"
},
"2":{
"Group":"$airport Groundlayout Stopbars Cat II",
"Ignore": true
}
}
}
}
}In this example we're defining a Runway Category with a Stopbar Suffix and ILS Category Additional Suffixes, each with their own property. The runway itself will be drawn as a Polygon in the Euroscope Regions, the Stopbars will be in Euroscope Geo as Lines, with a different Group name and a different color, and the ILS categories themselves will each also have their own group, and Cat II stopbars will be disregarded.
The two sectorfile headers also included in this folder serve as a basis to generate the stub sectorfile and contain some Euroscope configuration data as needed for the sector display.
This file serves as the basis of the sectorfile, it contains a general disclaimer at the top, then the Euroscope [INFO] section as described in the VRC documentation
The $ formatted tags are insertion points for the code to know where things go, currently there's three of them in the sct file
$colorsmarks the insertion point for the color definitions for Euroscope so that color aliases can be used$geomarks the insertion point for any line features$regionsmarks the insertion point for any polygon features If you want you can also easily add more hardcoded data into this header file just like you would into a standard .sct file, for example if you want the airways in your stub sectorfile you can just copy/paste them from your existing sectorfile into this header.
This basically works the same as the .sct file heade, except that this one is for the sectorfile extension (duh). Again the general format of this file is the same as a normal .ese file so the Euroscope documentation is a good source of info about this one too.
There's also one $ tag in this one, currently only the freetext labels go into this file, so obviously $freetext works as the insertion point for any point type features containing a label or other freetext.