[mkgmap-dev] Small problem with global index

Mon Nov 22 10:54:51 GMT 2021

Hi Ticker,

I test with MapSource and the POI search also offers fields for region and country. On devices the search for region was probably dropped.
Basecamp search is not very useful when you want to verify the index. The result is often a mixture of index results and nearby search.
> Your workflow makes sense when all upper case, but might not lead us to the best solution for mixed case.
Why not? I see also reasonable results for such a gmapsupp (but I didn't try it on the device so far).
BTW: A good reason to use --lower-case in Germany are road names like Hauptstraße which is displayed as Hauptstrasse without that option.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 22. November 2021 11:43
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Small problem with global index

Hi Gerd

The first stages of investigation should avoid other complexities that
might be introduced by --lower-case (and --unicode). In this
environment there should be no difference between SECONDARY and
TERTIARY so the question is reduced to .equals() vs .compare() and
other flag settings / Mdr sections.

Your tests seem be examining the behaviour of "Find" > "POI" limited by
region. My devices don't seem to have the ability do this and I don't
see it in BaseCamp / MapSource either. "Find" > "Address" /
"Intersection" are the only places where I can limit by Country and
City.

Your workflow makes sense when all upper case, but might not lead us to
the best solution for mixed case.

Ticker

On Mon, 2021-11-22 at 05:24 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> sorry, seems I attached the wrong patch for the default style. The
> problem is neither about upper/lower case nor about special
> characters like highway shield codes.
> It might be a problem in Garmin software, but it might as well show a
> problem with wrongly calculated repeat flags or maybe other flags.
> My thinking is that we should try to learn from the gmapsupp that is
> produced by MapSource, so my current workflow is this:
> - Compile the tile(s) and the gmapi and the gmapsupp.
> - Start MapSource, try if search works (it still doesn't for my
> example).
> - Generate a gmapsupp with Mapsource.
> - Extract the tiles from the gmapsupp (or copy those produced by
> mkgmap)
> - execute MdrDisplay and MdrCheck on the two different gmapsupp.img
> - compare all significant difference (different flags, existence of
> different sections etc)
>
> My latests results are that both MdrCheck and mkgmap should use
> TERTIARY strength were SECONDARY is used now.
> Unpatched MdrCheck reports several errors reg. repeat flags on Garmin
> maps which disapear when I use TERTIARY (the default).
> There also seems to be a problem with the positions of some bit
> flags. It seems that some flags should be shifted depending on the
> size of sections, but I don't know yet the details.
>
> Gerd

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