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:

    Code
    0.0000654927
    0
    0
    -0.0000426
    6.743398875698556
    44.36568831142908

    My TMC file:

    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):

    Code
    <[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 ?

  • @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 ?

    No, just an example of my files.

    Wish for Aerofly FS 2/4:

    - Flightpath recording on hard drive and replay in sim from different view points

    - Smoke for aerobatic planes

    - Multiplayer or at least watching other people flying sitting on ground or inside tower

    Edited once, last by flightxtreme (July 7, 2019 at 4:23 PM).

  • 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 :(


    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)

    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).

    Edited once, last by turman (July 8, 2019 at 10:25 AM).

  • 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 X(

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

    NW corner and SE corner:

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

    SW corner and NE corner:

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

    And my TFW file is:

    Code
    0.000277778
    0
    0
    -0.000277778
    6.999861111111112
    44.00013888888889
  • Turman,

    As a sanity check I decided o give the file a try. I downloaded the DEM and did a gdalwarp reprojection from Lambert-93 to WGS84 before loading into QGIS.
    I exported as a rendered GEOTIFF and processed as I would any other mesh.



    Looks like a similar result.

    Code
    0.0000503057
    0
    0
    -0.0000503057
    6.743398876
    44.365688310

    BTW pixel coefficients will be identical if you are dealing with square pixels.

    Well I don't know what the problem is. But it sure does look like there is a wacky coefficient being applied to the vertical component of the data.

    -- Rich

  • 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 ! :huh:

    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.

    Edited 3 times, last by turman (July 11, 2019 at 10:03 AM).

  • 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 ...

  • I have not used this source. Sorry.

    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.

    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.)

    Wish for Aerofly FS 2/4:

    - Flightpath recording on hard drive and replay in sim from different view points

    - Smoke for aerobatic planes

    - Multiplayer or at least watching other people flying sitting on ground or inside tower

  • 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 ! :huh:

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

    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...

    Good luck

    Antoine

    Config : i7 6900K - 20MB currently set at 3.20GHz, Cooling Noctua NH-U14S, Motherboard ASUS Rampage V Extreme U3.1, RAM HyperX Savage Black Edition 16GB DDR4 3000 MHz, Graphic Card Gigabyte GeForce GTX 1080 8GB, Power supply Corsair RM Series 850W, Windows 10 64 bit.

  • 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...

    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...

    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.

  • 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 :(

    Well my initial guess was a conflict with the Swiss DLC mesh as it was the only place where I faced this phenomenon, but it's obviously not the case.

    Even when there was a conflict, it doesn't explain the spikes, I still have no explanation...

    Anyway, I tried compiling again this small patch of mesh in Levels 9 and 10 and still get the same result :

    The source file: 5m dem NEXT from Intermap.

    The compiled area, note the masks caused by non-matching borders (the boolean switch in TMC file has no effect on mesh tiles)

    The result in AFS2

    As soon as I remove this part of mesh...

    Here's the Swiss DLC local mesh :

    If I deactivate the Swiss DLC Level 10 and 11 Tiles, leaving only the default Level 7, the spikes from my patch of mesh are still there :

    Conclusion : the spikes actually come from compiling this part of 5m DEM mesh, but I have no clue yet what's wrong with it.

    I compiled the same source in Paris and in Courchevel without any issue...

    Cheers

    Antoine

    Config : i7 6900K - 20MB currently set at 3.20GHz, Cooling Noctua NH-U14S, Motherboard ASUS Rampage V Extreme U3.1, RAM HyperX Savage Black Edition 16GB DDR4 3000 MHz, Graphic Card Gigabyte GeForce GTX 1080 8GB, Power supply Corsair RM Series 850W, Windows 10 64 bit.

    Edited 3 times, last by Trespassers (July 12, 2019 at 11:02 AM).

  • 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 !!