Hello all,I think I may have found an undocumented feature of VoxATC, giving us a manual way of defining the MSA for a particular airport. Create in %appdata%\Internal Workings\VoxATC\apdata a new xml file using as the name the airport code (e.g. LOWI.xml). In this xml file write these (this comes from LOWI.xml):

<?xml version="1.0" encoding="utf-8"?><Airport ReplaceUnits="True">	<RoutePositions>    	<Position Latitude="N47*15.37'" Longitude="E11*20.38'" Altitude="2896" />	</RoutePositions></Airport>

Notes:- I don't know if ReplaceUnits is needed- You can get the Latitude and Longitude by opening the .pln file (assuming the destination airport is LOWI) with a text editor and getting the DestinationLLA. Just don't forget to format the value like this: "N47°15'37.00" --> "N47*15.37' ". In these attributes I set the coordinates of LOWI airport.- The Altitude is in meters, thus for a supposed MSA in LOWI of 9500 ft we write 9500/3.28=2896 approximately.Of course, gettings MSA correct is not that simple. The approach plates (at least these I have) for LOWI LLZ East Procedure 26, give us an MSA of 9500ft only when north of RTT NDB and of course in the west approach (through KTI) the MSA are a lot higher. That means that a "generic" MSA value is of course not accurate enough and that the ATC system has to take into account the actual aircraft position. I don't know if adding in the above xml various Position elements having the coordinates of high terrain and the respective "MSAs" around LOWI would make VoxATC behave differently, though I doubt it.Anyway, having a way of (at least manually) instructing VoxATC for a "generic" MSA of a particular region is IMHO an addition to the way we've been vectored until now. I could automate the procedure (writing a simple dot net program manipulating the xmls as I could do the same thing for the transition altitudes I referred to in another thread), but I will not since, this might probably violate the EULA.I'm also sure that at some point the developer(s) of VoxATC will figure out a much more advanced way of handling the MSA issue. I am certain about this (I admire his/their programming skills), I only wish they could communicate a little bit more through this (or other) forums about their plans-intentions for the future of this brilliant pice of software. Kostas

Hi, Kostas.This looks interesting. Maybe you want to write an email to the devs of VoxATC to see if they are interested too. Reading your description, a tool based reading of the MSAs would be the preferred way to go then.

Hi, Kostas.This looks interesting. Maybe you want to write an email to the devs of VoxATC to see if they are interested too. Reading your description, a tool based reading of the MSAs would be the preferred way to go then.

They obviously know it. I think we are in the middle of something here (not yet fully implemented), that's why this is undocumented for now. We'll have to wait. I'm glad they seem to actively (even though silently) work.

They obviously know it. I think we are in the middle of something here (not yet fully implemented), that's why this is undocumented for now. We'll have to wait. I'm glad they seem to actively (even though silently) work.

<RoutePosition> seems an odd name to give an attribute for MSA, but what's in a name, eh? Whatever works... works.MEF and MOCA can be determined by finding the highest elevation for an area and allowing for obstacles and for "a little extra."However for the little I know, MSAs are specific to a radius from an object associated with an approach - usually a navaid or even a runway TDZ. Quite often (in the US) MSAs for an entire set of airport approaches are defined as 25-30NM from a single point. Period. But as noted earlier, MSAs can have different values for different arcs of the coverage radius. I recall seeing lots of UK charts where MSAs are depicted as a circle split into four quadrants.There can also be MSAs "nested" within other MSA areas - giving an appearance of a bullseye. It's not uncommon for RNAV approaches (again, in the US) to split the MSA circle into semicircles or single quadrants for differing IAPs - as attached.I'm very interesting in accumulating MSA information... would anyone know of an aeronautic data source that could be used to derive MSA diagrams from??In any event, I suspect Tegwyn is making slow (but quiet) progress with VoxATC in several areas. This would be a nice area to see work done in.

You are right that <RoutePositions> is not a proper name. My thought is that this XML file gives the user an opportunity to override the default way of setting up a vectored approach and possibly these positions (with their altitude constraints) may represent a "user-defined" vectored approach route. And the highest of these positions may represent the MSA for the program. In fact, I found out tonight that the value I set there is relevant only to the initial descend from cruise altitute and it is not respected when vectored for an approach subsequently. It seems that "Full ILS" is the only suitable option for high terrain approaches, at least for now.