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

Implement segmentation as part of the package #41

Merged
merged 36 commits into from
Dec 19, 2024
Merged

Conversation

fnattino
Copy link
Contributor

No description provided.

@fnattino fnattino linked an issue Nov 18, 2024 that may be closed by this pull request
Copy link
Contributor Author

@fnattino fnattino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @cforgaci , I finally managed to move forward with the segmentation module. Happy to hear your thoughts, for now only tests are missing.

Thinks to think on (maybe later on):

  • which functions should be exported and which should remain private (we should fix it consistently everyewhere)?
  • should we create a module for all the general-purpose geometry-related functions e.g. to buffer, split, find longes geometry, etc. (geometry.R or maybe even better sf.R?)

R/delineate.R Show resolved Hide resolved
@fnattino fnattino marked this pull request as ready for review December 15, 2024 22:16
@fnattino fnattino requested a review from cforgaci December 15, 2024 22:29
@fnattino
Copy link
Contributor Author

fnattino commented Dec 16, 2024

TODO:

  • Rename inner functions to get_corridor and get_segments
  • Update vignette

Copy link
Contributor

@cforgaci cforgaci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fnattino many thanks for this! I left some comments and suggestions, nothing fundamental. Can you please have a look?

R/segments.R Outdated Show resolved Hide resolved
R/segments.R Outdated Show resolved Hide resolved
R/segments.R Outdated Show resolved Hide resolved
R/segments.R Outdated Show resolved Hide resolved
R/segments.R Outdated Show resolved Hide resolved
R/segments.R Outdated Show resolved Hide resolved
vignettes/corridor-segmentation.Rmd Outdated Show resolved Hide resolved
vignettes/corridor-segmentation.Rmd Outdated Show resolved Hide resolved
vignettes/corridor-segmentation.Rmd Outdated Show resolved Hide resolved
We then delineate segments in the corridor. The algorithm spits the corridor using river-crossing transversal edges that form continuous lines in the network:

```{r eval=FALSE}
# TODO remove eval=FALSE when the corridor is available as packaged data
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this still needs to be added, but it falls outside the scope of this PR. Where should we save that? It is neither bucharest_osm, nor bucharest_dem, so it would make sense that it is a separate object called bucharest_delineation or bucharest_del which contains the corridor, segments and riverspace. Then we can use bucharest_del$corridor here. What do you think @fnattino?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe bucharest_delineation? Will use this here and raise an issue pointing to this thread.

@cforgaci
Copy link
Contributor

cforgaci commented Dec 17, 2024

  • which functions should be exported and which should remain private (we should fix it consistently everyewhere)?

Maybe we expose only the top-level functions; in the segments.r module, for instance, we would export only get_segments(). We can still generate documentation for functions like clip_and_filter() and add #' @noRd to smaller helper funcions as you did. Non-exported functions would still be available to the user via the ::: namespace operator. Would that work?

  • should we create a module for all the general-purpose geometry-related functions e.g. to buffer, split, find longes geometry, etc. (geometry.R or maybe even better sf.R?)

sf.R would make most sense. And I see indeed that the find_*() functions from this module could move there.

@fnattino fnattino requested a review from cforgaci December 19, 2024 14:18
@fnattino
Copy link
Contributor Author

Hi @cforgaci - I think I have addressed all the comments, do you want to have a look?

Copy link
Contributor

@cforgaci cforgaci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good @fnattino! This looks ready to be merged.

R/network.R Show resolved Hide resolved
@fnattino fnattino merged commit dfa958c into main Dec 19, 2024
8 checks passed
@fnattino fnattino deleted the 37-segmentation-fn branch December 19, 2024 14:46
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

Successfully merging this pull request may close these issues.

Add corridor segmentation module
2 participants