Worldwide Soaring Turnpoint Exchange Waypoint Format
![](../GRAPHICS/construction.gif)
There are many different sorts of data that are currently accomodated
in the "Worldwide Soaring Turnpoint Exchange" data base; however only the waypoint
name, latitude,
and longitude are necessary, and they can be submitted in any format;
"degrees", "degrees and minutes", "degrees, minutes, and seconds", or
even "radians". Additional information,
e.g.
description of the waypoint, elevation, frequency and other airport
information,
etc are most welcomed.
We can accept data in "virtually" any format. ASCII text, one
waypoint per line with a distinguishing character like "tab" or ","
separating the fields, is simplest, but hardly required. The data can
be in any order.
If you don't already have your waypoint data in a file, may I suggest
the following interchange structure, which I can import immediately and
with no work at this end!!
Objectives
The idea is to have a simple format that contest organizers,
individuals who want a personalized waypoint collection, as
well as stewards of regional waypoint collections, can maintain
in whatever layout and with whatever tools they find most convenient.
The layout [ format, syntax ] must allow the individuals to store all
of the data that they wish, in the form that they wish,
and then to be read without change by the
"Worldwide Soaring Turnpoint Exchange" to generate the various flight recorder,
flight computer, GPS, and scoring program files that are then made
available on the WWW or provided back to the contributor.
The intention is to "eventually" provide online generation of the various
formats for the user; i.e. the user submits a WSTX compatible file
and selects the import format that they wish, and the files are generated
immediately. It is possible - and desireable - that the various software
providers may offer
the capability to import this, or a functionally similar IGC standard,
in addition to their existing, individual, data import formats.
A prime user, that I have in mind, is the contest organizer who changes some of
the data the night before a contest, and who would like to provide all of the
contestants with files that can be uploaded to their flight units immediately.
A flexible, self-identifying structure was adopted three years
Requirements
- Accuracy/Consistency
Contributors shold be able to provide waypoint coordinates
in degrees,
degrees:minutes,
degrees:minutes:seconds, or
radians.
A strong requirement, that was easily satisfied, was respecting the full
precision of the contributed latitude and longitude; that is the coordinates
are stored as contributed and used "as is" for those output formats using
the same format, and the other output formats are derived from the input. Thus, d:m:s
input is not converted to another, homogeneous format - such as fractional
degrees - internally and then converted back to d:m:s when required, which
would result inevitably in slight differences.
- Flexibility/Extensibility
Different sites have different data available, and new types of data continue
to emerge.
So the format should allow
storage to be allocated only for the data actually contributed for the site, and
the system should be able to grow gracefully as new data becomes available for additional
sites.
For example, if waypoint numbers are used,
they can be included, but if there are not used
there is no need to enter null data.
This is achieved by having the data be "self-identifying"; that is each "column"
in a table has a definition of the contents of that column. So the column with the
latitude in degrees, just says "latitude degrees" at the top, and subsequent rows
have the latitude in degrees for each waypoint. Furthermore, since the columns are
self-identifying, they can appear in any order; for example "name, latitude, longitude"
or "longitude, latitude, name".
Additional types of data can be added later easily, by just adding new "column
definitions". In addition, application specific data can be included without conflict
with other applications, by prepending the application's name; for example
CAI_COMMENT.
- Easy maintainance
by any of a variety of readily accessible tools
General Specifications
- Comments
Everything after "*" on a line is ignored; it's a "comment".
This default character for specifying comments can be changed, by a metadata
line.
- Definitions
$
This default character for specifying metadata can be changed, by a metadata
line to some other character which is not otherwise employed, e.g. {
as in the following.
$ metadata: { * changes the metadata character from $ to {
Here are some of the definitions already in use.
- Waypoints
Blanks at the beginning or at the end of a cell, for example for readability
if a separator other than the is used, are not considered part
of the contents of the cell, by the reader. Quotation marks ["] surrounding
the contents of a cell are ignored.
Here are some of the columns already in use.
File Names
They are completely arbitrary. However, limiting oneself to the old DOS standard
of 8 characters with a 3 character "extension" simplifies some displays.
The extension is arbitrary, but we use "*.STX" to readily identify the
Worldwide
Soaring
Turnpoint e
Xchange import files.
Coordinate Specification
Character encoding
The default character set is ISO-8859-1, which works for electronic transmission
and for display, and which includes the following:
¡ ¢ £ ¤ ¥ ¦ § ¨ © ª «
¬ ® ¯ ° ± ² ³ ´ µ ¶ · ¸ ¹ º
» ¼ ½ ¾ ¿ À Á Â Ã Ä Å Æ Ç È É
Ê Ë Ì Í Î Ï Ð Ñ Ò Ó Ô Õ Ö × Ø
Ù Ú Û Ü Ý Þ ß à á â ã ä å æ ç
è é ê ë ì í î ï ð ñ ò ó ô õ ö
÷ ø ù ú û ü ý þ ÿ .
The
Hyper
Text
Markup
Language
equivalents -
e.g. either
è or è for è - are also fine.
The encoding can be changed from this default, to handle
e.g.
the polish or hungarian character sets. Note that some of these characters,
e.g. ¶, don't have a convenient simple character representation
and are just ignored! Stick to the accented characters.
An example
The default field separator is the "tab" character, which has been rendered
visible in the following by displaying it as
<T>.
* Everything after * on a line is ignored; it's a "comment" like this entire line
* Lines starting with a $ are meta-data; information that applies to the entire file
* None are required
$Site<T>Minden, Nevada * Nice to know the name, but not required
$Latitude<T>N * Specifying this saves you from entering it for each waypoint
$Longitude<T>W
*-------------------------------------------------------------------------------
* The first line that is non-blank, non-comment, non-meta-data definition
* defines the contents of the columns that follow with the waypoint data
* It can be placed anywhere before the waypoint data starts.
* Placing it as the first line of the file can be helpful if the
* data is maintained by a spreadsheet program, like Excel, which
* allows the first row to be frozen at the top of the display so when
* you've scrolled down several screens you can still see the column definitions
* It's placed just before the waypoint data here to "improve" readability.
*-------------------------------------------------------------------------------
Name<T>Latitude degrees<T>Latitude minutes<T>Latitude seconds<T>Longitude degrees<T>Longitude minutes<T>Longitude seconds
*-------- Here is the waypoint data -------------------------------------------
Air Sailing<T> 39 <T> 51 <T> 18 <T> 119 <T> 42 <T> 4
* Note the accent in Alturas, which is important for many languages
Altúras <T> 41 <T> 28 <T> 49 <T> 120 <T> 34 <T> 5
Austin <T> 39 <T> 27 <T> 37 <T> 117 <T> 12 <T> 0
Basalt <T> 38 <T> 0 <T> 37 <T> 118 <T> 16 <T> 29
Some additional examples:
If you would like to check and see if your file will be read the way
you want, you can try
this link which will upload
your file, and display the result.
Try downloading one of the examples above, editing it and then uploading it to
see how it is displayed. Choose the layout that is most convenient for you,
and just edit in your data and submit it.
If you really like this sort of stuff, here is
some PERL that does the parsing.
Return to "Information about the Worldwide Soaring Turnpoint Exchange".
Please contact John Leibacher with any suggestions concerning this material.