Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for multiple travel cost columns #21

Open
1 of 6 tasks
rafapereirabr opened this issue Jun 29, 2022 · 1 comment
Open
1 of 6 tasks

Allow for multiple travel cost columns #21

rafapereirabr opened this issue Jun 29, 2022 · 1 comment
Assignees

Comments

@rafapereirabr
Copy link
Member

rafapereirabr commented Jun 29, 2022

The package currently allows users to pass only one travel cost column. However, it would be good to have a more flexible approach that allow users to pass multiple travel cost columns.


Edit by Daniel:

How would that work for each measure we have implemented?

  • cost_to_closest(): we wouldn't have a single minimum cost for each origin anymore. Instead, the result would be a pareto frontier of optimal costs. Output would need to include a column for each travel cost, specifying the costs at each pareto frontier edge.
  • cumulative_cutoff(): apply two+ restrictions at the same time. Output would need to include a column for each travel cost, in which the specified cutoffs would be listed.
  • cumulative_interval(): similar to above, but we would need to calculate all possible combinations of cutoffs inside the specified interval. Then we would have to summarize the accessibility estimates calculated from all these combinations. Output would need to include a column for each travel cost, in which the specified intervals would be listed.
  • balancing_cost(): similar to cost_to_closest().
  • gravity(): would need to be able to receive a list of decay functions, each would be simultaneously applied, each with its own cost. Output would need to include a column for the decay function used for each travel cost, in which the specified decay parameters would be listed.
  • spatial_availability() and floating_catchment_area(): similar to gravity().
@dhersz dhersz self-assigned this Jul 1, 2022
@dhersz
Copy link
Member

dhersz commented Jun 2, 2023

3045a20: cumulative_cutoff() works with more than one travel cost

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants