Follow

Geofiles

Graphics Information Files specification

Specification version 2.0


This section explains how to create graphic information files, also called GF files, or simple geofiles.

1. About GF Files

You can provide "graphic information" to Sygic FLEET in the form of a file consisting of variable-length records describing graphic shapes and elements (e.g. representing static linear objects).

Sygic FLEET will load and maintain a file as soon as you load it with SDK API function LoadGFFile. If function succeeds and GF file was correct , Sygic FLEET draws GF data on map. Data are not discarded until SDK API function UnloadGFFile is called.

Calling UnloadGF file in effect "clears" data loaded by LoadGFFunction. It won't erase data loaded by other GF files, only the unloaded one.

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

2. GF File Format

2.1. Basics of the File Format

The following rules apply to all the records of a GF file.

  • Multi-byte values are stored with least-significant-byte first.
  • Timestamps are specified as (4-byte) unsigned longs, representing seconds since midnight 01/01/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, they 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 to 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,
Including the 8-byte header
4 bytes Record ID (for future unique manipulation of this record)

 

2.2. Supported Record Types

 

TIMESTAMP (type 5): Specifies an "end-of-validity" for all the records that follow it (i.e. until the next timestamp record)

8 BYTES    HEADER
4 bytes End-of-validity timestamp
4 bytes Number of bytes (excluding this record itself) that can be
skipped immediately when end-of-validity is in the past
(note: this value can be set to 0 if you are lazy)

NOTE: Records NOT preceded by an end-of-validity are "permanently valid." Even so, it is highly recommended that you consider the issue of validity periods, and always make sure that the very first record of the file specifies the end-of-validity for the whole file.

SKIPPER (type 6): Specifies that the coming X bytes relate to a certain rectangle.

8 BYTES    HEADER
16 bytes Normalized coordinate rectangle of the area
4 bytes Number of bytes (excluding this record itself) that can be
skipped if rectangle doesn't overlap the current screen

NOTE: It is highly recommended, in the interest of processing speed, that you always provide a skipper record that specifies the surrounding-rectangle for all the rectangle-dependent records in the whole file together.

IGNORE (type 0): Records with type 0 are completely ignored by the application.

8 BYTES          HEADER
X bytes Ignored content

NOTE: Uses of this type of record range from permanent deletion (rather than de-activation) of records to watermarking copyright information into your files. However, please be aware that these records still consume memory, and also cost a very short amount of time that can be ignored.

LINE (type 1):

8 BYTES    HEADER
8 bytes Start coordinates of the line
8 bytes End coordinates of the line
4 bytes Line type (0=default)
4 bytes Red/Green/Blue color code of line

NOTE: The line type is defined by line thickness. The line thickness codes are:

  • 0 - width of road x 1.25
  • 2 - width of road
  • 6 - width of road x 0.75
  • 8 - width of road x 0.5
  • 12 - width of road x 0.25


POLYLINE (type 2):

8 BYTES          HEADER
                                                                        
16 bytes Normalized coordinate rectangle of the area around polyline
4 bytes Line type (0=default)
4 bytes Red/Green/Blue color code of lines
4 bytes N = number of co-ordinates (should be 2 or more)
N*8 bytes x/y-coordinates of the poly-line

NOTE: The line type field can contain the same codes as in the LINE (type 1) records.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments