Embed georeferenced approach charts

[spuckebaer]

Is your feature request related to a problem? Please describe.

No problem, idea for feature

Describe the solution you'd like Now that the German AIP is readily available, a function would be nice to georeference maps and include them in enroute. An automatic swop to the approach charts when approaching the airport would be a nice feature

Describe alternatives you've considered

If automatic integration is not possible, it would be helpful to store data for the airport as a user and to be able to display the approach sheets as an image in the menu

Additional context None

[kebekus]

@spuckebaer Thanks for the suggestion. I have to admit that I have reached the limits of what I can do in my spare time. To implement the feature, we need the support of the DFS.

• The DFS must provide a stable interface that the app can use to download charts.
• The DFS must allow automated downloads.
• The terms and conditions must allow the use of the charts for the app's purposes.

Would you be willing to turn to the DFS, find the relevant people, discuss the matter, and negotiate a contract if required?

Your help would be greatly appreciated. As I wrote above, I do not see how I can do all this alone.

[spuckebaer]

More than understandable that you can't do more in your free time than what you already do. I think we misunderstood each other with this improvement idea. It is not my concern that the DFS data flow in automatically. The parameters you have shown are simply missing. Although there are a number of initiatives in this regard, it will certainly not be settled quickly. And it certainly won't have any added value if I ask additional questions. What I would find great if I could link information to myself in enroute within the overview for the airports. For example, by loading approach sheets manually onto devive and then having them available quickly. I would icing on the cake if georeferable, but that sure is a complex subject

[kebekus]

@spuckebaer Interesting. I will keep that suggestion in mind.

[kebekus]

The new program AIP Browser can generate nice georeferenced charts from Germany's official AIP.

[fbbln]

Is there any way to use the georeferenced approach charts directly in Enroute? AIP Browser outputs JPG with the Georeference in the filename...does this need to be stored somewhere special?

[kebekus]

@fbbln Including georeferenced approach charts is currently not supported. Given the recent interest in the functionality, we plan to implement it later this year. At the moment, all manpower goes into the port for Apple devices.

Best,

Stefan.

[kebekus]

A first prototype runs…

[kebekus]

I uploaded the latest program version to Google Play Beta, which supports approach charts.

@spuckebaer I would be very interested in your feedback. Does the feature work for you?

[spuckebaer]

Thank you very much, this will be a brilliant expansion. I tried to use the function yesterday and this morning, but failed to create and embedd geotiff. The error message within enroute is that geo information on the TIF is obviously missing. I loaded your test file from Aachen, it works without any error messages. I just reinstalled AIP Browser in Windows and tried again. However, I can't generate a geotiff within the AIP browser, only jpg, which I then converted into various ways)... so it seems to be up to me at the moment to create a geotiff. I'll keep trying this. If anyone reads this and could provide an example file for EDHE, I would be happy to test the integration in enroute as a DAU

[fbbln]

Same here. The downloadable versions of AIP Browser do not seem to support GeoTiff or TripKits as of now. It's on the todo list: See: https://mpmediasoft.de/products/AIPBrowserDE/help/AIPBrowserDE.html#_ausblick

I have not found a simple (online) tool to convert the jpg to geotiff ... some rather complicated instructions using gdal_translate only.

[kebekus]

@fbbln @spuckebaer Thank you for the feedback. As you point out, the official version of the AIP Browser cannot generate GeoTIFFs yet. I am in contact with the author, who has implemented GeoTIFF support in the current test version of his program. If you send him a request, he will probably be glad to give you access to his beta software.

[fbbln]

Already did so ;-) BTW, I also tried creating a GeoTiff using QGIS but no matter which settings I use Enroute always errors out with "does not contain reference data". Loading the files created with QGIS again shows them correctly referenced, though. Is Enroute expecting any special coordinate system setting?

[spuckebaer]

Perfect, good proposal....just dropt him also a message. AIP Browser is pretty awesome and I think it's just right for end-user dummies like me. I had also tried QGIS and some other online converters to create geotiff but not successfully

[spuckebaer]

The AIP Browser author responded very promptly. I once generated my standard airports as geotiff and integrated them into enroute, which worked without any error messages. The expected display behavior within the Enroute app is still unclear to me. I assume once my position is within the rectangle georeferenced from the two points that the map will be displayed? Or will it only displayed when I click on "Anflugkarten"? (Installed on google pixel 6, to come: Lenovo TAB10 with older Android version)....I hope for good weather tommorow to test it....

[fbbln]

I created a few VAC Charts and importing them worked nicely. Although they sometimes seem a bit off (EDOI Bienenfarm 1-geo.zip). I also tried creating a tripkit for Brandenburg and AIP Browser exported perfectly. Yet, I always get an error from Enroute upon trying to import it. Brandenburg.zip.

[mipastgt]

As far as Brandenburg is concerned, you haven't specified the imageFormat parameter as tiff. This results in the default format which is webp. See Preview Help Probably Enroute is not yet able to handle any other formats than tiff. I updated the examples in the documentation to use tiff as image format in order to avoid any confusion.

[mipastgt]

I also looked into the offset problem with Bienenfarm. It looks to me as beeing perfectly geo-referenced with respect to the grid printed onto the chart but it is true that the map itself seems to have a significant offset.

I verified this with our own software as well as QGIS and the map offset is always the same. So, I think I can exclude a mistake on our side.

The only explanation that I have for this is that the DFS has made a mistake here or is using some very bad maps for the chart generation. It would be interesting to collect more of such examples because this is the first of this kind that I have been made aware of.

I also had a look at the aerial images from Google Maps which confirm that the map data used by the DFS must be ancient. E.g, the branching railway tracks to the north must have been removed already decades ago. Some faint traces of them are still visible.

[spuckebaer]

Today I tested the integration of geotiffs in enroute live in flight (1 Pixel - Android 13 & 1 Lenovo Tab Android 10). Both the integration and use in flight worked well. Only on the tablet does the card appear twice in the VAC list, but everything is great in the display. I haven't tested the trip kit yet.

[fbbln]

@mipastgt I regenerated brandenburg with setting tiff but Enroute crashes upon import. Side note: the "Flying in France" Example Tripkit contains webp files and not tiff and it imports well.

{
    "version": "1.0.0",
    "name":"Brandenburg",
    "description": "Das Brandenburger Flachland",
    "charts": {
        "coveredArea": [
            {
                "type": "GeoRectangle",
                "west": 12.309495550329785,
                "south": 51.931891038279275,
                "east": 14.2482142633705,
                "north": 52.86364436125615
            }
        ],
        "minInvScale": 50000.0,
        "maxInvScale": 90000.0,
        "imageFormat": "tiff"
    }
}

[kebekus]

@fbbln Very short note: the problems with TripKit imports come from incompatible path separators on Windows/Non-Windows machines; it seems that TripKits look different, depending on what machine they were built. A fix is underway, ETA: today evening.

Still, Enroute should never crash. Can you please send me the file that causes the crash, and I will look into that.

[fbbln]

Here it is: Brandenburg.zip Enroute starts, shows an empty map screen and then ends again. I needed to completely kill the processs and restart it with another tripkit (France) ...before that even normal starting created the above behaviour. Android 12, OnePlus Nord

[mipastgt]

@fbbln OK, so my assumption that only TIFF import is implemented at the moment was wrong. Good to know. @kebekus I'd be interested to know what these platform differences in the trip-kits are. @fbbln A side question about Brandenburg. Do you know what the status of this aerodrome "Locktow" is? It's the only one without an ICAO code. On the other hand there is much more detailed aerodrome data at the DFS site but Locktow does not even show up there at all.

[fbbln]

@mipastgt I don't know about Locktow...seems to be a pure glider spot. Therfore out of my scope. This is not uncommon for glider landing fields, though: PLOETZIN, HUBERTUSHOEHE. Glider only do not seem to have ICAO codes.

[fbbln]

The only explanation that I have for this is that the DFS has made a mistake here or is using some very bad maps for the chart generation. It would be interesting to collect more of such examples because this is the first of this kind that I have been made aware of.

IIRC last year the runway at Bienenfarm war moved 60m south to rebuild the original runway. It was yet moved back after some month...so maybe this was not fed back to the DFS data.

[kebekus]

@fbbln @mipastgt @spuckebaer I have uploaded a new beta version (=v2.28.91) to Google Play. If you have the time, please have a look and try it out. This version fixes the issue with TripKit import, it should now recognize all valid TripKits.

[fbbln]

@kebekus I can confirm the Brandenburg Tripkit, which was crashing the app, now imports nicely. Kudos for your quick fix!

[kebekus]

@kebekus I'd be interested to know what these platform differences in the trip-kits are.

@mipastgt The problem came from the path delimiters. If you go to the test data directory and look at the files "Flying in the Ländle.zip" and "Brandenburg.zip", you will find that

• "Flying in the Ländle.zip" contains a file named "charts/charts_toc.json"
• "Brandenburg.zip" contains a file named "charts\charts_toc.json"

According to your RFC (and the test files that I developed against), I understood that path delimiters should be "/", and never considered Windows-Style delimiters "\". Once the issue was pointed out, I robustified to code, so now it deals with arbitrary delimiters.

[kebekus]

@ffbln Thank you for the extremely quick reply (on Tuesday morning before 8 am!). I am glad that things work now. To be honest, I have no idea where the crash came from. I tried to investigate yesterday night, but I was not able to reproduce the issue…

[mipastgt]

@kebekus Interesting, but I think this is more an issue with the library that you use for the extraction of the zip content. I have only specified the contents of the files but of course not the zip format :-) If I look at the examples here, then I see that in the JSON files the delimiter is consistently '/' in both cases but the zip library seems to store its internal directory according to platform conventions. I never realized that there is such a difference because Java seems to handle that transparently. If I open the zips on the mac with the disc browser you can see the difference in the table of contents at the left although the file is displayed correctly in both cases.

I hope my interpretation of these observations is correct.

[fbbln]

This is a quite common issue, which I've fought a lot with in Python scripts running both on Windows and Linux as well. Also not all libs handle things the same way: some embed the path within the filename (like in Brandenbug.zip) some use "real subdirectories" like in "Flying in France".

[mipastgt]

@fbbln Good to know although on my side it is the same standard Java library in both cases which seems to introduce this inconsistency. We'll probably just have to live with that :-(

[mipastgt]

I have found the line where this inconsistency is introduced due to Javas file path handling and tweaked it a bit so that it should now be independent from the platform on which the zip file is created. But as I said before, the extraction libraries normally handle that transparently. I'd still keep the changes made by Stefan in the Enroute code because it might be that someone creates a trip-kit by manually zipping a folder of files and then this inconsistency could otherwise show up again.

[kebekus]

@mipastgt Agreed, the robustification code in Enroute will stay in place.

[fbbln]

I gave the VAC a try yesterday and it works well. The only thing I don't understand is that I have to activate the VAC view and select the Airport during approach. Wouldn't it make more sense if Enroute shows the VAC in the normal view upon getting close enough to an airport or at a certain zoom level?

I dislike fiddling around with the phone/tablet during the last minutes of flight....

Am I missing something?

[kebekus]

@fbbln You are not missing anything. At the moment, VACs need to be activated manually. We might change that in the future, but we need to think about how to implement the feature in a way that is clear and unobstructive to the pilot. We have a few places where many airfields are very close to one another (Herrenteich - Hockenheim - Speyer - Walldorf / Schwäbisch-Hall - Weckenried), sometimes with overlapping traffic patterns. To make matters worse, switching maps takes substantial time (especially on older devices), which makes it a bit of a challenge to implement a system that works in practice and does not become a nuisance.

We will return to the issue, but we decided to settle on the simplest solution for now ["Solve one problem at a time"]. At present, I recommend switching to the approach map 10-15 minutes before arriving at the destination…

[kebekus]

Dear all,

I am closing this issue because the feature has been implemented and is available from version 2.29.0 onwards. Thank you for all your help!

Best,

Stefan.