New SimBrief API

[SimBrief]

Greetings,

This is just a quick note for those of you looking to add advanced dispatch and flight planning tools to your VA website. As of a few weeks ago, there is a new SimBrief API available which makes this easy!

The SimBrief API has been designed to give you full control over the dispatch process by keeping your users on your site. When a flight plan request is made, the API will return a massive data file containing nearly every variable used to calculate the flight plan, including the OFP text, weather/NOTAM data, detailed fuel and time figures, and an assortment of flight maps and downloadable flight plan and FMS data formats. Using this data, one could create something as complex as a full dispatch system, complete with their own custom OFP layout, or something as simple as a small page displaying the OFP text.

To illustrate how this process works, I have put together the following demo page: http://www.simbrief.com/api/demo.php . If you are interested in learning more, please see the SimBrief forum topic here: http://www.simbrief.com/forum/viewtopic.php?f=6&t=243 .

For those seeking a simpler solution, the old SimBrief VA Integration method (which redirects pilots to the SimBrief dispatch system) is also available. Detailed info on that method can be found here: http://www.simbrief.com/forum/viewtopic.php?f=6&t=6 .

If there are any questions, feel free to post them here. You can also e-mail me any time at contact@simbrief.com .

Finally, if you are a developer of phpVMS Add-ons and would be interested in creating a Dispatch Add-on based on this API, let me know and I would be glad to help in any way I can!

Thanks for your support,

- Derek Mayer

- www.simbrief.com

[mark1million]

Exciting developments, ill be checking this out right now!

[Tom]

Why do you force the end-user to log in for a site to use this? It makes the process really bad.

As a developer I wouldn't want to use this simply because it looks messy to work with and would be a real difficult experience for my users.

This probably relates to your answer to my first question, however why not develop this as a proper RESTful API that can be called by the back-end system? Saves a lot of hassle.

[mark1million]

Maybe a "VA Licence" would be more suitable, i have to agree with Tom about forcing users to have their own personal account.

Vroute used this same kind of thing where you can call the parameters off their api and you get a return xml string of route data and such, the VA only had to pay for the current araic and this was all a backend function invisible to the user except from a logo at the bottom with "route provided by vroute".

[freshJet]

This looks promising. As I told you before I am already making my own OFP system but it is extremely complex in some aspects. Most of it is OK, however this may be the breakthrough weneed to get it fully functional.

I've just given it ago, it seems like a simpler solution than I'd thought. I have to agree with Tom.

[joeri]

looks verry nice but like all the others i don't like that the enduser needs to register. iff it where a "va license" i would defenetly look in to this

[Cor]

looks verry nice but like all the others i don't like that the enduser needs to register. iff it where a "va license" i would defenetly look in to this

I agree with Joeri, just a VA License and it will be interesting.

Regards,

Cor

[Zach]

Agreed. VA licence would be good.

The VA account could be managed by someone who already has an account. I was tempted to make an account for my whole VA, but people could just change all the account details which ruined the point of having one for all our pilots.

VA licence

[Cor]

Like the IVAO VA system one person should be owner and then can appoint ohther people who can also manage the system.

Regards,

Cor

[SimBrief]

Hi all,

Sorry for the delay, I've been away for work these past few days and my posts are still subject to mod approval, so it's difficult to make timely responses. I'm glad to see so many of you responding to this, maybe through this discussion we'll be able to come up with a solution that's more practical for you guys.

Why do you force the end-user to log in for a site to use this? It makes the process really bad.

As a developer I wouldn't want to use this simply because it looks messy to work with and would be a real difficult experience for my users.

This probably relates to your answer to my first question, however why not develop this as a proper RESTful API that can be called by the back-end system? Saves a lot of hassle.

Right off the bat, I'd like to clarify why the login is still required when using this method. It comes down to the Navdata, and my partnership with Navigraph.

To be clear, my partnership with Navigraph is as follows: They allow me to use their AIRAC cycles on my website, and in return, they gain exposure (and presumably, more clients) as any user wishing to update their SimBrief AIRAC must purchase a Navigraph cycle. I do not receive any financial compensation from Navigraph, nor do I benefit personally from forcing users to register an account on my website. The MAIN reason why the accounts are required is to be able to track which users have unlocked which AIRAC cycles. Since users must pay for these cycles, it stands to reason that I would need a fairly secure way of tracking who unlocked what. User accounts fulfill this task well.

So you can understand now why my hands are somewhat tied when it comes to designing an API, as I still need to somehow ensure that the AIRAC cycle being delivered is appropriate to the user who will be using the flightplan. If you have suggestions on how to accomplish this without requiring user authentication, and yet which still allows this kind of verification, please let me know!

Maybe a "VA Licence" would be more suitable, i have to agree with Tom about forcing users to have their own personal account.

Vroute used this same kind of thing where you can call the parameters off their api and you get a return xml string of route data and such, the VA only had to pay for the current araic and this was all a backend function invisible to the user except from a logo at the bottom with "route provided by vroute".

Personally, I wouldn't require any licence if it were up to me (short of the standard API key stuff to prevent misuse). The issue with this is that I highly doubt Navigraph would allow a "VA Licence" whereby a VA could purchase an AIRAC cycle and allow their entire user base to use the data. At least, I'm not aware of any time in the past that Navigraph has allowed this. If you can negotiate this with them, then I'd be glad to modify the API accordingly!

To be clear, it is also technically forbidden to use a single SimBrief account for an entire VA, as you would essentially be sharing any unlocked cycles with other users. Navigraph does not allow this, and consequently, the SimBrief terms of use forbid account sharing.

You mention that Vroute provides current AIRACs that VAs can pay for. Would you happen to know where they get these AIRACs from? It took me several years to find and put together the data feeds that SimBrief uses (notably, winds and NOTAMs data), and yet try as I might I was never able to find affordable AIRAC data. My initial plan for SimBrief was to offer current AIRAC cycles for free (as I do for the rest of my data), but I soon realized that wasn't going to be possible. Official Navdata sources cost thousands of dollars, making Navigraph the only realistic option that I could find for SimBrief.

In closing, it's possible that Navigraph would allow the use of their default, free cycle (currently cycle 1303) without the need to log in, however this cycle is over a year old so this wouldn't really be an ideal solution. Likewise, having you provide your own AIRAC data when using the API (therefore removing the requirement to use the Navigraph AIRAC) would be difficult to manage and would be getting away from the simplicity I am aiming for. If you have suggestions on how this could be achieved easily then let me know!

Thanks for reading, I look forward to your comments.

- Derek

[skylineVirtual]

It doesn't only look very nice, it is very nice

The fact that every member has to be registered isn't to bad - many VAPilots already have a simBrief account so we figured out this wouldn't really be a big deal.

The possibilities you get are great. We were able to modify and improve our briefing to a high realism level in only two days. The pilots get realistic fuel calculations, route and weather information as well as maps and downloads in not time. And you are free to design this however you want.

As an example, screenshots of our briefing page:

http://skyline-va.de/pic/ofp/pic.php

[SimBrief]

Nice work! Thanks for sharing those pics, I'm glad you have found the API to be useful!

[Zach]

Maybe not such a VA licence, but a VA account that is managed from current simbrief accounts. You can register your VA with your private account, receive and API key, set a password and username, and then when you use the API it checks that information against your database and allows pilots from a VA to generate the flight plans without signing into a private account.

If that functionality was added, i would definitely include this in my airline, without a doubt.

Thoughts?

[skylineVirtual]

I don't know if this would be possible but it would maybe work if VA owners were able to add registered users on simBrief to a VA account or something along with their pilotid so when the request gets sent by the VA Website it checks if this pilot is part of the airline and then uses his Airac to generate the briefing.

If the API can't find the pilot to be matching with the database entries it opens up the login window so non VA projects can still use it the other way.

Just a thought, the way it is right now is OK with us but this would be my suggestion how you could maybe solve this. People obviously would still need a simBrief account but wouldn't have to log in.

[Tom]

I see your reasoning behind it now.

In this case, I would suggest a Twitter/OAuth style linking of accounts would be nicest, so users can sign in once to associate their SimBrief account with their VA account, and then future requests can be completed server-side by the VA site without the need for login.

[SimBrief]

Well in practice, my method doesn't require a login every time either. If the user selects the "Keep me logged in" checkbox on the SimBrief website (enabling the perpetual login), the popup window will detect the login cookie and the process will be seamless. I like this method as it guarantees that the client (VA website) is using the proper user account.

My fear with OAuth, is that unless I impose limitations on how often or for what duration the client program can access a given user profile on the SimBrief website, the client could in theory trick SimBrief into delivering another user's AIRAC. If I were to impose a check (either via a popup window, a redirect, or otherwise) that would prevent such misuse, the end user experience would be very similar to the current popup window method.

Now granted, I am just a hobbyist, and everything I know about OAuth I learned last night through a Google search, so you would probably be much more familiar with it. Am I missing the mark at all? Assuming that I need to ensure that a client website won't be able to use another user's AIRAC, can OAuth guarantee this while keeping the whole process transparent to the end user?

Thanks for your input!