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