Being aware of surrounding terrain - MSA - IFR

tomjnx wrote:

should maybe, but they aren’t. I have 212 obstacle (areas) in my EAD dump, all of them are associated to some airport, and include things like glideslope antennae and RVR measurement equipment. So it’s useless for enroute.

Well, ok… AIP-Sweden has 52 pages of enroute obstacle data. Everything higher than 328 ft (100 m).

Peter wrote:

For example Openstreetmap blocks this immediately

I’ve never seen that happening. Also, if I look at the mod_tile code, it doesn’t seem to have that capability, what it can do however is throttle bulk downloaders.

And if you don’t like what they do, you can always render the tiles yourself, everything you need is available publicly. Although I have to say importing OSM europe only into a PostGIS database was a 2 week experiment now hogging about 600MB disk space.

Peter wrote:

(fortunately OSM is not relevant to flying).

Many airports are now extremely well digitized, including taxiway labels, so you can actually use OSM as taxi chart.

This is why I like to fly with a tablet running Oziexplorer running the “real printed” VFR charts.

It is hard to find current ones outside UK and France so for that I run the last (2013) Jepp ones. For Greece I run charts from 2011. Terrain doesn’t change.

I appreciate this is not a good solution for most people because it involves obtaining maps from, ahem, useful contacts… I have totally current ones for UK, France, Switzerland and Germany. And the charts don’t rotate – they are always north-up. This solution has worked for me since my earliest trips, since 2004.

Over the Alps, for flying above an overcast, I run a special data set which is just topo data, obtained from Google Terrain using a tool called Mobile Atlas Creator. The idea is that one could head for a nice big canyon. This data download route is continually being frustrated by the data owners who don’t like bulk downloads. For example Openstreetmap blocks this immediately (fortunately OSM is not relevant to flying).

And there is NO solution for an Ipad. Ozi never did an IOS version. They talked about it but it never appeared. The Android and Windows versions are fine. The Windows one is by far the best but it limits the choice of tablets.

The shuttle radar data doesn’t do man-made obstacles but these were added into the VFR charts. They were also added into products like the Garmin 496 TAWS function – for Europe, anyway.

Not sure about that Avidyne MFD data. Read this to see how the elevations can be screwed up. The KMD550, which probably uses the same Jeppesen elevation data, contained very wrong (dangerous) terrain elevation depictions.

PetitCessnaVoyageur wrote:

But I would be happy to know, how more experienced pilots, proceed to stay aware of surrounding terrain when IMC.

Thanks. I understand what you meant now. You are right that grid MORA is your friend. And then if you are lucky enough to have a GPS that displays MSA, that is a good reference as long as the equipment does not fail.

I always note the MORA on my PLOGs for each leg.

One possibility …

Airborne_Again wrote:

all significant obstacles should be in the relevant AIP and thus (in Europe) in the EAD database

should maybe, but they aren’t. I have 212 obstacle (areas) in my EAD dump, all of them are associated to some airport, and include things like glideslope antennae and RVR measurement equipment. So it’s useless for enroute.

Actually my question was meant to be addressed to Achim and other autorouter folks, to read if they could usefully integrate grid MORA where they now use terrain height.

PetitCessnaVoyageur wrote:

Flying IFR, we never are on airways, so MEA and MOCA are of low value.

I think this would deserve further explanations.