API Issue - getGeoObject returning empty list

[Anthon769]

The server and API are functioning properly and almost all of the API methods are working exactly as described in the API guide. However, regardless of input parameters, the getGeoObject process returns an empty list as its payload ("[ ]"). We seem to be making successful contact with the endpoint (the return message also contains "statusCode: 200", indicating a successful return), but regardless of the geoObjects present in our environment, we cannot see any of them.

We've primarily been running it with {"longitude":0,"latitude":0,"attitude":"friendly","radius":10000} parameters, but have tried all the combinations of parameters we could think of. {"longitude":0,"latitude":0,"attitude":"any","radius":10000}, {"longitude":0,"latitude":0,"radius":10000}, etc...

We are deploying this in Node-RED, but the flow seems to be working properly given that we are getting a successful return statement.

When the getGeoObject request is sent, there are a few errors thrown on the computer that is running the server. Additionally, the PowerShell script running the server seems to be identifying some of the UIDs of the objects within getGeoObject's search radius but is then throwing a "list index out of range" error.

Any advice would be much appreciated!!

getGeoObject Return:

Server Computer Errors:

[HeeebsInc]

Have you found a solution to this? Same is happening to me. Everything used to work with the same FTS version so think there has been a change within ATAK that’s broken. I’m down a rabbit hole so any advice would be great

[naman108]

The way in which the API interacts with the database has changed, likely provoking this issue.

[starcheek]

Same issue

[HeeebsInc]

What fixed it for me was downgrading FreeTAKServer to 2.0.21

pip install FreeTAKServer==2.0.21

[naman108]

I'll take some time out today and open a branch to check it out

[naman108]

... safe to say I did not open up a branch, still an issue. Hopefully we can address this issue in the process of address issue #675 by moving the database access to a proper component and out of the service.