[mkgmap-dev] Commit r3968: merge the optimize-index branch. This fixes some problems with address search

Mon Jun 12 05:48:36 BST 2017

Hi Carlos,

I am not sure how a search for full name can work in combination with this feature.
Maybe by adding the label to MDR15 two times, once with and once without the
separator characters. I've no spare time for coding during the next weeks, so maybe
someone else can have a look.

Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam at orangecorreo.es>
Gesendet: Freitag, 9. Juni 2017 14:35:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit r3968: merge the optimize-index branch. This fixes some problems with address search

Just a comment, probably searching by full name is not needed for suffixes.

El 09/06/17 a las 10:57, Gerd Petermann escribió:
> Hi all,
>
> thanks for the suggestions. I think the patch provided by Carlos looks reasonable. If no one complains I'll
> commit it on Monday.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam at orangecorreo.es>
> Gesendet: Montag, 5. Juni 2017 21:05:54
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit r3968: merge the optimize-index branch. This fixes some problems with address search
>
> First of all, a great thanks to Gerd for the lot of work behind this
> improvement to search functionality in mkgmap. That said, I think is
> would be convenient to keep the capability to search the original full
> name of roads when using road-name-config option, as many users tend to
> search it instead of main part of the name. Original Garmin maps are
> able to search both full name and main part.
> Attached is a first revision of roadNameConfig file which includes all
> Spanish speaking countries, suggestions from Stéphane and some
> alphabetical sorting.
>
> El 04/06/17 a las 09:15, Stéphane MARTIN escribió:
>> Hi,
>>
>> For France I suggest:
>>
>> -prefix1:fr = "Allée", "Chemin", "Avenue", "Rue", "Place"
>> +prefix1:fr = "Allée", "Chemin", "Avenue", "Rue", "Place", "Boulevard",
>> "Route"
>>
>> For Guyana, is a new item necessary ?
>> +lang:GUY = en
>>
>> Best regards.
>>
>> Steph
>>
>> Le 04/06/2017 à 03:18, Alexandre de Menezes a écrit :
>>> Hi Gerd,
>>>
>>> I have been testing the new features, and I have some suggestions for
>>> the sample file:
>>>
>>> 1) Spellcheck and new prefixes "Alameda"(means promenade) and
>>> "Beco"(means alley):
>>>
>>> -# portugese
>>> -prefix1:pt = "Rua", "Avenida", "Travessa"
>>> +# portuguese
>>> +prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco"
>>> prefix2:pt = "da ", "do ", "de ", "das ", "dos "
>>>
>>> 2) Add Brazil to the Portuguese speaking countries:
>>>
>>> +lang:BRA = pt
>>> lang:CAN = en, fr
>>>
>>>
>>> Best regards,
>>>
>>>       Alexandre
>>>
>>> On 02/06/2017 02:07, svn commit wrote:
>>>> Version mkgmap-r3968 was committed by gerd on Fri, 02 Jun 2017
>>>>
>>>> merge the optimize-index branch. This fixes some problems with address
>>>> search
>>>> and adds new options which give control the content of the index. Also,
>>>> option split-name-index is no longer temporary.
>>>>
>>>> New options:
>>>> --road-name-config=file
>>>>       This option handles the problem that some countries have road
>>>> names which
>>>>       often start or end with very similar words, e.g. in France the
>>>> first word
>>>>       is very often 'Rue', often followed by a preposition like 'de la'
>>>> or 'des'.
>>>>       This leads to rather long road names like 'Rue de la Concorde'
>>>> where only
>>>>       the word 'Concorde' is really interesting. In the USA, you often
>>>> have names
>>>>       like 'West Main Street' where only the word 'Main' is important.
>>>>       Garmin software has some tricks to handle this problem. It allows
>>>> to use
>>>>       special characters in the road labels which mark the beginning and
>>>> end of
>>>>       the important part. In combinarion with option split-name-index
>>>>       only the words in the important part are indexed.
>>>>
>>>>       There are two different visiual effects of this option:
>>>>       - On the PC, when zooming out, the name 'Rue de la Concorde' is only
>>>>           rendered as 'Concorde'.
>>>>       - The index for road names only contains the important part of the
>>>> name.
>>>>           You can search for road name Conc to find road names like 'Rue
>>>> de la Concorde'.
>>>>           One problem: Search for 'Rue' will not list 'Rue de la Concorde'
>>>>           or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if that
>>>> is in the map.
>>>>           Only MapSource shows a corresponding hint.
>>>>
>>>>       Another effect is that the index is smaller.
>>>>       The option specifies the path to a file which gives the details. See
>>>>       comments in the sample roadNameConfig.txt for further details.
>>>>     --mdr7-excl
>>>>       This option allows to specify words which should not be in the
>>>> road index.
>>>>       It was added before option road-name-config and is probably no
>>>> longer needed.
>>>>       Example usage: --x-mdr7-excl="Road, Street, Straße, Weg"
>>>>     --mdr7-del
>>>>       Use this option if your style adds strings to the labels of roads
>>>> which you
>>>>       want to see in the map but which should not appear in the result list
>>>>       of a road name / address search. The list is used like this:
>>>>       For each road label mkgmap searches the last blank. If one is
>>>> found, it checks
>>>>       if the word after it appears in the given list. If so, the word is
>>>> removed
>>>>       and the search is repeated. The remaining string is used to create
>>>> the index.
>>>>       Example: Assume your style adds surface attributes like 'pav.' or
>>>> 'unp.' to a road
>>>>       label. You can use --mdr7-del="pav.,unp." to remove these
>>>> apendixes from the index.
>>>>
>>>> --poi-excl-index
>>>>       By default, mkgmap indexes the following POI types with a
>>>> non-empty label:
>>>>       - 0x00 .. 0x0f (cities, sub type 0, type <= 0xf)
>>>>       - 0x2axx..0x30xx (Food & Drink, Lodging, ...)
>>>>       - 0x28xx (no category ?)
>>>>       - 0x64xx .. 0x66xx (attractions)
>>>>       This option allows to exclude POI types from the index.
>>>>       The exclueded types are not indexed, but may still be searchable
>>>> on a device
>>>>       as some devices seem to ignore most of the index, e.g. an Oregon
>>>> 600 with
>>>>       firmware 5.00 only seems to use it for city search.
>>>>       If you device finds a POI name like 'Planet' when you search for
>>>> 'Net'
>>>>       it doesn't use the index because the index created by mkgmap
>>>> cannot help for
>>>>       that search.
>>>>       So, this option may help when you care about the size of the index
>>>> or the
>>>>       memory that is needed to calculate it.
>>>>       The option expects a comma separated list of types or type ranges.
>>>> A range is
>>>>       given with from-type-to-type, e.g. 0x6400-0x6405. First and last
>>>> type are both
>>>>       excluded.A range can span multiple types, e.g. 0x6400-0x661f.
>>>>       Examples for usage:
>>>>       - Assume your style adds a POI with type 0x2800 for each
>>>> addr:housenumber.
>>>>           It is not useful to index those numbers, so you can use
>>>>           --poi-excl-index=0x2800
>>>>           to exclude this.
>>>>       - For the mentioned Oregon you may use --poi-excl-index=0x2a00-0x661f
>>>>           to reduce the index size.
>>>>
>>>>
>>>>
>>>> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3968
>

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev