Table of Contents
Advertisement
7. Graphic Information Files
This section explains how to create graphic information files, also called GF files.
7.1. About GF Files
You can provide "graphic information" to TomTom Navigator in the form of a file consisting of
variable−length records describing graphic shapes and elements (e.g. representing dynamic situations such
as traffic conditions).
TomTom Navigator will load and maintain such a file as soon as you pass it the path name of the file,
using the routine UseGFFile. When this routine returns, TomTom Navigator will have discarded any
previous files, and will have loaded the new file into memory. The caller is thus free to delete or change the
file after having called this routine.
Calling UseGFFile with an empty name, or with the name of a non−existent or empty file, in effect
"clears" any previously loaded data.
For any change in the situation (e.g. the traffic situation) either call EnableGFRecord with the unique id
of some record you want enabled or disabled, or call UseGFFile with the name of a new or adjusted file (or
with the empty string as filename, which effectively deletes all the current records).
Caveats:
On general principles, it is recommended that you "refresh" files relating to traffic information every 15
minutes even if there are no changes. On the other hand, there are obvious disadvantages to refreshing files
too often, e.g. every few seconds, in terms of power drain, application speed degradation etc.
Tips:
For some applications, it may be useful to switch between a limited set of pre−defined, fixed files. For
some applications, it may be useful to use a single pre−defined file, of which records are "enabled" or
"disabled" by the simple action of stamping them with an "end−of−validity" in the past resp. the future.
7.2. GF File Format
7.2.1. Basics of the File Format
The following rules apply to all the records of a GF file.
• Multi−byte values are stored least−significant−byte first.
• Timestamps are specified as (4−byte) unsigned longs, representing seconds since midnight 1/1/1970.
• Coordinates are stored as (4−byte) signed longs, representing WGS84−coordinates in degrees
multiplied by 100,000. The coordinates of a point are stored in the order: x, y.
• Strings (including filenames) are stored in ASCII format, are zero−terminated, and contain at most
254 non−zero characters.
• Rectangles must be "normalized", i.e. the four co−ordinates are in the following sequence:
minimum−x, minimum−y, maximum−x, maximum−y.
• Every record must have the same 8−byte "header" and must be a multiple of 4 bytes in length.
The "header" must be as follows:
1 byte
Type of this record, which is a value between 0 and 127.
When the most significant bit of this byte is set (>=128),
it indicates that the record is disabled
3 bytes
Length of this record as a number of 4−byte words,
48
Advertisement
Table of Contents
