Data types and precision

[Bearick]

Hi there,

I'm currently looking into the potential of Btraced for a number of applications, and I'm working on a backend web service which can handle and process Btraced app data. I now have a few questions about the data types being used:

1) Point id's: what is the data type for this (precision or range), and how does the app cope with it while it seems ever increasing? Does it go 'round robin' after it goes out of range? I'm able to generate a lot of points if I set the updating of points to the highest resolution. Not really a problem if you use an unsigned 64-bit integer, but it ís a problem when you use a signed 16-bit integer (max is 32767!)

2) GetTripUrl: always seems to be set at '1' it seems, thus resulting our server responding with a full URL after each request, while sending it once should be enough (and saves bandwidth)

3) Altitude: From documentation: "Can be -1.0 if vertical accuracy cannot be determinated". Problem is that an elevation of -1.0 (or lower) is actual a valid value in meters. Living below sea level you will see these figures all the time

Thank you in advance for some answers and regards,
Erik

[smfunder]

Hi Erik,

Thank you for your interest in Btraced. I'm Santiago and I work on the programming of Btraced. We are happy about your interest and comments to improve Btraced.

Here are the answers:

1) We are storing Point id's into a SQLite database with Integer type. Based on the SQLite specifications it can be up to 8-Byte signed integer value and that's actually a huge number. We don't even will exceed to the maximum value.

2) I've been checking again just in case and against our servers "GetTripUrl" is only sent once while the server keeps the same. To make sure, please check if you are sending back the url exactly as the parameter "tripURL" in the JSON reply. Please note that this is case sensitive. If for some reason it cannot be parsed correctly by Btraced the trip will keep asking for the trip URL.

Maybe you can send me by private email (info@btraced.com) your server URL and I will try against your server to check what's wrong.

3) Altitude. You are totally right. We will update this default value to a very low number so it cannot be confused. We will update the specification and notify you.

We are planning an update of Btraced in these few days so Altitude will work correctly and if there are something wrong with "getTripUrl" we will fix that too.

Thank you!
Santiago

[smfunder]

Hi Erik,

Just a detail I forgot. Regarding the Altitude, the right way to check if that value is available is checking vertical accuracy (vaccu). If Vertical Accuracy is negative, then Altitude is invalid value.

This check will still working on the next Btraced Update and you can implement it that way in your server.

Thank you!
Santiago

[Bearick]

Hi Santiago,

Thank you for your reply!

1) I hope you mean 8-byte and not 8-bit indeed If it is 8-byte, then we are safe.
(8 byte signed integer ranges from 9223372036854775808 to 9223372036854775807, so even if i store 1 point every second permanently, it will take me 292471208 centuries (!!) to run out of range )

2) Thank you for your explanation on the GetTripUrl. I think I have found the problem and it is in our server.

3) The lowest point on dry land (with the possibility of GPS reception) is the shore of the Dead Sea, shared by Israel and Jordan (nice trivia ). It is 418 m (1,371 ft) below sea level. So if you pick -1000 mtr. you will be safe . But also thanks for your hint regarding vertical accuracy! I will implement this right now.

Good to hear that there is going to be a new version of the app real soon. Can you give me a hint if there is also a solution for the gps-update bug for iPhone 5 devices (bug mentioned by simonog in viewtopic.php?f=7&t=418. I also suffer from this bug)?

Regards,
Erik

[Btraced]

See viewtopic.php?f=7&t=418#p505