search

dabreegster / odjitter

Disaggregate zone-based origin/destination data to specific points
Apache License 2.0
12 stars 6 forks source link

Consider an rextendr interface #22

Open dabreegster opened 2 years ago

dabreegster commented 2 years ago

@Robinlovelace, I want to understand the current friction of R calling odjitter by command-line. https://github.com/atumworld/odrust/blob/main/R/odr_jitter.R is how it works today, correct?

Is the problem...

1) Having to compile the Rust tool on a target system? (#6 solves if so) 2) Packaging for CRAN and having a dependency on any extra binary tool? 3) Slow to write input CSV or zone geojson? 4) Slow to read the output geojson? (We can look at geopackage, flatgeobuf, etc if so)

or something else?

Robinlovelace commented 2 years ago

@Robinlovelace, I want to understand the current friction of R calling odjitter by command-line. https://github.com/atumworld/odrust/blob/main/R/odr_jitter.R is how it works today, correct?

Correct, that's a crude hack involving system calls but seems to work fine for all inputs I've seen..

Robinlovelace commented 2 years ago

Regarding the questions, rextendr

  1. Definitely is good from the perspective of 1. because it auto compiles the crate on install.packages() from R which is neat (currently working but that's all it does, compiles and then is not wired up).
  2. rextendr should ease the CRAN process compared with system calls which may not pass CRAN inspections
  3. Minor issue separate from rextendr but would speed up R/Rust IO if we do it via temp files (which seems logical at this stage)
  4. Again minor issue but could speed things up, would be good to offer GeoJSON and maybe other file formats, I actually think GeoJSON is a reasonable default