Digital Mobile Map

Tutorial 2b – Custom Types in GM8

Goals for this section

- Understanding Custom Types in GM8

- Understanding Custom Types in cGPSMapper

So far we’ve downloaded data from the Internet, digitized some roads and local features, generated topographic contour data, and downloaded iterations of our map into our GPSr. The next area we’ll address is Custom Types.

Custom types allow you to control the appearance of your on-screen data. Custom types can be as simple as changing the representation in GM8 of how a road looks, or as complex as changing the internal representation of a Garmin data type in your GPSr. We’ll cover the entire range of possibilities in this section.

Let’s begin with altering the look of displayed data in GM8. Each standard type in GM8 has a default visual representation used when rendering that type onscreen. For example, press Alt+D to enter Edit Mode in GM8, then double-click on Highway 89.

In the Modify Feature Info dialog, we have two choices for the Feature’s rendering style:

- ‘Use Default Style for the Selected Feature Type’ (the current selection), or

- ‘Specify Style to Use When Rendering Feature’.

A style specified in this dialog is local to the selected Feature(s). This modified style is not globally available to use with other Features.

Click the ‘Specify Style to Use When Rendering Feature’ radio button, then click ‘Customize Style’.

In this dialog, I’ve changed Width from 2 to 3, and Color from red to blue.

Click OK, and the changes are applied to the currently selected Feature(s). If you wish to revert to the standard rendering style for this line, simply reopen this dialog by double-clicking on the Feature, then click the Feature Style radio button labeled ‘Use Default Style for Selected Feature Type’.

We can also change the default rendering for the default Feature Types. This will affect all objects of a given Feature type.

In the menu, select Tools | Configure… This brings up the Configuration dialog. Click the ‘Line Styles’ tab, then scroll to ‘Residential Road’.

For built-in types like Residential Road, you can alter the line width, the color of the lines, and the appearance of the font used to label the Feature. Uncheck the ‘Display Roads As Fat Lines When Zoomed In’ checkbox, then try different styles for Residential Roads. Click the Apply button to see your changes. Note that all Residential Roads are affected by a change made in this dialog.

Finally, let’s create a new Feature Type.

In the Configuration dialog, click the ‘Point Styles’ tab, then click ‘New Type’. Enter ‘Ski Lift’ as the Type Name, and select ‘Skiing’ as the symbol.

Now we have a new custom Ski Lift feature available to use in our map, but cGPSMapper doesn’t know anything about Ski Lifts. We need to provide some Type information for this object.

Consulting the cGPSMapper manual at http://cgpsmapper.com/manual.htm we see in section 8.3.1, POI Types, that objects of type 0×2Dxx are similar to our new Ski Lift type. The last referenced object of this type listed in the manual is 0×2D0B, so let’s take the next higher one in the series at 0×2D0C for our custom Ski Lift type.

With ‘Ski Lift’ selected in the Configuration dialog, click the ‘Attributes’ button to add a default attribute whenever objects of Type ‘Ski Lift’ are created.

Click ‘Add Attribute…’ and enter ‘MP_TYPE’ as the Attribute Name, and ‘0×2D0C’ as the Attribute Value. Exit all the dialogs.

Zoom in near the area of the Snow King Resort. About two blocks left of the Snow King Resort in Phil Baux Park, just SE of the baseball diamond is the ski lift. In Edit Mode, right-click to Add New Point/Text Feature, then click at the location of the lift and create Phil Baux Park as a new Point Feature of type Ski Lift.

What Undefined Type Values are Safe to Use?

If your map will be used in conjunction with a commercially available map, then you should pay attention to the standard data types by checking the cGPSMapper manual before adding your own data type. The worst that could happen is that there are other objects sharing the same type in the other maps loaded on your GPSr, which could cause some confusion.

If your map is intended to be used alone, without depending on a Garmin basemap or other user-loaded maps, then you have much more latitude in using Type IDs as you wish. However, it’s a good idea to stay close to the existing scheme in case you want to integrate your map with another in the future. Scan the various pre-assigned types in the cGPSMapper manual so you’re familiar with the general categories.

Custom Types in your GPSr

So far we’ve discussed modifying the representation of your objects within GM8 on the computer. It’s also possible to modify the representation of objects in your GPSr. This capability is limited to recent Garmin models. At this time, GM8 does not support the full range of possible presentation styles available in the GPSr, but you can get pretty close.

Tutorial 2c – Creating Custom Types with cGPSMapper

Goals for this section

- Understand how custom type files are created for a compatible GPSr

- Create a simple custom type file with cGPSMapper

- Download a map with a custom type file to your GPSr

The source file for custom type definition is very similar to a conventional .MP Polish format source file, but with different declarations applying specifically to bitmap descriptions for your custom types, plus instructions on the draw order for area objects. We will refer to these source files as .MPT, or .MP type files. The compiled version of the file has a .TYP suffix.

At a minimum, your .MPT file will contain a [_ID] section, a [_drawOrder] section, and one or more custom definitions for objects – [_point], [_line] or [_area].

There is currently no GUI editor for .MPT files – you’re going to have to roll up your sleeves and create your own using a text editor, graphics editor and reference materials. Let’s get started.

[_ID] Section

[_ID]

ProductCode=1

FID=888

[END-ID]

This declaration goes first in your .MPT file. Its most important function is to tell cGPSMapper your Family or Product ID (FID), corresponding to a similar FID declaration in your Preview source file. This keeps your various map elements connected to one another in MapSource. 888 is a generic FID often used by beginning map makers; it’s unlikely that you will have a collision with another map of this FID on your own system. If you are considering creating maps for distribution, there is an unofficial database and registry for FIDs at

http://www.keenpeople.com/index.php?option=com_maplist&Itemid=78

[_drawOrder] Section

At a minimum, your .MPT source file must define the draw order for ALL polygon types in your map, not just your custom ones. Even if you don’t define any custom polygon types in your source file, this section is mandatory. If a polygon type is not defined in the [_drawOrder] section, it will not be rendered on your GPSr. If a polygon type is not showing up, check to make sure that it is listed in your [_drawOrder] section, and that it has a higher priority number than any other overlapping polygons.

Each statement in the [_drawOrder] section includes the hex ID of the defined polygon type and its relative draw order. Higher numbers are rendered later. Therefore, a polygon defined with a priority of 1 will be drawn first, and overwritten by an overlapping polygon defined with a higher number (2-8). Priority numbers are between 1 and 8. For example, in the [_drawOrder] section below, a Shopping center (Type 0×08, priority 3) will be drawn on top of a large urban area (Type 0×01, priority 1).

[_drawOrder]

;Type=POLYGON_CODE(HEX),PRIORITY

Type=0×01,1 ; Large urban area >200k

Type=0×02,1 ; Small urban area <200k

Type=0×03,1 ; Rural housing area

Type=0×04,1 ; Military base

Type=0×05,1 ; Parking lot

Type=0×06,1 ; Parking garage

Type=0×07,1 ; Airport

Type=0×08,3 ; Shopping center

Type=0×09,1 ; Marina

Type=0×0a,2 ; University/college

Type=0×0b,2 ; Hospital

Type=0×0c,2 ; Industrial complex

Type=0×0d,2 ; Reservation

Type=0×0e,2 ; Airport runway

Type=0×13,2 ; Building/Man-made area

Type=0×14,2 ; National park

Type=0×15,2 ; National park

Type=0×16,2 ; National park

Type=0×17,3 ; City park

Type=0×18,3 ; Golf course

Type=0×19,3 ; Sports complex

Type=0×1a,4 ; Cemetery

Type=0×1e,2 ; State park

Type=0×1f,2 ; State park

Type=0×20,2 ; State park

Type=0×28,1 ; Sea/Ocean

Type=0×29,1 ; Blue-Unknown

Type=0×32,1 ; Sea

Type=0×3b,1 ; Blue-Unknown

Type=0×3c,8 ; Large lake (250-600 km2)

Type=0×3d,8 ; Large lake (77-250 km2)

Type=0×3e,8 ; Medium lake (25-77 km2)

Type=0×3f,8 ; Medium lake (11-25 km2)

Type=0×40,8 ; Small lake (0.25-11 km2)

Type=0×41,8 ; Small lake (<0.25 km2)

Type=0×42,8 ; Major lake (>3.3tkm2)

Type=0×43,8 ; Major lake (1.1-3.3tkm2)

Type=0×44,4 ; Large lake (0.6-1.1tkm2)

Type=0×45,2 ; Blue-Unknown

Type=0×46,2 ; Major river (>1km)

Type=0×47,2 ; Large river (200m-1km)

Type=0×48,3 ; Medium river (20-200km)

Type=0×49,4 ; Small river (<40m)

Type=0×4c,5 ; Intermittent water

Type=0×4d,5 ; Glacier

Type=0×4e,5 ; Orchard/plantation

Type=0×4f,5 ; Scrub

Type=0×50,3 ; Forest

Type=0×51,6 ; Wetland/swamp

Type=0×52,4 ; Tundra

Type=0×53,5 ; Sand/tidal/mud flat

[end]

Custom Type Definitions

Your custom type definitions will replace the default imagery on your GPSr or in MapSource. All other objects will be rendered with their default imagery.

[_point] Definitions

Points (POIs) define your replacement bitmap for the associated Point type using the XPM format. For example,

defines a daytime replacement image for POI type 0×01 (Large city). The rendered image will be a 16 pixel square rectangle with a 1 pixel black border and a transparent interior, as shown in the rendering above.

In addition, you may also specify up to four language strings defining the default label for the Point type. This label is displayed when the cursor is over an unlabeled object. For example,

defines the string ‘Large city’ when the GPSr is set for English, and ‘Ciudad grande’ when the GPSr is set for Spanish.

Point bitmap definitions may be up to 24 x 24 pixels and 254 colors. There may be different definitions for the daytime bitmap and the nighttime bitmap. For nighttime definitions, use Nightxpm=. If you do not use Nightxpm=, the DayXPM= or simply XPM= definition will be used for both day and nighttime rendering.

The first line of the definition describes the bitmap dimensions, number of colors, and number of ASCII characters used to represent each pixel. We will use the following Point definition to illustrate the individual parts of the definition:

Dayxpm=”4 4 2 1” declares this definition to be 4 pixels wide x 4 pixels tall, with 2 defined colors, and 1 character representing each pixel in the bitmap.

Bitmap colors are defined using hex RGB values. Each color should be declared explicitly – cGPSmapper does not support reserved literals representing standard colors. The only literal allowed is None for transparent pixels.

The first character is the ASCII character used to represent the associated color in the bitmap. In this example, we are using a space to represent transparent pixels and an ‘X’ to represent black pixels. Next is a tab, then the letter ‘c’ which indicates a color definition follows, followed by a space, ‘#’, then the hex RGB color value.

Following the color declarations is the bitmap description:

This XPM bitmap describes a 4×4 rectangle with a black 1-pixel border and a transparent center.

[_line] Definitions

Line definitions are used to replace the standard line types, including roads. There are two ways to define a line. You may either declare the line’s color and thickness attributes for its interior and border, or you may provide a custom bitmap. Both methods allow transparency in the definitions.

Method 1: Declare a line thickness and border thickness.

The [_line] definition above specifies a replacement rendering for lines of Type=0×01, a Major highway. LineWidth is specified as 5 pixels, BorderWidth is specified as 1 pixel.

This statement indicates that there is no associated pixel bitmap, only color definitions. This is because we are using LineWidth= and BorderWidth= instead of a bitmap. There are 4 colors defined, 2 for daytime, and 2 for nighttime.

When describing lines using LineWidth and BorderWidth, note that the color declarations use a different format. The first character represents either daytime interior (1), daytime border (2), nighttime interior (3) or nighttime border (4).

As with POIs and polygons, you may use up to four language substitution strings for the generic type description.

Method 2: Describe a bitmap using XPM:

The first line of this xpm declaration indicates a definition 32 pixels wide, 5 pixels tall, with 4 colors, using 1 character for the pixel representations in the bitmap. This declaration uses a transparent background, represented by the space character in the ASCII bitmap. In the image above, notice that the transparency reveals the texture and color underneath the line.

[_polygon] Definitions

Polygon definitions are limited to 32×32 xpm bitmaps using of 2 colors each for the daytime and nighttime definitions. They are tiled when rendered.

In this screen capture from a Garmin nüvi, four polygon types are shown. The tile on the left is a custom definition (described below), and the following three are standard types 0×4F, 0×50 and 0×51. The black boxes outline the 32×32 tiles. Notice that the leftmost tile uses two colors, while the next three tiles use one color plus transparency.

You may define 2 colors, which will be used for both day and night rendering, or 4 colors with colors 3 and 4 used for nighttime rendering.

Name substitution

You may create up to 4 default names associated with different languages to be displayed if the object does not have a label. For example:

Code	Language	Code	Language
0×00	Unspecified	0×12	Czech
0×01	French	0×13	Croatian
0×02	German	0×14	Hungarian
0×03	Dutch	0×15	Polish
0×04	English	0×16	Turkish
0×05	Italian	0×17	Greek
0×06	Finnish	0×18	Slovenian
0×07	Swedish	0×19	Russian
0×08	Spanish	0×1a	Estonian
0×09	Basque	0×1b	Latvian
0×0a	Catalan	0×1c	Romanian
0×0b	Galican	0×1d	Albanian
0×0c	Welsh	0×1e	Bosnian
0×0d	Gaelic	0×1f	Lithuanian
0×0e	Danish	0×20	Serbian
0×0f	Norwegian	0×21	Macedonian
0×10	Portuguese	0×22	Bulgarian
0×11	Slovak

Creating XPM bitmaps

If you want to create anything other than the simplest shapes for your custom Points and Areas, you will want to use a graphics tools to manage your source bitmaps and output your XPM definitions. The following workflow description uses Photoshop Elements, IconXP and Microsoft Word. This is certainly not the only way, but it works.

Photoshop:

• Create the original full-color image. You may find it easier to edit the image at a multiple of its target size. For example, 96×96 is a good size, as it scales well

to 24×24, 16×16, 12×12 and 8×8 nicely. Or, you can edit at the target dimensions.

• Create your transparent areas as desired.

• Resize as needed to your target dimensions.

• Save in png-24 format with transparency.

IconXP steps:

• Go to http://www.aha-soft.com/iconxp/index.htm to download a trial version of IconXP. (The registered version is $20US)

• Open your .png file saved from Photoshop.

• Export As ..XPM

Microsoft Word steps:

• Open the .XPM file.

• Look for any instances of color definitions using black or white; replace them with #000000 or #FFFFFF. cGPSmapper does not support these literals.

• Copy the definition and paste into your source file, starting with the quotation mark before the first line of the declaration, all the way to the closing brace.

Text Editor steps:

• Add the necessary header, type, strings and [end] statements.

Putting it all together

• Create a .MPT file with your custom type definitions.

• Compile your custom type file with cGPSmapper, using the typ switch: cGPSmapper typ <YOURCUSTOMTYPES>.MPT

• Use Sendmap 2.0 to combine your .IMG file and your .TYP file into a single upload or GMAPSUPP.IMG.