Hi Franco, I did my test with an extract of all route=bicycle or route=mtb relations in Europe. I used osmfilter for that with a statement similar to the one that is used to extract the boundaries: https://wiki.openstreetmap.org/wiki/Mkgmap/help/options#Filter_Boundary_Data For the bicycle layer this was some near 300 MB in pbf format and I used splitter with maxnodes=3000000 .
I also wondered if there is another way to do this by merging the tiles produced by splitter, but that would probably create memory problems because mkgmap would read a huge tile first before it can calculate the few objects that are used by the style. I'll try again to find a better solution when I am back from my next cycle tour which starts soon. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Franco Bez <franco....@web.de> Gesendet: Dienstag, 28. Juli 2020 21:52 An: mkgmap-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 not be improved that way. With the other overlays I'm a little lost on how to get bigger tiles. Usually I split the data once and then build all the map flavours from the same tiles. Of course the map containing all the roads and routing information needs to have smaller tiles than the overlays. Most likely I will have to split the data with different settings for each map flavour. Or is there any way of joining several osm-tiles into one garmin-tile when creating the gmapsupp image? Ciao, Franco Am 19.07.20 um 08:39 schrieb Gerd Petermann: > Hi all, > > I still try to understand why the existence of a (transparent) overlay map > can slow down the search for POI. It seems the more tiles we have in the > overlay > the longer the delay. So, it looks like the Oregon performs a sequential > search over all tiles in the overlay map. It seems to ignore a global index > in that map, > but, as Franco found out, it might stop earlier / work faster when the > overlay map contains a few POI. > > My 1st assumption was that the transparent flag makes it difficult for the > device to find out if the tile contains any data that may be relevant as it > doesn't contain the 0x4b polygon. I tried with a semi-transparent map (0x4b > polygon written and transparent flag set). Didn't improve anything. > So, another idea is that the POI with address info change the content of the > LBL file header because e.g. the list of countries is filled. > Maybe the device checks this. > Looking at this now... > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > franco_bez <franco....@web.de> > 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 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 > <http://files.mkgmap.org.uk/download/477/dach_boundary_gmapsupp.img> > Ciao, > Franco > > > > -- > Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > _______________________________________________ > 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
