August 2017 - mkgmap-dev - The mkgmap lists

Commit r3842: Improve ResidentialHook / BoundaryQuadTree: suppress misleading warnings about overlapping admin_level=11 boundaries
by svn commit 09 Apr '18

09 Apr '18

Version mkgmap-r3842 was committed by gerd on Sat, 11 Mar 2017 Improve ResidentialHook / BoundaryQuadTree: suppress misleading warnings about overlapping admin_level=11 boundaries http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3842

8 15

Recent Garmin Firmware "cannot authenticate maps" when they are unicode
by franco_bez 17 Sep '17

17 Sep '17

Hi all, maybe it's already a know bug. I just stumbled over this one: On a new Oregon750 I got the Error "cannot authenticate maps", while on the old Oregon550 the maps worked like always. I found out that changing the option "unicode" to "latin1" in my style did the trick, the resulting maps work on both devices. Over here in Germany I have no problem with latin1, but I suspect that in Russia or in the middle east or far east countries this will be a real problem. I attached the Error Screenshots. Ciao, Franco <http://gis.19327.n8.nabble.com/file/n5901399/IMG_20170818_063414%7E01.jpg> <http://gis.19327.n8.nabble.com/file/n5901399/IMG_20170818_063911%7E01.jpg> -- View this message in context: http://gis.19327.n8.nabble.com/Recent-Garmin-Firmware-cannot-authenticate-m… Sent from the Mkgmap Development mailing list archive at Nabble.com.

6 13

License issue in mkgmap & splitter source: GPL-2 (v2 only) incompatible with GPL-3 (v3 only)
by Sebastiaan Couwenberg 02 Sep '17

02 Sep '17

Several source files are licensed under the GPL-2 which is incompatible with GPL-3 source in splitter. To combine GPL-2 code with GPL-3 code, the GPL-2 code needs to be license under the GPL-2+ (v2 or later), or dual-licensed under the GPL-2 (v2 only) or GPL-3 (v3 only).[0] The mkgmap source files in question: src/uk/me/parabola/mkgmap/filters/MustSplitException.java src/uk/me/parabola/mkgmap/reader/MapReader.java The splitter source files in question: src/uk/me/parabola/splitter/tools/BitReader.java src/uk/me/parabola/splitter/tools/BitWriter.java test/func/ArgsTest.java test/func/Base.java test/func/SolverAndProblemGeneratorTest.java test/func/lib/Args.java test/func/lib/Outputs.java test/func/lib/TestUtils.java test/uk/me/parabola/splitter/tools/TestBitReader.java Steve & Gerd, can you relicense the code to GPL-2+ (v2 or later) or dual license those files as GPL-2 (v2 only) or GPL-3 (v3 only)? This issue prevents the update of the mkgmap packages in Debian. Kind Regards, Bas [0] https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

3 8

splitter crash
by Mike Baggaley 25 Aug '17

25 Aug '17

I had an osm file that had an empty value for lat and long at one node and it crashed splitter as below: Exception in thread "producer for DensityMapCollector" java.lang.AssertionError at uk.me.parabola.splitter.parser.O5mMapParser.readNode(O5mMapParser.java:248) at uk.me.parabola.splitter.parser.O5mMapParser.readFile(O5mMapParser.java:183) at uk.me.parabola.splitter.parser.O5mMapParser.parse(O5mMapParser.java:141) at uk.me.parabola.splitter.OSMFileHandler.process(OSMFileHandler.java:85) at uk.me.parabola.splitter.OSMFileHandler$1.run(OSMFileHandler.java:148) I think the attached patch should fix the problem (I can't test it because I haven't got a full development environment of splitter, but it just replaces the asserts with throws). Can you please test and commit if you are happy with it? Thanks, Mike

2 1

Re: [mkgmap-dev] Buildings with wrong corners.
by d.kwapisz 24 Aug '17

24 Aug '17

Thank You Gerd Darek W dniu 2017-08-24 19:46:39 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > Hi Dariusz, > > this is caused by the rather low resolution used in the img format (~ 2.3m) while OSM is somewhere near 1 cm. > You did nothing wong and mkgmap already contains code to reduce the errors. > Imagine you have to draw a picture using lines on a bed of nails. Each real OSM node is rounded so that it > falls exactly on a nail. > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > Gesendet: Mittwoch, 23. August 2017 16:11:15 > An: mkgmap-dev(a)lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Buildings with wrong corners. > > Hi, > The buildings which are correct in OSM, after using 'mkgmap', they haven't right angles (the edges are not perpendicular). > > There are any 'mkgmap' options responsible for this? Or maybe I'm doing something wrong? > > I attached file with two screens (from OSM and BaseCamp). > > Best regards > Dariusz Kwapisz > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0

Routing jumps
by Ervin Malicdem 24 Aug '17

24 Aug '17

Anybody have the same issue? About 3 users have already reported routing jumps to a straight line on most of the newer Garmin models. They have reported that the issue happens with Nuvi 66 BMW Navigator V, Nuvi 35; but does not happen in older Montana, Nuvi 1360, Zumo 350. Thanks in advance. Ervin -- Ervin Malicdem for Schadow1 Expeditions A Filipino must not be a stranger to his own motherland. http://www.s1expeditions.com

2 1

Buildings with wrong corners.
by d.kwapisz 24 Aug '17

24 Aug '17

Hi, The buildings which are correct in OSM, after using 'mkgmap', they haven't right angles (the edges are not perpendicular). There are any 'mkgmap' options responsible for this? Or maybe I'm doing something wrong? I attached file with two screens (from OSM and BaseCamp). Best regards Dariusz Kwapisz

2 1

Commit r3995: default style: ignore highway=stopline
by svn commit 24 Aug '17

24 Aug '17

Version mkgmap-r3995 was committed by gerd on Thu, 24 Aug 2017 default style: ignore highway=stopline Was treated by the mop up rule, exists 17677 times according to taginfo http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3995

1 0

TYP files and oruxmaps
by Pedro Torres 22 Aug '17

22 Aug '17

Hello, I am trying to open a map that I created with mkgmap with a TYP file in oruxmaps (Android app). I can load the map with success in my Garmin device or Basecamp but can't open it in oruxmaps. The maps is not rendered correctly. If a create a IMG file without the TYP file, I can open it in oruxmaps (but its too much ugly). What's is the best way to fix it? Thanks, Pedro

3 2

Data / routing issue - Vancouver, BC ferries
by Samuel Longiaru 21 Aug '17

21 Aug '17

Greetings all, I have been lurking on this list for several years now and first want to congratulate all for such a fantastic project. Very, very nicely done! But I have run into an issue with the maps I create of British Columbia and am unable to determine whether it is a data or mkgmap issue. The problem is that ferries coming out of the Tsawwassen ferry terminal to/from Vancouver island do not get routed. For example finding a route from Kamloops (BC interior) to Victoria, the route on my Nuvi 255 shows a 1400 km diversion north to the coastal town of Bella Coola, then a ferry to Port Hardy on the north end of the island, then south to Victoria. This routing is suggested whether I use maps I've generated myself or ones downloaded from garmin.openstreetmap.nl. It is interesting, however, that other routing engines (GraphHopper, OSRM and Mapzen) route over the ferries as expected... Kamloops direct to the Tsawwassen terminal, then ferry to the island. I question, however, whether the ferry routes are mapped properly as just west of the Tsawwassen terminal is a node where all routes join and branch http://openstreetmap.org/node/660826272 . A similar node exists east of the Swartz Bay terminal on Vancouver Island - 323308217. The wiki documentation for tag route=ferry states in part "The ferry route must not branch in the water, so it must always be drawn to the ferry dock. This is important for routing to work correctly." So when the wiki says that it is important for routing... whose routing? Clearly this is not a requirement for these other engines, but is it the case for us? If we need data in the form as that described in the wiki, then I will contact the Talk-CA list and see if there is someone local who can fix it... i.e., recreate it as per the wiki standard. Otherwise, if the wiki is outdated and the data are acceptable, then could there be a problem here, or could I just need an adjustment to something in my args list? Thanks in advance, Samuel Longiaru Kamloops, BC Canada

5 16