URock without Java

[j3r3m1]

Problem statement

URock is a UMEP model useful to estimate wind speed in urban settings. It uses a spatial database system called H2GIS which is coded in Java. To use the DB (= to apply spatial processes via SQL queries), we need the user:

• to install a Python library called "JayDeBeApi" (in order to use Java DB)
• to install Java on his computer

We know many of you have had troubles installing UMEP or running URock due to the dependence to Java.

Proposition to solve the issue

Recently, the h2gis developer team has released a version of H2GIS which is compiled in C and develop a Python library to directly use H2GIS in Python. I have created a new UMEP branch called 'RemoveJava' to test whether this library could replace the couple 'jayDeBeApi' Python library + 'Java'.

Advantages / shortcomings

Advantages of the new version	Shortcomings of the new version
A1 - Java not need anymore	S1 - Not sure it currently works for MacOS
A2 - 3 times quicker (1 s instead of 3 s) for a single building	S2 - 2-times longer for a 1 M voxels
	S3 - A GitHub action has to be coded to compile the code in C each time a new H2GIS version is released

Concerning computational time, it has been tested on a single labtop and only two cases. More tests should be performed to verify the level of magnitude of the first results. The performance of the new version could also be improved by using the last version of the compiler which might optimize the code (this version has been compiled with version 1.21 while 1.25 exists).

Time for tests

I know some of you (@biglimp @jessikalonn @lgzdbf) are using URock quite intensively in their research of teaching. It would be nice if you could test the new version on your machine reporting:

• your OS
• your test case (number of buildings and dimension in number of pixels X * Y * Z)
• time spent for initialization with the old version
• time spend for initialization with the new version

If you know anyone using MacOS it would be nice if you manage to make them test it !

[j3r3m1]

I start:
First case:

• Ubuntu 22.04
• 2 buildings - 49 x 98 x 16
• 2.4 s
• 0.8 s

Second case:

• Ubuntu 22.04
• 12 buildings - 184 x 218 x 29
• 45 s
• 80 s

[lgzdbf]

Hi @j3r3m1 ,

I can start the test tomorrow on the same study area and with the same configuration as mentioned here #757 , so we will be able to compare the outputs.

Just to be clear, when you say initialization, do you mean the total time to obtain the result, or the time needed to load the urban scene when running the model?

I will try to gather some more precise statistics.

I will keep you posted early next week (once the run is complete).
A+

[biglimp]

Thank would be great. I only have one mac colleague and he is usually very busy.

[biglimp]

@lgzdbf , did you have any chance to try on iOS yet?

[lgzdbf]

No, unfortunately my colleagues are quite busy as well. I am trying to follow up with them and I will keep you posted!

[biglimp]

Great. I tried it on one of my colleagues but his version of QGIS and Python (3.9) was very old and therefore not compatible.

[lgzdbf]

Ok, I found someone for a test tomorrow; @biglimp or @j3r3m1, could you please send me the Python code you are using? Otherwise, I will run it directly from QGIS, but in that case we will only get the total time, not the initialization time. As you want.

[biglimp]

Excellent progress Jeremy! We have a french intern ( @EliottBrr ) that can help us to some testing on some different OS. We will report back when we have some results.

[j3r3m1]

The idea is to see if the calculations can be made with the two versions (especially the updated one) so no worries about the calculation time 6 nov. 2025 17:04:34 lgzdbf ***@***.***>:

…

Ok, I found someone for a test tomorrow; @biglimp[https://github.com/biglimp] or @j3r3m1[https://github.com/j3r3m1], could you please send me the Python code you are using? Otherwise, I will run it directly from QGIS, but in that case we will only get the total time, not the initialization time. As you want. — Reply to this email directly, view it on GitHub[#794 (reply in thread)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ADEDHFMLYX2TSM66RFTRW7333NWQZAVCNFSM6AAAAACKKRZQAOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBZGMZTEMI]. You are receiving this because you were mentioned. [data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAABICAYAAABV7bNHAAAAAXNSR0IArs4c6QAAAARzQklUCAgICHwIZIgAAAArSURBVHic7cEBDQAAAMKg909tDjegAAAAAAAAAAAAAAAAAAAAAAAAAAA+DFFIAAEctgHwAAAAAElFTkSuQmCC###24x24:true###][Image de pistage][https://github.com/notifications/beacon/ADEDHFJJBXY6OTPK4K2YDH333NWQZA5CNFSM6AAAAACKKRZQAOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQA4NAQS.gif]

[lgzdbf]

I tried remotely, but my colleague couldn’t download the necessary modules… But I am not giving up, I’ll try again next week with the computer in front of me. :–)

[biglimp]

Thank you for your efforts! One thing that you should be aware of is the Python version used. It should be 3.12, not 3.9.

[lgzdbf]

Hi, I finally managed to install all the modules. When I run uRock using the official version, everything works fine, but when I run it with the version without Java, this error message appears (through the graphical interface):

Writing settings for this model run to specified output folder (Filename: RunInfoURock_YYYY_DOY_HHMM.txt)

Initiating algorithm

Creates an H2GIS Instance and load data

Traceback (most recent call last):
File "/Users/kaltrinamaloku/Library/Application Support/QGIS/QGIS3/profiles/default/python/plugins/UMEP-processing-RemoveJava/processor/urock_processing_algorithm.py", line 429, in processAlgorithm
MainCalculation.main(pluginDirectory = plugin_directory,
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
outputFilePath = outputDirectory,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<33 lines>...
profileType = profileType,
^^^^^^^^^^^^^^^^^^^^^^^^^^
verticalProfileFile = profileFile)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/kaltrinamaloku/Library/Application Support/QGIS/QGIS3/profiles/default/python/plugins/UMEP-processing-RemoveJava/functions/URock/MainCalculation.py", line 145, in main
H2gisConnection.startH2gisInstance(dbInstanceDir = tmp_dir_unique,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
suffix = db_suffix)
^^^^^^^^^^^^^^^^^^^
File "/Users/kaltrinamaloku/Library/Application Support/QGIS/QGIS3/profiles/default/python/plugins/UMEP-processing-RemoveJava/functions/URock/H2gisConnection.py", line 79, in startH2gisInstance
cur = h2gis.H2GIS(f"{localH2InstanceDir};AUTO_SERVER=TRUE;",
username = instanceId,
password = instancePass)
File "/Users/kaltrinamaloku/Library/Python/3.13/lib/python/site-packages/h2gis/h2gis.py", line 83, in __init__
self.lib = ctypes.CDLL(lib_path)
~~~~~~~~~~~^^^^^^^^^^
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/ctypes/__init__.py", line 390, in __init__
self._handle = _dlopen(self._name, mode)
~~~~~~~^^^^^^^^^^^^^^^^^^
OSError: dlopen(/Users/kaltrinamaloku/Library/Python/3.13/lib/python/site-packages/h2gis/lib/h2gis.so, 0x0006): tried: '/Users/kaltrinamaloku/Library/Python/3.13/lib/python/site-packages/h2gis/lib/h2gis.so' (not a mach-o file), '/System/Volumes/Preboot/Cryptexes/OS/Users/kaltrinamaloku/Library/Python/3.13/lib/python/site-packages/h2gis/lib/h2gis.so' (no such file), '/Users/kaltrinamaloku/Library/Python/3.13/lib/python/site-packages/h2gis/lib/h2gis.so' (not a mach-o file)

Execution failed after 0.02 seconds

From what I understand, it seems to be a compatibility issue between macOS and h2gis.so? Have you ever encountered this type of error?

[j3r3m1]

Never but you are the first to try =)
Thank you for trying !
You have install h2gis library I suppose ? It was a bit expected, even though I would have liked it to work. @ebocher do you think that someone could make it automatic to compile H2GIS for MacOS ?

[ebocher]

H2GIS-Python is not available for MacOS.
To give you some information, H2GIS is compiled from JAVA to a native shared library, thanks to GraalVM (https://www.graalvm.org/) . The shared lib is then exposed to Python using a C API.
H2GIS uses an older version of GraalVM (21+). With the latest version (> 25), it is possible to improve performance, but the roadmap is not very clear regarding MacOS support. https://www.graalvm.org/release-notes/JDK_25/ saids "Support for macOS x64 is deprecated. Version 25.0.1 is the last release that supports this hardware architecture. In future, GraalVM will only support macOS on AArch64 (Apple Silicon)." Will this affect your users?

[ebocher]

The pip install-jdk may be a way to investigate to install automatically the JVM on different OS ?

[biglimp]

Would it be possible keep java for mac-users, i.e. identifying OS before H2GIS is used? If iOS is present, the old java-based version is used, otherwise we use the new non-java?

[ebocher]

I suggest doing a little experiment with @j3r3m1 to see if install-jdk is a good way.

[biglimp]

The issue is that users have different versions and different java (openjdk, java.com etc.) installed. This makes the URock not work.

I dont think an automatic installation of java is very popular. Also, since java is, as you imply, "owned" by oracle, a true open source software should not include java...

[ebocher]

I dont think an automatic installation of java is very popular. Also, since java is, as you imply, "owned" by oracle, a true open source software should not include java...

OpenJDK is the community JVM and it is the most widely deployed JVM. I don't see why it would be a problem to deploy the community version.

The issue is that users have different versions and different java (openjdk, java.com etc.) installed. This makes the URock not work.

With a fresh install from pip install-jdk you can ensure that your user always has the correct JVM

[biglimp]

ok, noted.
Still, the less installation of other things than Python code should preferably be avoided.

What are the reasons why not proceed with the non-java version? Please explain.

[j3r3m1]

Still, the less installation of other things than Python code should preferably be avoided.

I would rather say the less stuff we install the better it is since even Python libraries might not be compatible between each other and are often causing problems. If properly installed, Java-JDK should not create more trouble but we have not tried yet and have to check.

What are the reasons why not proceed with the non-java version? Please explain.
Currently, the "non-java" version does not work for Mac so it means that we will have to maintain "two URock versions". However, it is probably possible to make it work for Mac also, it is just a matter of investigation.

So both options can be used, we just need time to compare them.