split between ridge and transform segments doesn’t always work
Closed this issue · 5 comments
This problem was reported by Nicky at #183 (comment)
It seems that the problem is the "ridges" have not been identified properly. See the screenshots below.
Hi @jcannon-gplates,
You are more familiar with the topology stuff. Any idea why the line is half-red and half-grey at 52Ma. How do we decide if a boundary section a ridge or other things?
The following comments by Nicky at #183 (comment) may also be related to this problem. But I am not entirely sure since I am lack of background info or necessary knowledge to understand.
@nickywright could you please confirm if the following comments are also about "the ridges have not been identified properly"? Thanks.
In 2016 I tested a lot of values for the ‘deviation angle’ that I think this code is based on (if it’s the same as Simon’s code?
Yes it's based an a deviation angle - the code wasn't based directly on Simon's code but it probably follows the same principle.
It looks like GPlately is currently using the default angle of 45 degrees. But, as you noted, I'd imagine it'd be hard to find a deviation angle that works well for all MOR features in a model.
but the code to split between ridge and transform segments for some reason thinks half of this boundary is a ridge (it shouldn’t be though) – and this segment is fine at 59 Ma so it might be ‘flipping’ between a transform and a ridge segment in an animation?
I think it's because the stage pole (calculated from left/right plate IDs) is hovering around the deviation angle. You can see the delta velocity (visually subtract arrow on one side from arrow on the other) is starting to align with the line direction (so it's behaving more like a transform than a MOR). For comparison, the MOR line next to it (south of the Kula plate) has nicely separated ridge/transform segments because its delta velocity is actually nicely perpendicular/parallel to its ridge/transform segments. I don't think there's a deviation angle that could satisfy both these MOR lines since they are actually perpendicular to each other (but still share the same left/right plate IDs and hence have the same stage pole that deviations are based on).
A possible solution is to just give that feature a type other than gpml:MidOceanRidge (such as gpml:Transform) since only features of type MOR will get split into ridge/transform segments. I think you alluded to this when you mentioned the "Pacific-Kula transform" (as opposed to "Pacific-Kula MOR"). Then the entire line would be grey (which I assume is desired for a transform feature).
By the way, the ridge/transform separation code can breakdown when the stage pole location is near a segment (arc) of the line - because the deviation can easily flip for example. But I don't imagine that happens very often (and is probably quite localised within a particular line (eg, localised to a specific segment of the line).
Sabin responded...
Yes, I had a close look too – both of those issues can be fixed in the plate model actually. I hadn’t realised we made that transform as a MOR feature all those years back, but that is an easy fix. Philippine MOR can also be fixed, so this issue can probably be closed.
...to my email saying...
In summary I think the MOR in the screenshot can be labelled a transform (instead of MOR).
Then it’d always be grey. It actually behaves more like a transform anyway (since convergence velocity is aligned with the line) whereas the MOR next to it (south of Kula plate) has same convergence (well, same stage pole from same left/right plates) but is oriented much more appropriately for MOR spreading.
So feel free to close this issue (or leave as wontfix).
I will close this issue in 7 days. Leave time for customers to response
See comments above.