Using the locator branch, I noticed that many cities in Austria are not findable anymore. The problem is that there are words like "Gemeinde Mödling" or "Bezirk Mödling" or "county XYZ". There should be a list where one can enter words that get deleted. That is because for the boundary it is the correct name, but not for searching a street.
Also there are problems in Austria in Vienna. Vienna is a state and a city, and ideally it should be possible to enter either the district or the city into the city field, in order to find a street. Currently it is not possible to properly separate cities outside Vienna from districts inside Vienna, as they have the same admin_level. But for the ise tags, there is a correct specification telling you that districts are not cities (from the standpoint of the admin_level, it is correct however to classify them the same as small cities outside of Vienna). So in effect if one does not enter specific rules for Vienna, address search can never work as expected. Admin_level was never intended to be used for address searching, hence taking it is flawed and will not provide correct results. Ise is intended for address searching, but mkgmap does not use it.
In general after using the locator branch, I more and more think, that the whole matching is completly the wrong way of doing. Much better to support real addresses as entered in OSM, and not do so much guessing. Especially support housenumbers, as at least in Germany and Austria housenumbers including full ise tags are becoming the norm, and not the exception. Only footways, pathes, or tracks should be matched, as they usually have no real address - but then it's rare that one searches for a specific path/track/footway, only real use would therefore be
Felix,
I understand that you are no longer interested in. Well it is not that I am not interested at all in it. But I don't think it is a good way to do in the long run. It will never yield better 90% accuracy, and it stops people mapping correctly (real addresses) and it might promote people to map boundaries wrongly, in order to get addresses right (like some years ago people retagging highway=path because Osmarender and the dreaded Opencyclemap would not render them and thereby causing a widely spread misconception of understanding the "Do not tag for renderers" into "Map as you like, it does not have to be readable in a consistent form, renderers should be creative and intelligent in understanding what my custom tagging means").
I hope, maybe at least by using "add" instead of "set" the current way can be enhanced, but the fact that the current locator branch destructs and thus renders invalid correct addresses is a real nogo for me (and shouldn't be promoted by such a popular tool like mkgmap).
Using the trunk, I can find about 90% of streets in Austria (tested in cities and countryside) in the correct city, with locator this drops to less than 10% as boundary name for a city is in most cases different from address name of a city.
Also I think searching for routes, footways, pathes or tracks is indeed an important feature, where the current locator branch approach is the best method (just the problem that the name of a boundary, is not the name of the address persists and is really bad - at least in Austria in my eyes it makes the city choice nearly unusable).
That's where the style system comes into play. If you don't want to use the boundaries you don't have to. Maybe it does not work perfectly at the moment but it is a branch. If the majority of the list doesn't like it at the *end* of development we can trash it. It's just a study if it improves mkgmap. And in the end it's open source so you can contribute with source code *any* time if you think you can improve parts of it.
Anyhow the mkgmap source code contains a SubstitutionFilter class which performs some string replacements. This should work to replace and to remove common words.
Okay, I'll see if I can understand how it works.
BTW will right now test why the locator branch crashes on some countries for me, while the normal mkgmap trunk processes them in a matter of<30 seconds. Maybe I got the pbf support wrong (by including outdated/future libs???).
I don't know how this filter can be configured in the style file but maybe someone else remembers.
WanMil