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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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