Hi Gerd I haven't worked out logic of your patch yet. Concerning your previous post on bounds - Yes. Sorry, I didn't notice that you were using existing tile .img files. Going back to the "find" behaviour for, eg, "de Wijk" vs. "De Wikj", I think it is important that, in the address search, the user doesn't need to know the case of the Country, Region and City to get the correct set of streets. I was hoping my changes of consistent use of collator strength SECONDARY would have this effect. I'll spend some time trying to work out why it doesn't, looking more carefully at what MDR25 is doing. If I can't get this to work then then I'll change it to be consistent TERTIARY in all the relevant places. Ticker On Sat, 2021-10-30 at 09:16 +0000, Gerd Petermann wrote:
Hi Ticker,
attached is a patch that simplifies calcMdr20SortPos(), no change in output intended. Does it help?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 29. Oktober 2021 14:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4810: revert changes from r4809 for now, they caused more trouble
Hi Ticker,
the bounds are not needed when existing *.img input is processed. I didn't try to compile the tiles from *.osm, my understanding of the patches was that they have no influence on the map tiles, only on the mdr file (as long as --latin1 is used).
I can upload the three img files if you don't have them.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 29. Oktober 2021 13:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4810: revert changes from r4809 for now, they caused more trouble
Hi Gerd
The behaviour for identically named but different cities shouldn't have changed - the main mdr structures deduped them based on name, region & country.
I have changed the behaviour around what 'identically named' means - country and region logic had a mix of case-sensitivity and I've made them consistently insensitive. Cities were generally case-sensitive (I'd have to check carefully if this was totally consistent) and are now consistently insensitive.
In your test you don't specify bounds, so region may not set.
It is possible that, where there were distinct identical cities, streets in all but one were not findable and no one noticed. I need to study more of the mdr logic around how streets are tied to cities to understand this. Any solution is complicated because the same city could be split across tiles so the cityIndex is not adequate.
I could just restore case-sensitivity to cities to give the old behaviour, but this may be avoiding the real issue. It seems wrong that device/basecamp/mapsource should present multiple "identical" cities and the correct one needs to be selected to find its streets.
Ticker
On Fri, 2021-10-29 at 08:35 +0000, Gerd Petermann wrote:
Hi Ticker,
patch v5 corrupts address search :( I tried the following command with the data from Arndt: (Arndt_NRWplus_mkgmapstyle.zip) java -Xmx5G -jar dist\mkgmap.jar --output-dir=e:/ld --max-jobs -- latin1 --gmapi --index 60050169.img 60050170.img 60050188.img
The three tiles contain data for cities "de Wijk" or "De Wijk" (two different cities and different spelling of the same city)
I test with Basecamp address search.
With the unpatched version I can find the street Cockserve in city De Wijk (OK), but not with the patched version. Basecamp shows the city name "De Wijk" when I seach for the road only, but obviously the index doesn't work. Same when I search for street Cockserve in city de Wijk
In MapSource the results are similar, but it doesn't suggest "De Wijk" as city name, only "de Wijk".
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 29. Oktober 2021 09:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4810: revert changes from r4809 for now, they caused more trouble
Hi Ticker,
OK, patch looks more consistent then v2 where I wondered about the mix of String.equals() and collator.compare(). I have to run a few tests to understand the meaning of the change.
Any chance to create unit tests for this? I got the impression that the indexes work quite well in the past, at least for latin1.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 28. Oktober 2021 13:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4810: revert changes from r4809 for now, they caused more trouble
Hi Gerd
After considering all places where the createSortKey strength must be set I've decided it isn't a good approach:
1/ It needs changes in NET and LBL as well as MDR. 2/ Because case-differences are not sorted, an apparently sorted and unique list of city/region/country could be out of order if there are case differences in the initial letters of duplicates. This also makes mdrCheck comparisons difficult
This would have been mdrUnicode_v4.patch
Attached patch doesn't change the Key/Sort behaviour but follows the sort with collator.compare where necessary instead of key.compareTo() or .equals()
Ticker
_______________________________________________ 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 _______________________________________________ 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