Hi Gerd
Patch attached that defaults Format6Encoder transliterator to UPPER.
mkgmap unconditionally calls to set required mode but test environment
doesn't.
Ticker
On Fri, 2021-11-26 at 18:40 +, Gerd Petermann wrote:
> Hi Ticker,
>
> result looks ok, but unit test CodeFunctionsTest fails.
Hi Ticker,
result looks ok, but unit test CodeFunctionsTest fails. Maybe it was intended
that codepage 0 ignores the --lower-case option?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Freitag, 26. November 2021 18:49
An: mkgmap
Hi Ticker,
sorry, meant r4718 instead of 4717 before.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Freitag, 26. November 2021 18:06
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Small problem with global index
Hi Ticker,
Hi Gerd
I was looking at encoders and noticed obvious mistake in Format6Decoder
relating to lower-case, plus parts that can be simplified to be general
and consistent with Format6Encoder.
Format6Encoder can handle a bunch of other characters (the remains of
the 'ascii' printables) + lower-case -
Hi Ticker,
I tried this: use your command to build a gmapi and gmapsupp, but replace r4810
by a binary compiled from mkgmap r4717 + mdrUnicode_v9b.patch
(I still see no difference in the output compared to unpatched r4717)
I then use MapSource to create another gmapsupp.
I run MdrDisplay and
Hi Gerd
I was sort of thinking the opposite. PlaceFile using some method (eg
what it does) to dedupe city/region/country and this is extended to the
POI/MDRBuilder logic, such that combinations of these 3 have unique
sets of index values regardless of case.
Then the relevant MdrX sections should
Hi Ticker,
reg. --lower-case and city/region/country names with different capitalization:
I think it would be good to keep the different capitalization within a single
tile, so yes, the .toUpperCase() in PlacesFile is probably not a good idea.
Results seem better when this is not done.
When the
