Clarify settings

[sarahcd]

What is the "timezone of the data"? Is this intended to mean the timezone of the local computer?

As I understand, all Apps/developers can assume that the timestamp is in UTC (e.g., using timestamp from Movebank, upload file from cloud, upload from local system).

[sarahcd]

Same question applies to the coordinate system. The location lat/long should always be in ESPG4326, right?

[annescharf]

Hi @sarahcd we try to make apps as flexible as possible always keeping in mind that data can be read into moveapps not only coming from movebank, but from anywhere, even simulated data. Therefore:

• Timezone in UTC (timezoneUTC): Check the box to ensure the timestamps are in UTC. If unchecked, the timestamps will be in the timezone of the data (which will be displayed in the logs of the app once it has run). ==> we give the option that the timestamps in the csv can be in UTC or can stay in whatever timezone they are. We print the timezone in the logs so the user can be reasured it is what they are expecting
• Coordenate system of the data in Lon/Lat (EPSG:4326) (crsLonLat): Check the box to ensure the data are in the geographic coordinate system (lon/lat) 'EPSG:4326'. If unchecked, the coordinates will be retained in the current projection (which will be displayed in the logs of the app once it has run). ==> even if data are coming from movebank, in moveapps there is an app to reproject the data, so they can potentially be in any projection. Therefore again we give the option to transform them or keep them as is and inform the user though the logs what projection they are in

Does this clarify your questions?

[annescharf]

Ah, yes, the timestamps currently can probably only be in UTC, but as we do not have control over what other app are going to do tomorrow, we are prepared for the case that apps can change the timezone of the data

[sarahcd]

Thanks Anne!

1) This is only affecting values of the specific attributes timestamp and coords x/y, right? Other coordinate or time attributes could be present in the data and I assume would be left as is.

2) Are the time zone and coordinate system for these attributes embedded in the move2 object (or movingPandas etc)? I assume this is required for the app to be able to convert back to UTC/EPSG:4326. I understand this information would be lost when converting to csv, thus the settings options are provided.

3) Considering questions 1 and 2, in the case that alternative time zones and coordinate systems are used in these attributes, is it true that if these attributes are presented in other file outputs from various apps, access to the original workflow or personal communication with the person who built it is needed to know the time zone and coordinate system? Can we assume that apps will deal with this variation on the fly, or could they lead to incorrect results or errors? (For example, will the Add Local and Solar Time App know and calculate accordingly if the timestamp values are not in UTC?)