Open AIP Data

[Kjelle69]

I am aware of PocketFMS as a good option for Flightmap data in the iEfis but I wanted to see what the possibilities are for open source data.

Found this source for open data available : https://www.openflightmaps.org/es-sweden/
The maps seems to be very good and complete, the question is how do I get this data in to the vector layers in the MGL iEfis lite?

Tried to use Mapmaker2 for the raster map alternatives and MGL-Central software for the vectorised maps.

Tested to import the ARINC-424 data available from Openflightmaps into the MGL-Central software but it does not seem to work, nothing shows up.

I have downloaded the older data from http://www.mglavionics.co.za/Enigma_Data.htm and imported this sucessfully into MGL-Central but as it says it's outdated data from 2006.

Any suggestions of how to go further from here to get the open source maps available into our fantastic panels?

[rainier]

Importing the image tiles using Mapmaker2 works great for raster maps. Maps look good.

Have not tried their ARINC data - not sure what is in there. We use the ARINC import for several sources (FAA, Jeppesen, Russian data (not anymore), Airmate).

BTW, we have been working with Airmate for some time and we are close to welcoming them as data source. They will provide Navidata, raster maps and plates. Some data is free for use and some on a subscription model.

[rainier]

Downloaded some of the ARINC data from OpenFlightMaps (Germany) to see what the issue is.
These files look like they contain ARINC424 data but they are missing the header - the first line or lines should start with HDR and contain header information. This details things such as the originator of the data and specifics, also start and expiry dates etc. MGL Central needs this header to figure out what data format the ARINC data is in - this is needed as not all vendors stick to the actual ARINC424 format as specified in the ARINC data definition document and add their own variations and amendments as they need to represent their data. This is important detail so the parser knows how to interpret a lot of the information.

In addition it appears the files have been created on a linux machine so the text line endings are not what is expected - a line is to end with a CR/LF - in this case there is only a LF so the entire file is seen as a single line.

Once a header is added and the line endings corrected the file imports. But there are some issues with some of the airspaces which look pretty wild (most seem fine). I will have to dig into that. It looks at first glance that the points are not sequenced correctly.

Airports seem to import fine - runways are there and it looks like frequencies as well.

[rainier]

There is a problem related to record numbering in this ARINC data. Here is an example:

SEURUREDRED-R 132 A 00100B G N48123000E008570000 GND 18000MR ED-R 132 A (HEUBERG) 111532310
SEURUREDRED-R 132 A 00110 G N48123000E009030000 111532310
SEURUREDRED-R 132 A 00120 G N48123000E009060000 111532310
SEURUREDRED-R 132 A 00130 G N48070000E009060000 111532310
SEURUREDRED-R 132 A 00140 G N48070000E009000000 111532310
SEURUREDRED-R 132 A 00150 GEN48070000E008570000 111532310
SEURUREDRED-R 132 B 00100B G N48123000E008540000 GND 18000MR ED-R 132 B (HEUBERG) 111532310
SEURUREDRED-R 132 B 00110 G N48123000E008570000 111532310
SEURUREDRED-R 132 B 00120 G N48070000E008570000 111542310
SEURUREDRED-R 132 B 00130 G N48070000E009030000 111542310
SEURUREDRED-R 132 B 00140 G N48070000E009060000 111542310
SEURUREDRED-R 132 B 00150 G N48050000E009060000 111542310
SEURUREDRED-R 132 B 00160 G N48050000E009000000 111542310
SEURUREDRED-R 132 B 00170 GEN48050000E008540000 111542310

These are two different airspaces with similar location. The last number in the line contains a record number (first 5 digits) and a cycle date (last 4). The cycle date is from yesterday. Notice the record number is not aligned with the start of the airspace definition - it's off by two lines. MGL Central uses this number to group lines belonging to one airspace so this is all mixed up now. This is happening throughout the file and should not be this way.
The record number is supposed to be the only reliable way to store details belonging to the same group and is vital as in this case all airspace points get stored with that number as reference so when you look up an airspace in a database you know where to find the points - the record number is the index.

[rainier]

I prepended the ARINC file with a fake header:

HDR01TEST2001T 001T013200947692001 30-OCT-202006:17:37 ATM CORP CAI TEST_v17 B0268330
HDR02

And fixed the line endings to CR/LF - it then imports but the airspaces have a big issue which has to be fixed at whoever creates the source.

Fixing line endings can be done in some of the text editors - I use Notepad+ (Notepad+ is a freely available editor). Also use it to insert the above two lines.

[rainier]

OK there is a workaround for the record number - on closer look OpenFlightMaps simply increases that number by one for every line. But since there are only 5 digits they start dropping the digits to the right of the number so the whole thing is meaningless.

The workaround is luckily simple: Insert this as the header line:

HDR01FAACIFP18 001P013203831072109 18-AUG-202113:08:23 U.S.A. DOT FAA 1FBEAE69

This makes it look like FAA data - this uses a different mechanism to index the airspaces and that works with this data.

[manolo.lezl]

Hello.

My first post here. Manolo from Sevilla (Spain). I'm building an ICP Savannah S and installing MGL avionics on it.

I'm creating the AIP info from the spanish AIP to my iEFIS Lite.

I have already created:

- VORs, NDs, etc
- intersection or fixes
- airports
- obstacles

I have uploaded some Youtube videos (in spanish) explaining how to do this (and many more configurations for the iEFIS). If anyone is interested I'll give the link.

Last step is creating airspaces so I need to know the format for ARINC files. I have looked for it but I can't find anything about.

Can anyone tell me what is each parameter in those files?

Latitude and Longitude are clear, but the rest of info...

SEURUREDRED-R 132 A 00100B G N48123000E008570000 GND 18000MR ED-R 132 A (HEUBERG) 111532310
SEURUREDRED-R 132 A 00110 G N48123000E009030000 111532310
SEURUREDRED-R 132 A 00120 G N48123000E009060000 111532310
SEURUREDRED-R 132 A 00130 G N48070000E009060000 111532310
SEURUREDRED-R 132 A 00140 G N48070000E009000000 111532310
SEURUREDRED-R 132 A 00150 GEN48070000E008570000 111532310
SEURUREDRED-R 132 B 00100B G N48123000E008540000 GND 18000MR ED-R 132 B (HEUBERG) 111532310
SEURUREDRED-R 132 B 00110 G N48123000E008570000 111532310
SEURUREDRED-R 132 B 00120 G N48070000E008570000 111542310
SEURUREDRED-R 132 B 00130 G N48070000E009030000 111542310
SEURUREDRED-R 132 B 00140 G N48070000E009060000 111542310

Thank you very much.

Manolo.

[rainier]

You will need the ARINC424 document - unfortunately it is quite expensive and may not be given away.
Even with that - it will be a challenge - the format is not simple as airspaces get described usually as a series of connected shapes. The example you post is a simple one - here it uses a series of points. This often used by apps that convert from other formats - just create a lot of points to describe the airspace. It's not how it should be done as it can cause trouble. The document does not state how many points you may use but most EFIS systems (including ours) has a limitation. Ours is 400 points. The reason for that is that airspaces are active shapes - it is a challenge to calculate if you are inside or outside an airspace and how far you are from a boundary in the direction you are pointing - couple to that you have to process rapidly a lot of close by airspaces in some dense areas. The more points or the more complex the shape the longer these calculations take.

But I have started looking at the OpenAIP data myself and will be doing a direct import of the airspace data to start from their JSON format into MGL Central. I'll do the airports, navaids and obstacles after that. It seems a lot of the airport runways are not georeferenced sadly so they can't be used in our 3D views and GLS approaches.

[rainier]

www.mglavionics.co.za/Beta/MGL_Central.exe

This is a Beta preview of version 2.3. It has several changes.

Added is an import for airspaces from OpenAIP in json format. Imports for the other files (airports, waypoints, obstacles etc) are not yet functional).

Further to this it is now once again possible to use something like Google maps to define runway thresholds, flightplans etc. It works differently to before but not too bad.

History: MGL Central used Google Maps API in the past to obtain Google Earth images for display and general interaction. This service changed - MGL_Central was then adapted for the changes but not long after that it became a pay per use service and I did not sign up for this.

I have managed to adapt this now using Bing Maps which offer similar satellite views via a browser. MGL Central now will use its map window to show the Bing satellite image. You can navigate (drag, zoom etc) in the same way you would using a browser. To define a runway (after you opened the table editor for airports and selected an airport after selecting Bing maps (and you have a terrain image) - click the "define runway using clipboard coordinates). Then navigate the image to the first threshold - and right click on it - a context menu pops up. Below the coordinates you have the word "copy" - click on that. The coordinates is now in your clip board. To copy that as first threshold - Click on the "define Runway theshold 1" button and the fields should be filled in. Repeat this for the second threshold and click on "define Runway threshold 2" button. You now have the runway defined in the database - add things like surface as "tar" or "grass" etc. The runway heading is calculated. It may be out by a degree as magnetic headings have shifted over the years so check the result and edit if needed.

Outside of the runway definitions you can right click anywhere on the map and copy the coordinate - you can use that to set the position window ("get from clipboard button"). You can use the "Goto" button to move the Bing image to anywhere you like (fill in the desired coordinates first).
Right click also brings up a popup menu with a selection of things you can do with your coordinate.

You can copy coordinates from an external browser - either use Bing maps or Google Earth - both work the same here using a right click to copy the coordinates. They must be in the form 20.1224, -60.1234 (note comma and space for lat, long) for this to work. The Google Earth desktop application does not work here - open Google Earth in a browser.

So basically the full original functionality is back related to using satellite images - except it now goes via the clipboard.

[manolo.lezl]

Hi Rainier.

Yes, the ARINC424 way looks very complicated, but very interesting to be able to download airspaces from OpenAIP.

Thank you very much.