# GPSBabel XCSV Style Files

## Introduction to GPSBabel Styles

Often it is desirable to add a new file format for "one-off" work (perhaps you want to export something to a spreadsheet or graphing program) or to read a format that GPSBabel does not yet support. For suitably simple formats, this can be done by a user with no programming experience by providing a GPSBabel style file.

For a format to be described by a style file, it must be predictable and generally readable by a human. Formats with binary or unreadable content are not good fits for this scheme. It should have:

- A fixed header at the beginning, if it has any at all. This is called a 'prologue'.
- Waypoints that are grouped by fixed separators, often a newline. In style file parlance, this is called a 'record'.
- Traits of that waypoint described in that record. In the style files, these are called 'fields' and examples may include longitude or a name.
- Fields that are grouped by fixed separators, often a comma or a tab. In the style files, this is called the field separator. Fields may be enclosed by characters, such as a double quote.
- A fixed footer at the end, if it has any at all. This is called the 'epilogue'.

Once you have created a style file that describes the file format you have or want, you must tell GPSBabel to use the xcsv format and have the xcsv format use that file. If you created a new style file called "mystyle.style" and you want to write the waypoints from a GPX file named "mine.gpx" to it, you would issue a command like:

`gpsbabel -i gpx -f mine.gpx -o xcsv,style=mystyle.style -F mine.new`

You might then examine `mine.new` to see if it met your expectations. If not, you could continue to tweak `mystyle.style` until it did, rerunning the above command each time. If 'mystyle' is a format that describes a popular program or is likely to be of use to others, you can then share `mystyle.style` with other GPSBabel users. Send it along with a coherent description to the GPSBabel-Misc mailing list for consideration to be included in a future version.

## Style file overview

The first and foremost important step is understanding how the style file is laid out itself. The format is:

    DIRECTIVE<whitespace>VALUE

Where <whitespace> is one or more spaces or tabs. There should be no spaces or tabs at the beginning of the line; all directives start at the left edge in column zero.

An example style format is shown here:

    # Format: MS S&T 2002/2003
    # Author: Alex Mottram
    #   Date: 12/09/2002
    #

    DESCRIPTION       Microsoft Streets and Trips 2002-2006
    EXTENSION               txt

    #
    # FILE LAYOUT DEFINITIIONS:
    #
    FIELD_DELIMITER      TAB
    RECORD_DELIMITER  NEWLINE
    BADCHARS    ,"

    PROLOGUE Name  Latitude Longitude   Description URL   Type  Container   Diff  Terr

    #
    # INDIVIDUAL DATA FIELDS, IN ORDER OF APPEARANCE:
    # NOTE: MS S&T ONLY IMPORTS DATA, IT DOESN'T
    #       EXPORT THIS ANYWHERE SO WE CAN HAVE OUR
    #       WAY WITH THE FORMATTING.
    #
    IFIELD   SHORTNAME, "", "%s"      # Name
    IFIELD   LAT_DECIMAL, "", "%f"    # Latitude
    IFIELD   LON_DECIMAL, "", "%f"    # Longitude
    IFIELD   DESCRIPTION, "", "%s"    # Name 2 (Big Description)
    IFIELD   URL, "", "%s"         # URL
    IFIELD   GEOCACHE_TYPE, "", "%s"     # Geocache Type
    IFIELD   GEOCACHE_CONTAINER, "", "%s"   # Geocache Type
    IFIELD   GEOCACHE_DIFF, "", "%3.1f"  # Geocache Type
    IFIELD   GEOCACHE_TERR, "", "%3.1f"  # Geocache Type

Each of these lines will be explained in the following sections.

## Internal Constants

A few internal constants are defined in the XCSV parser to make the style file simpler. They may or may not be used and are optional in most cases. Note that only certain style file directives map these constants.

Style Constant Maps to Char(s)
- COMMA ,
- COMMASPACE ,<space>
- SINGLEQUOTE '
- DOUBLEQUOTE "
- COLON :
- SEMICOLON ;
- NEWLINE \n
- CR \r
- CRNEWLINE \r\n
- TAB \t
- SPACE <space>
- HASH #
- PIPE |
- WHITESPACE see below

### WHITESPACE

The WHITESPACE constant has special properties. When reading data, WHITESPACE refers to sequential runs of SPACES and/or TABS. When writing data, WHITESPACE is always a single SPACE.

For example, the following line:

    SOME_NAME       30.1208 -91.1365    SOME OTHER NAME

Parses into the following data fields:

    SOME_NAME,30.1208,-91.1365,SOME,OTHER,NAME

### COMMENTS

Anything after a hash (#) on a line is not parsed. For example:

    #THIS ENTIRE LINE IS A COMMENT.
    #FIELD   LAT_DECIMAL, "", "%f"   THIS ENTIRE LINE IS A COMMENT
    FIELD LAT_DECIMAL, "", "%f"  # ONLY THIS SENTENCE IS A COMMENT.

## Global Properties of the File

There are a few available directives to describe general traits of the file being described and not specific data within the file itself.

### DESCRIPTION

This is the description of the file format being described. This text appears in the help screens and in menus used by the various GUI wrappers.

### EXTENSION

This directive gives the filename extension generally associated with this file.

### ENCODING

Describes the character set used by this format. The value given must be one listed by 'gpsbabel -l'. example:

    ENCODING          UTF-8 # Use UTF-8 for input and output.

### DATUM

This value specifies the GPS datum to be used on read or write. Valid values for this option are listed in .

    DATUM             European 1950

### DATATYPE

Specifies the kind of data we have to read or write.

By default all data are seen as waypoint data. With DATATYPE you are now able to bind a specific type to this format. Possible values are WAYPOINT, ROUTE or TRACK.

    DATATYPE          ROUTE # route-only format

## GPSBabel Behavior Directives

There are a few available directives to control some of the internal processing functions of GPSBabel.

### SHORTLEN

This sets the maximum allowed shortname length when using the internal shortname synthesizer.

example:

    SHORTLEN 16 # shortnames will be at most 16 characters long.

### SHORTWHITE

This tells the shortname synthesizer whether or not to allow whitespace in the synthesized shortnames. Allowed values are zero and one.

example:

    SHORTWHITE  0  # Do not allow whitespace in shortname.
       SHORTWHITE   1 # Allow whitespace in shortname.

## Defining the Layout of the File

The first few directives define the layout the physical file itself:

### FIELD_DELIMITER

The field delimiter defines the character(s) that separate the fields in the rows of data inside the XCSV file. Common field delimiters are commas and tabs. (referred to as "comma separated values" and "tab separated values")

examples:

    FIELD_DELIMITER    COMMA
       FIELD_DELIMITER    ~

The directive FIELD_DELIMITER is parsed for STYLE CONSTANTS as defined in the table above.

### FIELD_ENCLOSER

The field encloser defines the character(s) that surround the field values. Common field enclosers are single and double quote marks. Many styles will leave this directive unset. If set, it will be applied to all fields.

examples:

    FIELD_ENCLOSER    DOUBLEQUOTE
       FIELD_ENCLOSER    SINGLEQUOTE

The directive FIELD_ENCLOSER is parsed for STYLE CONSTANTS as defined in the table above.

### RECORD_DELIMITER

The record delimiter defines that character(s) that separate ROWS of data (FIELDS) in the XCSV file. The most common record delimiters are NEWLINE and CR (carriage return).

examples:

    RECORD_DELIMITER    NEWLINE
       RECORD_DELIMITER    |

The directive RECORD_DELIMITER is parsed for STYLE CONSTANTS as defined in the table above.

### BADCHARS

Bad characters are things that should *never* be written into the XCSV file as data on output. GPSBabel automatically includes any non-blank FIELD_DELIMITER and FIELD_ENCLOSER and RECORD_DELIMITER characters as BADCHARS by default.

examples:

    BADCHARS    COMMA
      BADCHARS    ~|

The directive BADCHARS is parsed for STYLE CONSTANTS as defined in the table above.

### PROLOGUE

A prologue is basically constant data that is written to the output file BEFORE any waypoints are processed. PROLOGUE can be defined multiple times in the style file, once for each "line" before the data begins. This is commonly used in XCSV files as a "header" row.

examples:

    PROLOGUE OziExplorer Waypoint File Version 1.1
      PROLOGUE  WGS 84
      PROLOGUE  Symbol,Name,Latitude,Longitude

### EPILOGUE

An Epilogue is the same as a prologue, except this data is written at the END of the file. See the examples for PROLOGUE above.

## Defining Fields Within the File

A field defines data. There are two different classifications of FIELDS, IFIELD (file input) and OFIELD (file output). In the absence of any OFIELDS, IFIELDS are use as both input and output. The existence of OFIELDS is primarily to allow more flexible mapping of GPSBabel data to output data (say, for instance, to map the internal GPSBabel "description" variable to two or more fields on output). For all practical purposes, IFIELDS and OFIELDS are defined the same way in the style file.

The following per-field options are defined:

- "no_delim_before" is supported on in OFIELD tags to specify that this field should be written without a field delimiter before it. It's useful for limited field concatenation.

- "absolute" is supported on OFIELD tags for lat and lon to indicate that only absolute values (never negative) are to be printed.

- "optional" is supported only OFIELD tags and indicates that the field may or may not be available in the source data. If the field is absent, no trailing field separator is written.

  This attribute is most useful when paired with "no_delim_before" as it allows you to concatenate fields without concern for whether those fields are actually populated or not.

There are several different types of fields that may be defined. Each field consists of three pieces of information: the FIELD TYPE, a DEFAULT VALUE, and a PRINTF CONVERSION (for output). In many cases, not all pieces are used, but all 3 pieces are required. Additionally, an fourth field is supported that modifies the behavior of the field being described.

FIELDS should be defined in the style file in the logical order that they appear in the data, from left to right. This is the order in which they are parsed from input and written to output.

The fields used by the XCSV parser are as follows:

### IGNORE

IGNORE fields are, guess what, ignored on input. Internally, IGNORE fields are treated as CHARACTER data, and as such, require a printf conversion for a character array.

examples:

    IFIELD IGNORE,"","%14.14s"   # (writes a 14 character blank field)
       IFIELD IGNORE,"","%s"        # (writes a blank field on output)

### CONSTANT

CONSTANT fields are, of course, constant. They are ignored on input, however they write CONSTANT data on output. As such, they require a DEFAULT VALUE and a printf conversion for a character array.

examples:

    IFIELD CONSTANT,"FFFFFF","%s"   # (writes "FFFFFF" in the field)
       IFIELD CONSTANT,"01/01/70","%s" # (a constant date field)

### INDEX

An INDEX field is used ONLY on output. The INDEX constant defines a field that, at output, contains the sequence number of the waypoint being written, starting at 0. An index is managed internally as an INTEGER and requires an INTEGER printf conversion. An INDEX has one special property. The DEFAULT VALUE of the index is added to the index on each iteration (to allow indexes starting at 1, 100, etc..).

examples:

    IFIELD INDEX,"0","%04d"     # (Starts counting at zero)
       IFIELD INDEX,"","%04d"      # (Starts counting at zero)
       IFIELD INDEX,"1","%04d"     # (Starts counting at one)

### SHORTNAME

A SHORTNAME is generally the waypoint name of the data being processed. SHORTNAME maps directly to the GPSBabel variable ->shortname. A SHORTNAME is CHARACTER data and requires a character array printf conversion.

example:

    IFIELD SHORTNAME,"","%s"

### DESCRIPTION

A DESCRIPTION is generally a long description of the waypoint. A DESCRIPTION maps to the GPSBabel variable ->description and is otherwise handled exactly like a SHORTNAME.

examples:

    IFIELD DESCRIPTION,"","%s"

### NOTES

NOTES are generally everything else about a waypoints. NOTES map to the GPSBabel variable ->notes and is otherwise handled exactly like a SHORTNAME.

### URL

URL is a URL for the waypoint. URL maps to the GPSBabel variable ->url and is otherwise handled exactly like a SHORTNAME.

example:

    IFIELD URL,"","%s"

### URL_LINK_TEXT

URL_LINK_TEXT is a textual description of where a URL points. URL_LINK_TEXT maps to the GPSBabel variable ->url_link_text and is otherwise handled exactly like a SHORTNAME.

example:

    IFIELD URL_LINK_TEXT,"","%s"

### ICON_DESCR

ICON_DESCR is a textual description of an icon type for a waypoint. ICON_DESCR maps to the GPSBabel variable ->icon_desc and is otherwise handled exactly like a SHORTNAME.

example:

    IFIELD ICON_DESCR,"","%s"

### LAT_DECIMAL

LAT_DECIMAL defines LATITUDE in DECIMAL format. Note that this is a PURE signed decimal format (i.e. -91.0000). This data is handled internally as a DOUBLE PRECISION FLOAT and requires a FLOATING POINT printf conversion.

example:

    IFIELD LAT_DECIMAL,"","%f"

### LON_DECIMAL

See LAT_DECIMAL, except LON_DECIMAL defines LONGITUDE.

### LAT_INT32DEG

LAT_INT32DEG defines LATITUDE in what I call INT32DEGREES. This value is a signed LONG INTEGER and requires a LONG INTEGER printf conversion. (This format is only used by some DeLorme products.)

example:

    IFIELD LAT_INT32DEG,"","%ld"

### LON_INT32DEG

See LON_INT32DEG except LON_INT32DEG defines LONGITUDE.

### LAT_DECIMALDIR / LAT_DIRDECIMAL

LAT_DECIMALDIR and LAT_DIRDECIMAL define LATITUDE in DECIMAL format with the added bonus of a 'N/S' or 'E/W' direction character. This data is handled internally as a DOUBLE PRECISION FLOAT and a single CHARACTER and requires a FLOATING POINT as well as a CHARACTER printf conversion. The only difference between the two is whether the directional character appears before (LAT_DIRDECIMAL) or after (LAT_DECIMALDIR) the decimal number.

examples:

    IFIELD LAT_DECIMALDIR,"","%f %c"     #  (writes 31.333 N)
       IFIELD LAT_DIRDECIMAL,"","%c %f"     #  (writes N 31.333)

### LON_DECIMALDIR / LON_DIRDECIMAL

Same as LAT_DECIMALDIR / LAT_DIRDECIMAL except LON_ defines LONGITUDE.

### LAT_DIR / LON_DIR

LAT_DIR returns the single character 'N' or 'S' depending on the hemisphere of the latitude. LON_DIR returns 'E' or 'W' depending on the hemisphere of the longitude.

### LAT_HUMAN_READABLE

LAT_HUMAN_READABLE defines LATITUDE in a human-readable format. This format is probably the most expressive format. It is similar to LAT_DECIMALDIR in that it requires multiple printf conversions, but it is far more flexible as to the contents of those conversions. On read, the printf conversions are ignored and GPSBabel attempts to determine the latitude and longitude based on what is in the file.

examples:

    #  (writes N 31 40.000)
       IFIELD LAT_HUMAN_READABLE,"","%c %d %f"
       #  (writes "31 deg 40.000 min N")
       IFIELD LAT_HUMAN_READABLE,"","%d deg %f min %c"
       #  Note that this string will confuse the reading routine due
       #  to the letter "n" in "min" and the letter "e" in "deg."
       # (writes 31 40 00.000N)
       IFIELD LAT_HUMAN_READABLE,"","%d %d %f%c"

### MAP_EN_BNG

MAP_EN_BNG converts coordinates from/to British National Grid (BNG).

The only supported order of the items is: Map,Easting,Northing. During output all coordinates have to be located within this limited area.

examples:

    IFIELD MAP_EN_BNG,"","%s%5d %5d"   #  (writes i.e. "SJ00001 00001")
       IFIELD MAP_EN_BNG,"","%s %d %d"    #  (writes i.e. "TQ 888 999")

### LON_HUMAN_READABLE

See LAT_HUMAN_READABLE except LON_HUMAN_READABLE defines LONGITUDE.

### LATLON_HUMAN_READABLE

LATLON_HUMAN_READABLE is like LAT_HUMAN_READABLE and LON_HUMAN_READABLE except that it reads and writes both latitude and longitude as a single field. On write, the same format specifier is used for both coordinates. On read, GPSBabel does exactly the same thing it does for LAT_HUMAN_READABLE or LON_HUMAN_READABLE.

example:

    IFIELD LATLON_HUMAN_READABLE,"","%c %d %f"
               # (writes "N 31 40.126 W 85 09.62" as a single field)

### LAT_NMEA

Defines the latitude in the format used by the NMEA standard which is degrees multiplied by 100 plus decimal minutes.

example:

    IFIELD  LAT_NMEA, "%f", "%08.3f"     # (writes  3558.322)

### LAT_DDMMDIR

Derived from the LAT_NMEA latitude format, with degrees * 100 plus decimal minutes, but using an additional specifier to position the 'N' or 'S' instead of a leading minus sign (or absence thereof) to give direction from zero.

    IFIELD LAT_DDMMDIR, "%f", "%08.3f%c" # (writes "5334.192S" giving -53.56987 degrees latitude)

### LON_NMEA

Defines the longitude in the format used by the NMEA standard which is degrees multiplied by 100 plus decimal minutes.

Example:

    IFIELD  LON_NMEA, "%f", "%010.3f"  # (writes -08708.082)

### LON_DDMMDIR

Derived from the LON_NMEA longitude format, with degrees * 100 plus decimal minutes, but using an additional character format character to position the 'E' or 'W' instead of a leading minus sign (or absence thereof) to give direction from zero.

Example:

    IFIELD LON_DDMMDIR, "%f", "%010.3f%c" # (writes "01232.745W" giving -12.54575 degrees
    longitude)

### LAT_10EX / LON_10EX

Defines the latitude or longitude in the format used i.e. by TomTom Navigator itinerary files. It is degrees multiplied by 10 power X. X have to be replaced with a valid decimal value. A factor of 10000 would be generated by LAT_10E5 as shown in the examples below.

examples:

    IFIELD  LAT_10E5, "%f", "%.f"       # (writes  3558322)

    IFIELD  LON_10E5, "%f", "%.f"       # (writes -8708082)

### UTM

A location in UTM has several components: a zone, a northing, and an easting. The UTM format specifier is the most common representation of these.

example:

    IFIELD UTM, "", "%s" # writes 6S 519045 3984035  -the easting is first by convention.

### UTM_EASTING

This is the decimal component representing the easting

example:

    IFIELD UTM_EASTING, "", "%.0f"  # outputs 519045

### UTM_NORTHING

This is the decimal component representing the northing

example:

    IFIELD UTM_NORTHING "", "%.0f"  # outputs 3984035

### UTM_ZONE

The UTM zone.

example:

    IFIELD UTM_ZONE "", "%d"  # outputs 6

### UTM_ZONEC

The UTM Zone character.

example:

    IFIELD UTM_ZONEC "", "%c"  # outputs S

###

The full UTM zone and latitude band.

example:

    IFIELD UTM_ZONEF "", "%d%c"  # outputs 6S

### ALT_FEET

ALT_FEET is the position's ALTITUDE in FEET. This value is treated as a SIGNED DOUBLE PRECISION FLOAT and requires a FLOATING POINT printf conversion.

example:

    IFIELD ALT_FEET,"","%.0f"

### ALT_METERS

ALT_METERS is identical to ALT_FEET with the exception that the altitude is in METERS.

### HEART_RATE

Heart rate, measured in beats per minute. Only valid for units with heart rate monitor features (i.e. Garmin Forerunner 301).

example:

    IFIELD HEART_RATE,"","%d"

### CADENCE

Cadence in revolutions per minute. Only valid for units with heart rate monitor features (i.e. Garmin Edge 305).

example:

    IFIELD CADENCE,"","%d"

### POWER

Cycling power in Watts. Only valid for units with power meter features (i.e. Garmin Edge 305).

example:

    IFIELD POWER,"","%.1f"

### TEMPERATURE

Temperature in degrees Celsius.

example:

    IFIELD TEMPERATURE,"","%.1f"

### TEMPERATURE_F

Temperature in degrees Fahrenheit.

example:

    IFIELD TEMPERATURE_F,"","%.1f"

### EXCEL_TIME

EXCEL_TIME is the waypoint's creation time, if any. This is actually the decimal days since 1/1/1900 and is handled internally as a DOUBLE PRECISION FLOAT and requires a FLOATING POINT printf conversion.

example:

    IFIELD EXCEL_TIME,"","%11.5f"

### TIMET_TIME

TIMET_TIME is the waypoint's creation time, if any. This is actually the integer seconds since 1970-01-01T00:00:00 UTC. It is handled internally as a 64 bit integer and requires a LONG LONG INTEGER printf conversion.

example:

    IFIELD TIMET_TIME,"","%lld"

### TIMET_TIME_MS

TIMET_TIME_MS is the same as TIMET_TIME, but expressed in milliseconds. It too is handled internally as a 64 bit integer and requires a LONG LONG INTEGER printf conversion.

example:

    IFIELD TIMET_TIME_MS,"","%lld"

### YYYYMMDD_TIME

YYYYMMDD_TIME is the waypoint's creation time in UTC, if any. It's a single decimal field containing four digits of year, two digits of month, and two digits of date. Internally it is a LONG INTEGER and thus requires a LONG INTEGER printf conversion.

example:

    IFIELD YYYYMMDD_TIME,"","%ld"

### GMT_TIME

GMT_TIME is the waypoint's creation time, in UTC time zone. It uses the strptime conversion format tags. It can be used to parse/print a date and time in one column, or a date in one column and a time in another column. If used to parse a date and a time in separate columns the date and time can be in either order.

example with a a date followed by a time using a 12 hour clock and an AM/PM indication:

    IFIELD GMT_TIME,"","%m/%d/%Y %I:%M:%S %p"

example with a a date followed by a time using a 24 hour clock:

    IFIELD GMT_TIME,"","%Y/%m/%d"
    IFIELD GMT_TIME,"","%H:%M:%S"

Search the web for 'strptime man page' for details strptime, but one such page can be found at http://www.die.net/doc/linux/man/man3/strptime.3.html

### LOCAL_TIME

LOCAL_TIME is the waypoint's creation time, in the local time zone. It uses strptime conversion format tags. It can be used to parse/print a date and time in one column, or a date in one column and a time in another column. If used to parse a date and a time in separate columns the date and time can be in either order. See GMT_TIME for examples and a reference.

### ISO_TIME

ISO_TIME is the waypoint's creation time, in ISO 8601 format, which include time zone information. It is expected to be in the format yyyy-mm-ddThh:mm:sszzzzz where zzzzzz is the local time offset or the character Z for UTC time. On output, UTC 'Z' time zone will always be used.

example:

    IFIELD ISO_TIME,"","%s"

### ISO_TIME_MS

ISO_TIME_MS is much like ISO_TIME, but expresses milliseconds at the end of the timestamp. It is thus in the format yyyy-mm-ddThh:mm:ss.SSSzzzzz where 'SSS' is milliseconds and zzzzzz is the local time offset or the character Z for UTC time. On output, UTC 'Z' time zone will always be used.

example:

    IFIELD ISO_TIME_MS,"","%s"

### NET_TIME

Microsoft dot net represents times in 100 nanosecond intervals since midnight Jan 1/0001 GMT, giving absurdly large numbers like 633943150010000000 for mid-November, 2009. NET_TIME is how to represent those in GPSBabel.

example:

    IFIELD NET_TIME,"","%lld"

### GEOCACHE_DIFF

GEOCACHE_DIFF is valid only for geocaches and represents a DOUBLE PRECISION FLOAT. This is the geocache "difficulty" rating as defined by Groundspeak. A "three and a half star" cache would therefore be "3.5"

example:

    IFIELD GEOCACHE_DIFF,"","%3.1f"

### GEOCACHE_TERR

GEOCACHE_TERR is valid only for geocaches and represents a DOUBLE PRECISION FLOAT. This is the geocache "terrain" rating as defined by Groundspeak. A "three and a half star" cache would therefore be "3.5"

example:

    IFIELD GEOCACHE_TERR,"","%3.1f"

### GEOCACHE_CONTAINER

GEOCACHE_CONTAINER is valid only for geocaches and is heavily influenced by the Groundspeak container types. Examples would include "Micro" and "Virtual".

example:

    GEOCACHE_CONTAINER,"","%s"

### GEOCACHE_TYPE

GEOCACHE_TYPE is valid only for geocaches and is heavily influenced by the Groundspeak cache types. Examples would include "Event cache" and "Multi-Cache".

example:

    GEOCACHE_TYPE,"","%s"

### GEOCACHE_PLACER

GEOCACHE_PLACER is a string containing the name of the placer of a geocache.

example:

    GEOCACHE_PLACER,"","%s"

### GEOCACHE_ISAVAILABLE

GEOCACHE_ISAVAILABLE is a string containing "True" or "False" indicating whether a geocache is currently available or not.

example:

    GEOCACHE_ISAVAILABLE,"","%s"

### GEOCACHE_ISARCHIVED

GEOCACHE_ISARCHIVED is a string containing "True" or "False" indicating whether a geocache has been archived.

example:

    GEOCACHE_ISARCHIVED,"","%s"

### GEOCACHE_LAST_FOUND

A long integer in format YYYYMMDD containing the last time this geocache was found.

example:

    GEOCACHE_LAST_FOUND,"","%ld"

### GEOCACHE_HINT

The hint for this geocache. No additional transformation (such as rot13) will be performed on this string.

example:

    GEOCACHE_HINT,"","%s"

### PATH_DISTANCE_MILES

PATH_DISTANCE_MILES outputs the total length of the route or track from the start point to the current point, in miles. This and the altitude could be used to create an elevation profile. PATH_DISTANCE_MILES is a DOUBLE PRECISION FLOAT.

PATH_DISTANCE_MILES is not valid as an input field.

PATH_DISTANCE_MILES is only meaningful if the data comes from a track or a route; waypoint data will generate essentially meaningless output.

example:

    PATH_DISTANCE_MILES,"","%f"

### PATH_DISTANCE_NAUTICAL_MILES

PATH_DISTANCE_NAUTICAL_MILES is like PATH_DISTANCE_MILES except it outputs the length in nautical miles.

### PATH_DISTANCE_KM

PATH_DISTANCE_KM is like PATH_DISTANCE_MILES except it outputs the length in kilometers.

### PATH_DISTANCE_METERS

PATH_DISTANCE_METERS is like PATH_DISTANCE_MILES except it outputs the length in meters.

### PATH_SPEED

Speed in meters per second. GPSBabel does NOT calculate this data by default; it is read from the input file if present. (If not present, it may be calculated with the track filter.)

example:

    PATH_SPEED,"","%f"

### PATH_SPEED_KPH

Like PATH_SPEED but means kilometers per hour.

example:

    PATH_SPEED_KPH,"","%.1f"

### PATH_SPEED_MPH

Like PATH_SPEED but means miles per hour.

example:

    PATH_SPEED_MPH,"","%.1f"

### PATH_SPEED_KNOTS

Like PATH_SPEED but means knots (nautical).

example:

    PATH_SPEED_KNOTS,"","%.1f"

### PATH_COURSE

Course in degrees. GPSBabel does not calculate this data by default; it is read from the input file if present. (If not present, it may be calculated with the track filter.)

example:

    PATH_COURSE,"","%f"

### GPS_HDOP / GPS_VDOP / GPS_PDOP

GPS horizontal / vertical / positional dilution of precision parameters. Needs float conversion.

example:

    GPS_HDOP,"","%f"

### GPS_SAT

Number of satellites used for determination of the position. Needs integer conversion.

example:

    GPS_SAT,"","%d"

### GPS_FIX

Type of fix (see GPX spec or track filter). Needs string conversion.

example:

    GPS_FIX,"","%s"

### TRACK_NEW

If '1', it indicates that this trackpoint is the first point of a new track. Needs integer conversion.

example:

    IFIELD TRACK_NEW,"","%d"

### TRACK_NAME

The name of the track currently being operated on. Needs string conversion.

example:

    TRACK_NAME, "", "%s"

### ROUTE_NAME

The name of the route currently being operated on. Needs string conversion.

example:

    ROUTE_NAME, "", "%s"

### STREET_ADDR

Street address including house number. Notice that this is not used for any geocoding, it's merely textual description associated with a position.

example:

    STREET_ADDR, "", "%s"

### CITY

The name of a city. Sometimes part of "Points of Interest". This is simple textual data associated with a position, no geocoding will be done..

example:

    CITY, "", "%s"

### COUNTRY

The name of a country associated with a position.

example:

    COUNTRY, "", "%s"

### EMAIL

An email address associated with a position.

example:

    EMAIL, "", "%s"

### FACILITY

The name of a facility to associate with a position.

example:

    FACILITY, "", "%s"

### PHONE_NR

A phone number associated with a position. This is just textual data attached for convenience.

example:

    PHONE_NR, "", "%s"

### POSTAL_CODE

A postal code to associate with a position. It is freeform text and is not used by GPSBabel for any geocoding or such.

example:

    POSTAL_CODE, "", "%s"

### FILENAME

The name of the input file from where the points were loaded. This field is available only on output.

example:

    OFIELD FILENAME, "", "%s"

### FORMAT

The name of the input format from where format the points came. This field is available only on output.

example:

    OFIELD FORMAT, "", "%s"

## Examples

Here is one example style file from the GPSBabel source.

    # gpsbabel XCSV style file
    #
    # Format: Garmin POI
    # Author: Robert Lipe
    # Date: 10/07/2005
    # Reference: http://forums.groundspeak.com/GC/index.php?showtopic=110641&st=0&#entry1752204
    #
    DESCRIPTION Garmin POI database
    #
    #
    # FILE LAYOUT DEFINITIIONS:
    #
    FIELD_DELIMITER COMMA
    RECORD_DELIMITER NEWLINE
    BADCHARS COMMA
    SHORTLEN 24

    #
    # INDIVIDUAL DATA FIELDS, IN ORDER OF APPEARANCE:
    #
    IFIELD LON_HUMAN_READABLE, "", "%08.5f"
    IFIELD LAT_HUMAN_READABLE, "", "%08.5f"
    IFIELD SHORTNAME, "", "%s"
    IFIELD DESCRIPTION, "", "%s"

    OFIELD LON_DECIMAL, "", "%08.5f"
    OFIELD LAT_DECIMAL, "", "%08.5f"
    OFIELD SHORTNAME, "", "%-.24s"
    OFIELD GEOCACHE_TYPE, "", " %-.4s", "no_delim_before,optional"
    OFIELD GEOCACHE_CONTAINER, "", "/%-.4s ", "no_delim_before,optional"
    OFIELD GEOCACHE_DIFF, "", "(%3.1f", "no_delim_before,optional"
    OFIELD GEOCACHE_TERR, "", "/%3.1f)", "no_delim_before,optional"
    OFIELD DESCRIPTION, "", "%-.50s"

When used on a Groundspeak Pocket Query, it will output lines that look like:

    -76.76234,38.39123,GC5370 Loca/Virt (1.0/1.0),Dude.. Wheres my Limo??
    -90.42345,38.55234,GCC8B Trad/Regu (2.0/2.0),Sweet Reward
    -90.81456,38.62456,GC3091 Trad/Regu (1.5/2.0),Matson Hill

that are suitable for Garmin's POI loader.

For additional examples, please see the `*.style` files in the `style/` subdirectory of the GPSBabel source tree or at the online source. .

## Miscellaneous Notes

### Default Values

Default values are supported for any output fields that contain pure character data output such as URL and NOTES. Default values are only written on output and are not used to supplement missing input. When using default values your mileage will vary greatly depending on the input formats used to populate waypoint data.