Messages

Huh, I like! When changing the zoom level, the line can reach even several 100 km - that should be good enough :-)

Now, the icing on the cake would be if there would be a button I could add to the sidebar menu to toggle triangle and line quickly - for most of the time the triangle is less intrusive.

Thanks for making me aware!

Hi Tronpo,

thanks for sharing your view!

I guess the best would be if I had the option to choose the behaviour I prefer.

The reason/use case for having the triangle at the cursor is the following: I am hiking, a track is recorded (so no option to switch off GPS), and I see in the far distance a tower. I want to know what tower that is, and start moving my map in the direction of sight. In the past, I had the triangle to make sure I stayed on the line of sight, even when I pan so far away that the GPS position is no longer on screen. Now, with moving the map further and further, chances increase that I diverge from the line of sight, eventually missing the tower on my map. Believe me, it is difficult enough to stay on the line of sight even with the triangle :-)

My suggestion: Let user's choose what they want to have, based on a setting in the preferences, or with a button in the toolbars.

Hi all,
I use the yellow triangle that shows the direction of view, i.e. where the phone points to, based on the internal compass.
Today I realized that two things changed:

• The triangle now has a colored border, where the border color seems to indicate GPS state and track recording
• When I pan the map, there's acursor that is connected to the GPS position by a line. In the past, the view direction triangle followed the cursor. Now it sticks to the GPS position.

I'm not sure if this is due to the recent OruxMaps GP update, or if I accidentily changed a setting. I fail to find that setting, or any setting that changes the behaviour of the triangle back to its previous functionality.

With the color border I could live (although admittedly I do not like it), but the triangle not following the curser is really bad.

Please advise how to switch back - thanks!!!

Big writeup finally done - find it in my Blog! Any comments very welcome!

Sure, here are the steps:

1. Install Mobile Tile Server - as of this writing you'll need to take the APK from the Github page - as soon as the new release has passed the Google checks, it should be available via Google Play.
2. If you have your mbtiles files in the OruxMaps offline maps directory, and there in a subdirectory (that's how I do it), you'll need to rename the subdirectory to "mbtiles". Mobile Tile Server expects all mbtiles files it can serve in a directory named mbtiles. If you do not want to change your OruxMaps directory, you'll need to create a separate directory and copy the mbtiles files there.
3. Configure Mobile Tile Server to serve data from the OruxMaps mapfiles directory, or, alternatively, from the directory you created. So if your directory containing the mbtiles files is named /storage/myfiles/mbtiles/, you need to configure Mobile Tile Server's root directory as /storage/myfiles/. For this, navigate to the settings of Mobile Tile Server and tap on "Tiles root directory path". Unfortunately there is no directory browser, you need to type the path – so as a preparation make sure you have this path at hand, e.g. by looking into the OruxMaps configuration.
4. Configure background activity of Mobile Tiles Server: To make sure that the Mobile Tile Server runs in the background and keeps running, you need to adjust the Android power settings of the App to "Unrestricted".
5. Change the <YourMap>.map.json files to use Mobile Tile Server. The URL for mbtiles access of the Mobile Server is http://localhost:1886/mbtiles/YourMap.mbtiles/{z}/{x}/{y} – so your .map.json-files need all URLs that currently are http://localhost:8998/YourMap.mbtiles/{z}/{x}/{y}.pbf changed to http://localhost:1886/mbtiles/YourMap.mbtiles/{z}/{x}/{y}

Now, before loading the map in OruxMaps, be sure that you started the Mobile Tile Server app and that you clicked on "Start" in it.

...and this will be my last post on this topic for the time being, workaround established:

The Author of Mobile Tile Server, Bogdan Hristozov, was so friendly to work again on his software and fix the issue with the vector tiles - 1000 thanks to him! Now I can use the vector mbtiles in OruxMaps via the Mobile Tile Server, and I can confirm, that this is stable even when sending OruxMaps in the background. That, for the time being, solves my problem, at the price to take care that the server is running when I am using Oruxmaps, but I guess I can now wait very well for this bug being fixed in OruxMaps.

For others that suffer from the same issue as me, i.e. want to use Mapbox format offline maps in mbtiles and have them stuck after putting OruxMaps into the background: Install Mobile Tile Server, configure it to serve your mbtiles files, and change the URL in the .map.json to http://localhost:1886/mbtiles/YOUR.mbtiles/{z}/{x}/{y}

It's me again - sorry for being a PITA :-)

The author of Mobile Tile Server was so nice to recompile his mbtiles android server for Android 13, and I got it up and running. It cannot serve vector tiles correctly, but since the error I describe also affects raster tiles, I used the exact same raster mbtiles file to once use it with OruxMaps builtin localhost:8998 server, and once via Mobile Tile Server (localhost:1886) with otherwise the same style JSON data.

With the OruxMaps builtin server, after sending OruxMaps once to the background, tile delivery stops and previously uncached regions stay empty. With the Mobile Tile Server, this is not the case. I can send OruxMaps to the background as often as I want, tile delivery is working and new areas are rendered as needed.

Thanks for fixing this at some point!

Did you try the "reload maps" button on the top of the list? The two bowed arrows that point at each other's end?

After a week of hiking in the Šumarva/Böhmerwald here's the real-world experience with multi-layer, self made, mixed vector/raster maps in the Mapbox-format - the TL;DR-version: It's great!!!

A bit more details (some are a bit repetitive to what I wrote earlier - forgive me, it is because I am so pleased with the results!):

• Power consumption: I'm not sure if it really eats more battery - if so, it is marginal. We did 8-9 hr. tours with intense use of Oruxmaps, and after that battery was somewhere between 45-60% remaining, which is matching my experience with pure raster based maps. Thats really good news, and I assume attribute to the caching - i.e. Oruxmaps renders once and then displays bitmaps out of the cache, which would not be much different from displaying pure raster maps.
• Zooming: as expected, it is extremely helpful to be able to zoom in deep if need be. Some places have really a lot information, and zooming in deep allows to get it all. Without the need to store tons of images that eat up tons of space! See the two zooming example screenshots attached.
• Ability to mix raster and vector: The Czech republic Geoportal does only offer raster, so being able to combine "legacy" raster and "modern" vector is making my life so easy!

For me this is now definitely the new standard! Still, there's a bit room for improvment, and some suggestions:

• The tileserver-crash-bug: My workaround was to at the beginning of a tour, after a fresh start of Oruxmaps, once scroll through the map along the planned route (and a bit left and right) at all relevant zoom levels. This made Oruxmaps to build up the cache, and as long as I did not close Oruxmaps, all cached parts of the map worked flawlessly, even after Oruxmaps was in the background. Which was good enough exept for one tour where we needed to take a detour because of a closed area. The map-parts for the detour where not cached, meaning I had to redo the caching procedure again with the new route. Also, once I wanted to look what tower I could see on the horizon, but that part was not cached, and I gave up.
  In terms of the impact, for me it means it is not a critical bug, but a considerably annoying bug, and I really hope it gets fixed.
• No digital zoom availabe: This is also annoying. See the two screenshots below, which show the same region at two zoom levels. The small path "vanishes" at the lower zoom level. I would really have appreciated if I could digitally zoom out while staying at the same map zoom level in order to see the small path in the larger context for spontaneous planning in the field. With pure raster maps this was possible. I only need this ever once in a while, but not having it then hurts. And it is needed not only for the raster layer as you might think: If I take e.g. the Austrian vector maps, smaller paths also are not part of the lower zoom levels, so the same would apply here.
• Really a minor thing, kindof "nice to have": It would be cool to have the offline mapbox format maps available in the list of Offline-maps if you use the "offline map at current position" button.
• The icing on the cake would be if I could show/hide the different layers of a map on the fly. The map for this vacation consists of several layers:
  
  • The German basemap.de vector map layer
  • The German basemap.de vector countour lines layer
  • The Czech Geoportal raster layer
  • My OSM selected information vector layer
  • The Austrian basmap.at raster layer (since there was a chance we might enter Austria during one tour)
  If I would be able to temporarily hide e.g. the Czech raster layer, that would potentially have been very convenient, because the Czech raster layer in the border region to Austria overlapped parts of the Austrian map due to missing transparency.

I hope I understand your question correctly - in MOBAC, the offline maps created consist of anything between 1 and several thousand tiles, depending on area and zoom levels selected. Within one zoom level, the tiles are exactly side by side, no overlap. I am crating MOBAC offline atlas files since ages for MOBAC, and until recently I used the OruxMaps SQLite format. I now realized that also MBTiles is working with OruxMaps, but both store the tiles as exactly matching images.
If you want to create mutiple maps/offline files for adjecent regions, my personal recommendation would be to have these maps overlap. How much overlap IMHO depends on the planned usage: If you walk, cycle or drive, the overlap should be so that you would not need to switch maps every few minutes when moving along the map's edge - for hiking I guess I'd choose 2-4 km, for cycling 15 km or so and when driving perhaps - dunno - 25 km?

Checked now with a very small map - same effect.

Thanks for the explanation!

Indeed, the documentation saying "The cumulative amount of unique maps tile packs used in the offline regions cannot be greater than 750" hints on some potential problem here. And that's quite a bummer honestly. perhaps switching to Maplibre SDK might be a way forward?

That said, I seem to have indications that this is not my problem. I'll try to explain why:

The offline maps I create use as data source in the style "http://localhost:8998/MySelfmade.mbtiles/{z}/{x}/{y}.pbf" - which makes me assume that Oruxmaps starts a simple webserver that serves the content of the mbtiles DB. There are several lightweight servers out in the wild, and I personally for style creation serve my mbtiles via tilemaker-server. So from the viewpoint of Mapbox GL, it is effectively an online source, which happens to be served locally.

What I think supports my theory is the fact that my map very likely exceeds the 750 tile packs (I mean: whole Germany?), but it works just nicely and without any issues as long as I keep Oruxmaps in the foreground. I can move east, west, north, south, in and out as much as I like, and it just works. I've as a stresstest (and to enjoy my product :-) ) been browsing my map for several minutes, looking at various regions all over Germany. It just worked to my utter delight. But as soon as I send Oruxmaps in the background, and regardless if I did just load the map or did excessive map browsing before, reproducibly after that the map gets stuck. all that was rendered before is there, cached, but any region that needs new rendering fails.

To further verify my statement, I will perhaps prepare a lightweight, very small map and see if I can reproduce the problem even with that.

Writing this, it comes to my mind to look for an "external" mbtiles-server as Andoid app... If such a thing exists, I might have my workaround, even bypassing the mapbox limit...

Thanks again for discussing with me! And Kudos to Jose Vazquez for keeping Oruxmaps alive as a one man show! Impressive!

EDIT: Just found this: https://github.com/bojko108/mobile-tile-server - available in Google Play: https://play.google.com/store/apps/details?id=com.bojko108.mobiletileserver&hl=de&gl=US --> Will try this! My hopes are high!

EDIT EDIT: Not compatible with Android 13 - nooooooo!

...and some more evidence: I created a mixed mapsource, combining offline (local mbtiles) plus online (Web-URLs with pbf tile services). When I put Oruxmaps into the background, the offline-tiles "die", i.e. they miss in the rendering. The online sources continue to work. So the renderer obviously works, but data delivery through the local web server is not successful.

Since I had no reaction to this bug yet: What is the best way forward? How can I best provide input? How do I know if this bug caught the awareness of the developers? Don't get me wrong: I do not want to put pressure or so, I just would love to hear feedback. It takes as long as it takes of course!

My offline maps "work" in 3D in the sense that I can use them in the Oruxmaps 3D view mode, but I did not include any elevation information, so it is not real 3D. I'm not sure if I'll go down that route - my usecases are limited, and I guess it eats memory again. But I may change my mind :-)

Thanks for the congrats :-) I owe part of my success to Tronpo - thanks again for providing your ES-maps!

@afgb1977 & Tronpo: Did you do something similar yourself? If so: Which tools did you use? Especially sprite creation is still not as good as I'd like it to be - happy for any hints here! What I am also not done with is a bit of workflow automation, like e.g. marking a region in MOBAC or GQIS and having the whole map creation done per script - do you have anything in place already?

How about the bug I have with the offline tile server dying - can you reproduce it? For me it is absolutely reproducible - it happens really every time Oruxmaps is sent to the background.

Regarding your question, Tronpo: For Germany I'm 100% vector mbtiles, as soon as Czech republic comes in, I have three vector mbtiles (basmap.de, contour lines and OSM data), and one raster mbtiles (Czech Geoportal map).

Battery use: I was positively surpised by only 10% plus. I was afraid that it would be much more. I guess it is partly because the rendered tiles are somehow cached.

I have two more issues:

• Zoom levels as displayed in Oruxmaps do not match Zoom-levels as per style file/Mapbox spec. Why is that so?
• When I have a line with a pattern of sprites along, or a area with a texture pattern, when I zoom in deep, the patterns sometime become distorted, as if the scaling fails. Strange enough, I can have the same pattern side by side in the map, one OK, one distorted. Any idea what may go wrong here?