The same discussion happened recently on EuroGA.

- and apparently there are just many different opinions about that topic. I still think the effort would be worth to have one open API database for fuel prices, landing fees and PIREPS.

Je länger ich drüber nachdenke, muß man (=ich) es vielleicht einfach nur machen. Ich werde demnächst mal alle Betreiber der einschlägigen Seiten kontaktieren, ob sie mitmachen würden, wenn es eine Meta-Datenbank gäbe, die ihre Reports in einer Non-Commercial-Datenbank mit Open API (frei zur non-kommerziellen Nutzung) zusammenfasst. Wenn sich genügend Leute finden, würde ich mich bereiterklären, eine DB die PIREPS, Landegebühren und Fuel-Preise zusammenfaßt zu entwickeln und zu betreiben.

Die Idee ist, dass jeder seine eigene Airport DB weiter betreiben kann, nur mir regelmäßig eine Datenbankkopie zur Verfügung stellt, die ich dann normalisiere. In den Suchergebnissen würden dann Backlinks auf die jeweilige Quelle angezeigt.

Ich hatte die Diskussion bei euroga ja noch einmal angestoßen in der Hoffnung, dass sie dort mehr fruchtet. ;-)

Denke in die gleiche Richtung wie Du. Ich finde es halt letztlich schade - da fängt man NOCH einmal von vorne an und es ist dann die x-te Datenbank - anstatt Herzblut und Arbeit gemeinsam in eine Sache zu stecken, schafft man in einer eh schon kleinen Community eher wieder ein Konkurrenzprodukt.

Aber ich bin da auch mittlerweile desillusioniert und vielleicht muss man es halt einfach nochmal neu anfangen.

Ich wäre wohl dabei...

Ich bin am Grübeln. Lass' mal zusammenwerfen, was für Fähigkeiten da sind.

Meinerseits:

• Kenntnis, Unix-Server hochverfügbar und sicher zu betreiben
• Java-Backend-Programmierung
• Perl-Schmuddeleien
• Ein zwei Server zu finanzieren: Kein Thema

(Sehr) gebrochene Kenntnisse:

• HTML
• JavaScript

Mein Ansatz wäre tatsächlich bei 0 mit der 101ten Datenbank anzufangen. Um das Problem der 200 attraktiven Damen zu lösen, wie es Peter bei den Dating-Plattformen zutreffend beschrieb, würde ich es anders herum aufziehen:

• Im Kern gibt es nur die Input-Maske für den Content und eine API, allenfalls ein marginales Frontend zur Visualisierung der Datenbank.
• Damit es aber auch für den allerersten Eintrag "Spaß macht", das System zu benutzen, "füttert" das System aktiv gängige Datenbanken. Pireps nach EDDH, meinetwegen Spritpreise nach av-fuel.com, wenn es der Eingebende wünscht. Natürlich darf sich das Siggi von Eddh oder Marco von AV-Fuel verbitten, dann eben nicht. Aber der Ansatz "Write once, feed multiple databases" könnte so auch eine einfache Eingabeseite attraktiv machen.

Die Information auf der Homepage ist 3 Jahre alt, im zweiten Anlauf ja schon selbst geschrieben.

Aktuell soll AVGAS in Guernsey 2,18€/L kosten. Was stimmt denn jetzt?

Grüße, Udo

Erstmal: danke für das Engagement. Ich denke, dass es eher nur andersherum funktioniert: eine Meta Datenbank die mit Zustimmung der owner die Daten aus 5-6 Datenbanken konsolidiert und zusätzlich die Möglichkeit bietet, lokale Reports hinzuzufügen.

Ich glaube es ist halt schwierig, diese "Zustimmung" zu bekommen. Dazu müssten ja die Owner ihre Daten (per API ;-) ?) freigeben und das ist ja genau das, woran es im Moment scheitert.

Ich denke eher, man muss zunächst in Vorleistung gehen und selber etwas bieten können. Eine PIREP Database, die ihren Content per API anderen zur Verfügung stellt, so dass es sich für den einzelnen Anwender "lohnt", etwas einzutragen.

Parallel oder in einem zweiten Schritt kann man sicherlich überlegen, es anderen Ownern per API auch zu ermöglichen, ihren Content zu teilen - aber nach der Erfahrung bisher würde ich darauf nicht bauen. Peter wird Dir in 1000 Jahren keine Unterstützung bieten und Siggi bin ich mir auch nicht sicher...

Außerdem können die Flugplatze die wollen die Daten selbst einstellen.

Da müsste man noch einmal diskutieren, über was für Daten wir überhaupt sprechen. Klassische Pireps müssen ja von den Flugplatzkunden kommen und nicht den Plätzen selber. Klar, ergänzende Metadaten gerne von den Plätzen selber.

Wir können aber gern mal ne video conferencing machen darüber.

Ja, find ich ne gute Idee!

Meinerseits:

Kenntnis, Unix-Server hochverfügbar und sicher zu betreiben
Java-Backend-Programmierung
Perl-Schmuddeleien
Ein zwei Server zu finanzieren: Kein Thema
(Sehr) gebrochene Kenntnisse:

HTML
JavaScript

Bei mir HTML, Javascript, JS UI Frameworks, MySQL, PHP etc. recht brauchbar. Früher auch mal Perl, ist aber tief im Hinterkopf vergraben.

Die Daten werden dann kostenlos über die Site und über ein API, free for non commercial use, zur Verfügung gestellt. Außerdem gibt es ein JS snippet, was Flugplatzbetreiber auf die eigene Seite anbinden können.

Anfrage nach Deiner Email zum Sync mit Patrick ist raus.

Ich wäre aber für ein "wirklich free". Ja, SkyDemon und FF sind kommerziell. Machen sie primär ihr Geld mit den Pireps oder Spritpreisen? Nein, das ist nur ein Goodie on top. EDDH wirkt unkommerziell, aber im Stil der 90er versucht Siggi, weiterhin Werbung zu verkaufen. Sind wir "gegen" Foreflight, SkyDemon, eddh.de, Runway-Map oder Jans Datenbank? Nein. Alles super. Nur zu fragmentiert.

Die Diskussion "Was ist kommerziell, was nicht?" ist m.E. nur verschwendete Zeit. Welchen Businesscase gibt es denn dafür, ein Geschäftsmodell aufzusetzen, die freien Daten nochmal kommerziell zu vermarkten, bei denen diese Daten das Primärprodukt sind?

Deswegen wäre mein Vorschlag, eher auf jegliche Nutzungseinschränkung zu verzichten, außer der Veränderung. CreativeCommons passt daher nicht. Allein die Pflicht zur Nennung der Quelle sollte erhalten bleiben, also z.B. "by berlinflyer@<derfinaledomainname>.org".

Antworte nur zufällig dem Letzten.

Ich finde alle bestehenden Datenbanken mühsam zu benutzen... vor allem pre/postflight am Mobilgerät. Daher füge ich Einträge nur "am Tisch, vom Computer aus" hinzu.

Könnte ich zB im Rahmen der METAR Abfrage im Autorouter gleich per Bot einen neuen Report abschicken, würde ich dies viel häufiger und aktueller tun. Eine unterladene Mobile Seite mit gutem UI wo es "flutscht" (und man nicht 18 Mal hintappen muss) ginge auch.

Nur so laut gedacht...

Danke!

Die Übersichtsseite kannte ich nicht, ich hatte von OpenAIP und Wikipedia ausgehend geguckt. Ja, dann wäre CC-BY meine Vorstellung.

"Peter wird Dir in 1000 Jahren keine Unterstützung bieten "

Das ist eine falsche Darstellung und das wissen Sie, Patrick. Es wurde bereits diskutiert.

Wie ich schon schrieb, hat jeder, der die EuroGA um die Flughafendaten gebeten hat, schon bei eddh.de und den anderen nachgefragt und wurde von allen weggeschickt.

Das ist natürlich nicht verwunderlich. Das eigentliche Ziel ist es, die Quelle dazu zu bringen, ihre Fair-Use-Policy von den Inhalten zu entfernen, so dass sie überall anders reproduziert werden können (einschließlich Seiten, die Werbung tragen). Die Forderung nach einer API ist nur ein Weg, dies zu verkleiden, um es "nett" aussehen zu lassen und die Fragenden als nicht hilfreich erscheinen zu lassen. Das eigentliche Ziel ist es, die Daten zu extrahieren und sie auf jeder anderen Seite zu verwenden, auch auf einer kommerziellen, und alle anderen Seiten können das sehen und sind daher nicht bereit, mitzuspielen.

Was die Umsetzung angeht, so machen Datenbanken Spaß, deshalb gibt es ja auch so viele :) Ich wünsche euch allen viel Spaß beim Kodieren (XSS nicht vergessen :) ), aber ihr werdet nie eine große Beteiligung von Flughäfen bekommen. In Deutschland werden Sie natürlich eine Reihe anmelden. Es liegt auf der Hand, dass Sie elektronische Verbindungen in Echtzeit einrichten müssten. Die meisten Flughäfen haben nicht einmal die Möglichkeit dazu (z.B. wird der Preis an der Zapfsäule selbst, manuell, eingestellt und die Person, die die Abrechnung macht, hat ihn auf einem Post-it-Block). Sie könnten genauso gut eine Datenbank anlegen, die den Tagespreis von Shampoo Marke XYZ enthält. Lidl usw. hätten die Möglichkeit der elektronischen Verknüpfung, aber werden sie sie Ihnen geben? Nein, natürlich nicht. Was denken Sie, wie z. B. Skyscanner funktioniert?

Original:

That is a misrepresentation and you know it, Patrick. Already discussed.

As I wrote before, everybody who asked EuroGA to supply them with the airports data had already asked eddh.de and the others and was told to go away by all of them.

Of course, not surprisingly. The real objective is to get the source to remove its fair usage policy from the content so it can be reproduced anywhere else (including sites which carry advertising). The request for an API is just a way of dressing this up, to make it look "nice" and to make those being asked look unhelpful. The real objective is to be able to extract the data and use it on any other site including a commercial one, and all the other sites can see this and so are not willing to play.

As regards the implementation, databases are fun which is why there are so many :) I wish you all a lot of fun coding it (don't forget XSS :) ), but you will never get much participation from airports. You will sign up a number in Germany, of course. It is obvious that you would need to set up real time electronic links. Most airports don't even have the capability for this (e.g. the price is set on the pump itself, manually, and the person doing the invoicing has it on a post-it pad). You may as well create a database carrying the daily price of Shampoo Brand XYZ. Lidl etc would have the electronic link capability but will they give it to you? Of course not. How do you think e.g Skyscanner works?

That is a misrepresentation and you know it, Patrick. Already discussed.

It is not: I have tried everything I could. I offered (and am still offering) to:

• Add the feature to the euroga airports database project on a test site just to evaluate for free
• Add an ability to opt-in or opt-out on a user account basis for those users who want to contribute to the euroga airport database, but who do not want the wider community beyond euroga users to benefit for whatever reason they may have. So only the data from accounts that opted-in would be available via the API.
• As you're considering a Telegram interface (the irony being that that requires an API of some sort), I would offer to build that as well - both including Natural Language Processing so you can just talk to it, as well as the "/command" kind of thing known from the autorouter bot.
• Of course, I'd also feed in all my airport experience.

I wonder, what's not to like? I have no imagination what else could be done to change the mindset behind the "Nay", so I think it is not a misrepresentation that if there were another project trying to consolidate airport information and pirep data (basically requiring API access, no?), they would not receive much support from the euroga project, as it stands now.

As I wrote before, everybody who asked EuroGA to supply them with the airports data had already asked eddh.de and the others and was told to go away by all of them.

That, of course, IS a misrepresentation. At least I have never reached out to eddh.de or anywhere else. I do not believe eddh.de (being German only and with little appetite for change) is the future in this regard. I did believe, at the time when I reached out to you, that the euroga project is the best suited candidate for becoming the single-source-of-truth for European airport data and reviews. However, I now understand that is not the case and the appetite to go that way is non-existant. This project expressively WANTS to be yet another data silo. I've tried to explain this before, but here again: People asking you is/was a compliment as people put faith in the project. It's frustrating and frankly offensive, to be rejected and subjected to accusations such as this:

The request for an API is just a way of dressing this up, to make it look "nice" and to make those being asked look unhelpful.

It's quite sad really: The GA community is small enough and it would be so great if the few in it could work together hand-in-hand to build good things. Here's an example where we'd all benefit more from cooperation than from competition. But here we are, everyone stuck in their own boxes.

So in clear terms, your motive is profit, mostly? (looks like you finally indicate an answer to your old question... ;-))

Sven - don't be silly. EuroGA.org and the airports database airports.euroga.org are donation funded GA community projects. If you can tell me how to make *any* money out of this, I am "all ears", but nobody has ever managed it before. Well, maybe Signature Handling, and Fraport skimming off the Greek airports ;)

Patrick - the Telegram interface can go direct to the database. No "API" as such is needed. Well, the database is the API - via SQL. I am still looking for some input for the user interface structure. Some suggestions have been made but I fear that it would be too convoluted. For example we already have a really quick way to get notams and the API (including VFR and IFR plates, where freely available) and there is no correspondingly easy way to do that via Telegram. I am always looking for good programmers to write nice self contained bits of code for the EuroGA community, and some have already made great contributions to the database project (which is in PHP, to make it much easier to find people to work on it, now and in 10-20 years' time).

German machine translation:

Sven - seien Sie nicht dumm. EuroGA.org und die Flughafendatenbank airports.euroga.org sind spendenfinanzierte GA-Gemeinschaftsprojekte. Wenn Sie mir sagen können, wie man damit *etwas* Geld verdienen kann, bin ich "ganz Ohr", aber das hat bisher noch niemand geschafft. Naja, vielleicht Signature Handling, und Fraport, die die griechischen Flughäfen abschöpfen ;)

Patrick - die Telegram-Schnittstelle kann direkt auf die Datenbank zugreifen. Es wird keine "API" als solche benötigt. Nun, die Datenbank ist die API - über SQL. Ich bin noch auf der Suche nach Anregungen für die Struktur der Benutzeroberfläche. Einige Vorschläge wurden gemacht, aber ich befürchte, dass es zu unübersichtlich wäre. Wir haben z.B. schon einen sehr schnellen Weg, Notams und die API zu bekommen (inklusive VFR- und IFR-Kennzeichen, wo frei verfügbar) und es gibt keinen entsprechend einfachen Weg, das über Telegram zu machen. Ich bin immer auf der Suche nach guten Programmierern, die nette, in sich geschlossene Codestücke für die EuroGA-Community schreiben, und einige haben bereits großartige Beiträge zum Datenbankprojekt geleistet (das in PHP ist, um es viel einfacher zu machen, Leute zu finden, die daran arbeiten, jetzt und in 10-20 Jahren).

the Telegram interface can go direct to the database. No "API" as such is needed. Well, the database is the API - via SQL.

Sure - but it's just not a very smart approach to spend time and effort on a single use case, when you could spend exactly the same time and effort (or have people do it for you as a community contribution, like I offered multiple times) on a generic format like JSON.

I don't think you realize just how easy it is to build a bot interface that brings Natural Language Processing (no idea what user interface structure you are asking for. It's all there already) and connectivity to Telegram, Alexa and tons of other messengers out of the box, if only you have a service that speaks a generically understood language such as JSON. That's the only piece here that is missing and that is what I'm arguing for: A PHP page that renders the content into JSON.

I've built a few bots now based on e.g. SAP Conversational AI (which is free to use for non-commercial projects) so I do know a bit what I'm talking about. I'd set up your basic euroga bot in an hour's work and with a few more hours, it could be made really good.

Sobald es eine taugliche Seite mit offenen Daten und API gibt, baue ich das gerne in autorouter ein, so dass Kraftstoffpreise (und am liebsten auch Landegebühren) automatisch angezeigt werden. Auch gerne für Pireps.

Das wäre für mich ein absoluter Knaller! Vielleicht darf ich einen kurzen Moment träumen:

Wenn autorouter sich die Fuel-Preise aus av-fuel und die Landegebühren aus aerops (die haben die ja für die angeschlossenen Plätze sehr genau, da ja auch darüber bezahlt wird...) zieht, könnte mit dem hinterlegten Performance-Modell, den anfallenden Airway-Gebühren und einer hinterlegten Bepreisung der Flugstunde des eigenen Fliegers eine wirklich hochintegrierte Flugplanung gemacht werden.

Bei langen Flügen von A nach B mit erforderlichem Nachtanken könnte autorouter automatisch den günstigsten Zwischenlandeort C bestimmen (frei nach dem Motto, wieviel Umweg lohnt sich für günstigere Spritpreise und günstigere Landegebühren...). Zur besseren Auswahl von Alternativen könnten gleich die jeweils letzten Pireps aus eddh.de mit angeboten werden, womit sich die benötigte Bodenzeit recht gut abschätzen lässt...

Von meiner Seite schon mal ganz herzlichen Dank an Achim H. für die ständigen bisherigen Verbesserungen bei autorouter, das geniale kostenlose Angebot und die Bereitschaft zur Integration weiterer Datenquellen! Und noch mehr würde ich mich freuen, wenn der obige Traum irgendwann mal Wirklichkeit würde!

Liebes Forum,

wie angekündigt möchte ich aktiv das Thema vorantreiben. Daher habe ich folgende E-Mail an alle relevanten Betreiber von Sites/Apps geschickt. Großartigerweise habe ich bereits einige positive Rückmeldungen bezüglich Kooperationsbereitschaft, was mich ermutigt. Ich werde das Forum regelmäßig auf dem Laufenden halten.

---------------------8<-----------snip--------------------------

Europäische nonkommerzielle Flugplatzdatenbank mit Nutzerinhalten

Lieber XYZ,

Ich bin selbst Pilot und weiß, wie wichtig Pilot-Reports über Flughäfen sowie Treibstoffpreise und Landegebühren sind. Das Problem ist leider, dass es nicht nur eine Seite als Single Source of Truth gibt, sondern jede Menge andere Seiten, Fuel- und AirportPIREP-Databases, u.a.:

- EuroGA
- PPL/IR
- eddh.de
- you-fly.com
- Airshampoo
- AV-Fuel
- AeroPS
- Skydemon
- Foreflight
- … und wahrscheinlich noch andere (plus Infos wie Mietwagenverfügbarkeit, OpenAIP, etc.)

Für den Piloten ist es natürlich unbefriedigend, da man sich seine Infos überall einzeln aufwendig zusammensuchen muss.

Weiterhin habe alle Lösungen gemeinsam, dass sie kein API haben und daher die Informationen nicht einfach in andere Apps integrierbar sind. So wäre es erstrebenswert, wenn z.B. im Autorouter diese Informationen auch direkt zur Verfügung stehen würden.

Außerdem sind die meisten Lösungen oft nicht besonders optimiert für Mobilgeräte. Idealerweise würde man nicht nur eine einfach zu bedienende mobile Seite haben, sondern z.B. wie Autorouter einen Telegram-Bot, wo man mit einem einzelnen Befehl auf einfachste Art und Weise z.B. Treibstoffpreise oder auch PIREPs übermitteln kann.

Diese Themen wurden erst neulich wieder breit in den entsprechenden Foren wie PuF und EuroGA diskutiert..

Da alle irgendwie unzufrieden sind, aber keiner etwas unternimmt, habe ich beschlossen, etwas für die Community zu tun. Ich war mein Leben lang Tech-Unternehmer und habe mit meinen Unternehmen webbasierte Software und Datenbanken entwickelt. Ich habe das notwendige Know-How als auch die Ressourcen, eine moderne Lösung zu entwickeln - und habe fest vor, dies auch tun. Die Lösung werde ich auf AWS (skalierbar, verfügbar) betreiben.

Da aber die Welt alles andere braucht, als eine neue Airport Database (https://xkcd.com/927), würde ich gern versuchen, die Daten der oben genannten Seiten zu integrieren.

Meine Idee ist, dass die Seite eine übergreifende Suche über die existierenden Reports von idealerweise allen genannten Datenbanken anbietet. Dabei sollen die Ergebnisse chronologisch sortiert so dargestellt werden, dass neben jedem Eintrag sofort ersichtlich ist, dass dies ein Report von z.B. eddh.de ist - inklusive entsprechendem Backlink auf die Seite. Inhalte werden nach Sprache filterbar und direkt auch übersetzbar sein.

Informationen, die über die Seite direkt eingestellt wurden, werden dabei grundsätzlich als Open Data wie bei Wikipedia unter der Creative Commons-Lizenz BY-SA (https://creativecommons.org/licenses/by-sa/4.0/) zur Verfügung gestellt und sind somit public domain. Es wird von Anfang an ein API geben, welches alle Daten programmatisch zur Verfügung stellt, damit sie in andere Plattformen (sowohl kommerziell als auch non-kommerziell) verwendet werden können. Ebenso wird es einen Download der kompletten Datenbank im offenen JSON-Format geben, so dass sichergestellt ist, dass der Betrieb der Plattform im Zweifelsfalle nicht an meiner Person hängt.

Ich möchte klarstellen, dass ich mit dieser Plattform keinen Gewinn erwirtschaften möchte, sondern es aus Spaß an der Freude und Beitrag zur Community realisiere. Dinge wie Spenden oder sonstige Unterstützungen will ich nicht ausschließen, aber alles eben non-kommerziell. Die Daten sollen der Community gehören.

Wenn man Reports seiner Seite ebenfalls im Rahmen des API und Datenbank-Downloads frei zur Verfügung stellen möchte, würde ich mich natürlich am meisten freuen. Gern zeichne ich die jeweiligen Einträge der DB dann auch mit einer individuellen Copyright-Notice/Link aus.

Es ist aber keine Voraussetzung - im Zweifelsfalle werden die Daten nur im Rahmen der Suche auf der Site angeboten, aber nicht zum Download und auch nicht im API: die individuelle Entscheidung jedes Betreibers.

Ebenso ist es im Rahmen der Vielvalt auch völlig okay und wünschenswert, wenn jeder seine Seiten weiterbetreibt und damit seine Community pflegt (und vielleicht auch spezifische Informationen anbietet, die die Site nicht hat). Und natürlich können mit Hilfe der offenen Schnittstellen alle Daten von der Site auch wieder in die eigene Seite integriert werden. Auch Fllugplätzen wird die Möglichkeit offenstehen, mit einem einfachen JavaScript-Snippet Reports und Bewertungen in die eigene Seite zu integrieren - und natürlich auch eigene Informationen (Treibstoffpreise) proaktiv einzupflegen. Auch hier strebe ich eine Kooperation mit anderen Anbietern wie AeroPS an, die diese Integrationen teilweise schon haben. Doppelarbeit will ich natürlich vermeiden.

Die einzige Voraussetzung zum Mitmachen wäre, mir periodisch (z.B. täglich) einen Abzug der eigenen Datenbank zur Verfügung zu stellen. Das Format ist mit weitestgehend egal, einfacher SQL-Dump oder auch direkter Zugriff auf die DB ist alles fein. Um die ganze Konvertierung der Daten und Einpflegen in meine internen Datenstrukturen würde ich mich kümmern, der Betreiber damit so wenig Streß wie möglich haben.

Ich würde mich freuen, wenn wir bei Interesse der jeweiligen Betrieber in einen Dialog eintreten könnten, wie wir im Interesse aller Piloten in Europa eine Zusammenarbeit realisieren können.

Viele Grüße,

BerlinFlyer

PS: Diese E-Mail geht an die Betreiber aller oben genannten Sites/Dienste/Apps raus.

Die Telegrammschnittstelle für die EuroGA-Flughafendatenbank ist jetzt fertig.

EuroGA.org wird durch Spenden von einigen der Piloten, die daran teilnehmen, finanziert.

1000 Berichte jetzt, trotz zwei Jahren, die für die meisten Piloten sehr schwierig waren.