Heading (between locations) vs calc.direction

[peterdesmet]

Is Movebank heading equal to UvA-BiTS calc.direction?

https://github.com/inbo/bird-tracking/blob/25495a0461f72dc69c7cf063779c1f5030aa2ba6/sql/movebank_gps_data.sql#L64

Movebank heading is defined as (https://www.movebank.org/node/2381#heading):

The direction in which the tag moved from this location to the subsequent location, calculated as the bearing between consecutive locations, in decimal degrees clockwise from north; for example, 0 = north, 90 = east, 180 = south. example: 315.88 units: decimal degrees

UvA-BiTS calc.direction is defined as (https://wiki.pubserv.e-ecology.nl/wiki/index.php/Useful_Queries#get_uvagps_track_speed):

Not documented in the UvA-BiTS wiki, but returned by get_uvagps_track_speed_incl_shared() which calculates between current location and previous one.

@sarahcd: Movebank definition is heading between pos and pos +1, ours is heading between pos and pos -1. Can we map our value for heading or should we either not provide it or try to calculate it as pos and pos +1 to fit the definition?

@Wouter-Vansteelant @jshamoun: We already discussed this at https://github.com/inbo/bird-tracking-etl/issues/15#issuecomment-362687283, but can you confirm that UvA-BiTS calc.heading is the heading from a current position to a previous one (expressed as degrees from north)?

[Wouter-Vansteelant]

@peterdesmet see my resopnse to other issue on compass heading in movebank. Brief answer: the column "heading" in movebank is equivalent to "direction" in uva-bits, but indeed in oppossing directions (i.e. from i to i+1 in movebank, and from position i-1 to i in uvabits)

[sarahcd]

Thanks for bringing this up. I am changing the definition for the Movebank field to make it more broad because that original definition really doesn't describe what most users are storing there. In most cases heading is provided by a GPS sensor and not calculated using consecutive fixes. I'm sure there are values calculated using consecutive fixes in both ways (i to i+1, i-1 to i) stored by users in Movebank (and could be recalculated from the locations to check or ensure consistency across studies). The important thing is that the values are in degrees clockwise from north, however they are calculated. So long as that is the same I'd recommend keeping your values as you have them in UvA-BiTS.

New definition: "The direction in which the tag is moving, in decimal degrees clockwise from north; for example, 0 = north, 90 = east, 180 = south. Values may be provided by the sensor or calculated between consecutive locations."

[peterdesmet]

Nice! In that case I’ll provide values measured by the tag, as that is information that cannot be calculated. Note: 0 north to 180 south leaves it open if west should be 270 or -90 (and I’ve seen both). Would make it explicit:

The direction in which the tag is moving, in decimal degrees clockwise from north, ranging from 0 to 360, with 0 as north; for example, 90 = east, 180 = south. Values may be provided by the sensor or calculated between consecutive locations.

[sarahcd]

Good catch. I think both "decimal degrees clockwise from north" and the sample value 315 indicate positive values to 360, but it's a good idea to make the wording more explicit: "The direction in which the tag is moving, in decimal degrees clockwise from north, as provided by the sensor or calculated between consecutive locations. Values range from 0–360: 0 = north, 90 = east, 180 = south, 270 = west."

[peterdesmet]

Data is now uploaded with gps.direction (measured by tag) as heading:

https://github.com/inbo/bird-tracking/blob/daae6e9ac0934add7d828720bdc6eb5682903b40/sql/movebank_gps.sql#L100-L103

The values seem to make sense (indivual L143467):