Other SOTA sites: SOTAwatch | SOTA Home | Database | Summits | Photos | Shop | Mapping | Sotlas | FAQs | Contact SOTA

Discrepancies in SOTA Swagger API

As I poke around the SOTA API, I have found a few discrepancies between various APIs and also the Summit List CSV file that’s provided elsewhere:

https://api2.sota.org.uk/docs/index.html
https://www.sotadata.org.uk/summitslist.csv

First of all, the BonusPoints field that is found in the CSV file does not appear to be provided anywhere in the JSON APIs documented through Swagger or in the actual data downloaded from them. This is not a big deal since I am already downloading and parsing the CSV data, but it means that I can’t completely replace it with the JSON data.

Second, while the Swagger docs show that the same data-type, SummitViewModel, is used for summit data listed on both the GET region and GET summit JSON APIs, several of the fields provided through the region API for summits are nulled out including regionCode, regionName, etc. They are present, but have the value null. This is somewhat understandable as they are duplicate information as what can be found in the region section at the top, but the documentation does not make this obvious. I’ll need to rework my app a little to account for this.

The third big discrepancy is a little more interesting. There are fields present in the GET summit API that have the value null, but have the proper value in the GET region API and the CSV file data. In particular, activationCount, activationDate, and activationCallsign are null in the summit-specific API call, but have valid data elsewhere. This is data that is more likely to change regularly so I’m not sure why it’s not filled in on the summit-specific GET JSON call. On top of that, the field locator is null in the GET region and non-null in the GET summit API. Ultimately, I’d need to combine information from the CSV file, GET region API, and the GET summit API and then merge it where non-null data takes priority in order to get the full picture of a summit. I do realize that I can easily calculate the locator value myself, but it would still be good to fix.

There may be other discrepancies as well, but this was what I’ve seen so far. Any ideas from the devs on this?

The short answer is the API does exactly what it needs to do to handle the SOTA websites and nothing much more. This means there’s a bunch of these kinds of inconsistencies because they aren’t issues for eg, summits.sota and the like.

The longer answer is the same as the shorter answer but that many folks are using the API in ways we aren’t sure about and I’m not really in the mood to make too many breaking changes to the API at this stage. There’s a bit of work going on to improve the API and will most likely be releases as a new API version, rather than fixing the existing API. Timeframe indeterminate at this point.

2 Likes

OK, in the mean time, I’m taking a closer look and will try to document all the needed discrepancies. Another one I just ran into is the valid field which I missed since it’s never null. However, it appears to always be false for summits from the GET region API, but true in the data retrieved from the GET summit API. That means, with the exception of the locator and valid fields, the GET summit API is really just a subset of the data retrieved from the GET regions API. With that, it’s probably not worth the effort for me to implement it per summit since I’m already caching the data retrieved offline. The locator can be calculated pretty easily from the latitude/longitude and I presume the valid boolean is probably nothing more than the current data when retrieves being in the range validFrom <= date <= validTo so it could also be calculated as needed. I’ll just have to make sure I implement the refresh button on a summit at the region API level if someone is trying to get the latest activation data for a specific summit.

This is how all the sites work. There is no point storing it and thus having to enter it, maintain it, validate it etc. when the data to generate it exists and we already done that to get the latitude and longitude. There’s also the question of whether we should store it at 6, 8 or 10 characters.

1 Like

Also, just to document it for others, it looks like restrictionMask and restrictionList only contain meaningful values at the GET summit level.

There’s also a minor, but generally insignificant different in the latitude/longitude between the two. One appears to be getting the data as a string from the database and printing it out as JSON floating point and the other is being retrieved as a floating point number causing a slight error in the precision. The different is less than a meter, but can cause values to fluctuate if caching data from both APIs offline:

GET /api/summits/HL/GN-001

...
  "summitCode": "HL/GN-001",
  "longitude": 127.7307,
  "latitude": 35.3369,
...

GET /api/regions/HL/GN

...
      "summitCode": "HL/GN-001",
      "longitude": 127.73069763183594,
      "latitude": 35.33689880371094,
...