MOBAC and hillshading

[Michael Bechtold]

Hi Robert,
I am refactoring (not on code but on source and config level) my OAM world map generation tooling.
In that context I put a curious question to Claude Sonnet 5 about MOBAC providing hillshading via the mapsforge capabilities (that would streamline my pipeline). That context led Claude to the wrong answer, because it found out that mapsforge libraries CAN do, but at the same time it did not find any clue about HOW TO configure such in MOBAC.
So I threw the latest MOBAC zip to Claude (it was a 2025 2.3.3 jar) and asked IF it could enable that feature. The answer was not a yes or no, but - after a while - a running patched .jar.
As I am travelling, I do not have the time to test with a set of hgt files.
What do you think about that whole thing?
TXs and cheers
Michael

[r_x]

I have to admnit that I never worked with hill-shading via mapsforge, I did not even know this is possible.

Assuming that Claude has made only changes to a limited number of class files, decompiling and comparing them to the original release should show us the modifications. If you can upload the modified jar I could give it a try. Decompiling and comparing are easy steps.

When working with AIt I noticed that AI often uses command-line tools to view JAR files on byte-code level, so I am not surprised that this is not restricted to reading but also modifying the code.

[Laurent Grenet]

With current version of MOBAC, it's already feasible to define a Mapsource using an existing mapsforge .map file, and specifying a specific map theme that define hillshading as active.
In such a case, MOBAC do not raise any error nor warning, that means that the "hillshading" instructions in the theme are not a problem for MOBAC.
But where to store .hgt files ? Their storage location is not defined in the theme. It has to be defined in the application.

As long as we do not specify their location to MOBAC, there is no actual hillshading. But it is the same (eg. in OruxMaps) when .hgt files are not present, or present but elsewhere than expected (no error, but no actual hillshading).
And if the files are not in the place where MOBAC / Mapsforge wants to find them, it's the same as if they are not present.

So the main question is : How can we define expected location of .hgt files in MOBAC's parameters ?

[r_x]

In mapsforge .hgt files are an offline-cache for hill-shading data. May be it tries to download the data from some other/online source?

I have seen the classes HgtCache and ElevationCacheand ElevationAPI which allows to define a path to a hgt file. But these classes are not used in MOBAC and also they are (as far as I can see) not used by default by Mapsforge.

I have also observed that the mapsforge DatabaseRenderer instace creation in MOBAC does not provide the hillsRenderConfig argument. I think that would be the point where you can provide HillsRenderConfig with a HgtCache instance.

[Michael Bechtold]

Hi Robert and Laurent,
while the theme definition allows hillshading statements, the implementation is always left to the rendering app, like Locus, Orux, etc. etc. And MOBAC - in this regard - is just another renderer. When I asked Claude AI (I only provided the jar in the first place) it saw what you, Robert - just described. And it started building the feature even without me asking for it ;-)) And of course it does need additional configuration data.
This is what Claude introduced for that:
<demfolder>C:\path\to\your\hgt\folder</demfolder>
<hillshadingmagnitude>1.0</hillshadingmagnitude>
<hillshadingzoommin>9</hillshadingzoommin>
<hillshadingzoommax>17</hillshadingzoommax>
Triggered by that quick success I put the next challenge on Claude's "desk": the Label Layer. It did not take long either and Claude (Sonnet 5, mid range effort) delivered the next feature; now based on the latest sources.
Why stop there? Of course not ... The old dispute about MBTiles sources for same zoom level led to a pain in the butt for my OAM world map generation. Now we have the best of both - default is what Laurent argued for (and has been fact of life since a couple of years), but it can be switched off in the settings xml, i.e. MOBAC tolerates multiple sources for one ZL then.
I have added all related files. The .md are nice reading. Even as a computer science PhD I am impressed over and over again.
There is a grain of salt, though: as I have a lot of garden work, the tax declaration is due - before the upcoming vacation, I enjoyed having above built, but I do not have the bandwidth to test it right now.
Cheers
Michael

[Michael Bechtold]

PS: there was an issue in MOBAC when in a multi layer map source tiles were incomplete, typically at the borders of the map. The last layer, if incomplete, would destroy the valid rendered tile content from earlier layer(s). That got fixed in this package, too.
As I want to complete a new release of OAM world maps before leaving, and the gaps between layers in various parts of the world could not be overcome otherwise, I had this final fix made. Inside a layer multiple mapsforge maps could overlap and incomplete tiles were ignored - works nicely since ages (mapsforge lib + MOBAC). What was missing is that dropping of incomplete tiles between layers. Use case: a more detailed theme for sparsely populated / mapped areas of the planet combined with urban theme for other areas.

[r_x]

I think I was able to extract all the relevant changes regarding the MapsforgeMap class that were made by Claude. See my commit here: https://sourceforge.net/p/mobac/git/ci/f557e645e75132d7601add9fb205c988dc00f7bf/

The other changes I have not yet checked.

[Laurent Grenet]

I just did some tests for hillshading, and it seems to be working fine, with one limitation :

To be working, as mentioned in the HILLSHADING_PATCH_NOTES.md, it needs that the theme includes a <hillshading ...=""> line.
If the line is not present, no hillshading (at least, not visible)</hillshading>

But, in a theme, this line may contain some "limitative" parameters, eg cat="...", or zoom_min and/or zoom_max, that allow to have different hillshading presence or magnitude depending on zoom level, or on selection done in "fine tuning" screen (with cat=... parameter)
These "limitations" are not taken into account in Mobac.

This means that if the mapsource file mentions a zoom_min and a zoom_max, and on the other hand theme file mentions other limits, only those of mapsource file are taken into account.

As a result, it is not possible to define, as I do in Oruxmaps, different magnitude depending on the zoom level. In Orux maps, this is done having several hillshading lines in the theme, each of them with a given range of zoom levels, and each of them with a different magnitude.
In Mobac, all these hillshading lines apply whatever the zoom level (provided we are in the range of the zoom levels defined in the mapsource file itself) and are cumulated (resulting in a very "dark" hillshading)

On the other hand, the "magnitude" defined in the theme (in the <hillshading ...=""> line) is taken into account, and the actual magnitude of displayed hillshading seems to be somewhere cumulatively depending on magnitude defined in the mapsource file and magnitude defined in the theme (with different scale of value in both places, since in the mapsource file, its value has to be around 1.0 (1.2 to be darker, 0.8 to be clearer...) while in the theme its a value from 0 to 255 (from the clearest to the darkest).</hillshading>

I have not tested at all any of the other evolutions brought by this new version.

And last remark, (this remark is for @r_x ), it is not possible to do these tests with mapevaluator, since mapevaluator do not allow display of a local mapsource file. I don't know why, but this is also the case with current version of Mobac : it doesn't display the selected map, but rather the light "world.map"

[r_x]

I found the bug in MapEvaluator that prevents MapsForge maps to be loaded correctly.

The latest version in main branch in GIT should work now.

[Laurent Grenet]

OK, good news ! I'll test that

[Laurent Grenet]

I tried to download it and to compile... but at compile time, I get the following error :

FAILURE: Build failed with an exception.


* Where:
Build file 'D:\Users\Public\Documents\Archive\Programmes\MOBAC\Sources\mobac-git-5d8848260a7cfe3e2814453cd9afc3e68a0231fe\mobac\build.gradle' line: 71


* What went wrong:
Could not determine the dependencies of task ':mobac:jar'.
> Could not resolve all files for configuration ':mobac:runtimeClasspath'.
   > Could not find org.beanshell:bsh:3.0.0-SNAPSHOT.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/org/beanshell/bsh/3.0.0-SNAPSHOT/maven-metadata.xml
       - https://repo.maven.apache.org/maven2/org/beanshell/bsh/3.0.0-SNAPSHOT/bsh-3.0.0-SNAPSHOT.pom
       - https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/org/beanshell/bsh/3.0.0-SNAPSHOT/maven-metadata.xml
       - https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/org/beanshell/bsh/3.0.0-SNAPSHOT/bsh-3.0.0-SNAPSHOT.pom
       - file:/C:/Users/Laurent/.m2/repository/org/beanshell/bsh/3.0.0-SNAPSHOT/maven-metadata.xml
       - file:/C:/Users/Laurent/.m2/repository/org/beanshell/bsh/3.0.0-SNAPSHOT/bsh-3.0.0-SNAPSHOT.pom
     Required by:
         project :mobac

[r_x]

That is expected. The used BSH library code base has some important changes for recent Java versions. Unfortunately they don't have a released version and their snapshot repository we used so far has been shut down by Sonatype. So we need to manually build a version.
For more details see README-DEV.md file (requires Apache Maven):

git clone https://github.com/beanshell/beanshell.git
cd beanshell
mvn install

[Laurent Grenet]

Thanks for answer !
Unfortunately, I'm afraid this is one or two steps too far and complex for my very limited capabilities ;-)
Moreover, I'm not on Linux but on Windows.

No problem, I'll wait for you to provide a ready-to-use new version !

[r_x]

I found a simple way to get the latest version of bsh/beanshell library via jitpack. The latest version of MOBAC now uses my forked version with Jitpack support. So the manual steps I described in my last post are no longer necessary.

[Laurent Grenet]

Great !
As a result, I've been eventually able to compile, and I confirm that with this version, "local" mapsforge maps are correctly managed in mapevaluator.

Thank you so much !

[Laurent Grenet]

Actually, I've been partially wrong above.
I confirm that limitation of hillshading by zoom level in the theme is not taken into account, with the negative impact I mention.
On the other hand, limitation with "cat" parameter is taken into account.