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