Re: [mkgmap-dev] Performance of POI search on the Device

p-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, now this sounds at least a little promissing for overlays with little data. I assume that my contourlines overlay that additionally holds the DEM data for hill shading (europe is almost 4GB) can n

Re: [mkgmap-dev] Performance of POI search on the Device

> > Gerd > > > Von: mkgmap-dev im Auftrag von > franco_bez > Gesendet: Dienstag, 2. Juni 2020 18:32 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Performance of POI search on the Device > > Hi Gerd, > &

Re: [mkgmap-dev] Performance of POI search on the Device

20 seconds. The rule is simple: The more tiles the higher the delay. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Sonntag, 19. Juli 2020 08:39 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the

Re: [mkgmap-dev] Performance of POI search on the Device

ice checks this. Looking at this now... Gerd Von: mkgmap-dev im Auftrag von franco_bez Gesendet: Dienstag, 2. Juni 2020 18:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, here's th

Re: [mkgmap-dev] Performance of POI search on the Device

Auftrag von Franco Bez Gesendet: Mittwoch, 10. Juni 2020 13:57 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, I did a little more testing. Is it possible that the presence of a complete address is the trigger ? I tried building maps

Re: [mkgmap-dev] Performance of POI search on the Device

___ > Von: mkgmap-dev im Auftrag von > Franco Bez > Gesendet: Samstag, 6. Juni 2020 10:39 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Performance of POI search on the Device > > Hi Gerd, > > I tried out my old Oregon 550 and my ZUMO 39

Re: [mkgmap-dev] Performance of POI search on the Device

: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, I tried out my old Oregon 550 and my ZUMO 396 The Oregon 550 behaves almost identical to the Oregon 750t. The boundary layer slows down the POI search by factor 10. Round about 1 sec

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, I tried out my old Oregon 550 and my ZUMO 396 The Oregon 550 behaves almost identical to the Oregon 750t. The boundary layer slows down the POI search by factor 10. Round about 1 sec without and 9 sec with the boundary layer. If I put all transparent layers on the SD Card it's 50 sec.

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, did you already try the "other things" ? Ciao, Franco Am 02.06.20 um 13:00 schrieb mkgmap-dev-requ...@lists.mkgmap.org.uk: > Betreff: > Re: [mkgmap-dev] Performance of POI search on the Device > Von: > Gerd Petermann > Datum: > 02.06.20,

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, here's the bondary-layer with x-center-poi-type=0x2f01 It slows down the search to the same extent as the other poi-types do. The option does not seem to have any impact. http://files.mkgmap.org.uk/download/477/dach_boundary_gmapsupp.img

Re: [mkgmap-dev] Performance of POI search on the Device

g, 2. Juni 2020 11:08 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, probabally I tried the "route" and "index" options with the patched version to see if it helps. (it didn't) I just tried the default center-POI

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, probabally I tried the "route" and "index" options with the patched version to see if it helps. (it didn't) I just tried the default center-POI type and 0x3200 - made no difference. I can do further testing in the evening. Ciao, Franco Gerd Petermann wrote > Hi Franco, > > interesti

Re: [mkgmap-dev] Performance of POI search on the Device

0 23:44 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd, some more test results: I switched back to the unpatched mkgmap-r4506. Instead I added some POIs to the boundary style (all fuel stations). This helped, now POI search is still fast.

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, some more test results: I switched back to the unpatched mkgmap-r4506. Instead I added some POIs to the boundary style (all fuel stations). This helped, now POI search is still fast. this file gives no problems, includes fuel stations

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, thanks for the binary. I did a lot of testing. I do not get any difference. As soon as I have a transparent layer, like housenumbers or bundaries the POI search is slow. not matter if I have "route" and "index" in the options or not. I also tried with and without "--x-center-poi-type=0x320

Re: [mkgmap-dev] Performance of POI search on the Device

ff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Franco, okay, I'll try to code a patch for this. Gerd Von: mkgmap-dev im Auftrag von franco_bez Gesendet: Montag, 1. Juni 2020 10:41 An: mkgmap-dev@lists.mkgmap.org.uk Betr

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Franco, okay, I'll try to code a patch for this. Gerd Von: mkgmap-dev im Auftrag von franco_bez Gesendet: Montag, 1. Juni 2020 10:41 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Hi Gerd,

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, I'm a little lost. I don't know how to proceed with the testing. I just tried a small map of the offensive "housenumber" layer. This makes no measurable difference in POI search. When I use a large "housenumber" map (covering DACH) the effect is significant. So I assume a single tile wou

Re: [mkgmap-dev] Performance of POI search on the Device

Von: mkgmap-dev im Auftrag von franco_bez Gesendet: Montag, 1. Juni 2020 10:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Gerd Petermann wrote > I also thought that the missing index of the over

Re: [mkgmap-dev] Performance of POI search on the Device

Gerd Petermann wrote > I also thought that the missing index of the overlay map might cause the > problem. I added an (empty) index to that map but that didn't help. > Maybe it helps to add a single (invisible) named POI to each tile. If that > helps it would prove that the bug is in the Oregon fir

Re: [mkgmap-dev] Performance of POI search on the Device

mkgmap Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Cool! Franco My godfeeling was telling me that this contourline overlay does do something. Did not yet find time to investigate it more properly. I also always have an Europe transparent contourline overlay map on my S

Re: [mkgmap-dev] Performance of POI search on the Device

: [mkgmap-dev] Performance of POI search on the Device Joris Bo wrote > Same for me. Even indexes of maps not 'enabed' are searched and if > covering the same area even displays duplicate results. > Where I first copied big maps to my Oregon just because there was > space enough

Re: [mkgmap-dev] Performance of POI search on the Device

Joris Bo wrote > Same for me. Even indexes of maps not 'enabed' are searched and if > covering the same area even displays duplicate results. > Where I first copied big maps to my Oregon just because there was space > enough on the 32GB SSD, now I build smaller maps and rename them if not > used th

Re: [mkgmap-dev] Performance of POI search on the Device

Von: mkgmap-dev im Auftrag von Joris Bo Gesendet: Montag, 1. Juni 2020 08:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Performance of POI search on the Device Same for me. Even indexes of maps not 'enabed' are searched and if covering the same

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, thank you so much. That did the trick. If I only have the one map file on my SD Card the POI search is incredibly fast. Now I try to identify the offending map(s) Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Re: [mkgmap-dev] Performance of POI search on the Device

holi)day(s) Kind Regards Joris -Oorspronkelijk bericht- Van: mkgmap-dev Namens Gerd Petermann Verzonden: maandag 1 juni 2020 08:21 Aan: mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] Performance of POI search on the Device Hi Franco, I had the same problem with my Oregon and foun

Re: [mkgmap-dev] Performance of POI search on the Device

Kukuk, but I have no idea why it causes the problems. I assume there is a firmware bug in the Oregon. Gerd Von: mkgmap-dev im Auftrag von franco_bez Gesendet: Montag, 1. Juni 2020 07:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Performance

[mkgmap-dev] Performance of POI search on the Device

Hi all, searching for POIs on my Oregon often is very frustrating. It virtually takes forever. Yesterday I noticed that some POI types are reasonably fast, while others are 10 times slower. I assume that this is some sort of index Problem. For example using my DACH map, built with mkgmap-r4506,

Re: [mkgmap-dev] performance best practice

Thx for the answer ! -Oorspronkelijk bericht- Van: mkgmap-dev Namens Gerd Petermann Verzonden: zaterdag 30 mei 2020 11:18 Aan: Development list for mkgmap Onderwerp: Re: [mkgmap-dev] performance best practice Hi Joris, yes, the evaluation of rules is already highly optimized. 1) It

Re: [mkgmap-dev] performance best practice

the evaluation of tags is very fast compared with the evaluation of e.g. a is_in(...) style function. Gerd Von: mkgmap-dev im Auftrag von Joris Bo Gesendet: Samstag, 30. Mai 2020 10:35 An: Development list for mkgmap Betreff: [mkgmap-dev] performance best pract

[mkgmap-dev] performance best practice

Hi I have a question about improving performance (I'm very happy already, I think is absolutely fast enough, its just that I could improve by doing things differently) I assume the is_in() function requires extra calculations and lookups which may cost time as well calculating unnecessary rules

Re: [mkgmap-dev] Performance with --bounds option

small increase in the bounds.zip. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 19. März 2020 15:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Performance with --bounds option Hi Gerd These are the timings I ge

Re: [mkgmap-dev] Performance with --bounds option

> Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 19. März 2020 11:04 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Performance with --bounds option > > Hi Gerd > > With the reversion of the code in r4469, the performance i

Re: [mkgmap-dev] Performance with --bounds option

: [mkgmap-dev] Performance with --bounds option Hi Gerd With the reversion of the code in r4469, the performance is acceptable again. It is only a few tiles that have this problem and, for GB, they don't add significantly to the overall map generation time Ticker On Thu, 2020-03-19 at 06:52 +,

Re: [mkgmap-dev] Performance with --bounds option

Von: mkgmap-dev im Auftrag > von Gerd Petermann > Gesendet: Mittwoch, 18. März 2020 19:46 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Performance with --bounds option > > Hi Ticker, > > I forgot to remove some experimental code for is-in bran

Re: [mkgmap-dev] Performance with --bounds option

Gesendet: Mittwoch, 18. März 2020 19:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Performance with --bounds option Hi Ticker, I forgot to remove some experimental code for is-in branch in BoundaryQuadTree. Fixed with r4469. I'll probably also remove the methods pointIns

Re: [mkgmap-dev] Performance with --bounds option

g von Ticker Berkin Gesendet: Mittwoch, 18. März 2020 18:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Performance with --bounds option Have done: http://files.mkgmap.org.uk/download/462/74220001.osm.pbf Ticker On Wed, 2020-03-18 at 16:26 +, Gerd Petermann wrote: > Hi Ticker,

Re: [mkgmap-dev] Performance with --bounds option

k/ > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 18. März 2020 11:56 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Performance with --bounds option > > Hi Gerd > > It's > > 74220001: 2674688,

Re: [mkgmap-dev] Performance with --bounds option

aries > > Gerd > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 18. März 2020 11:43 > An: mkgmap development > Betreff: [mkgmap-dev] Performance with --bounds option > > Hi Gerd > > With the current version I have a t

Re: [mkgmap-dev] Performance with --bounds option

___ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 18. März 2020 11:43 > An: mkgmap development > Betreff: [mkgmap-dev] Performance with --bounds option > > Hi Gerd > > With the current version I have a tile that takes 3.5 hou

Re: [mkgmap-dev] Performance with --bounds option

Hi Ticker, please tell me the tile boundaries Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Mittwoch, 18. März 2020 11:43 An: mkgmap development Betreff: [mkgmap-dev] Performance with --bounds option Hi Gerd With the current version I

[mkgmap-dev] Performance with --bounds option

Hi Gerd With the current version I have a tile that takes 3.5 hours to build. With an old version (r4295) it took about 3 minutes. Without --bounds it takes 1 minute 15 secs. Relevant options are: --bounds=bounds.zip --location-autofill=is_in,nearest >From the mkgmap.log files: INFO: uk.me.par

Re: [mkgmap-dev] Performance hints for Java JRE 9 + 10

Hi, i have comparable performance to former Java 8 and considerable lower memory consumption, when i use the OpenJDK 10 with the Eclipse OpenJ9 VM from AdoptOpenJDK! It is not officially released jet, but i use it with great success. If you want to try, you'll have to use the nightly builds from

Re: [mkgmap-dev] Performance hints for Java JRE 9 + 10

h to 10 or higher. Gerd Von: mkgmap-dev im Auftrag von Felix Hartmann Gesendet: Mittwoch, 16. Mai 2018 16:05:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Performance hints for Java JRE 9 + 10 Hi Gerd, What about if you compile mkgmap

Re: [mkgmap-dev] Performance hints for Java JRE 9 + 10

Hi Gerd, What about if you compile mkgmap with java 9 or higher - and run it on Java 8 - this also applies or not? Or asked differently - is this dependant on the compilation system or on the executing system? Felix On 16 May 2018 at 15:53, Gerd Petermann wrote: > Hi all, > > it seems that the

[mkgmap-dev] Performance hints for Java JRE 9 + 10

Hi all, it seems that the new Garbage Collector (G1GC) that was introduced with Java JRE 9 causes longer run times for splitter and mkgmap. I've played with some options and found that the use of -XX:+AggressiveHeap seems to be a good idea when you use these newer JREs. Without this option the

Re: [mkgmap-dev] Performance with zipped hgt files

results for your work loads. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Dienstag, 9. Januar 2018 00:04:07 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with zipped hgt files Hi Gerd, I can confirm, that mkgmap

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, I can confirm, that mkgmap has no memory problems with DEM for big tiles. I can compile map without limiting tile sizes. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/lis

Re: [mkgmap-dev] Performance with zipped hgt files

w > 16MB. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Montag, 8. Januar 2018 21:04:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with zipped hgt files Hi Gerd, I decided for 11.25 (=360/32) because of me

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, I decided for 11.25 (=360/32) because of memory limits in early BuildDemFile. Maybe this is not a problem for mkgmap? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listi

Re: [mkgmap-dev] Performance with zipped hgt files

endet: Montag, 8. Januar 2018 18:43:33 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with zipped hgt files Hi Gerd, > I don't yet see a need to change splitter like that but I can do that > as well. I would use this option too. Whenever I split data for Euro

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, basically this describes my idea, just less quick&dirty ;-) I will give it a try next weekend. Of course for every map, you need a individual temp-DEM. So I don't seen any issues with poly-cutted-tiles. Henning ___ mkgmap-dev mailing list mkgma

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, I don't yet see a need to change splitter like that but I can do that as well. I would use this option too. Whenever I split data for Europe, I get a tile which includes Azores and south shore of Island. I split it manually then. For maps with DEM I use an awk script, which proces

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, > I did not try it but mkgmap should support 76x76 tiles, but I see no > need to use that with mkgmap, at least not with unzipped hgt files. Yes, but since I already have created small version, I can save several minutes of reading HGT files form drive, when creating a big overview map

Re: [mkgmap-dev] Performance with zipped hgt files

p dir. Gerd Von: mkgmap-dev im Auftrag von Frank Stinner Gesendet: Montag, 8. Januar 2018 15:30:08 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with zipped hgt files Hi Gerd, at last you need the data uncompressed in a buffer,

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, at last you need the data uncompressed in a buffer, right? That's why i see no difference between using compressed or uncompressed hgt files. Compressed files need a little bit more time for uncompressing, but after that the data need the same size in memory. That's why i see no vantag

Re: [mkgmap-dev] Performance with zipped hgt files

rag von Henning Scholland Gesendet: Montag, 8. Januar 2018 14:16:31 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with zipped hgt files Hi Gerd, I was thinking of writing the 'final' DEM not only in img-container but also in a temp-file. This temp file can be used fo

Re: [mkgmap-dev] Performance with zipped hgt files

so in the end you might need the > data twice. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Henning Scholland > Gesendet: Montag, 8. Januar 2018 12:52:05 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Performance with zipp

Re: [mkgmap-dev] Performance with zipped hgt files

you might need the data twice. Gerd Von: mkgmap-dev im Auftrag von Henning Scholland Gesendet: Montag, 8. Januar 2018 12:52:05 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with zipped hgt files Hi Gerd, how about using a

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, how about using a compressed temp-format for DEM information, which is more suitable for DEM-calculation? Or even store DEM-information in temp folder /DEM and just reuse them next time if possible. I think (at least for me) they don't change that often. So this will have a high impact and

Re: [mkgmap-dev] Performance with zipped hgt files

: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with zipped hgt files Hi Gerd, > 2) reduce run time be storing more data in buffers This is what I would chose. I think java x64 can use swap to increase heap size. And RAM memory is a relatively cheap upgrade. > I

Re: [mkgmap-dev] Performance with zipped hgt files

Hi Gerd, > 2) reduce run time be storing more data in buffers This is what I would chose. I think java x64 can use swap to increase heap size. And RAM memory is a relatively cheap upgrade. > I think NTFS compressed folder is a good compromise I did it long time ago. Whole set of SRTM3 is abo

[mkgmap-dev] Performance with zipped hgt files

Hi all, I see no way to improve the handling of zipped files much more. We have two conflicting optimization goals here: 1) reduce heap memory by storing less data in buffers (risking additional rather slow unzip actions) 2) reduce run time be storing more data in buffers (risking OutOfMemoryE

Re: [mkgmap-dev] Performance with large files

Gesendet: Mittwoch, 22. März 2017 21:07:37 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with large files Hi Gerd, it was one single tile which took more than 2 hours: 4313.osm.pbf took ~7242 sec It covers a large area, but not as big as the tile mentioned previously

Re: [mkgmap-dev] Performance with large files

kgmap Betreff: Re: [mkgmap-dev] Performance with large files Hi Bernhard, okay, that is a good guess. How do you combine the files? Do you download single country extracts from geofabrik and merge them with osmconvert? Or maybe another tool? The splitter log file may show some hints why the area is so

Re: [mkgmap-dev] Performance with large files

-trim. Gerd Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Dienstag, 21. März 2017 18:56:51 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with large files Hi Gerd, mkgmap is running now, I'll likely report tom

Re: [mkgmap-dev] Performance with large files

rmann: Hi Bernhard, other tests did not show new results. Any idea why you got so different numbers? Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Montag, 20. März 2017 07:40:00 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Perfor

Re: [mkgmap-dev] Performance with large files

. I just noticed that I did not enable assertions (-ea) so I now try a variant with a max-nodes=140 and -ea. Gerd Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Sonntag, 19. März 2017 19:46:32 An: mkgmap-dev@lists.mkgmap.org.uk Bet

Re: [mkgmap-dev] Performance with large files

I did not enable assertions (-ea) so I now try a variant with a max-nodes=140 and -ea. Gerd Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Sonntag, 19. März 2017 19:46:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [m

Re: [mkgmap-dev] Performance with large files

Gerd Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Sonntag, 19. März 2017 19:46:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Performance with large files Eventually I updated Java and tried the latest version of mkgmap 3847 (and also splitter 580). The extracts

Re: [mkgmap-dev] Performance with large files

Eventually I updated Java and tried the latest version of mkgmap 3847 (and also splitter 580). The extracts were retrieved from Geofabrik on Saturday 18. Germany: 2.93 GB plus additional countries: 5.62 GB (incl. Germany) which were combined to a 7.57 GB o5m file. splitter: Germany 14 minutes -

Re: [mkgmap-dev] Performance with large files

Auftrag von Gerd Petermann Gesendet: Sonntag, 19. März 2017 12:16:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Performance with large files Hi Bernhard, the calculation time per tile can depend on map elements, e.g. complex multpolygons may result in additional seconds. Besides that

Re: [mkgmap-dev] Performance with large files

Von: mkgmap-dev im Auftrag von Bernhard Hiller Gesendet: Sonntag, 19. März 2017 12:06:31 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Performance with large files How is mkgmap expected to behave when input files grow in size? Is a linear inrease in calculation

[mkgmap-dev] Performance with large files

How is mkgmap expected to behave when input files grow in size? Is a linear inrease in calculation time - i.e. O(n) - expected, or an increase beyond linearity? E.g. when I create a map with routable lines for bicycle, mkgmap takes some 30 minutes for Germany alone (3 GB pbf file resulting in 85

Re: [mkgmap-dev] Performance

Steve Ratcliffe wrote: When I get the time (which should be next week) I will re-write splitter to remove the limitation of 4 tiles per relation or way. And try to improve the size estimate too. Sounds great - look forward to it. I'll hold off with my queries about the style rules until th

Re: [mkgmap-dev] Performance

Steve Ratcliffe wrote: When I get the time (which should be next week) I will re-write splitter to remove the limitation of 4 tiles per relation or way. And try to improve the size estimate too. Much appreciated! :D ___ mkgmap-dev mailing list mkgmap

Re: [mkgmap-dev] Performance

Hi On Sun, Jun 28, 2009 at 08:52:03AM +0100, Richard Fairhurst wrote: > I was going by the docs on http://www.mkgmap.org.uk/page/tile-splitter > which suggest "The default [for max-nodes] is fairly conservative, I > think you could increase it quite a lot". Clearly not by 50% though. ;) Yes t

Re: [mkgmap-dev] Performance

Hi Richard > I'm currently trying to create a map from a GB planet extract, and > performance seems much slower than I remember. I've split the extract > into six parts with splitter.jar (I'm using some big route relations so > can't split it any further). The first .osm (36Mb) has been chun

Re: [mkgmap-dev] Performance

What that does mean is that I'll need to write a relation splitter, as the whole reason I'm doing this is to show cycle routes, and two of them have bitten the dust (too many tiles) even on the default split. I presume there isn't one already out there? Why is it a problem for relations to

Re: [mkgmap-dev] Performance

Apollinaris Schoell wrote: there is nearly no chance that a gzipped 36Mb osm file file fit into a .img tile. you will need to split it into smaller tiles. Thanks. I was going by the docs on http://www.mkgmap.org.uk/page/tile-splitter which suggest "The default [for max-nodes] is fairly cons

Re: [mkgmap-dev] Performance

there is nearly no chance that a gzipped 36Mb osm file file fit into a .img tile. you will need to split it into smaller tiles. On 27 Jun 2009, at 15:59 , Richard Fairhurst wrote: Richard Fairhurst wrote: The first .osm (36Mb) has been chuntering away for an hour and a half and the .img has

Re: [mkgmap-dev] Performance

Richard Fairhurst wrote: The first .osm (36Mb) has been chuntering away for an hour and a half and the .img hasn't been produced yet - is this normal? Just killed it after 12 hours and still no .img. :( cheers Richard ___ mkgmap-dev mailing list mk

[mkgmap-dev] Performance

Hi all, I've not used mkgmap for a good while and am really impressed with all the features that've been added in recent months. I'm currently trying to create a map from a GB planet extract, and performance seems much slower than I remember. I've split the extract into six parts with spl