Operations on CoordinateOperation

[jetgeo]

2 Operations on CoordinateOperation: transform(position:DirectPosition )-->(position:DirectPosition ), transform(CoordinateSet )-->(CoordinateSet )

[jetgeo]

OK, done. TBD.

[RogerLott]

These transformations are necessary in the CoordinateOperation class. And it is necessary for them to appear in the CoordinateOperations_with_Data_Epoch diagram. But do they need to appear in the OperationsPart1 diagram? That package is describing the requirements for defining the attributes of a coordinate operation. These transforms are not relevant for that. I suggest reverting to the previous version for the operations_Part1 diagram - i.e. just show the two attributes (operationVersion and coordinateOperationAccuracy) and the constraint. It will not be the end of the world if they are left in the Operations_Part1 diagram - it will at least mean that the whole class is shown in one of the diagrams.

[jetgeo]

I think all attributes and operations for the clas should be shown in at least one diagram. This would then be either "Operations Part 1" oe "CoordinateOperations with Data Epoch".

[jetgeo]

Hide the constraint in Data epoch diagram

[jetgeo]

This cannot be done, given that we are adding other constraints that are relevant for the diagram (Ref https://github.com/ISO-TC211/ISO19111/issues/16). You can't hide one constraint, unfortunately.

[RogerLott]

Understand, but can we get around this another way? Move the constraint re mandatory source/target CRS from the CoordinateOperation class to each of the PassThroughOperation, ConcatenatedOperation and Transformation classes?? Then it cannot appear in the coordinate metadata diagrams.

[jetgeo]

Yes, that will work. Even though it might not be best practice to repeat the constraint in three subclasses as long as there are no subclass without the constraints. But let's do that. With this solution, I think we should also hide the operation (transform()) in the Operations Part 1 diagram. It makes no sense without the constraints and the CoordinateSet data type. I think we can manage without showing all attributes and operations in one of the diagrams. Instead, I will create context diagrams for each class, for use in the model, not in the document. These diagrams will show all attributes, associations, operations and constraints for each class.

[RogerLott]

not be best practice to repeat the constraint in three subclasses as long as there are no subclass without the constraints The Conversion class is subtyped off CoordinateOperation and will not have this constraint.

I will create context diagrams for each class, for use in the model, not in the document. These diagrams will show all attributes, associations, operations and constraints for each class. Fine, that will make the diagrams in the document better fitted to the text. But the tables in the document will need to include all attributes, associations, operations and constraints, i.e. be consistent with the context diagrams.

[jetgeo]

Ok, done.

Descriptions of the constraints, extracted from the old common constraint:

• PassThroughOperation - {count(sourceCRS)=1 and count(targetCRS)=1} - Description: The "sourceCRS" and "targetCRS" associations are mandatory for coordinate transformations only.
• SingleOperation - {not oclAsType(Conversion) implies (count(sourceCRS)=1 and count(targetCRS)=1)} - Description: The "sourceCRS" and "targetCRS" associations are mandatory for coordinate transformations only. Coordinate conversions have a source CRS and a target CRS that are NOT specified through these associations, but through associations from GeneralDerivedCRS to SingleCRS.
• ConcatenatedOperation - {count(sourceCRS)=1 and count(targetCRS)=1} - Description: The "sourceCRS" and "targetCRS" associations are mandatory for coordinate transformations only. For a concatenated coordinate operation sequence of n coordinate operations: source CRS (concatenated coordinate operation) = source CRS (coordinate operation step 1) target CRS (coordinate operation step i) = source CRS (coordinate operation step i+1); i = 1 ...(n-1) target CRS (concatenated coordinate operation) = target CRS (coordinate operation step n) Instead of a forward coordinate operation, an inverse coordinate operation may be used for one or more of the coordinate operation steps mentioned above, if the inverse coordinate operation is uniquely defined by the forward coordinate operation method.

Are these descriptions OK?

[RogerLott]

Descriptions are not correct.

PassThroughOperation - {count(sourceCRS)=1 and count(targetCRS)=1} - Description: A pass-through coordinate operation specifies that a subset of a coordinate tuple is subject to a specific coordinate operation. The "sourceCRS" and "targetCRS" associations are mandatory.

ConcatenatedOperation - {count(sourceCRS)=1 and count(targetCRS)=1} - Description: An ordered sequence of two or more single coordinate operations. The "sourceCRS" and "targetCRS" associations are mandatory.
For a concatenated coordinate operation sequence of n coordinate operations: source CRS (concatenated coordinate operation) = source CRS (coordinate operation step 1) target CRS (coordinate operation step i) = source CRS (coordinate operation step i+1); i = 1 ...(n-1) target CRS (concatenated coordinate operation) = target CRS (coordinate operation step n) Instead of a forward coordinate operation, an inverse coordinate operation may be used for one or more of the coordinate operation steps mentioned above, if the inverse coordinate operation is uniquely defined by the forward coordinate operation method.

(Note: You had previously suggested taking the ordering note off the association, which is not problem. I had assumed it was just going into the normative text. So it has surprised me to see it in the concatenated operation description. But I have no problem with it being there).

I was not expecting any constraint on SingleOperation or on Conversion (leaving Conversion to inherit optionallity from the CoordinateOperation-CRS associations), then expecting a constraint on Transformation. But I don't understand the modelling issues involved so if my naive expectation was wrong then that is fine. But if the constraint is on Transformation then:

i) Singleoperation. No constraint, - Description: A single (not concatenated) coordinate operation. ii) Transformation: count(sourceCRS)=1 and count(targetCRS)=1} - Description: A coordinate operation in which parameters are empirically derived from data containing the coordinates of a series of points in both coordinate reference systems. This computational process is usually “over-determined”, allowing derivation of error (or accuracy) estimates for the coordinate transformation. Also, the stochastic nature of the parameters may result in multiple (different) versions of the same coordinate transformations between the same source and target CRSs. Any single coordinate operation in which the input and output coordinates are referenced to different datums (reference frames) will be a coordinate transformation. The "sourceCRS" and "targetCRS" associations are mandatory. iii) Conversion. No constraint. - Description: A coordinate operation in which the parameter values are defined rather than empirically derived; application of the coordinate conversion introduces no error into output coordinates. The best-known example of a coordinate conversion is a map projection. For coordinate conversions the output coordinates are referenced to the same datum as are the input coordinates. For coordinate conversions the source CRS and a target CRS may specified through associations from DerivedCRS to SingleCRS. (Note - DerivedCRS, not GeneralDerivedCRS)

[jetgeo]

You're right, the constraint should of course be on Transformation, not on SingleOperation. Didn't see that, sorry! The definitions I referred to were based on the note in the old Operations Part 1 diagram (in the 2007-version). I think it is good to have this text implemented in the class definitions, as you have described. I have removed the descriptive text from the constraints, they are just pure OCL now. And I have added your definitions to these classes. New diagram bellow. Guess we can close this now.