HakanSeven12 wrote: ↑
Thu Jun 04, 2020 7:13 pm
So I'm thinking we need to save GeoOrigin to *.fcstd file.
So I've been thinking more on this, trying to consider the possible cases that adding out-of-tree support for SoGeo nodes requires. It's a bit lengthy, but
I'm trying to think through a robust solution that won't require major code rewrites in the future...
1. Are we loading an existing geo-referenced document, or opening a new, empty document?
2. Is the Trails WB active or inactive?
3. Has there been previous geo-referencing activity, whether in Trails or somewhere else?
Different combinations of the above items creates different challenges.
1. When do we insert the SoGeoOrigin into the scenegraph?
2. How do we handle an existing SoGeoOrigin?
1. Insert the SoGeoOrigin on workbench activation or force the user to create a special Trails-specific "new document" function that triggers it. The latter approach means the user can't just create a new, empty document and start working in that - which I don't really like. Which leaves the former approach.
2. Serialize the SoGeoOrigin management using a FPO as you've suggested. Of course, what's serialized is the FPO properties, but this would be a single point to manage SoGeoOrigin insertion code. This also addresses variable #1 and #2 above, as the management code will be added to a new document when the workbench is activated, and will execute automatically when an existing Trails document is loaded, whether or not the workbench is active.
3. This leaves variable #3 / question #2. How do we address a scenegraph with an existing SoGeoOrigin? How can we know it was created by Trails?
If the user opens two existing Trails documents / imports data using the Trails WB into a new document, we can add a separator for each document to prevent "bleeding" between the document-specific nodes.
If the user uses another WB that also creates an SoGeoOrigin, we have an issue. We can't account for their use of the SoGeoOrigin node, so I would have to argue that work done in another geo-referencing WB would be exclusive to Trails. Which means we'd have to generate an error and tell the user to restart FreeCAD. Or give the user the option to "clean" the tree by simply deleting the existing SoGeoOrigin.
1. Create a FPO which handles all SoGeoOrigin activity. It creates an SoSeparator / SoGeoOrigin structure, and adds a document-specfic SoSeparator child node to the group for every new document that Trails imports data into, or existing Trails document that's loaded.
2. Generate an error if, when the FPO is created, an existing SoGeoOrigin is discovered. Give the user the option to delete the existing SoGeoOrigin from the scenegraph or recommend they save their open documents and restart FreeCAD before continuing.
3. Make sure the FPO is a singleton. That way, if other Trails documents are opened simultaneously, another, competing SoGeoOrigin FPO isn't also created.
4. Make sure the FPO and geo-referencing node graphs are destroyed when all Trails-specific documents are closed.
I think that covers everything. For now.