- mkgmap-dev - The mkgmap lists

some findings about NT format
by Gerd Petermann 15 Apr '22

15 Apr '22

Hi all, my findings so far which are not used / needed in GPXSee. Maybe it helps someone else: - method linkLabel() could extract further road labels, bit 0x800000 flags the last of up to 4 labels. - method linkLabel() extracts a flag, the bit 0x08 in this flag seems to signal a tunnel. No idea yet what the other bits mean. - the flags field in struct LinkInfo is used like this (netfile.cpp) bool firstIsShape = (linkInfo.flags >> 10) & 1; bool singleTopology = (linkInfo.flags >> 9) & 1; bool hasLevels = (linkInfo.flags >> 11) & 1; My guesses about the meaning of the lower bits: // int road_speed = linkInfo.flags & 7; // bool oneway = (linkInfo.flags >> 3) & 1; // int road_class = (linkInfo.flags >> 4) & 7; - The NET header can have two more sections, e.g. I see 00000684 | f6 cb 13 00 | NET5 ???, offset 13cbf6 00000688 | 96 0a 01 00 | NET5 ???, length 68246 0000068c | 23 00 | ??? 0000068e | 8c d6 14 00 | NET6 ???, offset 14d68c 00000692 | 28 05 00 00 | NET6 ???, length 1320 00000696 | 03 00 | NET6 ??? record size 3 00000698 | 02 00 00 00 | ??? NET6 contains a list of offsets into NET4, they are in sorted order and each offset points to the byte following the flag byte that is read in linkLabel() I see 440 recrods here, and 441 NOD6 records in the corresponding NOD file, so they are obviously related (field blockIndexId). I've not yet found where the address info like city name, zip name, and house numbers are stored. Maybe that's in NET5. I think in the old non-NT format there is no need to know NOD data to be able to read NET, so I woulld expect that this is also possible with NT maps. Gerd

4 11

Commit r4899: Polish input: Only create roads for line types which are considered special routable types,
by svn commit 08 Apr '22

08 Apr '22

Version mkgmap-r4899 was committed by gerd on Fri, 08 Apr 2022 Polish input: Only create roads for line types which are considered special routable types, not all types 0x01..03f http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4899

1 0

Commit r4898: prevent NullPointerException for roads which are not added to NOD
by svn commit 08 Apr '22

08 Apr '22

Version mkgmap-r4898 was committed by gerd on Fri, 08 Apr 2022 prevent NullPointerException for roads which are not added to NOD http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4898

1 0

"Too many roads"
by John Thorn 08 Apr '22

08 Apr '22

I am working on a map of France based on Open IGN, OSM and other sources. I have broken it into tiles 0.25 latitude by 0.5 longitude. I built a set of contours using 'marching squares' on the IGN Height data.. But MKGMAP fails on some of the contour tiles saying 'Too many roads' (which I guess is really Too many Polylines). Is this a limit on the number of Polylines (I could join some shorter ones together) or a limit on the number of data points? Thanks, John www.the-thorns.org.uk/46251550.mp

2 1

mkgmap:area2poi placement
by lig fietser 06 Apr '22

06 Apr '22

Hi, I've noticed on my map that mkgmap places the poi of an area like the "Nationalpark Niedersächsisches Wattenmeer" (https://www.openstreetmap.org/relation/157811) outside of the National Park, so not in the sea but on the mainland near Wittmund. I prefer to place those pois inside such odd shapes polygons. OSM carto puts the label just east of Borkum. I'm not sure if there was a mkgmap option how to control this behaviour? I know it can be done by manipulating the OSM data and add a label, but I prefer to control this in mkgmap.

3 6

lake made up from multipolygon relation
by 7770 25 Mar '22

25 Mar '22

Hi. The type=multipolygon relation with number 2 141 543 is a lake. it has the tags: natural=water and water=lake. The included members (lines) does not have these tags. This lake is not rendered when i generate maps. other lakes (which are regular enclosed polygons) render just fine. The lake and relation does not look wrong but i maybe something is incorrect in it, which i dont understand. Or, could i have missed something in a style that should deal with such lakes? The lake is called Haggen, it is in Ludvika and Smedjebacken municipality in Sweden. https://www.openstreetmap.org/relation/2141543 Regards Karl

2 2

Re: [mkgmap-dev] lake made up from multipolygon relation
by Gerard Cattiaux 25 Mar '22

25 Mar '22

Hi Karl, I just have a look with JOSM of the Haggen lake. At first sight, all seems good. I also downloaded a little surface around Ludvika with data from https://extract.bbbike.org/ After using Splitter and mkgmap, the lake seems correctly displayed in Basecamp. The result in Basecamp is given here https://files.mkgmap.org.uk/download/550/Haggen-Ludvika.pdf Probably a little issue in polygons style files. Regards Gerard -----Message d'origine----- De : mkgmap-dev [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] De la part de 7770 Envoyé : vendredi 25 mars 2022 18:17 À : mkgmap-dev(a)lists.mkgmap.org.uk Objet : [mkgmap-dev] lake made up from multipolygon relation Hi. The type=multipolygon relation with number 2 141 543 is a lake. it has the tags: natural=water and water=lake. The included members (lines) does not have these tags. This lake is not rendered when i generate maps. other lakes (which are regular enclosed polygons) render just fine. The lake and relation does not look wrong but i maybe something is incorrect in it, which i dont understand. Or, could i have missed something in a style that should deal with such lakes? The lake is called Haggen, it is in Ludvika and Smedjebacken municipality in Sweden. https://www.openstreetmap.org/relation/2141543 Regards Karl _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

Re: [mkgmap-dev] Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00"
by Gerard Cattiaux 21 Mar '22

21 Mar '22

Hi Bernhard, I recently made a few new tests with an old release of phyghtmap (the release 1.47 tested §4.3 Windows Installation, see http://katze.tfiu.de/projects/phyghtmap/) A comparison between hgt2osm and phyghtmap (1.42) is given at this link: https://drive.google.com/file/d/1loWwr6JE9wq1rORKWae7CNAqn0t3h62L/view?usp=s haring We also can see cut contour lines only at 0°. But phyghtmap don't generate horizontal lines. IMHO I think that this little issue could be easily solved by Frank Stinner the developer of hgt2osm. I tried to send him an email about these "artefacts" near 0°, hopping the email addresses are correct and in usage. fstinner at gmx.de frank.stinner at kabelmail.de Best regards, Gerard De : mkgmap-dev [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] De la part de Bernhard Hiller Envoyé : vendredi 11 mars 2022 17:23 À : mkgmap-dev(a)lists.mkgmap.org.uk Objet : Re: [mkgmap-dev] Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00" Hi Gerard, you can check the elevation contour lines by opening the file generated by your tool in e.g. JOSM (my take some time when the file is large). Strange distortions are expected at the borders of the whole set of input files, but not where input files are adjacent to each other. Your description seems to hint to a bug when crossing the 0°-meridian. I do not know how srtm2osm reacts there, it might be worth to try it. Kind regards, Bernhard Am 10.03.2022 um 14:15 schrieb Gerard CATTIAUX: Hello, After many hours of time to get a correct knowledge of the most important tools needed to produce Garmin map, like mkmap, Splitter.. and plenty of hours to develop my own Styles files for mkgmap, I am now able to produce local maps mainly for Fenix 6x or Garmin 66, specifically for Trail Running. That help me also to have a mean to verify immediately all my contributions to OSM database. To have the best results for my personal maps, I use altitude data from Sonny. <https://data.europa.eu/data/datasets/dtm-europe?locale=en> https://data.europa.eu/data/datasets/dtm-europe?locale=en For flat part of the country, I generally generate contour lines with a 5m space, in lieu of a 10m or 20m space between contours lines. That choice seems for me a very good choice for as an example "Ile de France" (Extended Region around Paris), where max altitude are between 150 to 200m. I recently generate contourlines near La Rochelle in France for a local zone called "Poitou-Charentes", <http://download.geofabrik.de/europe/france/poitou-charentes.html> http://download.geofabrik.de/europe/france/poitou-charentes.html but unfortunately, I have artefacts, that I don't have for example in many other regions of France. These artefacts are also visible for 5m, 10m and 20m space between contours lines. These "artefacts" are described in the pdf files given at this link: <https://drive.google.com/file/d/1uiA51R4Kd_WYsdeTrEtevu2jJ_8aPinH/view?usp= sharing> https://drive.google.com/file/d/1uiA51R4Kd_WYsdeTrEtevu2jJ_8aPinH/view?usp=s haring To generate my contour lines, I use mainly hgt2osm, with hgt files from Sonny. Hgt files in the example : N46W002.zip N46W001.zip N46E000.zip N45W002.zip N45W001.zip N45E000.zip Command line hgt2osm -g HGT-AFAIRE --MinorDistance=10 Hgt2Osm, 13.11.2017, FSofT 64 Bit-OS: ja Programmodus 64 Bit: ja MinorDistance: 10 MediumFactor: 5 MajorFactor: 5 HGT-Verzeichnis: HGT-AFAIRE Mergefile: OutputOverwrite: False Höhenkorrektur: -0.5 MinVerticePoints: 3 MinBoundingbox: 0.0005 Douglas-Peucker: 0.04 1. OSM-ID: -1 mit OSMBound: False mit OSMBounds: True mit OSMTimestamp: True mit OSMVersion: 1 mit OSMVisible: False max. Punktanzahl je Weg: 500 mit 'contour_ext'-Tag: True At first sight, it seems that all these artefacts begin just near a vertical line situated at W0° 00' 00" / E0° 00' 00" Any ideas to helps me to solve the problem? Many thanks Regards Gerard Cattiaux

1 0

Update on mapnik.txt typ file
by Joris Bo 21 Mar '22

21 Mar '22

Hi, In attachment a new version of the mapnik.txt typ-file. The one that comes with mkgmap at the moment is not editable by typviewer. I made the follwing changes to be alligned with mkgmap-4895 default-style - Compiled to .typ with mkgmap, opened with typviewer and exported as utf-8 to make it typviewer compliant again - Recreated language 0x04 English if not exists anymore - Made translations 0x00 (unknown/default) same as 0x04 English - If 0x00 Default does not exist, created copy from 0x04 englisch - Re-translated some items - Added amenity=bench 0x6505 - Added water point 0x650d - Added symbol for borderpatrol same as police - Duplicate camp_site 0x2b03 from 0x2b05 Kind regards, Joris

2 3

Bug in LblFileReader
by Gerd Petermann 16 Mar '22

16 Mar '22

Hi devs, one of the reason that I needed so long to figure out the zip/city encoding in the NT format is that LBLFileReader.getZips() returns a more or less shuffled version of the list of zip codes in the LBL file. Reason is that we store the zips in a HashMap instead of an ArrayList. No idea why we do that. It seems it did no harm so far... Gerd

2 1