Custom area feature types

drnick

I would like to be able to create custom area feature types and manipulate their color rendition outside of GM. it appears in principle that the way to do this is by editing the custom_area_types.txt file, but I cannot figure out how the fill-color information is stored in that file. It looks like it is in column two, but in what format?

Thanks for any guidance,

Dr. Nick

global_mapper

Dr. Nick,

The fill color is in the second column. It is stored as a 32-bit integer created as follows:

Alpha * 16777216 + Blue * 65536 + Green * 256 + Red

Note that an alpha of 0 is treated as completely opaque as is an alpha of 255, so you can just ignore the alpha if you don't want a translucent area.

Let me know if I can be of further assistance.

Thanks,

Mike
Global Mapper Support
support@globalmapper.com

drnick

Seems more complicated than that though. When I generate from within GM feature types with pure red, green, blue, or black solid fills I get this in the custom_area_type file:

"TestGreen",16711681,208,0,255,"~0~534799372~0.000~0",0,32768
"TestBlue",65281,208,0,255,"~0~534799372~0.000~0",0,32768
"TestBlack",1,208,0,255,"~0~534799372~0.000~0",0,32768
"TestRed",-16776975,208,0,255,"~0~534799372~0.000~0",0,32768

so it looks like green*65536 +blue*256 +1, and so I just don't know what to do with red. Have played around a little with the 32nd bit, but have not hit paydirt.

Dr Nick

global_mapper

Dr. Nick,

Sorry, I completely mis-spoke earlier. I was thinking of in-memory colors. In the custom_area_types.txt file the 2nd value is the color and some additional style flags. The bit breakdown is as follows:

Bits 0-3: Area Fill Style
Bits 4-7: Other label-related flags (you'll just want 0)
Bits 8-15: Blue Color
Bits 16-23: Green Color
Bits 24-31: Red Color

Let me know if I can be of further assistance.

Thanks,

Mike
Global Mapper Support
support@globalmapper.com

drnick

So first, I should no doubt have specified that I am talking about v. 8.03 of GM; perhaps this changed radically in v. 9, but in any case, between yr hint that the color is represented as a 32 bit integer, and mine that yr formula (at least for v. 8) is off a bit, or a byte, I see that the color is represented by the
decimal equivalent of RGB in the _usual_ hex representation padded with "01" in the last two places. That is, the color is represented as the dec. equivalent of "RRGGBB01" where RR, GG, BB would be hex numbers between 0and FF. But any color with red more intense than 7F runs into the sign bit of the 32 bit integer, and the dec. equivalent is then RRGGBB01-2^32, so to speak.

Same in v. 9??

Dr Nick

global_mapper

The lower 8 bits are always '01' in your case since you have the style set to fill (lower 4 bits is 1) and the other 4 label style bits are their default value, which is 0. All filled area styles should have the last digit set to '1'.

The rest of your analysis is correct. The 32-bit value is written out as a signed value, so you are correct that any red values greater than 7F result in a negative number. If you are programatically changing this, just cast to an unsigned value and work with that.

Let me know if I can be of further assistance.

Thanks,

Mike
Global Mapper Support
support@globalmapper.com