[mkgmap-dev] Small problem with global index

Sun Nov 21 18:46:14 GMT 2021

Hi Gerd

Although non-sorting (eg shields) characters are a handy way of
examining behaviour, I don't think they should influence any changes in
the handling of Country/Region/City. We shouldn't attempt to make your
example with the 3 variants of DREG region work.

So, the problem becomes what to do with differently cased Country,
Region & City when --lower-case. I found that trying to respect the
case had problems both in implementation and use. I think we have to
build a case-insensitive index if possible.

Country, Region & City come into MDRFile with map relative index. For
Country & Region, I think this is unique regardless of case. This isn't
always true of City, so this should be tackled. POIs then need to be
fixed to ref the chosen City.

Then need to experiment with changing .equal to collator.compare and
changing strengths from TERTIARY to SECONDARY.

It is possible that MapInstall, having access to all the case variants
via the LBL section, might rebuild a case-sensitive index. 

Was hoping to get mdrUnicode_v9p.patch out of the way before this.

Ticker

On Sat, 2021-11-20 at 17:27 +0000, Ticker Berkin wrote:
> Hi Gerd
> 
> I can't look at this in detail at the moment but:
> 
> Lower case and indexing behaviour is affected by the tile processing
> stages deduping using upper case on country/region/city when loading
> MDR data (mainly from mkgmap:country/region/city). I seem to remember
> that explicit city POI behave differently and might be combined into
> the country/region/city/data. Some of these get an index which
> confuses
> matters more. Also isIn processing can introduce names forced to
> upper-
> case.
> 
> I came to the conclusion that indexing would have to be done ignoring
> case, but my simple attempts to do this failed. Before trying again,
> we
> need to work on EQUAL/collator.compare in various places without the
> complications of --lower-case and --unicode
> 
> Then make sure --unicode indexing works. Some Mdr sections are
> suppressed when Unicode.
> 
> Only then tackle --lower-case and strange find behaviour.
> 
> Ticker
>  
> On Sat, 2021-11-20 at 16:49 +0000, Gerd Petermann wrote:
> > Hi Devs,
> > 
> > did not find a solution for this yet but I noticed that MapSource
> > creates a different mdr for this small map.
> > If I got that right the order in Mdr11 also depends on the
> > city/region and in Mdr19 the "repeated name" flag also considers
> > this.
> > 
> > I'll try to modify MdrCheck to find out if I am right here.
> > 
> > My current thinking is that we have to identify (in this order)
> > 1.  unique countries -> each gets a number
> > 2. unique regions -> name and number of country, each gets a number
> > 3. unique cities -> name and number of region (we probably need an
> > empy region for each country), each gets a number
> > 4. POI -> name and city number
> > 
> > No idea yet where Garmin considers upper/lower case differences or
> > special "characters" like the highway shield codes.
> > 
> > Gerd
> > 
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Gerd Petermann <GPetermann_muenchen at hotmail.com>
> > Gesendet: Samstag, 20. November 2021 14:59
> > An: mkgmap-dev at lists.mkgmap.org.uk
> > Betreff: [mkgmap-dev] Small problem with global index
> > 
> > Hi Ticker,
> > 
> > while experimenting with the index and unicode I found a rather
> > simple case that doesn't work as expected.
> > I've attached a small example file and a patch for the default
> > style.
> > A map produced with these options and the patched style
> > --style-file=d:\mkgmap\resources\styles\default   --lower-case --
> > preserve-element-order --code-page=1252 --gmapi --index --
> > housenumbers --bounds=bounds.zip bad-search.osm
> > produces a map that shows an error in the POI search.
> > I search for name=abc123x in region Bayern and get the correct
> > result
> > list of three different restaurants named abc123x.
> > I search for name=abc123x in region reg1 and get the correct result
> > list of three different restaurants named abc123x.
> > Now I also fill the search field city with Burgpreppach.
> > with name=abc123x in city Burgpreppach and region Bayern the result
> > is still correct.
> > with name=abc123x in city Burgpreppach and region reg1 the result
> > is
> > not correct, it also lists the objects in region Bayern
> > 
> > So far I found no correction for this.  It also doesn't seem to
> > depend on the lower-case option. Any idea?
> > 
> > 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