- mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00"
by gerard-mkgmap＠gmx.com 12 Mar '22

12 Mar '22

Hi Gerd and Bernhard, I made a lot of complementary tests that are still in progress to try to understand the issue. Among these tests, the main results are: 1) Just after the conversion of one elementary tile (ex: N45W001.HGT ) with hgt2osm, I can see the artefacts when I edit "mycontour.osm.pbf" with JOSM. 2) I generate contour lines for a large surface comprising Benelux and France, except a vertical band around 0% (see: https://drive.google.com/file/d/1r3v3UBc_Cfdm2vw1VepIvN3oM1JJVBp3/view?usp=s haring NB: I use Data from SONNY https://data.europa.eu/data/datasets/dtm-europe?locale=en) because they are for me the best data for Europe, data are from 2021 and comprising LIDAR measurement. --> The result after: All the contour lines are perfect. I don't see any problem !! 3) I generate contour lines for the vertical band around 0° In France and a local zone in SPAIN --> The Result: All contourlines have the Artefact at 0° 4) I choose also to generate contourlines from an another source of DEM data for France around 0° (ALOS data from Japan Aerospace https://www.eorc.jaxa.jp/ALOS/en/index_e.htm) --> The Result : Contourlines have all the same artefacts, just after conversion with hgt2osm. It is very clear for me, that SPLITTER and MKGMAP do perfectly their jobs. For now, I will try to have a look on using osm2srtm, but I am not sure that it is possible to have the choice to use the recent data from SONNY as input files !! Best regards, Gerard -----Message d'origine----- De : mkgmap-dev [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] De la part de Gerd Petermann Envoyé : vendredi 11 mars 2022 11:34 À : Development list for mkgmap Objet : Re: [mkgmap-dev] Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00" Hi Gerard, I don't know the program hgt2osm, I would suggest to contact the author or try one of the alternatives like srtm2osm or Phyghtmap: https://wiki.openstreetmap.org/wiki/Srtm2Osm https://wiki.openstreetmap.org/wiki/Phyghtmap Or do you think that the generated OSM data is okay and it is mkgmap that fails? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von Gerard CATTIAUX <gerard-mkgmap(a)gmx.com> Gesendet: Donnerstag, 10. März 2022 14:15 An: mkgmap-dev(a)lists.mkgmap.org.uk Betreff: [mkgmap-dev] Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00" 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 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 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=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 _______________________________________________ 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 12 Mar '22

12 Mar '22

Hi Gerd and Bernhard, I made a lot of complementary tests that are still in progress to try to understand the issue. Among these tests, the main results are: 1) Just after the conversion of one elementary tile (ex: N45W001.HGT ) with hgt2osm, I can see the artefacts when I edit "mycontour.osm.pbf" with JOSM. 2) I generate contour lines for a large surface comprising Benelux and France, except a vertical band around 0% (see: https://drive.google.com/file/d/1r3v3UBc_Cfdm2vw1VepIvN3oM1JJVBp3/view?usp=s haring NB: I use Data from SONNY https://data.europa.eu/data/datasets/dtm-europe?locale=en) because they are for me the best data for Europe, data are from 2021 and comprising LIDAR measurement. --> The result after: All the contour lines are perfect. I don't see any problem !! 3) I generate contour lines for the vertical band around 0° In France and a local zone in SPAIN --> The Result: All contourlines have the Artefact at 0° 4) I choose also to generate contourlines from an another source of DEM data for France around 0° (ALOS data from Japan Aerospace https://www.eorc.jaxa.jp/ALOS/en/index_e.htm) --> The Result : Contourlines have all the same artefacts, just after conversion with hgt2osm. It is very clear for me, that SPLITTER and MKGMAP do perfectly their jobs. For now, I will try to have a look on using osm2srtm, but I am not sure that it is possible to have the choice to use the recent data from SONNY as input files !! Best regards, Gerard -----Message d'origine----- De : mkgmap-dev [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] De la part de Gerd Petermann Envoyé : vendredi 11 mars 2022 11:34 À : Development list for mkgmap Objet : Re: [mkgmap-dev] Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00" Hi Gerard, I don't know the program hgt2osm, I would suggest to contact the author or try one of the alternatives like srtm2osm or Phyghtmap: https://wiki.openstreetmap.org/wiki/Srtm2Osm https://wiki.openstreetmap.org/wiki/Phyghtmap Or do you think that the generated OSM data is okay and it is mkgmap that fails? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von Gerard CATTIAUX <gerard-mkgmap(a)gmx.com> Gesendet: Donnerstag, 10. März 2022 14:15 An: mkgmap-dev(a)lists.mkgmap.org.uk Betreff: [mkgmap-dev] Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00" 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 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 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=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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

Contour lines with "Artefacts" near a vertical line situated at W0° 00' 00"
by Gerard CATTIAUX 11 Mar '22

11 Mar '22

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 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 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=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

3 2

Commit r4897: merge (again) from faster-mp branch
by svn commit 25 Feb '22

25 Feb '22

Version mkgmap-r4897 was committed by gerd on Fri, 25 Feb 2022 merge (again) from faster-mp branch http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4897

1 0

option link-pois-to-ways information
by Ticker Berkin 21 Feb '22

21 Feb '22

Hi all To improve routing, I'd like to get information about the POIS that are being linked to a WAY that can be used as part of the style/lines processing. The problem I'm trying to solve is to restrict car routing through some types of very low level roads (eg service) when there is a barrier. Setting mkgmap:throughroute=no on these works nicely with MapSource and older devices but BaseCamp and newer devices will happily route over a footpath to avoid a throughroute=no section. At the moment, with --link-pois-to-ways, if the POI has a barrier or highway tag, mkgmap:way-has-pois is set true. This can be tested by lines, inc/access etc, but there is no way to find out if it is a significant barrier or something like highway=street_lamp. points processing can set mkgmap: access & road_speed/class variables that are handled by inbuild code after lines processing to imposes more restrictions on the way and/or reduces speed/class; this is no use for what I want to do. Possibilities are: 1/ have options to say which POI tag/value combinations cause link-pois-to-ways 2/ set new variables on the way, eg mkgmap:barrier_tags/highway_tags, which are a list of distinct POI highway/barrier tag values. Ticker

3 16

splitter with --polygon-desc-file crashes
by 7770 16 Feb '22

16 Feb '22

Hi. I have asked long ago about this particular problem i have and it was long time ago i last tried, but now i did again. It relates to splitter and usage of --polygon-desc-file= This is how i have tried: 1. Download data for Estonia and Latvia. https://download.geofabrik.de/europe/estonia-latest.osm.pbf https://download.geofabrik.de/europe/latvia-latest.osm.pbf 2. convert to o5m and combine osmconvert estonia-latest.osm.pbf -o=estonia-latest.osm.o5m; osmconvert latvia-latest.osm.pbf -o=latvia-latest.osm.o5m; osmconvert estonia-latest.osm.o5m latvia-latest.osm.o5m -o=ee_lv.o5m; 3. Prepare an osm-polygon file with one area for Estonia and one for Latvia. (file attached) 4. Run splitter: java -Xmx2000m -jar ${SPLITTER} \ --polygon-desc-file=./polygon_ee_lv.osm \ --output-dir=ee_lv/splitted/ \ --max-nodes=750000 \ --no-trim \ ee_lv.o5m While running this is seems like the Latvia part is fine, but the Estonia crashes. The error message doesn't say much (that i understand). But maybe it makes some sense to you? I imagine something is wrong with the polygon file, but i dont know what. The polygon files is partially made in JOSM and partially manaully to re-use the same segments/edges which belong to both countries. (I could see that Gerd was using this concept in some example file for Germany and the alps, but i could not add two ways over one edge in JOSM, so i made manual chanegs in the file). I tried also making two separate boxes, one for each country, but that was just as bad (not reusing edges). Anything that could be suggested that i change or try? PS. i am trying this on small scale for two smaller countries, later i will apply it because i need to split europe in parts of max 4GB. Regards Karl

2 2

Patch: use all 4 bytes of POIGlobalFlags in LBL Header
by Gerd Petermann 12 Feb '22

12 Feb '22

Hi devs, attached patch simplifies the code, but should not change anything in the output of mkgmap. GPXSee contains code to evaluate some of the bits which were ignored so far. Do you see any problems? Gerd

3 6

Commit r4896: step 1 of partial merge from mdr2 branch
by svn commit 11 Feb '22

11 Feb '22

Version mkgmap-r4896 was committed by gerd on Fri, 11 Feb 2022 step 1 of partial merge from mdr2 branch - don't render natural=coastline as lines, this is rarely useful - don't fill string table and don't create tempFile for strings when calculating global index for gnapsupp. This reduces I/O and peak memory usage. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4896

1 0

Work in progress and the mdr2 branch
by Gerd Petermann 10 Feb '22

10 Feb '22

Hi all, during the last days I've mainly rewritten GPXSee code in Java to be able to understand all the new structures in NT format. I am making progress but it will probably take weeks until I really understand any of it. The code in GPXSee is written to be very fast and it silently stops reading whereever bits or bytes have unexpected values, something that we cannot do when we want to be able to write that format. Most confusing for me is that it reads parts of the NOD file backwards (at least I think that is what class BitStream4R does). Anyway, while debugging I see data that looks correct, e.g. some road geometry and labels match the data shown in GPXSee, so I think it's just a matter of time to get to the point where GPXSee is now. I wonder if I should try to merge the mdr2 branch into trunk first? It's major changes so far are: - ability to use Huffman compression MDR15 (the string table in the global PC index *_mdr.img) - different (hopefully better) handling of mixed cased labels (--lower-case option) - changes from the faster-mp branch - possibly more memory needed to write global POI index (mdr11) - default style change to not render natural=coastline as line (*) - reduced I/O because no strings temp file written for gmapsupp index (*) (*) It would be quite easy to do this in trunk as well without merging the rest of the changes Gerd

3 2

Commit r4895: oops, 4894 caused a change (and infinite(?) loop in unit test
by svn commit 04 Feb '22

04 Feb '22

Version mkgmap-r4895 was committed by gerd on Fri, 04 Feb 2022 oops, 4894 caused a change (and infinite(?) loop in unit test http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4895

1 0