logo separator

[mkgmap-dev] Small problem with global index

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Nov 22 15:27:47 GMT 2021

Hi Ticker,

the results probably depend on the way how you "renamed a city". You may only rename a single POI or also the data in the bounds.zip or maybe also addr:city=Upton etc.
That's why I keep asking for demo data to reproduce your results.
Testing this stuff is quite complex and error prone and thus we should try to have common input files to be able to verify our results.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 22. November 2021 16:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Small problem with global index

Hi Gerd

I had renamed a city (Upton>wherWell) to duplicate another (Wherwell)
in the same region, but with different capitalisation. The streets for
"wherWell" spanned tiles, one tile contained the the real "Wherwell",
the other tile contained the city POI (renamed in the same way).

I can't remember which, but one or both of MapSource/BaseCamp showed
both entries for the city during Find>Address, but one as "wherwell"
instead of "wherWell" and the other as "Wherwell". They had different
sets of streets, and these didn't even corresponding to the correct
city.

Ticker


On Mon, 2021-11-22 at 12:56 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> > it shouldn't be up to the user to know which variant of Country,
> > Region,City or Street to choose to find something,
> Yes, I agree. I never noticed such a problem in MapSource. Where do
> you see this problem?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Montag, 22. November 2021 12:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Small problem with global index
>
> Hi Gerd
>
> I'd forgotten about MapSource's better POI searching.
>
> If a mixed case map has differently cased variants of the same name,
> it
> shouldn't be up to the user to know which variant of Country, Region,
> City or Street to choose to find something, hence the interface
> should
> be case-insensitive. These case variants come from inconsistent OSM
> data and, at the moment, mkgmap logic.
>
> It might be possible for mkgmap to make a case-insensitive index by
> changing all TERTIARY to SECONDARY etc.
>
> However, once this is loaded into BaseCamp and MapInstall regenerates
> the indexes for a gmapsupp, it sees all the name variants and might
> include them in the new index structures. It lacks information to do
> this properly. The resultant index might have the problems described
> earlier about the user having to guess which Country, Region ...
> works.
>
> Ticker
>
>
> On Mon, 2021-11-22 at 10:54 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I test with MapSource and the POI search also offers fields for
> > region and country. On devices the search for region was probably
> > dropped.
> > Basecamp search is not very useful when you want to verify the
> > index.
> > The result is often a mixture of index results and nearby search.
> > > Your workflow makes sense when all upper case, but might not lead
> > > us to the best solution for mixed case.
> > Why not? I see also reasonable results for such a gmapsupp (but I
> > didn't try it on the device so far).
> > BTW: A good reason to use --lower-case in Germany are road names
> > like
> > Hauptstraße which is displayed as Hauptstrasse without that option.
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Montag, 22. November 2021 11:43
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Small problem with global index
> >
> > Hi Gerd
> >
> > The first stages of investigation should avoid other complexities
> > that
> > might be introduced by --lower-case (and --unicode). In this
> > environment there should be no difference between SECONDARY and
> > TERTIARY so the question is reduced to .equals() vs .compare() and
> > other flag settings / Mdr sections.
> >
> > Your tests seem be examining the behaviour of "Find" > "POI"
> > limited
> > by
> > region. My devices don't seem to have the ability do this and I
> > don't
> > see it in BaseCamp / MapSource either. "Find" > "Address" /
> > "Intersection" are the only places where I can limit by Country and
> > City.
> >
> > Your workflow makes sense when all upper case, but might not lead
> > us
> > to
> > the best solution for mixed case.
> >
> > Ticker
> >
> > On Mon, 2021-11-22 at 05:24 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > sorry, seems I attached the wrong patch for the default style.
> > > The
> > > problem is neither about upper/lower case nor about special
> > > characters like highway shield codes.
> > > It might be a problem in Garmin software, but it might as well
> > > show
> > > a
> > > problem with wrongly calculated repeat flags or maybe other
> > > flags.
> > > My thinking is that we should try to learn from the gmapsupp that
> > > is
> > > produced by MapSource, so my current workflow is this:
> > > - Compile the tile(s) and the gmapi and the gmapsupp.
> > > - Start MapSource, try if search works (it still doesn't for my
> > > example).
> > > - Generate a gmapsupp with Mapsource.
> > > - Extract the tiles from the gmapsupp (or copy those produced by
> > > mkgmap)
> > > - execute MdrDisplay and MdrCheck on the two different
> > > gmapsupp.img
> > > - compare all significant difference (different flags, existence
> > > of
> > > different sections etc)
> > >
> > > My latests results are that both MdrCheck and mkgmap should use
> > > TERTIARY strength were SECONDARY is used now.
> > > Unpatched MdrCheck reports several errors reg. repeat flags on
> > > Garmin
> > > maps which disapear when I use TERTIARY (the default).
> > > There also seems to be a problem with the positions of some bit
> > > flags. It seems that some flags should be shifted depending on
> > > the
> > > size of sections, but I don't know yet the details.
> > >
> > > Gerd
> >
> >
> > _______________________________________________
> > 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


More information about the mkgmap-dev mailing list