Include new deck definition

[ChristianHesse]

A replacement definition for the aircraft cabin or deck is proposed according to the attached mindmap. The new definition includes changes to make it consistent to the definition of the primary structure by referencing the fuselage cutouts. In addition, a basic description for the secondary structures (lining, hatracks and ceiling panels) in the form of the bounding box as well as a reference to a genericGeometryComponent is included.
The major changes and the rationale behind the new definition are discussed in detail in https://elib.dlr.de/135956/.

Edit: The uploaded mindmap has been changed to include the suggestion below by @jnwalther.

DeckDefinition_InDiCaD_v1.zip

[jnwalther]

We have discovered some abiguity in the description of the bounding boxes, as fallback if no geometry components are provided. It needs to be clarified which point within the box is used as reference for subsequent positioning. Therefore we propose to add an optional local reference coordinate in [0, 1] space, which defaults to 0.5 (COG of the box). To clarify affiliation, length/width/height of the box should also be renamed to dX/dY/dZ. This results in a structure like this:

<boundingBox>
  <dX>1.0</dX>
  <dY>2.0</dY>
  <dZ>3.0</dZ>
  <boundingBoxOrigin>
    <referenceXLocal>0.5</referenceXLocal>
    <referenceYLocal>0.5</referenceYLocal>
    <referenceZLocal>0.0</referenceZLocal>
  </boundingBoxOrigin>
</boundingBox> 

@ChristianHesse: I suggest we add this in an updated version of the above document.

[ChristianHesse]

Please find attached a schema definition (*.xsd) proposal for the revised deck definition.
newDeckSchema.zip

@marcengelmann & @MarAlder: We´re very happy about feedback and thoughts from your end.

[MarAlder]

First impression: very nice!! It follows well our concept of pre-defining library elements and linking it in the actual aircraft instance. It follows all naming conventions. I will give you more detailed feedback soon and then initiate step 2 of our development process, i.e. informing the entire community and getting feedback from stakeholders. But as the proposal already looks quite advanced I also already scheduled it for CPACS 3.4.

[marcengelmann]

I really like the new structure of the deck definition. As a regular user of the current style I think this will be a big step forward.
The challenge here is to satisfy both a top down perspective where the mechanical structure of the fuselage an cabin can be neglected (e.g. when using it for boarding simulations) as well as a detailed structural perspective.

From what I can tell now, this looks promising for both use cases.

I will definitely look into it in more detail in the coming days and give you proper feedback. But thank you already for the efforts you put into this @ChristianHesse and @jnwalther.

[marcengelmann]

After having attended the meeting there are a few things I discovered which I wanted to discuss:

• Galley/Lavatory Split
  We at Bauhaus Luftfahrt look at unconventional cabin layouts that can include a bar, beds, staircases, tables etc. Currently we include these with a custom literal at the floorElement type. With the new split, there is unfortunately no generic new element type possible.

• cabGeometry layers
  Just for clarification, in your presentation there were y-z shapes stacked along the x axis which is a change to the current implementation.

• Rotation of cabin elements
  You mentioned a translation option for cabin elements, but does this also include rotation of objects? E.g. if I wanted to create a seat group located around a table or a rotation of seats towards the aisle.

Thanks again for the very interesting stakeholder meeting!

[jnwalther]

Thanks @marcengelmann for your comments! I will go through them one by one:

• Galley/Lavatory Split
  After discussing with @ChristianHesse we have decided to re-introduce some kind of generic deck geometry type, which would be a bare-bones version of the deckElement types introduced during the stakeholder meeting (i.e. no metadata like numberOfSeats/numberOfTrolleys/... will be allowed).

• cabGeometry layers
  Sorry, I guess our slides were less than perfectly clear on this. Our implementation does in fact retain the definition as it was previously. The z entry in each contour node is a single value that corresponds to an entry in the old vector z. The y entry is a vector that corresponds to the respective yZi. The x entry is also a vector of the same length as all vectors y and constitutes the sample points for all contour entries, which is why it is located outside the contour list. I hope this makes more sense, somehow.

• Rotation of cabin elements
  All cabin objects have a transformation node, which comprises translation, rotation and scaling. For floor-based elements, this is a 2D transformation (translate on xy-plane, rotate around z-axis), which should serve your purpose just fine.

Does this answer your questions?