MajorMike Posted January 19, 2014 Share Posted January 19, 2014 Why do I receive this message Runway assignment Warning for GATWICK. In the data provider it says that Runways 08R and 26L could not be assigned to the simulator. I am using the UK2000 Xtreme airport I have attached a link to drop box where you can see the message in the Data Provider and the Display Unit https://www.dropbox.com/sh/ww6zqf9wgimd9gz/q-Gd-BOG_6 I have updated the scenery in the scenery data update and have used the latest Airac cycle 09/01/4-05/02/14 across all the applications in my FSX. Thank-you for your help. Michael Houghton Link to comment Share on other sites More sharing options...
aivlasoft Posted January 20, 2014 Share Posted January 20, 2014 Hi Michael, did you already read this article from the FAQs: viewtopic.php?f=3&t=1260 Link to comment Share on other sites More sharing options...
PeterDowson Posted January 20, 2014 Share Posted January 20, 2014 did you already read this article from the FAQs: viewtopic.php?f=3&t=1260 I am getting a warning for my Aerosoft Santorini airport (LGSR), one which seems explicitly forbidden to correct in the Runways.txt file. The situation there is that the current NAVDATA shows 2 runways, 16L/34R and 16R/34L. But the current charts also state that runway 16R/34L is only used if activated by NOTAM and is normally used as a taxiway. I assume it is only used when maintenance work in needed on 16L/34R. The scenery implements this, sensibly in my opinion, by having 16R/34L classfied as a taxiway but depicted as a runway (but without lights and with aged dull markings). EFB grumbles about 16R/34L, but it should not -- it should allow the FS scenery setting to take precedence over the NAVDATA in this case. I'd like to explicitly state this in the Runways.txt file, but this isn't allowed -- the case is simply described as follows: C) if a runway in reality (and in Navdata) is existing, but is not available in FSX *** this case is not possible to assign *** What is really needed is the reverse of case B, like so: LGSR nil 16R LGSR nil 34L Regards Pete Link to comment Share on other sites More sharing options...
GG_Flyer Posted January 20, 2014 Share Posted January 20, 2014 Mike, What Urs was pointing out is that while UK2000 has drawn EGKK 08L/26R so that it's visible, that runway is not defined in any of the airport's BGL files. Since that's where EFB gets its airport data from, there's no way for EFB to know there's a runway there. So if we want EFB to know there's a runway there, we have to tell EFB that there is a runway there. I fancy flying in the UK, and I have several choices of EGKK sceneries (stock, traffic, Orbx, UK2000) I prefer the UK2000 scenery with its "non-specified 08L/26R" but IIRC, all other versions that I have do include that runway. I did a quick forum and AFCAD check to see if UK2000 offers a BGL that includes that runway and I didn't find one. (Perhaps I missed one.) So what I chose to do was to load the UK2000 BGL that I use (I prefer the ones with airline parking) into Airport Design Editor and I added my own runway approximately where it should go. I didn't include any lighting elements or markings or start points, and did not change the taxiway elements to connect it to the taxi network. I didn't add any approaches, and kept both ends closed for arrival and landing, so ATC won't try anything. Finally I sunk that runway a meter into the ground so it wouldn't appear in conflict with UK2000's runway textures. I compiled it to the scenery folder and "hid" the original UK2000 BGL and rescanned it with EFB. Both runways appear in my EFB and all NAVDATA procedures can be selected. [attachment=0]my egkk.png[/attachment] EFB grumbles about 16R/34L, but it should not -- it should allow the FS scenery setting to take precedence over the NAVDATA in this case. Pete, That's what EFB is doing here. EFB version 1 has always taken what I term "intangible elements" (waypoints, airways, procedures, transition altitudes) from NAVDATA. Anything that can be seen (or heard) by the user comes from the simulator and its BGLs. I see the runways listed in NAVDATA, but without much more specification than NAVDATA includes, EFB cannot draw an accurate representation of such a runway. We've tossed around ideas for EFB 2 to allow users to define certain elements independently of BGLs and NAVDATA. That would be very powerful - as well as a very tricky to implement - feature. Certain such definitions would necessarily have to be tied directly to a specific scenery for an airport. (As above, defining the runway for the UK2000 sceneries but not for others, etc.) Link to comment Share on other sites More sharing options...
PeterDowson Posted January 20, 2014 Share Posted January 20, 2014 That's what EFB is doing here. EFB version 1 has always taken what I term "intangible elements" (waypoints, airways, procedures, transition altitudes) from NAVDATA. Anything that can be seen (or heard) by the user comes from the simulator and its BGLs. Yes, I know all that. That isn't the point. I get a needless error message complaining that a runway listed in NAVDATA doesn't exist as such in FSX. I know that. I just want to tell EFB that I know it. You allow Runways.txt to tell is one way, but not the other. Why not? I see the runways listed in NAVDATA, but without much more specification than NAVDATA includes, EFB cannot draw an accurate representation of such a runway. I don't want a representation of a runway that isn't used as a runway. EFB can draw the taxiway, okay, from the data it reads from FS. That works fine. Everything was fine except for the unwanted error message that isn't necessary! You seem to have completely missed the point of my message. All I asked for was to be able to say "no runway X exists in FSX" so it won't complain that there's a mismatch. In other words, the same as you do now for "XXXX nn nil" but the other way around -- "XXXX nil nn". I thought I made that perfectly clear with the example? Regards Pete Link to comment Share on other sites More sharing options...
GG_Flyer Posted January 21, 2014 Share Posted January 21, 2014 You seem to have completely missed the point of my message. All I asked for was to be able to say "no runway X exists in FSX" so it won't complain that there's a mismatch. In other words, the same as you do now for "XXXX nn nil" but the other way around -- "XXXX nil nn". I thought I made that perfectly clear with the example? Hi Pete, You are correct. In reading your post on this thread about not including a runway in real life I totally misunderstood you. I have never read where an EFB customer has not wanted to be informed of an airport's runway update via NAVDATA. In the concept you posed against the concept we've held for EFB and EFB 2, it would not be possible to define a non-existent simulator runway to be effected or not-effected via NAVDATA. Such would simply be ignored. However I can now visualize what you posit. So in the user-defined dataset that I mentioned for a version of EFB 2, we will strive to allow for a user to define to not be informed for NAVADATA update(s) for an airport's runway(s) or such for multiple airports, etc. Link to comment Share on other sites More sharing options...
PeterDowson Posted January 21, 2014 Share Posted January 21, 2014 I have never read where an EFB customer has not wanted to be informed of an airport's runway update via NAVDATA. Well, this is perhaps a rather odd case. It is NOT actually a NAVDATA runway update It is simply a runway which isn't used as such, it is used as a taxiway. And the NAVIGRAPH charts do actually state this despite the runway being shown as a runway. You find out it isn't used as such only by reading the text -- as obviously the scenery programmer did. So in the user-defined dataset that I mentioned for a version of EFB 2, we will strive to allow for a user to define to not be informed for NAVADATA update(s) for an airport's runway(s) or such for multiple airports, etc. Thank you! Pete Link to comment Share on other sites More sharing options...
GG_Flyer Posted January 22, 2014 Share Posted January 22, 2014 Well, this is perhaps a rather odd case. It is NOT actually a NAVDATA runway update It is simply a runway which isn't used as such, it is used as a taxiway. And the NAVIGRAPH charts do actually state this despite the runway being shown as a runway. You find out it isn't used as such only by reading the text -- as obviously the scenery programmer did. Mr. Dowson, As you may know, EFB does not read the text of the NAVIGRAPH charts -- we read the BGLs primarily, and then the NAVDATA references which neither the scenery developer nor your "Make Runways" utility do... since neither of you need be concerned with NAVDATA to the extent that EFB is. For EFB 1, when the BGLs and NAVDATA conflict, we must raise the possibility of a question / conflict to remain true to all of our customers. When EFB is revised to a new version, I hope to have defined and implemented a user-defined ability to enter and ignore specific NAVDATA references so that users like yourself are not frequently bothered by conflicting data sources. Link to comment Share on other sites More sharing options...
PeterDowson Posted January 23, 2014 Share Posted January 23, 2014 As you may know, EFB does not read the text of the NAVIGRAPH charts -- we read the BGLs primarily, and then the NAVDATA references which neither the scenery developer nor your "Make Runways" utility do... since neither of you need be concerned with NAVDATA to the extent that EFB is. For EFB 1, when the BGLs and NAVDATA conflict, we must raise the possibility of a question / conflict to remain true to all of our customers. Yes, of course. All that is fine. but when the customer is aware of the difference, the missing runway in FS, why should he have to put up with a mismatch warning every time he uses that airport? The "runways.txt" file is supposed to be there so he can list the differences and avoid this bother. You've implemented it fine for other circumstances, just not the one where the NAVDATA says there's a runway which isn't there in the scenery! When EFB is revised to a new version, I hope to have defined and implemented a user-defined ability to enter and ignore specific NAVDATA references so that users like yourself are not frequently bothered by conflicting data sources. Yes, okay. I just thought it such a shame that the existing Runways.txt file couldn't be so simply amended in the way I suggested. Thanks, Pete Link to comment Share on other sites More sharing options...
Recommended Posts