Re: [mkgmap-dev] splitter: option for maximum tile area?
Ansonsten ist es so, wie ich vermutet habe. Srtm2OSM erzeugt elend lange Wege mit z.B. 184.962 Punkten. Die laufen dann natürlich weit über die Bounding Box hinaus und machen es wohl auch mkgmap schwer, weil die Wege erst recht spät abgeschnitten werden. Fazit: Das Problem ist in Srtm2OSM, versuch es mal mit der Option -maxwaynodes=5000 oder noch kleiner. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Sonntag, 4. November 2018 11:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? Hallo Bernhard, wolltest Du nicht max-nodes verringern? Jetzt ist es sogar 3.000.000 anstatt 1.400.000 Gerd Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Sonntag, 4. November 2018 11:19 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? Hi Gerd, I've uploaded some files: splitter log: https://drive.google.com/open?id=12wsnncNkfwKruEw-4UIgmvddK3E_TxtE kml: https://drive.google.com/open?id=1UOv_FTtl_pK_Nj126WDFnirhaswnvyfZ smallest tile: https://drive.google.com/open?id=1_yDKKpALKSfiRTiicCrEOYgH1vKmnm4w largest tile: https://drive.google.com/open?id=1aidryuJuhixrJIHHou3sibbBNBpRWJeN Kind regards, Bernhard Am 03.11.2018 um 11:38 schrieb Gerd Petermann: > Hi Bernhard, > > please post a link to one of the files produced by splitter. If the sum of > file sizes is much larger than the input file that means that each file > contains a lot of data that was written to keep ways complete. Maybe srtm2osm > creates lots of very long ways ? > > Gerd > > > Von: mkgmap-dev im Auftrag von > Bernhard Hiller > Gesendet: Samstag, 3. November 2018 11:25 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? > > Hi Gerd, > contour lines were created with srtm2osm -step 25 -cat 500 100 25 > -large with 3" elevation data downloaded from viewfinderpanoramas. > The mkgmap parameters contain "--add-pois-to-areas", but no > "--add-pois-to-lines" (the splitter parameters contain neither - as Ralf > said). > The style for contour lines is simple: > contour=evation & ele<=0 { delete contour; } > contour=evation & contour_ext=elevation_major { name > '${ele|conv:m=t}'; } [0x22 level 4] > contour=evation & contour_ext=elevation_medium { name > '${ele|conv:m=t}'; } [0x21 level 2] > contour=evation & contour_ext=elevation_minor { name > '${ele|conv:m=t}'; } [0x20 level 0] > There are no rules for contours in the points and polygons file. The > options file defines the levels only. > > Running splitter on the contour lines file only, creates several pdb > files summing up to 4.5 GB > =the problem is with the contour lines. > > Next, I'll try to cut Laos from the contour lines file and create a > contour lines map of Laos only... > > Kind regards, > Bernhard > > Am 02.11.2018 um 19:31 schrieb Gerd Petermann: >> Hi Bernhard, >> >> just a guess: If you use option --add-pois-to-lines and you have a rule in >> the points file which processes ele to add a POI >> you may see something like that. >> >> Gerd >> >> >> Von: mkgmap-dev im Auftrag von Gerd >> Petermann >> Gesendet: Freitag, 2. November 2018 19:24 >> An: Bernhard Hiller; Development list for mkgmap >> Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? >> >> Hi Bernhard, >> >> what are your rules for the contour lines? >> >> Gerd >> >> >> Von: mkgmap-dev im Auftrag von >> Bernhard Hiller >> Gesendet: Freitag, 2. November 2018 19:18 >> An: mkgmap-dev@lists.mkgmap.org.uk >> Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? >> >> Hi all, >> still struggling with that strange issue. But I guess I found some hint >> to the cause: inconsistent file sizes. >> - extracted OSM data: 400 MB pbf >> - elevation contour lines: 600 MB pbf >> - merged file: 1 GB pbf >> So far, sizes are consistent. >> >> When I run splitter on the OSM data only file, it produces many tiles >> summing up to some 400 MB. Consistent, too. When I run mkgmap on this >> output, I get a map within about half an hour, and it looks OK (tested >> with QLandkarte). >> >> When I run splitter on the merged file, the tiles sum up to some 9 GB. >> That is 9 times the size I'd expect. mkgmap can render several of those >> tiles (but very slowly); and then crashes on one of them with an >> OutOfMemory exception. >> >> So I think that the problem is somewhere in those contour lines, either >> when merged or alone. >> I'll try to create a contour lines only map as the next step to test >> this hypothesis. >> >> Kind regards, >> Bernhard >> >> Am 01.11.2018 um 09:32 schrieb Gerd Petermann: >>> Hi Bernhard, >>> >>> I tried to reproduce the memory problems with tile 47120005. I don't think >>> that the sea itself is a problem
Re: [mkgmap-dev] splitter: option for maximum tile area?
Hallo Bernhard, wolltest Du nicht max-nodes verringern? Jetzt ist es sogar 3.000.000 anstatt 1.400.000 Gerd Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Sonntag, 4. November 2018 11:19 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? Hi Gerd, I've uploaded some files: splitter log: https://drive.google.com/open?id=12wsnncNkfwKruEw-4UIgmvddK3E_TxtE kml: https://drive.google.com/open?id=1UOv_FTtl_pK_Nj126WDFnirhaswnvyfZ smallest tile: https://drive.google.com/open?id=1_yDKKpALKSfiRTiicCrEOYgH1vKmnm4w largest tile: https://drive.google.com/open?id=1aidryuJuhixrJIHHou3sibbBNBpRWJeN Kind regards, Bernhard Am 03.11.2018 um 11:38 schrieb Gerd Petermann: > Hi Bernhard, > > please post a link to one of the files produced by splitter. If the sum of > file sizes is much larger than the input file that means that each file > contains a lot of data that was written to keep ways complete. Maybe srtm2osm > creates lots of very long ways ? > > Gerd > > > Von: mkgmap-dev im Auftrag von > Bernhard Hiller > Gesendet: Samstag, 3. November 2018 11:25 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? > > Hi Gerd, > contour lines were created with srtm2osm -step 25 -cat 500 100 25 > -large with 3" elevation data downloaded from viewfinderpanoramas. > The mkgmap parameters contain "--add-pois-to-areas", but no > "--add-pois-to-lines" (the splitter parameters contain neither - as Ralf > said). > The style for contour lines is simple: > contour=evation & ele<=0 { delete contour; } > contour=evation & contour_ext=elevation_major { name > '${ele|conv:m=t}'; } [0x22 level 4] > contour=evation & contour_ext=elevation_medium { name > '${ele|conv:m=t}'; } [0x21 level 2] > contour=evation & contour_ext=elevation_minor { name > '${ele|conv:m=t}'; } [0x20 level 0] > There are no rules for contours in the points and polygons file. The > options file defines the levels only. > > Running splitter on the contour lines file only, creates several pdb > files summing up to 4.5 GB > =the problem is with the contour lines. > > Next, I'll try to cut Laos from the contour lines file and create a > contour lines map of Laos only... > > Kind regards, > Bernhard > > Am 02.11.2018 um 19:31 schrieb Gerd Petermann: >> Hi Bernhard, >> >> just a guess: If you use option --add-pois-to-lines and you have a rule in >> the points file which processes ele to add a POI >> you may see something like that. >> >> Gerd >> >> >> Von: mkgmap-dev im Auftrag von Gerd >> Petermann >> Gesendet: Freitag, 2. November 2018 19:24 >> An: Bernhard Hiller; Development list for mkgmap >> Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? >> >> Hi Bernhard, >> >> what are your rules for the contour lines? >> >> Gerd >> >> >> Von: mkgmap-dev im Auftrag von >> Bernhard Hiller >> Gesendet: Freitag, 2. November 2018 19:18 >> An: mkgmap-dev@lists.mkgmap.org.uk >> Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? >> >> Hi all, >> still struggling with that strange issue. But I guess I found some hint >> to the cause: inconsistent file sizes. >> - extracted OSM data: 400 MB pbf >> - elevation contour lines: 600 MB pbf >> - merged file: 1 GB pbf >> So far, sizes are consistent. >> >> When I run splitter on the OSM data only file, it produces many tiles >> summing up to some 400 MB. Consistent, too. When I run mkgmap on this >> output, I get a map within about half an hour, and it looks OK (tested >> with QLandkarte). >> >> When I run splitter on the merged file, the tiles sum up to some 9 GB. >> That is 9 times the size I'd expect. mkgmap can render several of those >> tiles (but very slowly); and then crashes on one of them with an >> OutOfMemory exception. >> >> So I think that the problem is somewhere in those contour lines, either >> when merged or alone. >> I'll try to create a contour lines only map as the next step to test >> this hypothesis. >> >> Kind regards, >> Bernhard >> >> Am 01.11.2018 um 09:32 schrieb Gerd Petermann: >>> Hi Bernhard, >>> >>> I tried to reproduce the memory problems with tile 47120005. I don't think >>> that the sea itself is a problem here, at least not when you use the >>> --precomp-sea option. It took only 15 secs to process that tile with asia >>> data from August with the default style and typical options for routing etc. >>> My input file didn't contain SRTM data so I assume this is the reason. >>> Maybe you have many contour lines with ele=our data? >>> >>> Gerd >>> >>> >>> Von: Gerd Petermann >>> Gesendet: Mittwoch, 31. Oktober 2018 22:49 >>> An: Gerd Petermann; Development list for mkgmap >>> Betreff: AW: [mkgmap-dev] splitter: option for maximum tile area? >>> >>> Hi
Re: [mkgmap-dev] splitter: option for maximum tile area?
Hi Gerd, I've uploaded some files: splitter log: https://drive.google.com/open?id=12wsnncNkfwKruEw-4UIgmvddK3E_TxtE kml: https://drive.google.com/open?id=1UOv_FTtl_pK_Nj126WDFnirhaswnvyfZ smallest tile: https://drive.google.com/open?id=1_yDKKpALKSfiRTiicCrEOYgH1vKmnm4w largest tile: https://drive.google.com/open?id=1aidryuJuhixrJIHHou3sibbBNBpRWJeN Kind regards, Bernhard Am 03.11.2018 um 11:38 schrieb Gerd Petermann: Hi Bernhard, please post a link to one of the files produced by splitter. If the sum of file sizes is much larger than the input file that means that each file contains a lot of data that was written to keep ways complete. Maybe srtm2osm creates lots of very long ways ? Gerd Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Samstag, 3. November 2018 11:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? Hi Gerd, contour lines were created with srtm2osm -step 25 -cat 500 100 25 -large with 3" elevation data downloaded from viewfinderpanoramas. The mkgmap parameters contain "--add-pois-to-areas", but no "--add-pois-to-lines" (the splitter parameters contain neither - as Ralf said). The style for contour lines is simple: contour=evation & ele<=0 { delete contour; } contour=evation & contour_ext=elevation_major { name '${ele|conv:m=t}'; } [0x22 level 4] contour=evation & contour_ext=elevation_medium { name '${ele|conv:m=t}'; } [0x21 level 2] contour=evation & contour_ext=elevation_minor { name '${ele|conv:m=t}'; } [0x20 level 0] There are no rules for contours in the points and polygons file. The options file defines the levels only. Running splitter on the contour lines file only, creates several pdb files summing up to 4.5 GB =the problem is with the contour lines. Next, I'll try to cut Laos from the contour lines file and create a contour lines map of Laos only... Kind regards, Bernhard Am 02.11.2018 um 19:31 schrieb Gerd Petermann: Hi Bernhard, just a guess: If you use option --add-pois-to-lines and you have a rule in the points file which processes ele to add a POI you may see something like that. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Freitag, 2. November 2018 19:24 An: Bernhard Hiller; Development list for mkgmap Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? Hi Bernhard, what are your rules for the contour lines? Gerd Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Freitag, 2. November 2018 19:18 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? Hi all, still struggling with that strange issue. But I guess I found some hint to the cause: inconsistent file sizes. - extracted OSM data: 400 MB pbf - elevation contour lines: 600 MB pbf - merged file: 1 GB pbf So far, sizes are consistent. When I run splitter on the OSM data only file, it produces many tiles summing up to some 400 MB. Consistent, too. When I run mkgmap on this output, I get a map within about half an hour, and it looks OK (tested with QLandkarte). When I run splitter on the merged file, the tiles sum up to some 9 GB. That is 9 times the size I'd expect. mkgmap can render several of those tiles (but very slowly); and then crashes on one of them with an OutOfMemory exception. So I think that the problem is somewhere in those contour lines, either when merged or alone. I'll try to create a contour lines only map as the next step to test this hypothesis. Kind regards, Bernhard Am 01.11.2018 um 09:32 schrieb Gerd Petermann: Hi Bernhard, I tried to reproduce the memory problems with tile 47120005. I don't think that the sea itself is a problem here, at least not when you use the --precomp-sea option. It took only 15 secs to process that tile with asia data from August with the default style and typical options for routing etc. My input file didn't contain SRTM data so I assume this is the reason. Maybe you have many contour lines with ele=our data? Gerd Von: Gerd Petermann Gesendet: Mittwoch, 31. Oktober 2018 22:49 An: Gerd Petermann; Development list for mkgmap Betreff: AW: [mkgmap-dev] splitter: option for maximum tile area? Hi Bernhard, looked again at the splitter command in your last post. You also use a rather high max-nodes value. Such a high value means that you get rather large tiles and that mkgmap needs more memory for each tile compared to the default 140. Many users use a value near 120. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Mittwoch, 31. Oktober 2018 22:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] splitter: option for maximum tile area? Hi Bernhard, there is no option for this. Do you use option --precomp-sea in splitter? Maybe you use --no-trim ? If