Support for manually created tree sequences with spatial information #144
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.
While doing some follow up inference work, it turned out that slendr's
ts_load()
function makes an implicit assumption that the only spatial tree sequences (those which store spatial coordinates in the individual tree sequence table) are those coming from SLiM. Naturally, loading a manually created tree sequence (a tree sequence composed from individual tables) ignored spatial coordinate columns.So, with a tree sequence created like this:
calling
ts_nodes(ts)
on a serialized andts_load()
-ed tree sequence returns this (note the absence of coordinates of nodes):This PR is a mildly terrifying attempt at a few surgical cuts deep into the slendr internals to make
ts_load()
load spatial columns even for such tree sequences without breaking anything else.With changes introduced by this PR,
ts_load()
and subsequentts_nodes(ts)
do what they're supposed to (note the presence of the location column as well as the fact that the data is now in the spatial sf data format):The question now is, did something else break in the process? Guess we will find out!