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

Any reason for not using sf::read_sf() #45

Open
ColinFay opened this issue Oct 18, 2021 · 2 comments
Open

Any reason for not using sf::read_sf() #45

ColinFay opened this issue Oct 18, 2021 · 2 comments

Comments

@ColinFay
Copy link
Contributor

Hey,

I was reading the code from process_data() and was wondering why this function was not relying on sf::read_sf() ?

As far as I can tell it gives a more straightforward interface and should be more reliable:

> sf::read_sf("inst/gpx/running/activity_7371775190.gpx", layer = "track_points")
Simple feature collection with 527 features and 27 fields
Geometry type: POINT
Dimension:     XY
Bounding box:  xmin: -1.275479 ymin: 51.38637 xmax: -1.252118 ymax: 51.40214
Geodetic CRS:  WGS 84
# A tibble: 527 × 28
   track_fid track_seg_id track_seg_point_id   ele time                magvar
       <int>        <int>              <int> <dbl> <dttm>               <dbl>
 1         0            0                  0 -46.2 2021-08-26 08:22:57     NA
 2         0            0                  1 -46   2021-08-26 08:22:58     NA
 3         0            0                  2 -45.8 2021-08-26 08:23:01     NA
 4         0            0                  3 -46.2 2021-08-26 08:23:07     NA
 5         0            0                  4 -46.8 2021-08-26 08:23:14     NA
 6         0            0                  5 -46.6 2021-08-26 08:23:20     NA
 7         0            0                  6 -46.6 2021-08-26 08:23:26     NA
 8         0            0                  7 -46.6 2021-08-26 08:23:27     NA
 9         0            0                  8 -46.8 2021-08-26 08:23:34     NA
10         0            0                  9 -46.6 2021-08-26 08:23:36     NA
# … with 517 more rows, and 22 more variables: geoidheight <dbl>, name <chr>,
#   cmt <chr>, desc <chr>, src <chr>, link1_href <chr>, link1_text <chr>,
#   link1_type <chr>, link2_href <chr>, link2_text <chr>, link2_type <chr>,
#   sym <chr>, type <chr>, fix <chr>, sat <int>, hdop <dbl>, vdop <dbl>,
#   pdop <dbl>, ageofdgpsdata <dbl>, dgpsid <int>,
#   ns3_TrackPointExtension <chr>, geometry <POINT [°]>
@datawookie
Copy link
Collaborator

Hi @ColinFay, wow! I was not aware that sf::read_sf() could consume GPX files. I think that this is awesome and would make process_data() a lot cleaner and easier to maintain. How about a PR? :) Thanks, Andrew.

@ColinFay
Copy link
Contributor Author

Super, will do a PR !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants