Mapmaker Getting Started
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 ‘
For built-in types like
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 0x2Dxx are similar
to our new Ski Lift type. The last referenced object of this type listed in the
manual is 0x2D0B, so let’s take the next higher one in the series at 0x2D0C 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 ‘0x2D0C’ 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
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 0x08, priority 3) will be drawn on top
of a large urban area (Type 0x01, priority 1).
[_drawOrder]
;Type=POLYGON_CODE(HEX),PRIORITY
Type=0x01,1 ; Large urban area
>200k
Type=0x02,1 ; Small urban area
<200k
Type=0x03,1 ; Rural housing area
Type=0x04,1 ; Military base
Type=0x05,1 ; Parking lot
Type=0x06,1 ; Parking garage
Type=0x07,1 ; Airport
Type=0x08,3 ; Shopping center
Type=0x09,1 ; Marina
Type=0x0a,2 ; University/college
Type=0x0b,2 ; Hospital
Type=0x0c,2 ; Industrial complex
Type=0x0d,2 ; Reservation
Type=0x0e,2 ; Airport runway
Type=0x13,2 ; Building/Man-made area
Type=0x14,2 ; National park
Type=0x15,2 ; National park
Type=0x16,2 ; National park
Type=0x17,3 ; City park
Type=0x18,3 ; Golf course
Type=0x19,3 ; Sports complex
Type=0x1a,4 ; Cemetery
Type=0x1e,2 ; State park
Type=0x1f,2 ; State park
Type=0x20,2 ; State park
Type=0x28,1 ; Sea/Ocean
Type=0x29,1 ; Blue-Unknown
Type=0x32,1 ; Sea
Type=0x3b,1 ; Blue-Unknown
Type=0x3c,8 ; Large lake (250-600
km2)
Type=0x3d,8 ; Large lake (77-250
km2)
Type=0x3e,8 ; Medium lake (25-77
km2)
Type=0x3f,8 ; Medium lake (11-25
km2)
Type=0x40,8 ; Small lake (0.25-11
km2)
Type=0x41,8 ; Small lake (<0.25
km2)
Type=0x42,8 ; Major lake
(>3.3tkm2)
Type=0x43,8 ; Major lake
(1.1-3.3tkm2)
Type=0x44,4 ; Large lake
(0.6-1.1tkm2)
Type=0x45,2 ; Blue-Unknown
Type=0x46,2 ; Major river (>1km)
Type=0x47,2 ; Large river (200m-1km)
Type=0x48,3 ; Medium river
(20-200km)
Type=0x49,4 ; Small river (<40m)
Type=0x4c,5 ; Intermittent water
Type=0x4d,5 ; Glacier
Type=0x4e,5 ; Orchard/plantation
Type=0x4f,5 ; Scrub
Type=0x50,3 ;
Type=0x51,6 ; Wetland/swamp
Type=0x52,4 ; Tundra
Type=0x53,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 0x01 (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 4x4 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=0x01, 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 32x32 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 0x4F, 0x50 and 0x51. The black boxes
outline the 32x32 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 |
|
0x00 |
Unspecified |
0x12 |
Czech |
|
0x01 |
French |
0x13 |
Croatian |
|
0x02 |
German |
0x14 |
Hungarian |
|
0x03 |
Dutch |
0x15 |
Polish |
|
0x04 |
English |
0x16 |
Turkish |
|
0x05 |
Italian |
0x17 |
Greek |
|
0x06 |
Finnish |
0x18 |
Slovenian |
|
0x07 |
Swedish |
0x19 |
Russian |
|
0x08 |
Spanish |
0x1a |
Estonian |
|
0x09 |
Basque |
0x1b |
Latvian |
|
0x0a |
Catalan |
0x1c |
Romanian |
|
0x0b |
Galican |
0x1d |
Albanian |
|
0x0c |
Welsh |
0x1e |
Bosnian |
|
0x0d |
Gaelic |
0x1f |
Lithuanian |
|
0x0e |
Danish |
0x20 |
Serbian |
|
0x0f |
Norwegian |
0x21 |
Macedonian |
|
0x10 |
Portuguese |
0x22 |
Bulgarian |
|
0x11 |
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, 96x96 is a good size, as it scales well
to 24x24, 16x16, 12x12 and 8x8
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.
|
Search your city map: |
|