Messages

MapLibre is feature-wise similar to MapBox (As far as I understand, it is a fork, i.e. to some extent basically identical), but license-free. So OruxMaps could offer the MapBox-style vector maps features without additional subscription. You would not get the MapBox maps itself without license - I can only voice my perspective here - these premium maps are of no big value to me. Not sure what others think about them. My interest is having the vector map feature unlocked.

That said: I find ~10€/year extremely fair priced, so if OruxMaps stays with that, no big issue.

Thanks Tronpo! Glad to hear that MapBox vector maps implementation continues to evolve. I will reach out to the developer privately as you suggest. Also to discuss if it would be an option to shift from the licensed MapBox to the free open source fork MapLibre, which is largly compatible.

Thanks Sandy!

OpenAndro is MapsForge format, which I know works. However, I had limited success in creating my own offline maps in MapsForge format (I could not find tools, and I find the style definitions cumbersome). I was very successful (with tronpos help) to create vector maps in MapBox format, but in order to use MapBox-Format offline maps, you need to "unlock" the rendering engine in oruxMaps by buying the subscription.

In other words: I am not so much interested in the MapBox premium maps, but in the rendering engine.

If you want to know in detail what I do, read about it here: https://projects.webvoss.de/2024/08/03/superatlas-goes-vector-part-ii-creating-and-using-the-offline-vector-maps/

TL;DR version: I create a combined map where I have map data from various official sources like basemap.de, basemap.at or swisstopo, and combine them with OpenStreetMap data for feature rich hiking maps that match exactly my preferences.

Being a rare visitor here, I only now realized that OruxMaps NG exists :-) I blindly purchased it, happy to support this project further! Will check it out over the next weeks.

Question: I own the MapBox premium maps subscription in GP. Can I reuse it in NG, or do I need to have a second subscription?

And: Is there development of this feature to be expected? I still have bugs in GP which never were fixed and require me to run workarounds.

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.