cyclestreets / cyclestreets-r Goto Github PK

For our purposes at least. From the example:

Any help on this gratefully received. Heads-up @EricKrg and @mvl22 (from CRAN pkg team):

    Package Information:
    Package: cyclestreets
    Version: 0.1.1
    Title: Route Planning and Other Services for Cyclists
    Author(s): person("Robin", "Lovelace", email = "[email protected]", role =
       c("aut", "cre"), comment = c(ORCID = "0000-0001-5679-6536")),
       person("Martin", "Lucas-Smith", role = c("aut")),
       person("Eric", "Krueger", role = c("cbt")))


Thanks, please use person() in the Authors@R field. The Author(s) and Maintainer field will be auto-generated from the information in the Authors@R field.



    Maintainer: Robin Lovelace <[email protected]>
    Description: The goal of cyclestreets is to provide a simple R interface
       to the CycleStreets.net routing service.


Please write URL in your description text in the form
<http:...> or <https:...>
with angle brackets for auto-linking and no space after 'http:' and 'https:'.

Please elaborate in your description what functinality CycleStreets.net provides.

Please write package names and software names in single quotes (e.g. 'cyclestreets') in  your description.

Please fix and resubmit.

I'm confident this is the next most useful function after journey. @mvl22 and @EricKrg please input and if you get a chance. Note I've created a boilerplate script in #9 that needs filling. Contributions very welcome!

The latter is clearer for input and output and matches route() in {stplanr}.

Please see the problems shown on
https://cran.r-project.org/web/checks/check_results_cyclestreets.html.

Please correct before 2021-11-05 to safely retain your package on CRAN.

Packages in Suggests should be used conditionally: see 'Writing R Extensions'.
This needs to be corrected even if the missing package(s) become available.
It can be tested by checking with R_CHECK_DEPENDS_ONLY=true.

As outlined in #65 this function is the major perf bottleneck at this stage.

As reported by @natesheehan:

Currently, very short routes do not work with the journey function.

Error:
Error in stats::filter(x, rep(1/n, n), sides = 2) : 'filter' is longer than time series
Example:

# dput(desire_line_town) getting lat long
origin = c(-0.214849749698027,51.5586119006974)
destination = c( -0.214888955159809,51.5564466729046)

a = cyclestreets::journey(
  origin,
  destination 
)
#> Loading required namespace: stplanr
#> Error in stats::filter(x, rep(1/n, n), sides = 2): 'filter' is longer than time series
mapview::mapview(a)
#> Error in eval(quote(list(...)), env): object 'a' not found
Created on 2021-05-19 by the reprex package (v2.0.0)

From the old cyclestreets repo...

Superceded by #69 which is ~10x more important.

E.g.

Linked to

#24

Opening this issue as a place to properly document efforts to generate accurate gradient estimates from cyclestreets elvation data.

A blog post on this R module would be gladly accepted for
https://www.cyclestreets.org/news/

Causing routing failure FYI @Robinlovelace @mvl22

E.g. https://api.cyclestreets.net/v2/mapdata?key=c047ed46f7b50b18&limit=400&types=way&wayFields=name,ridingSurface,id,cyclableText,quietness,speedMph,speedKmph,pause,color&zoom=16&bbox=-9.160863,38.754642,-9.150128,38.75764

This may be more of a CycleStreets issue than a cyclestreets-r issue but reporting here in any case. Any ideas how to delete the job shown below @mvl22 ?

There have been issues with processing results from batch processing, worth checking if those can be overcome by using a different read function.

Also allow all columns to be returned

As raised by @mem48 here nptscot#1

There is now an API call to remove the batch (including all data) rather than having it left lying about.

https://www.cyclestreets.net/api/v2/batchroutes.deletejob/

This should be added into the batch function, used after a successful CSV download.

• Update urls in documentation
• Move across!

I think this is a great idea proposed by @mvl22, should lead to tighter CycleStreets integration and help us fix issues with expertise from the cyclestreets team ; )

Any chance we might have this instead as an official repo at

cyclestreets/cyclestreets-r

instead of

Robinlovelace/cyclestreets

? Would be great to have such officialness, and we are aiming to put other wrapper-type stuff there over time.

While trying to do routing using the new gradient_smooth approach, I've found that it fails for very short routes. It looks like we need to edit journey.R to avoid this.

> library(stplanr)
> library(parallel)
> library(cyclestreets)
> cl = makeCluster(detectCores())
> clusterExport(cl, c("journey"))
> od_lsoas_short = readRDS("od_lsoas_short.Rds")
> split_grouping_variable = rep(1:331, each = 1000)[1:nrow(od_lsoas_short)]                                 
> od_lsoas_short_list = split(od_lsoas_short, split_grouping_variable)
> system.time({routes_lsoa_1 = route(l = od_lsoas_short_list[[1]], route_fun = cyclestreets::journey, cl = cl, smooth_gradient = TRUE)})
  |++++++++++++++++++++++++++++++++++++++++++++++++++| 100% elapsed=02m 06s
Most common output is sf
These routes failed: 818
The first of which was:
<simpleError in stats::filter(x, rep(1/n, n), sides = 2): 'filter' is longer than time series>
   user  system elapsed 
  1.945   0.490 125.794 

The geometry below shows that this route only contains one segment.

> od_lsoas_short$geometry[818,]
Geometry set for 1 feature 
geometry type:  LINESTRING
dimension:      XY
bbox:           xmin: 0.1431735 ymin: 51.5433 xmax: 0.1468841 ymax: 51.54429
geographic CRS: WGS 84
LINESTRING (0.1431735 51.54429, 0.1468841 51.5433)

Reproducible example: hope to add one soon. In the meantime any ideas @mvl22? We're using POST requests for this.

As discussed with @mvl22. Please can you provide a link to the batch routing api?

Good news, we can now go above 15k lines, as per #51 and shown below for good speed-up, nearly 10x compared with normal routing.

However, when I go from 30 to 40k lines it fails again. Any ideas @mvl22 ?

Looking at the output I think it would be good to have optional unchanging variables representing journey origin and destination. Working on this...

Based on info from @joeytalbot I suspect that the batch() is returning incorrect ids. Do you have a reproducible example desire line with IDs in Ireland Joey? Great work on identifying the issue.

The old function stplanr::route_cyclestreet could return grouped data (one row per route) and derived values cum_hill change_elev dif_max_min up_tot down_tot av_incline co2_saving calories busyness

The new function cyclestreets::journey does not group (one row per route segment), and cannot calculate these grouped values.

This seems like a limitation and makes the cyclestreet package less useful.

It would be good to have an interface to the batch routing API, enabling upload of .csv files and download of .geojson files (or output in other formats).

This issue can track development of this functionality.

# Aim: test batch routing
library(stplanr)
library(cyclestreets)

# input data
?odrust::odr_jitter
library(odrust)
od = readr::read_csv("https://github.com/dabreegster/odjitter/raw/main/data/od.csv")
zones = sf::read_sf("https://github.com/dabreegster/odjitter/raw/main/data/zones.geojson")
road_network = sf::read_sf("https://github.com/dabreegster/odjitter/raw/main/data/road_network.geojson")
set.seed(42)
od_jittered = odr_jitter(
  od,
  zones,
  subpoints = road_network,
  disaggregation_threshold = 50
)

od_geo = od_jittered[1:3, 0]
coord_example = od::od_coordinates(od_geo)
readr::write_csv(as.data.frame(coord_example), "coord_example.csv")
sf::write_sf(od_geo, "coord_example.geojson")
coord_example_sf = sf::st_sf(coord_example, geometry = od_geo$geometry)
coord_example_cs = route(coord_example_sf, route_fun = journey)
sf::write_sf(coord_example_cs, "batch_output_example_route_stplanr.geojson")

As shown in the example below, the provisionName column is duplicated for some routes it seems:

start_coords = c(-8.80639, 52.50692)
  end_coords = c(-8.80565, 52.51329)
  j = cyclestreets::journey(from = start_coords, to = end_coords)
  names(j)
#>  [1] "name"              "distances"         "time"             
#>  [4] "busynance"         "quietness"         "gradient_segment" 
#>  [7] "elevation_change"  "provisionName"     "start_longitude"  
#> [10] "start_latitude"    "finish_longitude"  "finish_latitude"  
#> [13] "crow_fly_distance" "event"             "whence"           
#> [16] "speed"             "itinerary"         "plan"             
#> [19] "note"              "length"            "west"             
#> [22] "south"             "east"              "north"            
#> [25] "leaving"           "arriving"          "grammesCO2saved"  
#> [28] "calories"          "edition"           "provisionName.1"  
#> [31] "geometry"          "gradient_smooth"

^{Created on 2023-08-05 with reprex v2.0.2}

To https://github.com/ropensci/onboarding/issues/ I suggest. Happy with this @mvl22 and @EricKrg ?

Prepare for release:

• Check current CRAN check results
• Polish NEWS
• devtools::build_readme()
• urlchecker::url_check()
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel()
• rhub::check_for_cran()
• revdepcheck::revdep_check(num_workers = 4)
• Update cran-comments.md
• Draft blog post

Submit to CRAN:

• usethis::use_version('minor')
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()
• Finish blog post
• Tweet
• Add link to blog post in pkgdown news menu

When a route fails, it would be very helpful to show the error message that explains why the route failed. E.g.

"Too short: journeys must be longer than 4 metres. (Your requested journey was 0 metres)."

This is especially needed for the batch routing, where a single failed route prevents the entire process from completing.

With this file. Heads-up @mvl22 I cannot see an error message here, may be the parsing on the R side but if you see anything unusual with this (batch id 383) please let us know, also in email.

Context: nptscot/npt#154

Split out from #51

As documented in U-Shift/biclar#19 (comment) we should change it.

We should change it to 1.