Feat(tracker): add rotation calculations #232
Conversation
…in per sec, per hr and per day
…mprehension" This reverts commit 4fdd6bc.
|
@danielmwatkins @cpaniaguam I think the function In the tracker it's restricted to allow rotations only up to ±π/4 rad (±45º), but as we talked about last week, you might want to have rotations which are beyond that in some cases. I added some testcases with rotations of rectangles and a couple of variations on a "hammer" shape all around the circle. These require that we allow full rotations ±π rad (±180º) so I loosened the maximum rotation in the version used in the IFTPipeline.jl package. This works a lot of the time, but it's pretty unstable and will often return a rotation π away from the true value, even in cases like the hammer where the orientation of the object is completely unambiguous and where rotating by π makes the fit substantially worse. Increasing the image size doesn't make this problem go away. The orientation and angular velocity measures will likely be impacted by this issue. |
| - `floe` ID | ||
| - `satellite` name | ||
| - `mask` – the binary mask (choose a column using argument `mask_column`) | ||
| - `passtime` in ISO8601 format (with trailing Z or +00:00), e.g. 2022-09-11T09:21:00+00:00 (choose a column using argument `time_column`) |
There was a problem hiding this comment.
How does it handle it if the pass time doesn't have the Z? Perhaps assuming UTC and raising a warning would be appropriate.
There was a problem hiding this comment.
If the pass time doesn't have the Z or an explicit time zone, right now it should throw an error.
I think assuming UTC would be sensible, but right now the mechanism it's using to parse the values doesn't have an easy way to add that as a fallback. Could we add that as an issue and tackle it later?
|
Yeah, that should be fine. The main place it'll need to work is with the
SOIT data for now.
…On Tue, Mar 18, 2025 at 2:17 PM John Gerrard Holland < ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In IFTPipeline.jl/src/rotations.jl
<#232 (comment)>
:
> +using DataFrames
+using TimeZones
+using Dates
+using CSV
+
+# Base.tryparse(::Type{ZonedDateTime}, str) = ZonedDateTime
+# default_format(::Type{ZonedDateTime}) = Format("yyyy-mm-dd\\THH:MM:SS.sZ")
+
+"""
+Make a CSV of pairwise rotations between floes detected on adjacent days.
+
+Loads the floes from the `input` CSV file, and uses the columns:
+- `floe` ID
+- `satellite` name
+- `mask` – the binary mask (choose a column using argument `mask_column`)
+- `passtime` in ISO8601 format (with trailing Z or +00:00), e.g. 2022-09-11T09:21:00+00:00 (choose a column using argument `time_column`)
If the pass time doesn't have the Z or an explicit time zone, right now it
should throw an error.
I think assuming UTC would be sensible, but right now the mechanism it's
using to parse the values doesn't have an easy way to add that as a
fallback. Could we add that as an issue and tackle it later?
—
Reply to this email directly, view it on GitHub
<#232 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6TAUNX776TLXXW7Y3BJYD2VBPMHAVCNFSM6AAAAABY4P72KOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDMOJVG43TQOJYGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Add support for calculating rotations based on tracked floes.
Input format:
Example: floes.tracked.satellite.csv
Columns required:
IDsatellitenamemask– the binary maskoverpass timein ISO8601 format (with trailingZor+00:00), e.g.2022-09-11T09:21:00+00:00dateinYYYY-MM-DDformatOutput format:
Example: floes.tracked.satellite.rotation.csv
One row per floe comparison. Measurements
i:i=1is the earlier,i=2is the later.Columns returned:
IDof the floetheta_deg– angle between floe image in degreestheta_rad– angle between floe image in radiansdt_sec– number of seconds between overpass in the two measurementsomega_<deg,rad>_per_<sec,hour,day>– mean angular velocity of rotation in degrees or radians per second hour or day.satellite<i>– which satellite measurementiwas fromdate<i>– which date measurementiwas takendatetime<i>– which UTC time measurementi's overpass occurredmask<i>– the binary mask used for the measurementExample:
Limitations
Testing of the rotation detection function (shown in
test-rotation.jl) shows that the rotation measurements aren't very stable, and often aren't very good.Even when given the same "floe" with an unambiguous orientation, the
qd_rigidwill often calculate a best fit rotation which is π radians.