FGElev does not take airport elevation into account WS3.0
FGElev does not take airport elevation into account WS3.0
FGElev cannot read *.osgb files in zipped folder structure (WS3.0)
FGElev does not work with WS3.0 on Next
Hi. I tested from C++ and Python and it works again (only tested WS3). Thank you very much. osm2city does not need solidness.
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
Can be assigned to me.
Materials plus new texture for osm2city trees
Materials plus new texture for osm2city trees
osm2city mesh buildings and random buildings have different brightness
It works - and the startup time is really negligible related to everything else. The ticket can IMO be closed. Thank you very much
It works - and the startup time is really negligible related to everything else. Thank you very much
Adding V2_ShortFloat3 for OPRF flares
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
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...
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).
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.
The points probed were all in the water/ocean. But it should still work.
FGElev does not work with WS3.0 on Next
There is no progress in osm2city to do this. I doubt whether it should be done at all - given that osm2city can generate at least the buildings in the right place, given that WS.0 will make it much easier to contribute changes to Airports and given the rendering challenges with performance for some of the features. Unless someone with either texturing or Python knowledge helps me, it will not be done in osm2city.
I have started to merge code into osm2city. The code is ported and works. However, it is a bit of a question, where it should go. there are some problematic pieces (e.g. cars) - and it is not on my list of priorities.
aircraft-qa
PC-9M test report
return bytes instead of decoded string from bytes due to encoding etc. in Emesary
Minimal correction to bool array properties
Small corrections to 2 bool array mp props according to .cxx file
Add more of the recent MP properties
Adding more recent MP properties
Default material for building lists
Adding default material for buildings lists (used e.g. in osm2city)
Saitek Pro Flight Rudder Pedals recognizing USB on Windows 10
Atlas for 2017.2 using 16k*256 size