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

Sat Oct 30 10:16:53 BST 2021

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdr5-simplify.patch
Type: application/octet-stream
Size: 2681 bytes
Desc: mdr5-simplify.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20211030/d8ead67b/attachment-0001.obj>