Two general questions

[rsbivand]

1. Does/could spflow https://cran.r-project.org/package=spflow https://github.com/LukeCe/spflow relate to si? Could you perhaps contact Luke to see whether data structures might not be coordinated where relevant?

2. I'm unsure where the Euclidean distance is explained - the centroids in the examples seem to be geographical coordinates? geodist::geodist() is used, you claim that this is as sf, but it isn't; sf uses s2 for geographical coordinates. Without an AOI and epoch, claims of high accuracy are misleading anyway, unless one discards plate tectonic movement (agreed, not many SI models cross plate boundaries). Is input checked to be "OGC:CRS84" anywhere? Could input be projected?

[Robinlovelace]

Hi Roger, thanks for the feedback. These are early days on the package. Feedback now is especially valuable in terms of deciding the direction of travel and whether or not the package is even needed or if it reinvents wheels, as per #5. In addition to that a bit of context may be helpful about this, which maybe should go in the README: I put this package idea together quickly after real world need and, wanting to get feedback and thinking it may be of use/interest to others have put it out there. We may have slightly jumped the gun on putting it out there. Hopeful that the 'go fast and break things' approach and getting conversations going around open source software for reproducible SIM development will be of use/interest to people in or interested in this field.

In terms of your questions.

1. Yes absolutely, I came across that and would be great to link up. Not sure if it accepts destination features that are different from origin features or how the geographic side works, but it seems the modelling side seems really strong. Will get in touch with Luke for sure, can envision a number of ways of making that happen, not least using spflow modelling functions as an input into si_predict() as alluded to in How should the {si} package work? / Roadmap ideas #5.
2. Euclidean distance is not explained, we could add a message and/or point out that projected data is recommended when accuracy of distance calculations in is important. Overall, however, my perception is that accuracy is not important here: road network distance is much more important and this is possible by using a route_distance column for each OD pair that needs to be calculated. But take the point and accuracy may be important in some situations. Worth stating the importance of route vs Euclidean distance in the README/docs/other? Worth allowing the user to use different distance-calculating functions?

[rsbivand]

1. Yes, as a choice in si_predict()would be good; may need a calibration step, then it might be better there.
2. Certainly; I guess the target might reasonably be to treat distance as a possibly biassed estimate of the underlying weighted directed graph? Maybe Luke has some ideas too?