MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
4 posters
MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
Hello,
It's my first post on the forum. I'd like to greet.
I have the problem with maps produced by Mobile Atlas Creator in sqlite format. I tried to change bits with OruxMapsDesktop but without success (tested also 0101 and 0202 bits).
They are not readed by OruxMaps on my samsung dev (with datatbase set on bits. 0101) or not displayable (with datatbase set on bits. 0202).
Spec:
- Ubuntu 12.04
- MOBAC ver. - 1.9.7,
- java api sqlite-jdbc: sqlite-jdbc-3.7.2.jar (newest one downloaded from http://code.google.com/p/sqlite-jdbc/)
Dev:
- OruxMaps ver. 5.0 (the latest from googleplay)
- Android - GINGERBREAD kernel 2.6.35.7
- device Samsung GT-I9001
Is it possible, that the problem comes from inappropriate version of sqlite-jdbc library?
greeting
Przemo
It's my first post on the forum. I'd like to greet.
I have the problem with maps produced by Mobile Atlas Creator in sqlite format. I tried to change bits with OruxMapsDesktop but without success (tested also 0101 and 0202 bits).
They are not readed by OruxMaps on my samsung dev (with datatbase set on bits. 0101) or not displayable (with datatbase set on bits. 0202).
Spec:
- Ubuntu 12.04
- MOBAC ver. - 1.9.7,
- java api sqlite-jdbc: sqlite-jdbc-3.7.2.jar (newest one downloaded from http://code.google.com/p/sqlite-jdbc/)
Dev:
- OruxMaps ver. 5.0 (the latest from googleplay)
- Android - GINGERBREAD kernel 2.6.35.7
- device Samsung GT-I9001
Is it possible, that the problem comes from inappropriate version of sqlite-jdbc library?
greeting
Przemo
reeb- Cantidad de envíos : 2
Fecha de inscripción : 2013-01-06
Re: MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
reeb wrote:Hello,
It's my first post on the forum. I'd like to greet.
I have the problem with maps produced by Mobile Atlas Creator in sqlite format. I tried to change bits with OruxMapsDesktop but without success (tested also 0101 and 0202 bits).
They are not readed by OruxMaps on my samsung dev (with datatbase set on bits. 0101) or not displayable (with datatbase set on bits. 0202).
Spec:
- Ubuntu 12.04
- MOBAC ver. - 1.9.7,
- java api sqlite-jdbc: sqlite-jdbc-3.7.2.jar (newest one downloaded from http://code.google.com/p/sqlite-jdbc/)
Dev:
- OruxMaps ver. 5.0 (the latest from googleplay)
- Android - GINGERBREAD kernel 2.6.35.7
- device Samsung GT-I9001
Is it possible, that the problem comes from inappropriate version of sqlite-jdbc library?
greeting
Przemo
Hi;
Have you tested with small maps?
Create one small map, with few tiles; if it does not work, please send to -->oruxuro@gmail.com
orux
orux- Cantidad de envíos : 3946
Fecha de inscripción : 2009-07-06
Re: MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
Hi
I have tested various sets of maps of different size, as you mentioned.
Generally there is no problem with small one (several mb). With bigger smetimes occur the problem as described above. After removal of cached data - gathered by MOBAC and starting the poroces of map generation again, smometimes in few attempts it is possible to obtain map without faults.
I have successfuly prepared maps from google server and OSM.
Maybe the problem is with quality of data downloaded and cached by MOBAC.
Przemo
I have tested various sets of maps of different size, as you mentioned.
Generally there is no problem with small one (several mb). With bigger smetimes occur the problem as described above. After removal of cached data - gathered by MOBAC and starting the poroces of map generation again, smometimes in few attempts it is possible to obtain map without faults.
I have successfuly prepared maps from google server and OSM.
Maybe the problem is with quality of data downloaded and cached by MOBAC.
Przemo
reeb- Cantidad de envíos : 2
Fecha de inscripción : 2013-01-06
Re: MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
Well, I'm not into the dev stuff, but I know the format database sqlite used by orux.
There is only 4 fields:
-coordinates X
-coordinates Y
-zoomlevel (1 to 20)
-data blob (which is a just a PNG/JPG)
(not sure of the sorting order)
So If you know how to do it, you can open the DB and extract the BLOB of a random row, and see if it is a valid PNG. it should be.
If you suspect some tiles to be faulty, you can extract them this way, and read the BLOB.
I troubleshooted some problems with maps before like that. In my case, instead of a map PNG, I had a blank PNG.
Mind you, for really big maps, using the sqlite3.exe command-line tool was the most efficient way. it is really fast. other GUI software tries to load the DB in memory, bringing the whole system down in the process.
Some maps servers don't allow too many requests in a short time span.
It can work for small amount of data (small maps), but they will silently fail during heavy downloading. If you suspect it is the case, try slowing down your connection speed ,
Or, what I did, download multiple small maps separatly, and merge the DBs into one with SQLite3 tools.
There is only 4 fields:
-coordinates X
-coordinates Y
-zoomlevel (1 to 20)
-data blob (which is a just a PNG/JPG)
(not sure of the sorting order)
So If you know how to do it, you can open the DB and extract the BLOB of a random row, and see if it is a valid PNG. it should be.
If you suspect some tiles to be faulty, you can extract them this way, and read the BLOB.
I troubleshooted some problems with maps before like that. In my case, instead of a map PNG, I had a blank PNG.
Mind you, for really big maps, using the sqlite3.exe command-line tool was the most efficient way. it is really fast. other GUI software tries to load the DB in memory, bringing the whole system down in the process.
Some maps servers don't allow too many requests in a short time span.
It can work for small amount of data (small maps), but they will silently fail during heavy downloading. If you suspect it is the case, try slowing down your connection speed ,
Or, what I did, download multiple small maps separatly, and merge the DBs into one with SQLite3 tools.
yip- Cantidad de envíos : 40
Fecha de inscripción : 2012-01-21
Re: MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
Hi Yip,
Could you expand on how to merge the DBs into one using the SQLite3 tools?
A problem I'm trying to eliminate is the blue border around offline maps. I have adjoining maps that are exactly the same projection and abut directly beside each other. I'd like to effect a seamless transition as the cursor travels across one image to the next without the blue border.
Is this possible with merged DBs?
Could you expand on how to merge the DBs into one using the SQLite3 tools?
A problem I'm trying to eliminate is the blue border around offline maps. I have adjoining maps that are exactly the same projection and abut directly beside each other. I'd like to effect a seamless transition as the cursor travels across one image to the next without the blue border.
Is this possible with merged DBs?
Icarus- Cantidad de envíos : 104
Fecha de inscripción : 2011-04-03
Re: MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
I've posted something a while ago about merging DB:
Well, I'm not sure if it apply to your request.
https://oruxmaps.forumotion.com/t2048-merge-layout-map-in-create-offline-mode
As orux said in the thread, Mobac should do it but I didn't knew it at the time ...
This was easily done because :
1- both offline maps covers the same area
2- they were on different zoomlevels.
I had a mix of OVImaps (nokia) and google maps, with even zoomlevels beeing Google maps and odd zoomlevels beeing OVImaps.
Icarus, I'm not sure I understand correctly,
you would like that, when moving near the border of a map, the adjacent map should be preloaded, for displaying its accross-the-limit tiles ?
that would mean 2 maps would be loaded, at the same time, by the software, not talking about the corners where 4 maps would be loaded
One option would be a new behavior for the autoload feature. when nearing a map edge, it would load the next map right away. that is, before effectively crossing the edge.
that would only work with maps that overlaps each others.
Another workaround is to merge all your maps into one, no more transitions problems . If MOBAC or other software can't do it, it can be done manually, with SQL and heavy XML editing.
That involve some calculations about the maps boundaries, recalculating indexes...
For it to work best, all the maps to be merged have to be ordered in a really clean grid pattern. no overlapping, stricly continguous, exactly the same structure ...
It's easier to make a brand new, bigger map from scratch ...
Well, I'm not sure if it apply to your request.
https://oruxmaps.forumotion.com/t2048-merge-layout-map-in-create-offline-mode
As orux said in the thread, Mobac should do it but I didn't knew it at the time ...
This was easily done because :
1- both offline maps covers the same area
2- they were on different zoomlevels.
I had a mix of OVImaps (nokia) and google maps, with even zoomlevels beeing Google maps and odd zoomlevels beeing OVImaps.
Icarus, I'm not sure I understand correctly,
you would like that, when moving near the border of a map, the adjacent map should be preloaded, for displaying its accross-the-limit tiles ?
that would mean 2 maps would be loaded, at the same time, by the software, not talking about the corners where 4 maps would be loaded
One option would be a new behavior for the autoload feature. when nearing a map edge, it would load the next map right away. that is, before effectively crossing the edge.
that would only work with maps that overlaps each others.
Another workaround is to merge all your maps into one, no more transitions problems . If MOBAC or other software can't do it, it can be done manually, with SQL and heavy XML editing.
That involve some calculations about the maps boundaries, recalculating indexes...
For it to work best, all the maps to be merged have to be ordered in a really clean grid pattern. no overlapping, stricly continguous, exactly the same structure ...
It's easier to make a brand new, bigger map from scratch ...
yip- Cantidad de envíos : 40
Fecha de inscripción : 2012-01-21
Re: MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
Thanks Yip,
Yes - the behaviour I need is that, when moving near the border of a map, the adjacent map should be preloaded, displaying its across-the-limit tiles. This is for an aviation application where crossing maps happens regularly and the OruxMaps blue edge is unacceptable.
Yes - that would mean 2 maps would be loaded, at the same time, by the software, and possibly 4 maps would be loaded at corners.
I realise this can't happen in OruxMaps due to the limited memory of Android devices, but Orux's database format is the best option to merge the coverage I need.
The 50 maps I have are about 430Mb each in .png format. They have no overlaps and abut each other exactly on lines of latitude and longitude. All have exactly the same projection ('unprojected' - latitude/longitude) and all are WGS84. They have exactly the same scale in terms of pixels/degree. They also have continental coverage in an ordered grid pattern.
The problem I have with joining them is that I have problems with Windows memory if lots of 430Mb .png are joined.
In OruxMaps Desktop, a single 430Mb .png reduces to an 87Mb SQLite database with 85% JPEG format.
So my intention is to process them individually with OruxMaps Desktop and do the merge of the SQLite databases into a single .db. This avoids the problem of a multi-gigabyte .png to process by OruxMaps Desktop.
I understand the XML format and am confident I will be able to do the heavy XML editing when joining adjacent map files.
What I don't understand is how to merge the .db files?
Yes - the behaviour I need is that, when moving near the border of a map, the adjacent map should be preloaded, displaying its across-the-limit tiles. This is for an aviation application where crossing maps happens regularly and the OruxMaps blue edge is unacceptable.
Yes - that would mean 2 maps would be loaded, at the same time, by the software, and possibly 4 maps would be loaded at corners.
I realise this can't happen in OruxMaps due to the limited memory of Android devices, but Orux's database format is the best option to merge the coverage I need.
The 50 maps I have are about 430Mb each in .png format. They have no overlaps and abut each other exactly on lines of latitude and longitude. All have exactly the same projection ('unprojected' - latitude/longitude) and all are WGS84. They have exactly the same scale in terms of pixels/degree. They also have continental coverage in an ordered grid pattern.
The problem I have with joining them is that I have problems with Windows memory if lots of 430Mb .png are joined.
In OruxMaps Desktop, a single 430Mb .png reduces to an 87Mb SQLite database with 85% JPEG format.
So my intention is to process them individually with OruxMaps Desktop and do the merge of the SQLite databases into a single .db. This avoids the problem of a multi-gigabyte .png to process by OruxMaps Desktop.
I understand the XML format and am confident I will be able to do the heavy XML editing when joining adjacent map files.
What I don't understand is how to merge the .db files?
Icarus- Cantidad de envíos : 104
Fecha de inscripción : 2011-04-03
Re: MOBAC 1.9.7, OruxMaps 5.0, Samsung Dev - problem with SQlite database format
Icarus wrote:Thanks Yip,
Yes - the behaviour I need is that, when moving near the border of a map, the adjacent map should be preloaded, displaying its across-the-limit tiles. This is for an aviation application where crossing maps happens regularly and the OruxMaps blue edge is unacceptable.
Yes - that would mean 2 maps would be loaded, at the same time, by the software, and possibly 4 maps would be loaded at corners.
I realise this can't happen in OruxMaps due to the limited memory of Android devices, but Orux's database format is the best option to merge the coverage I need.
The 50 maps I have are about 430Mb each in .png format. They have no overlaps and abut each other exactly on lines of latitude and longitude. All have exactly the same projection ('unprojected' - latitude/longitude) and all are WGS84. They have exactly the same scale in terms of pixels/degree. They also have continental coverage in an ordered grid pattern.
The problem I have with joining them is that I have problems with Windows memory if lots of 430Mb .png are joined.
In OruxMaps Desktop, a single 430Mb .png reduces to an 87Mb SQLite database with 85% JPEG format.
So my intention is to process them individually with OruxMaps Desktop and do the merge of the SQLite databases into a single .db. This avoids the problem of a multi-gigabyte .png to process by OruxMaps Desktop.
I understand the XML format and am confident I will be able to do the heavy XML editing when joining adjacent map files.
What I don't understand is how to merge the .db files?
Hi;
It's not easy because you have to know SQL. You also have to modify the indexes of the images.
And the original PNG must have a size multiple of 2 (128, 256, 512, 1024, ...) so that the resulting calibration map is correct.
The easiest is to have slightly overlapping maps. Still not working, but soon changing the xml (the values of max/min lon/lat) you can force to Oruxmaps to load a new map before you see the blue zone.
orux
orux- Cantidad de envíos : 3946
Fecha de inscripción : 2009-07-06
Similar topics
» Create map for oruxmaps from png to a single sqlite database
» How to create a single OruxMaps sqlite database from multiples ozi files?
» RMaps sqlite to OruxMaps sqlite conversion
» Unable to open maps in sqlite format
» Performance and size of sqlite database file
» How to create a single OruxMaps sqlite database from multiples ozi files?
» RMaps sqlite to OruxMaps sqlite conversion
» Unable to open maps in sqlite format
» Performance and size of sqlite database file
Permissions in this forum:
You cannot reply to topics in this forum