-
-
Notifications
You must be signed in to change notification settings - Fork 58
Calibrating Mercator Maps
An image or PDF of a chart with Mercator projection can be used as a georeferenced map source in the Map App or as a georeferenced chart in the Airport App. The chart must be calibrated/georeferenced before the current aircraft position can be overlayed. In Avitab, a chart is calibrated with a .json file. which provides the required georeferencing metadata. For the Map App, a sibling .json file with same basename as the chart file is given preference for the calibration metadata. From Avitab 0.6.1 on, a decoupled .json file can also be associated with a chart file via its sha256 hash. A search for a hash-matching .json file is performed in the Map App if no adjacent .json (or .kml) file is found. A search for a hash-matching .json file is always performed for the Airport App.
The .json metadata file can be created by Avitab in the Map App, with manual calibration. It can also be automatically provided by Little Navmap when exporting a map section to Avitab. It can also be derived from a .kml file if the chart has been georeferenced via image overlay in Google Earth and then exported to KML.
Avitab can now handle arbitrary chart rotation, so charts no longer need to have grid north aligned with a horizontal or vertical axis. For users familiar with older versions of Avitab calibration, a third data entry is now required to define the rotation, but this is pre-filled as default '0' (degrees), which just needs to be accepted if north is (usually) up on the chart. Ideally though, this third data entry is a third lat/lon reference point and the rotation is calculated.
Charts can also be pre-rotated (N * 90) during calibration to resolve portrait/landscape orientation, which is stored as part of the .json meta-data.
Avitab does not handle Lambert projection charts yet, but in some cases a useable approximation can be calibrated. This approximation is sufficient for flight simulation purposes where a sanity check / visualisation is required to back up navigation by instruments.
Manual calibration inside Avitab must be performed in the Map App. The Airport App can show already calibrated charts, but does not support the calibration process. You first have to indicate the position on the map of two reference points along with their lat/long position. A third data item is then required which may be either a third lat/long position or a rotation angle.
A Mercator chart can be loaded into Avitab without immediately needing calibration. But once the track icon is pressed to overlay aircraft position, Avitab will check for a .json or .kml metadata file. If neither of these are present, the user will be asked to calibrate the chart. Click OK to dismiss the pop-up.
Before selecting the first reference point, a rotate button can be used to rotate the chart with 90 degree steps in order to resolve portrait/landscape orientation. This button disappears after the first reference point is defined.
Avitab will show a red square first. Centre it above a known location on the chart and enter its lat/long coordinates, then click the tracking icon again. In some cases, it may be easier to enter coordinates first, then centre it. If the coordinates are correctly formatted, the square will turn blue. Move the square to a different location and enter its coordinates, then click the tracking icon again.
The square then turns green and can be similarly taken to a third lat/lon to define a third reference point. Alternatively, the third data entry may be a rotation angle, which is the north offset angle of the chart. For a chart with north pointing towards the right, this would be a positive value. North pointing towards the left of a chart would be a negative value. Once the third data item has been entered, the .json metadata file will be created alongside the chart file and a plane can be tracked on the now georeferenced chart. Entering three lat/lon references usually seems to give better calibration results than a third angle, even when North is up.
During calibration, if the track icon is pressed when the coordinates field is empty, the coordinates field will be populated by the current aircraft position. Press the track icon again to submit these coordinates. This can help if there is a reference point where lat/long is unknown, but to which the user can fly/taxi/slew.
After calibration, verify the correctness and accuracy of calibration by enabling airport/nav/waypoint/POI/VRP overlays and/or flying/taxing/slewing the plane to known reference points.
Coordinates may be entered in decimal, DMS or DM format. Coordinates are often provided on the chart itself, but table/website/database lookup is sometimes required. For some chart types, coordinates but can be deduced from eyeballing and matching features in satellite imagery. Using Placemark in Google Earth Pro helps.
Degrees only, with an optional decimal point. Use a comma (with optional space) to separate lat and long. Coordinates may be prefixed with a '-' sign to indicate S or W.
53.8019, 10.7017
51.469, -0.465
Degrees, minutes, seconds. e.g. 58°12'13.18"N, 6°19'43.68"W. This is sometimes seen in charts without separators. e.g. 581213.18N 0061943.68W. Note that the latitude has 2 digits for degrees while longitude has 3 digits for degrees. Minutes and seconds fields must be less than 60 and only the seconds field may contain a decimal point.
Enter DMS into Avitab using a comma (with optional space) to separate lat,long and use a single space as a separator between the DMS fields. Prefix '-' to indicate S or W. e.g.
58 12 13.18, -006 19 43.68
58 12 13,-6 19 43
Similar to DMS, but there is no seconds field. The minutes field must be less than 60. DM format is typically used when reference points come from a grid on the chart, so a decimal point is not typically required. e.g.
58 12, -6 59
55 00, -005 00
An airport ID or nav ID can be entered into the coordinates field. If matched, the coordinates field is re-populated by the associated lat/long. This lat/long then needs to be submitted by clicking the tracking icon again.
For airports, this must be the unique 4 letter ICAO code : e.g.
EDHL
KORD
Navaid IDs may not be unique worldwide, so navaids and waypoints must be entered as "ICAO-region,id", with no space : e.g.
EG,TLA
K5,BENKY
Those nice guys over at Little Navmap have added the ability to export a section of a map along with the required .json metadata file used by Avitab. In Little Navmap, enable required overlays such as airport diagrams, navaids and airspaces to get the view required. Then use File -> Save Map As Image for Avitab ... to get a .png file and the associated .json metadata file.
Little Navmap has the ability to overlay a Google Earth .kml onto its map. However, at the time of writing this overlay does not appear on the exported PNG.
Google Earth Pro (free) has a feature that allows an image to be overlayed onto its map, adjusted to fit and the georeferencing metadata to be exported to a .kml file. When the Avitab plane sync icon is pressed and Avitab finds no .json file but just an associated .kml file, then that KML is used for calibration. An equivalent .json file is written out and takes priority next time the chart is loaded.
Google Earth Pro does not accept PDF as an overlay, so a PDF chart will need to be converted to PNG first. GIMP is a good, free, multi-platform, open source application that can take care of this conversion.
In Google Earth, zoom in to the rough area for the chart then Add -> Image Overlay. Browse to the recently exported .png file and align it. Use the diamond to rotate, centre to move, corners to resize. When resizing, use the shift key to ensure aspect ratio does not change. Once aligned, close the Properties panel and right click on the item to export to a .kml file.
Although the subsequent KML will refer to the intermediate .png file, Avitab does not read this .png link. In order to render the higher quality of PDF, the .kml file should be named to associate with the original PDF file. e.g.
EGSS_Stansted_Parking.pdf
EGSS_Stansted_Parking.pdf.kml
There is one special case for KML import. If a PDF chart has incorrect orientation, the first step in manual calibration would be to pre-rotate. This pre-rotate step is not represented in the .png related KML. So if an orientation fix is needed, then:
- In GIMP, rotate to fix orientation before exporting to PNG
- Georeference the PNG with Google Earth Pro and export to a .kml file
- Load the PDF into Avitab to create the .json file from the KML
- Edit the value of the "prerotate" tag in the .json file to fix orientation
- Reload the chart
Calibration inside VR can be awkward, both in terms of accurately placing the calibration cursor and entering coordinates. Calibration outside of VR, using the keyboard, may be easier.
If possible, 3 reference points usually give better calibration than 2 points and an angle, even when North is up.
The 3 items of data entered during calibration form a triangle. For 3 sets of lat/lon, the triangle formed is obvious. If entered as 2 lat/lon + angle, then the triangle is formed AFTER a rotation has been applied to align chart north with grid north. The triangle is formed by the line between the 2 rotated points, a horizontal line and a vertical line. The 3rd derived point is on a right angle.
The calibration triangle needs to have a large enough area and be "fat". If the triangle is too small an area or too thin, then calibration may be inaccurate or maybe even impossible. The triangle area and fatness are checked against limits during calibration. If unsuitable, a warning/error is shown to the user and further details can be found in the Avitab.log. However, these limits are set fairly low and calibration can be OK with quite small or thin triangles.
Avitab always shows a pop-up after first manual calibration to inform the user of the result of the calibration. By default, this is also shown when a calibration metadata file is loaded. In the Avitab.prf preferences file, show_calibration_msg_on_load can be configured to show/hide the full calibration result pop-up when a Mercator chart is loaded into Avitab. If set to false, a basic "Chart is georeferenced" popup is shown.
...
"general": {
"prefs_version": 1,
"show_calibration_msg_on_load": true,
"show_fps": true,
},
...
Overlays may be enabled in the Airport App by setting the following in the Avitab.prf file. The overlay config is borrowed from those in the Map App.
...
"show_overlays_in_airport_app": true,
...
A SID/STAR/Approach chart may have a sparse lat/long grid and not enough reference points to calibrate. Load the PDF into GIMP and manually draw additional horizontal/vertical lat/long lines between the sub-ticks that often run along the margins. Export to PNG and calibrate as normal. Rename the .json to associate with the original PDF.
A chart may use Lambert projection rather than Mercator. A hint for Lambert would be curved latitude lines and straight but diverging longitude lines. If the warp from Mercator is slight, approximating the calibration with Mercator is generally OK for flight simulation purposes. However, in this case, it is preferable to reference using the waypoints and navaids that are part of, or close to, the SID/STAR itself. This results in any Lambert/Mercator inaccuracies being minimised on the SID/STAR actually being flown.
For VFR area charts, there are often formal Visual Reference Points marked on the chart. A list of these VRPs, and their lat/long is typically published as part of the country AIP. Grab a searchable copy of this and keep it alongside Avitab while calibrating.
Sets of approach plates may often use the same background map and only need one calibration per set. Load the charts in bulk into GIMP and tab between the images to see similarity. The first calibrated .json file can then be multi-copied and renamed to associate with the other charts. If you intend to decouple the calibration metadata and share, the sha256 hash in the copied .json files also require manual fixing to ensure they associate with the correct chart.
Look in the Avitab.log file in the Xplane Resources/plugins/Avitab directory for hints as to why. If still confused, post the Avitab.log, the chart and any .json, .kml or intermediate .png files on the Avitab support forum.
From Avitab 0.6.1 onwards, the calibration .json also includes the sha256 hash of the PDF/PNG chart file itself. This uniquely (4.3e-60 probability of collision) associates a .json calibration file with the contents of the source chart file, independently of the name of the chart file.
This means that calibration files can be decoupled from the charts themselves. It also means that sets of calibration files can be shared among the Avitab community without needing to distribute the charts themselves. Chart sets can be a large amount of data and distributing them may infringe copyright rules.
The MapTiles/Mercator/Calibration folder is scanned by Avitab at startup for calibration .json files.
When the Airport App loads a chart via Chartfox or locally, it looks in the Avitab folder in MapTiles/Mercator/Calibration for a .json file with a hash that matches the sha256 of the PDF/PNG chart loaded. If found, the chart is automatically georeferenced.
When the Map App loads a local Mercator PDF/PNG chart, it first looks for a similarly named .json file alongside the PDF/PNG chart. If found, it uses that for calibration. If not found, it looks for a similarly named .kml file alongside the PDF/PNG chart. If neither a .json or .kml file are found alongside, it then looks in the Avitab folder in MapTiles/Mercator/Calibration for a .json file with a hash that matches the sha256 of the PDF/PNG chart. If any of these are found, the chart is automatically georeferenced.
In conjunction with Avitab 0.6.1 release, a full set of calibration files for 1000 UK AIP aerodrome charts has been created - Aerodrome, Parking, Area, SID, STARS, Approaches. It is intended that this will be kept up to date with AIRAC cycles for a while.
It is hoped that the Avitab community will be able to contribute and maintain sets of calibration files for other countries/aerodromes. The following contains some guidelines for those considering contributing.
Most likely, you will want to georeference a set of charts for the country you live in. Consider what collection of calibration metadata makes sense and has a good number of charts. Small countries such as Netherlands (~200 charts) or Belgium/Luxembourg (~300 charts) would be good sized complete and manageable collections. Posting smaller datasets such as "All 62 Schiphol charts" would be very welcome as early contributions, but would be absorbed into a larger collection for future maintenance and posting. Larger countries like France or US may initially need some sub-division. Other than a country collection, something like a "VATSIM Top 20 European aerodromes" might also be useful to the community
Consider whether you want to just create the initial metadata set or also commit to updating it for monthly AIRAC cycles. Creating an initial set is most of the hard work and only needs to be done once. Subsequent AIRAC updating is far less work, but does require a committment of about an evening a month.
Have a look through the XPlane.org forum calibration metadata thread to see if anyone else is interested in the same country. Or has started a collection which shares an aerodrome.
Figure out if next and maybe next+1 AIRAC cycles are readily available. The UK and Netherlands AIPs are good examples of this. This is not a hard requirement, but it takes some time pressure off AIRAC updating.
Does Chartfox support this country? Are the official AIP website charts behind a login? The Germany AIP website has some chart access quirks and although useable on the Chartfox website, it is currently broken in Avitab. Italy is behind a login and is unavailable in both Chartfox website and Avitab. It would still be possible to share calibration metadata for Germany/Italy, but users would need to manually download charts for themselves.
Is it possible to accurately georeference most of the charts you're interested in? Avitab only supports Mercator, but many Lambert charts can be approximated enough for flight-sim purposes. USA SIDs and STARs are typically "not to scale" and may not georeference accurately enough to be of use, even for flight-sim purposes.
Once you've got an idea of the number of charts, the work required and any quirks, post on the XPlane.org forum calibration metadata thread to give other users a heads-up. This should help reduce duplication of effort and encourage collaboration.
Ideally get the charts from the official website of the country AIP. For a list, see https://www.eurocontrol.int/articles/ais-online. If available, get the initial chart set from a next+1 AIRAC cycle. Failing that, a next AIRAC cycle. By the time you've finished, the collection will be more likely to be current.
It can be useful to load a chart via the Chartfox website, hover over the attribution text at the bottom and note from the browser where this is linking to. This same link can also be found in the Avitab.log when a Chartfox chart is loaded in the Avitab Airport App. Chartfox only links to the current AIRAC cycle of AIP providers. So use Chartfox to help figure out where to get charts from, but you may then want to download from the official country AIP, particularly if you're calibrating a future AIRAC cycle. If Chartfox redirects to a virtual airline chart website (Portugal/Switzerland), this is probably preferred as a chart source. If so, make it clear when posting that this is the origin of the charts.
Use meaningful names for the charts/.json files. Charts may sometimes come out of the AIP or Chartfox website as an unhelpful e.g. "8450234.pdf". Renaming these before calibration helps track down potential future issues. Ensure your renaming convention is consistent across AIRAC cycles, which will help in AIRAC updating.
Some charts may have 2 panels on a page or an inset panel. The hash-matching feature mechanism cannot support 2 different sets of calibration for each of the panels. Either calibrate one panel or don't calibrate such charts. Make a note of instances of this in the README when you package.
How long will this take ? I estimate that the first round of ~1000 UK charts took me about 80 hours = about 12/hr. Some SIDs and STARs have useful navaid and waypoint IDs and can be georeferenced in less than 2 minutes per chart. Other charts with no helpful reference points may require calibration via intermediate PNG / Google Earth and can take 5 minutes.
See https://www.icao.int/airnavigation/information-management/Pages/AIRAC.aspx
There is usually a document somewhere in the country AIP for that AIRAC cycle that details which charts have been updated. However, managing the update process can be made significantly faster if you have some Python scripting skills to automate some of the steps. Ask on the forum if you already have some Python experience and would like some hints.
In my experience of UK AIP chart AIRAC updates, the vast majority of charts are unchanged, so the calibration .json file from the previous AIRAC cycle can be used as is. Of the charts that have changed, most have had just minor edits in which the calibration is still valid, but the sha256 hash in the .json calibration file needs to be updated. For the UK, on average, about 5% of the charts then need manual recalibration
How long with this take ? For the UK AIP with ~1000 charts, and using Python, the last 5 AIRAC cycle updates have typically taken me about 2-3 hrs each month.
Don't include the charts themselves. They take too much space, are very likely to infringe copyright and are not required.
Ideally, if the AIP provider makes next AIRAC cycles available, include 2 AIRAC cycles in the zip - current and next. This gives users more flexibility in terms of when they need to update their metadata.
Don't have duplicate hashes. Include a complete set for the first, current AIRAC cycle. For the second, next, AIRAC cycle, only include those calibration files that are changed or new.
Look at the UK AIP ~1000 calibration metadata set as a template. The AIRAC cycles should be clear, both in top level zip name and down in the extracted folder names. Use ICAO region and ICAO country as sub-folders so there's consistency when different sets are merged together.