[mkgmap-dev] Small problem with global index

Fri Nov 26 10:56:01 GMT 2021

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 global index is created we can log warnings for those cases, but I don't see yet how we can create a valid index which doesn't require the user to decide whether wherWell or Wherwell should be searched.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Donnerstag, 25. November 2021 10:43
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Small problem with global index

Hi Ticker,

yes, sorry, I probably wasn't fully awake this morning and forgot what the problem is :(

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, 25. November 2021 10:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Small problem with global index

Hi Gerd

Sorry about the confusion with Upton/Upham.

Baybridge Lane has a section in Upham and there is nothing of this name
in Wherwell so it is clear it should be found as a street in Upham
(wherWell with the rename).

I'm not saying there is a problem with the global index, except that
when using --lower-case and there are case-variations in city names, it
might be necessary for the user to guess which variation to use to find
a street and, worse, some streets in the same city might require the
choice of the other variant.

Ticker

On Thu, 2021-11-25 at 06:15 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> it's all quite confusing for me because your table mentiones Upton
> but the rules say Upham ;)
> Anyway, when I remove the rules which replace Upham by wherWell the
> road "Baybridge Lane" is still found in the upper tile, so it is not
> a problem with the global index.
> Looking at the current data I see that the road crosses the boundary
> between Owslebury and Upham near
> https://www.openstreetmap.org/way/368825450, so it's not clear to
> which area it belongs.
>
> Gerd
>
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Gerd Petermann <gpetermann_muenchen at hotmail.com>
> Gesendet: Donnerstag, 25. November 2021 06:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Small problem with global index
>
> 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
> _______________________________________________
> 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