[mkgmap-dev] exclude words from city / state

Sun May 22 20:00:13 BST 2011

On 22.05.2011 20:47, WanMil wrote:
>> 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).
>
> 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