Start fg at holding point

[I-PZB]

Hi,

I hate start FG with plane at rwy. It's innatural and on controlled or busy (like KSFO) airports also disturbing. But for many apts (even controlled ones) there are no other points defined except rwys. One way to solve this problem is definition of parking positions and holding points for that apts (I start doing so using groundnet.xml, these xml files will be contributed, when polished, I promise).
Another way is take alredy known info about rwy and taxiways and calculate nearest holding point position and heading and place aircraft there. IMHO it shouldn't be so difficult to programming and resource consumpting task (but I can be complettely wrong, not beeing so good in C++ and not knowing FG internals well. Pls, don't vaste your time for detailed explanation, "you are wrong, it's very complex task" will be enough. Also I apologize for needless request if this question is alredy resolved in 3.2 version. I'm using 3.0). Programm flow should be: pilot asks for start on rwy XX. groundnet.xml exits? Yes, take nearest holding point. No, calculate nearest holding point. No start directly on rwy allowed.

Another two little, but not so satisfactory user experiences, linked to this question (always 3.0 version). I choose to start on rwy XX (rarely) and I'm welcomed with info 'You are on rwy XX". I choose to start on parking pos YY and I'm welcomed with info "you are on rwy <empty space>" (I'm not on rwy, I'm on parking pos, you fool )
And the second one: I move to another airport, using menu Position->Place aircraft on airport, choosing position on rwy and I'm welcomed with 2 line information "You are on rwy XX" and "You are on rwy YY" (oposite direction). I can feel myself as our Lord, omnipresent

Just my 5 cents
Ragards

Pietro
(not yet contributor, dumb tester for now)

[Hooray]

You don't need to know any C/C++ to come up with new in-sim starting options - most of these can be entirely configured in XML and scripting space - which is also how the existing dialogs work. For details, refer to $FG_ROOT/gui/dialogs and see the positiion/location or reposition dialogs. To learn the exact file names, see $FG_ROOT/gui/menubar.xml

Besides, much of FlightGear is scriptable using a JavaScript-like scripting language called "Nasal": http://wiki.flightgear.org/Nasal


I am not sure if/how well ground networks are currently exposed to scripting space though - but we can already access taxiways, and there are a bunch of helpers available in geo.nas to help with computing offset positions

[ludomotico]

There was already a discussion about your suggestion not long ago, but I can't find the thread.

Automatically identifying a holding point is a difficult task. You have to identify the right taxiway to enter the runway. For example, it may be the one at the end, or the one in the middle! So, automatically identifying holding points is by no means an easy task, it depends on the specific airport layout.

I think an easy way to calculate a holding point is looking for "the holding lines": the launcher may identify these lines and offer a start position right on them. The bad news are these lines are only defined starting from v850 of the airports and for not all of them. This means only about 30% of the airports will have these lines. Anyway, this could be an improvement and I think it is something easy to code.

Another option is manually defining a "parking position" right on the holding point. It would be a special parking position, its name should reflect this and it needs an agreement with people in the X-Plane community, since we share the same definition for parking points. These special parking positions must be created by the airport designers manually, submitted to the X-Plane community... and wait until that FligthGear imports parking positions from X-Plane! This is an easy thing to do, but it seems it won't happen in the near future due to lack of man power.

You can also combine both ideas: create a script that identifies the holding lines and adds parking positions for them in the groundnet file. In fact, I think this could be a good idea, very easy to implement and it does not need any change in FligthGear or X-Plane.

Since you are writing groundnets, be aware there are some scripts that create automatically these groundnet files from the information in the apt.dat. I'm aware of two of these scripts:

- My script : viewtopic.php?p=197351#p196239
- VaLeo's script: viewtopic.php?p=169365#p169365

It should be easy to modify any of these scripts to add a new "parking position" at the holding point of the runway by looking for "holding lines" in the apt.dat

[I-PZB]

thanks for enlightenment, ludomotico.

>Another option is manually defining a "parking position" right on the holding point.
yes, for now I do so, naming these "holdptA, B, ..." according to rwy and taxi apt shape (and looking to real charts)
Going to try these scripts, tnx for hint.

sidenote: so we must do 'submit to X-plane','wait for X-plane changes it', 'wait for fg import from X-plane' round?
What we are? Subsidiary of X-plane? (joke, obviously)

[I-PZB]

thanks Hooray, I'll look on gui/dialogs files. This is what I needed, a little hint

[Hooray]

All those dialogs are just "PropertyList" encoded XML files: http://wiki.flightgear.org/PropertyList_XML_File

The most minimal example is probably the exit dialog (exit.xml)
Otherwise, you'll want to refer to $FG_ROOT/Docs/README.gui for an introduction to FG GUI dialogs.

[ludomotico]

What we are? Subsidiary of X-plane? (joke, obviously)

Regarding anything related to airports and navigation, yes, we are. We rely on their definitions for airports and navaids. The only official way to add airport/navigation data to FligthGear is submitting the data to X-Plane. And even if we submit data to X-Plane, it takes at least two years to appear in FlightGear... if it ever does.

[I-PZB]

Ok, seems to me a little bit odd, but probably 'cose I don't know the whole history of flightgear birth and development. I'll return to this argument after reading some materials. tnx for info.

[onox]

I am not sure if/how well ground networks are currently exposed to scripting space though - but we can already access taxiways

You mean accessing taxiways from the C++ side? Are there any Nasal bindings for an XML library?

[Hooray]

sure, you can parse all kinds of XML using the helpers in io.nas - but most of the STG data is unlikely to be currently available to Nasal.
The helpers in io.nas can be used to parse arbitrary XML dialects, PropertyList-files are handled by SimGear's EasyXML

[pommesschranke]

Regarding anything related to airports and navigation, yes, we are. We rely on their definitions for airports and navaids. The only official way to add airport/navigation data to FligthGear is submitting the data to X-Plane. And even if we submit data to X-Plane, it takes at least two years to appear in FlightGear... if it ever does.

That sounds too negative to me. It is not "their definitions" . The content is produced by people who use the Tool WED to make airports for X-plane and FlightGear. Those people are users of X-Plane or FlightGear or both.
one example:
http://gateway.x-plane.com/scenery/page/EDFQ
obviously made by a Flightgear-user (his comment: "smarter airport for FGFS ")
Downloadable for everyone.
Nobody has to wait 2 years...
To use it in FlightGear I have to run genapts850(from TerraGear) once, copy some files to the correct location - that's it.
correct ?

Those files can also be submitted to Terrasync, I think

Does Flightgear support many small apt.dat files or do I have to patch the big one ?

sorry for getting a bit off topic.

[ludomotico]

pommesschranke, I didn't intend to sound negative. If I do, it is my lack of communication skills. I'm sorry for this.

The fact is the X-Plane community had the best database for airports and it was open for anyone to use. The official terrain in FlightGear available from terrasync used the X-Plane database because FlightGear doesn't have the man-power to maintain a database as huge as this. In fact, Robin (from X-Plane) was completely overwhelmed with this task and I don't know if you have ever tried to reach him, but it was a painful process that took 3-6 months. Once Robin accepted your changes, you had to wait for a new release of the database (the last version was released on October, 2013) and then wait again for a rebuilding of the world in terrasync. This process has changed, and now the scenery team is not sure if we will have access to the complete database again.

Of course, you can create a layout, build the airport and surrounding terrain and distribute a custom scenery. I have been doing this during the last two years for Argentina, Spain and now some airports in Vietnam. But most users prefer not installing any custom scenery and they use only terrasync. If you want to fix even a minor error in terrasync (for example, a beacon in the middle of a runway), then you have to wait about two years after reporting.

BTW, running genapts850 alone will NOT suffice. You still have to compute the terrain elevation (using terrafit) and, if the limits of the airport changed, the whole tile with all the landclasses (ogrdecode and tg-build). You can use the small files for genapts850. Only patch the big apt.dat distributed with FlightGear if a runway changed, or you add a new airport that didn't exist before.

[I-PZB]

to ludomotico: crazy idea (I'm sure i'm not first, who came with it) When I can add 3D objects (buildings, beacons, aircrafts, cars, rwy signs and so on) by relatively simple mechanism of .stg .xml and .ac files, why can't be whole apt done this way, adding only 2D objects for rwy, taxiways and aprons and leave terragear terrain completely "apt-less"?
Simple response "read this documentation" will suffice. Tnx.

[f-ojac]

Because elevation can be different on different places of the airport, because you can have curved elevated runways like this:

In that case the very start of the runway is below the middle of the runway. Without clipping the apt in the terrain, this would not be achievable with just 2D "patches".

[I-PZB]

tnx. I was thinking about difficulty with rwy&taxiway lights. Curved elevated strip can be modeled in Blender (yes, it's no more 2D, but can be done), but lights may be problem, IMHO. But I know almost nothing about apt building. Must study more.