Yes, when overlaps are involved there are more ways to confound the hierarchy than I really appreciated (or needed to consider) at the time I first wrote it. Sometimes the order in which the annotations are created can matter, which doesn’t exactly feel right.
On the other hand, it is really helpful for the data model to be able to represent tissue in a hierarchical way… so dropping the concept entirely would potentially lose a lot of good stuff.
I’ve written a bit about the topic, e.g.
In the longer term I can think of a couple of ways to go:
- Forbid annotation overlaps
- Move to a more layer-based approach
I tend towards the second option, but it’s a rather drastic solution that can’t be done quickly.
In the meantime, I think it’s best to see the hierarchy as a useful way to represent your objects if you want to use it… but taking full control really means scripting to construct it in exactly the way that fits your needs, because leaving it up to the automatic resolution isn’t robust enough in many cases.
But also, for most applications the hierarchy is never really more than 2 levels deep and can often be ignored. The changes in v0.2.0 to be able to count objects based on spatial location rather than strictly where they hierarchy makes the whole concept much less important than it was in v0.1.2 in these cases.