initial implementation of linetrace #24
Merged
+316
−9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does
cf #11 for supporting linestrings. This is a work-in-progress and needs some deliberation.
I tried to come up with an equivalent name to "polyfill", and came up with "linetrace". Happy to change it.
There's a number of ways this could be implemented, depending on a few inter-related criteria:
explode
?explode
do with a multilinestring? (Perhaps a MultiIndex?)In general I think that the return type should be an ordered list, not a set. However I don't permit repeated cells if they are in sequence. Non-sequential repeats are possible to handle cases like self-intersection.
This currently supports multilinestring input, but information about the parts is not retained. I thought about an extra parameter to handle these, maybe
retain_parts
, True by default.Happy to take direction on the appropriate behaviour, but at some level there's probably an element of opinion, unless there's a standard (even a de facto one) for how linestrings should be represented in a DGGS---if the idea makes sense at all.