search

ctmm-initiative / ctmmweb

Web app for analyzing animal tracking data, built upon ctmm R package
http://biology.umd.edu/movement.html
GNU General Public License v3.0
32 stars 21 forks source link

Location Data is turned 90° counterclockwise in the Menu -> "Visualization" tab, but not "Map" tab #106

Closed MatthiasKlappproth closed 4 years ago

MatthiasKlappproth commented 4 years ago

I'm using a dataset downloaded from movebank.org (.csv file). When plotting the attribute table in GQIS/ ArcGIS / rhr / t-locoh / move (decimal degrees as well as UTM), everything is normal and looks identical to the ctmmweb "Map" plot when using the HERE.satelliteDay background (see an example for 1 individual in Fig. 1). Hence, there seems to be no problem with the location data in general. Fig1 When looking at the plot created in the "Visualization" tab, the data looks like this (Fig.2): Fig 2. Consequently, home ranges have the same issue, also when exported into shapefile format for further individual plotting (Fig.3): Fig 3.

Any idea why the data is turned 90° counterclockwise? I encountered this problem before in the ctmm package as well when using movebank data. Is there any solution to circumvent this?

A further issue I noticed is when plotting the location data in the "Map" tab with the HERE.terrainDay background. Then the data is shifted to the east by a few 100 meters (Fig.4): Fig4

xhdong-umd commented 4 years ago

When ctmm imported telemetry data, it will convert lon/lat to x/y and center them for easier numerical optimization. They may also get rotated to landscape shape(I am not sure the reason, maybe making plots easier to arrange?).

When making map or any other plots that need the actual location, lon/lat were used.

As for terrain map layer differences, that looks to be the accuracy problem of the map source (the projection should right as the other layer is good) and we can't do anything about it. You can try raising the issue with Here map but I doubt that can be fixed easily unless it's a simple error instead of data quality problem.

MatthiasKlappproth commented 4 years ago

Thanks a lot for the quick reply! So the rotation issue is a question/ issue for the ctmm-initiative/ctmm and not for the ctmm-initiative/ctmmweb!? Please let me know if I should close the thread and re-open it under ctmm. I assume there is a work-around and @chfleming would be the responsible contact for this?

As for terrain map layer differences, that looks to be the accuracy problem of the map source (the projection should right as the other layer is good) and we have nothing can do about it. Nevermind, don't worry! Just something I noticed in addition. The satellite map is preferable anyway...

xhdong-umd commented 4 years ago

Yes rotation is done in ctmm end with a purpose, not a bug. It will be better to ask @chfleming if there could be a work around, but discussing it here is totally fine with me.

chfleming commented 4 years ago

There are two issues here:

In ctmm if you do not argument a PROJ4 projection on import then the default one is a 2-point azimuthal, which is a safe projection for distortion, but does not preserve North=up. If you want, you can raise a feature request for ctmmweb to be able to accept PROJ4 projection arguments.

As for the second issue with the map being off. I have had users find that QGIS does not render 2-point azimuthal projection correctly, and are off like this. I am curious if this issue also goes away with a simpler projection like 1-point azimuthal.

chfleming commented 4 years ago

I should add another thing that I've seen that can cause a shift in the projected data is if the input long-lat and output projection have different datums. I have been using rgdal::project(), which assumes datums are consistent, but am about to switch to sp::spTransform() to avoid this issue, though the user will have to supply the input datum to get the correct results.