Question to the Taxi feature

[AUA9085]

Hi,

 

I did my first flight now with the new EFB v2 and I really like it already :) Great job! Congratulations!

 

The only thing I am a bit confused is the Taxi feature.

As I hopefully understand the manual correctly, it shows you automaticly the fastes way to the active, selected DEP runway BUT there is the posibility to "limit" the taxi way, right?

 

Example, that I am not wrong with my thinking:

LSZH, active Runway 28 like in the manual. I can enter "INNER" in the text and the tool should change the taxiway via K + A, right?

 

So, the feature is not created to show an "own" taxiway provided by ATC like "taxi via "J and A and A1"

 

I tried that too, but then this came up:

 

The taxi way was straight over the map to the runway :)

 

Just to understand that feature a bit better!

 

Thanks

[lonewulf47]

37 minutes ago, AUA9085 said:

Hi,

 

I did my first flight now with the new EFB v2 and I really like it already Great job! Congratulations!

 

The only thing I am a bit confused is the Taxi feature.

As I hopefully understand the manual correctly, it shows you automaticly the fastes way to the active, selected DEP runway BUT there is the posibility to "limit" the taxi way, right?

 

Example, that I am not wrong with my thinking:

LSZH, active Runway 28 like in the manual. I can enter "INNER" in the text and the tool should change the taxiway via K + A, right?

...

Just to understand that feature a bit better!

 

Thanks

The Taxi Feature is still considered to be in an experimental  state. Especially when it comes to use an User specified taxiroute. This is a field that we are just not able to make it work correctly under all circumstances whereas the direct routes work more or less satisfactorily. To be honest, we were tempted to discard the selectable taxiways for that very reason, but decided to leave it as it is for the moment. Just keep in mind that only the direct taxiroutes are working reliably, as long as the BGL's provide the necessary information.

[AUA9085]

23 hours ago, lonewulf47 said:

The Taxi Feature is still considered to be in an experimental  state. Especially when it comes to use an User specified taxiroute. This is a field that we are just not able to make it work correctly under all circumstances whereas the direct routes work more or less satisfactorily. To be honest, we were tempted to discard the selectable taxiways for that very reason, but decided to leave it as it is for the moment. Just keep in mind that only the direct taxiroutes are working reliably, as long as the BGL's provide the necessary information.

 

Thanks for the reply, anyway a nice little feature to right the Taxiway somewhere down with oneclick which is provide by ATC  (even its not shown correclty :D)

[KiloJuliett]

The taxi routing feature works amazingly - if the AFCAD is done properly. This again depends on the scenery designer. You may edit AFCAD files and use them according "Manual 4 Database - Chapter 2.7" to make full advantage of the functions offered by EFB.

[alpha117]

2 hours ago, Mr. ATC said:

The taxi routing feature works amazingly - if the AFCAD is done properly. This again depends on the scenery designer. You may edit AFCAD files and use them according "Manual 3 Server - Chapter 2.7" to make full advantage of the functions offered by EFB.

 

Jonas, you are a 'STAR' player; its in Manual 4 - Database -Chapter 2.7', by the way ?

 

My first question, yes could have done 'RTFM', but why has no other staff member/BETA tester not mentioned this until now??  If they had done it would have stopped all the endless threads that have been posted over the last 36hrs.

 

So, going back to the start of the issues about EFB not displaying AFCADs correctly, for whatever reasons(let not go there again!!). Here is LFBD  placed into the folder mentioned in the manual.

 

All runways are now displayed correctly, well nearly but for now its a start and 100% move forward after the saga of the last 36hrs.

 

CONS

 

1. A user must have the skill and knowledge to edit and recompile scenery AFCADS.  

2. Does not display the correct status of the runways

3. Possibility of having 1000+  duplicated AFCADs . Even though saved outside of the SIM, therefore they  have no affect on the SIM at all. In my case I must have 60+ AFCADs that I have changed so they match the real world configuration. I'm sure there will be users out there have many more than I currently have.

4. Difficult to maintain if the scenery has a scenery tool that allow AFCAD changes for different weather, or different runway configurations, EHAM as an example.

 

PROs

 

1. Allows EFB to display ALL the runways and will be correct if compared to the airport chart

 

 

Conclusion

 

Good idea but not that easy to implement for users who do not have the skills to make this work. 

 

Now, one of the Staff/Beta Tester maybe could put a manual together showing how to achieve this and add it to your documentation, just a thought.

 

 

[KiloJuliett]

2 minutes ago, alpha117 said:

its in Manual 4 - Database -Chapter 2.7'

hoops, that happens when you have all the manual open to assist others

 

4 minutes ago, alpha117 said:

but why has no other staff member/BETA tester has mentioned this until now

We have identified this as Oskar wrote. But there is no solution in sight for now as every scenery designer is using the AFCAD with his own interpretation.

 

5 minutes ago, alpha117 said:

EFB not displaying AFCADs correctly, for whatever reasons

The reason is because this runway is marked closed. If such runways would be displayed anyway in general, a lot of artificial runways would pop up on other sceneries because designers use them to tweak their AFCAD. So we have only two bad alternatives. Choosing the other one would not kill any of the CONS mentioned (only alter no.2 to read "does display a lot of not existing runways"). I hope you can understand the underlying issue following these explanations.

[alpha117]

Jonas, 

 

Why not read the R5.csv from makerunways?

 

Currently the above solution(Manual 4 chapter 2.7) will 'fix'  the 'why does EFB display not look like the chart'.  Which to be honest is good.

 

Let's be honest, all the 'average' end user wants to see is that EFB displays the same runways as a chart, they are no bothered about the status at all.

 

Job done, case closed. Manual 4 chapter 2.7 is the fix until EFB V2.5 or V3.0.   

 

All move on

[KiloJuliett]

10 minutes ago, alpha117 said:

Currently the above solution(Manual 4 chapter 2.7) will 'fix'  the 'why does EFB display not look like the chart'.

Actually, it is the solution to fix the "why scenery designers do not design the AFCAD as they draw the painting". But finally, BGL files are the only source I am currently aware of where information about the ground layout is saved in an electronic and logic format. Makerunways does also "only" interpret these BGL files. We may check with Pete whether he found a solution to overcome the dilemma we are currently in.

[alpha117]

sounds like a plan

[lonewulf47]

We currently have no plans to use Pete Dowson's makeRwys. Why?

 

1. It uses the very same source as we do

2. We are also able to completely decode BGLs

3. MakeRwys need a third party software to "find" all airports when installed with P3D's new package system

4. EFB v2 analyzes the package system using its own resources

5. The filtering method of suppressing "fake runways" is not applicable as it suppresses short runways that actually exist

 

So you see, quite few reasons why there is no need to use a third party tool which gives no benefit at all ?