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

[Gerd Petermann]

Hi Ticker,

OK to fix de-dup where it's wrong. So far I found no problem with the different 
spelling of "De Wijk".
I don't fully understand the discrepancies in the existing code, but the 
patched code also looks wrong to me with the mixed usage of strengths and 
String.equals() and collator.compare() or key.compareTo()

If I got that right the changes in mdr5 and mdr7 are just refactoring and OK.
Mdr25 could better use Mdr5Record.isSameByName() (although the method name is a 
bit confusing)
Mdr29 should probably use strength TERTIARY for the collator instead of 
SECONDARY, or there should be a comment why a different strength is needed.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Donnerstag, 4. November 2021 17:17
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

Although the Sort change fixes the Unicode problem reported by Carlos
it demonstrated that the different methods of dedupe between Mdr5 and
Mdr25 can lead to the same error with certain patterns of city names
and so I really think this should be fixed at the same time.

If not, it is a problem waiting to happen and the use of, say, code-
page=936 as in Carlos's second problem, could trigger it.

Mdr25 could be reverted to have the weird logic, but I think it was a
bug that would never happen and the code would always confuse.

The obsolete sort/Mdr20Posn/Index can be fixed as a trivial change
soon.

What to do with city case-variants and their street attachments is much
more complicated and needs addressing in the tile-generation phase more
than the MDR generation. This should definitely wait.

Ticker

On Thu, 2021-11-04 at 14:10 +, Gerd Petermann wrote:
> Hi Ticker,
>
> My understanding of mdrUnicode_v8.patch is again that only the
> changes in class Sort are relevant for the unicode error reported by
> Carlos.
> Why should we do more right now?
>
> In a second step we can try to simplify the code or fix other issues
> that came up last weeks like weird code in Mdr25 or the obsolete sort
> for mdr20.
>
> Gerd
>
>
>
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 4. November 2021 14:34
> 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
>
> This was a bit arbitrary and maybe I should have reverted it to
> .equals().
>
> Generally Regions and Countries don't cause a problem because they
> (almost always) originate from --bounds and go through
> PlacesFile.createRegion() / createCountry() which stops any case
> difference within a tile.
>
> Ticker
>
> On Thu, 2021-11-04 at 13:15 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > why collator.setStrength(Collator.SECONDARY); in Mdr29?
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 4. November 2021 12:40
> > 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
> >
> > Yes, patch r4809 caused the crash with Arndt's data (--lower-case
> > and
> > differently cased city names).
> >
> > Ticker
> >
> > On Thu, 2021-11-04 at 11:11 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > thanks, will have a closer later. Just to make sure:
> > > My understanding is that the assertion with Arndts data was
> > > caused
> > > by
> > > your patch (r4809) and everything worked fine with r4808 / r4810.
> > >
> > > Gerd
> > >
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Donnerstag, 4. November 2021 11:55
> > > 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
> > >
> > > Here is a minimal patch to stop the 2 assertion crashes:
> > > 1/ unspecified sort for some blocks of Unicode chararacters.
> > > 2/ inconsistent MDR20 city positions that could result from city
> > > names
> > >with different case or use of non-unicode multi-byte codepage
> > >
> > > For 2/ with option --lower-case, the behaviour of how and which
> > > cities
> > > with capitalisation differences are shown in the find list, and
> > > which
> > > streets are attached to them is:
> > > 1/ device/BaseCamp/MapSource dependant.
> > > 2/ depends on how the streets are spread over tiles where there
> > > is
> > >possible name conflict.
> > > 3/ Affected by the presence of city POI on a tile.
> > >
> > > Ticker
> > >
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > 

Re: [mkgmap-dev] Failure splitting USA

[Carlos Dávila]

I have realized the problem occurs since I updated my old version of 
splitter to r642. Currently splitting with r641, it has already passed 
the crashing point.


https://files.mkgmap.org.uk/download/525/densities-out.txt

El 4/11/21 a las 16:52, Gerd Petermann escribió:

Hi Carlos,

please try the branch version 
https://www.mkgmap.org.uk/download/splitter-solve-parallel-r641.zip
I never found the time to complete the work on this.
Would also be good to have the densities-out.txt file.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 4. November 2021 16:48
An: Development list for mkgmap
Betreff: [mkgmap-dev] Failure splitting USA

Since a couple of weeks or so I'm unable to split USA. I have tried with
my own extract and also with the one from Geofabrik
.
Splitter crashes trying to find a nice split. I have tried different
--max-nodes values, from 40 to 180, with no success. Version
used is 642.

Exact map coverage read from input file(s) is
(15.920970439910889,-180.0) to (72.98844337463379,180.0)
Rounded map coverage is (15.908203125,-180.0) to (72.9931640625,180.0)
Splitting nodes into areas containing a maximum of 1,600,000 nodes each...
Highest node count in a single grid element is 423,372
Solving partition (15.908203125,-180.0) to (71.806640625,-9.5361328125)
with 1,036,376,610 nodes
Trying to find nice split for (15.908203125,-180.0) to
(71.806640625,-9.5361328125) with 1,036,376,610 nodes
searching for split with min-nodes 8, learned 0 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 13540 good partial
solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 18542 good partial
solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 21915 good partial
solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 26044 good partial
solutions
Elapsed time: 6m 0s   Memory: Current 2996MB (406MB used, 2590MB free)
Max 27648MB
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 38395 good partial
solutions
No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 83498 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 83595 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 84812 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 84886 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 84941 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 85011 good partial solutions
Still no good solution found, trying alternative algorithm
searching for split with min-nodes 8, learned 85011 good partial
solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 85012 good partial
solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 85020 good partial
solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 85020 good partial
solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 85494 good partial
solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 87541 good partial
solutions
No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 88954 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 88989 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 89006 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 90462 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 93165 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 94259 good partial solutions
Warning: No solution found for partition (15.908203125,-180.0) to
(71.806640625,-9.5361328125) with 1,036,376,610 nodes

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

[Ticker Berkin]

Hi Gerd

Although the Sort change fixes the Unicode problem reported by Carlos
it demonstrated that the different methods of dedupe between Mdr5 and
Mdr25 can lead to the same error with certain patterns of city names
and so I really think this should be fixed at the same time.

If not, it is a problem waiting to happen and the use of, say, code-
page=936 as in Carlos's second problem, could trigger it.

Mdr25 could be reverted to have the weird logic, but I think it was a
bug that would never happen and the code would always confuse.

The obsolete sort/Mdr20Posn/Index can be fixed as a trivial change
soon.

What to do with city case-variants and their street attachments is much
more complicated and needs addressing in the tile-generation phase more
than the MDR generation. This should definitely wait.

Ticker

On Thu, 2021-11-04 at 14:10 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> My understanding of mdrUnicode_v8.patch is again that only the
> changes in class Sort are relevant for the unicode error reported by
> Carlos.
> Why should we do more right now?
> 
> In a second step we can try to simplify the code or fix other issues
> that came up last weeks like weird code in Mdr25 or the obsolete sort
> for mdr20.
> 
> Gerd
> 
> 
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 4. November 2021 14:34
> 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
> 
> This was a bit arbitrary and maybe I should have reverted it to
> .equals().
> 
> Generally Regions and Countries don't cause a problem because they
> (almost always) originate from --bounds and go through
> PlacesFile.createRegion() / createCountry() which stops any case
> difference within a tile.
> 
> Ticker
> 
> On Thu, 2021-11-04 at 13:15 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > why collator.setStrength(Collator.SECONDARY); in Mdr29?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 4. November 2021 12:40
> > 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
> > 
> > Yes, patch r4809 caused the crash with Arndt's data (--lower-case
> > and
> > differently cased city names).
> > 
> > Ticker
> > 
> > On Thu, 2021-11-04 at 11:11 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > thanks, will have a closer later. Just to make sure:
> > > My understanding is that the assertion with Arndts data was
> > > caused
> > > by
> > > your patch (r4809) and everything worked fine with r4808 / r4810.
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Donnerstag, 4. November 2021 11:55
> > > 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
> > > 
> > > Here is a minimal patch to stop the 2 assertion crashes:
> > > 1/ unspecified sort for some blocks of Unicode chararacters.
> > > 2/ inconsistent MDR20 city positions that could result from city
> > > names
> > >    with different case or use of non-unicode multi-byte codepage
> > > 
> > > For 2/ with option --lower-case, the behaviour of how and which
> > > cities
> > > with capitalisation differences are shown in the find list, and
> > > which
> > > streets are attached to them is:
> > > 1/ device/BaseCamp/MapSource dependant.
> > > 2/ depends on how the streets are spread over tiles where there
> > > is
> > >    possible name conflict.
> > > 3/ Affected by the presence of city POI on a tile.
> > > 
> > > 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


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Failure splitting USA

[Gerd Petermann]

Hi Carlos,

please try the branch version 
https://www.mkgmap.org.uk/download/splitter-solve-parallel-r641.zip
I never found the time to complete the work on this.
Would also be good to have the densities-out.txt file.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Donnerstag, 4. November 2021 16:48
An: Development list for mkgmap
Betreff: [mkgmap-dev] Failure splitting USA

Since a couple of weeks or so I'm unable to split USA. I have tried with
my own extract and also with the one from Geofabrik
.
Splitter crashes trying to find a nice split. I have tried different
--max-nodes values, from 40 to 180, with no success. Version
used is 642.

Exact map coverage read from input file(s) is
(15.920970439910889,-180.0) to (72.98844337463379,180.0)
Rounded map coverage is (15.908203125,-180.0) to (72.9931640625,180.0)
Splitting nodes into areas containing a maximum of 1,600,000 nodes each...
Highest node count in a single grid element is 423,372
Solving partition (15.908203125,-180.0) to (71.806640625,-9.5361328125)
with 1,036,376,610 nodes
Trying to find nice split for (15.908203125,-180.0) to
(71.806640625,-9.5361328125) with 1,036,376,610 nodes
searching for split with min-nodes 8, learned 0 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 13540 good partial
solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 18542 good partial
solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 21915 good partial
solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 26044 good partial
solutions
Elapsed time: 6m 0s   Memory: Current 2996MB (406MB used, 2590MB free)
Max 27648MB
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 38395 good partial
solutions
No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 83498 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 83595 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 84812 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 84886 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 84941 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 85011 good partial solutions
Still no good solution found, trying alternative algorithm
searching for split with min-nodes 8, learned 85011 good partial
solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 85012 good partial
solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 85020 good partial
solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 85020 good partial
solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 85494 good partial
solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 87541 good partial
solutions
No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 88954 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 88989 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 89006 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 90462 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 93165 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 94259 good partial solutions
Warning: No solution found for partition (15.908203125,-180.0) to
(71.806640625,-9.5361328125) with 1,036,376,610 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split
 at
uk.me.parabola.splitter.solver.SplittableDensityArea.split(SplittableDensityArea.java:162)
 at
uk.me.parabola.splitter.solver.SplittableDensityArea.split(SplittableDensityArea.java:211)
 at

[mkgmap-dev] Failure splitting USA

[Carlos Dávila]

Since a couple of weeks or so I'm unable to split USA. I have tried with 
my own extract and also with the one from Geofabrik 
. 
Splitter crashes trying to find a nice split. I have tried different 
--max-nodes values, from 40 to 180, with no success. Version 
used is 642.


Exact map coverage read from input file(s) is 
(15.920970439910889,-180.0) to (72.98844337463379,180.0)

Rounded map coverage is (15.908203125,-180.0) to (72.9931640625,180.0)
Splitting nodes into areas containing a maximum of 1,600,000 nodes each...
Highest node count in a single grid element is 423,372
Solving partition (15.908203125,-180.0) to (71.806640625,-9.5361328125) 
with 1,036,376,610 nodes
Trying to find nice split for (15.908203125,-180.0) to 
(71.806640625,-9.5361328125) with 1,036,376,610 nodes

searching for split with min-nodes 8, learned 0 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 13540 good partial 
solutions

No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 18542 good partial 
solutions

No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 21915 good partial 
solutions

No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 26044 good partial 
solutions
Elapsed time: 6m 0s   Memory: Current 2996MB (406MB used, 2590MB free) 
Max 27648MB

No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 38395 good partial 
solutions

No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 83498 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 83595 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 84812 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 84886 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 84941 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 85011 good partial solutions
Still no good solution found, trying alternative algorithm
searching for split with min-nodes 8, learned 85011 good partial 
solutions

No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 85012 good partial 
solutions

No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 85020 good partial 
solutions

No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 85020 good partial 
solutions

No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 85494 good partial 
solutions

No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 87541 good partial 
solutions

No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 88954 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 88989 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 89006 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 90462 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 93165 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 94259 good partial solutions
Warning: No solution found for partition (15.908203125,-180.0) to 
(71.806640625,-9.5361328125) with 1,036,376,610 nodes

uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split
    at 
uk.me.parabola.splitter.solver.SplittableDensityArea.split(SplittableDensityArea.java:162)
    at 
uk.me.parabola.splitter.solver.SplittableDensityArea.split(SplittableDensityArea.java:211)
    at 
uk.me.parabola.splitter.solver.AreasCalculator.calcAreas(AreasCalculator.java:226)

    at uk.me.parabola.splitter.Main.split(Main.java:227)
    at uk.me.parabola.splitter.Main.start(Main.java:121)
    at uk.me.parabola.splitter.Main.main(Main.java:81)


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk

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

[Gerd Petermann]

Hi Ticker,

My understanding of mdrUnicode_v8.patch is again that only the changes in class 
Sort are relevant for the unicode error reported by Carlos.
Why should we do more right now?

In a second step we can try to simplify the code or fix other issues that came 
up last weeks like weird code in Mdr25 or the obsolete sort for mdr20.

Gerd





Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Donnerstag, 4. November 2021 14:34
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

This was a bit arbitrary and maybe I should have reverted it to
.equals().

Generally Regions and Countries don't cause a problem because they
(almost always) originate from --bounds and go through
PlacesFile.createRegion() / createCountry() which stops any case
difference within a tile.

Ticker

On Thu, 2021-11-04 at 13:15 +, Gerd Petermann wrote:
> Hi Ticker,
>
> why collator.setStrength(Collator.SECONDARY); in Mdr29?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 4. November 2021 12:40
> 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
>
> Yes, patch r4809 caused the crash with Arndt's data (--lower-case and
> differently cased city names).
>
> Ticker
>
> On Thu, 2021-11-04 at 11:11 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > thanks, will have a closer later. Just to make sure:
> > My understanding is that the assertion with Arndts data was caused
> > by
> > your patch (r4809) and everything worked fine with r4808 / r4810.
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 4. November 2021 11:55
> > 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
> >
> > Here is a minimal patch to stop the 2 assertion crashes:
> > 1/ unspecified sort for some blocks of Unicode chararacters.
> > 2/ inconsistent MDR20 city positions that could result from city
> > names
> >with different case or use of non-unicode multi-byte codepage
> >
> > For 2/ with option --lower-case, the behaviour of how and which
> > cities
> > with capitalisation differences are shown in the find list, and
> > which
> > streets are attached to them is:
> > 1/ device/BaseCamp/MapSource dependant.
> > 2/ depends on how the streets are spread over tiles where there is
> >possible name conflict.
> > 3/ Affected by the presence of city POI on a tile.
> >
> > 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

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

[Ticker Berkin]

Hi Gerd

This was a bit arbitrary and maybe I should have reverted it to
.equals().

Generally Regions and Countries don't cause a problem because they
(almost always) originate from --bounds and go through
PlacesFile.createRegion() / createCountry() which stops any case
difference within a tile.

Ticker

On Thu, 2021-11-04 at 13:15 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> why collator.setStrength(Collator.SECONDARY); in Mdr29?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 4. November 2021 12:40
> 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
> 
> Yes, patch r4809 caused the crash with Arndt's data (--lower-case and
> differently cased city names).
> 
> Ticker
> 
> On Thu, 2021-11-04 at 11:11 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > thanks, will have a closer later. Just to make sure:
> > My understanding is that the assertion with Arndts data was caused
> > by
> > your patch (r4809) and everything worked fine with r4808 / r4810.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 4. November 2021 11:55
> > 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
> > 
> > Here is a minimal patch to stop the 2 assertion crashes:
> > 1/ unspecified sort for some blocks of Unicode chararacters.
> > 2/ inconsistent MDR20 city positions that could result from city
> > names
> >    with different case or use of non-unicode multi-byte codepage
> > 
> > For 2/ with option --lower-case, the behaviour of how and which
> > cities
> > with capitalisation differences are shown in the find list, and
> > which
> > streets are attached to them is:
> > 1/ device/BaseCamp/MapSource dependant.
> > 2/ depends on how the streets are spread over tiles where there is
> >    possible name conflict.
> > 3/ Affected by the presence of city POI on a tile.
> > 
> > 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

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

[Gerd Petermann]

Hi Ticker,

why collator.setStrength(Collator.SECONDARY); in Mdr29?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Donnerstag, 4. November 2021 12:40
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

Yes, patch r4809 caused the crash with Arndt's data (--lower-case and
differently cased city names).

Ticker

On Thu, 2021-11-04 at 11:11 +, Gerd Petermann wrote:
> Hi Ticker,
>
> thanks, will have a closer later. Just to make sure:
> My understanding is that the assertion with Arndts data was caused by
> your patch (r4809) and everything worked fine with r4808 / r4810.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 4. November 2021 11:55
> 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
>
> Here is a minimal patch to stop the 2 assertion crashes:
> 1/ unspecified sort for some blocks of Unicode chararacters.
> 2/ inconsistent MDR20 city positions that could result from city
> names
>with different case or use of non-unicode multi-byte codepage
>
> For 2/ with option --lower-case, the behaviour of how and which
> cities
> with capitalisation differences are shown in the find list, and which
> streets are attached to them is:
> 1/ device/BaseCamp/MapSource dependant.
> 2/ depends on how the streets are spread over tiles where there is
>possible name conflict.
> 3/ Affected by the presence of city POI on a tile.
>
> 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

Re: [mkgmap-dev] Solarpark Inden will not be displayed with the correct polygon

[Manfred Haiduk]

  
  
Thank you Gerd and Bernd, problem solved !

Am 04.11.2021 um 13:03 schrieb Bernd
  Weigelt:


  For these cases i have these rules in my style

# barrier
# please don't delete the continue action, because they are needed to render
# landuse polygons with barrier tags


barrier~'.*(wall)'[0x10f02 resolution 24 continue]
barrier~'.*(fence)'   [0x10f03 resolution 24 continue]
barrier~'.*(block)'   [0x10f05 resolution 24 continue]
barrier~'.*(hedge)'   [0x10f0c resolution 24 continue]


Am Donnerstag, 4. November 2021, 11:07:44 CET schrieb Gerd Petermann:

  
Hi Manfred,

I assume you refer to https://www.osm.org/way/136793805
Maybe the tag barrier=fence makes the difference?

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

Re: [mkgmap-dev] Solarpark Inden will not be displayed with the correct polygon

[Manfred Haiduk]

Hi Gerd

yes, you are right, i've commented out the line

barrier=fence & fence_type!=railing [0x10f09 resolution 24]

in my lines file and the polygon will be displayed as it is supposed to
be. But, i don't understand, why this line prevents drawing the polygon
underneath ? And because of your hint, i checked my map and found
several areas which are not displayed as i wished, all of them with a
barrier=fence around.

Do you have another hint how to manage this ?

Thanks in advance


Am 04.11.2021 um 11:07 schrieb Gerd Petermann:

Hi Manfred,

I assume you refer to https://www.osm.org/way/136793805
Maybe the tag barrier=fence makes the difference?

Gerd


Von: mkgmap-dev  im Auftrag von Manfred 
Haiduk 
Gesendet: Mittwoch, 3. November 2021 13:44
An: Development list for mkgmap
Betreff: [mkgmap-dev] Solarpark Inden will not be displayed with the correct
polygon

Hi all

i just encounter a problem making my garmin maps. I do have the statement

generator:source=solar [0x6d resolution 24]

in my polygon style file. This works very well with all of the solar fields i 
have allready checked (not all, but these i was aware off) but for this 
particular solar field in the near of Weisweiler i get only the color of

Hintergrund

displayed.

Do you have an idea whats going wrong with this polygon ? I have allready tried 
to use a polygon with another drwaing priority but it seems, the polygon itself 
will not be recognized.

  Mit freundlichen Grüßen

#
Manfred Haiduk,
Zum Fischbach 9,
52393 Hürtgenwald
e-mail mhai...@t-online.de
#
___
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

Re: [mkgmap-dev] Solarpark Inden will not be displayed with the correct polygon

[Bernd Weigelt]

For these cases i have these rules in my style

# barrier
# please don't delete the continue action, because they are needed to render
# landuse polygons with barrier tags


barrier~'.*(wall)'[0x10f02 resolution 24 continue]
barrier~'.*(fence)'   [0x10f03 resolution 24 continue]
barrier~'.*(block)'   [0x10f05 resolution 24 continue]
barrier~'.*(hedge)'   [0x10f0c resolution 24 continue]


Am Donnerstag, 4. November 2021, 11:07:44 CET schrieb Gerd Petermann:
> Hi Manfred,
>
> I assume you refer to https://www.osm.org/way/136793805
> Maybe the tag barrier=fence makes the difference?
>
> Gerd


signature.asc
Description: This is a digitally signed message part.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Ticker Berkin]

Hi Gerd

Yes, patch r4809 caused the crash with Arndt's data (--lower-case and  
differently cased city names).

Ticker

On Thu, 2021-11-04 at 11:11 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> thanks, will have a closer later. Just to make sure:
> My understanding is that the assertion with Arndts data was caused by
> your patch (r4809) and everything worked fine with r4808 / r4810.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 4. November 2021 11:55
> 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
> 
> Here is a minimal patch to stop the 2 assertion crashes:
> 1/ unspecified sort for some blocks of Unicode chararacters.
> 2/ inconsistent MDR20 city positions that could result from city
> names
>    with different case or use of non-unicode multi-byte codepage
> 
> For 2/ with option --lower-case, the behaviour of how and which
> cities
> with capitalisation differences are shown in the find list, and which
> streets are attached to them is:
> 1/ device/BaseCamp/MapSource dependant.
> 2/ depends on how the streets are spread over tiles where there is
>    possible name conflict.
> 3/ Affected by the presence of city POI on a tile.
> 
> 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

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

[Gerd Petermann]

Hi Ticker,

thanks, will have a closer later. Just to make sure:
My understanding is that the assertion with Arndts data was caused by your 
patch (r4809) and everything worked fine with r4808 / r4810.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Donnerstag, 4. November 2021 11:55
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

Here is a minimal patch to stop the 2 assertion crashes:
1/ unspecified sort for some blocks of Unicode chararacters.
2/ inconsistent MDR20 city positions that could result from city names
   with different case or use of non-unicode multi-byte codepage

For 2/ with option --lower-case, the behaviour of how and which cities
with capitalisation differences are shown in the find list, and which
streets are attached to them is:
1/ device/BaseCamp/MapSource dependant.
2/ depends on how the streets are spread over tiles where there is
   possible name conflict.
3/ Affected by the presence of city POI on a tile.

Ticker

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Ticker Berkin]

Hi Gerd

Here is a minimal patch to stop the 2 assertion crashes:
1/ unspecified sort for some blocks of Unicode chararacters.
2/ inconsistent MDR20 city positions that could result from city names
   with different case or use of non-unicode multi-byte codepage

For 2/ with option --lower-case, the behaviour of how and which cities
with capitalisation differences are shown in the find list, and which
streets are attached to them is: 
1/ device/BaseCamp/MapSource dependant.
2/ depends on how the streets are spread over tiles where there is
   possible name conflict.
3/ Affected by the presence of city POI on a tile. 
  
Ticker

Index: src/uk/me/parabola/imgfmt/app/mdr/Mdr25.java
===
--- src/uk/me/parabola/imgfmt/app/mdr/Mdr25.java	(revision 4810)
+++ src/uk/me/parabola/imgfmt/app/mdr/Mdr25.java	(working copy)
@@ -12,6 +12,7 @@
  */
 package uk.me.parabola.imgfmt.app.mdr;
 
+import java.text.Collator;
 import java.util.ArrayList;
 import java.util.List;
 
@@ -37,6 +38,8 @@
 	 */
 	public void sortCities(List list) {
 		Sort sort = getConfig().getSort();
+		Collator collator = sort.getCollator();
+		collator.setStrength(Collator.TERTIARY);
 
 		List> keys = new ArrayList<>();
 		for (Mdr5Record c : list) {
@@ -53,8 +56,9 @@
 			Mdr5Record city = key.getObject();
 
 			if (lastCity == null ||
-	(!city.getName().equals(lastCity.getName()) || !(city.getRegionName().equals(lastCity.getRegionName()
-			{
+collator.compare(city.getName(), lastCity.getName()) != 0 ||
+collator.compare(city.getRegionName(), lastCity.getRegionName()) != 0 ||
+collator.compare(city.getCountryName(), lastCity.getCountryName()) != 0) {
 record++;
 
 // Record in the 29 index if there is one for this record
@@ -61,8 +65,8 @@
 Mdr14Record mdrCountry = city.getMdrCountry();
 Mdr29Record mdr29 = mdrCountry.getMdr29();
 String name = mdr29.getName();
-assert mdrCountry.getName().equals(name);
-if (!name.equals(lastName)) {
+assert collator.compare(mdrCountry.getName(), name) == 0;
+if (lastName == null || collator.compare(name, lastName) != 0) {
 	mdr29.setMdr25(record);
 	lastName = name;
 }
Index: src/uk/me/parabola/imgfmt/app/mdr/Mdr29.java
===
--- src/uk/me/parabola/imgfmt/app/mdr/Mdr29.java	(revision 4810)
+++ src/uk/me/parabola/imgfmt/app/mdr/Mdr29.java	(working copy)
@@ -12,6 +12,7 @@
  */
 package uk.me.parabola.imgfmt.app.mdr;
 
+import java.text.Collator;
 import java.util.ArrayList;
 import java.util.List;
 
@@ -36,6 +37,8 @@
 
 	public void buildFromCountries(List countries) {
 		Sort sort = getConfig().getSort();
+		Collator collator = sort.getCollator();
+		collator.setStrength(Collator.SECONDARY);
 		List> keys = MdrUtils.sortList(sort, countries);
 
 		// Sorted by name, for every new name we allocate a new 29 record and set the same one in every
@@ -46,7 +49,7 @@
 			Mdr14Record country = key.getObject();
 
 			String name = country.getName();
-			if (!name.equals(lastName)) {
+			if (lastName == null || collator.compare(name, lastName) != 0) {
 mdr29 = new Mdr29Record();
 mdr29.setName(name);
 mdr29.setStrOffset(country.getStrOff());
@@ -83,6 +86,8 @@
 		PointerSizes sizes = getSizes();
 		int size24 = sizes.getSize(24);
 		int size22 = sizes.getSize(22);
+		assert sizes.getNumberOfItems(5) >= sizes.getNumberOfItems(25)
+			: "5:" + sizes.getNumberOfItems(5) + " 25:" + sizes.getNumberOfItems(25);
 		int size25 = sizes.getSize(5);  // NB appears to be size of 5 (cities), not 25 (cities with country).
 		int size26 = has26? sizes.getSize(26): 0;
 		int size17 = Utils.numberToPointerSize(max17);
Index: src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java
===
--- src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java	(revision 4810)
+++ src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java	(working copy)
@@ -39,6 +39,8 @@
 	private int maxCityIndex;
 	private int localCitySize;
 	private int mdr20PointerSize = 0; // bytes for mdr20 pointer, or 0 if no mdr20
+	private Sort sort;
+	private Collator collator;
 
 	// We need a common area to save the mdr20 values, since there can be multiple
 	// city records with the same global city index
@@ -46,6 +48,9 @@
 
 	public Mdr5(MdrConfig config) {
 		setConfig(config);
+		sort = config.getSort();
+		collator = sort.getCollator();
+		collator.setStrength(Collator.TERTIARY);
 	}
 
 	public void addCity(Mdr5Record record) {
@@ -62,15 +67,14 @@
 	public void preWriteImpl() {
 		allCities.trimToSize();
 		localCitySize = Utils.numberToPointerSize(maxCityIndex + 1);
-		Sort sort = getConfig().getSort();
-		genCitiesAndMdr20s(sort);
+		genCitiesAndMdr20s();
 		// calculate positions for the different road indexes
-		calcMdr20SortPos(sort);
-		calcMdr21SortPos(sort);
-		calcMdr22SortPos(sort);
+		calcMdr20SortPos();  // TODO: Maybe this can be simplified 

Re: [mkgmap-dev] Solarpark Inden will not be displayed with the correct polygon

[Gerd Petermann]

Hi Manfred,

I assume you refer to https://www.osm.org/way/136793805
Maybe the tag barrier=fence makes the difference?

Gerd


Von: mkgmap-dev  im Auftrag von Manfred 
Haiduk 
Gesendet: Mittwoch, 3. November 2021 13:44
An: Development list for mkgmap
Betreff: [mkgmap-dev] Solarpark Inden will not be displayed with the correct
polygon

Hi all

i just encounter a problem making my garmin maps. I do have the statement

generator:source=solar [0x6d resolution 24]

in my polygon style file. This works very well with all of the solar fields i 
have allready checked (not all, but these i was aware off) but for this 
particular solar field in the near of Weisweiler i get only the color of

Hintergrund

displayed.

Do you have an idea whats going wrong with this polygon ? I have allready tried 
to use a polygon with another drwaing priority but it seems, the polygon itself 
will not be recognized.

 Mit freundlichen Grüßen

#
Manfred Haiduk,
Zum Fischbach 9,
52393 Hürtgenwald
e-mail mhai...@t-online.de
#
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] MDR and city streets on different tile from POI place=city

[Gerd Petermann]

Hi Ticker,

I fear you lost me. My current understanding is that it doesn't matter much if 
there is one city or two as long as the index structures are correct and Garmin 
software finds the objects that exist. MapSource seems to ignore the case 
differences when it builds the list of city names in the drop down lists, it 
only showed one entry in my tests. I've not yet tried to understand which 
variant is choosen, might be the first in the MDR5  section. Anyway, it 
presents results with different spelling and they all seem to be correct as the 
correct object is shown when I click on an entry.

Just post the minimal patch(es) and describe the expected effect(s) .


Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 3. November 2021 17:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] MDR and city streets on different tile from POI 
place=city

Hi Gerd

As per your example with "De Wijk", it could be the same city and
different cities and difficult to decide programatically - esp. if
different tiles.

My attempts to cope with this in the MDR indexes didn't seem to work
and I've abandoned this idea. I'd like to release a minimal patch that
fixes the 2 assertion crashes. With --lower-case, which streets are
attached to the different case variants of a city will not bear
scrutiny - I don't think it did before.

Then we should considering case-sensitivity of street, city, region and
country as a new issue.

Ticker


On Wed, 2021-11-03 at 14:27 +, Gerd Petermann wrote:
> Hi Ticker,
>
> yes, might be better to change that to be more precise. Question is
> if Aa and AA are two different cities or just different spellings of
> the same city. The latter is much more likely, so it seems justified
> to use only one.
> We have more code which tries to ignore case, e.g. for --housenumbers
> I often use String.equalsIgnoreCase() to work around different
> spelling in road names and addr:street or place names and addr:place.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 3. November 2021 11:40
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] MDR and city streets on different tile from
> POI place=city
>
> Hi Gerd
>
> The scenario is:
>  --lower-case,
>  2 tiles,
>  mkmap:city "Aa" area that spans the tiles",
>  streets with this mkgmap:city in either/both tiles,
>  the City POI "Aa" on one of the tiles,
>  another city, eg "AA" in the tile without the "Aa" POI,
>  streets for this.
>
> I am finding streets in the tile with both regions are all assigned
> to
> one or the other and this behaviour is effected by the presence of
> the
> City POI.
>
> PlacesFile::CreateCity(not unique) will return the same City record
> for
> both "Aa" and "AA" so I propose to remove the toUpperCase() from it
> when --lower-case (unless ascii/cp0 which forces upper case)
>
> Ticker
>
>
> On Wed, 2021-11-03 at 09:17 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > no idea what your problem is.
> > Address search seems to work fine without any city POI. I think the
> > code just tries to avoid duplicated entries in the LBL file?
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 2. November 2021 19:31
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] MDR and city streets on different tile
> > from
> > POI place=city
> >
> > Hi Gerd
> >
> > Actually, a major part of my problem is probably app/lbl/PlacesFile
> > with its toUpperCase()
> >
> > Ticker
> >
> > On Tue, 2021-11-02 at 16:52 +, Ticker Berkin wrote:
> > > Hi Gerd
> > >
> > > I've been checking the street list in the Mdr20 index to make
> > > sure
> > > they
> > > are attached to the correct city (as part of checking case-
> > > significance
> > > for the unicode/mdr errors) and finding discrepancies.
> > >
> > > I think this is because combiners/MdrBuilder, on a tile by tile
> > > basis
> > > takes the POI city list as the basis for Mdr5Records for
> > > attaching
> > > to
> > > streets and passing on for MDR processing.
> > >
> > > If the POI is in an adjacent tile to a road with the same
> > > mkgmap:city,
> > > there seem to be problems.
> > >
> > > This might be the reason for not being able to find some streets
> > > by
> > > city, rather than problems with case.
> > >
> > > I'm still trying to work it all out.
> > >
> > > 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] Solarpark Inden will not be displayed with the correct polygon

[Manfred Haiduk]

  
  
Hi all
i just encounter a problem making my garmin maps. I do have the
  statement 

generator:source=solar [0x6d resolution 24]
in my polygon style file. This works very well with all of the
  solar fields i have allready checked (not all, but these i was
  aware off) but for this particular solar field in the near of
  Weisweiler i get only the color of 
  
Hintergrund 

displayed.
Do you have an idea whats going wrong with this polygon ? I have
  allready tried to use a polygon with another drwaing priority but
  it seems, the polygon itself will not be recognized.

 Mit freundlichen Grüßen

#
Manfred Haiduk,
Zum Fischbach 9, 
52393 Hürtgenwald
e-mail mhai...@t-online.de
#
  

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev