GBXML Import reverses floors/ceilings normals and surface types

[macumber]

Moved from openstudiocoalition/OpenStudioApplication#395

Enhancement Request

Currently, when importing a gbxml file from Revit, some of the surface normals get reversed as well as the surface types. It is very laborious going through and fixing the normals and surface types by hand.

It would be good to have OpenStudio check for and correct this error during the import or have a measure that corrects it after import.

Detailed Description

This has been reported before and is described in detail here: https://unmethours.com/question/24512/os-imports-gbxml-with-reversed-floor-construction/

[macumber]

Seems related to #93 and #2992

[ggartside]

I finally managed to get a good repro on this one

@macumber @DavidGoldwasser
If we can't rely on the surface orientation in the file to determine whether the surface is a floor or a ceiling for each space what can we do?

How about looking at the spaces, determine which space is above the other (from the location) and that will determine whether the surface is a floor or a ceiling

I though about using bounding box but if the space shape is very irregular then it is entirely possible for a ceiling to be closer to the minimum z than the maximum z)

Any other ideas?

[macumber]

I pushed to get the detail about the second surface vertices being flipped in the adjacent space added to the gbXML specification but I don't think it ever got added. If it's not added to the gbXML specification maybe you could at least get Revit to standardize their export. I never really liked the heuristic approach since there is a pretty sensible convention that could be used.

[ggartside]

Unfortunately I don't have any say in what Revit does or does not do, all we can do is figure out how to live with it

"It would be good to have OpenStudio check for and correct this error during the import or have a measure that corrects it after import" - " I never really liked the heuristic approach since there is a pretty sensible convention that could be used." - did you change your mind about this enhancement request?

[macumber]

My thought was a multi-pronged strategy. Best approach (but takes longest amount of time) is to modify gbXML specification. Second best (but next hardest) is to work with Revit team to implement a convention. Worst solution (but only one in OS's control) is implement the heuristic.

I'd recommend NREL use it's contacts at gbXML and Revit to push for the best two long term approaches but implement a temporary heuristic in the meantime.

[ggartside]

I think a potential heuristic could be treating the surfaces of the space as a brep. We know in this case that each edge is shared between two faces and that the orientation of the edge is reversed for one of the faces if both faces have the correct orientation.

So if we can start with a face that we know has the correct orientation we can find the shared edges and check the direction of the edge, if the directions are the same then the orientation of the second face is incorrect and the face can be reversed

We need to have a starting face whose orientation is correct - I think we could look for a horizontal surface that has a z value equal to the maximum or minimum z value of the space's bounding box, for this surface we can easily determine that its normal should be 0,0,1 or 0,0,-1, correct if necessary and use as a starting surface.

If we cant do this then we would have to make sure all the faces wee consistent with each other and then generate a point we know should be inside the brep and sum up the solid angles subtended by each surface.

(Another thought did occur, if we can find a point we know is inside the brep then the sign of the solid angle will tell us whether the surface normal points away from the point (+ve)_ or towards it (-ve) so if the solid angle is -ve then the surface is incorrectly oriented. This might be easier to implement than the first idea)