Can you give an example of OSM ways that (a) don’t and (b) do appear as an airport runway? I’m presuming that the points, lines and polygons of the style that you’re using are in “osm/tstan” here? Do the highways appear as airport runways on the Garmin device or only in BaseCamp?
Here are some screenshots of BaseCamp labeling streets in Moscow as airport runways (the tags in OSM don’t indicate that they are runways at all):
This screenshot of Bolshaya Ordynka Street (on which I lived 1986-1988) seems to label it as a normal street:
And here the grounds of the U.S. Embassy in Moscow are labeled as an “industrial complex” although the tags in OSM show no such thing.
I started out with those style sheets but amended the “name” sheet to reflect name:ru rather than the local languages in Central Asia. After a few tries, I then reverted the “name” style sheet to the default sample sheet, which is what is shown in the screenshots above. I also tried reverting the “lines” style sheet to the default sample sheet. The results are the same either way.
My Garmin nuvi 2598 indicates that these streets are “roads”. It seems willing to route on them in simulation mode.
My notes from when I last looked at BaseCamp are genuinely “That was 2 hours of my life that I won’t get back.”. I found it incredibly user-hostile to use, and so haven’t bothered since. I know that people do use it, so it can’t be that bad, but I’ll have to let one of them answer BaseCamp specifics.
The only thing mapped to 0x27 in your OSM-shell/OSM/tstan/lines file (for linear features) is “aeroway=runway” and “aeroway=taxiway”, so unless you’re manipulating OSM tags before running mkgmap I wouldn’t expect “linear runways” in the data there.
Your first road in the data is Оружейный переулок. It’s just a regular primary road - the tags don’t look very odd.
However, there is an “area:highway” mapped there. In OSM-shell/OSM/tstan/polygons (for area features), your map style has this
area:highway=* [0x0e resolution 24]
.which allegedly means:
0x0e Airport Runway
So I suspect if you just remove “area:highway” from polygons your “runways” should disappear.
Personally, I found a lot of benefit from removing unnecessary cruft from the mkgmap points, lines and polygons files and (if desired) doing tag transformations on OSM data first.
Bingo, that indeed worked. Curiously, the “polygons” style sheet is one I didn’t touch. It’s the default sample style sheet for polygons, so that line has been in there a while. Many thanks! I suspect some of the other anomalies in the rendering of Russian OSM data are to be found in the polygons style sheet as well (embassies as industrial parks?) Thank you again for taking a look!
Yes, with a standard Garmin .typ file (I haven’t experimented with different ones) the available polygon types are fairly limited. The good news is that you can map things to points easily and if you make sure that that points entry appears as something sensible to mkgmap, it’ll appear in a sensible search menu.
See for example here - in that code various “diplomatic” values are appended to the end of the name in brackets, so an embassy will appear as a government office (both on the display and in the search menus) with “(embassy)” and the country in brackets after the name.
If your “points” file doesn’t contain “diplomatic” and you don’t have some sort of preprocessing that changes “diplomatic” in OSM to something else, embassies won’t appear as points on your map and won’t be searchable,.
I do convert ways into points when invoking mkgmap, and have the following lines in the points style sheet, which seem to work ok.
(amenity=embassy | office=diplomatic) & country=* & embassy!=residence { set name=‘${country} ${name|def:}’ } [0x3003 resolution 24]
(amenity=embassy | office=diplomatic) & country!=* & embassy!=residence [0x3003 resolution 24 default_name ‘Embassy’]
(amenity=embassy | office=diplomatic) & country=* & embassy=residence { set name=‘${country} “Residence” ‘} [0x3003 resolution 24]
office=diplomatic & country!=* & diplomatic=consulate [0x3003 resolution 24 default_name ‘Consulate’]
office=diplomatic & country=* & diplomatic=consulate { set name=’${country} ${name|def:}’ } [0x3003 resolution 24]
Searching for “embassy” or “consulate” yields good results, although BaseCamp has an annoying tendency to crash when searching for embassies, for some reason. I share your view that it is an unfriendly piece of poorly engineered software.
Taginfo reveals occasional use of landuse=embassy_grounds and landuse=government, which would help with proper identification if used more widely. Not all government installations are military bases, police stations, public educational institutions, or post offices, and as a retired federal government employee, I’ve been bemused that there is no widely used landuse tag for strictly civilian government installations not specified elsewhere.
Many thanks, @SomeoneElse, for the hints and advice. I have produced usable IMG files of Russia and posted the style sheets and batch file here. The batch file produces 9 IMG files, one for each Russian federal district plus another for Kaliningrad, the exclave. The only hitch so far is that I tried to get mkgmap to assign name + name:en to streets and roads [highway=*] so they could be searched in either English or Russian, but for some reason it doesn’t work. It does work for names of municipalities [place=*].
The latest efforts are here: GitHub - allanmustard/mkgmap: personal mkgmap files
I’ve produced style sheets for Central Asia and for Russia, and in the latter case the style sheets label streets and roads with both the Russian and (if a name:en tag exists) English names. In addition, the index is searchable by individual words, so “Devyatinskiy” will yield any street containing that string, no need to memorize complete street names. The batch file generates nine IMG files corresponding to federal districts (it uses the Geofabrik PBF files, thank you Geofabrik!) That way users can select only the maps they want to enable in their Garmin GPS units, and not overload either memory or processor (total size of the combined 9 files is a bit over 4 Gb).
Comments or suggestions for improvement of the style sheets are welcome. Many thanks againt to @SomeoneElse for some very valuable pointers.