Sandworm not using correctly some geotiff files

[Amerio.Stephane]

Hello, the attached geotiff file is not correctly loaded by sandworm. It was generated by QGIS, and it loads fine in qgis.

If QGIS re-export the same data to ESRI BIL format, then Sandworm can load it, but only as an external data because BIL extension is not recognized as an asset.

(so 2 bugs: the geotiff not loading, and .BIL format not seen).elev_bath.zip

[bmyagkov]

Hello, Stephane!

It seems that the GeoTIFF generated by QGIS contains an inconsistent CRS definition or Sandworm Tool might parse it incorrectly. The projection is declared as Lambert-93 but the embedded datum definition does not match. Because of this mismatch the reprojection pipeline cannot be created and the file fails to load in Sandworm Tool.

When exporting to ESRI BIL, QGIS appears to rewrite the spatial reference information correctly.

Please see the error that the console shows when attempting to add your source in Sandworm Tool:

Quote

PROJ: proj_create_from_database: crs not found

The definition of projected CRS EPSG:9794 got from GeoTIFF keys is not the same as the one from the EPSG registry, which may cause issues during reprojection operations. Set GTIFF_SRS_SOURCE configuration option to EPSG to use official parameters (overriding the ones from GeoTIFF keys), or to GEOKEYS to use custom values from GeoTIFF keys and drop the EPSG code.

Cannot find coordinate operations from `ENGCRS["RGF93 v2b / Lambert-93",EDATUM[""],CS[Cartesian,2],AXIS["(E)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["(N)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]]' to `EPSG:4326'

LayerGeo::onPrepare: can't reproject geo transform in layer(elev_bath).

Can't create layer: elev_bath.

Could you attach a new file after re-exporting? This will allow us to compare both files and see if our assumption about the issue is correct.

Thanks!

[bmyagkov]

It appears that we have identified the root cause of the issue.

At the moment, Sandworm Tool uses GDAL v3.6.2-patch1 which relies on a proj.db (EPSG v10.008) revision from 2020. This version does not include a reference to EPSG:9794 (RGF93 v2b / Lambert-93) which was introduced in 2021. Because of this, the CRS cannot be resolved correctly during import and the dataset fails to load.

As an alternative, you may consider using EPSG:9793 instead. The difference between EPSG:9793 and EPSG:9794 is minimal with discrepancies measured only in millimeters.

In addition, based on the previously delivered data, your landscape datasets were generated using EPSG:2154. If you are extending the same project with new areas, it would therefore be consistent and technically appropriate to continue using EPSG:2154.

Thanks!

[Amerio.Stephane]

Thanks, indeed, the sandworm project was using the good projection for the final export (2154), but the geotiff was using a more recent projection (for no objective reason).

After that, the geotiff for elevation works great. But I might have made some other modification that now make sandworm systematically crash during generation, and I have no clue why; attached some editor crash dumps:editor_crash_dump_62e2124c_1.zip

[bmyagkov]

19 minutes ago, Amerio.Stephane said:

Thanks, indeed, the sandworm project was using the good projection for the final export (2154), but the geotiff was using a more recent projection (for no objective reason).

We're glad it was helpful! You're very welcome. :)

19 minutes ago, Amerio.Stephane said:

After that, the geotiff for elevation works great. But I might have made some other modification that now make sandworm systematically crash during generation, and I have no clue why; attached some editor crash dumps:editor_crash_dump_62e2124c_1.zip

It appears that certain vector data used for generating buildings might be causing the issue. Would you be so kind as to temporarily disable this layer to check the results? If it turns out that this is indeed the cause, could you please share the source files along with the settings used and the editor log file?

Thanks!

[Amerio.Stephane]

log.zipDisabling the building generation works, so I must have gotten something wrong here. The building shapes are from openstreetmap and the generation was working yesterday, and the file was not modified. So I guess my wrongdoing must be in the sandworm configuration itself somehow. As far as I remember, the only tweeking from me was selecting to have only 1 and 2 floors for building with hipped roofs.

[bmyagkov]

Hello Stéphane,

Thank you for the additional information. It was very helpful in narrowing down the issue.

It appears that this behavior occurs because for the process to proceed correctly at least one “Flat” type must be present in the "Roof Type–Material" configuration. Without it the generation may not continue as expected.

This issue is already listed in our internal bug tracker and is planned to be addressed in the upcoming SDK update later this month.

We apologize for any inconvenience this may have caused.

P.S. Please set “Coordinate System” to “Source” which is the default option. The thing is “Unigine World” is mainly for flipped NED (North-East-Down) projections (like EPSG:31468) where terrain data gets flipped along the Y-axis. Your coordinate system (EPSG:2154) uses the kind of industry-standard ENU orientation (East-North-UP), so “Source” is the appropriate choice here.

Thanks!

[Amerio.Stephane]

8 hours ago, bmyagkov said:

at least one “Flat” type must be present in the "Roof Type–Material"

Ok, added it, and that prevented the crash. But how can I get rid of any Flat roof? whatever the roof distribution, I always get a lot of flat roof when there should be none?

The doc is not very clear here, I assume the numbers on the right only have a significance when Attribute+Random is selected, or is there something else? (the algo is not explained clearly in the doc).

8 hours ago, bmyagkov said:

Please set “Coordinate System” to “Source” which is the default option

Fixed! Thanks!

[bmyagkov]

Hello Stéphane,

Regrettably, it is not possible to completely remove flat roofs due to internal limitations that prevent the creation of custom roof shapes for complex buildings such as the example shown in the image below taken from your vector source:

For such buildings a flat roof will always be generated because the tool currently does not support generation for buildings of this shape. We hope to improve this functionality in the future. For now, the only solution is to set the roof type to “Flat” and assign it a probability of 0. This way, flat roofs will only be generated for buildings where creating a "Hipped" roof is not possible.

Once generated, the .mesh files can be opened in a third-party application such as Blender, 3ds Max, Maya or similar and edited as needed. At first glance, there don’t seem to be many buildings of this type in your source, so the edits should not require much time or effort.

We apologize for any inconvenience caused.

Thanks!