[mkgmap-dev] exclude words from city / state

Sat Jul 23 13:14:43 BST 2011

Hi,

the style system provides a substitution filter which can remove the 
'Gemeinde' prefix:

The following rule from the locator branch is expanded with 
"|subst:Gemeinde ":
mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level8=* { set 
mkgmap:city='${mkgmap:admin_level8|subst:Gemeinde }' }

The subst value filter searches for "Gemeinde " (I also want to remove 
the whitespace at the end) and replaces that with an empty string. If 
you want to replace that with something else you can build a rule like:
${mkgmap:admin_level8|subst:Gemeinde =>City }
This replaces "Gemeinde " with "City ".

Maybe we should create a similar filter that is more comfortable and 
optimized for removing multiple prefixed strings and/or postfixed 
strings. Please send your ideas.

WanMil

> 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
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev