Civil engineering feature implementation (Transportation Engineering)

[HakanSeven12]

So I'm thinking we need to save GeoOrigin to *.fcstd file.

[Joel_graff]

The FPO should serialize without issue. Just need to make sure that only one exists and when it reconstructs from a load, it re-inserts the SoGeoOrigin.

You might want properties in the FPO that allow the user to change the coordinate system type, as well as remember the SoGeoOrigin location... but those values should serialize automatically, if I recall correctly.

The only problem is making sure that, when you load a document, there isn't already an SoGeoOrigin in the scenegraph, because the FPO will try to recreate it when it's deserialized.

Maybe we create the separator / geo origin when the workbench initializes, and just have the FPO take control of it when it's created. That would prevent loading a new document and accidentally adding a second SoGeoOrigin.

[Joel_graff]

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...

Variables

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.

Key Questions

1. When do we insert the SoGeoOrigin into the scenegraph?
2. How do we handle an existing SoGeoOrigin?

Possible Approaches

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.

Proposal

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.

[HakanSeven12]

I think that covers everything. For now.

Yes

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.

For rendering quality we always need to change SoGeoOrigin coords variable to move it to 3d view area. Maybe we can add a refresh button to toolbar for this. It can detect center coordinate of view area and add it to SoGeoOrigin coords variable and zoom to origin. For other wbs I dont think that cause an issue. We can change coords variable freely. So if there is a SoGeoOrigin we can use it. If not we can create a new one. The real problem for me how we handle non-geo objects from other workbenches? Because our objects positions will change(Im talking about 3d view real origin) to protect rendering quality but other objects stay where they are. So I think we also need to add a SoGeoLocation node in our FPO to move this object too.

I agree with you for other stuff.

[Joel_graff]

For rendering quality we always need to change SoGeoOrigin coords variable to move it to 3d view area

Right. and maybe a recenter / refresh function as you suggest is the easiest way to manage that. It's not really necessary unless the geometry starts distorting, I suppose.

So if there is a SoGeoOrigin we can use it. If not we can create a new one.

The issue I had with that in testing was that even if the SoGeoOrigin preceded the SoGeoCoordinate in the stack, it wouldn't always pick up. I did get consistent performance after putting the SoGeoOrigin (and GeoCoordaintes) under a separator, however - so that makes me reluctant to just use something that's already existing.

As an edge case, suppose an SoGeoOrigin node exists under a separator a previous workbench has used? That would make it unavailable to us unless we used that same separator (which we shouldn't do). Unless SoGeoOrigin node is not subject to the effects of a separator?

Still, this isn't exactly a big deal. We're the only ones who care right now, anyway.

The real problem for me how we handle non-geo objects from other workbenches? Because our objects positions will change(Im talking about 3d view real origin) to protect rendering quality but other objects stay where they are. So I think we also need to add a SoGeoLocation node in our FPO to move this object too.

I'm afraid I've lost you, here... If we shift the SoGeoOrigin position to protect the rendering quality, that shouldn't have any effect on non-geo objects...

Unless you're talking about positioning a non-geo object somewhere within the SoGeo* node graph? Like, for example, a model of a car on a roadway 15 km from the origin?

If that's the case, I think you only need to add the non-geo object as a child of an SoGeoSeparator node and set the separator's position. The non-geo object becomes a geo object by proxy, so to speak...

Honestly, I don't claim to know. I looked at SoGeoLocation, but it wasn't obvious to me why I'd use that over an SoGeoSeparator...

[HakanSeven12]

If we shift the SoGeoOrigin position to protect the rendering quality, that shouldn't have any effect on non-geo objects...

For example if I create a surface by using sogeo nodes and I create a cube at the spesific position on surface by using part workbench. If this cube represent a building on surface we need to move it with surface. When we changed the sogeoorigin it effect surface and dont effect cube. So I think we can use geolocation to effect non-geo object.

[Joel_graff]

For example if I create a surface by using sogeo nodes and I create a cube at the spesific position on surface by using part workbench. If this cube represent a building on surface we need to move it with surface. When we changed the sogeoorigin it effect surface and dont effect cube. So I think we can use geolocation to effect non-geo object.

Right. I think you can accomplish the same thing by creating an SoGeoSeparator at the desired position, and adding the non-geo objects to it - the SoGeoSeparator's position is applied to all non-geo child coordinate nodes.

That's why I couldn't figure out the point of using SoGeoLocation... Maybe just as a way to not require a Separator node...?

EDIT:

I took a second look - the SoGeoLocation inherits the SoTransform node - so it's just a transformation node. You could use that inside a standard SoGroup / SoSeparator... or use SoGeoSeparator instead.

[Joel_graff]

So I'm going to prototype a FeaturePython object that acts as a Singleton (only one instance of it can exist at any time), It will manage the SoGeo graph structure from the start.

For the time being, I plan on having it do the following things:

1. Check for an existing SoGeoOrigin. If it exists, notify the user to close an existing document and / or restart FreeCAD. Until use cases arise where this posses a problem, I think it'll be useful to catch when the FPO itself may be misbehaving...

2. Generate the initial SoGeo* node structure. *Everything* that is created in a Trails document will go under this structure. Right now, that's just an SoSeparator node with the SoGeoOrigin as it's first child. I could create additional child separators for different parts of Trails - maybe a Geomatics separator and a Horizontal Alignment separator, for example).

3. Destroy the node graphs, either by calling a single function, or when the FPO itself is destroyed.

[HakanSeven12]

Can you do something for pivy tracker first? There is still bugs. I don't have time nowadays. I will return to work on wb after a week or two.

[Joel_graff]

Can you do something for pivy tracker first? There is still bugs. I don't have time nowadays. I will return to work on wb after a week or two.

I've no doubt there are... but what ones are you talking about? Is it still throwing errors when the workbench activates?