×

Notice

The forum is in read only mode.

One of your developers has broken your REST API output

2 years 11 months ago #1650 by w3sz
Hi,

One of your developers has broken your REST API output, so that a query without a sensor filter no longer gives a null output for index 12, the "sensors" field.  Instead, it incorrectly gives a list of all sensor IDs even when no filtering for the sensor was used in the request.

Needless to say, this change has broken parsing of the data obtained with a standard query.

For example, use of your example query:
opensky-network.org/api/states/all?lamin...7.8229&lomax=10.5226

Now incorrectly gives:["3c5ef8","EWG2822 ","Germany",1634748722,1634748722,8.5503,46.7884,7010.4,false,171.05,183.1,0,[-1408233453,-1408234987,-1408234283,-1408234539,1408233257,-1408237161,-1408233705,-1408234728,-1408233894,970501013,90188,-1408234466,1433774459,1539466573,-1408236928,2106064085,1208480659,-1408233468,-1408233083,960481128,-1408237048,1516942451,2100459881,1977010121,80389995,-1408232909,1434571365,-1408235788,-1408234186,1805971594,-1408236994,80602915,-1408235905,1805967060,-1408234527,-1408234331,-1408233817,-1408234200,758475469,206281911],7315.2,"0122",false,0],["46b823","AEE853 ","Greece",1634748722,1634748722,8.5625,47.455,null,true,8.75,67.5,null,[-1408237048],null,null,false,0]

As you know, your API specification for the sensors field is: "IDs of the receivers which contributed to this state vector. Is null if no filtering for sensor was used in the request".
I am hoping that you can quickly fix this.  Now that you know about this problem, I suspect the fix will be quick and easy.

Thanks in advance and Best Regards!!
2 years 11 months ago #1651 by strohmeier
Thanks, we will look into this. We are currently making improvements to the speed of the API, which, as everybody experienced wasn't really performing well any more. Some glitches are to be expected.
2 years 11 months ago #1653 by w3sz
No problem, thanks for the reply! I always say if a day goes by without my making at least one coding error, then I am not doing enough coding. Mistakes are inevitable as long as we humans are part of the process.

Thanks again and good luck with all. OpenSky is amazing, and all of your team's hard work is very much appreciated!
2 years 11 months ago - 2 years 11 months ago #1656 by w3sz
This bug causes a huge increase in bandwidth, and that cannot be good for system performance.

Here is a typical single aircraft record from "states", taken just now from the REST API output, with the bug still present:

["aa56b8","UAL2317 ","United States",1635087453,1635087453,-76.4773,39.7557,10447.02,false,207.89,236.51,-5.2,[-1408232368,-1408233901,-1408233323,970505937,-1408234405,-1408233852,-1408232951,-1408235763,-1408237234,970514683,-1408232525,-1408233928,-1408233543,1408236164,-1408235039,-1408236891,-1408237211,1805987731,-1408235098,-1408232857,-1408237079,-1408234903,-1408235926,970515234,-1408232854,-1408237014],10706.1,"1762",false,0,4]

and this is what that same record would be if the bug had not appeared, or had been corrected:

["aa56b8","UAL2317 ","United States",1635087453,1635087453,-76.4773,39.7557,10447.02,false,207.89,236.51,-5.2,null,10706.1,"1762",false,0,4]

Multiply this difference in data size for a single aircraft record by the average number of aircraft downloaded per data request times the volume of data requests that you get in a day and you can see that the severity of the effect of this bug on overall bandwidth used by your server(s) is very large!  In addition there is the adverse effect of this bug on the bandwidth for each individual user at his/her/their location and the adverse effect of the increased bandwidth on every portion of the path between your server(s) and each and every user.

So addressing this bug is important from a community standpoint, including the broader internet community and not only the OpenSky community.

As a side note, your REST API documentation at opensky-network.org/apidoc/rest.html does not contain documentation regarding the inclusion of a new field [17] in the "states" array which as you can see above is now present in your REST API output.  It would be beneficial to users to add this change to the documentation..

I'll add another example just taken from the REST API output stream here.  This record from the current output (with the bug):

["4841a8","TRA5427 ","Kingdom of the Netherlands",1635099491,1635099492,7.661,47.6954,12496.8,false,234.74,156.36,0,[-1408233453,-1408236394,-1408233705,1434525323,1435907100,-1408234466,1433774459,-1408234338,-1408234337,934459296,-1408233597,-1408234492,1208480659,-1408233083,-1408237048,1516942451,1977010121,80389995,-1408232909,1805974151,-1408234186,91305,970500210,90925,2098002593,1805971594,-1408232413,-1408234332,-1408234331,-1408232409,-1408236377,-1408233817,-1408234200,954776276,-1408234159,-1408233388,-1408234283,-1408234539,1408233257,1801273114,42064840,-1408233894,91083,970501013,-1408233890,333333392,970510088,333333391,333333900,2106064085,-1408233661,960481128,852742020,1408234672,-1408235661,-1408235788,1434571365,-1408232583,-1408235909,-1408232580,1035116639,80602915,-1408235905,1805967060,-1408233501,693642540,-1408234394,758475469,81483681,206281911,-1408236946,956030212],12687.3,"0177",false,0]

becomes, without the bug:

["4841a8","TRA5427 ","Kingdom of the Netherlands",1635099491,1635099492,7.661,47.6954,12496.8,false,234.74,156.36,0,null,12687.3,"0177",false,0]

There are many similar examples from a single download of the REST API dataset in its current iteration.
2 years 11 months ago #1658 by strohmeier
Should be fixed. Let us know if you notice anything else. The API should overall be two orders of maginitudes snappier according to our backend data...
2 years 11 months ago #1664 by w3sz
Thanks! It is fixed and performance is excellent!
Powered by Kunena Forum
This website uses cookies to offer you the best experience of our services. By using this website you agree to our privacy policy!