[mkgmap-dev] Small problem with global index

Mon Nov 22 11:36:21 GMT 2021

Hi Gerd

I'd forgotten about MapSource's better POI searching.

If a mixed case map has differently cased variants of the same name, it
shouldn't be up to the user to know which variant of Country, Region,
City or Street to choose to find something, hence the interface should
be case-insensitive. These case variants come from inconsistent OSM
data and, at the moment, mkgmap logic.

It might be possible for mkgmap to make a case-insensitive index by
changing all TERTIARY to SECONDARY etc.

However, once this is loaded into BaseCamp and MapInstall regenerates
the indexes for a gmapsupp, it sees all the name variants and might
include them in the new index structures. It lacks information to do
this properly. The resultant index might have the problems described
earlier about the user having to guess which Country, Region ... works.

Ticker

On Mon, 2021-11-22 at 10:54 +0000, Gerd Petermann wrote:
> 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev