[mkgmap-dev] Small problem with global index

Mon Nov 22 05:24:16 GMT 2021

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

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

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

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default-mini.patch
Type: application/octet-stream
Size: 1554 bytes
Desc: default-mini.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20211122/c889c6eb/attachment.obj>