January 2021 - mkgmap-dev - The mkgmap lists

split multipolygon not shown in both img tiles
by Ranko Jaksic 23 Jan '21

23 Jan '21

Hi Gerd, I found another case where a split mp is not properly handled in mkgmap. When following relation (park with inner lake) is split verticaly (so that the lake is intersected) then the park is shown in only one of the generated img tiles. https://www.openstreetmap.org/relation/3351946 I have uploaded my test data to http://files.mkgmap.org.uk/ rj-mp-split.zip relation-3351946.osm.pbf (OSM data for this relation) areas-test.list (areas.list for splitter) Test code: java -d64 -Xmx8G -jar splitter.jar --split-file=areas-test.list relation-3351946.osm.pbf java -d64 -Xmx8G -jar mkgmap.jar -c template.args --gmapi --remove-ovm-work-files I am using mkgmap-r4574, but also tested with latest mkgmap-r4596 and the results are the same... regards, Ranko

2 3

Commit r4597: Use high-precision coordinates when looking for self-intersecting multipolygon ways.
by svn commit 23 Jan '21

23 Jan '21

Version mkgmap-r4597 was committed by gerd on Sat, 23 Jan 2021 Use high-precision coordinates when looking for self-intersecting multipolygon ways. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4597

1 0

Commit r4596: remove wrong javadoc statements, no functional changes
by svn commit 21 Jan '21

21 Jan '21

Version mkgmap-r4596 was committed by gerd on Thu, 21 Jan 2021 remove wrong javadoc statements, no functional changes http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4596

1 0

Commit r4595: unit test: Code reformatting and some minor changes reg. naming conventions
by svn commit 21 Jan '21

21 Jan '21

Version mkgmap-r4595 was committed by gerd on Thu, 21 Jan 2021 unit test: Code reformatting and some minor changes reg. naming conventions http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4595

1 0

improved diagnostics patch v2
by Mike Baggaley 16 Jan '21

16 Jan '21

Hi Gerd, My previous diagnostic improvements patch seems to have got lost, but since then I have noticed another couple of items to include, so attached is an updated version. Cheers, Mike

2 14

Commit r4594: improve diagnostic messages (diagnostics8.patch by Mike Baggaley)
by svn commit 16 Jan '21

16 Jan '21

Version mkgmap-r4594 was committed by gerd on Sat, 16 Jan 2021 improve diagnostic messages (diagnostics8.patch by Mike Baggaley) Those who parse the logging results with scripts may have to adapt those scripts http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4594

1 0

Re: [mkgmap-dev] Garmin Topo Europe map
by 7770 11 Jan '21

11 Jan '21

Hi. I made a few tests to lower the size of the maps. Comparison is made to my standard map which is based on the styles example in mkgmap but extended a bit for my purposes. This has 100 % size. There are 4 levels, 24 is the most detailed resolution. Setting the resolution to 23 and changing relevant polygons, lines, points to show at 23 instead of 24. 4 levels (option file). Size 78 %. Setting the resolution to 23 and changing relevant polygons, lines, points to show at 23 instead of 24. 3 levels (option file). levels = 0:23, 1:20, 2:18 Size 64 %. Using my minimal style (discussed earlier in this thread). Compared to normal map, it is about 75 % in size. Using minimal style and Setting the resolution to 23 and changing relevant polygons, lines, points to show at 23 instead of 24. 4 levels (option file). Size 63 %. Using minimal style and Setting the resolution to 23 and changing relevant polygons, lines, points to show at 23 instead of 24. 3 levels (option file). levels = 0:23, 1:20, 2:18 Size 51 %. I noted that when resolution is set to 23 polygons smaller than the mentioned raster at ~4.8 m disappear. They also do get distorted. Buildings are such polygons that are effected a lot, and it is (in my opinion) a good idea to disable buildings and similar polygons entirely when lowering the resolution. Coast lines and alike become less detailed of course. Some line segments have become a bit misaligned (i noted bus stop platforms and similar short lines can have this issue). I yet have to check how well these maps work on a unit but it seems possible to lower the size quite a lot if it is desired. Regards Karl On onsdag 30 december 2020 kl. 13:27:06 CET Vuki wrote: > Hi, > > am also working on a "lite" style and there may be some nice idea in yours > to use :) will check that out, thanks! > > > Köszi: > Vuki > On 2020.12.30. 12:08, 7770 wrote: > > Hi. > I am ok with sharing the style, but i was not able to do it until today > (planned today or tomorrow). > 5 files attached, 4 related to style, 1 to TYP (foskan.txt). > Only those 4 style files have changes, compared to the standard. > > The complete set of files is ./mkgmap-rNNNN/examples/styles/default/ > > > There is nothing fancy nor complex, nor have i played around with the levels > yet. > > For reference i also added my TYP-file, which may help in case you find some > type codes which are non standard (there might be a few). The type file is > shared and does contain a few things that are not used by the minimal style > (don't get confused). > > > Summery of the style, which is based on the default mkgmap example. > All changes comments are marked with ## to be able to tell them apart from > regular comments given after #. > > polygons and points do have a lot of disabled information. > Buildings, shops, and most of the parking types are disables. > > lines doesn't have as many changes and probably a few more small waterways > (streams, rapids, waterfalls) can be disabled to remove yet a bit of data. > > note for polygons. > Waters and forests are still visible, since it adds information to the map, > but if natural objects are not important for you, there is more space to > save. > > i have made one change in lines file to display the road name on tertiary > roads instead of the reference. this does make sense in nordic countries, > where tertiary roads are usually only referred to with the name. > > Ski lifts (arealways in general) are set in similar way as railroads. > > One last thing to mention is that i have updated the inc/address file. > Close to the end there is a section in which the mkgmap:phone is updated to > show information about which fuels are sold at fuel stations. This is not > fully complete for all fuel types but the ones i somehow considered > important. Depending on where one is, a few more fuel types can easily be > added. > > A note. > The mkgmap:phone seems to be 50 characters maximum, longer data will be > truncated and not shown on the device it seems. > > > Regards and happy new year! > Karl > > On onsdag 30 december 2020 kl. 10:16:51 CET Vuki wrote: > > Hi Karl, > > don't you want to share your minimal style? :) > > > Köszi: > Vuki > On 2020.12.27. 20:59, 7770 wrote: > > Hi. > A few observations about the TopoActive europe map. (i have it on a GPSMAP > 66st). > > The map is rendered slower than most custom made maps. > Updates occur 2 times per year, but even at those times many changes to OSM > are not present. Perhaps they only update some parts yearly. > Points lack all kind of additional information which other mappers add > (opening hours, region, phone numbers, etc.). > One nice thing is colour marked national parks and reserves. > Being an outdoor map, it lacks some information about shelters in the > wilderness. > Routing is possible only for outdoor activities (cycle, walk, hike, direct), > automotive routing (car, motorcycle) is disabled. > > I have tried creating a minimal style. This lowers the data to about 75 % or > my normal set up. But i did not change the level, which i will try :-) > Currently I am no way near the compression which TopoActive achieves. Using > input data which is about 6,7 GB in pbf format, creates a gmapsupp just > below 4 GB for normal and around 3 GB for minimal style. These numbers > feels similar to getting France into 1.9 GB from 3.7 GB pbf (geofabrik). > > > The minimal set up is not very fancy at all, it disables things not wanted. > Buildings, shops, most of parkings, and a bit more. > > Today i cannot send off any style, but in case that would be of interest let > me know and i can share it in a few days (guessing Wednesday or Thursday). > > > Regards > Karl > > On söndag 27 december 2020 kl. 20:08:10 CET Gerd Petermann wrote: > > Hi Pierre, > > my first guess would be that the level 0 is at resolution 23 instead of 24. > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von > Pierre Brico <pierre.brico(a)gmail.com> Gesendet: Sonntag, 27. Dezember 2020 > 19:37 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Garmin Topo Europe map > > > Hello guys, > > I've just discovered the Garmin TopoActive Europe map based on OpenStreetMap > data. This map is sold at a price of 50€ or is pre-installed on some new > devices. I've just seen it on the device of one of my friends and it looks > very good. I'm surprised to see that for West Europe, it takes only 2.8GB > and is quite complete (index for search, routable, ...). > > For now, I generate my own maps based on your excellent tool but the result > is much bigger (1.9GB only for France with probably more details). So, my > question is: does anybody have a similar configuration (style files and > command line) to obtain a result like the Garmin TopoActive Europe ? > > Thanks, > Pierre > _______________________________________________ > 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

4 5

Commit r4593: Fix problem in destclass calculation when --x-no-force-end-nodes-routing-nodes is used.
by svn commit 07 Jan '21

07 Jan '21

Version mkgmap-r4593 was committed by gerd on Thu, 07 Jan 2021 Fix problem in destclass calculation when --x-no-force-end-nodes-routing-nodes is used. - if node has no arcs: use road class of highest road for which the node is the first node Fixes NodCheck complains about high class boundary node not included in NOD 4 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4593

1 0

Embedding raster maps
by Oliver Eichler 05 Jan '21

05 Jan '21

Dear mailing list, let me introduce myself. Some might recognize my name. I am the main author of QLandkarte/QMapShack. I have quite some experience in decoding the Garmin formats. But little knowledge in encoding the format. My main focus is on raster maps rather than vector maps as they provide more details in alpine areas. Years ago I was in contact with Alex Whiter to decode and encode the Garmin Bird's Eye format that uses some kind of DRM. To make it work the DRM check on the devices had to be disabled. Alex provided a firmware patcher. That solution worked pretty well over the years. A couple of years ago we had another contact. This time it was decoding the raster maps embedded into the IMG format. At that time decoding was the goal. We never considered encoding the stuff as there is the JNX format as a much simpler solution. However life is not a constant and Alex died a couple of moons ago. See for details: https://www.gpspower.net/forum-announcements/359499-vale-alexwhiter.html And with him the knowledge about the firmware patcher. Right now it still works. But it's just a question of time that this will fail. Therefore I invested quite some days of spare time to consolidate my old decode code and to start encoding. Alex wrote some documentation in Russian and Wolfgang taking care of the QMapShack Wiki translated it into English: https://github.com/Maproom/qmapshack/wiki/RasterImg_AWhiter My current progress can be found here: https://github.com/kiozen/GarminImg Let me explain why I started to write my own encoder rather than diving into the code of mkgmap * I never wrote Java. And starting to learn Java with mkgmap is a bit frightening ;) Sorry :D * My target users are everyday Garmin users that do have raster maps but very little experience with map creation. Therefore I need a simple solution that can be shipped with QMapShack/QMapTools * All IMG files embedding raster maps that are available to me make use of the newer encoding via GMP part rather than the older format. I do not know if the last point is necessary. From my understanding it shouldn't matter. But as I am not sure I started with new newer format. The complete project reached the point, where I can create IMG files with a raster map embedded. And I can decode that map again. However - you surely guessed it - the device refuses to list the map. This is kind of expected. There are many details to get right and a single one can make it fail. Therefore I decided to reach out for help and inspiration contacting this list. My first question would be: What is the minimum data an IMG file has to contain to be listed on the device? Right now I try to create a file with more or less empty GMP section. From the comments in mkgmap I already learned that it needs at least two copyright strings. But does a map require to have points/lines and areas to be listed on the device? In other words: How can I make sure my header, FAT table and MPS section is ok? To have a map with no data listed on the device would be a huge step forward. Cheers Oliver

3 6

Commit r4592: improve documentation - minordoc.patch by Mike Baggaley
by svn commit 05 Jan '21

05 Jan '21

Version mkgmap-r4592 was committed by gerd on Tue, 05 Jan 2021 improve documentation - minordoc.patch by Mike Baggaley http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4592

1 0