Locus Map - forum

Support => Information => Topic started by: Menion on January 17, 2011, 06:53:14

Title: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on January 17, 2011, 06:53:14
needed version - 0.9.22 and higher

Android limitation
After some testing, seems that Android cannot handle files bigger then 2^31 b, so around 2GB!! Here I slowly create solution how to use maps bigger then this limitation in Locus software, so ...

ACTUAL STATE
OK, solution is out in version 0.9.22. It need to be tested!

How dows it work
In Locus/maps directory create new directory for your new SQL map. Into this directory upload all files that you want to be as one map. After Locus start, it initialize all map parts (you have to wait for a while, 1GB map takes around 2 minutes, so count with it) and then you can use it. All files in this directory now work as ONE MAP!

Also, for perfect usage, there should be any tool that help to create these maps.

Locus
In locus you should create maps lower then 2GB. Bigger cannot be created due to Android limitation. I should create some tool that help separate maps into more parts directly in Locus, but will not be used by many people as well as I have important thinks to do. So actually, to create these maps in Locus, you ahve to create every part separate and manually and then also manually copy them into one directory in Locus/maps!

Mobac
Much better tool to create big maps. Only one disadvantage. It have no tool to separate maps into parts needed by Locus. So, best solution as I can see, if anyone wrote tool (in Python for example) that separate big maps into 2GB parts!


NEXT METHOD IS DEPRECATED, SO DON'T USE IT
[s:1vycvo9h]In android device seems to be some limitation on external SQL database (on internal also). This limitation don't allow to go through simple sql query on whole table so you have to use this alternative method! (It's also useful if you want faster initialization or you have any other troubles with SQL map initialization process)


IMPORTANT
If you change map file, initialization process will run for this map again (it depend on time of last edit of map file) so TXT file will be loaded again.
But when you for example download any new layer into map file, but you do not change TXT file before initialization process run in Locus, no new layer will be visible. If this problem occur, change layers in TXT file to correct values and also DELETE cache directory. Initialization process will run again and now ... correctly![/s:1vycvo9h]
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: naxan on January 17, 2011, 21:41:23
Hi,

unfortunately, with a 4.5GB map, it doesn't work.. in the end:
With help by the .txt-file, I can import the map and also show it.
but: in highest zoom level, somewhere in my map theres a 'vertical border': if I cross it from left to right, I just get a white screen.
If I swype back the left, tiles are shown again.

I think all tiles beyond a certain point in the db cannot be accessed. Here an excerpt from logcat:

I/Database( 3045): sqlite returned: error code = 266, msg = prepared statement aborts at 11: [SELECT image FROM tiles WHERE x=='17224' AND Y=='11749' AND z=='2']
E/FileMapTypeAbstract( 3045): appendRequest(), filePath: /mnt/storage/sdcard/Norditalien.sqlitedb
E/FileMapTypeAbstract( 3045): android.database.sqlite.SQLiteDiskIOException: disk I/O error
E/FileMapTypeAbstract( 3045): at android.database.sqlite.SQLiteQuery.native_fill_window(Native Method)
E/FileMapTypeAbstract( 3045): at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:70)
E/FileMapTypeAbstract( 3045): at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:283)
E/FileMapTypeAbstract( 3045): at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:264)
E/FileMapTypeAbstract( 3045): at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:171)
E/FileMapTypeAbstract( 3045): at android.database.AbstractCursor.moveToFirst(AbstractCursor.java:248)
E/FileMapTypeAbstract( 3045): at menion.android.maps.filemaps.FileMapTypeSql.directDownload(FileMapTypeSql.java:233)
E/FileMapTypeAbstract( 3045): at menion.android.maps.filemaps.FileMapTypeAbstract.appendRequests(FileMapTypeAbstract.java:254)
E/FileMapTypeAbstract( 3045): at menion.android.maps.FileMapLayer.drawMap(FileMapLayer.java:155)
E/FileMapTypeAbstract( 3045): at menion.android.maps.MapLayer.drawMap(MapLayer.java:120)
E/FileMapTypeAbstract( 3045): at menion.android.maps.MapContent.drawMap(MapContent.java:310)
E/FileMapTypeAbstract( 3045): at menion.android.maps.background.SimpleMapScreenBackground.drawContent(SimpleMapScreenBackground.java:29)
E/FileMapTypeAbstract( 3045): at menion.android.maps.background.AbstractMapScreenBackground.onDraw(AbstractMapScreenBackground.java:50)
E/FileMapTypeAbstract( 3045): at android.view.View.draw(View.java:6740)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.drawChild(ViewGroup.java:1640)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1367)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.drawChild(ViewGroup.java:1638)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1367)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.drawChild(ViewGroup.java:1638)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1367)
E/FileMapTypeAbstract( 3045): at android.view.View.draw(View.java:6743)
E/FileMapTypeAbstract( 3045): at android.widget.FrameLayout.draw(FrameLayout.java:352)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.drawChild(ViewGroup.java:1640)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1367)
E/FileMapTypeAbstract( 3045): at android.view.View.draw(View.java:6743)
E/FileMapTypeAbstract( 3045): at android.widget.FrameLayout.draw(FrameLayout.java:352)
E/FileMapTypeAbstract( 3045): at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:1876)
E/FileMapTypeAbstract( 3045): at android.view.ViewRoot.draw(ViewRoot.java:1407)
E/FileMapTypeAbstract( 3045): at android.view.ViewRoot.performTraversals(ViewRoot.java:1163)
E/FileMapTypeAbstract( 3045): at android.view.ViewRoot.handleMessage(ViewRoot.java:1727)
E/FileMapTypeAbstract( 3045): at android.os.Handler.dispatchMessage(Handler.java:99)
E/FileMapTypeAbstract( 3045): at android.os.Looper.loop(Looper.java:123)
E/FileMapTypeAbstract( 3045): at android.app.ActivityThread.main(ActivityThread.java:4627)
E/FileMapTypeAbstract( 3045): at java.lang.reflect.Method.invokeNative(Native Method)
E/FileMapTypeAbstract( 3045): at java.lang.reflect.Method.invoke(Method.java:521)
E/FileMapTypeAbstract( 3045): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
E/FileMapTypeAbstract( 3045): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
E/FileMapTypeAbstract( 3045): at dalvik.system.NativeStart.main(Native Method)
D/PersistentEventStore/putEvent( 3045): Row ID: 648, Event ID: 648
I/Database( 3045): sqlite returned: error code = 266, msg = prepared statement aborts at 11: [SELECT image FROM tiles WHERE x=='17225' AND Y=='11749' AND z=='2']
E/FileMapTypeAbstract( 3045): appendRequest(), filePath: /mnt/storage/sdcard/Norditalien.sqlitedb
E/FileMapTypeAbstract( 3045): android.database.sqlite.SQLiteDiskIOException: disk I/O error
E/FileMapTypeAbstract( 3045): at android.database.sqlite.SQLiteQuery.native_fill_window(Native Method)
E/FileMapTypeAbstract( 3045): at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:70)
E/FileMapTypeAbstract( 3045): at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:283)
E/FileMapTypeAbstract( 3045): at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:264)
E/FileMapTypeAbstract( 3045): at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:171)
E/FileMapTypeAbstract( 3045): at android.database.AbstractCursor.moveToFirst(AbstractCursor.java:248)
E/FileMapTypeAbstract( 3045): at menion.android.maps.filemaps.FileMapTypeSql.directDownload(FileMapTypeSql.java:233)
E/FileMapTypeAbstract( 3045): at menion.android.maps.filemaps.FileMapTypeAbstract.appendRequests(FileMapTypeAbstract.java:254)
E/FileMapTypeAbstract( 3045): at menion.android.maps.FileMapLayer.drawMap(FileMapLayer.java:155)
E/FileMapTypeAbstract( 3045): at menion.android.maps.MapLayer.drawMap(MapLayer.java:120)
E/FileMapTypeAbstract( 3045): at menion.android.maps.MapContent.drawMap(MapContent.java:310)
E/FileMapTypeAbstract( 3045): at menion.android.maps.background.SimpleMapScreenBackground.drawContent(SimpleMapScreenBackground.java:29)
E/FileMapTypeAbstract( 3045): at menion.android.maps.background.AbstractMapScreenBackground.onDraw(AbstractMapScreenBackground.java:50)
E/FileMapTypeAbstract( 3045): at android.view.View.draw(View.java:6740)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.drawChild(ViewGroup.java:1640)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1367)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.drawChild(ViewGroup.java:1638)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1367)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.drawChild(ViewGroup.java:1638)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1367)
E/FileMapTypeAbstract( 3045): at android.view.View.draw(View.java:6743)
E/FileMapTypeAbstract( 3045): at android.widget.FrameLayout.draw(FrameLayout.java:352)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.drawChild(ViewGroup.java:1640)
E/FileMapTypeAbstract( 3045): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1367)
E/FileMapTypeAbstract( 3045): at android.view.View.draw(View.java:6743)
E/FileMapTypeAbstract( 3045): at android.widget.FrameLayout.draw(FrameLayout.java:352)
E/FileMapTypeAbstract( 3045): at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:1876)
E/FileMapTypeAbstract( 3045): at android.view.ViewRoot.draw(ViewRoot.java:1407)
E/FileMapTypeAbstract( 3045): at android.view.ViewRoot.performTraversals(ViewRoot.java:1163)
E/FileMapTypeAbstract( 3045): at android.view.ViewRoot.handleMessage(ViewRoot.java:1727)
E/FileMapTypeAbstract( 3045): at android.os.Handler.dispatchMessage(Handler.java:99)
E/FileMapTypeAbstract( 3045): at android.os.Looper.loop(Looper.java:123)
E/FileMapTypeAbstract( 3045): at android.app.ActivityThread.main(ActivityThread.java:4627)
E/FileMapTypeAbstract( 3045): at java.lang.reflect.Method.invokeNative(Native Method)
E/FileMapTypeAbstract( 3045): at java.lang.reflect.Method.invoke(Method.java:521)
E/FileMapTypeAbstract( 3045): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
E/FileMapTypeAbstract( 3045): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
E/FileMapTypeAbstract( 3045): at dalvik.system.NativeStart.main(Native Method)
D/PersistentEventStore/putEvent( 3045): Row ID: 649, Event ID: 649
I/Database( 3045): sqlite returned: error code = 266, msg = prepared statement aborts at 11: [SELECT image FROM tiles WHERE x=='17225' AND Y=='11749' AND z=='2']
D/dalvikvm( 3045): GC_FOR_MALLOC freed 5566 objects / 546296 bytes in 50ms
E/Cursor  ( 3045): Finalizing a Cursor that has not been deactivated or closed. database = /mnt/storage/sdcard/Norditalien.sqlitedb, table = tiles, query = SELECT image FROM tiles WHERE x=='17225' AND Y=='11749' AND z=='2'
E/Cursor  ( 3045): android.database.sqlite.DatabaseObjectNotClosedException: Application did not close the cursor or database object that was opened here
E/Cursor  ( 3045): at android.database.sqlite.SQLiteCursor.<init>(SQLiteCursor.java:210)
E/Cursor  ( 3045): at android.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:53)
E/Cursor  ( 3045): at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1345)
E/Cursor  ( 3045): at android.database.sqlite.SQLiteDatabase.queryWithFactory(SQLiteDatabase.java:1229)
E/Cursor  ( 3045): at android.database.sqlite.SQLiteDatabase.query(SQLiteDatabase.java:1184)

Due to
  http://www.mail-archive.com/android-dev ... 79647.html (http://www.mail-archive.com/android-developers@googlegroups.com/msg79647.html)
I already tried adding another index to the db, which resulted in the above error happening _all_ the time in every zoom level...
Now trying other constellations, but without much hope..
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on January 17, 2011, 23:01:18
oh crap ... seems that my idea that for maps now will not be any limit is not comming to be true ...

hmm, thanks naxan for excelent test. No it's important to figure out if problems starts on 4GB map files or even on 2GB files.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: naxan on January 17, 2011, 23:19:58
Up to 2GB do work for me (they already worked before; largest one has 2.045.807).
But I didn't test larger than 2GB (besides 4,5GB).
Actually, in the optimum case, I'd have wanted  something like 14GB ;)
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on January 17, 2011, 23:52:05
Heh, 14GB seems to be good :) but unfortunately as you can see, this is not in my power!

so with this troubles, comes two questions!
1) which is maximum size allowed to read correctly and why is this limit!
2) is here any other solution on this problem? Maybe some special format with separated files working all together ...

anyway ... did anyone tried this huge maps on any other supported software how they handle them? RMaps for example ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: mmcyklo on February 21, 2011, 22:36:04
Hi there,

any news in the possibility of over 2GB maps (at least 2-4GB as Android does not support NTFS format so only 4GB is possible to put on SD)?

Thanks
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: GOF007 on February 22, 2011, 22:43:02
I have no SQL knowledge but just a simple idea.
If there is 2 GB limit per DB file why dont just split the file?

For large original map file, it should be possible to run a script to split them.....
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on February 22, 2011, 22:52:32
I'm already working on it, don't worry, solution will be available. Anyway I'll not do direct support into Locus to download and automatically separate this big map files. It should be better to create this by Mobac and then separate to more files as you wrote.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: mmcyklo on February 23, 2011, 09:13:58
This woud be realy perfect solution - I have created approx 10 GB full resolution map for CZSK, so if it would be possible to split it into 5 x 2GB files and to use it in Locus (like one map) would be excelent!
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: ykf on March 02, 2011, 11:30:14
Hi, I'm a java developer, and I can help to write a small tool to split the sqlite db into separate files. Menion can you tell me how Locus now read the database of more than 1 file?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 02, 2011, 11:49:06
Hi,
  hmm excellent! What do you exactly need to know?

I just object that hold list of database files sorted by filename (just in Arraylist). When request for any tile come, I'm doing through all files and check if this tile is in database.

When second request on tile come, I then check firstly the last used database file. If nothing there, then I go as in first case, from first to last (except the one already tested).

So question is, what is the best separate algorithm right? There is not much big problem count of files. Best for performance will be if whole zoom will be in same file. You should create some simple solution as


When zoom level is bigger then 2GB, then you should separate it into more then one file also by any algorithm. If only to two parts, it's simple. If more, this should be interesting ... :)

And last think. Initializing of 2GB SQLite db file (just executing query "select distinct z from tiles") takes on android cca 3 minutes!! It will be good to on the end, create some txt file with zoom values in every file. Best will be for every file, same file with "txt" ending, that contain numbers separate by comma with zoom values. Initializing of this map will then be incredibly fast ...

uff, long story from me. Ask whatever you need. I hope you understand whole concept, how Locus handle these maps. I expect then this will not change in future. Looks fast enough ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: mmcyklo on March 02, 2011, 12:42:08
Hi there,

seems to be very interesting.

BTW I have to come with the results of testing huge maps:

 - CZSK with relief full resol
 - 25 files each zoom separately (z1-13), zooms 14 and 15 in few parts less than 2 GB
 - in total 10GB !
 - initialisation very slow (also with white screen) - 20 min
 - but after initialisation very fast and I must say ecxelent (only now it is initialisation every time when Locus is opened but only for 1-2 sec, so no problem).

So thanks a lot menion for this module "Separate map (SQL type)", and of course for the whole app!!!
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 02, 2011, 13:04:34
Yes, it's exactly as I wrote. Initializing takes too much time. It have to be done with some help of external file.

You have initializing maps every start? That means that you have any file in maps directory that have some problem with initializing. You have file in maps directory but missing in list of offline maps! Check it ...

and thanks for tests! This show that whole system works fine only needs some small improvements. Fine fine ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: ykf on March 03, 2011, 04:58:03
I never worked on sqlite, and after I go though the usage of it, it seems that if you have a zoom level which across several db files, you need to have multiple connections to query for that zoom level and consolidate the result sets together. This is not very efficient is it? Is there any chance to split db files based on x instead of z? This of course depends on your querying needs on Locus, I dunno how you query the files of course  :lol:

Btw, I'm looking at the MOBAC source code and seems I can add a new atlascreator impl, although I guess MOBAC authors will not be too happy on that because I saw them rejecting your new format requests on their forum... :oops:
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: mmcyklo on March 03, 2011, 09:04:36
Hi there,

I am continuing testing of huge files and I have one questions:

This 2GB limitaion is exactely 2GB or 2 000 000 000 B or 2 000 000 kB or 2 000 MB?

Thx
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 03, 2011, 13:20:49
Quote from: "ykf"I never worked on sqlite, and after I go though the usage of it, it seems that if you have a zoom level which across several db files, you need to have multiple connections to query for that zoom level and consolidate the result sets together. This is not very efficient is it? Is there any chance to split db files based on x instead of z? This of course depends on your querying needs on Locus, I dunno how you query the files of course  :lol:

Btw, I'm looking at the MOBAC source code and seems I can add a new atlascreator impl, although I guess MOBAC authors will not be too happy on that because I saw them rejecting your new format requests on their forum... :oops:

Hmm, i don't think is unefficient to hold more connections at once. As wrote mmcyclo, there is no speed issue with actual system and I don't see reason, why this should be wrong. But I'm not and database expert. Anyway, splitting by Z (zoom) looks for me as best idea, and also easier to implement.

About MOBAC, yes I looked at this also but they, as you read, do not agree with adding support for big maps, so it's up on us :)

Anyway, nice photos on homepage ykf ;)

mmcyclo: I don't know exact value. It's question on any experienced Linux user who know limitations of this platform. But I expect limit at 2 147 483 648b ;)
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: skrz on March 03, 2011, 15:25:16
What program or procedure do you recommend to use for splitting a big SQL map?
I have 6GB .sqlitedb file, how should I split it?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 03, 2011, 15:33:52
there is actually no way how to do this. In this topic we discuss about developing such a tool ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: ykf on March 07, 2011, 16:02:26
Menion, thanks for your appreciation on my art!  :D

There is a problem on splitting by z... when one level zoom is too big, e.g. for those google map on zoom level 19, just the zoom file alone can be bigger than 2GB. Anyway I'll do the MOBAC modification on each zoom level first, and then we'll think of how to solve this problem later.
The good news is MOBAC is pretty easy to understand and change, although the design seems outdated... why don't they use maven?!  :roll:
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: ykf on March 08, 2011, 07:55:50
Menion, there's a question... will you still use the info table for the multi-db file implementation?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 10, 2011, 19:24:24
hi,
  sorry for late answer.No this table is mystery for me. Why should I want to know only first and last zoom when I need to know all zooms. Hmm, this brings me idea. What about creating this table as storage of zoom informations? Create there column named "zooms" which can contain just a string with zoom levels separated by ";", so for example "4;6;8;10". Hmm maybe I should use this also on created offline maps which will almost completely remove needed initialization because this is just one second task ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Mr Yod on March 17, 2011, 14:44:14
If a map file greater than 2GB doesn't work, why not reduce the dimension of the file itself?


Let me explain.
I made some tests using Mobile Atlas Creator making a map with the following features: google hybrid, 3x3 blocks with grid zoom 12 and zoom from 12 to 18 (not very big map, but big enough in storage terms).

I made that map using the "RMaps SQLite" option and the map file is 5.48GB (really HUGE for a map with an area of about 25km x 25km), then I made the same map using the "OruxMaps SQLite" option and the map file is 641MB (yes: 9 times smaller).

So: somehow the oruxmaps sqlite file is compressed and, in my opinion, some sort of compression could help both for the storage (less memory required) and for the use (the file can be opened).


EDIT: I looked at the MOBAC cache: google earth, google maps and google hybrid take 1.96GB of total space (1.78GB google earth, 1MB google maps and 179MB google hybrid); considering that I used the cache to make that map, how is possible that the rmaps sqlite file takes 5.48GB?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 17, 2011, 14:56:56
hey what is this? Really so big difference?? have to check :)

Anyway you can use bigger maps now, If you prepare them in small part, but I'm sure you know about it ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Mr Yod on March 17, 2011, 17:07:38
Quote from: "menion"hey what is this? Really so big difference?? have to check :)
There's the "MOBAC's cache issue" too, like I explained in my edit at the end of my previous post
I made another test: I deleted all the MOBAC's cache and downloaded again the same area I used for the previus tests to see how much memory would take the cache.
The results are the following:
google earth: 450MB
google hybrid: 57MB
total memory used: 508MB

So: how's possible that rmaps sqlite file takes over 5GB?
The same space is taken if I use the "TrekBuddy tared atlas" option (I wanted to see if a tar archive would have taken less space)

QuoteAnyway you can use bigger maps now, If you prepare them in small part, but I'm sure you know about it ...
yes, I know: I already read it.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: MedoMys on March 17, 2011, 17:42:44
If I understand correctly first post of this thread, I have to create a directory in the directory Locus/Maps, copy some SQLite maps (of size less then 2 GB) into it and it should look like as a one compact map. This is what I tried (directory ZM10k, maps Brno_ZM10k.sqlitedb and CeskyRaj_ZM10k.sqlitedb), but such maps are not visible in offline maps list. Am I doing something wrong?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 17, 2011, 17:48:37
no, you understand it correctly. you should see map named as your directory, so ZM10k. So, is there?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: MedoMys on March 17, 2011, 18:00:53
No. Both maps disapeared when I've moved it into subdirectory ZM10k (they've worked correctly before it), and there isn't any new map named ZM10k in offline list. Some manual settings needed ?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 17, 2011, 18:12:29
nono, no settings needed. Weird. Try to clear cache directory if you're using market version. Hmm this is really weird :)
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: MedoMys on March 17, 2011, 18:23:57
LocusCacheMap ? All subdirectories are empty now.
Tested function Empty cache in Locus also.
But the same behaviour.
Not Market version, I've version 0.9.28.9.

Edit: Testet both market versions, Free and Pro, unsuccessfull.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: MedoMys on March 18, 2011, 15:18:01
Any idea, how to solve it ?
I've tried test version 1.0.1 , reinitalized maps, but nothing has changed.
Last attempt - I've taken map created in Locus, made subdirectory and moved map into it. But this map has disappeared from the offline maps list after it.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 18, 2011, 15:21:56
this is really weird. May you just do some test? Just create two small maps of any area. Best same area but different zoom. And then put them into one directory. If this will not work, please send them to me on email or if they'll be bigger, then thanks to some service, rapidshare, dropbox, whatever ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: MedoMys on March 18, 2011, 15:36:13
Created 2 maps, moved to subdirectory, invisible ...
I've sent you these maps.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on March 18, 2011, 18:01:45
I'm stupid, sorry!! Problem is only two maps in directory. When you add third, all will works!!

Fixed and will be tomorrow in testing version ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: suamikim on April 13, 2011, 14:37:51
Hi there!

I've been following this thread with high interest and have an idea:

Have you ever considered supporting the AndNav-Format for stored offline-maps?
I know that the Geocaching-App GeOrg supports it and that mobac can create them too.

Because of the fact, that AndNav-Maps are based on single files (every tile in the map is represented by one file) there are some advantages towards the sqlite-database-files:


One disadvantage that i can think of is that the handling of so many single small files could be a problem for the performance. At least in comparison with databases I'm pretty sure that the performance would decrease a little but as much as i can tell GeOrg is able to handle large AndNav-Maps pretty well so either it's not really that big a deal with the performance or they have pretty good algorithms to handle those maps...

Finally I got to admit that I'm not too familiar with the design of your app and how much work it would be to support AndNav-Maps but maybe i was able to give you some new input and a new idea on how to solve the problem with bigger maps...

Thanks & best regards!
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: marlar on April 13, 2011, 15:57:28
Hi,

FYI, Locus can already handle a format much similar to what you describe. It is called TAR format and is also supported by mobac. Each tile is a different file just as you sketch above.

It works well and the performance is fine enough. The downside is that it takes ages to copy the files to the phone. Virtually hours for big maps as opposed to minutes for similar sqlite based maps. And if you want to the delete the maps from the phone, it takes ages too!

For that reason I prefer sqlite based maps.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on April 13, 2011, 17:04:22
I'll think about it later but as marlar say, there is no advantage with Andnav format! It slow, it takes too much disk space, it's really terrible to copy on card or delete. And do something like this just for "better" support for Georg? No thanks. If Georg use Locus map format, so just create few smaller maps (smaller then 2GB) and use them ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: suchuaato on April 14, 2011, 04:34:52
Hi Menion,
regarding rmaps, I set my RMaps directory to where the locus directory is and it did treat all of the maps as one big one,
 but currently I only have 1.9 GB of maps in 6 separate sqlitedb maps  so not over the total 2 gb limit yet,
am creating some more maps for locus will let you know what happens
Stuart

Quote from: "menion"Heh, 14GB seems to be good :) but unfortunately as you can see, this is not in my power!

so with this troubles, comes two questions!
1) which is maximum size allowed to read correctly and why is this limit!
2) is here any other solution on this problem? Maybe some special format with separated files working all together ...

anyway ... did anyone tried this huge maps on any other supported software how they handle them? RMaps for example ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: suamikim on April 14, 2011, 16:25:09
Ok, i just realized how much more disk-space those single files actually need then a single one. Therefore the AndNav-Format is no option for me neither ;(

But there's one question left for me:
How do you guys manage to create maps with mobac smaller than 2 GB. The problem for me is that the software doesn't display how large the resulting file would be.
The only way I can think of is to approximate the size by the number of selected tiles, but (obviously) 1 tile has not always the same size...

To clarify this a little bit I've just created 2 maps with a nearly similar number of tiles:

1. Center of London: 3546 tiles -> Resulting sqlite-db 56,7 MB (approx. 16,6 Bytes per tile)
2. Somewhere in Panama (partly city, partly forest): 3592 tiles -> Resulting sqlite-db 10.7 MB (approx. 3 Bytes per tile)

How do i know now before creating the map how to choose the zoom-levels and the size of the selected region to not exceed the 2 GB limit in the resulting file?
Trial and error is definitely not the way to go because on one hand the download of large maps with mobac takes pretty long and on the other hand it produces a lot of trafic on the servers...

Thanks, for every advice on this topic!
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: xxc on May 27, 2011, 11:09:32
Hi Menion,
What appends if the cached map files (the ones in locus/mapsOnline ) become bigger than 2Gb ?
One of my file is growing and will soon reach 2Gb!
Thanks
Vincent
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on May 27, 2011, 11:30:11
hi,
  very probably will stop works correctly. When android send request to SQLite database bigger then 2GB, I noticed that there is big chance that this call return no tile, random tile, correct tile ... never now. If you have cached some area and want to use it still, move this cached map to offline "maps" directory (just a suggestion). Anyway I tested it with A2.1. Maybe something changed since that so you can try to keep copy of this file in mapsOnline also and let me and others know, how this works with bigger files on newer system
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: xxc on May 27, 2011, 12:16:58
Ok thanks ! I'll do a "backup" to the offline maps directory and try to keep a copy on mapsOnline.
We'll see :)
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Jens21 on April 23, 2012, 12:44:02
Hi,
now I have the same problem, I download a Outdoor Active map step by step over a few weeks. Now is my file size over 2GB. Is it possible zu reduce the file size? I don´t want to download the map new.
Why is there no message when the size goes over 2GB?

The file in the online Map directory is working, but this is not a good solution.

Best regards
Jens21
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on April 23, 2012, 13:03:41
Hi Jens,
  I already read you email. Sorry but I have no idea how to simply remove some part of map from file. It's a basic SQLite database so If I have same problem, I'll download for example extension to firefox (SQLite manager) and manually delete some lines and rows by executing SQL query.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Jens21 on April 30, 2012, 20:46:55
Hi,
thank you for your answer, I done it, and it works. So far so god.

But now I have a new problem.
I use one SQL File for a complete map of Germany, but only a few zoom levels.
And I had a different SQL file with a map with more zooms level of my home area.
Normally when I select the Germany file, I zoom in the map, Locus change automatically to the other SQL File.
This function doesn´t work since a few days.
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: prawns on October 10, 2013, 02:11:01
Is the 2gig map limit still a issue?

Im new to Locus but have maps I downloaded myself using MOBAC up to 2.7gig in size,  but I have no issues here at all with loading or viewing them so far

The first time I load Locus with a 2gig+ new map copied to /map on my SDcard it took about 40seconds to load up, but after the very first run is done with a new map the loading speed of locus returns to normal (seconds)

Is the 2gig limit a "non issue" now or perhaps I might get issues later?

So far locus has handled it all beautifully with a few 2+gig maps placed in the same directory /maps/googlehybrid running fine here.  Mind you I had to hack MOBAC 1.9 to get google hybrid maps back in the list and I cant seem to figure out how to get Microsoft Hybrid in the MOBAC list after following instructions :(

PS the image verification on here is really bad. I cant read it. It wont let me listen to the letters either unless I download the audio file manually - but the audio file sounds the same for alot of letters (B sounds like Z sounds like V sounds like C sounds like E)

Im thinking about half the people give up in frustration trying to post?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on October 10, 2013, 06:31:22
Hi,
  if map works fine for you, then there will be no problem with 2GB limit even in future. This problem is related on to Android 2.X, not to new 4.X+ versions (there should be on some devices problem with 4GB+ maps).

  And captcha - seems this forum gets quite a lot of attention from some automatic spambots, so increasing complexity of captcha was only was to stop it for now
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: prawns on October 10, 2013, 06:39:33
Thanks for the quick reply :)

I managed the captcha on the sign up page, but for some reason it asked me another captcha the first time I tried replying to a topic,  Maybe I had too many tabs open and firefox got confused as this reply seems ok without a captcha lol  ;D

Its good to hear I should be good for -->4gig maps on my note2 (4.1.2 jellybean i think)

Locus is the best program Ive ever used for doing maps on a device and Ive tried literally dozens using iphones and androinds (including a hema 4wd atlas one which cost me AU$150 compared to locus at AU$9)  Well done mate Top job :)
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: ch3ch2o6 on October 10, 2013, 14:18:40
Hello menion,
I'm not sure that we can't use file over 2 Gb in android :
I have the same surface in differents scales (a big part of France from geoportail, in MTB) from scale 12 to scale 16.
Scale 15 : 2 Gb, scale 16 : 5 Gb.
In Locus, all scales are ok without scale 16 because of the "limit" of 2 Gb.
In another .apk (from Spain), I can use the sames maps (the maps are in one directory only) and I can open without problem all the maps, the scale 16 also !
Do you know why ?
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: Menion on October 10, 2013, 17:45:10
"another .apk from Spain" ... funny :). Orux isn't prohibited word on this forum if you mean this app. I was very pleasantly convinced of the quality of that app and also it's developer. Shame he's not from Prague, then we should make one app together :). Anyway back to topic ...

In older androids, there were problems with size over 2GB, so I had in Locus protection for adding such huge maps. Later I increased this limit to 4 GB for Android 4.0+ devices, but during a few months, your another persona who write me that also 4+ GB maps works on Android, but Locus still! have set 4 GB limit. So that's the problem

I'll remove this limitation to next version of Locus as it seems to have no more need ...
Title: Re: [MANUAL] - using SQL map files bigger then 2GB
Post by: ch3ch2o6 on October 10, 2013, 21:21:31
Hello menion,
Thanks for the answer.
I'm still waiting for this version.
For the .apk of Spain, maybe Orux or TwoNav ?
You are right, it is Orux.