Back to the main page.
Bug 3142 - add coordsys field consistently to more data-objects
| Status | CLOSED FIXED |
| Reported | 2016-06-13 09:22:00 +0200 |
| Modified | 2019-08-10 12:41:27 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | 2032 |
| Blocks: | |
| See also: |
Jan-Mathijs Schoffelen - 2016-06-13 09:22:22 +0200
Last weekend two people asked questions on the discussion list that in the end are related to coordinate system issues, and which are most likely user errors. This is a recurring topic and somehow explaining it again and again does not stick. One way to be more informative towards the user is to more explicitly and consistently use a coordsys field in data objects that contain geometric information in 3D space: -grad/elec -headmodel -sourcemodel -source -mri -> this one has it, but as far as I know, the others don't. 1) Having it in grad/elec, headmodel, sourcemodel also allows for an explicit check of consistency of coordinate systems (and goes beyond the metrical units). 2) Having it in sourcemodel, and let it percolate to source structures, allows for checking it against the coordsys in the mri-structure (or the cortical (template) sheet) prior to doing the interpolation. Throwing an error at a mismatch in coordinate systems (which is probably the cause of Vitoria's and Andreas' problems) at least makes the user aware of the fact the coordinate systems should match. Note that point 2 pertains to bug 2032 as well.
Robert Oostenveld - 2017-02-08 22:41:27 +0100
related to bug #2032 I have added it to the template data for the atlasses (the ones stored in *.mat format) and to the anatomical surfaces. The inflated surfaces don't have coordsys, but should also not be interpreted geometrically. Furthermore, I have added a check for coordsys consistency in ft_sourceplot. That uses a helper function "fixcoordsys" to handle the spm/mni ambiguity. Do you know of other concrete actions that can be taken to further resolve this issue? If not, I suggest we close it.
Jan-Mathijs Schoffelen - 2017-02-09 09:18:23 +0100
Great! Indeed I think this can be closed for now. Thanks for doing my work :o)
Robert Oostenveld - 2017-06-08 08:38:13 +0200
can be closed according to the last comment.
Robert Oostenveld - 2019-08-10 12:35:14 +0200
This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on https://github.com/fieldtrip/fieldtrip/issues.