[mkgmap-dev] [mkgmap-svn] Commit r4810: revert changes from r4809 for now, they caused more trouble

Sat Oct 30 17:50:52 BST 2021

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 at lists.mkgmap.org.uk> im Auftrag von
> Gerd Petermann <gpetermann_muenchen at 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 at lists.mkgmap.org.uk> im Auftrag von
> Ticker Berkin <rwb-mkgmap at 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 at lists.mkgmap.org.uk> im Auftrag
> > von Gerd Petermann <gpetermann_muenchen at 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 at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at 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 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
> _______________________________________________
> 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