.gm_style file format question

BoydBoyd Global Mapper UserPosts: 19Trusted User
edited August 2015 in Vector Data
I am working on a project that uses about 80 custom globalmapper area styles. The styles are very simple, they are solid fill colors with no border, no label, no transparency.... just solid colors. I'm using a database to assign the styles to area features by modifying a .dbf file associated with a shapefile.

Now I would also like to have my database modify a .gm_style file so that I don't have to manually change the area styles one at a time in globalmapper. I don't need to create new styles, just modify the fill color of existing styles. The fill color seems to be the first number in each record of the .gm_style file, but I can't quite figure out how to compute that number based on the color. It seems to be related to the decimal value of the color, but the pattern is not obvious to me.

Here are the results from the .gm_style file when I changed the color of an area style from black to white, red, green and blue. Any insight on how to compute these color values myself? I am using globalmapper 12 if that matters.

(BLACK) AREA,"test",193,208,0,255,"~0~534799372~0.000~0~0",2097152,32768,0
(WHITE) AREA,"test",-63,208,0,255,"~0~534799372~0.000~0~0",2097152,32768,0
(RED) AREA,"test",-16777023,208,0,255,"~0~534799372~0.000~0~0",2097152,32768,0
(GREEN) AREA,"test",16711873,208,0,255,"~0~534799372~0.000~0~0",2097152,32768,0
(BLUE) AREA,"test",-16777023,208,0,255,"~0~534799372~0.000~0~0",2097152,32768,0

In case this wasn't clear... globalmapper seems to be using the following color values in the style file. How are they computed?

BLACK = 193
WHITE = -63
RED = -16777023
GREEN = 16711873
BLUE = -16777023

Best Answer

  • bmg_bobbmg_bob Global Mapper Programmer Posts: 2,093
    Answer ✓
    Using your sample:


    the first number (65473) defines how the area will be filled, and the second number (208) defines the border style. The border is a line style, and there is discussion of how it is calculated in this thread.

    The color calculation is the same for both area and line style definitions. Starting with an RGB definition, the calculation is as follows (R is the Red value, G is the Green value, and B is the Blue value):
    Color = (R * 16777216) + (G * 65536) + (B * 256) 
    The area info also contains style information and the style values get added to the color value. The style information is:
    • Fill Style - indicates how to fill the area. Values are listed below.
    • Use Default Render Label - Value is 64 if you want to use this option, 0 if you don't.
    • Render Label - Value is 128 if you want to use this option, 0 if you don't.
    Fill Style Values:

    No Fill (hollow) = 0 (color will be ignored)
    Solid Fill = 1

    // Hatched patterns
    Back Diagonal Hatch = 2,
    Crosshatch = 3,
    Diagonal Crosshatch = 4,
    Forward Diagonal Hatch = 5,
    Horizontal Hatch = 6,
    Vertical Hatch = 7,

    // Other Patterns
    Sand Pattern = 8,
    Intermittent Water Pattern = 9,
    Salt Pattern = 10,
    Coral Pattern = 11,
    Black Cross Pattern = 12,
    Black Dot Pattern = 13,

    So the number in your example is calculated as follows. Blue is RGB(0,0,255), and the style is a solid fill(1), that includes both render options (64 and 128):
    (1 + 64 + 128) + (0 * 16777216) + (0 * 65536) + (255 * 256)  = 65473
    In your sample data, some of the values are negative. That is an artifact of the way the numeric data is converted to text to be stored in the gm_style file. If you use the formula here, you will not get any negative numbers, but the numbers you get should still work. (Note that you can not simply remove the negative sign.)

    I hope this helps.


  • BoydBoyd Global Mapper User Posts: 19Trusted User
    edited August 2015
    Oops, there was a mistake in what I posted above. For blue, the correct gm_style is


    So BLUE=65473

    Here's a spreadsheet showing hex and decimal values for several colors - I know how to calculate these from RGB. The column on the right (highlighted in yellow) is the value that globalmapper inserts in the .gm_style file. That's where I'm stumped :)
  • BoydBoyd Global Mapper User Posts: 19Trusted User
    Looks like I have it figured out. I'm sure there is a more elegant solution, but given values for red, green and blue, this code (FileMaker Pro) works with everything I've tried so far. :smile:

    Case (
    red < 128; 193 + red*16777216 + green*65536 + blue*256 ;
    red *- 16777216 + (red-128)*33554432 + green*65536 + blue*256
  • BoydBoyd Global Mapper User Posts: 19Trusted User
    edited August 2015
    Thank you so much for the detailed answer! I now understand why black had the value of 93 (1 + 64 + 128) :) My reverse-engineered version generates values with the "artifact" you mentioned, and they seem to work fine. But I am now using your algorithm and that works also, so will stick with it.

    But I am seeing one oddity. 12 out of my 83 custom types are not importing correctly. I don't see a pattern... here are three examples from the file I generated that contain different solid grayscale colors. The RGB values for lu04=128,128,128, lu05=170,170,170 and lu06=213,213,213


    In Globalmapper, these areas all appear with no fill and a color of 127,255,255. If I export the gm_style file from Globalmapper, these three entries have been changed to this


    As I said, the other 71 area styles in my file are correctly imported by globalmapper. Any clue what is happening here? Could this be a bug?... remember I am still using Globalmapper 12. For now I am just manually changing the bad styles... 71 out of 83 ain't bad! :)

    Thanks again for your help!
  • BoydBoyd Global Mapper User Posts: 19Trusted User
    edited August 2015
    After manually changing the bad styles individually in globalmapper, I exported them to another gm_style file and compared the results with the styles I generated. There was a pattern to the bad styles - they all had negative values - this seems to happen when red has a value greater than 127. So I switched back to my old kludgy algorithm that generates colors with negative values.

    That was close, but the color values still didn't match. Comparing the two files, I found that my kludgy algorithm was generating negative numbers that were all off by 241. So I kludged the algorithm even further and now it works perfectly. If the red value is greater than 127, I calculate the color as follows (makes the programmer in me cringe, but it works, lol). :D

    241+( red *- 16777216 + (red-128)*33554432 + green*65536 + blue*256)

    Now my next task is writing some code that will generate a Garmin .typ file to match the custom gm_styles. :)
  • bmg_bobbmg_bob Global Mapper Programmer Posts: 2,093
    Upon further review, it appears that you do have to be concerned with colors that have a Red component that is 128 or higher. If you use unsigned values greater than 2147483647, they will get truncated. I would not call this a bug since these values are written out and read back in successfully by Global Mapper, and are not intended to be created by hand. Your best bet is to use GM to write out the style information when you need to use large red values.

    Here are corrected versions of the style strings you posted earlier:

  • BoydBoyd Global Mapper User Posts: 19Trusted User
    edited August 2015
    Thanks again, but those values do not quite agree with what my version of globalmapper inserts into the gm_style file for those colors. This is what I get


    The kludgy algorithm I posted above generates these values correctly and they are imported into globalmapper with the desired colors and style. I don't pretend to understand why this works, but it does. :)

    Naturally I understand that globalmapper wasn't intended to be used with another application that generates custom styles, so I didn't intend my comments as criticism. But it greatly simplifies some of my projects to be able to generate a large number of styles quickly so that I can modify them frequently.

    I do appreciate your taking the time to help with this!
Sign In or Register to comment.