I've taken a break from App Inventor for a little while, but have some time to get back into updating an app of mine. I'm continuing to work out the best way to have my app work offline when the app needs to periodically be online. Some background to the issue, where i'm changing the way the app geolocates when data if sketchy or offline: Does the Location Service need a data connection to work effectively?
My app (a compass app) also currently connects to a UK server to collect declination data for the device's current location. I'm proposing to change the way it does this by using a NOAA API and a python script to download a CSV file which allows me to embed declination data into the APP as an asset.
Problem with the Earth's magnetic filed is that it constantly changing, so the data I get with the Python script will only be reasonably accurate on the day I download the data and publish the app. I therefore need to build the same API functionality into the app to periodically gather new data to use.
The principle will be along the lines of the image below:
This essentially creates a baseline set of data for the app to use if there is no data connection available from the start (which is unlikely), but then the app can update this with some new code I write that's essentially the same as the Python scipt I use on the PC before compiling. Well, it won't overwrite the CSV asset, but if newer data is availble, the app will use this instead of the CSV Asset.
I just wanted to get the community's thoughts on this approach. Should I make it so complicated or should I simply have no declination data available to the compass app until I connect to NOAA and store the data in a TinyDB at which point the app can display the declination?
Generally not all that fast for most locations on earth. he magnetic declination in a given area may (most likely will) change slowly over time, possibly as little as 2–2.5 degrees every hundred years or so, depending on where it is measured.
Thanks @SteveJG, yes the link you provided is basically how I have been running it, but it failed me becasue I need to both be at the location and then also have connectivity. If I have only one of these, then the system fails. This is what happened when I went to use my app in the field. You'll see that I was the one who followed up with a lot of commentary to your post and I had resolved to move towards the use of tables.
I'm getting the tables from NOAA using a python script and embed the tabels as a CSV as an asset, but i'm wondering if the approach I'd sketched out graphically in my original post here is the best way to do it.
True although with small exceptions it changes only by very small amounts. I don't see an issue. By the time declination changes appreciably you probably will have updated your app or gone on to other things.
If your app uses the little compass that is part of the Map component the problem is moot. That compass is not very precise anyway so I would not worry about the exact declination. Are you setting up a telescope with a polar axis and need to know true North or something else?
Go ahead and build it as you propose and see what happens. What you do depends on why you insist in precision and can not accept just reasonable accuracy. If you want precision take with you to the field a copy of your magnetic tables, correct manually for deviation, and use a Brunton compass. The gps in your cell phone is a toy, no where near the modern gps hardware in use for surveys.
Good luck
p.s. I found your previous discussions . Your bilinear interpolation seems interesting but a few decimal places difference in magnetic variation calculation seems over kill. I guess you have your reasons.
Spot on. The app is part of a process to both set up and drive/control a RA drive that i've built from the ground up. For the first part, the app helps pre-align the base ready for me to mount the RA drive and follow with a Polemaster polar alignment. The compass i've built isn't based on the Map component, it uses sensors - so maybe i'm lucky that the Samsung phones i've used are quite accurate.
Using the gear at home, where I had great data but poor skies, I found my app was extremely accurate in the setup phase and I only had to make very slight adjustments using the Polemaster on final setup. I really like this, becasue if anything ever goes wrong with the Polemaster, then i can be fairly confident that i've set the unit up as accurately as I can without it's assistance.
I really don't want to take physical field tables out either. Standing in a field at 0 degrees, I really want to minimise the amount of work I need to do.
In terms of GPS, the accuracy here isn't really as important (for now). In any case, the RA drive incorporates its own GPS module, which is more accurate than the phone. Ultimately, an advanced version of my setup won't actually rely on a data connection whatsoever - the declination and all other relevant information can be grabbed from the GPS data stream. Unfortunately though, the GPS modules i'm using now have the declination data stream component disabled for some reason.
The bilinear interpolation was a great find, and for the extremely simple maths it requires, provides a great result. For now I think I'll continue to use it.
I'm actually tending to steer away from building-in the scraped CSV data and simply going to rely on the app downloading it on first run into a TinyDB. As long as I get the latest data before I theoretically go on a week-long trip in the sticks with no connection, the system should work.
What you do depends on why you insist in precision and can not accept just reasonable accuracy. If you want precision take with you to the field a copy of your magnetic tables, correct manually for deviation, and use a Brunton compass. The gps in your cell phone is a toy, no where near the modern gps hardware in use for surveys.
. Your bilinear interpolation seems interesting but a few decimal places difference in magnetic variation calculation seems over kill. I guess you have your reasons.