weight_streetnet.sc method

[mpadge]

Following on from #64, the currently singular weight_streetnet function needs to implement (currently) two distinct methods, weight_streetnet.sf and weight_streetnet.sc, with both of them taking care of the full necessary duplication of directed edges. Ping @mdsumner

[mpadge]

... although, having said that, this actually needs a bit more thing in regard to the "master" issue, the whole idea of which is to replace the dodgr::streetnet format with sc/SC. As indicated in that issue, and this osmdata::osmdata_sc() issue, the general idea is to use silicate::SC as a "master" class to replace current dodgr classes, and be able to be submitted directly to all dodgr operations. It seems at the moment that the only major thing lacking from such a "master" class is the edge replications needed to represent the directed graph. That in turn suggests that the solution lies in first addressing the osmdata issue, before returning to here. It's hard to see clearly at the moment, but I think this would seem to be the best approach. The only real danger that I can see is that the osmdata_sc() function is intended to be as generic as possible, while an extra dir parameter is specific only to the potentially restricted subset of street networks. On the other hand, it's called Open Street Map for a reason, and street network extraction is likely always going to be the major use of osmdata.

[mpadge]

Another Q @mdsumner: An integral part of the whole SC -> dodgr thang is going to be attributing properties / values / variables to vertices. You've clearly got in your core silicate forms:

SC0::vertex [x_, y_, ...]
SC::vertex [x_, y_, ..., vertex_]

are the ...'s reflective of a general vision of vertices possessing arbitrary intrinsic properties? And is that the envisioned place these might be stored? If yes and yes, then I think I've got most of the building blocks pretty clear in my head and am ready to move on this. (The osmdata issue is all clear, I've just gotta implement that.)

[mdsumner]

Yep, also toyed with nominated spaces so attribute names could be arbitrary but that is hard.

Just also think about how some data belongs on link or instance tables rather than on a normalized vertex table. Needs more attention ...

[mpadge]

This is now implemented, and allows the following:

library (osmdata)
#> Data (c) OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
library (dodgr)
dat <- opq ("omaha nebraska") %>%
    add_osm_feature (key = "highway") %>%
    osmdata_sc ()
elev_file <- "/data/elevation/cut_n30w120.tif" # 5-by-5 geotif from http://srtm.csi.cgiar.org/srtmdata
dat <- osm_elevation (dat, elev_file) # new osmdata fn; currently only on "elevation" branch
#> Loading required namespace: raster
#> Elevation data from Consortium for Spatial Information; see http://srtm.csi.cgiar.org/srtmdata/
system.time (edges <- weight_streetnet (dat, wt_profile = "bicycle"))
#> Loading required namespace: geodist
#> Loading required namespace: dplyr
#>    user  system elapsed 
#>   2.052   0.000   2.055
knitr::kable (head (edges))

.vx0	.vx1	edge_	.vx0_x	.vx0_y	.vx1_x	.vx1_y	d	object_	highway	oneway	oneway_bicycle	d_weighted	time
1903265686	1903265664	1dD1JNQCX6	-96.18100	41.27039	-96.18099	41.27046	7.852440	14071785	living_street	FALSE	FALSE	8.265726	0.1571181
1903265664	1903265638	EUC3hhbuNQ	-96.18099	41.27046	-96.18095	41.27051	6.710915	14071785	living_street	FALSE	FALSE	7.064121	0.0353206
1903265638	1903265710	4SlTXInYcZ	-96.18095	41.27051	-96.18072	41.27078	35.727600	14071785	living_street	FALSE	FALSE	37.608000	0.1880400
1903265710	1903265636	HQpFegxYmu	-96.18072	41.27078	-96.18068	41.27083	5.805178	14071785	living_street	FALSE	FALSE	6.110713	0.0305536
1903265636	1903265685	q4UUROLOIy	-96.18068	41.27083	-96.18066	41.27087	5.742714	14071785	living_street	FALSE	FALSE	6.044962	0.0302248
1903265685	1903265678	LVMp14Nh3M	-96.18066	41.27087	-96.18063	41.27096	9.789188	14071785	living_street	FALSE	FALSE	10.304408	0.0515220

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

The whole thing is so much more efficient than sf - like at least 5 times faster - and the final edges matrix even incorporates slope calculations from the elevation data, and has both distances and times, so the latter can be used for fastest routes.

@mdsumner This represents the primary step towards dodgr becoming entirely silicate-based. It's so much easier and more efficient than sf, and might even move towards dumping sf completely and relying instead on our notional "universal sf-builder". The code base would be reduced enormously in that case, strongly suggesting it should be done.

@Robinlovelace Time-based routing almost implemented now; will be finished in #76

[mdsumner]

Sweeeeet. I made fair progress on cleaning silicate up, gotta get that home!

[Robinlovelace]

Great progress indeed.