Martin,
QUOTE
First, should a STAR begin with the waypoint that it originates at, or should it start with the next waypoint after that, the assumption being that you've already input the start waypoint? Maybe an example will make this clearer... there's a STAR at LOWS that starts at the RTT NDB and routes via CHIEM and a couple of DME-defined intersections to SBG VOR. When defining this STAR, should I include the RTT NDB, or should I leave it off and start with CHIEM, since RTT is probably going to be in the FMC route already, anyway? I'm asking because I've seen both styles in procedure files I've downloaded, and I'd like to know which is right.
I've taken a look at the chart from EADS, and I believe the transition you speak of, on the chart I see, is listed as:
FM TULSI via L725 to CHIEM->INSOL via T701 to SBG VOR
If this is correct, I think the best way to code these arrivals is to create each transition as a separate STAR, only because the STAR itself does not seem to have an identifier to name it as a whole.
I see the following transitions available:
TULSI
KPT
MUN
WLD
EGG
LNZ
BAGSI
RASTA
So I would do the following:
STAR TULSI FIX VISIBLE TULSI FIX VISIBLE CHIEM FIX VISIBLE INSOL NAVAID SBG
STAR KPT NAVAID KPT FIX VISIBLE TRAUN NAVAID SBG
etc. (though it would be a good idea to sort them alphabetically

)
To answer your actual question, after my long winded comments

, if a fix/navaid is listed on the procedure, it should be included. This will allow for the occasional "Proceed direct XXX than via the arrival" to be loaded directly from the ARR page of the FMS, without having to have the arrival transition entered separately.
QUOTE
Second, for navaids and intersections, is it preferable to define those myself in the procedure file (as a FIX), or should I pull them in as a NAVAID (in hopes that the AIRAC is current)? It seems a bit wasteful to redefine all of the waypoints when they're probably in the AIRAC already, but OTOH someone with an old AIRAC might not be able to use the procedures if they use recently defined waypoints. (The RNAV transitions-to-final that are now all the rage at the larger German airports come to mind... they use loads of numbered fixes called DS411, DS412, DS413 etc.) Or maybe I should compromise and define the intersections, but not the VORs and NDBs, in the assumption that the former will change more quickly than the latter?
I like to play it a bit safe. All fixes that are NOT specifically VOR's or NDB's get redefined in the individual procedure file. I agree, it may be a bit more work initially, but IMHO it allows for much greater flexibility, in addition to remaining compatible across different AIRAC cycles, as you mention.
The DS411, DS412 type fixes you mention are especially susceptible to eventual duplication, etc.
I'm considering eventually including VOR's and NDB's as well, when I find time to update the files here, as this then makes the procedures entirely independent of the AIRAC data, but I would agree that this is not entirely necessary.
QUOTE
And one more question (if I may...) -- does anyone know how the Maddog disambiguates between several NAVAIDs with the same name? I'm asking because Salzburg has a VOR named SBG and an NDB named SBG, and they're not colocated (don't ask me who came up with that). So if I pull those in via a NAVAID instructions -- what's going to happen? I'm going to play it safe and define both explicitly (they're called SBGVOR and SBGNDB in my file), but I'm curious anyway...
Of this I am not sure, as I have yet to come across this situation. Davide ?
QUOTE
Oh, and Brian -- if you could check out my procedure file when I'm done, that would be great!
I'd be glad to. I wish I could find more time to write new files, but that hasn't been possible these past weeks, so at the very least I can help give advice from what I have learned so far.