Worldwide Soaring Turnpoint Exchange Waypoint Format



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 eXchange 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 HyperTextMarkupLanguage 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

Altras    <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.