How to get smooth scrolling between adjacent map tiles?

I have numbers of adjacent (topographical) maps in the maps directory. They originate from the Finnish topographical maps database which was fully opened to public access last summer. My problem is that OM only shows the map tile with the current position. When approaching the border of the map, half of the screen is empty. When crossing the border, OM correctly switches onto the next map - having the the other half of the screen empty in turn. Is there a solution for handling this kind of problem already? Maybe a parameter in the settings that I haven't found or understood? Or a way of combining those map tiles to one larger map? OruxMaps is currently THE greatest map application available for any smart phone! Excellent work, thank You! --Kari

I'm fairly sure this is an inherent limitation with OruxMaps. I believe Orux was trying to solve the issue but hasn't found a way around Android memory limitations.

I'd be very happy to be corrected, as this limitation is a significant issue for aviation users where transitions across map boundaries happens regularly.

Orux - you mentioned that overlapping maps might be supported in a future release? Is this still on the horizon?

Overlapping map support might provide a work-around to this issue as you could create 'strips' over the top of map boundaries to have seamless map transitions. It would involve a bit of mucking about in Photoshop to create the strips, but at least the empty screen would be alleviated.

Icarus wrote:I'm fairly sure this is an inherent limitation with OruxMaps. I believe Orux was trying to solve the issue but hasn't found a way around Android memory limitations.

I'd be very happy to be corrected, as this limitation is a significant issue for aviation users where transitions across map boundaries happens regularly.

Orux - you mentioned that overlapping maps might be supported in a future release? Is this still on the horizon?

Overlapping map support might provide a work-around to this issue as you could create 'strips' over the top of map boundaries to have seamless map transitions. It would involve a bit of mucking about in Photoshop to create the strips, but at least the empty screen would be alleviated.

Hi,

I promise I will implement a solution for the next to the next version (out in a few days).

orux

Icarus wrote:I'm fairly sure this is an inherent limitation with OruxMaps. I believe Orux was trying to solve the issue but hasn't found a way around Android memory limitations.

I'd be very happy to be corrected, as this limitation is a significant issue for aviation users where transitions across map boundaries happens regularly.

Orux - you mentioned that overlapping maps might be supported in a future release? Is this still on the horizon?

Overlapping map support might provide a work-around to this issue as you could create 'strips' over the top of map boundaries to have seamless map transitions. It would involve a bit of mucking about in Photoshop to create the strips, but at least the empty screen would be alleviated.

Two quick solutions meanwhile we wait for a true smooth navigation between maps:


1.-add a margin of xx pixels for all the maps. OruxMaps will open a new map before reaching the end. This needs overlapped maps. It will force that behaviour for all maps and all layers.

2.-add an attribute to the otrk2.xml file (the calibration file of the maps) with a specific margin for a map or layer. It will not work with maps without otrk2.xml file (garmin, rmap,...)

I think I am going to add both options in next to next release (I want to release current beta today/tomorrow).

orux

This would solve my problem of large maps (https://oruxmaps.forumotion.com/t3183-how-can-i-calibrate-really-large-maps) by letting me split them into much smaller chunks. It'd make map management easier too by allowing easier selection of chunks to copy to a device without having to rebuild a db to change the area (or just have the entire lot which would be too large to fit on most devices).

Another possible way that might work - linking maps in otrk2.xml by adding pointers to all the maps that surround it e.g. add attributes NextMapNorth, NextMapEast, NextMapNorthEast, etc. Just containing the name of the next map so you reach the edge of the map you know where to look for the next tiles. This would work well for maps that are split into regular square pieces at least.

Richard.

p.s. is it possible to use a tile size of anything other than 512x512? My tiles are not multiples of 512 so dividing up the map and labelling the resulting map pieces would get messy. 500x500 would work much better. I haven't tested to see if orux can handle that but I might give it a go tomorrow.

rab wrote:This would solve my problem of large maps (https://oruxmaps.forumotion.com/t3183-how-can-i-calibrate-really-large-maps) by letting me split them into much smaller chunks. It'd make map management easier too by allowing easier selection of chunks to copy to a device without having to rebuild a db to change the area (or just have the entire lot which would be too large to fit on most devices).

Another possible way that might work - linking maps in otrk2.xml by adding pointers to all the maps that surround it e.g. add attributes NextMapNorth, NextMapEast, NextMapNorthEast, etc. Just containing the name of the next map so you reach the edge of the map you know where to look for the next tiles. This would work well for maps that are split into regular square pieces at least.

Hi,

This is not necessary, if you have enabled autoload map feature, OruxMaps will load the next map automatically.

rab wrote:
p.s. is it possible to use a tile size of anything other than 512x512? My tiles are not multiples of 512 so dividing up the map and labelling the resulting map pieces would get messy. 500x500 would work much better. I haven't tested to see if orux can handle that but I might give it a go tomorrow.

OM only works with 128, 256 & 512 tile sizes. Working with powers of two has many advantages.

orux

orux wrote:This is not necessary, if you have enabled autoload map feature, OruxMaps will load the next map automatically.

I have auto load set to when it reaches the edge of the map, but it doesn't display the next map until you are actually on to it (only shows tiles from one database at a time). Setting auto load to "always(caution)" doesn't work well at all, when you move to the edge of the map you often get thrown to the centre of it (I guess that's what the caution is about).

orux wrote:OM only works with 128, 256 & 512 tile sizes. Working with powers of two has many advantages.

Shame, as OS maps in the UK are in tiles that are not divisible by 512. It wouldn't be a problem to have a white border on 2 edges of the map to makes the tiles up to the next 512 boundary, so long as it's not counted as part of the map i.e. not displayed to the edge of it. If you can get the next map showing when you approach the edge of the map (rather than just when you reach it) you would need to overlay the white border with real map from the next database.

Richard.

I am not familiar with Android development, but I am programmer, and I do not get what is problem with memory limitation.

I hope OruxMaps does not load whole map in memory but only tiles needed for display? It that is the case, then size of map is not important as it never gets loaded as a whole.

pedja wrote:I hope OruxMaps does not load whole map in memory but only tiles needed for display? It that is the case, then size of map is not important as it never gets loaded as a whole.

Of course that's how it works. The problem is that 1 single large map database many gb in size is a pain to work with for the user and large maps cannot be calibrated accurately because each map only has 4 calibration points. Therefore splitting large maps into several/many smaller ones is necessary.

I think it is not good approach if you make decision for users. If map is to large to manipulate or to be properly calibrated that should be users problem.

To be truthful, I had no problem with OruxMaps limitation. I usually reach limitations of bitmap image format I have to prepare map into, to convert it in Oruxmaps.

Maybe you can introduce some kind of map set, group of maps that are subjected to be used a single map. That would allow each map to be calibrated independently, but when transiting from one to another, Orux might display them as single map.

Once I asked about option that Orux load locally saved tiles in the same manner as online maps (url just has to be file://) as that would allow us to use large maps but you said that is not possible.

pedja wrote:I think it is not good approach if you make decision for users. If map is to large to manipulate or to be properly calibrated that should be users problem.

To be truthful, I had no problem with OruxMaps limitation. I usually reach limitations of bitmap image format I have to prepare map into, to convert it in Oruxmaps.

Maybe you can introduce some kind of map set, group of maps that are subjected to be used a single map. That would allow each map to be calibrated independently, but when transiting from one to another, Orux might display them as single map.

Once I asked about option that Orux load locally saved tiles in the same manner as online maps (url just has to be file://) as that would allow us to use large maps but you said that is not possible.

Hi;

There is a beta where you can play with the map margins-->www.oruxmaps.com/cs

Using overlapping maps, with an adequate margin should not have problems with transitions, if the maps are not very small.

If all the offline maps were using the google tile system, no problem to make a continuous map, but maps and projections can be as diverse, which should reproject each map, and this is a very difficult task and heavy.

orux

If all the offline maps were using the google tile system, no problem to make a continuous map, but maps and projections can be as diverse, which should reproject each map, and this is a very difficult task and heavy.

If I could have option to load google/osm tiled map from local storage, then I would not have need to have overlaping maps. I would create single tiled map that covers whole area.

pedja wrote:I think it is not good approach if you make decision for users. If map is to large to manipulate or to be properly calibrated that should be users problem.

Not trying to impose anything, looking for more options not less.

pedja wrote:To be truthful, I had no problem with OruxMaps limitation. I usually reach limitations of bitmap image format I have to prepare map into, to convert it in Oruxmaps.

That's probably why you don't see the issue. I'm working with maps 280,000 x 520,000 pixels in size (you don't create that as a single bitmap first!).

pedja wrote:Maybe you can introduce some kind of map set, group of maps that are subjected to be used a single map. That would allow each map to be calibrated independently, but when transiting from one to another, Orux might display them as single map.

That's exactly what's being asked for in this thread (as I understand it). The ability to have multiple maps that are displayed as one seamless maps. I.e. when the edge of your current map would be visible on screen (and you currently get purple background) tiles from another map covering that area are displayed so you are unaware that reaching the edge of the map and you just smoothly move to the next.

orux wrote:There is a beta where you can play with the map margins-->www.oruxmaps.com/cs

Using overlapping maps, with an adequate margin should not have problems with transitions, if the maps are not very small.

Sorry for the slow reply, I was on holiday.

I've had a play with the beta version and I can't work out what it does. It still only displays one map at a time, when I reach the edge of the map I get the purple background until I have actually moved the centre of the screen off the edge of the map to the purple, then it displays the new maps (but not the old one as well, so the other half of the screen then goes purple). No amount of playing the the new margin option seems to do anything as far as I can tell.

rab wrote:I'm working with maps 280,000 x 520,000 pixels in size (you don't create that as a single bitmap first!).

How do you manage that? I also have large maps but I cannot move them to OruxMaps as they are too big to save as single bitmap image.

I've written my own tooling to produce oruxmaps sqlite database files directly from sets of map tiles. Unfortunately you can't accurately calibrate a map that size in oruxmaps because you only get 4 corner points for calibration, so the maps need to be divided into much smaller chunks anyway. So while I can easily produce maps that are very large they aren't useful if they are above a certain size (and that's the issue I'd like to see a solution for).

At the moment we have these options for working with large maps:
1) very large single map that isn't accurately calibrated, but does work as single map (you can go from coast to coast without ever seeing the purple background)
2) multiple smaller maps which are much easier to manage (don't need to take the entire map, if for example space on your device is limited, easier to update just a part of the map without having to work with a 10gb sqlite db), but when you are reaching the edge it of an area you get half a screen of purple background instead of displaying the next map before you actually reach it

I'd prefer option 2 to be fixed rather than option 1, because of the ease of working with smaller areas and files. I think option 2 would be easier to fix that than option 1 as well, as large maps would need a lot of calibration points to be useful and I think managing them (for the map maker and oruxmaps) would be quite complicated.

Hmm, that tool would be interesting to try out. Not that for large maps but for an option to transform TileMap to OruxMap. That is what I am missing from the first try of OruxMapsDesktop.

Hi there. I've been a way for quite some time from this forum - using Oruxmaps all the time though. Any good solution to this challenge of handling large maps yet? I guess this is the biggest shortcoming of Oruxmaps at the moment. For me at least as well as a number of other fellow users - that are not on this forum though. Here's one thing I'm wondering. A proper solution must definitely rely on a tiling type of approach, one way or the other. Handling of indefinitely large maps in single files is not the way go. Well, as far as I understand OM is already using some kind of "tiling approach" internally. Is it hard to apply this same approach - maybe even same code - on a higher level as well? Maybe apply it to maps in one single directory.

Unfortunately the thread has gone quiet. However, we really do need a solution to this problem, currently oruxmaps is only useful for small maps.

I trust that there's a solution under work to overcome this major limitation since the author said so.