🔧route_dodgr example; closes #305

[mpadge]

No description provided.

[Robinlovelace]

Many thanks @mpadge - and re-enforces the need for a standard way of representing origin-destination coordinates, and a function to translate between them. Best I've got so far is below.

Worth creating a class system / package for handling OD data? Note, the (sparse) matrix representation is almost completely lacking in stplanr, which needs to be addressed, as per #253.

Here's what works so far - @mpadge which is best from a dodgr perspective of options 1:3? Note this is similar to GIScience/openrouteservice-r#42 (comment)

library(stplanr)
l = flowlines_sf[2:4, ]

# representations of the data
line2df(l)            # 1: 'Wide' coordinate list
#> # A tibble: 3 x 5
#>      L1    fx    fy    tx    ty
#>   <dbl> <dbl> <dbl> <dbl> <dbl>
#> 1     1 -1.52  53.8 -1.54  53.8
#> 2     2 -1.52  53.8 -1.55  53.8
#> 3     3 -1.52  53.8 -1.53  53.8
sf::st_coordinates(l) # 2: 'Long' coordinate list
#>              X        Y L1
#> [1,] -1.516734 53.82887  1
#> [2,] -1.535617 53.82847  1
#> [3,] -1.516734 53.82887  2
#> [4,] -1.550807 53.82442  2
#> [5,] -1.516734 53.82887  3
#> [6,] -1.530712 53.81756  3
p = line_to_points(l) # 3: consecutivee points
p 
#> Simple feature collection with 6 features and 1 field
#> geometry type:  POINT
#> dimension:      XY
#> bbox:           xmin: -1.550807 ymin: 53.81756 xmax: -1.516734 ymax: 53.82887
#> epsg (SRID):    NA
#> proj4string:    NA
#>   id                          p
#> 1  1 POINT (-1.516734 53.82887)
#> 2  1 POINT (-1.535617 53.82847)
#> 3  2 POINT (-1.516734 53.82887)
#> 4  2 POINT (-1.550807 53.82442)
#> 5  3 POINT (-1.516734 53.82887)
#> 6  3 POINT (-1.530712 53.81756)

# All to all options
points2odf(p)
#>    O D
#> 1  1 1
#> 2  1 1
#> 3  1 2
#> 4  1 2
#> 5  1 3
#> 6  1 3
#> 7  1 1
#> 8  1 1
#> 9  1 2
#> 10 1 2
#> 11 1 3
#> 12 1 3
#> 13 2 1
#> 14 2 1
#> 15 2 2
#> 16 2 2
#> 17 2 3
#> 18 2 3
#> 19 2 1
#> 20 2 1
#> 21 2 2
#> 22 2 2
#> 23 2 3
#> 24 2 3
#> 25 3 1
#> 26 3 1
#> 27 3 2
#> 28 3 2
#> 29 3 3
#> 30 3 3
#> 31 3 1
#> 32 3 1
#> 33 3 2
#> 34 3 2
#> 35 3 3
#> 36 3 3
points2flow(p)
#> Simple feature collection with 36 features and 2 fields
#> geometry type:  LINESTRING
#> dimension:      XY
#> bbox:           xmin: -1.516734 ymin: 53.82887 xmax: -1.516734 ymax: 53.82887
#> epsg (SRID):    NA
#> proj4string:    NA
#> First 10 features:
#>    O D                       geometry
#> 1  1 1 LINESTRING (-1.516734 53.82...
#> 2  1 1 LINESTRING (-1.516734 53.82...
#> 3  1 2 LINESTRING (-1.516734 53.82...
#> 4  1 2 LINESTRING (-1.516734 53.82...
#> 5  1 3 LINESTRING (-1.516734 53.82...
#> 6  1 3 LINESTRING (-1.516734 53.82...
#> 7  1 1 LINESTRING (-1.516734 53.82...
#> 8  1 1 LINESTRING (-1.516734 53.82...
#> 9  1 2 LINESTRING (-1.516734 53.82...
#> 10 1 2 LINESTRING (-1.516734 53.82...
points2line(p)
#> Simple feature collection with 36 features and 2 fields
#> geometry type:  LINESTRING
#> dimension:      XY
#> bbox:           xmin: -1.516734 ymin: 53.82887 xmax: -1.516734 ymax: 53.82887
#> epsg (SRID):    NA
#> proj4string:    NA
#> First 10 features:
#>    O D                       geometry
#> 1  1 1 LINESTRING (-1.516734 53.82...
#> 2  1 1 LINESTRING (-1.516734 53.82...
#> 3  1 2 LINESTRING (-1.516734 53.82...
#> 4  1 2 LINESTRING (-1.516734 53.82...
#> 5  1 3 LINESTRING (-1.516734 53.82...
#> 6  1 3 LINESTRING (-1.516734 53.82...
#> 7  1 1 LINESTRING (-1.516734 53.82...
#> 8  1 1 LINESTRING (-1.516734 53.82...
#> 9  1 2 LINESTRING (-1.516734 53.82...
#> 10 1 2 LINESTRING (-1.516734 53.82...

^{Created on 2019-04-17 by the reprex package (v0.2.1)}

[mpadge]

Yeah, these are all really worthy considerations. The dodgr representation is always the first of your examples - a wide coordinate list. Any other format is dangerous, because it relies on two inherently fragile aspects: (1) indexing in an arbitrary additional column; and (2) arbitrary ordering of (from->to) within those indices. The wide representation is more robust, and also more computationally inefficient in typical table filter/join scenarios (meaning within R, in any dplyr terms).

The things being aggregated in any of your subsequent examples are then simply rows of a table, so a full LINESTRING is just a sequence of former table rows. Your other 2 examples require rows to first be somehow packed together end-to-end to create edges, and then edges assembled in sequence to make a LINESTRING. The points2flow and points2line cases are already handled by dodgr::dodgr_to_sf(), which does exactly that.

BUT - this still leaves the abidingly important representation in OD terms, which dodgr can't currently do. There is simply no version of your points2odf() function, and that is something that we both really need. Let's continue this is a separate issue somewhere else ...

[Robinlovelace]

Thanks for the detailed and insightful response. Yes one to think about...