Support for reading UGRID 3D layered mesh

[Huite]

Greetings all,

I've posted a little bit here before, we're actively using MDAL currently (not just via QGIS). We're interested in adding support for layered UGRID meshes, and having a go at contributing it ourselves.

The table currently states that UGRID 3D isn't supported, so I was having a look at the TUFLOW implementation for inspiration. That gives some clues to which methods to be added, but one of the differences I've noticed is the explicit Dataset2D & Dataset3D classes for the TUFLOW driver, although not for UGRID 1D & 2D. Is there a reason for this?

But basically, I've got a few general questions:

• would you be happy with a Pull Request adding 3D layered support for UGRID? (Provided we follow the contributing guidelines of course)
• Any suggestions on where to get started? (As mentioned, I think the data model and the TUFLOW implementation gives some idea, but there's no tutorial like e.g. GDAL: https://gdal.org/tutorials/raster_driver_tut.html)
• Other suggestions? (e.g. the aforementioned Dataset2D/3D)
• A very general MDAL question: does MDAL support layers with "gaps" between them? E.g. layer 1: from z=0.0 to z=10.0; layer 2 from z=15.0 to 25.0. Or is this delegated to the driver?

(I've already run into an issue with the UGRID conventions, which don't seem to have sufficient opinion on the z-coordinate... but that's something I've already taken up with colleagues.)

[PeterPetrik]

Hi @Huite and thanks for approaching us,

as an open-source project, the community is obviously happy to accept any pull requests that conforms with the code-quality and contribution standards (https://github.com/lutraconsulting/MDAL#development). If you add new driver, also consider that you would be (co-)responsible for maintaining your code :)

For your question, tuflow use its own datasets because we do lazy loading there and it was convinient for the first driver to it as separate class. If you find during the implementation of ugrid 3d that most of the code can be reused, it could be refactored to some common base class.

some docs are https://www.mdal.xyz/tutorials/add_driver_tut.html, and https://github.com/qgis/QGIS-Enhancement-Proposals/issues/158 . If you have time, I will be more than pleased to fix/update our docs too (just edit it on github sources)

I think this discussion is better to continue on https://lists.osgeo.org/mailman/listinfo/mdal-developer , github issues are not suited for the general discussion so I am closing this ticket.

MDAL driver supports whatever you implement in the driver code.... The core Api/structures are very generic, so also everything fits there....