[mkgmap-dev] Small problem with global index

Thu Nov 25 05:37:58 GMT 2021

Hi Ticker,

OK, sorry, did not understand the table. I can confirm that the search for "Baybridge Lane" doesn't work as expected.

Gerd

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

Hi Gerd

In this example, choosing the correct version of the spelling doesn't
necessarily work!

To find "Alma Lane", which is in Upton=wherWell, "wherWell" must be
selected as the city.

To find "Baybridge Lane", also in Upton=wherWell, "Wherwell" must be
given.

Getting capitalisation consistent in OSM would be a good thing.
Generally, for cities, it is pretty good; in the original problem
report (Arndt / NRW + surrounding) I found only 3 examples. However,
for streets, I find a lots. This is why I'm keen on getting to a nicely
working case-insensitive search and against moving existing logic from
SECONDARY to TERTIARY/EQUAL

is-in logic unconditionally upper-casing everything isn't ideal - I
don't think it adds to the problem but its effect might be visible.

The strange behaviour in this example is because, although
combiners/MDRBuilder attempts to do case-insensitive dedup on COUNTRY,
REGION and CITY, a CITY POI (only existing in 1 tile) evades this and
so, in this tile, there might be 2 entries with different city.index.
This needs to be fixed before trying to change from TERTIARY/EQUAL to
SECONDARY.

Concerning the case where there really are 2 Cities with the same name
in the same region: There isn't any way of distinguishing which streets
belong to which (in my example the correct city is in another tile), so
how many streets with the same name to show? With the current mkgmap
implementation of not joining streets with different attributes, there
might be many in the same city. mkgmap appears to dedup them (give or
take the r/rr flags which I haven't understood yet), which is
reasonable if all in 1 city but not if >1.

Ticker

On Wed, 2021-11-24 at 16:39 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> OK, with the zipped style I could reproduce (with r4808) some
> results. I think MapSource works well, but with my Oregon I also
> have  the problem that I have to decide whether I want to search in
> wherWell or in Wherwell,
> and the device will only find the roads in the corresponding city.
> That's not nice but at least it looks correct, means, it doesn't find
> Alma Lane in "Wherwell", only in "wherWell", and e.g. Bigpath Lane is
> found in both cities, but different and correct roads for each.
>
> When I change your style to replace Upton by Wherwell the device
> shows only one Wherwell as city after typing wh and three occurrences
> for Bigpath Lane. That's good and I guess you would want the same for
> the special case that cities are written with only TERTIARY
> differences?
>
> No idea if this is a good approach. Maybe it's better to let the user
> stumble over this so that someone fixes the wrong OSM data.
>
> Gerd

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev