Terrarium tiles provider

[naulan-chrzaszcz]

Changes

Add terrarium tiles provider

Technical changes

TODO

Showcase

TODO

Reason

For Albanian and world DTM generation

TODOs

• Review myself
• Explain some difficult lines of code
• Write the documentation of this provider
• Make the unit test for the params side

Self-checks

• The code has unit tests associated
• The code has Javadoc Comments associated
• Complex / Unexpected code is explained / justified with a small comment
• Relevant documentation inside the /docs folder has been updated
• All examples in examples/ work the same (or have been adapted if subject to changes in this PR)
• Git history is clean (each commit accomplish a single task and describe it accordingly)
• The texts have been proofread (documentation, error messages, logs, comments...)

[naulan-chrzaszcz]

This feature is pretty raw; it was a prototype I quickly put together while I was in Albania, using the most powerful Claude Code model.
I need to make it less obscure and understand what it actually generated for me.

[indyteo]

I did not read the code in details, but just from a quick overview, it seems like you can quite drastically simplify it, especially by removing the re-projection.

In the WMS provider, we have a CRS in the params because we need to tell to the GeoServer in which CRS we want our data. It is intended that the user inputs either the native data CRS (so the server don't reproject and our MapToWorldConverter does), or the generated map CRS (so the server reprojects and our converter don't).
In the Overpass provider, we don't have a CRS in the params because OSM data is ALWAYS in EPSG:4326. Our MapToWorldConverter will handle the re-projection as long as the correct CRS is indicated in the Provider.Result#crs() method.

In your case, it seems like the data will always be in EPSG:4326. So, just like the Overpass provider, don't worry about any re-projection yourself, and let the MapToWorldConverter do it. I guess you started from the WMS provider, which explains why you had this CRS and thus struggled to integrate it.

Additionally, keep in mind that it is completely OK for a provider to return multiple results. Even with matrices, it looks like you could return one matrix per tile instead of having to handle the merging yourself. Claude might be good at writing working code, but it's up to you to integrate it properly into the codebase (because it doesn't know about everything that is already handled by another component). If you were to write such code by hand, would you have really implemented re-projection and tile merging yourself? Probably not, because you would have known that it was tedious to do and also unnecessary ;)

[pyrollo]

This feature is interesting.

You should not limit it to Terrarium, many other data are provided using XYZ tiles.

And as said Theo, this could be very simplified and made more Voxatile-like:

• separate Provider logic from data storage logic (keep data in BufferedImage);
• remove useless (and memory consuming) conversion to FloatGeographicDataMatrix2d, prefer keeping data in BufferedImage rather (this is the policy we had from the beginning of the project);
• avoid useless CRS transformations

[github-actions]

[Maven Build Status]

📑 Commit: 58d9e894076d2ade1843db3eda6203a72d6666ed
⌚️ Date: 2026-09-29T11:01:19 (CEST)
🛠️ Status: ✅ Success

📦 Download artifact: Generator.jar