Re: [mkgmap-dev] splitter r590,wrong handling of relations
Hi Thomas, I've just fixed the relation [1], so please try again with a fresh download tomorrow. Gerd [1] https://www.openstreetmap.org/changeset/56139020 Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Dienstag, 6. Februar 2018 14:47 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations Hi Thomas, the relation is broken. Use JOSM validator and it will report 2 errors. I think this way https://www.openstreetmap.org/way/556302821 should not belong to it and a few nodes should be merged to repiar it: node 4298102908 node 4298102907 node 655141348 Gerd Von: mkgmap-dev im Auftrag von Thomas Morgenstern Gesendet: Dienstag, 6. Februar 2018 14:35 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations Hi Gerd, i have now made a different split, so that 1 tile contains the whole isle. In this case it looks good. I assume, that the relation is okay. No idea what should be changed in data. Also i have looked before with JOSM in the old split and confirm, that in the left tile the relation also exists, but not rendered from mkgmap. I can't judge, if the relation is broken or not. Therefore the problem is in mkgmap ? I thomas -- Von: "Gerd Petermann" Datum: Dienstag, 6. Februar 2018 12:15 An: "Thomas Morgenstern" ; "Development list for mkgmap" Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations > Hi Thomas, > > I think the problem is that the relation is broken. Splitter writes it to > both tiles, but > mkgmap seems to have problems with it. > Anyway, the problem is in the data and should be fixed in OSM. > > Gerd > > > > Von: mkgmap-dev im Auftrag von > Thomas Morgenstern > Gesendet: Dienstag, 6. Februar 2018 12:50 > An: Development list for mkgmap > Betreff: [mkgmap-dev] splitter r590,wrong handling of relations > > Hi Gerd, i found out, that splitter r590 can not proper handle the > relation > 2.691.138. I can reproduce the problem. It makes no different, if I splitt > the canary-islands-latest.osm.pbf with the default-option or with my own > splitt.list. If I move the tileborder by changing the nord-south border, > also the problem is moved. See picture at > http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary > splitter > creates only for the rightsite tile the polygon for tag > boundary=protected_area , respektive leisure=nature_reserve. In the > leftsite-tile this tags are missing. > maybee you can have a look at that ? > > regards thomas > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] max-jobs patch
Hi Gerd, please find attached v2 of the max-jobs patch. This version additionally catches out of heap memory exceptions and displays a message suggesting either the use of the Java -Xmx option to increase the available heap memory or the mkgmap --max-jobs option with a smaller value to reduce the memory requirement (the latter is suggested only if using more than one thread). How does that seem? Regards, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 05 February 2018 07:28 To: Mike Baggaley ; 'Development list for mkgmap' Subject: Re: [mkgmap-dev] max-jobs patch Hi Mike, thought about this again. Maybe this change is too simple. With multiple jobs one also needs more heap (-Xmx JRE option). If you create rather large tiles with splitter (max-nodes=160) you need 0.5 - 1 GB for each job. Not sure what happens when a user creates a map with 10 tiles on an 8-core machine without any -Xmx option. I fear this will result in OutOfMemory exception, so better check the available heap as well. Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Sonntag, 4. Februar 2018 15:14 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] max-jobs patch Hi Gerd, Please find attached a patch that amends the default behaviour if the --max-jobs option is not specified, to using a value equal to the number of CPU cores, as suggested in a previous post. The documentation is also amended to reflect the change. This halves the execution time of mkgmap for building a map of Staffordshire on my 8-core PC when --max-jobs is not specified (I didn't know about this option previously and was unaware the performance could have been improved). Cheers, Mike maxjobs-v2.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin uses overlapping tiles
Hi Andrzej, changing the TRE bounds helps sometimes, but not always :-( @Frank: All Garmin TRE files that I looked at where aligned to multiples of 4 map units. I tried this as well as aligning to multiples of 2, nothing worked without crashes so far. Anyhow, it seems to be the right thing to look at. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Dienstag, 6. Februar 2018 15:49 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Garmin uses overlapping tiles Hi Gerd, I guess basemap is overview map. 0x4A objects are derived form backgrounds of detailed tiles, but with resolution of overview map, it would be difficult to guess, if background overlap or not. I hope extending values written to TRE will work. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin uses overlapping tiles
Hi Gerd, i have only picked 1 IMG from the "Garmin TransAlpin v2" (Immenstadt im Allgau / 16596679.img). The TRE-borders are overlapping with 2 units with all the 4 neighbors. Perhaps a border-value is ever even (?). Frank___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin uses overlapping tiles
Hi Gerd, I guess basemap is overview map. 0x4A objects are derived form backgrounds of detailed tiles, but with resolution of overview map, it would be difficult to guess, if background overlap or not. I hope extending values written to TRE will work. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin uses overlapping tiles
Hi Andrzej, hard to say where exactly the DEM area ends on the right / bottom side. I got the info about 0x4a polygons from GPSMapEdit looking at the basemap. MapSource shows the tile boundary more or less exactly at E16.5, so I have no idea whrere the 0x4a value comes from. I don't plan to change splitter, I want to change the TRE file written by mkgmap. Working on a patch right now ... Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Dienstag, 6. Februar 2018 14:57 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Garmin uses overlapping tiles Hi Gerd, I have some questions. Is TRE area bigger than DEM area or tiles overlap but still DEM area is bigger than TRE? It looks like overlap is 4 Garmin's units, this is less than DEM raster size. > The next interesting point is that the 0x4a polygons of these two > tiles do NOT overlap. > They seem to share 768896 (!). Is it a typo? I guess: polygon 0x4B and 768856 Does map data overlap too, or this is only extended rectangle size written to TRE header? If backgrounds don't overlap, maybe real map data don't either. If I get border value right, than maybe tile is extended only at left and top border? What about routing nodes, if splitter creates overlapped tiles? I think there should be an external routing node where road crosses tile border. There would be mismatch, if tiles overlap. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin uses overlapping tiles
Hi Gerd, I have some questions. Is TRE area bigger than DEM area or tiles overlap but still DEM area is bigger than TRE? It looks like overlap is 4 Garmin's units, this is less than DEM raster size. > The next interesting point is that the 0x4a polygons of these two > tiles do NOT overlap. > They seem to share 768896 (!). Is it a typo? I guess: polygon 0x4B and 768856 Does map data overlap too, or this is only extended rectangle size written to TRE header? If backgrounds don't overlap, maybe real map data don't either. If I get border value right, than maybe tile is extended only at left and top border? What about routing nodes, if splitter creates overlapped tiles? I think there should be an external routing node where road crosses tile border. There would be mismatch, if tiles overlap. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter r590,wrong handling of relations
Hi Thomas, the relation is broken. Use JOSM validator and it will report 2 errors. I think this way https://www.openstreetmap.org/way/556302821 should not belong to it and a few nodes should be merged to repiar it: node 4298102908 node 4298102907 node 655141348 Gerd Von: mkgmap-dev im Auftrag von Thomas Morgenstern Gesendet: Dienstag, 6. Februar 2018 14:35 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations Hi Gerd, i have now made a different split, so that 1 tile contains the whole isle. In this case it looks good. I assume, that the relation is okay. No idea what should be changed in data. Also i have looked before with JOSM in the old split and confirm, that in the left tile the relation also exists, but not rendered from mkgmap. I can't judge, if the relation is broken or not. Therefore the problem is in mkgmap ? I thomas -- Von: "Gerd Petermann" Datum: Dienstag, 6. Februar 2018 12:15 An: "Thomas Morgenstern" ; "Development list for mkgmap" Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations > Hi Thomas, > > I think the problem is that the relation is broken. Splitter writes it to > both tiles, but > mkgmap seems to have problems with it. > Anyway, the problem is in the data and should be fixed in OSM. > > Gerd > > > > Von: mkgmap-dev im Auftrag von > Thomas Morgenstern > Gesendet: Dienstag, 6. Februar 2018 12:50 > An: Development list for mkgmap > Betreff: [mkgmap-dev] splitter r590,wrong handling of relations > > Hi Gerd, i found out, that splitter r590 can not proper handle the > relation > 2.691.138. I can reproduce the problem. It makes no different, if I splitt > the canary-islands-latest.osm.pbf with the default-option or with my own > splitt.list. If I move the tileborder by changing the nord-south border, > also the problem is moved. See picture at > http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary > splitter > creates only for the rightsite tile the polygon for tag > boundary=protected_area , respektive leisure=nature_reserve. In the > leftsite-tile this tags are missing. > maybee you can have a look at that ? > > regards thomas > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter r590,wrong handling of relations
Hi Gerd, i have now made a different split, so that 1 tile contains the whole isle. In this case it looks good. I assume, that the relation is okay. No idea what should be changed in data. Also i have looked before with JOSM in the old split and confirm, that in the left tile the relation also exists, but not rendered from mkgmap. I can't judge, if the relation is broken or not. Therefore the problem is in mkgmap ? I thomas -- Von: "Gerd Petermann" Datum: Dienstag, 6. Februar 2018 12:15 An: "Thomas Morgenstern" ; "Development list for mkgmap" Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations Hi Thomas, I think the problem is that the relation is broken. Splitter writes it to both tiles, but mkgmap seems to have problems with it. Anyway, the problem is in the data and should be fixed in OSM. Gerd Von: mkgmap-dev im Auftrag von Thomas Morgenstern Gesendet: Dienstag, 6. Februar 2018 12:50 An: Development list for mkgmap Betreff: [mkgmap-dev] splitter r590,wrong handling of relations Hi Gerd, i found out, that splitter r590 can not proper handle the relation 2.691.138. I can reproduce the problem. It makes no different, if I splitt the canary-islands-latest.osm.pbf with the default-option or with my own splitt.list. If I move the tileborder by changing the nord-south border, also the problem is moved. See picture at http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary splitter creates only for the rightsite tile the polygon for tag boundary=protected_area , respektive leisure=nature_reserve. In the leftsite-tile this tags are missing. maybee you can have a look at that ? regards thomas ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter r590,wrong handling of relations
Hi Thomas, I think the problem is that the relation is broken. Splitter writes it to both tiles, but mkgmap seems to have problems with it. Anyway, the problem is in the data and should be fixed in OSM. Gerd Von: mkgmap-dev im Auftrag von Thomas Morgenstern Gesendet: Dienstag, 6. Februar 2018 12:50 An: Development list for mkgmap Betreff: [mkgmap-dev] splitter r590,wrong handling of relations Hi Gerd, i found out, that splitter r590 can not proper handle the relation 2.691.138. I can reproduce the problem. It makes no different, if I splitt the canary-islands-latest.osm.pbf with the default-option or with my own splitt.list. If I move the tileborder by changing the nord-south border, also the problem is moved. See picture at http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary splitter creates only for the rightsite tile the polygon for tag boundary=protected_area , respektive leisure=nature_reserve. In the leftsite-tile this tags are missing. maybee you can have a look at that ? regards thomas ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter r590,wrong handling of relations
Hi Gerd, i found out, that splitter r590 can not proper handle the relation 2.691.138. I can reproduce the problem. It makes no different, if I splitt the canary-islands-latest.osm.pbf with the default-option or with my own splitt.list. If I move the tileborder by changing the nord-south border, also the problem is moved. See picture at http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary splitter creates only for the rightsite tile the polygon for tag boundary=protected_area , respektive leisure=nature_reserve. In the leftsite-tile this tags are missing. maybee you can have a look at that ? regards thomas ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Garmin uses overlapping tiles
Hi all, so far I've never seen the crash in MapSource using the Garmin maps, although they also have tiles with "invalid heights" and therefore the tile headers have the "Extra flag". my idea: - use mkgmap to create DEM data for exactly the same two areas as in a Garmin map [1] - Try to reproduce the crash with those two areas - replace Garmin DEM by mkgmap DEM and see what happens in MapSource The interesting point: Garmin tiles overlap. I've created this areas.list from the information in two Garmin TRE files: 0029: 2174824,745652 to 2190360,768956 # 46,6667,16, 47,,16,5000 0030: 2174824,768952 to 2190360,792260 # 46,6667,16,4999 47,,17,0001 Note that the first tile has eastern border at 768956 while the 2nd uses 768952 for the western border. When I use exactly those values I cannot reproduce the crash. When I move the boundary of one of the two tiles so that they are equal I can reproduce the crash, but not always with the same routes. I tried 768952, 768954, 768956. So, I tried to change mkgmap so that it calculates DEM as if the tile boundaries are overlapping, but with TRE where tiles have same 768956 --> crash possible. The next interesting point is that the 0x4a polygons of these two tiles do NOT overlap. They seem to share 768896 (!). So, I used a new areas.list with this value and still see the crash. My conclusion: We have to modify mkgmap to write a different TRE file, probably it has to cover the DEM area as well. Does that make sense? Gerd [1] TopoGuide Hungary 2.12c ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev