November 2018 - mkgmap-dev - The mkgmap lists

supershort ways - creating routing problems on some devices
by Felix Hartmann 12 Nov '18

12 Nov '18

Hi Everyone, with my style https://www.openstreetmap.org/way/111528845 this micromapping of steps is creating problems for autorouting. It would be great if there would be a way to force join ways below XX meters to the next longer way (or other way around). Basically here someone mapped ways 1-2m long - so it's a 2m piece of highway=footway, then 2m highway=step step_count=1, then again 2m of highway=footway, then 2m of highway=steps, step_count=4, then 1m long highway=footway - and then finally a little longer highway=steps with 11 steps. Now there is no way right now to simply drop the highway=steps and join it to another way - as in style we do not know what the other way actually is. Optimally here either highway=steps is removed and all made highway=footway (footways often have steps) or the other way round - the short footways become highway=steps and the footway pieces thereby removed. It would be good to have a filter remove ways shorter than XMeters - and do the joining (maybe needs a separate file for rules? I guess mostly such ways are highway=steps anyhow however). With my map this causes garmin devices to freeze. With others it's fine - but this micromapping really serves not much. On the other hand of course we cannot remove the detail from OSM in the database. The remove-short-arcs options once did something similar - but it's ben deprecated. Felix -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

2 1

Commit r4249: correct address search index
by svn commit 12 Nov '18

12 Nov '18

Version mkgmap-r4249 was committed by gerd on Mon, 12 Nov 2018 correct address search index Roads with an empty first label where not added to the global index. The --housenumber option may add roads where first label is empty (so that the map doesn't display it) but further labels have names needed for the address search. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4249

1 0

TYP compiler problems
by Ticker Berkin 09 Nov '18

09 Nov '18

Hi I'm having problems with the TYP file appearing corrupt. A simple file was working as expected, but adding a bit more caused very strange display properties in unrelated items on the Garmin device - eg, an area showed as a pattern never seen before, and, when selected, claimed to be waypoint. Running test.display on the file, sometimes I get: Exception in thread "main" java.lang.AssertionError at test.display.TypSectionDisplayer.printLabels(TypSectionDisplayer.java:1 19) at test.display.PolygonDisplayer.printStyles(PolygonDisplayer.java:83) at test.display.PolygonDisplayer.printPolygonDefs(PolygonDisplayer.java:60 ) at test.display.PolygonDisplayer.print(PolygonDisplayer.java:42) at test.display.TypDisplay.print(TypDisplay.java:56) at test.display.CommonDisplay.display(CommonDisplay.java:171) at test.display.CommonDisplay.display(CommonDisplay.java:196) at test.display.TypDisplay.main(TypDisplay.java:302) and, making slight adjustments to the length of some strings, it doesn't crash but the test output has lots of non-printing characters in the label display and sometimes messages about overshoot {-ve val} Gradually deleting almost all the contents of the typ file, it now always crashes display. Changing the xpm from a bit-map to a block colour makes it OK. This is file badTypMin.txt Going back to a version with more contents, changing the string in polygon type 0x58 changes the crash/corruption behaviour as per the comment. This is file badTypMore.txt Also attached is tst.sh that I've been using to compile and display the badTyp.txt file Ticker

4 4

Style for pipeline routes
by Dave Swarthout 08 Nov '18

08 Nov '18

Gerd, Thanks for the help on the pipeline rendering. Your rule had one error in it, the word "way" but mkgmap complained and provided the line number of the error so it was easy to fix. I checked to see if the sections of the TAP pipeline where I removed the tags were rendered properly, and they were, even the sections that are underground or overground show up fine. Of course, those ways already carry the location tag. My line styles have provisions for both. type=route & route=pipeline { apply { set man_made=pipeline; } } During the long conversation about tagging relation members that began by trying to come up with a method of tagging groups of lakes. Someone suggested creating a new relation type of "group" to handle such things. I didn't want to do that so stuck with using a multipolygon to group a set of lakes that have a single name. Then I encountered a situation that was ideal for an experiment, three rocks near Kodiak Island that have the name "Three Sisters Rocks". These are nodes, not ways, so the multipolygon approach really doesn't suit them well. I create a new relation, tagged it as type=group and added the nodes to it. Of course, the rocks do not render on the OSM slippy map but they did on mymkgmap file because I added the following rule to the relations style sheet: type=group & name=* { apply { set name='${name}'; } } -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

2 2

Pipeline route style
by Dave Swarthout 08 Nov '18

08 Nov '18

Hi again, Gerd, Thanks for the help on the pipeline rendering rule. I checked to see if the style renders the pipeline in the area where I removed the tags from the way and it rendered there perfectly. There was one error in the rule you provided, the word "way". When I tried to compile my map, mkgmap complained and provided the line number of the error so it was easy to fix. Here's the corrected rule: type=route & route=pipeline { apply { set man_made=pipeline; } } During that long thread about tagging groups of lakes, someone suggested creating a new relation type of "group". I wasn't ready to try creating something new so I grouped my lakes into a standard multipolygon as I've always done. Then a few days ago I came across a situation that was perfect to experiment with the idea of a type=group. There are three large rocks near Kodiak Island (Alaska) that together have the name "Three Sisters Rocks". (See http://www.geonames.org/5876155/three-sisters-rocks.html) The rocks are nodes, not ways, so the multipolygon approach wouldn't work. I created a new relation, tagged it as type=group and added the three nodes to it, added a name tag and saved it. Of course, OSM doesn't know anything about it, not even the name, because it has no idea what to do with a multipolygon of type=group. Then, because of your hint I was able to construct this rule which made them visible in my mkgmap images! type=group & name=* { apply {set name='${name}'; } } I can't decide whether to leave them as a "group" or try to invent a new scheme to tag them. I certainly will not be pushing for the creation of a new relation type anytime soon. Life is too short LOL Best, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

1 0

Re: [mkgmap-dev] Address Searches on new GPSmap66S
by manfred.haiduk 07 Nov '18

07 Nov '18

Just some thoughts from my side about adress search on garmin device. Since more than a year i owned the new GPSMAP276CX. Comparing to the former GPSMAP276 the adress search is extremly slow, even when i first do it with GARMIN CITY NAVIGATOR MAP. The old one (276) show up search results after each letter which was typed in, nearly the same time, as i typed them. The new 276Cx seems to be blocked during input, you have to wait some seconds between each letter. But in the end, the search has success. This behaviour can be seen also on self made maps compiled with mkgmap. I myself have the feeling, that GARMIN uses a slow search routine compared to former devices. Another hint, i think they have merged their software to have only one branch for all street navigation devices, i.e Nuvi, GPSMAP etcVon meinem Samsung Gerät gesendet. -------- Ursprüngliche Nachricht -------- Von: "osm@pinns" <osm(a)pinns.co.uk> Datum: 07.11.2018 17:00 (GMT+01:00) An: mkgmap-dev(a)lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Address Searches on new GPSmap66S Hi TickerThanks for that info.Have reported the bug to Garmin .Your info will be very useful when / if they reply.rNickOn 07/11/2018 15:57, Ticker Berkin wrote:> I've just got a new Etrex 30x, updated with the latest firmware, and> most of the searching is very slow compared with my almost 10 year old> Etrex Legend.>> Using mkgmap generated map of the British Isles:>> On the Legend, earching for city gives a narrowed list as fast as I can> type in each character of the name. The 30x takes 5 seconds after> Search is selected before displaying nearby cities, then takes about 8> seconds per letter entered before showing the narrowed list. Typing> ahead can reduce the total time taken.>> Address searches do work, with the City selection being much faster> than the City search, but I have lots of City points that are not part> of an address.>> Ticker> >> On Wed, 2018-11-07 at 11:25 +0000, osm@pinns wrote:>> Hi Gerd>>>> I have been in contact with someone at Garmin about another bug and>> will>> ask him about it.>>>> I can see where they are coming from , ie city navigator maps don't>> seem>> to 'popular'>>>> Interestingly , have tested this bug on a Topo France with the same>> result so it might be a bug.>>>> With this gps not problems with searching for restaurants>>>> Nick>>>> On 07/11/2018 11:10, Gerd Petermann wrote:>>> Hi Nick,>>>>>> well, my Oregon 600 no longer uses the index when I search for>>> restaurants. No idea if that started after an update of the>>> firmware>>> or a change in mkgmap. Search takes very long, even if map contains>>> only one tile.>>> It might not be intended by Garmin, maybe they just change the>>> firmware without testing it with our maps?>>>>>> Gerd>>>>>> ________________________________________>>> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag>>> von nwillink <osm(a)pinns.co.uk>>>> Gesendet: Mittwoch, 7. November 2018 11:53>>> An: mkgmap-dev(a)lists.mkgmap.org.uk>>> Betreff: [mkgmap-dev] Address Searches on new GPSmap66S>>>>>> Hi All>>>>>> Just say that the latest GPSmap66S gives a 'Cannot find address'>>> when>>> searching for an address!>>>>>> Oddly, it lists any address you have entered, ie it finds the names>>> of>>> streets and towns/cities even the numbers of an address but>>> annoyingly>>> refuses to locate them on the map.>>>>>> Checking the manual it says:>>>>>> 'You can use optional City Navigator maps to search for addresses.'>>>>>> mmm....>>>>>> So it only works with City Navigator maps ,.... a sign of things to>>> come?>>>>>> Apart from that , mkgmap's custom maps work !>>>>>> r>>>>>> Nick>>>>>>>>>>>> -->>> Sent from:>>> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html>>> _______________________________________________>>> mkgmap-dev mailing list>>> mkgmap-dev(a)lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>>> _______________________________________________>>> mkgmap-dev mailing list>>> mkgmap-dev(a)lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>> _______________________________________________>> mkgmap-dev mailing list>> mkgmap-dev(a)lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> _______________________________________________> mkgmap-dev mailing list> mkgmap-dev(a)lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev_______________________… mailing listmkgmap-dev@lists.mkgmap.org.ukhttp://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 1

Address Searches on new GPSmap66S
by nwillink 07 Nov '18

07 Nov '18

Hi All Just say that the latest GPSmap66S gives a 'Cannot find address' when searching for an address! Oddly, it lists any address you have entered, ie it finds the names of streets and towns/cities even the numbers of an address but annoyingly refuses to locate them on the map. Checking the manual it says: 'You can use optional City Navigator maps to search for addresses.' mmm.... So it only works with City Navigator maps ,.... a sign of things to come? Apart from that , mkgmap's custom maps work ! r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

4 4

splitter: option for maximum tile area?
by Bernhard Hiller 07 Nov '18

07 Nov '18

Hi all, currently a Java OutOfMemory exception prevents me from creating a map. I already use option --max-jobs=3 (the machine has 4 physical cores) and -Xmx5G (of 8 GB installed). Beyond OSM data, the map contains DEM and elevation contour lines. From the tiles finished and those with a new timestamp but about 0 bytes length, I can see that mkgmap was rendering tiles 47120005, 47120006, 47120007 at the time of crash. Tile 47120005 is extremely large by physical area - some 6° x 5.5° (see attached file), covering a lot of the south chinese sea, i.e. there are not many actual data in that area. I guess that the problem arises with that tile. I remember some case in the past where a single tile covering such a large area of mainly sea caused mkgmap to take an enormous amount of time for rendering - also here, mkgmap already spent about 1 hour before crashing. So I'd like to ask: is there some possibility for limiting the area of a tile among the splitter options? Kind regards, Bernhard

4 20

Commit r4248: backgroundArea.patch by Ticker Berkin (modified)
by svn commit 07 Nov '18

07 Nov '18

Version mkgmap-r4248 was committed by gerd on Wed, 07 Nov 2018 backgroundArea.patch by Ticker Berkin (modified) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4248

1 0

DEM and SRTM hgt files: size too small
by Thorsten Kukuk 01 Nov '18

01 Nov '18

Hi, I started to play with maps with DEM, but run into a problem: viewfinderpanoramas.org provides hgt files, but only for some areas. The SRTM1v3.0 data is using geotiff. No problem, you can convert them with gdal_translate and fill the missing areas. Works fine for below N50, but starting with N50, the data is much smaller and this leads to the following error: SEVERE (HGTReader): 71200154.osm.pbf: file /data/OSM/data/hgt/N50E012.hgt has unexpected size 12970802 and is ignored SEVERE (HGTReader): 71200154.osm.pbf: file /data/OSM/data/hgt/N50E013.hgt has unexpected size 12970802 and is ignored SEVERE (HGTReader): 71200159.osm.pbf: file /data/OSM/data/hgt/N50E014.hgt has unexpected size 12970802 and is ignored Any ideas how to solve the problem? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

3 3