Sector Metadata File Format

Traditional Traveller sector data is a list of UWPs, describing the systems in the sector. While this is adequate for most adventuring and exploration, it only represents a portion of the information presented in maps. Details such as borders and routes provide extra flavor to the visual presentation of sectors, and important details such as subsector names also need to be captured. Together, this extra detail is described by J. Greely as sector metadata.

Greely defines a plain text metadata file format by example: SpinwardMarches.txt This format is used by his sec2pdf tool for generating PDF sector maps. The Traveller Map site supports MSEC files in both the "MSEC" format in the Poster Maker and other tools, but also supports an XML format specific to the site that gives more options.

For details on the non-meta data file format, see the Sector Data File Formats page.

XML Metadata File Structure

The XML metadata format is formally described by a W3C XML Schema file; validation tools can be used to ensure that files conform to the schema. The schema defines far more detail than is presented here, as it also allows for annotations regarding the source of the data, relevant era, and so on to be added to practically any element.. This is primarily of interest only for managing the dataset of the entire map, and is the reasoning behind an extensible XML-based format.

The basic XML metadata file structure is as follows:


Subsector names are specified using one Subsector element each, with the subsector name as the text content.


subsector position A - P



Routes - representing the Imperial X-boat network, trade routes, rift-crossing routes, and so on - are listed with each connection requiring one Route element:


route start hex as XXYY
route end hex as XXYY
(optional) 1, -1, or 0 (default)
(optional) Used with stylesheets. e.g. ZhCo or Aq
(optional) Used with stylesheets. e.g. Trade, Communication, etc
(optional) one of Solid, Dashed or Dotted
(optional) an HTML color name or code #RRGGBB
(optional) a scaling factor, relative to the default width e.g. 1.5


Routes that extend past the bounds of a sector can use either otherwise invalid 4-digit hex codes (e.g. 0000, 3341) or indicate a sector offset x or y for the start or end hex, with negative x being spinward and negative y being coreward. For example, these two routes are identical:


Routes can be styled either through direct use of the Style and Color attributes, or by Stylesheet definitions, referencing the Allegiance or Type attributes in style selectors.

Use the Route Maker to assist in authoring routes for your sectors.


Borders are the most complex metadata type. Following the "MSEC" format, borders are defined by listing the hexes around the perimeter. Each Border element contains the hexes as a list, e.g. 0101 0201 0102 0101. The start hex must be the uppermost (Coreward) hex in the leftmost (Spinward) column. The path then follows each hex clockwise around the bounded region until it returns to the start hex again.

Borders support regions that extend beyond the edges of a sector. This is done by using otherwise invalid 4-digit hex codes (e.g. 0000, 3341), for a one-hex buffer zone around the edge of the sector representing adjacent sectors. The borders on these hexes are not drawn, but are necessary to specify to satisfy the algorithm above.

It's easy to make a mistake when hand-coding borders following the above rules. This will result in sometimes subtle, but often dramatic visual glitches when rendering maps. Consider using the Border Maker.

If a border specifies an Allegiance attribute which matches a known allegiance code, or an explicit Label is given, a label is shown (by default) at the approximate center of the bounded region.


(optional) Used with stylesheets and for automatic labels. e.g. ZhCo or Aq
(optional) Must be true (default) or false (to suppress the automatic label)
(optional) Must be false (default) or true (to wrap the label text onto multiple lines)
(optional) Label hex position, as XXYY
(optional) Label text to use, regardless of a matching allegiance
(optional) one of Solid, Dashed or Dotted
(optional) an HTML color name or code #RRGGBB


Borders can be styled either through direct use of the Style and Color attributes, or by Stylesheet definitions, referencing the Allegiance in style selectors.

Use the Border Maker to assist in authoring borders for your sectors.


Although there are common allegiance codes in use, e.g. Im for the Third Imperium, custom allegiances may be necessary. These are defined using Allegiance elements.


The abbreviation for the allegiance. This is matched by Border elements to produce automatic labels.

Although the Traveller5 Second Survey project is defining canonical four-character allegiance codes (e.g. ZhCo) for polities in the Official Traveller Universe, two-character allegiance codes (e.g. Aq) should continue to be used for custom data. This is because the Traveller Map site enforces that four-character codes are from the T5SS list, and rejects unknown codes as errors to assist in the project. Since all T5SS allegiance codes are known by the site already, it is not necessary to define them using Allegiance elements.


Since allegiances are not directly displayed, they can be used for other book-keeping, e.g. to conveniently annotate routes with a shipping company.


In addition to the labels generated automatically for borders, labels can be explicitly added using Label elements. These can be used for labelling rift-crossing routes, navigation hazards, and so on.


label position as XXYY
an HTML color name or code #RRGGBB
(optional) one of small or large
(optional) Must be false (default) or true (to wrap the label text onto multiple lines)
(optional) a positive or negative floating point value, adjusts the vertical alignment of the label (default is 0)
Currently unused



Regions are just like borders but they are filled rather than outlined. They can be used to represent regions of space other than political boundaries, such as nebulas.

The format and options are exactly the same as borders, although Allegiance is not typically used and Style is ignored.



Just as CSS provides a convenient way to define styles for HTML documents, you can specify a Stylesheet element to easily control the appearance of borders and routes The syntax is intentionally similar to the CSS language used in web pages. The basic structure is a list of rules:

selector, selector, ... { property: value; property: value; ... }

Selectors (the bit up front)

Declarations (the bit in the back)


HTML color name or code #RRGGBB
integer or floating point number
one of solid, dashed, or dotted

Application Rules


The following allegiance codes are recognized and matching routes and borders are automatically styled, although a Stylesheet definition will take precedence.

Im SoCf ZhCo As HvFd Kk JuPr

Since T5SS codes are focused on the allegiance of a specific world to a polity or domain, they don't precisely match the needs for metadata elements such as routes or borders which implicitly span multiple worlds. HvFd, SoCf, and ZhCo are T5SS allegiance codes for those homogenous polities (Hive Federation, Solomani Confederation and Zhodani Consulate, respectively). JuPr is the generic code for Julian Protectorate worlds although some may be aligned to a member state of the protectorate. Imperial worlds are marked with the allegiance e.g. ImDd for worlds in the Domain of Deneb, so a generic Im code is used for Imperial routes and borders. Similarly, Aslan worlds are associated with specific clans, but As is retained as a code for the Hierate as a whole. No T5SS codes have been defined for the Two Thousand Worlds so Kk continue to be used.

The Traveller game in all forms is owned by Far Future Enterprises. Copyright © 1977 – 2018 Far Future Enterprises. Fair Use Policy