Re: [Flightgear-devel] Mapping Airspace
On 09/19/2011 04:07 PM, HB-GRAL wrote: To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html I need probably some advice from real pilots around here for what is useful to map for FlightGear airspace, and how this should be displayed. I think I am aware of regular ICAO graphics definitions etc. But I dont want to design well known (and also free available) maps, I just want to develop a design as a overview and some really necessary items i.e. for learning the basics or whatelse. There is no RFC for what I am doing here, I am just playing around with data and an new Mapnik Server and ask for discussion and contribution. (Notice, my new signature since I send this links to the list and elsewhere: Please do not use any of this material for real navigation! NEVER. Do only use this to help developing and improving the design of my maps ;-). A few remarks: 1) Real pilots are concerned about airspace, but they are also concerned about terrain and obstructions. Also weather and winds aloft. You don't want to follow the example of Cory Lidle and his instructor. Their flight path was compressed by airspace and they ended up flying into the side of a high-rise apartment building. Violating the airspace would have been a better choice. 2) It is good to provide disclaimers, and people should take those seriously. However: 2a) Pilots are trained to cross-check everything, and never rely on a single source of information. 2b) People *are* going to use whatever maps they can get their hands on -- in conjunction with other information -- to help with real-world flight planning and training. For example, I commonly use FlightGear to familiarize myself with the IFR approach procedures and other details before flying into an unfamiliar airport. Of course I crosscheck the apt.dat description of the airport against satellite photos et cetera. Discrepancies abound, as previously described. 3) Interactive computerized maps offer some treeemendous advantages. For one thing, the ability to turn layers on and off is very powerful. The total amount of detail that is /sometimes/ useful is more than can be shown on any one map. Here's a rough scenario, aka use case: 1) Turn on airport names (not just 4-letter identifiers) because I have not memorized every identifier in the world. 2) Sketch a rough route. 3) Turn off the names, to declutter the map. 4) Turn on navaids, intersections, and fixes, so as to facilitate defining the route in terms that can be used on an ATC flight plan. 5) Turn off everything but the route and the terrain, to see what sort of obstructions there are. 6) Apply safety margins required by regulations. Apply additional personal margins. 7) Revise the route to get around the worst of the obstructions. 8) Cross-check against the VFR sectional, IFR enroute chart, et cetera. 9) Go back to step 4 and iterate. 10) Turn on weather and winds aloft. *) et cetera. Note that I have a tool that not only highlights the route centerline, but also the /corridor/ extending some distance on either side. For example, a half-width of 4 nm is relevant to FAR 91.177. http://www.av8n.com/fly/grass-intro.htm#fig-colored-fix-pass These tools are painfully difficult to use. The only thing that would be worse would be not having them. Flight planning is relatively easy if you stick to IFR airways, but sometimes in mountainous regions (e.g. Alaska among many others) this can lead to insanely high MEAs (minimum enroute altitudes). As soon as you start planning an off-airways flight, trying to do it just by penciling in lines on a chart is exceedingly laborious and error-prone. So, you have to decide what you want to do. You could go for a map that is merely pretty to look at ... or you could go for a map that is actually useful. One more thing: You don't want to go too far with the disclaimers. Lives are at stake, and /not/ providing information can be just as much of a problem as providing not-quite-perfect information. CFIT i.e. controlled flight into terrain makes a large contribution to the fatal accident rate. Sometimes a contributing factor is compression between airspace or weather above and terrain below ... but sometimes it just comes down to bad planning and really bad luck. Providing something that helps with this would be a Good Thing. Again: It doesn't have to be perfect. Note that the FAA provides (via contractors) a service that will prepare a computerized flight plan for you. There are scenarios where you can file such a flight plan, get cleared As Filed, and fly it as cleared ... and fly right into the side of a mountain. Hence the need for cross-checking. This
Re: [Flightgear-devel] Mapping Airspace
When I ran the research flight simulator for a major aircraft manufacturer in the UK (many moons ago when we still had such an industry), we had a saying:- Ask 10 test pilots for their opinion, and you will get 10 different answers The same will apply here. Someone who is interested in commercial airliners will have a different view from a light aircraft pilot who wishes to hone his IFR techniques, or from another light aircraft pilot who want to know how to fly VFR in a congested area, or from a military pilot. etc. etc. etc. The gamers probably don´t understand what you are asking. They just need a pretty map so that they can find the way back to an airfield. Keep up the work, it looks like a very good start. I would suggest that you keep as close as possible to a common format, either one that is available in printed form, or as represented in a modern glass cockpit. As most users are limited to small PC screens keep it uncluttered, or allow information layers to be turned on and off. Alan -Original Message- From: HB-GRAL Sent: Tuesday, September 20, 2011 12:07 AM To: FlightGear developers discussions Subject: [Flightgear-devel] Mapping Airspace Hi all To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html I need probably some advice from real pilots around here for what is useful to map for FlightGear airspace, and how this should be displayed. I think I am aware of regular ICAO graphics definitions etc. But I dont want to design well known (and also free available) maps, I just want to develop a design as a overview and some really necessary items i.e. for learning the basics or whatelse. There is no RFC for what I am doing here, I am just playing around with data and an new Mapnik Server and ask for discussion and contribution. (Notice, my new signature since I send this links to the list and elsewhere: Please do not use any of this material for real navigation! NEVER. Do only use this to help developing and improving the design of my maps ;-). Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
Dear everyone,
a day late and I must admit the first version of the script really
wasn't what it was supposed to be, but here is the final version now.
Verified and tested on a small reproduction of FGData, example repo has
been uploaded[1].
The instructions have changed, no more tmpfs is required. Just browse
into your FGDATA, make sure the working dir is clean, and run the script
(which necessarily lies outside of the FGDATA dir).
There is one tiny problem which I was not entirely able to solve, that
is that not all tags appear to be sucessfully transfered. I must insist
though, that this is a negligible issue and given the project at hand,
clearly acceptable. In the worst case we will have to reset the few tags
on FGDATA were required.
In order to run the script on the example repo instead of the real
fgdata to check for yourself, you will have to change the settings
ac_dir and canonical as indicated in the first lines of the script to
the commented-out versions.
[1] http://ompldr.org/vYWZydg
#!/bin/bash
iodir=/tmp/fgsplit
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
ac_dir=Aircraft
canonical=origin/master
#canonical=master
#ac_dir=Aircrafts
#dornot2d=-d $iodir
bare=--bare
echo
Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!
WARNINGS
Make _ABSOLUTELY SURE_ that you are in the right repository
Running this script in a wrong repository will have unpredictable
results!
Make sure to have $iodir mounted as tmpfs with all the storage
that you can spare, at least the size of the tree, which is 6GB
All data in the following directories will be purged, if they
already exist:
$final_ac $final_fg
NOTE
_NO_ irreversible changes will be made to your local repository
The resulting 'split' repositories after the spit can be found in
$final_ac
and
$final_fg
If satisfied with the results you can then delete this very repo
Which will, of course, seal the deal and make it irreversible
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
echo Removing $final_ac $final_fg and $iodir
rm -RI $final_ac $final_fg $iodir
mkdir -p $final_ac $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout $canonical
echo Creating branches for all aircrafts
for acf in ./$ac_dir/* ; do
ac=${acf#./$ac_dir/}
acbn=SPLIT-$ac
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
echo Skipping $ac
continue ;
fi
echo Going onto canonical master
git checkout $canonical
echo Branching for $ac ;
git branch $acbn
echo Switching to new branch;
git checkout $acbn
echo Isolating, please wait;
git filter-branch -f $dornot2d --subdirectory-filter $ac_dir/$ac
(
echo Extracting into new repository
cd $final_ac
mkdir $ac
cd $ac
git init $bare
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout $canonical
echo Branching for reduced FGDATA
git branch SPLIT-CORE
git checkout SPLIT-CORE
echo Isolating, please wait
git filter-branch -f $dornot2d --index-filter git rm --cached --ignore-unmatch
$ac_dir/*
cd $final_fg
echo Extracting into new repository
git init $bare
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
echo Done. Please verify the results.
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgadmin fails to compile
Hi again fgadmin also fails to compile, here is the output I get with GCC: --- $ make Making all in src make[1]: Entering directory `/home/quix0r/fgfs/build/fgadmin/src' make all-am make[2]: Entering directory `/home/quix0r/fgfs/build/fgadmin/src' ccache g++ -DHAVE_CONFIG_H -I. -I../../../fgfs-base/flightgear/utils/fgadmin/src -I/usr/include/freetype2 -D_THREAD_SAFE -D_REENTRANT -g -O3 -fPIC -MT fgadmin_funcs.o -MD -MP -MF .deps/fgadmin_funcs.Tpo -c -o fgadmin_funcs.o ../../../fgfs-base/flightgear/utils/fgadmin/src/fgadmin_funcs.cxx ../../../fgfs-base/flightgear/utils/fgadmin/src/fgadmin_funcs.cxx: In member function ‘void FGAdminUI::install_selected()’: ../../../fgfs-base/flightgear/utils/fgadmin/src/fgadmin_funcs.cxx:258:25: error: aggregate ‘FGAdminUI::install_selected()::stat info’ has incomplete type and cannot be defined ../../../fgfs-base/flightgear/utils/fgadmin/src/fgadmin_funcs.cxx:259:48: error: ‘fl_stat’ was not declared in this scope make[2]: *** [fgadmin_funcs.o] Error 1 make[2]: Leaving directory `/home/quix0r/fgfs/build/fgadmin/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/quix0r/fgfs/build/fgadmin/src' make: *** [all-recursive] Error 1 --- Roland signature.asc Description: This is a digitally signed message part -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An extension to --parkpos
On 17 Sep 2011, at 21:45, Stuart Buchanan wrote: /sim/dimensions/radius-m /sim/aircraft-class ? It might be worth having this multi-valued, so classes such as WWII fighter can be identified bit as mil-combat, and WWII. Looking at the -set.xml and Liveries/*.xml files in our aircraft database, I think that it should be possible to implement this the way you suggested. The radius parameter can go into the -set.xml, and the reasonable defaults could also be provided there for the /sim/aircraft-class. Then it looks like the essential function that the Liveries/*.xml files to is override some default values of properties, so it should be easy to implement this. I think I would like to settle on the property names as you proposed: /sim/dimensions/radius-m /sim/aircraft-class /sim/aircraft-operator (which has a slightly broader connotation than airline). In addition, I would propose adding a fourth property: /sim/dimentions/parkpos-offset-m As pointed out in the forum, aircraft don't always park correctly at the right location, so it would be desirable to specify an offset, which places the aircraft with the nose wheel at the parking. I'm awaiting furhter comments. I'll probably make a testcase by adding these properties to the 777-200ER (locally, just to test), and if there are no objections, I'll investigate if there is a way to automate the adding some reasonable default values of all our aircraft in the git repositories. (We have 519 -set.xml files, 821 Liveries/*.xml files). cheers, Durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] proposal: new keybing to show map
Hi, I was wondering why not to have a keybinding to show the map under equipment section... something like ALT + m to be added to the keyboard.xml. I have found the map useful, specially for a short look out, which if best used using a key press. Here my xml adding to the keyboard.xml if ok. key n=109 namem/name descShow map/desc mod-alt binding commanddialog-show/command dialog-namemap/dialog-name /binding /mod-alt /key Cheers Francesco -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] proposal: new keybing to show map
On 20 Sep 2011, at 19:35, Francesco Angelo Brisa wrote: something like ALT + m to be added to the keyboard.xml. I have found the map useful, specially for a short look out, which if best used using a key press. Here my xml adding to the keyboard.xml if ok. key n=109 namem/name descShow map/desc mod-alt binding commanddialog-show/command dialog-namemap/dialog-name /binding /mod-alt /key Sounds fine to me, the only reason I didn't add a binding originally, was worry that every possible key combination was assigned by someone to something already :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
Hi all, In referral to my previous posting: Can anybody tell me (or point me to documentation) how I can specify new property in an aircraft -set.xml file, and ensure that any changes to this property are saved in an aircraft specific data file. As an example in the 777-200ER-set.xml, I have specified /sim/aircraft-operator=NONE, and in the three Model/Livery xml files (DAL, BA, and KLM, I change this to the corresponding 3-letter ICAO code, and I want to save this property to use in the next session. While I run flightGear, I can see that the property has the right value, (i.e. KLM, BAW, or DAL, depending which livery file is loaded, but the problem is that during startup and runway assignment, the value is still listed as NONE. I've been playing with various versions of archive, and userarchive, but to no avail. Any hint would be appreciated, as this seemingly trivial problem is driving me nuts. Simple pointers to documentation of the PropertyTree xml do's and don'ts are also welcome. :-) Cheers, durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG hangs on loading scenery when using many objects
Hey group, I've come across a problem with FG when many (static) objects are to be loaded on FG startup. Usually, on my (faily old) PC FG loads for about 20 seconds, then says loading scenery for about 6 seconds, and places me in the c172 ready for takeoff. During all this CPU load is at 100%. Now if I start FG with scenery that contains many ( 1000) objects, I get the following: - FG still loads for about 20 sec, then says loading scenery - about 3 seconds later, CPU load drops to ~20% and stays there - and FG never finishes startup --log-level=debug shows the main loop is running, I can use the menu, but I never end up in the c172, nor see anything else but the splash screen Starting at a nearby airport and flying into said scenery works. I can also teleport to this nearby airport while FG 'hangs', and then fly into said scenery flawlessly. I've created a test scenery [1] which uses TNCM terrain and 5000 instances of one object, furthermore, a script which lets me reduce the number of objects in the .stg. If I use 3100 objects, everything is fine. 3200 objects, and FG hangs. 100% repeatable, though I did not narrow down the threshold number further. However, the threshold number seems to depend on - the object(s) loaded - CPU load: If I have another process running (mplayer, for example) which consumes some CPU, FG now also hangs for the 3100 objects case (which would otherwise load fine if there was no other demanding process). It appears as if FG somewhat locks up if the initial scenery is not loaded within a certain wall clock time. Any ideas? Cheers, Tom - Git from 5 Sep 2011 - Gentoo Linux - GeForce 7600 GS (running ancient nvidia drivers 180.29) fgfs --prop:/sim/frame-rate-throttle-hz=30 --disable-random-objects --geometry=1920x1190+0+0 --atlas=socket,out,1,localhost,5500,udp --fg-root=/home/tom/daten/fgfs/src/fgdata --season=summer --fg-scenery=/home/tom/fgfs/home/Scenery-Manual:/home/tom/fgfs/home/Scenery-TerraSync:/home/tom/daten/fgfs/src/fgdata/Scenery:/home/tom/fgfs/home/Scenery-1.0.1 --aircraft=c172p --airport=TNCM --log-level=alert --prop:/sim/rendering/multi-sample-buffers=true --prop:/sim/rendering/multi-samples=2 --prop:/sim/ai-traffic/enabled=false --prop:/sim/traffic-manager/enabled=false --prop:/sim/atc/enabled=false --timeofday=dawn --enable-real-weather-fetch --control=joystick --disable-auto-coordination [1] http://www.mediafire.com/?n9uftx7vil98btz signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
On Tuesday 20 September 2011 23:25:51 Durk Talsma wrote: Hi all, In referral to my previous posting: Can anybody tell me (or point me to documentation) how I can specify new property in an aircraft -set.xml file, and ensure that any changes to this property are saved in an aircraft specific data file. As an example in the 777-200ER-set.xml, I have specified /sim/aircraft-operator=NONE, and in the three Model/Livery xml files (DAL, BA, and KLM, I change this to the corresponding 3-letter ICAO code, and I want to save this property to use in the next session. While I run flightGear, I can see that the property has the right value, (i.e. KLM, BAW, or DAL, depending which livery file is loaded, but the problem is that during startup and runway assignment, the value is still listed as NONE. I've been playing with various versions of archive, and userarchive, but to no avail. Any hint would be appreciated, as this seemingly trivial problem is driving me nuts. Simple pointers to documentation of the PropertyTree xml do's and don'ts are also welcome. :-) Cheers, durk Adding archive=y to the property tag?: new-archived-property archive=ymyprop/new-archived-property -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
Am 20.09.2011 22:25, schrieb Durk Talsma: how I can specify new property in an aircraft -set.xml file, and ensure that any changes to this property are saved in an aircraft specific data file. Just add this to you aircraft's nasal code so it gets executed once during startup. aircraft.data.add( /one/property, /another/property, /and/another/property ); Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
To agree with Alan, but with some additional generalizations. On Tue, Sep 20, 2011 at 2:25 AM, Alan Teeder ajtee...@v-twin.org.uk wrote: When I ran the research flight simulator for a major aircraft manufacturer in the UK (many moons ago when we still had such an industry), we had a saying:- Ask 10 test pilots for their opinion, and you will get 10 different answers 1. IFR commercial pilot: airspace is completely irrelevant as they fly the clearance from ATC, initially filed by another airline individual who is not a pilot. 2. IFR general aviation pilot: airspace is only of interest on the ground when designing a clearance request that will be typed into the web terminal. 3. VFR commercial pilot: Almost irrelevant as tends to operate in areas without airspace restrictions or with full ATC coordination on an ad-hoc basis. 4. VFR cross country pilot: Interested in airspace, but usually just wanting to know where it is, to fly far around it. 5. VFR visiting pilot: Intensely interested in airspace, wants the simulator to help him learn not to accidentally bump into it. 6. VFR local pilot: Probably has it memorized anyway, owns the chart mostly to be compliant with the rules. 7. Antique / simple homebuilt pilot: Doesn't have radios or the like anyway, simply needs a few circles marked 'mode C veil'. 8. Military pilot: Doesn't use civilian charts. Could be fun to have the MTR details transcribed for simulating those fighters. 9. Shuttle pilot: I could ask if needed, but I suspect they count as [2] since they're in class A airspace until the final brick-like landing. 10. Aerobatic pilot: The boxes. And something on the simulator to be sarcastic when you accidentally leave the box. 11. RC pilot: No idea. Curt? 12. ... who is missing from the list? From: HB-GRAL To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html Lovely, keep up the good work. The comments above are intended to clarify and not discourage. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
