The contours of the Charlottesville AP in XPlane are such that the Approach End of runway 21 either floats above the ground if the "follows contours" setup is turned off or produces an unusable airport ramp situation if the runway is set to follow the land countours. In this latter case, the buildings on the other end of the airport are floating above the ground on one end or another and may end up partially burried in the ground if "follows countours" is enabled. Some way of producing a better flattened surface needs to be supplied for the several (many) airports that exiit this property.
If you look at the runway 21 threshold with "follows countours ON" it has difficult slope problems. If it is turned off, the aircraft landing in that problem area merely sinks into the runway and is supported by the actual countour of the ground beneath. in either case the first 500 feet of landing area is next to useless.
The actual runway, viewed with Google Earth has some 5% grdes from taxiway A and G at the RW21 threshold end of the AP. So apparently those two paths are meant as exits only and TW F is used as the access to RW21 on takeoff. By making A and G ONE WAY OFF the runway to TWay A, the XPlane Scenery is reasonably usable and I have made that change in the Taxi and will submit that mod.
Unfortunately, the airport has countour problems with the ramps which have several abrupt changes in elevation on a line parallel to the runway all the way down the ramps. This lump is such that most prop planes trying to roll over it hit their props on the ground and cannot proceed without crashing. Further back on the ramp most buildings and hangers sit whth their back sides several feet in the air because of the change in elevation.
So if you want to do any on-airport ATC operations or any taxiing, the airport needs to be used only with the "follows contors" option in Rendering turned OFF. This will generally mask any of the problems at the airport in normal operation mode.
We need an easy way to level and handle such a piece of support land for scenery problems of this kind.
Julian: From the comments which appear above it looks like Robin relocated the localizer in the 37186 version, and that the later 37237 version was never actually released. I uploaded the latest version from the 10.45 release to add the taxi paths for the AP. It turned out to be 37186. If the runway elongation to 6800 feet was made, I suspect that it is has been released in the 37186 version at the RW21 Threshold end of the runway. I believe that effects of that elongation could have caused the problem and its mismatch in the surface structure under it. In any event, the submission I made which added the taxipaths AND avoided using the A (north) and G taxiways as takeoff paths for RW21 (43055) is at least a viable solution to making the AP usable.
EBOB_MARSH
commented
in reference to scenery pack
43055on July 17, 2016 9:22 PM
Could you please tag this AP to always be flattened.?
For airports that are already released, there must be an easier way for you to make this change than for the releasing author. Otherwise the AP needs to be downloaded into WED and handled to make that change with all of the potential errors that allows.
This should save you time and assure that the design remains valid.
You must be logged in to participate in the discussion
KCHO Scenery Problems
The contours of the Charlottesville AP in XPlane are such that the Approach End of runway 21 either floats above the ground if the "follows contours" setup is turned off or produces an unusable airport ramp situation if the runway is set to follow the land countours. In this latter case, the buildings on the other end of the airport are floating above the ground on one end or another and may end up partially burried in the ground if "follows countours" is enabled. Some way of producing a better flattened surface needs to be supplied for the several (many) airports that exiit this property.
If you look at the runway 21 threshold with "follows countours ON" it has difficult slope problems. If it is turned off, the aircraft landing in that problem area merely sinks into the runway and is supported by the actual countour of the ground beneath. in either case the first 500 feet of landing area is next to useless.
The actual runway, viewed with Google Earth has some 5% grdes from taxiway A and G at the RW21 threshold end of the AP. So apparently those two paths are meant as exits only and TW F is used as the access to RW21 on takeoff. By making A and G ONE WAY OFF the runway to TWay A, the XPlane Scenery is reasonably usable and I have made that change in the Taxi and will submit that mod.
Unfortunately, the airport has countour problems with the ramps which have several abrupt changes in elevation on a line parallel to the runway all the way down the ramps. This lump is such that most prop planes trying to roll over it hit their props on the ground and cannot proceed without crashing. Further back on the ramp most buildings and hangers sit whth their back sides several feet in the air because of the change in elevation. So if you want to do any on-airport ATC operations or any taxiing, the airport needs to be used only with the "follows contors" option in Rendering turned OFF. This will generally mask any of the problems at the airport in normal operation mode.
We need an easy way to level and handle such a piece of support land for scenery problems of this kind.
Julian: From the comments which appear above it looks like Robin relocated the localizer in the 37186 version, and that the later 37237 version was never actually released. I uploaded the latest version from the 10.45 release to add the taxi paths for the AP. It turned out to be 37186. If the runway elongation to 6800 feet was made, I suspect that it is has been released in the 37186 version at the RW21 Threshold end of the runway. I believe that effects of that elongation could have caused the problem and its mismatch in the surface structure under it. In any event, the submission I made which added the taxipaths AND avoided using the A (north) and G taxiways as takeoff paths for RW21 (43055) is at least a viable solution to making the AP usable.
Could you please tag this AP to always be flattened.? For airports that are already released, there must be an easier way for you to make this change than for the releasing author. Otherwise the AP needs to be downloaded into WED and handled to make that change with all of the potential errors that allows. This should save you time and assure that the design remains valid.