Well several reason behind that. I know I managed to reduce the jams at LFPG with the following steps
- Do not let planes pick their routes by imposing one-way traffic on certain taxiways
- Using the above create smaller circuits to get in/out of aprons, onto major 'highway like' taxiways. on certain aprons I have only one way in but multiple ways out so that clearing happens faster.
- Dedicate/assign separate runways to take off and landing in the rwyuse.xml file
Beware of the content of your traffic files. Older files have a lot of daily flights coded via 7 entries (one per day) each with a "week" repeat tags this results on your monday plane sitting idle at a gate for a week, waiting for its next monday rotation and blocking new arrival's parking spots. Before I rebuilt it, I had to remove the default Air France traffic file (and ban AF from landing in Paris CDG ... ) just so that other airlines could use the airport
Final (biggest) reason behind clogging in my experience -but just a gut feel- It looks like arriving aircrafts have their taxiing route (from rwy to parkpos) reserved for them way ahead of their actual landingso I also have pushed back aircrafts sitting idle until said arriving aircraft has actually reached its parking spot which can take some serious time. I believe Durk is currently looking at fixing the AI code in relation to planes no longer taking off in v2016.1, hopefully this last one is also on his radar.
Now, for Edinburgh, it looks like you really have no option to trick the groundnet. See below : For each Apron you have over 10 parking positions all fighting for a single access both in and out so clogging is here to stay, I also had a look at the Runway usage file and both runways are set to available for both landing and take off in both directions. I wouldn't mess with the rwyuse at this point given the runways are not parallel and I believe FG picks the one to use for each aircraft movement based on (changing) wind.
Sorry I can't be more useful to resolve this one