-
Notifications
You must be signed in to change notification settings - Fork 16
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
function to insert new vertices #40
Comments
The idea is to add a new node somewhere along an existing edge. One element to consider in this task is the location of the new node, whether it should be placed halfway the edge or whether it should be placed at a specific location set by the user. In the case of my SO question, it's the second case, where the user sets a pair of Thanks for taking this task on board ! |
For reference, the answer to this stack exchange question provides code which seems to be useful for this extra functionality: https://gis.stackexchange.com/questions/288445/split-polyline-by-point-using-sf-package-in-r |
Just reading this ... the new node should be created at the closest point to the
Maybe the |
That commit adds a new function |
thanks for the follow up ! |
Yeah, sorry it took sooooo long! It's still not ideal, but there are a number of alternative paths from here on, so I think it's just best to first spin out this initial version and see what kind of feedback it might generate before moving further with it. Thanks for the impetus! Please give any feedback, insight, suggestions you might have either here, or in new issues. |
Following on from @rafapereirabr's SO question, it would be very useful for
dodgr
to incorporate the ability to insert new points in a network. Current routing can accept arbitrary points, but these are simply mapped to nearest network points and then forgotten. Incorporation of new points would involve modification of the underlying network, so a network with an edge between A and B would be modified through callingto
or,
The points A and B could be automatically identified as the nearest two points, yet this may not necessarily be what is desired. It will likely be necessary to have an option to override this default behaviour that would then graphically show the default, yet enable other options to be specified.
@rafapereirabr: this might take a while to implement, because it will be more appropriately incorporated within the soon-to-appear-on-cran
silicate
, and associatedsc
, rather thansf
orsp
representations. This whole issue is therefore likely to first be shifted tosilicate
and ultimately resolved there. cc @mdsumnerThe text was updated successfully, but these errors were encountered: