With you approach, the only thing the object needs to know is that all the base object it operates on is in the same coordinate system. It makes no difference which coordinate system it is in, right? So why not assume it is in the global CS? If we follow the same 'tool and its bases must be in the same coordinate system'. It makes no difference right? Why will this be a 'placement mess'.ickby wrote: ↑Sun Jul 30, 2017 12:16 pm So Every GeoFeature has a unambiguous location, it exists one time at one place only. That means every document object that uses geometric input from other objects need to know this unambiguous location to calculate the correct result. And this is only possible when the calculating object lives within the same GeoFeatureGroup than the objects it uses. Only than it uses the correct location information, and only then the calculated result is correct.
Is it because if we move the base objects to another group, we'll see the tool's claimed children moved as well? Is that why you say it is wrong and must not be allowed? Well, my approach always shows the claimed the children at global CS, so it will not move. Then I guess you think my approach will be a mess because, say if I add only the fusion to some group, the fusion object's distance from its children will change, and that is wrong? But, when adding any object into a group, that object will jump as well. It is expected, right? And the distance between the fusion and its children is changeable in the first place, because it too has a placement of its own. So the user is obviously accustomed to the fact that the fusion and its children are not always at the same place.
With my approach, the workflow is much more flexible. You can follow the old way, by doing geometry modeling with objects all inside global CS, and then choose to add some final result objects (but not necessary its base objects) into whatever group, nested whatever you want. If you want to check the original relationship between the the model and its bases, just toggle its visibility in the global CS. If you work solely in some local CS, just make sure you add all objects and the tool output to that group. You don't need any special adjustment of the placement.
Is this 'instance' you are referring to somehow similar to my Link? Because, that is what Link is originally designed for. But, then I always wanted to see if it is possible to make this 'instance' behavior implicit for geo group, meaning that, any object added to it is implicitly made into an 'instance', so that it does not interfere with the real object in global CS. And that is kind of my whole idea of this post, not exactly the same, but pretty close (it has independent visibility already, but not placement, yet). And I am sure you realize that this 'instance' object must be treated specially, and be excluded from re-grouping. I am NOT sure, however, whether or not you realize that if you still insist on one object inside one group concept, than adding an 'instance' of another geo group will force you to make all of its nested children 'instance' as well. Trying to maintain synchronization is going to be a nightmare, I am afraid. Or, do you want to simply forbid instance of geo group as well? In summary, your 'local' approach put too much restrictions on the group member, which makes it not very 'nesting' friendly. But, being able to nest is a very important requirement for assembly, if not the most important.Toll and base in same Group: Yes, that will be enforced. Our solution to this is the instance object. If you want to use something in a different GeoFeatureGroup you simply make a instance of it and move that instance to the other Group. You have the object at two places, they are different. This is perfectly captured by the instance.
Well, breaking is not the right word. I should have said incompatible, because existing model may not be addable to GeoFeatureGroup. Imagine how I would feel, if after all that hard work, and my own gigantic models can't be used in the new assembly WB?Breaking Models: Definitely not. GeoFeatureGroup or the whole concept has not been available before, we do not break anything. Not all constructions may be splittable into different GeoFeatureGroups, but that is a minor Issue in my opinion. All old workflows are still supportet, Everything can live in the global CS as they do now, just don't put it in a GeoFeatureGroup.