Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unprojected distance? #16

Open
rrmn opened this issue May 22, 2019 · 4 comments · May be fixed by #26
Open

Unprojected distance? #16

rrmn opened this issue May 22, 2019 · 4 comments · May be fixed by #26
Labels
type: enhancement new features, improvements

Comments

@rrmn
Copy link

rrmn commented May 22, 2019

Hey guys,

would it not make sense to utilize unprojected distance calculation methods? (e.g., Haversine, geodesic, ... as implemented in geosphere)

Right now you have to project the coordinates. This makes sense for localized analyses but falls short when you work with larger areas and thresholds which cross UTM zones.

@rrmn
Copy link
Author

rrmn commented May 29, 2019

E.g., something along the lines of the code below

DT[, withinGroup := {
        distMatrix <-
            # Geodesic distance via geosphere
            as.matrix(geosphere::distm(cbind(
                get(..coords[1]), get(..coords[2])
            ),
            fun = distGeo))
        graphAdj <-
            igraph::graph_from_adjacency_matrix(distMatrix <= threshold)
        igraph::clusters(graphAdj)$membership
    },
    by = splitBy, .SDcols = c(coords, id)]
    DT[, group := .GRP,
       by = c(splitBy, 'withinGroup')]
    set(DT, j = 'withinGroup', value = NULL)
    return(DT[])

@robitalec
Copy link
Member

Hey @RomanAbashin,
Yes - great point. The original functions were written with a relatively local (within one UTM zone), animal social network context in mind.

And thanks for the code chunk, that'd be the only spot to change it in group_pts along with some of the if checks above potentially.

I'll look into this and update here. Thanks!

@robitalec robitalec added the type: enhancement new features, improvements label May 31, 2019
@robitalec robitalec linked a pull request Mar 2, 2020 that will close this issue
@robitalec
Copy link
Member

@RomanAbashin I've started implementing this in #26.

I started testing this with the package's example data, with original UTM coordinates back in WGS84 but if you had some of your own data you wanted to try it out with - please let me know what you think.

I've opted for geodist because it doesn't come with a pile of dependencies and is fast - but let me know if you have any alternatives.

@robitalec
Copy link
Member

I'll need to add some checks in the function to warn if unprojected coordinates were provided without turning the "lonlat" switch on, add some tests, and update the vignettes that state throughout UTM coordinates are expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement new features, improvements
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants