January 2019 - mkgmap-dev - The mkgmap lists

Street names abreviated on screen but complete in speech?
by muralito＠montevideo.com.uy 14 Jan '19

14 Jan '19

Hello. It's possible to have mkgmap compile the street name abreviated for text labels and address of POI (and other on-screen uses), and keeps the name as it is in OSM so the garmin device speechs the complete sound? It could help a lot with long names in spanish language, eg "Av."->"Avenida", and several other words. Regards, M.

2 1

Commit r4262: improve default style (defaultStyleTidy3e.patch by Ticker Berkin with small modifications)
by svn commit 11 Jan '19

11 Jan '19

Version mkgmap-r4262 was committed by gerd on Fri, 11 Jan 2019 improve default style (defaultStyleTidy3e.patch by Ticker Berkin with small modifications) A few minor layout tidy-ups Add GBR section to inc/access_country Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway Ignore more highways when abandoned/disused/demolished Ignore more highway tags that are not suitable for routing Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway with bicycle=no and remove later test for steps Convert highway=crossing/virtual to path Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway Add footway around man_made=pier even if area=yes Fix common bad tagging for highway= by converting to the presumed values Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing Handle some rarer highway types by converting to more generic type Show any other water lines Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits from place=city/town... Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search and add some more cuisines. One effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. The other effect is that an element that is both a Restaurant and a Lodging now shows as Lodging rather than Restaurant For leisure=* where sport might be involved, show the sport if no name available Show canal/lock as 0x6505 (Water Features>Canal) Show aeroway=runway/taxiway/taxilane as polygon only if marked as area=yes Increase resolution that amenity=cafe/fast_food/restaurant polygons show at Show place=suburb Alternative rule to show highway=pedestrian as square/plaza unless explicit area=no. highway=footway show as square/plaza if explicit area=yes Don't assume any other closed highway is parking area, just services/rest_area Show more historic=* Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes Show any other water area Show all man_made=* unless explicit area=no http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4262

1 0

Commit r4261: don't treat amenity=shelter + shelter_type=public_transport like other shelters
by svn commit 07 Jan '19

07 Jan '19

Version mkgmap-r4261 was committed by gerd on Mon, 07 Jan 2019 don't treat amenity=shelter + shelter_type=public_transport like other shelters http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4261

1 0

Not-equal compare bug?
by Harri Suomalainen 05 Jan '19

05 Jan '19

Using mkgmap-r4260 I tried several variations to make a rule match when some tag does not exist: Line: ( highway!=* | oneway!=*) { deletealltags } Error in style: Error: (lines:12): Invalid rule expression: $highway!=*| $oneway!=* Similar error is given when comparing expression with this line: oneway!=* { deletealltags } Tt seems != works fine but only if there is an equal comparision first like in this line that gives no error: highway=* & oneway !=* { deletealltags } Do I missunderstand something or is this a bug? I think I tried some other use case while back and I got similar errors when it started with != comparision first. This may not be a very new issue. Chears, Harri

5 8

splitter, mapid
by brad 03 Jan '19

03 Jan '19

One thing I think I missed, is that each tile on a garmin device needs a unique mapid. A different family-id and mapname for each gmap is not sufficient. Does this sound correct? I'd been downloading US states from Geofabrik, creating maps with unique family-id, mapname, every name & id that seemed important, (with mkgmap) but when I put them on the Garmin they all wouldn't show up. Only when I went back to the splitter step & used a different mapid did they all show up. Sometimes I'm not too good at reading directions, did I overlook this someplace? Brad

5 13