luukvdmeer / sfnetworks

Tidy Geospatial Networks in R
https://luukvdmeer.github.io/sfnetworks/
Other
352 stars 20 forks source link

The `trunc_mat` function we use in print.sfnetwork is deprecated #247

Open agila5 opened 1 year ago

agila5 commented 1 year ago

Describe the bug According to the official documentation, starting from tibble v3.1.0 (the current CRAN version is 3.2.1) the function trunc_mat is deprecated since "printing is handled entirely by the pillar package". This is a slight problem for us since we use trunc_mat in print.sfnetwork:

https://github.com/luukvdmeer/sfnetworks/blob/23a4125030178f5c42ebb48d2547052a31a3cdea/R/sfnetwork.R#L430-L431

Moreover, starting from tibble 3.1.8, the output of trunc_mat slightly changed and the printing of sfnetwork objects is much less informative (see below).

Reproducible example Current output:

library(sfnetworks)
as_sfnetwork(roxel)
#> # A sfnetwork with 701 nodes and 851 edges
#> #
#> # CRS:  EPSG:4326 
#> #
#> # A directed multigraph with 14 components with spatially explicit edges
#> #
#> # A tibble: 701 × 1
#>              geometry
#>           <POINT [°]>
#> 1 (7.533722 51.95556)
#> 2 (7.533461 51.95576)
#> 3 (7.532442 51.95422)
#> 4  (7.53209 51.95328)
#> 5 (7.532709 51.95209)
#> 6 (7.532869 51.95257)
#> # ℹ 695 more rows
#> #
#> # A tibble: 851 × 5
#>    from    to name                  type                                geometry
#>   <int> <int> <chr>                 <fct>                       <LINESTRING [°]>
#> 1     1     2 Havixbecker Strasse   residential (7.533722 51.95556, 7.533461 51…
#> 2     3     4 Pienersallee          secondary   (7.532442 51.95422, 7.53236 51.…
#> 3     5     6 Schulte-Bernd-Strasse residential (7.532709 51.95209, 7.532823 51…
#> # ℹ 848 more rows

Created on 2023-08-02 with reprex v2.0.2

Old output:

# A sfnetwork with 701 nodes and 851 edges
#
# CRS:  EPSG:4326 
#
# A directed multigraph with 14 components with spatially explicit edges
#
# Node Data:     701 x 1 (active)
# Geometry type: POINT
# Dimension:     XY
# Bounding box:  xmin: 7.522622 ymin: 51.94151 xmax: 7.546705 ymax:
#   51.9612
             geometry
          <POINT [°]>
1 (7.533722 51.95556)
2 (7.533461 51.95576)
3 (7.532442 51.95422)
4  (7.53209 51.95328)
5 (7.532709 51.95209)
6 (7.532869 51.95257)
# ... with 695 more rows
#
# Edge Data:     851 x 5
# Geometry type: LINESTRING
# Dimension:     XY
# Bounding box:  xmin: 7.522594 ymin: 51.94151 xmax: 7.546705 ymax:
#   51.9612
   from    to name        type                                geometry
  <int> <int> <chr>       <fct>                       <LINESTRING [°]>
1     1     2 Havixbecke~ reside~ (7.533722 51.95556, 7.533461 51.955~
2     3     4 Pienersall~ second~ (7.532442 51.95422, 7.53236 51.9537~
3     5     6 Schulte-Be~ reside~ (7.532709 51.95209, 7.532823 51.952~
# ... with 848 more rows

Expected behavior I think the old behaviour is a bit better. Happy to check the pillar docs to see how we can define an ad-hoc printing method.

R Session Info NA

loreabad6 commented 1 year ago

Hi @agila5, thanks for noticing this! Are you planning to work on this? Otherwise I will start checking the function refactoring since I am also fixing #256 which could then be in a single PR

agila5 commented 1 year ago

Hi @loreabad6! Unfortunately, I'm really busy for the next 2 weeks (approximately) so feel free to work on this issue if you can, otherwise I will explore the pillar docs sometime in October.