Airport/runway information for ESSA incorrect

[WebMaximus]

Just noticed when looking at the airport information and more specific the runway information under the runways tab that rwy 08 is indicated as a 'No' when it comes to takeoffs but that is not correct, rwy 08 is very often used for takeoffs IRL at ESSA.

 

Not sure where this info comes from, maybe EFB will just fetch it from FSX or somewhere else but thought I would at least mention it so it maybe can be corrected.

[aivlasoft]

Hi Richard,

 

Not sure where this info comes from, maybe EFB will just fetch it from FSX

That's a value taken from the runway record in the BGL file. I guess the value is not correct. I just thought to leave it out in version 2.

[WebMaximus]

Ok, too bad the information can't be trusted because the information itself is great when you're at unfamiliar airports.

[GG_Flyer]

Those values do come from the BGL file, so AI aircraft should not use that for takeoffs, nor should MSFS ATC give that out as a valid departure runway.

 

If they do for you... then we need to re-think a lot of things.

 

Regardless, Urs and I have discussed a possible workaround for some of these values (for EFB 2 of course) where users could specify different attributes for display. (Note to Urs - yes it's 4 letters consisting of 3 different vowels. ) Such changes would not affect what MSFS ATC believes or acts upon, but would be for your (the user's) use only. It's not been implemented, so still up in the air.

[WebMaximus]

Actually I have never paid attention to this information before and it's not a biggy but I do all my flying online and when there isn't any ATC online and you're at an unfamiliar airport it's very handy if you can check what runways are used for takeoffs/landings so you don't make a fool out of yourself in front of other online traffic

 

For instance at ESSA which is my home airport rwy 26 is almost never used for takeoffs and yet I've seen people takeoff from that rwy many times simply because they are unfamiliar with the airport and it's real world OPs and I have then in a friendly way pointed this out to them and most of them are very thankful when they get this kind of info so they know for next time they fly to/from this airport.

 

I'm not sure if I understood exactly what you meant but one thing I was thinking of is if this kind of info could be editable by us the end users...then we could simply help each other by correcting all values that are not correct and in the end have a very good source of info. Naturally this requires that people would take this seriously and not just edit things "out of the blue" without first knowing for fact what they edit/enter is correct but I would like to think most of us EFB users are very serious simmers.

 

Just an idea but could be a good way to increase the accuracy of the information availiable in EFB.

[GG_Flyer]

I'm not sure if I understood exactly what you meant

That's ok, I hear that a lot.

 

but one thing I was thinking of is if this kind of info could be editable by us the end users...then we could simply help each other by correcting all values that are not correct and in the end have a very good source of info. Naturally this requires that people would take this seriously and not just edit things "out of the blue" without first knowing for fact what they edit/enter is correct but I would like to think most of us EFB users are very serious simmers.

 

Just an idea but could be a good way to increase the accuracy of the information availiable in EFB.

Yes!

 

It could be easily editable by users in the context of displaying within EFB and there are long-set plans to include such for EFB version 2.

 

However be aware that such is a function that's mainly intended as a workaround to allow EFB 2 users to enhance the data read from complex and un-editable 3rd party scenery. But not to change the scenery itself. Its main purpose is to note that certain graphic elements are present at a scenery despite not being listed as being present in the BGL itself. (For instance, if a scenery has custom runway or approach lighting in lieu of stock runway or approach lighting.)

 

I'm referring to most modern airport sceneries such as those published by (in alphabetic order): Aerosoft, Flightbeam, France VFR, FS Dreamteam, ORBX, UK2000. As well as by many others.

 

If anyone is familiar with BGL editors such as Airport Design Editor, similar data for default or freeware airports could be edited and compiled and saved in the context of the BGL files that are used by both MSFS and by EFB.

 

So for instance if you were to load your ESSA airport into a BGL editor and then to change the setting for runway 08 to permit takeoffs... then your AI would allow such... and if you were to have EFB rescan your scenery, it would also recognize such.

 

Now I know (since I checked ) that the stock ESSA airport does allow for takeoffs from runway 08. So I'll assume that you're using a 3rd party scenery (either freeware or payware). Modifying the takeoff/landing values for a runway should have no graphic impact on the scenery. (I am open for correction if someone knows different!) So I would feel fairly safe to advise you to consider backing up your primary ESSA scenery BGL and to take a BGL editor and to make the change yourself. (Or to request such from the author of your scenery if you so choose.)

 

Now I hope this has clarified things... but I think back to my first line in this reply and I fear differently.

[WebMaximus]

Actually I followed you all the way this time

 

I'm using Aerosoft scenery for ESSA and will try modifying the BGL the way you suggested.

 

Looking forward to version 2 of EFB!