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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Samstag, 20. November 2021 14:59 An: mkgmap-dev@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev