#2657 FGElev does not work with WS3.0 on Next

[Rick Gruber-Riemer]

FGElev (latest updates from GIT on NEXT) does not work with WS3.0 scenery.

For all points around Edinburgh getting "holes in the scenery":

/home/vanosten/bin/flightgear/dnc-managed/install/flightgear/bin/fgelev --print-solidness --expire 1000000 --fg-scenery /home/vanosten/custom_scenery/WS30_UK_DDS --use-vpb
/home/vanosten/bin/flightgear/dnc-managed/simgear/simgear/props/props.cxx:285: name=SG_PROPERTY_LOCKING value=<unset> returning: 1
/home/vanosten/bin/flightgear/dnc-managed/simgear/simgear/props/props.cxx:285: name=SG_PROPERTY_LOCKING_VERBOSE value=<unset> returning: 0
Now checking for plug-in osgPlugins-3.6.4/osgdb_nvtt.so
1 -3.5 56.0
Found hole of minimum diameter 1.31072m at lon = -3.5deg lat = 56deg
1: -1000</unset></unset>

Last change in https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/utils/fgelev/fgelev.cxx by Chris Frey.

Ubuntu 20.04, download_and_compile.sh

I am using https://drive.google.com/file/d/18CfT_sVrfv6gkwp4QU7w0fHSiDabvUJk/view?usp=sharing for WS3.0 as referenced in https://wiki.flightgear.org/World_Scenery_3.0_roadmap. WS3.0 works on my computer in fgfs.

[Rick Gruber-Riemer]

The points probed were all in the water/ocean. But it should still work.

[Rick Gruber-Riemer]

Retested in Scotland with boundaries -3_55.75_-2.75_55.875 (near the border to England - Humbie: no water). Same problem.

Using Ubuntu 20.04, download_and_compile.sh on NEXT.

[Stuart Buchanan]

OK. So only 6 months late, I've had a look at this in detail. Apologies for the delay.

The fundamental issue here is that fgelev does not traverse the tree of separate files that WS3.0 uses properly. This is partly because it doesn't seem to have a proper "camera" that would trigger the PagerLOD.

I must admit that I don't understand this totally. But from experimentation, loading the L3 tile or lower explicitly using --tile-file does trigger loading of all the subtiles underneath.

Using the standard scenery settings, the resolution of the L3 tile is a 0.25x0.25 degree tile, which is probably sufficient for your needs.

So osm2city would need to identify the correct L3 subtile for the lat/lon that you wish to query and call through the fgelev to load that subtile directly:

E.g.

./fgelev --use-vpb --fg-scenery /home/stuart/FlightGear/Scenery/WS30_UK_30 --tile-file /home/stuart/FlightGear/Scenery/WS30_UK_30/vpb/w010n50/w004n55/ws_w004n55_root_L0_X0_Y0/ws_w004n55_L3_X0_Y0_subtile.osgb

The L3 subtiles are a 4x4 array across the 1x1 degree tile.

E.g. ws_w004n55_L3_X[0-4]_Y[0-4]_subtile.osgb

So ws_w004n55_L3_X0_Y0_subtile.osgb is the SW subtile (Lon from -4 to -3.75, Lat 55 to 55.25) and ws_w004n55_L3_X3_Y3_subtile.osgb is the NE subtile (Lon -3.25 to -3, Lat 55.75 to 56).

Does that work for you in the short term?

-Stuart

[Rick Gruber-Riemer]

Yes, it would work. In the perfect world you would implement most of the code in SimGear and only FGElev would only have a thin layer. The reason for this is that I could directly use the library function in SimGear in the C++ implementation of C++ (instead of calling an external process - which osm2city Python and other consumers of FGElev still would do).

[Rick Gruber-Riemer]

I have implemented a first version in osm2city. It works for most of the points searched - still getting some "Found hole of minimum diameter ...". It works as a current workaround for WS3.0.

The issue in the long run is that for areas above 62 deg latitude I need to use more than one instance of FGElev within each tile. And that if some points are just across the tile border also a separate instance is needed (resulting in 9 instances of FGElev for 1 tile.

On the other hand side: if I would do elev probing in the C++ space with osm2gear using Simgear as a library, this concern might go away.

[Rick Gruber-Riemer]

E.g. vanosten@vanosten-P17SM:~$ /home/vanosten/bin/flightgear/dnc-managed/install/flightgear/bin/fgelev --print-solidness --expire 1000000 --fg-scenery /home/vanosten/custom_scenery/WS30_FSWeekend --use-vpb --tile-file /home/vanosten/custom_scenery/WS30_FSWeekend/vpb/e000n50/e005n52/ws_e005n52_root_L0_X0_Y0/ws_e005n52_L3_X1_Y2_subtile.osgb
Now checking for plug-in osgPlugins-3.6.5/osgdb_nvtt.so
1 5.48 52.52
1: -0.007 -
2 5.35 52.52
2: -0.006 -
^C

X[0-3] is longitude, Y[0-3] is latitude

[Stuart Buchanan]

I've pushed a proper fix for this (98af3df3c6ef0d42539209363855a5dbde7070fa)

You still need to use the --tile-file argument, but just against the top level 1x1 tile:

./fgelev --use-vpb --fg-scenery /home/stuart/FlightGear/Scenery/WS30_UK_30 --tile-file /home/stuart/FlightGear/Scenery/WS30_UK_30/vpb/w010n50/w003n56/ws_w003n56.osgb

The first check will take some time to load (I have some ideas on how to speed it up but have still to implement them). Subsequent queries in the same area should be much faster.

let me know how you get on.

-Stuart

[Rick Gruber-Riemer]

It works - and the startup time is really negligible related to everything else.

The ticket can IMO be closed.

Thank you very much

[Rick Gruber-Riemer]

Unfortunately, fgelev seems to be broken again. I get the following:

($ /home/vanosten/bin/flightgear/dnc-managed/install/flightgear/bin/fgelev --expire 1000 --fg-scenery /home/vanosten/custom_scenery/WS30_MTQ_5m --use-vpb --tile-file /home/vanosten/custom_scenery/WS30_MTQ_5m/vpb/w070n10/w062n14/ws_w062n14.osgb
Now checking for plug-in osgPlugins-3.6.5/osgdb_nvtt.so
2.40 [ALRT]:general /home/vanosten/bin/flightgear/dnc-managed/install/flightgear/bin/fgelev: No data loaded

[Stuart Buchanan]

I think I have fixed this (again!)

See https://sourceforge.net/p/flightgear/simgear/ci/b66afb09e37509633018586e3273248545bc6ccf/

Note that the lookup for whether the terrain is solid or not does not work. Is this something that osm2city requires?

[Rick Gruber-Riemer]

Hi. I tested from C++ and Python and it works again (only tested WS3). Thank you very much.

osm2city does not need solidness.