- mkgmap-dev - The mkgmap lists

Questions for a new front end GUI for MkgMap
by Frank Bijnen 21 Feb '25

21 Feb '25

Dear all, Sorry if this is the wrong place to ask. Background: I have developed a front end gui for mkgmap, written in Delphi (Rad 12 CE) that will run on Windows 64 bit. It allows to download the files needed and create maps from them using splitter/mkgmap. Typical files to download are the bounds-latest.zip, sea-latest.zip from www.thkukuk and pbf files from download.geofabrik.de. Initially this was meant only for private use, to update my own devices. But now I would like to share this program on a Github repository, including source code and an installer. Ideally the installer would also download and install the latest versions of mkgmap and splitter. I have no commercial interest, it will be free software. Externals used: - mkgmap/splitter - osmconvert/osmfilter (slightly modified versions to allow compiling with CBuilder) - java of course - style files (The standard style files, openfietsmap lite and hiking, modified version of abandoned project motoroute.de) - geonames cities500 - sea-latest.zip, bounds-latest.zip Questions: - Am I allowed to publish this kind of project? If yes: Are there any rules I should obey? - Are there any persons/organisations I should ask permission? @Thorsten Kukuk. What is your opinion? - The installer would need the latest version of mkgmap and splitter. Is there a way to find this info, or is there a link to the 'latest' version? Thanks in advance, Frank P.S. Happy to provide more info, source code, current installer etc.

2 3

Does mkgmap:unpaved work?
by Thorsten Kukuk 20 Feb '25

20 Feb '25

Hi, My Garmin Edge 1050 shows now for every tour in the statistic, how many percent of the roads are paved and how many unpaved. For my OSM maps, it shows always 100% paved. I even changed that value so that all ways should be unpaved. (I hope it doesn't matter that the doc says "mkgmap:unpaved=yes" while all examples and my style are using "mkgmap:unpaved=1". Does anybody knows if this flag is really working/set correct or has example maps where it is working? Except the original Garmin NT maps, that ones are correct. Thanks, Thorsten

2 1

Update on missing POI Labels on some devices and some questions...
by scott taggart 05 Feb '25

05 Feb '25

* As I posted here <https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2024q4/034350.html>on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): ** * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps. Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this? Any and all help is appreciated. *

6 17

Feature Request
by Joao Almeida 04 Feb '25

04 Feb '25

Hi, Is it possible to add the feature to output all elements like: Test map mkgmap has a built-in feature to make a map containing all(?) possible points, lines and polygons. This is useful to see how different Garmin types looks like. export BASE_LAT=50.0 export BASE_LONG=10.0 java -jar mkgmap.jar test-map:all-elements but instead of producing an .img file I'm looking to produce an .osm file in order to be able to manipulate it... Cheers Joao

2 2

Feature Request
by Joao Almeida 03 Feb '25

03 Feb '25

Hi, Is it possible to add the feature to output all elements like: Test map mkgmap has a built-in feature to make a map containing all(?) possible points, lines and polygons. This is useful to see how different Garmin types looks like. export BASE_LAT=50.0 export BASE_LONG=10.0 java -jar mkgmap.jar test-map:all-elements but instead of producing an .img file I'm looking to produce an .osm file in order to be able to manipulate it... Or if anyone knows how to apply a TYP file to that img file please let me know... Cheers Joao

1 0

Removing Dead Ends
by osm 12 Jan '25

12 Jan '25

Hi Recently, an area has become riddled with short highways=footway leading to individual houses ; these are (perhaps correctly) not marked private as they are drawn from a residential road. They are basically dead ends. Problem is they 'freeze up' the map on my garmin. I can delete them using the length <5m tag but that will also remove footways which are short and NOT dead ends. Is there a boolean mkgmap:report_dead_end I can use? Regards Nick

2 2

Commit r4923: failed-render.patch:
by svn commit 08 Jan '25

08 Jan '25

Version mkgmap-r4923 was committed by gerd on Wed, 08 Jan 2025 failed-render.patch: - Improve partitioning of complex multipolygons by splitting into exact halves - Don't stop to render a multipolygon when a partition turns out to be invalid - replace error message "Failed to render ..." by a warning with more information http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4923

1 0

Re: [mkgmap-dev] Internal Error Failed to render Multipolygon
by Ticker Berkin 24 Dec '24

24 Dec '24

Hi Thomas I've just loaded the relation 1754729 with JOSM. JOSM validation reports no errors, but mkgmap (direct, no splitting) gives errors: WARN: uk.me.parabola.imgfmt.app.Area lakeLadoga.osm: Area.split 2852864 1400832 2854912 1402880 res 11 can't 2 1 WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation lakeLadoga.osm: Multipolygon http://www.openstreetmap.org/relation/1754729 [ele=4.84, int_name=Ladoga lake, name:en=Lake Ladoga, name=Ладожское озеро, natural=water, type=multipolygon, water=lake] contains errors. WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation lakeLadoga.osm: Polygon 4611686018427403156(4P)(259078070[118P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon The area.split WARN happens when there are too many object (points/lines/polygons) in 1 resolution unit. The other error is as described. I notice that this relation was edited a couple of days ago so maybe someone is fixing or creating problems. I'll try again in a few days and investigate more deeply. Regards Ticker On Mon, 2024-09-02 at 19:44 +0200, Thomas Morgenstern wrote: > Hi Ticker, I found : osmium-tool and splitter works proper. I can the > splitted <12345678>.osm.pbf open and render in JOSM. JOSM shows the part of > the multipolygon 1754729, which is inside the boundary of the polygonfile for > splitter. I assume, mkgmap has the problem. But sorry, I am not a good > programmer and can not do deeper investigation or find a solution. If you > interested, I can give you my polygon and the <maptile-number>.osm.pbf. > > Thomas > > > Am 02.09.2024 um 15:04 schrieb Ticker Berkin: > > > > > > Hi Thomas > > > > I get similar problems just using > > > > https://download.geofabrik.de/europe/britain-and-ireland.html > > > > directly. The relations that cause the problem are not within the above > > combined > > territories but excluding them would required a much more complicated shape > > to > > define the download area. > > > > Ticker > > > > On Mon, 2024-09-02 at 12:42 +0200, Thomas Morgenstern wrote: > > > > > > > > Hi Ticker, i made further investigation. You are right.: the > > > MultiPolygonRelation 1754729 ('Ladoga sea') was cut by ectract Scandinavia > > > from europe-latest.osm.pbf using osmium-tool . > > > I am not sure, but means this, that osmium can not write a proper > > > ectract, > > > if such Relation must bee split ? > > > This means also, osmium has a bug ? I must check my osmium version... > > > regards Thomas > > > > > > > > > Am 02.09.2024 um 10:30 schrieb Ticker Berkin: > > > > > > > > > > > > > > > > > > > > > Hi Thomas > > > > > > > > It isn't related to AngleChecker. > > > > > > > > I notice that both these relations have been changed in the last couple > > > > of > > > > days > > > > so maybe they were faulty. > > > > > > > > The large one is on the boarder with Scandinavia and it is likely that > > > > the > > > > map > > > > extraction download only had part of it and this gives rise to this type > > > > of > > > > error. > > > > > > > > Regards > > > > Ticker > > > > > > > > On Mon, 2024-09-02 at 09:43 +0200, Thomas Morgenstern wrote: > > > > > > > > > > > > > > > > > > > > > > > Hello , I use mkgmap-4921 with patch from Ticker Berkin - > > > > > Angelchecker-V6. > > > > > With that i get in Scandinavia following error : Internal Error Failed > > > > > to > > > > > render MultiPolygonRelation 1754729 and 304507. Rel. 1754729 is > > > > > 'Ladoga'- > > > > > sea > > > > > with 5 226 Elements. Rel. 304507 is Multipolygon=water, 171 Elements. > > > > > I assume the error ist not specific to the patch...and more common.. > > > > > How to avoid this ? > > > > > > > > > > regards Thomas > > > > > > > > > > _______________________________________________ > > > > > mkgmap-dev mailing list > > > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > >

2 7

Error or feature?
by Gerd Petermann 23 Dec '24

23 Dec '24

Hi all, this discussion in the German forum https://community.openstreetmap.org/t/mkgmap-extra-pois-definieren/122931 brought up an issue with mkgmap and the --nsis option. With the command java -jar mkgmap.jar --nsis --output-dir=map examples\typ-files\mapnik.txt somedata.osm the *.typ file is copied into the output directory ./map as expected while the this sequence which compiles the typ file first java -jar mkgmap.jar examples\typ-files\mapnik.txt java -jar mkgmap.jar --nsis --output-dir=map mapnik.typ somedata.osm doesn't copy the *.typ file to the output directiory ./map but the *.nsi file expects it there. Does anybody remember if there is a good reason for this different behaviour? For me it looks plain wrong. Gerd

1 1

Problem in AngleFixer?
by Gerd Petermann 15 Dec '24

15 Dec '24

Hi all, in a private email Thorsten Kukuk contacted me about wrong turn instructions a sharp angles. An example is the node https://www.osm.org/node/27550903 A route coming from South that follows the way https://www.osm.org/way/36138336 at this junction should NOT produce a turn instruction. A route that turns left SHOULD produce a turn instruction. With current mkgmap it's vice versa and thus not OK. I thnk the current code in AngleFixer.java is too agressive as it tries to enlarge the angles so that a compact format can be used to write the heading values of the arcs at the mentioned node. It does this by changing the heading values of both arcs with go to the north. @Ticker: The code was introduced with your arcHeading_v2.patch, but maybe it existed before. Can you explain why the constant AngleChecker.SHARP_DEGREES is set to 46° instead of maybe 22.5° ? Gerd

3 37