R interface

[Robinlovelace]

Is your feature request related to a problem? Please describe.

An R interface would make this software project available to more people.

Describe the solution you'd like

install.packages("cityseer") # or similar
# use cityseer functionality

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

I've recently been trying a number of alternatives, including cugraph, cppRouting, networkx, rustworkx and depthmapx. None of them have the combination of features and performance that this package does.

Additional context

I'm involved in other cross-language projects such as https://github.com/JosiahParry/anime which has R and Rust packages. Tagging @JosiahParry here FYI, this is partly inspired by your work in this space. See https://github.com/Robinlovelace/cityseerr for a proof-of-concept. An alternative would be a separate repo but I think there are benefits of having bindings like R and Python in the same repo for CI and coherence. Would you welcome a PR?

[songololo]

Hi @Robinlovelace - I am definitely supportive of this idea and happy to think through the best approach.

A fair bit of the network cleaning and prep is in Python, would you want this accessible from R as well or more so the core rust algos for centralities and network based aggregation?

[Robinlovelace]

Great to hear you're up for it in principle, fantastico! 🎉

I've been thinking about the best approach and looked at how other Rust projects with both Python and R interfaces structure things:

• apache/arrow - uses r and python directories
• JosiahParry/anime - uses r and py directories
• apache/sedona-db - uses r/sedonadb and python/sedonadb (a bit more nested)

My first thought would be keeping it simple with an r/ directory at the repo root.

Some considerations:

• rextendr vs savvy - For the Rust-R bindings, rextendr is the more established option with broader community adoption, while savvy is newer but has some nice ergonomics. Given this is a first iteration, I'd suggest rextendr for its maturity and documentation.

• Scope for initial PR - Should I aim to expose just a core subset of functionality first (e.g., network analysis basics) to establish the pattern, then iterate? Or do you have recommendations on places to start? I guess getting the network data structure in and out of Rust would be a key consideration here and once that is working many things can build on that.

• API naming conventions - I guess making the R interface try to closely mirror the Python API (e.g., network_structure() → network_structure()) makes sense

• CI integration - Happy to add R package checks to the existing GitHub Actions workflow.

I've dabbled with Rust but have decent experience developing and publishing R packages (including CRAN submissions), so any pointers on the Rust/interface side are very welcome. The proof-of-concept at Robinlovelace/cityseerr is pretty bare-bones but could serve as a starting point.

Looking forward to collaborating on this!

[songololo]

Hi @Robinlovelace - my apologies for the slow response...!

Everything you've said makes sense to me.

Starting with an R source folder similar to the Python source folder sounds like a good course of action. We can then compartmentalise the python and the R functionality while keeping the core rust functionality shared in common.

Yes, starting with the essential functionality like the network structure would be the way to go, because as you say we can then add functionality incrementally. I guess it's up to debate just how much of the Python functionality (network cleaning etc.) one would want to expose to the R ecosystem but this can be answered over the time as demand arises or time allows.

Let me know if you need any feedback, but otherwise I'm quite comfortable with you doing what makes sense and then we can tweak and figure things out as they develop.

[Robinlovelace]

Good timing on your response as I was just doing some more benchmarks, starting with sfnetworks and dodgr and then cityseer (the Python version in the first instance, R version TBC)! Not sure when I'll get on it but having this green light is great, PR incoming... at some point!

[Robinlovelace]

Preliminary results based on the following setup

• Network: ~18,700 road edges around Leeds, UK
• Ground truth: 191 AADT (annual average daily traffic) sensor records
• Tools tested: cityseer, sfnetworks (R), dodgr (R)

Headline results after running 24 tests so far:

Tool	Variant	Driving	Cycling	Walking	Time
sfnetworks	betweenness	0.28	0.09	0.01	18.4s
dodgr	foot_profile	0.00	0.14	0.03	8.5s
cityseer	shortest_1600m	0.01	0.08	0.14	3.0s
cityseer	angular_800m	0.00	0.04	0.11	3.0s

Cityseer seems excellent for walking prediction estimation.

Happy to share the full benchmark repo when ready. Great package and looking forward to contributing!

[songololo]

Sounds promising!

Thinking a bit more, it might make sense to split the rust code itself into 3 parts:

• a core folder which is Python / R agnostic rust only code
• pyo3 rust wrappers for compiling to python
• R equivalent wrappers

If this makes sense then maybe in about two or three weeks I can spend some time to get this agnostic core part separated so that it is easier to start adding the R version without running into Python complications.

[JosiahParry]

@songololo yes! this is exactly how i've done it at https://github.com/JosiahParry/anime/

[Robinlovelace]

Heads-up @songololo I'm drafting a GISRUK abstract on this, plan to email you, if I can find your address!