ST6RI-523 Extended coordinate transformation

[hpdekoning]

1. Created initial definitions for curved spatial coordinate frames (3D spherical, cylindrical and planetary) and associated vector quantities in addition to existing Cartesian frames and vectors. Where possible proper reference to ISO 80000 is made.

2. Implemented a consistent naming convention for specialization of vector and coordinate frame types and features in library packages Quantities.sysml, MeasurementReferences.sysml and ISQSpaceTime.sysml. The following is an example of successive levels of specialization:

   • VectorQuantityValue, ThreeVectorValue (from KerML)
     • '3dVectorQuantityValue' (alias ThreeDVectorQuantityValue)
       • Position3dVector
         • CartesianPosition3dVector
         • CylindricalPosition3dVector
         • SphericalPosition3dVector
         • PlanetaryPosition3dVector

   A similar style has been implemented for coordinate frames, as well as related attributes. The convention is to keep qualifying specializations by prefixing more narrow adjectives to the names of the attribute definitions and attributes.

3. Added a universalCartesianSpatial3dCoordinateFrame singleton (in ISQSpaceTime and in SpatialItems) to be used as a default coordinate frame, similar to the Time::universalClock singleton.

4. Added a transform calculation definition to VectorCalculations, which transforms a VectorQuantityValue from a source to a target CoordinateFrame. (Only the signature is included at this time, not a full specification of the functionality.)

5. Added the basic geometry example SimpleQuadcopter.sysml to the Geometry examples.

(Note: Description has been updated per comments below.)

[seidewitz]

Per @hpdekoning :

The quantities and measurement references generator has not yet been fully updated to automatically generate all variations of curved coordinate frames and vectors. So the current PR consists of a combination of generated and manually updated ISQ* packages. Currently only position, displacement, Cartesian velocity and Cartesian acceleration are implemented. JIRA issue https://openmbee.atlassian.net/browse/ST6RI-606 to move the ISQ/SI/USCU generator tooling to a Systems Modeling git repo has been added to the backlog.

[seidewitz]

@hpdekoning Are the updates to the ISQ packages as of the draft PR sufficient for submission, or do other changes need to be made? If the latter, can these be done manually, since the generator has not been updated?

[seidewitz]

@hpdekoning

Transformation functions to convert between different kinds of coordinate frames. Depends also on quantity arithmetic, for scalar components.

What are the minimum set of functions necessary? We can just declare their signatures at this point without the full mathematical specification.

[hpdekoning]

@hpdekoning Are the updates to the ISQ packages as of the draft PR sufficient for submission, or do other changes need to be made? If the latter, can these be done manually, since the generator has not been updated?

Yes, they are sufficient for submission. There have not been changes to ISQ, SI, etc, after this draft PR. If any, the only expected changes would be possible updates for syntax changes, but not on content.

[hpdekoning]

Transformation functions to convert between different kinds of coordinate frames. Depends also on quantity arithmetic, for scalar components. What are the minimum set of functions necessary? We can just declare their signatures at this point without the full mathematical specification.

The minimum set needs to convert any vector component (which are in effect scalar quantities) from a source to a target MeasurementReference, in practice a MeasurementUnit (if the coordinate frames have one or more different mRefs). I will provide the initial set in the PR for ST6RI-534 . However, I did not prepare signatures for the transformations between Cartesian, and curved coordinate frames. That and their implementation is a major task in itself.

[seidewitz]

The minimum set needs to convert any vector component (which are in effect scalar quantities) from a source to a target MeasurementReference...

In QuantityCalculations, we already have the following:

calc def ConvertQuantity{ in x: ScalarQuantityValue[1]; in targetMRef: ScalarMeasurementReference[1]; return : ScalarQuantityValue[1]; }

However, I did not prepare signatures for the transformations between Cartesian, and curved coordinate frames. That and their implementation is a major task in itself.

Wouldn't the following be enough to start?

calc def transform {
    in sourceVector : VectorQuantityValue {
        :>> mRef = transformation.source;
    }
    in transformation : CoordinateTransformation;
    return targetVector : VectorQuantityValue {
        :>> mRef = transformation.target;
    }
}

[seidewitz]

@hpdekoning I added transform to VectorCalculations, but I switched the order of the sourceVector and transformation input parameters. This allows for a notation like trans->transform(vec).

Please re-base your branch for ST6RI-534 on this branch.

[hpdekoning]

I added transform to VectorCalculations, but I switched the order of the sourceVector and transformation input parameters. This allows for a notation like trans->transform(vec).

Thx, that is a good generic and very usable signature. I was more worried about all the details that implementation will require. Also it does not take into account possible dependency on any clock (like in SpatialItems::PositionOf), but that only plays a role in advanced scenarios, and can be added later.

[hpdekoning]

I did the pull / rebase and have no further comments. Good to go for me.