How do I make residential areas visible on my Garmin GPSr?

Okay, I’ve been working steadily on making custom maps for my Garmin Montana for a while now and have had some success. I’ve been able to customize highway colors and widths, add custom icons for Buddhist wats, the vending machine fuel stations so common in Thailand, and a few other POIs but there are many other things I want to do that I cannot seem to accomplish. For example, I want to make residential areas (landuse=residential) visible just as they are on the OSM slippy map. My understanding about how the various components of the map compilation process interact (TYP files, styles, internal Garmin codes) is far from complete and I’m hoping that an explanation of how solve this issue will help.

I’m using the TYP file and generic_new_styles provided by Lambertus as my starting points. I’ve modified both of these to meet my needs but the residential area will not render no matter what I do. The TYP file I’m using (24983.TYP) contains not one but two residential polygon definitions, an 0x0200 and an 0x0300 type both of which are labeled “residential”, and neither of which works to make such areas visible. In addition, the polygon style file contains this line:

landuse=residential [0x10 resolution 18-22]

which agrees with the Garmin type code for “city” from this page: http://wiki.openstreetmap.org/wiki/GroundTruth_Standard_Garmin_Types. However, there is no type 0x100 (or 0x0100) polygon in the 24983.TYP file. (Confusingly, TYPViewer adds an extra zero to these codes). Even if I redefine one of those two existing TYP definitions to match the code in the style file, it does not render. In a fit of desperation I tried to use the type for man_made polygons (type 0x3900) but there are directives at the head of the style file that might prevent using this code for man_made items that are also areas:

man_made=* & area!=no
& (man_made!=door & man_made!=embankment & man_made!=breakwater
   & man_made!=cable_line & man_made!=cutline & man_made!=cutting
   & man_made!=groyne & man_made!=reinforced_slope
   & man_made!=levee & man_made!=trench)
[0x39 resolution 24]
man_made=* & area=yes
[0x39 resolution 24]

The syntax is a bit muddy in my mind but I think this means apply type 0x39 to man_made items that are also an area UNLESS they are one of the following: door, embankment, breakwater … trench, etc. In any case, defining a landuse=residential with type 0x39 does not render. Is this due to the location of the above code segment, i.e., at the top of the styles list? Anyone care to contribute to my understanding of that code segment?

I should mention that residential areas are not visible either in Basecamp or my Montana GPS on the generic_new_style map of Thailand from Lambertus.

What’s going on? Why doesn’t Lambertus’s map render residential areas? And, more importantly, how can I force my own maps to render them?

Thanks,
Dave

Try to make this change in style:

landuse=residential [0x10 resolution 18]

Standard definition in style causes residential area to disappear at bigger zoom.

If I look in the typ file the polygon for residential is 0x10 and is rendered, but with a low draw order (3). Maybe it is hidden under another polygon layer?
It also disappears on the highest zoom level, because in well mapped areas there will be buildings visible.

Whereas in not well mapped regions you got nothing. I prefer to see residential areas, especially on maps for automotive use.

Wow, that worked! I’ve been struggling with this for quite a while so I owe you many thanks. Since there is no 0x10 polygon in the TYP file could you tell me where that “style” comes from?

I’ve made some custom icons for various fuel stations that are common here but are different from the normal fuel stations. Finding a code that will work to display those custom icons is very difficult. I keep substituting codes until I find one that works. Yet, there must be hundreds of these codes that the Garmin firmware “knows about”.

The type code I use for my fuel-vending-machine is 0x02f0f, which TYPViewer tells me is for Garmin dealers, a POI I will never need in Thailand. Another code I tried is the one for County Council(NT), code 0x1101a, but it does not work for my intended use. In the TYPViewer interface there is a drop-down list of POIs that include hundreds of “Customizable Points”. I’ve been able to use one of these successfully but many others I tried simply do not work.

Is there a way to know in advance which POI codes (or polygon or line codes) one can use without all the guesswork?

And I’m still wondering why the Lambertus maps don’t render the residential areas. This would clearly be a useful feature IMO.

Thanks again,

Dave

Well, it is you, who posted exempt form a style. Similar rule is included in standard style from mkgmap.

Hints from TYPViewer are a good source. But there is no single standard, since each model of Garmin GPS behaves differently. See:
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types

Can you be a bit more specific? I agree, there is a landuse=residential style in my generic_new_styles folder but how do I alter the color of that 0x10 style, or make it display differently at night? It seems I must also define a corresponding polygon in the TYP file where I can change those parameters. Is that true? And why don’t either of the pre-existing polygons in the 24983.TYP file act to render the residential areas?

As for the table in the Wiki you mentioned; I’ve looked at it many times before. Unfortunately it is very out-of-date and makes no mention of either Basecamp or the Montana.

As I said in my original post, I have not found much help in understanding how these things work together so I’m wondering is there anywhere I can read a description of what happens when mkgmap runs? Something like, "when mkgmap encounters a specific tag in the OSM data it first looks in the style file to see if any of the definitions apply, and if so it looks next in the TYP file to see how … " Throw in the other fact about Gamin units behaving differently and what you have is a very confusing situation. How any of these maps come out looking good is a total mystery to me.

Please be as verbose as you can in your reply. Thanks in advance for you time and attention.

Dave, there is a 0x10 polygon in the typ file.
Look in the Typviewer list of Polygons for 0x010, it comes after 0x00f. In the text field you see

[_polygon]
Type=0x10
String1=0x04,residential
etc

It took me ages of trial and error to understand a bit, so please be patient… :wink:

Ah, the extra zero trick strikes again! Actually, it’s TYPwiz that shows the correct number, not TYPViewer. I don’t see any text like you show in TYPViewer unless I’m missing something in its interface. I would use TYPWiz for that reason alone but I prefer the way TYPViewer handles the rest of the job. Why TYPViewer insists on that extra zero is one of the weirdest things I’ve ever seen in a programming interface. 0x01 is NOT the same as 0x10!

At any rate, thank you ligfietser for your help. I’m sorry if I seem impatient. I know learning something new takes a while but this process is extra hard because we’re trying to build a map for a device whose internals are a black box. No surprise there. Garmin income depends on keeping such details secret. Too bad there’s not an open source operating system for Garmins. Now that would be something!

Any clues as to why I’m seeing a pale yellow background? It’s not annoying, in fact I rather like it, but I would like to know where it’s coming from.

In the OSM Generic New the background is polygon 0x10101. Pale yellow is the default garmin background.

[_polygon]
Type=0x10101
String1=0x04,land
ExtendedLabels=Y
FontStyle=NoLabel (invisible)
CustomColor=No
Xpm=“0 0 2 0”
“1 c #FFFFFF
“2 c #000000
[end]

You can define background color for object 0x4B, which is a real background present in all non-transparent img.

There are some peculiarities with that kind of definition. If you define bitmap and add 0x4B to draw order in TYP file, then you can observe DEM shadings coming from other maps of the same area. But then nuvi 7xx can crash with the map, so I define bitmap with color but don’t include 0x4B to draw order.

Okay, thanks.

I see the 0x10101 polygon definition for “land” in the TYP file (Garmin code for Land_Not_Urban). As expected, it is white/black (day/night).

How do I define it in my polygon style sheet?

There is no 0x4b in either the TYP file or the style sheet currently, which I’m sure you knew already.

However IMG2TYP shows that the IMG file for one of the Lambertus maps I’ve inspected includes a 0x4b00 polygon as “background container (d1)”. Ultimately, I want to add contours to my maps so it would seem I need to know how to add this semi-transparent polygon to my scenario. For now, I won’t concern myself with the Nuvi crashes. And, needless to say, I have not yet broached the topic of draw order.

Can you continue with the step-by-step?

Many thanks,

Dave

I just checked the polygon style of generic new, the background is 0x27 instead of 0x10101 but I think it doesnt really matter which one you use:

natural=background [0x27 resolution 14]

To make it work, put in your mkgmap options –generate-sea=land-tag=natural=background

You can use another tag instead of natural=background (of course use a non existing OSM tag)

Contours as an overlay don’t need background object and won’t change background color, which is set by non-transparent map.
If you include contours directly into your map, then rules are like for any other map.

You have to define draw order for polygons in TYP file. If you use TYP file, then only polygons which have defined draw order are actually drawn in device. Polygons with lower draw order are drawn first. That way you can define for example if you’d like to draw a lake over a forest or just the opposite.

That worked. That is quite a parameter. –generate-sea=land-tag=natural=background (!!!) I reckon by the time I’m though with all this I’ll be able to write a very humorous book about my experiences LOL.

I will save the question of why there are so many “land” polygons in that TYP file for anoher day. Time to clear my brain with some sleep.