Mesh creation issues

Hello,

I'm trying to build a mesh for the area of Nice, France with a DEM of 5 meters resolution from the open data portal of the Municipality.

Here is the DEM converted to TIFF in QGIS:

Here are its coordinates in its original CRS:

And here they are in the standard CRS (EPSG:4326):

My TFW file:

0.0000654927
0
0
-0.0000426
6.743398875698556
44.36568831142908

My TMC file:

<[file][][]
<[tmcolormap_regions][][]
<[string] [folder_source_files][./input/elevation-nice/]>
<[bool]   [write_images_with_mask][false]> // global flag -> if this is true, no image is created
// if a mask is required. if this is false you can still
// disable mask images for a selected level, see below
// images with mask are always 'problematic'. rule of thum
// is to create an area as large as possible

<[bool]   [write_ttc_files][false]>
<[bool]   [do_heightmaps][true]>
<[string8][folder_destination_ttc][./output/images/]>
<[string8][folder_destination_heightmaps][./output/elevation/]>
<[bool]   [always_overwrite][true]>

<[list][region_list][]

<[tmheightmap_region][element][7]
<[uint32]              [level]  [7]>
<[vector2_float64]     [lonlat_min]   [6.743398875698556 43.63047716301322]>
<[vector2_float64]     [lonlat_max]   [7.467846368136574 44.36568831142908]>
<[bool]                [write_images_with_mask][false]> // do not create images that would require a mask
>

<[tmheightmap_region][element][8]
<[uint32]              [level]  [8]>
<[vector2_float64]     [lonlat_min]   [6.743398875698556 43.63047716301322]>
<[vector2_float64]     [lonlat_max]   [7.467846368136574 44.36568831142908]>
<[bool]                [write_images_with_mask][false]> // do not create images that would require a mask
>

<[tmheightmap_region][element][9]
<[uint32]              [level]  [9]>
<[vector2_float64]     [lonlat_min]   [6.743398875698556 43.63047716301322]>
<[vector2_float64]     [lonlat_max]   [7.467846368136574 44.36568831142908]>
<[bool]                [write_images_with_mask][false]> // do not create images that would require a mask
>

<[tmheightmap_region][element][10]
<[uint32]              [level]  [10]>
<[vector2_float64]     [lonlat_min]   [6.743398875698556 43.63047716301322]>
<[vector2_float64]     [lonlat_max]   [7.467846368136574 44.36568831142908]>
<[bool]                [write_images_with_mask][false]> // do not create images that would require a mask
>

<[tmheightmap_region][element][11]
<[uint32]              [level]  [11]>
<[vector2_float64]     [lonlat_min]   [6.743398875698556 43.63047716301322]>
<[vector2_float64]     [lonlat_max]   [7.467846368136574 44.36568831142908]>
<[bool]                [write_images_with_mask][false]> // do not create images that would require a mask
>

<[tmheightmap_region][element][12]
<[uint32]              [level]  [12]>
<[vector2_float64]     [lonlat_min]   [6.743398875698556 43.63047716301322]>
<[vector2_float64]     [lonlat_max]   [7.467846368136574 44.36568831142908]>
<[bool]                [write_images_with_mask][false]> // do not create images that would require a mask
>

>
>
>

But the result is not perfect as you can see

The issue is not only about the heights, the impacted surface is not really correct too...

Any idea of what's could be wrong in my settings ?

Note that I have to close manually the Geoconvert window at the end of the process (100% of the tiles are generated) but this can be considered as "normal" as said in another topic.

I'd would rather see an error with the pixel size (line 1 and 4 in the TFW file).

Thanks for your help, Vincent.

In fact my original values were like that (with NW corner and then SE corner):

<[vector2_float64]     [lonlat_min]   [6.743398875698556 44.36568831142908]>
<[vector2_float64]     [lonlat_max]   [7.467846368136574 43.63047716301322]>

But the result was exactly the same (which was a bit surprising for me).

@flightxtreme: your tool looks interesting and I'll give a try tonight but the values visible on your screenshot are the ones with my DEM file ?

I have tried MultiSpecW64 and the values are the same as in QGIS (as expected).

I also tried to first convert the TIF image from its original SRS (EPSG:2142) to the standard one (EPSG:4326) *before* to open the "Save as" window of QGIS. That way the values are directly in EGPS:4226 (ie. no need to change the SRS in the dialog box). With that method the north/south/east/west values are slightly different but the pixel size was totally different from the previous ones (X and Y are now equal which was not the case before). Anyway the result is result is almost the same: the impacted surface is not exactly the same but I still have mountains with heights around 50 kilometers

Zitat von Jet-Pack

strictly speaking

min should be lower left corner so South/West corner (lowest lat and lon)

and max should be North/East corner (highest lat and lon)

Zitat von TomSimMuc

Are you sure Jan?

The WIKI says Max = SE corner

https://www.aerofly.com/dokuwiki/lib/e…cenery_creation

It would be nice the clarify it.

It's true that "lowest lat and lon" means South West corner.

But in the AFS literature (wiki and forum) it looks it is the North West corner which must be used.

And in my case I even don't see the difference when I changes the values (but maybe it's linked to another issue).

Zitat von Jet-Pack

I'm pretty sure South West and North East corner is correct because it is a similar system like U-V coordinates, but if both work then if obviously doesn't make a difference.

But in my case both don't work

If I have time I'll try with another DEM file to check if the issue is related to file itself or not.

So I tried with N43E007 tile from Jonathan de Ferranti's website (embeded SRTM 30 meters).

This time the SRS of the file is EPSG:4326 so no conversion is needed:

But sadly the result is very similar:

There must be something obvious wrong but I do not know what

I've tried the two ways of setting coordinates in the TMC file.

NW corner and SE corner:

<[vector2_float64]     [lonlat_min]   [6.999861111111112 44.00013888888889]>
<[vector2_float64]     [lonlat_max]   [8.00013888888889 42.999861111111116]>

SW corner and NE corner:

<[vector2_float64]     [lonlat_min]   [6.999861111111112 42.999861111111116]>
<[vector2_float64]     [lonlat_max]   [8.00013888888889 44.00013888888889]>

And my TFW file is:

0.000277778
0
0
-0.000277778
6.999861111111112
44.00013888888889

Thanks Rich for your try.

We could imagine the DEM file of Nice has something wrong in its content but I have a very similar issue with the DEM files from de Ferranti as well. And these files are already in WGS84 so issue is not linked to a wrong conversion / reprojection !

On QGIS we can see the 2 TIFF have correct "Z" values:

• Nice: from 20 to 2649 meters
• N43E007 (de Ferranti): from 0 to 1456 meters

As you said it is like a wacky factor is applied to the Z values, but why ???

BTW your screenshot is a bit different from mine: mountains seem less high and around them there is that surface without any relief.

After tons of attempts I tried to rename the elevation directory provided by default with AFS2 in order to disable it and then my mesh is finally displayed correctly !

The problem therefore seems to come from a conflict with the base mesh, any idea why ?

Note that the previous screenshot is the mesh based on Johnathan de Ferrati's tile (30 meters resolution). With the mesh based on the open data DEM of Nice (5 meters resolution) I still have the same issue than before, even with the base mesh disabled, but I have to retest to be sure.

It's strange, all my last posts have been merged with the post #12 ! I guess this is automatic feature of the forum but it's not very handful because it prevents others from knowing that there has been a new post.

Anyway I'll be curious if people have ever encountered this kind of conflict problem with the base mesh.

If the problem concerns all the DEM files provided by J. de Ferranti I imagine that other people have already succeeded, or at least tried ...

Zitat von flightxtreme

If I get the Spike-Fields, it is usually the wrong modifications or export from gimp. I also use the SRTM 1°Arc sources from the IPACS-wikipages. These are already in geoTiff format, so I do not need to convert the sources into geoTiff, they already are.

Interesting, could you please post the link ? I tried "SRTM" on the wiki search but without any result...

Zitat von flightxtreme

Czech Republic Meshes working well together with the standard-Mesh so far. I always compile whole tiles without masked files as a result and go from Level 9 to 11. I don't do Level 7 and 8. The borders of the tiles are looking ok at the moment. So I don't see why I should do 7 to 8.

(Well, I compile the whole region and just put the right files for the specific tiles I am working on into the scenery.)

I'll try to build the mesh with levels 9-11 only, but I'm not optimistic because the issue was present whatever the distance between the camera and the impacted aera...

Zitat von Trespassers

I had the same spikes issue when generating a 5m mesh partly overlapping the Switzerland DLC

BTW, this caused some mess in my photo scenery display priority, even after totally deleting this mesh attempt.

I had no problem compiling 5m DEM mesh in other zones like Courchevel or Paris, ie. without overlap with Swiss DLC.

A place like Nice should however be in the same category...

So for you Antoine we can have the issue if we build a mesh over an existing mesh, but not the default mesh.

I wish it was like that but unfortunately in my case it does not work

But I should dig a little more these masks stories, maybe it's the clue !

Thanks for your responses, Vincent.

Thanks Antoine for your post.

What looks crazy for me is that you have the spike issue even if you disable the Swiss DLC mesh.. and also your own mesh ?!?

The inefficiency of the flag for masked image creation is also surprising...

Geoconvert has a lot of hidden secrets !!