[Ssc-dev] Updated Invitation: InformaCam Weekly Scrum

[Wendy Betts]

Hi Nathan,

Thanks for these clarifications.  Maybe the chart we attempted to complete in January could be of some use in developing the documentation.  We realized that the UI/report didn't directly match up with the J3M data collected.  So, the chart was an effort to catalogue and map the two.  The first column are fields from the J3M document and the second are fields from the dashboard.  We found a number of dashboard fields without corresponding J3M fields and vice versa.  The final two columns were an attempt to get at what actual information was being captured (for example, altitude being air pressure at sea level rather than elevation).  I'm attaching the chart again here in case anyone is interested.
  
One quick follow-up regarding bearing.  I've never quite understood how to calculate it from the pitch, roll, and azimuth figures, since they do not seem to calculate camera movement or position on a 360 degree scale.  Plus, it was not clear to me which readings were the camera's position at the point of capture versus the camera's movement from initiation of the camera to point of capture.  It might help to include an explanation of how to read that data in the write up.

Best,
Wendy
________________________________________
From: Nathan of Guardian [nathan at guardianproject.info]
Sent: 20 May 2014 21:52
To: Wendy Betts; ssc-dev at lists.mayfirst.org
Subject: Re: Updated Invitation: InformaCam Weekly Scrum

On 05/13/2014 12:49 PM, Wendy Betts wrote:
>
> A quick comment on Martin's notes.  We had a similar question about the
> altitude and bearing.  In regard to altitude, we determined that what
> the app was actually measuring what atmospheric pressure.  In regard to
> bearing, the app was recording whether the phone was in portrait or
> landscape, 0 denoted one and 360 denoted the other.  Hope that helps.

We discussed this on the scrum but it is probably a good idea to
re-iterate here and provide better documentation on the wiki and perhaps
in a formal presentation.

First, the web UI/report is very rough still in parts, and the values
displayed there do not fully represent all of the data collected in the
J3M document itself.

For example, in most cases we only show one summary value on the page,
but there are in fact many, many values stored over time in the document
itself. The summary value is intended to be at the time/point of
capture, but it doesn't show the full picture of data.

For altitude, we are indeed using pressure, which is the recommended
approach that Google/Android promotes for calculating altitude. First,
we capture the raw pressure data under the field "pressureHPAOrMBAR".
Then using a standard "air pressure at sea level" value, we attempt to
calculate altitude through a built in mechanism in Android.

The problem is that we are not getting a true "air pressure at sea
level" value for the geospecific location of the phone/user. To do that
we'd need to query a third party service to find the air pressure say at
the nearest airport at that time. It is definitely feasable to do, but
there are privacy issues around potentially leaking geocoordinates that
we need to think about.

FOR NOW, I would say the evidence is the air pressure
(pressureHPAOrMBAR) + the GPS and the timestamp. Together, you could
properly calculate the altitude using historic pressure data from the
area. Not as nice as having it built in, and perfect, that is the
current reality.

SECOND, is bearing. This is more an issue of buggy code, where the
rotation of the phone does indeed cause some problems. I am looking into
this, and hope we can provide better data here with true compass bearing
soon. AGAIN, however, I want to point out that the raw pitch, roll and
azimuth data is captured from the J3M, and if the GPS is high-accuracy
enough to give it to us, we will also capture GPS altitude data (usually
you have to be outside for this).

Hope that is helpful and useful.

Best,
 Nathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: J3MData.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 11020 bytes
Desc: J3MData.xlsx
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20140521/eb822f40/attachment-0001.xlsx>