Version mkgmap-r4337 was committed by gerd on Sat, 02 Nov 2019

Improve address search with better de-duplication of sorted roads in NET3
Expected effect: typically better search results AND slightly smaller NET files,
run time should not differ

NET1 contains the defintions of roads, NET3 contains a sorted list of offsets 
into NET1. It is sorted by the labels of the roads. The list is used when you 
search for a road name, maybe with additional attributes like a house number or 
city name or zip code.
So, we want at least one entry for each road where these attributes differ.
My current understanding is this:
When you do an address search the Garmin software uses the global index to find 
out which tiles contain the given road name. Next it uses the list in NET3 to 
build a list of matching NET1 entries. From those entries it extracts further 
information like city name(s), zip code(s(), and house numbers. Each of these 
roads in NET1 is matched against the further search pattern and that gives the 
result list.
So, our goal is to keep the NET3 list as small as possible to avoid a long 
result list with similar entries. This doesn't have to be perfect, but missing 
entries might cause a "not found" while redundant entries blow up the NET size 
as well as the search result lists.

The new implementation makes sure that all roads with house numbers appear in 
NET3, it also tries to write all further roads with different combinations of 
city and zip code. It probably doesn't work 100% correct when roads with 
multiple zip codes and without numbers are processed, but I think this should 
not happen with OSM input data.


http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4337
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to