Can we handle individual locations in SLiM directly in projected CRS units?

[bodkan]

@petrelharp pointed out that lots of the projected CRS coordinates <---> pixel coordinates voodoo I'm currently doing might be simplified/eliminated by specifying the projected CRS spatial extent (bounding box) dimensions right in the call to setSpatialBounds() here. I completely missed this option when I wrote the first version of the backend, and stuck to it through several refactoring attempts.

This will probably require significant changes throughout the entire codebase (it doesn't involve just the backend script but affects many steps throughout the simulation pipeline). I might not do this during the current round of backend script refactoring but will tackle this soon.

This will not only make the codebase simpler to maintain, but together with saving the spatial information metadata in the tree sequence output (see #61 which will be implemented in the upcoming refactoring PR), it will make it easy to expose the locations of tree sequence nodes to an appropriate spatial data format without having to first do the awkward projected CRS coordinates <---> pixel coordinates conversion.

[bhaller]

Yeah, I just assumed that there was some reason you weren't doing this. :-> It does seem like it would make things better. It would make the models resolution-independent; the distances for spatial interactions like competition and mate choice would be in a unit based on the CRS (or in meters?), not in pixels, and so you could change the pixel resolution of the maps and you wouldn't have to change the model code at all. That would be nice.

[bodkan]

Yes, that's another excellent point!

Fortunately, the distances in the model have always been specified in projected CRS units (meters) and not pixels, so the user didn't have to worry about that. But regardless, this is another situation where the CRS <---> pixel conversion currently happens internally, and it will simplify the codebase quite a bit.

And no, there wasn't a reason for this other than that I wasn't aware that the dimensions of the spatial bounds can be in whatever "application-specific units" the user wants to use. This is really nice. 👍 Yet again, we have:

                              SLiM : Martin
                                 1 : 0

:)

[bhaller]

Yeah, I meant that distances in the SLiM model could be in logical distance units, rather than pixels; I know they're already in logical distance units in slendr's model. :->

[percyfal]

I have a question related to the interpretation of locations and coordinates. I'm currently using the documentation example in slendr to simulate a test dataset for a visualization of GNNs (cf Spatial equivalent of GNN). The tree sequence individual locations reported by SLiM are in the range 0-500 and I'm not quite sure how to convert them back to lon,lat coordinates, or if they could be used as is in a coordinate reference system of some kind (I'm pretty new to these datatypes, sorry if I'm missing something obvious). Ideally I'm looking for a way to leverage the interactive plotting capabilities of the python geoviews package.

[bodkan]

Which example do you have in mind here? Could you please open a new issue and paste a complete script code that I could run? It would help me narrow down to the issue you're having.

The sf package which all spatial juggling in slendr is based around should make it possible to convert the coordinates to whatever system you need (abstract or realistic).

If you give me an example script which produces a table with which you're exactly struggling with, I'd be happy to help with the format conversion. I'm not familiar with geoviews, but as long as it accepts something reasonably well standardized as input, we can format slendr outputs appropriately for your usecase.

(And no worries about being confused about geospatial data types... it took me weeks to wrap my head around the format standards and objects.)