luukvdmeer / sfnetworks

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

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

Open agila5 opened 12 months ago

agila5 commented 12 months 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 10 months 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 10 months 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.