This Guide provides additional explanations on how to create your own maps using the GPSmapper freeware (http://gps.chrisb.org/gps_mapper.htm). It is assumed that you have studied my UMP: Getting Started (available from the above-mentioned site) and know how to make simple maps and upload them to a Garmin’s GPS receiver with map memory.

Until now, your maps were created completely manually, i.e. you had to enter coordinates of points and object vertices as numbers, using a text editor. It is a laborious process if you have more than, say, a dozen coordinate pairs. To facilitate this process, the cGPSmapper map compiler accepts files imported from OziExplorer (http://www.oziexplorer.com). It is one of the most popular tools for defining objects (such as waypoints, routes, and tracks) on scanned maps and uploading those objects to a GPS receiver.

To make things more clear, in the examples given below files are imported directly to the main map file. However, in a real-world project it is often more convenient to split the whole data set into a number of modules, each of which deals with a different aspect of your map, such as cities/towns, land cover, water, POIs, land contour, etc., or with a different sub-area. Each of such aspects or sub-areas may be kept in a separate file, perhaps maintained by a different person. To include such files into the main map file, use the [FILE]...[END-FILE] section. Insert this section just after the header (the [IMG ID]...[END-IMG-ID] section). For example, the following section:

has the same effect as inserting the body of the two files, water.txt and towns.txt, directly into your map file. Of course, you can insert as many files as you need.

Instead of manually creating a series of [RGN10] or [RGN20] sections (for POI objects or non-POI point objects, correspondingly), you may define corresponding waypoints in OziExplorer and save them to a .wpt file.

Such a file may be imported using the [WPT]...[END-WPT] section. For example, suppose you’ve created the bus_stations.wpt file with 12 waypoints. The section:

creates 12 points of interest (RgnType=0x10), each of them being a bus station (Type=0x2f08). (The meaning of the Levels parameter is explained in Section 5 Object visibility below.)

creates as many non-POI objects as there are waypoints in the small_towns.wpt file, each object being a small town (Type=0x0c).

The efficiency boost achieved by importing OziExplorer files is even more visible when you use .plt files to define linear and area objects. The following example section imports the file yellow_trail.plt, containing perhaps hundreds of track points created in OziExplorer, defining a trail:

Pay attention to the Label parameter. It defines the object label, because (unlike waypoints) tracks and track segments are not individually named.

Similarly as with waypoint files, you may define several linear objects in one .plt file. To do this, create a track consisting of a number of segments. Each track segment will correspond to a separate object. As before, all objects in one file must be of the same type, which is defined by the Type=... parameter.

It is also possible to have a different label for each of the objects (track segments) in the file. To achieve this, create a separate file with the same name and the .plt.txt extension, then enter into it the corresponding number of lines, each containing one label. For example, if you have the file alleys.plt containing three segments for three alleys, create the alleys.plt.txt file containing, say, the following three lines:

To import area objects, do it in a similar way, only use RgnType=0x80.

By default, the height is defined in feet. To define the height in meters, use the following parameter in the map header (i.e., in the [ID]...[END-ID] section):

The height is defined not as a distinct parameter, but in the object name, separated from the rest of it by the ~[0x1f] delimiter. The following section defines a summit with the defined height of 2499 meters (provided that the Elevation=m parameter is defined):

The number of visibility layers in the map is defined by the Levels=... parameter in the header.

Note: The number of layers defined by the Levels=... parameter must be one more than the actual number of layers you use. In other words, no objects may belong to the highest layer which always remains empty.

Following the Levels=... parameter, there are parameters Levelx (where x is 0 through 9) which define zoom levels for individual layers. For example, the following header specifies that the map has four (Levels=4) visibility layers (out of which only three may be used for placing objects) and defines their corresponding zoom levels:

The numeric values in the Levelx parameters specify the visibility in terms of so-called display grid expressed in fractions of degrees, according to the formula Grid = 360*2^-n (where n is the value provided in the Levelx parameter). In practice, it is more convenient to use the following approximate table (valid for normal settings in the GPS unit):

For example, with the layers defined as in the header above, objects belonging to the lowest layer (Level0=22) will be visible when you zoom the map to 500 m or closer, while objects belonging to the second layer (Level2=19) will be visible when you zoom out to 3 km.

Each object belongs to the layer indicated by the Datax or Filex parameter with which the object is defined. For example, the objects defined with the parameter:

If you want to have the object visible in more than one layer (as is often the case), you don’t need to define the object multiple times. Instead, use the Levels=... parameter in the object definition. For example, the section

The -p option causes the program to wait after execution until the user hits a key.

A.: Due to a quirk in the present version of software, if the map ID (defined in the ID=... parameter) is numeric only, you see the title (defined in the Name=... parameter) twice in the receiver’s menu, and if the map ID is non-numeric, you don’t see the title at all.