
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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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