Activity for Rick Gruber-Riemer
-
Rick Gruber-Riemer posted a comment on ticket #2782
As of 2024.1R3 still the case - but difference is smaller. Also tracked as https://gitlab.com/osm2city/osm2city/-/issues/206 in osm2city.
-
@gijsrooy: can you change the status somehow to closed?
-
Need to wait and see when a new world scenery is built and added to Terrasync. WS3 will be much better, because then more recent airport layouts can be used. I cannot do more about this.
-
It is hard to control, which parameters are used, when scenery is generated. I have made some parameters to be a bit more conservative by default (because most scenery generated is not changing the defaults) and have added a parameter, which by defaults uses the whole airport boundary for overlap check (however, whether or not an airport has a good airport boundary, is another question).
-
I can help with carrier testing this one - also MP carrier - however I do not understand the error (or it is not fixed). Using latest 2024.1.1 compiled this morning. When I start at KSFO and change to tower view, then it it the view from KSFO tower. When I continue to fly, use Location->Tower View, then uncheck the "Always use closest", change the ICAO to KOAK and then hit the OK button, the view is still from KSFO tower - I would have assumed that the view then changes to KOAK tower.
-
FGElev cannot read *.osgb files in zipped folder structure (WS3.0)
-
I can confirm that it is working. thank you very much.
-
osm2city mesh buildings and random buildings have different brightness
-
Once 2024.1 and Next are stable I have to compare again. Lots of changes have been done in random buildings - but merge is not complete yet.
-
I will have to test. Should be solved, but let us see the newest world build.
-
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
1
