Recent changes to feature-requests

#313 Add EPSG:102067 coordinate system

r_x — Tue, 10 Jun 2025 07:38:55 -0000

status: open --> wont-fix
Group: Scheduled_for_next_release --> Not_planned

#313 Add EPSG:102067 coordinate system

r_x — Tue, 10 Jun 2025 07:38:31 -0000

I don't know any atlas format that supports this projection, therefore "implementing" it would require to add a reprojection engine to MOBAC (deform map images exactly that way that all coordinates stay the same but the image size, concavity, ... is translated from one projection to a different projection). For more details see https://en.wikipedia.org/wiki/Map_projection

Sorry but reprojections is totally out of scope of MOBAC. Changing the projection requires sophisticated mathematics and detailed knowledge about the source and target projection.

If you have the necessary knowledge feel free to implement it in MOBAC. I don't have the knowledge therefore this will never happen.

Add EPSG:102067 coordinate system

Stewecord — Mon, 09 Jun 2025 18:07:53 -0000

Hello, please could it be possible to implement EPSG:102067 coordinate system for map sources in Mobac to create maps?

Add EPSG:102067 coordinate system

Stewecord — Mon, 09 Jun 2025 18:07:53 -0000

Ticket 313 has been modified: Add EPSG:102067 coordinate system
Edited By: r_x (r_x)
Status updated: 'open' => 'wont-fix'
_milestone updated: 'Scheduled_for_next_release' => 'Not_planned'

#312 revert the 2023-03-19 introduction of "one map per ZL" check - or make that optional

Laurent Grenet — Thu, 14 Nov 2024 18:22:20 -0000

I FULLY DISAGREE with this request !

As I already mentioned here https://sourceforge.net/p/mobac/forum/general/thread/6599836848/?page=1#bc4c
It's not "purely academic" as @mbe57 says. These boundaries are used (at least by Oruxmaps) to correctly fulfill the feature "Switch map here".
If you have a map with a lot of zoom levels, from 6 to 16, for example, with previous algorithm, boundaries were the one of the lowest zoom 6 (since, by definition, they cover a larger area), while with the current algorithm, boundaries are the one of highest zoom 16.
And he difference may be very important. And if you click on "Switch map here" in a place not actually covered by the zoom level you are... you get an empty display, which can be very frustrating.

Moreover, even if it was "purely academic" as he says, specs of MBTiles are done to be respected and fulfilled and not ignored for the pleasure of only one guy !

And finally, this evolution is absolutely not necessary to requester @mbe57 to fulfill his process, as I have already shown him here https://sourceforge.net/p/mobac/forum/general/thread/6599836848/#93a6

So please @r_x REJECT this request.
If @mbe57 absolutely wants this evolution, he has to create his own fork of MOBAC

revert the 2023-03-19 introduction of "one map per ZL" check - or make that optional

Michael Bechtold — Thu, 14 Nov 2024 17:31:37 -0000

I've checked with Orux and Locus - two major App that can handle MBtiles. Both - and I assume any other smart Geo App - can handle gaps in zoom level of a map, one way or another.
Hence I consider the "all" ZL requirement of the MBtiles spec purely academic and irrelevant in the practical world.
So my proposal is to revert the 2023-03-19 introduction of "one map per ZL" check. Even Rainer could live perfectly using the 2.3.1 (without that check) with Laurent's hint.

#311 perform digital zoom with customMultiLayerMapSource

Cyril42e — Wed, 26 Jun 2024 22:28:26 -0000

Interesting! Would it be possible to include this source in a Multilayer source, or to make directly the java map source a multilayer source?

But anyway in the end it would indeed be a bit easier to use (though a simple script can synchronize the execution of the local tile server and Mobac), however it would also be more complicated to configure (in order to change the server URL, API key, ...) by requiring to recompile the package, especially if the multilayer has to be compiled in java. It also requires additional development that is specific to Mobac but without being easily reusable by other users for creating their custom map sources (contrary to my initial suggestion). I'll let you know if I change my mind and implement something like that though.

Thanks for your inputs!

#311 perform digital zoom with customMultiLayerMapSource

r_x — Tue, 25 Jun 2024 09:59:57 -0000

Group: Already_implemented --> Not_planned

#311 perform digital zoom with customMultiLayerMapSource

r_x — Tue, 25 Jun 2024 09:59:43 -0000

I see an intermediate way that behaves like running a local tile server inside MOBAC:

The implementation of non-custom map sources are Java classes. Multiple map source together are packed into one mapsource jar package.
The structure of MOBAC source code allows to create new map sources that can provide not only the URLs of map tiles but also implement totally custom loading mechanisms like generating images on the fly (or based on a tile form a different layer).

For someone with some Java skills implementing this isn't a big problem. A new map source package and a new map source isn't a big problem to add in MOBAC's gradle project. And a sample map source that generates tile son-the fly is mobac.mapsources.impl.DebugMapSource#DebugMapSource.

perform digital zoom with customMultiLayerMapSource

Cyril Roussillon — Tue, 25 Jun 2024 09:46:55 -0000

Hi,

I made a custom multilayer map source in order to add hillshade (from MapTiler) to a vector map (from OpenAndroMaps). It works great, except that the hillshade tiles are limited to zoom level 12, and when I try to zoom more Mobac does not display anything except an error tile mentioning "400 Bad Request Out of bounds" which is what the tile server responds when requested for zoom level beyond 12. It does not display the valid layers, and does not perform digital zoom on the missing layers.

I found a workaround by writing a local tile server that directly forwards requests for zoom level <=12, and performs digital zoom on the fly for zoom levels >12 (requests tile 12, and performs crop and scale up). But it is a bit cumbersome, and I was thinking that it would be pretty easy and useful for Mobac to perform it automatically (i.e. when zooming beyond the configured maxZoom of one layer, but not of all layers, then perform digital zoom on the max zoom available for each layer).

Or maybe there is another way to do it, easier than running a local tile server?

Thanks