[mkgmap-dev] exclude words from city / state

Sun Jul 17 17:50:24 BST 2011

I noticed that level 8 boundaries in Germany use the name of the city, 
and that lavel 8 boundaries in Austria always have the prefix 'Gemeinde' 
in the name before the name of the city. That prefix is in my opinion 
obsolete information. Using a Garmin one always needs to type this 
prefix 'Gemeinde'. Does anyone know hoe we can get rid of typing this 
prefix in Garmin devices?

Cheers, Johan

On Sun, 22 May 2011 21:09:25 +0200, 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).
>
> 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev