| Author |
 Topic  |
|
Coolwind
Moderator
Italy
8957 Posts |
 Posted - 13/04/2016 : 17:32:26
|
Just a few words to tell you that our team developer Alberto Realis is adding full support for OpenAIP airspaces and airports.
It will be included in the first beta shortly after the release of v6.0 .
|
|
|
Alus
Pulcino
Netherlands
30 Posts |
Posted - 19/04/2016 : 11:42:51
|
Thanks Paolo for introducing this new development.
Hopefully I found some time to add some new functionalities to LK8000!
I have something ready to be tested: here there is a version of LK8000 which supports (in addition to OpenAir) also OpenAIP airspaces, waypoints and navigation aids compiled for for PC and PNA (built over the last 5.3U version).
From http://www.openaip.net/ it is possible to download airspaces and waypoints as .aip files for many countries.
OpenAIP defines three kind of waypoints: airports, navigation aids (VOR, NDB etc.) and hot spots (thermals).
In this test version of LK8000, in the zip file, .aip airspaces files can be now configured as airspaces and .aip airports, nav aids and hot spots files can be now configured as waypoints.
For the airspaces OpenAIP defines also the "Gliding area" airspace that really exist in practice but it isn't defined in LK.
Same as RMZ but it has been already added recently also in LK so no problem here.
And I noticed that in LK we have also the "NO_GLIDER" airspace definition that seems not used, and it is not importable from OpenAir and also not defined by OpenAIP.
So I have a question for you guys: Is anybody using the current LK8000 "NO_GLIDER" airspace definition?
This because in my actual OpenAIP implementation I renamed the "NO_GLIDER" definition as "GLIDING" and I'm actually using it for the gliding areas defined in OpenAIP.
Regarding the waypoints: not all the details of OpenAIP can be actually supported in LK; some of this data is now being added as textual comment of each waypoint.
For example: actually, we don't support airfields with multiple runways and radio frequencies. So only the longest runway is used and all the other info is added as comments for each airfield.
Heliports are displayed only for GA aircraft otherwise ignored.
For the hot spots, the thermals considered good only for para-gliders are ignored if LK is being used as glider or GA airplane.
Would be nice to have some feedback form who is willing to test this new feature.
Many thanks in advance! |
Edited by - Alus on 11/06/2016 15:46:17 |
 |
|
|
BravoLima
Aquilotto
Netherlands
276 Posts |
Posted - 19/04/2016 : 15:50:09
|
I've tried the OpenAip conversion in v5.3p and it is working alright. To answer your question about NO_GLIDER airspace: I don't use it.
The only thing I noticed is that the Belgium and Netherlands FIR-boundary doesn't fit, but that's a matter of correcting the airspace files.
I'm used to the OpenAir and cup format. Is there also an "easy to use" OpenAip editor to make my own files? |
Edited by - BravoLima on 19/04/2016 23:24:58 |
|
|
|
Alus
Pulcino
Netherlands
30 Posts |
Posted - 21/04/2016 : 11:51:22
|
Hi BravoLima,
thanks for your message, I think the answers are mostly depending on OpenAIP.
If something regarding airspaces is not correct the best thing to do would be just to submit the corrections directly on openaip.net
I don't know if there is an "easy to use" editor, this is a good question for the people of OpenAIP...
We liked the idea behind OpenAIP: a place where everybody can contribute to build an updated database for aispaces and various waypoints free to everybody.
So we decided to support, experimentally, the actual OpenAIP format (XML based) version 1.1 in LK8000.
We hope that OpenAIP will define in the future a more light and compact format specifically designed as export format from their database to mobile (and not connected) devices.
In OpenAIP there are also other airspaces definitions that we currently don't have in LK8000 (and probably also less relevant for us): FIR, OTH (Over The Horizon), TMA and UIR.
In the current implementation, in order to don't introduce too many changes, those airspaces from OpenAIP are simply ignored. But I can also easily show them anyway, or just some of them, as airspace of "OTHER" type.
So other questions: what shall we do here? Do we want to show them or some of them as "OTHER" airspace? Or do we want to make the right definitions also in LK8000?
Thanks in advance to who is willing to participate.
|
|
|
|
BravoLima
Aquilotto
Netherlands
276 Posts |
Posted - 21/04/2016 : 13:33:27
|
At this moment the Airspace in LK is sorted by classification and by type. I think you shouldn't enter new types which can also be defined by classification. Example: a TMA can have different classifications so a definition for TMA is redundant, this also applies to UIR and FIR.
|
|
|
|
kestrel19
Falchetto
United Kingdom
158 Posts |
Posted - 09/05/2016 : 14:11:48
|
Agree (I'm also UK based). Class A, Class D, TMZ tells you what you can do, TMA doesn't. I can't see the value of "no gliders". What we do have is some airspace that is restricted but not covered, two that come to mind are airfield traffic zones (perhaps best treated as class D "you can go in with permission"), and parachute drop zones. I've not yet looked in detail at what's in the AIP files but I certainly wouldn't want to fly with anything that didn't warn about them. Currently we can identify them as "Unknown" or class G.
Also certainly in the UK "FIR" covers all airspace, so as information is pretty useless. |
Soar the big sky |
|
|
|
davesalmon
Pterodattilo
United Kingdom
1620 Posts |
Posted - 10/05/2016 : 11:06:56
|
| What is the advantage of OpenAIP over OpenAir? On inspection of the files they look almost identical, except for the ommision in OAIP of the asterix between sectors. It has already been established that LK8000 is not limited to the types of airspace originally included in OpenAir. Lets KISS, or we shall finish up with only flying in 2-seaters, so that one can navigate whilst the other flies. |
|
|
|
Coolwind
Moderator
Italy
8957 Posts |
Posted - 14/05/2016 : 13:33:51
|
It seems that the format of OpenAIP is changing before even the old one we implemented is adopted by the people.
Very bad. Good idea, bad implementation of the idea. |
|
|
|
Alus
Pulcino
Netherlands
30 Posts |
Posted - 19/05/2016 : 12:17:09
|
Thanks All for the replies.
BravoLima and kestrel19, I agree, so we will not add the new airspace definitions: FIR, OTH, TMA and UIR.
davesalmon, the advantage of OpenAIP is that it's only one place where to get free updated navigational data like: airspace's, airfields etc. for many countries. As they say it's a kind of open "worldwide aviation database".
Since already some year is used to in software's like KFLog to update automatically via Internet airspace's and airfields, which is the same thing that commercial software's, like SkyDaemon, are asking money for, because they are certified...
Let's imagine a desktop software or a more simple script that is updating automatically the airspace's and waypoints directly on our device with LK8000 connected via USB. This would already possible with OpenAIP.
Paolo, I know that you don't like the current format definition of OpenAIP, me too.
Probably it wasn't born with a portable devices in mind but more with a web-oriented approach.
Anyway in the exchange of e-mail we had with OpenAIP they were available to define an export format more compact and specific for portable devices, like a PNA running LK.
I don't know when they will start using the new format, anyway I don't think that they will simply throw away the actual format which is actually used by other applications. I'm waiting an answer about that I will let you know.
Alus |
Edited by - Alus on 22/05/2016 08:07:01 |
|
|
|
Coolwind
Moderator
Italy
8957 Posts |
Posted - 19/05/2016 : 12:44:59
|
This is exactly what worries me. A service like OpenAIP should primarily think about an export data to let people use it. What else should it be used for? To look at online? They cannot expect people populating their database without a decent download format. And what about software developers adopting a non-existing not-yet-decided that-can-change format?
If I cannot use what is inside OpenAIP I will not spend my time to update and add things to their database.
Without people doing it, OpenAIP is already dead.
|
|
|
|
davesalmon
Pterodattilo
United Kingdom
1620 Posts |
Posted - 19/05/2016 : 14:17:39
|
My only experience of OAIP is KTrax etc. What I do not like is the way the labels are placed on the lines. Perhaps there is a convention to learn, but I don't know which side of the line it refers to. It becomes confusing even when you know the airspace.
Re updates, I usually only go to one place to download. |
|
|
|
Alus
Pulcino
Netherlands
30 Posts |
Posted - 19/05/2016 : 17:57:48
|
Paolo, I completely agree with you, something like OpenAIP must be not only web-based, that's exactly why I started this work.
Consider that the current OpenAIP fomat, XML based, that I implemented in my LK8000 fork, seems working just fine.
Sure it must be tested by more people; it was not that hard to write and it is not affecting the current OpenAir stuff that, of course, remains there and everybody will be free to choose which one to use. With this work I just wanted to add new functionalities to LK8000.
I would like that the people has the opportunity to use also OpenAIP on LK, as it is now (I already wrote it) and after we can define together with OpenAIP a proper and more compact export format for portable and not connected devices (like a PNA running LK8000) based on what we will find using it, so based on our real user experience, this makes more sense to me.
I'm already personally flying with it, since weeks. I found a mistake in the height of one airspace and I submitted the correction to OpenAIP so updating its database. To me seems working, we have just to use it, as I did everybody can now do.
If we refuse to use it only because we don't like the format "a priori" well we are not going that far.
Why not to use what OpenAIP already built and then improve it according to our needs?
I would say: let them to realize what is the real potential of having hundreds of LK8000 devices around capable of using their database (and so consequently many new users submitting real and accurate corrections and improvements) and I guess that it will be no problem to define together a proper export format. We all will take advantage of that.
davesalmon, the way how the labels are drawn in KTrax doesn't depend on OpenAIP. In LK8000 airsapce's red from a .aip file are drawn exactly in the same way as airspace's from an OpenAir file.
I fly in different countries, I personally found it handy to get everything: airpaces, airfields and nav-aids from one place.
|
Edited by - Alus on 19/05/2016 18:10:31 |
|
|
|
maxb
Pulcino
25 Posts |
Posted - 19/05/2016 : 19:39:16
|
I'm testing OpenAIP too, and (up to today) it seems to work ok.
May the format definition be done better? Yes, of course! Json-like files are not so good for small devices, and the possibility to have a lighter definition format could be discussed.
In any case it is the only free source of airspace (and not only) data on the web, so having the possibility to use them is in any case a good thing even, again, it could be better. Are there other free alternatives to OpenAIP?
BTW, It is gaining consensus by other sw developers see http://www.openaip.net/node/961845), so having it already done (thanks to Alus) is anyway good.
I believe that a format more suitable for small device should be defined, and that we could collaborate with them in order to define how it can be done and, after all, we already have the current format already running.
my2 cents...
|
|
|
|
Coolwind
Moderator
Italy
8957 Posts |
Posted - 20/05/2016 : 01:36:44
|
Alus I am not saying we dont integrate your work. We are going to merge it as soon as we are done fixing v6.0.
Then we can release immediately after new beta.
|
|
|
|
Alus
Pulcino
Netherlands
30 Posts |
Posted - 20/05/2016 : 13:59:45
|
Thanks Paolo.
In the meanwhile I received the confirms I was awaiting from OpenAIP.
As announced there will be a new version of their format (JSON based) for all kind of web applications, it will include more data of the actual format.
Anyway they completely understand our need for a more compact format for not online devices, so they confirmed to be open to define a proper export format.
They also confirmed that the actual XML format will remain available also after OpenAIP v2 so my work will be anyway usable.
So actually I don't see any problem regarding the format. |
Edited by - Alus on 20/05/2016 14:47:26 |
|
|
|
Coolwind
Moderator
Italy
8957 Posts |
Posted - 20/05/2016 : 15:20:31
|
What OpenAIP need to understand is that the people using their data is using software to read it. This software must be developed and tested first. On avionics it takes weeks to months, to make it a non-beta. Then people must download it and install, and update the databases.
This is something that happens once a year, at best.
Changing format means pushing one year ahead any real use of it. At best! |
|
|
|
Topic |
|
OpenAIP