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

Tue Jul 28 21:07:46 BST 2020

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-bounces at lists.mkgmap.org.uk> im Auftrag von Franco Bez <franco.bez at web.de>
Gesendet: Dienstag, 28. Juli 2020 21:52
An: mkgmap-dev at 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-bounces at lists.mkgmap.org.uk> im Auftrag von franco_bez <franco.bez at web.de>
> Gesendet: Dienstag, 2. Juni 2020 18:32
> An: mkgmap-dev at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev