Hooray wrote in Sat Aug 16, 2014 11:32 pm:like I said, it was meant to be pseudo code - but should be easy to fix, I haven't actually tested anything - it was just intended as an example to reduce the amount of redundant code.

great, if you've got any updated code that you'd like to share, I suggest to post it on the wiki so that we can help peer-review and extend the code, so that this could become the foundation for a little tutorial for people wanting to do similar stuff - alternatively, we could also add this to the upcoming newsletter. Let me know if you should have any Nasal related questions or if you need help using the wiki accordingly.

Please do not use the wiki for hosting code. Set up a Git repository and collaboratively work on it there, until it's mature enough to be pushed to fgdata. You can create a wiki article to explain the system and link to relevant code, but hosting the code itself is really much better done in a Git repository.

Don't forget that most of us know how to use git/gitorious - but many newcomers don't know anything about those tools - the wiki is much better accessible for them, and for a code snippet/tutorial, using gitorious would be overkill - In fact, even experienced contributors like Philosopher have used the wiki for collaborative code editing, without even requiring a full computer. So I wouldn't underestimate the power of the wiki as a collaborative code editing environment - especially tiny code snippets for tutorials etc should not be a problem. We have the GeSHi plugin for a reason, and as someone who doesn't mind reviewing/editing such code, I am much more likely to quickly edit a wiki section/article, than actually setting up a git clone locally - which would be "overkill" for such purposes.

Obviously, this is not about "hosting" code - it's just about getting it peer-reviewed, fixed/improved and then used in tutorials.The snippet posted previously would be trivial to re-implement using ~50 lines of code and a few comments - i.e. much better accessible than git/gitorious for people wanting to work with Nasal.

And as you know, there's plenty of "tutorial"-style code that never ends up in fgdata at all - and a number of "sidekicks" that are unlikely to be merged at all.

The code that I have shown in a previous post should be part of a tutorial, but the actual code (TakeoffRunwayAnnounceClass and LandingRunwayAnnounceClass) should eventually live in Nasal/runway_announcer.nas or something in the giant monolithic beast called fgdata.

Was there any particular method proposed for using groundnet.xml as described in the TODO wiki article? Parsing it and checking aircraft proximity to the coords of any positively parsed node's holdPointType coord is the only thing that comes to my mind.

I am complicating this needlessly. I just read some of the Honeywell RAAS documentation, which seems to not have any information about holding points or taxiways, instead it just checks the distance to the end of the runway:

4.2.2.1 Annunciation Criteria RAAS determines the runway identifier for the end of the runway that is closest to the position of the aircraft. This advisory is enabled when:

Aircraft is on the ground, and

Aircraft ground speed is less than 40 knots, and

Aircraft is within a specified distance from the runway.

NOTE: The specified distance from the runway is a function of aircraft ground speed and closure angle with the runway; a higher ground speed will result in an earlier advisory (i.e. the aircraft is farther from the runway when the advisory is provided).

For example, the minimum distance from the runway that the advisory would be provided at very low ground speeds is 1 ½ times the runway width from the runway edge to the aircraft when approaching from 90 degrees relative to the runway. As the ground speed increases, the advisory is provided farther from the runway.