Data epoch change

[jetgeo]

Suggested new model (see also https://github.com/ISO-TC211/ISO19111/tree/master/Figures/Main%20version):

[RogerLott]

At the meeting the class name "DataEpochChange" was proposed, but there was one significant objection to this. The objection is that DataEpochChange is not really what is going on. There is a change of coordinates caused by tectonic motion over the period between sourceCoordinateEpoch and targetCoordinateEpoch. To avoid the objection a better name for the class might be "CoordinateChangeByPointMotion" or perhaps because shorter just "PointMotion". (All of the other subtypes of coordinate operations are coordinate change caused by having different source and target CRS, and these omit the preface 'CoordinateChangeBy[Transformation/ConcatenatedOperation/...]).

This class is to be used by the DataEpoch class. So is replacing the current direct associations named Source and Target between CoordinateOperation and and DataEpoch with associations from the new class to DataEpoch appropriate?

And to make it more obvious that this clas is an alternative to Conversion and Transformation, in the diagram could Conversion be on the same level (and to accomodate this DerivedCRS moved below), please.

[marqh]

I am in favour of PointMotion instead of DataEpochChange

for the constraint on this class targetCRS=sourceCRS reads a little better (just reordered, the semantics are the same)

[jetgeo]

See bellow. @RogerLott :Regarding the Source and Target association - you said "replace". Shall this class be the only one with associations to DataEpoch?

[desruisseaux]

It seems to me that ConcatenatedOperation and PassThroughOperation also need the association to DataEpoch.

[RogerLott]

@jetgeo asked

Shall this class be the only one with associations to DataEpoch? The only one of the 19111 classes (but DataEpoch is also associated to Geometry).

We have two concepts to deal with: i) coordinates can be changed because they can be put through a coordinate operation can be applied to them so that they become referenced to a different CRS. The coordinate operation can be any of Conversion, Transformation, concatenatedOperation or passThroughoperation. If Conversion or Transformation the attributes in the part2 coordinate operation disgram may be needed. All this is unchanged.

ii) Coordinates may change because of point motion [caused by tectonic plate motion or other deformation mechanism]. In this, there is no change of CRS; the point has moved within the CRS. We are adding the PointMotion class to facilitate this. Like Conversion and Transformation, PointMotion needs additional information (method and parameters) so needs to be able to be associated with the OperationMethod and GeneralParameterValue classes shown in the part 2 diagram, either directly itself or indirectly by being subtyped off SingleOperation. We have assumed the latter but this may not be appropriate.

iii) A ConcatenatedOperation may include PointMotion(s) as well as Conversion(s) and/or Transformation(s). This is perhaps also true of a PassThoughOperation.

Now let us consider the relationships shown in 19111 figure 8 between CoordinateOperation and CRS and between CoordinateOperation and DataEpoch. Of the various subtypes of CoordinateOperation we currently have, then (from (i) above) the association between CoordinateOperation and CRS may use any one of Conversion, Transformation, concatenatedOperation or passThroughoperation. From (ii) above the association between CoordinateOperation and DataEpoch may use PointMotion. Do we need to show this distinction?

[desruisseaux]

Just to check if I'm understanding right, is the following summary correct?

• Conversion, Transformation and PointMotion need parameters. They inherit them from SingleOperation. Since other kinds of operation (ConcatenatedOperation and PassThroughOperation) do not need parameters (as far as I can see), we do not need to move parameters higher in the hierarchy.
• Conversion and Transformation have distinct sourceCRS and targetCRS attribute values (ignoring for this discussion the fact that those associations are optional for conversions), but same sourceEpoch and targetEpoch attribute value (if any).
• PointMotion has same sourceCRS and targetCRS attribute value, but distinct sourceEpoch and targetEpoch attribute values.
• Because ConcatenatedOperation may contain any mix of Conversion, Transformation and PointMotion, it needs sourceCRS, targetCRS, sourceEpoch and targetEpoch attributes. All of them may be distinct.
• Because PassThroughOperation may contain a ConcatenatedOperation, above remark about concatenated operation applies also to pass through operation.

Consequently it seems to me that sourceEpoch and targetEpoch should be in the CoordinateOperation class, together with sourceCRS and targetCRS?

[RogerLott]

Your first three bullets are correct but not quite complete - in addition to parameters they need the method [formula]. This all comes from the classes in the Operations part2 diagram, associated with SingleOperation.

Your last two bullets are correct. The arguments for ConcatenatedOperation is a list of singleOperations. The method and parameters for these are embedded in each SingleOperation. Similar for PassThroughOperation.

I do not think this leads to sourceCRS etc being "in the CoordinateOperation class" (which I infer to mean as attributes of the class). Is not association fine?

What you are perhaps checking is my suggestion that DataEpoch should be associated with PointMotion. If you amalgamate the OperationswithDataEpoch diagram (fig 8 in 19111) with the Operations part 1 diagram above we need to bring in the DataEpoch class and its two associations from CoordinateOperation.

This I read to say that all subtypes of CoordinateOperation are associated to both DataEpoch and CRS. Is this so? True for ConcatenatedOperation. But for the subtypes of SingleOperation, are not Conversion and Transformation associated only with CRS and PointMotion only with DataEpoch? Do we need to show that, and if so how?

[desruisseaux]

Indeed sourceCRS and targetCRS are associations; my use of "attribute" word was a mistake (attribute and association are indistinguishable in Java language, so I sometime forget to make the distinction when talking about UML).

You are right, I was trying to figure out where DataEpoch associations appear. I also see them as optional associations from CoordinateOperation. The PointMotion class could make those associations mandatory in the same way than Transformation makes the sourceCRS and targetCRS associations mandatory. Conversely, Conversion and Transformation could set the cardinality of DataEpoch associations to 0 in the same way than Conversion set the cardinality of operationVersion to 0.

[jetgeo]

Updated diagram, after discussion with @RogerLott.

• [X] Changed constraints on PointMotion, Conversion and Transformation, to specify how CRS and DataEpoch are used in these.
• [X] Removed constraints from PassTroughOperation and ConcatenatedOperation, since they can relate to any of the three single operation types.

Please comment if I have misunderstood.

[RogerLott]

@jetgeo the constraints on PointMotion and Transformation look fine. But I think that the constraints on Conversion are not correct. The sourceCRS and targetCRS may be implicit when the conversion defines a derivedCRS. The constraints count(SourceCRS)=1 and count(TargetCRS=1) should be removed so that the class can inherit the 0..1 cardinallity through CoordinateOperation. The constraints for SourceEpoch and TargetEpoch should be retained.

[jetgeo]

OK, done.

[RogerLott]

Sorry, we still do not have this correct. In PointMotion the counts for sourceEpoch and targetEpoch should be retained, but we need to delete the constraints of count(sourceCRS) and count(targetCRS) and reinstate the constraint (targetCRS=sourceCRS).

Why does the diagram show the coordOperationTo/From 0..* attributes on the CoordinateOperation to DataEpoch associations? There are similar attributes on the CoordinateOperation to CRS associations but these are not shown. Whether or not these attributes are shown, there needs to be consistency.

[RogerLott]

Is it sensible for the two pairs of associations between CoordinateOperation and CRS / DataEpoch to both be called 'Source' and 'Target'? To differentiate between them more easily whilst retaining backward compatibility for the CoordinateOperation to CRS associations, I suggest changing those between CoordinateOperation and DataEpoch to be SourceEpoch and TargetEpoch.

[jetgeo]

OK, done (see new figures in https://github.com/ISO-TC211/ISO19111/tree/master/Figures). This is no problem though, since it is the role name, not the name of the association that shall be unique.

[RogerLott]

A minor question. Can we change the name of the PointMotion class to PointMotionOperation, please? It would make it easier to refer to in text. Currently as subtypes of single operation we have a conversion (noun), a transformation (noun), and a point motion (verb). Better as a conversion (noun), a transformation (noun), and a point motion operation (noun). Also in its constraints, change (sourceCRS = targetCRS) to (targetCRS = sourceCRS) as it once was. Akthough making absolutely no difference to the model it is more logical in implementation - you start with the source CRS and must end with it too.

[desruisseaux]

This is fine for me. Just out of curiosity, of course you know much better than me, but I though that in this context motion was a noun?

[jetgeo]

OK, done. New figure: https://github.com/ISO-TC211/ISO19111/blob/master/Figures/Operations%20Part%201.png