Menion:Sure it is possible.There is an only simple convention - database has to have same name and be in same directory as map. So if you map has name. "my_map.osm.map", then database has to be in same directory with name: "my_map.osm.db".

Some time ago, there were restriction to only LoMaps + DB. This is not anymore needed, so feel free to use this database with all possible vector maps.

Ah only limitation is version of maps. It needs to be based on format of MapsForge V3.

2) Now districts/ suburb names are displayed. Very nice improvement but inconsistent. In old example map=oceania.South Australia > city=Adelaide > street=Grenfell St the way https://www.openstreetmap.org/way/174104238 should have district name of Adelaide but is blank:

Other old examples of ways are still OK.

Some user interface issues.

3) Now each time address search is performed user must specify whether online/ offline search. Previously this was just a setting - fine. Also notice the dash-dash-dash icon in top/right corner wiggles madly. Necessary? Maybe just once but then remember preference please?

4A) When empty city field is displayed the keyboard is not always displayed.4B) When empty city field is displayed a list of recently entered cities is not always displayed.4C) When empty street field is displayed the keyboard is not always displayed.4D) When empty street field is displayed a list of recently entered streets is not always displayed.I can't work out why/ when this happens. Sometimes the keyboard is displayed OK, and MRU list is displayed OK, but other times it isn't. It seems related to the online/ offline side panel, but no pattern.

5) When I select a name from onscreen keyboard suggestions (eg. Swiftkey) it appears that Locus is now deleting the space character, for example "grenfell " ==> "grenfell" so if now have to tap space character myself if I want to add "str*" or "roa*".

Issue 1 and 2 are on Petr, because it's he who create database itself. Anyway because I was just solving some issues with him last days, I think that these two will be also solved with new database, but he will say more.

3. - correctly, I've forget to display this just once (because of testing), fixed

4A, 4C ... very hard to fix. When I notice it and discover some mechanism to repeat it, I'll definitely try to fix it.4B ... found that happen right after open screen, fixed4D ... it should not, there are currently no hints for a streets when no text is entered

5. hmm it really happen to you? Just testing (after some previous fixes for 3. and 4. point) and it do not happen to me with default keyboard and as I check a code, it really should preserve selected text from keyboard. Maybe a Swiftkey speciality? You will see in next version, but I'm worried it will be same. Are you able to test next version with different (default system) keyboard? Thanks

thanks @menion for updatebecause I will be cycling in foreign countries for 2 months soon you can tell I am very keen to have offline address search working nicely

4A, 4C - I thought they were working better in 3.16.2.7 than 3.16.2.9

>5. hmm it really happen to you? Just testing (after some previous fixes for 3. and 4. point) and it do not happen to me with> default keyboard and as I check a code,

I just tested with Swiftkey, when suggested "street" is tapped from keyboard, I can see briefly the full text "street"<space> pasted into the field (with cursor moved after <space>), and short time later a visual <backspace> operation to delete the <space> character. Could Swiftkey do that? When I use a text editor (Jota) and do exact same sequence the editor does preserve the <space> character!

So I tried default Google & Swiftkey keyboards with street "north" - fairly common, with Google no space is pasted, & with Swiftkey operation as described. I can't tell "who" is doing the mysterious <backspace>.

@Andrew Heard1) North Street and Slovenia Ljubljana - this should be fixed in the next address database that is in generation process

2) Inconsistent suburbs - Well it's similar to previous problem - to find the best city / district / suburb for street. If no suburb is found for street then no suburb is shown in dialog. However especially mentioned Grenfell St should be displayed with Suburb - I'll check it in the next DB (probably in the end of this week)

I have noticed a new? bug with long tap labels displaying the wrong offline address. I don't recall a problem prior to current beta 3.16.2.12 but maybe I just hadn't tapped in the "wrong" places. Below I long tap on "Huon Highway" (Oceania> Australia> Tasmania) S42.59.036 E147.11.591 https://www.openstreetmap.org/way/131480712 - address in label is correct:

But when I long tap on another way "Pelverata Road" 200m to south S42.59.142 E147.11.650 https://www.openstreetmap.org/way/254103410 - observe that label incorrectly shows "Huon Highway" instead of "Pelverata Road":

So I did some more testing. Mostly the label address is correct, but sometimes not.

I can do an offline address search and the road is correctly found: map=Tasmania city=Pelverata street=Pelverata Road.

Pelverata Road - unfortunately I'm not sure if this is issue or not. My goal was to limit long named roads that are fare from Cities or towns. Because named road outside the city is not street (from my central European point of view ) And such road should not be in address database. When you try the reverse search near Pelverata city you can get correct value - because there is a record in offline database for this part https://www.openstreetmap.org/way/59454330 of Pelverate road

Do you think that all named roads should have a record in offline DB? Let's say that there is a long road that have about 40 km. Is it important (in Australia) to use such long road for offline address search?

Pelverata Road - unfortunately I'm not sure if this is issue or not. My goal was to limit long named roads that are fare from Cities or towns. Because named road outside the city is not street (from my central European point of view ) And such road should not be in address database. When you try the reverse search near Pelverata city you can get correct value - because there is a record in offline database for this part https://www.openstreetmap.org/way/59454330 of Pelverate road

@voldapet - hmmm, strange, because another road few 100m south of example road (Talbots Rd) has correct long tap label and found with offline address search. This seems only example I have found. The road IS in the address database, simply that long tap displays wrong one. I think best to ignore report for now.

Do you think that all named roads should have a record in offline DB? Let's say that there is a long road that have about 40 km. Is it important (in Australia) to use such long road for offline address search?

@Andrew HeardMy description were quite simplified. There are more values that influence if road / street has record in DB. Num of segments (number of OSM Way with the same name), the distance from the city (if any exist around), houses along the road...

The handling of long roads is not ideal and the address database does not expect that there could be long roads outside the towns. The generator process them but there are some weakness. More over is complicated to recognize if Osm Way is part of street inside any town if it is only some named road outside. For example almost every forest track in Germany has defined the name. For example https://www.openstreetmap.org/way/37641016

And the question is how handle such way? Is it street? Should we use this road in address search? This is probably the question for every body..

Which brings back the issue of missing option to download only the Address/POI DBs.As we know, those work nicely with maps like Mapsforge or OAM, if you respect the naming convention. Hence there is no justification to handcuff those LoMaps and Address/POI DBs.You argued in the past that the LoCoins cover the server cost and traffic. Fair enough. So, why let people create useless traffic and make them pay for it, if they only need the Address/POI DBs ??TXS and cheersMichael