Deformation model link to CRS

[RogerLott]

The 19111 EC needs some advice on modelling of the relationship between a dynamic CRS and zero to many 'deformation grids' which associated with but not part of the CRS definition. The datamodel should allow for these grids to be easily identified from the CRS. The deformation grids are modelled as PointMotionOperations. In geodesy this is somewhat analogous to the relationship between a geoid-based vertical CRS and a geoid model, which we have modelled as a HeightTransformation association from Transformation to VerticalCRS. This led to a proposal that a similar association (perhaps called "Deformation") from PointMotionOperation to SingleCRS should be added to the model (to SingleCRS because it needs to cover both Geodetic CRS and Vertical CRS - however it is very unlikely to be relevant to other subtypes of SingleCRS, so two associations one from PointMotionOperation to GeodeticCRS and the second from PointMotionOperation to VerticalCRS would suffice).

However the analogy with Height Transformation is not exact because in some cases the deformation grid may be superseded by or augmented with a later grid. This led to an alternative suggestion for the data model, instead of adding the Deformation association, to add an appropriate function to the OperationsFactory class.

I took away an action to solicit Jetgeo's opinion on this.

So grateful if Jetgeo would: a) offer his opinion on the two options b) if the recommendation is to add the OperationsFactory function, comment on whether it would be inconsistent to have this and the HeightTransformation function.

[desruisseaux]

I think that using functions has the advantage of keeping associations only for the parts of CRS definitions. Do the following functions in OperationFactory (to be renamed) catch the intend?

• findCoordinateOperation(CRS, CRS) : Set<CoordinateOperation> (already existing function).
• getHeightTransformation(VerticalCRS) : Set<Transformation>
• getDeformation(GeodeticCRS) : Set<PointMotionOperation>
• isSameEnsemble(CRS, CRS) : boolean (mentioned during the teleconference call)

In addition, should we put an association from OperationFactory to CI_Citation named "authority"? The reason is that the result of findCoordinateOperation(CRS, CRS) may depend on the geodetic registry used. For example when asking the transformations from OSGB 1936 to ED50, if OperationFactory performs its search using the EPSG geodetic database, then the Transformation set will include EPSG::1315 - a transformation defined for oil exploration - while another geodetic registry may not include that transformation, or include other transformations.

[RogerLott]

Take at look at two examples in EPSG:

1. Height Transformation association. CRS code 6647 (CGVD2013 height) and coordinate operation code 6648 (NAD83(CSRS) to CGVD2013 height (1), geoid model CGG2013). In this case there are cross-referencing remarks in both entries saying that 6648 was used to define 6647. Machines do not read remarks.
2. CRS code 8251 (NAD83(CSRS)v6) and coordinate operation code 7957 (Canada velocity grid v6) (currently a transformation, but to be changed to a point motion operation when data model updated). CRS 8251 is dynamic and the 'dynamism' is described through coordinate operation 7957.

It is desirable that CRS 6647 'knows' that it is defined by transformation 6648, and that CRS 8251 'knows' that the appropriate point motion operation is 7957.

If the EPSG Access db CRS table were updated with an attribute (height transformation, deformation model respectively) then these linkages would be direct. This is the equivalent to having associations in the UML model.

This can be done in these two examples because the are 1:1. I don't have any current use cases that are 1 to many, but I suspect they may come in the feature. Then functions as described by Martin would be useful.

So do we need both associations and functions? Or is that poor (duplicate) modelling?

[desruisseaux]

I think we don't need to duplicate. I do not have a strong opinion on whether they should be associations or functions. It is okay to have an 1:1 association in one direction and 1 to many in the opposite direction. The only cases where we can not use associations is for functions taking two or more arguments, like findCoordinateOperation(CRS, CRS).

In the CGVD2013 height case, isn't similar to a DerivedCRS where the coordinate operation would have been allowed to be a transformation instead than a conversion, and where the datum and CRS type are different than the base CRS ones? I don't said that we should use DerivedCRS for cases like CGVD2013, but I wonder if some kind of convergence is possible. E.g. another GeneralDerivedCRS sub-type? (may require relaxing some rules in GeneralDerivedCRS, but the rules would stay strict in DerivedCRS and ProjectedCRS subtypes).

For deformation models like the Canada velocity grid v6 case, I think that an association is fine too - no strong preference on my side. I feel a little bit uncomfortable about having this association in SingleCRS however. I wonder if we should define a DynamicCRS in a way very similar to what we did with DerivedCRS in "UML diagram - Derived Coordinate Reference Systems" figure, i.e. using multi-inheritance. Example:

• DynamicCRS defines an association to PointMotionOperation, named "deformation".
• DynamicCRS adds the restriction that its datum must by dynamic datum.
• DynamicGeographicCRS extends both GeographicCRS and DynamicCRS.
• DynamicVerticalCRS extends both VerticalCRS and DynamicCRS.

However above proposal would add 3 more types to an already quite populated UML.

[RogerLott]

Decision reached at today's meeting:

1. Add 0..* association named Deformation from GeodeticCRS to PointMotionOperation

2. Add 0..* association named Deformation from VerticalCRS to PointMotionOperation (If preferable from modelling perspective, these two associations could be normalised through adding an abstract GeodeticVerticalCRS class with subtypes GeodeticCRS and VerticalCRS. [GeodeticVerticalCRS I think is preferable to DynamicCRS because many Geodetic and Vertical CRSs are not dynamic]. However introducing this extra class is not really desirable from the perspective of users - seems superfluous).

3. In OperationFactory, add function isSameEnsemble(CRS, CRS) : Boolean

4. Martin to provide a further additional function to go into the OperationFactory class (to find entity ID from a registry).

Definitions of these to be provided later.

We failed to discuss Martin's question: "In addition, should we put an association from OperationFactory to CI_Citation named "authority"? The reason is that the result of findCoordinateOperation(CRS, CRS) may depend on the geodetic registry used. For example when asking the transformations from OSGB 1936 to ED50, if OperationFactory performs its search using the EPSG geodetic database, then the Transformation set will include EPSG::1315 - a transformation defined for oil exploration - while another geodetic registry may not include that transformation, or include other transformations.". This looks to me like a sensible suggestion.

We also failed to discuss whether the name of the OperationsFactory class remains sensible given the addition of these extra functions.

[desruisseaux]

Just as a clarification, DynamicCRS was not proposed as a parent type of all GeodeticCRS and VerticalCRS, but rather only some of them through multi-inheritance. For example DynamicVerticalCRS would have two parents: VerticalCRS and DynamicCRS. UML below. This is the same approach than what we did with DerivedCRS. Just for clarity in this diagram, boxes in yellow are abstract classes and I represented associations as attributes just for making this diagram simpler.

I do not claim that it is the right thing to do; just submitting for evaluation.

[jetgeo]

I think this should be somewhere close to what you are describing?

[RogerLott]

Jetgeo said

I think this should be somewhere close to what you are describing?

Yes, but I think that the Deformation associations should be simple associations, not aggregations (like HeightTransformation). Only DerivedCRS to Conversion is an aggregation.

I am fine with the role name deformation, but wonder why you chose that when the association to Conversion is called conversion and that to Transformation is called transformation. Would pointMotion be more consistent with these two?

Would the assocation lines be less complicated if the order of PointMotionOperation, Conversion and Transformation were changed so that Transformation was in the centre? Then VerticalCRs to PointMotionOperation could go upward.

[desruisseaux]

I am fine with the role name deformation, but wonder why you chose that when the association to Conversion is called conversion and that to Transformation is called transformation. Would pointMotion be more consistent with these two?

Should we consider the opposite approach? Rename the "conversion" association as "definition" and the "transformation" association as "heightTransformation"? The reason is that an association of the same name than the target class does not bring new information, while alternative names are more explicit about what are the purpose of those coordinate operations.

[jetgeo]

I agree with all comments from @RogerLott. I didn't really put any effort into the role name, I just used the same name as the name of the association. I also find @desruisseaux 's suggestion interessting, but eave that up to you to descide. I have no strong opinion, both versions area OK from a UML Point of view.

[RogerLott]

As long as we have consistency between the role names of the three associations I am ok with either the above or Martin's suggestion to change them all. The above seems to be more consistent with what has been done for role name coordOperation for the associations from ConcatenatedOperation and PassThroughOperation to CoordinateOperation, but perhaps these are not good analogies. Taking Martin's point but perhaps giving greater geodetic meaning, what about velocityModel, geoidModel, and derivingConversion as the three role names? The latter is already in use as the keyword in CRS WKT, ISO 19162. velocityModel could alternatively be deformationModel in case in the future something other than velocity is used, and geoidModel could instead be heightCorrectionModel to when the surface is not exactly the geoid, but the above are shorter and we can explain in the text these alternatives. These are all new (to this revision) associations so we are free to choose any appropriate names. What we should not do is change the role names of those associations in the 2007 model. Nobody is suggesting that, but I am just closing it down before it opens up.

[desruisseaux]

I would propose the names having geodetic meaning as suggested by Roger.

[RogerLott]

One other item we have yet to finalise: OperationFactory. From my post above:

_4. Martin to provide a further additional function to go into the OperationFactory class (to find entity ID from a registry).

We failed to discuss Martin's question: "In addition, should we put an association from OperationFactory to CI_Citation named "authority"? The reason is that the result of findCoordinateOperation(CRS, CRS) may depend on the geodetic registry used. For example when asking the transformations from OSGB 1936 to ED50, if OperationFactory performs its search using the EPSG geodetic database, then the Transformation set will include EPSG::1315 - a transformation defined for oil exploration - while another geodetic registry may not include that transformation, or include other transformations.". This looks to me like a sensible suggestion.

We also failed to discuss whether the name of the OperationsFactory class remains sensible given the addition of these extra functions._

Martin, could you finalise your input to this?

[desruisseaux]

OperationFactory needs to be renamed. I propose GeodeticRegistry since the intend is to give access to a registry like EPSG. Functions could be (I'm putting more than we discussed; feel free to remove any extraneous functions):

• authority association to CI_Citation. If all remaining methods listed below fetch their information from the EPSG geodetic registry, than the authority shall be the CI_Citation described in EPSG guidance note. All CharacterSequence arguments below are codes in the namespace of this authority (typically EPSG codes, in which case implementations will parse the character sequences as numbers before to use them as primary keys for database lookup).
• findCoordinateReferenceSystem(CharacterSequence) : CoordinateReferenceSystem
• findCoordinateSystem(CharacterSequence) : CoordinateSystem
• findCoordinateSystemAxis(CharacterSequence) : CoordinateSystemAxis
• findDatum(CharacterSequence) : Datum
• findPrimeMeridian(CharacterSequence) : PrimeMeridian
• findEllipsoid(CharacterSequence) : Ellipsoid
• findUnitOfMeasurement(CharacterSequence) : UnitOfMeasurement
• findCoordinateOperation(CharacterSequence) : CoordinateOperation
• findCoordinateOperations(CRS, CRS) : Set<CoordinateOperation>
• areMembersOfSameEnsemble(CRS, CRS) : boolean

Examples: if the authority is EPSG, then an example of valid function call is:

CoordinateReferenceSystem crs = findCoordinateReferenceSystem("4326");

But if the authority is OGC, then an example of valid function call is (from WMS specification):

CoordinateReferenceSystem crs = findCoordinateReferenceSystem("CRS84");

Other codes valid under OGC authority are "AUTO" and "AUTO2" codes.

[RogerLott]

For the find* functions, I suggest that we omit for 'low level' (constituent) entities Martin has included and limit the functions to the 'top level' entities: findCoordinateReferenceSystem(CharacterSequence) : CoordinateReferenceSystem findCoordinateOperation(CharacterSequence) : CoordinateOperation and also have findCoordinateOperations(CRS, CRS) : Set areMembersOfSameEnsemble(CRS, CRS) : boolean

I agree to changing class name from OperationFactory to GeodeticRegistry and to including association to CI_Citation.

[jetgeo]

Hm... I might be wrong, but didn't we discuss the name GeodeticRegistry when we first created the class, and dropped it because it was in another standard's domain?

[desruisseaux]

I do not remember well. Does the other standard really defines GeodeticRegistry or more abstract kind of registry? It happen sometime that different ISO standards use the same words (e.g. ISO 19111:2007 RS_Identifier extending ISO 19115:2003 MD_Identifier). Maybe it is okay if our use of "registry" word is not in contradiction with their use.

[RogerLott]

We certainly did discuss the name GeodeticRegistry when we first created the class. At that time we were considering several functions. All but one of them were either changed to associations (e.g. HeightTransformation) or eliminated and the class was reduced to having the single function findCoordinateOperations(CRS, CRS) : Set ,CoordinateOperation>. At that stage the class name was changed to OperationsFactory. I have no clear recollection for the reason why the name was changed, but I don't think it was anything to do with use in other ISO standards, more to do with better reflecting its [then] content. The only ISO standard for geodetic registries is 19127 is a simple bridging document between 19135 (Registry management) and 19111, it contains no UML model. So the name GeodeticRegistry could, I think, be used if we want to. With the now-proposed four functions I listed earlier it seems to me to reflect their scope - they can only be made in the context of a collection of definitions. However 19135 distinguishes between 'register' as the collection of items and 'registry' as the IT platform which houses a register. As these operations may not be limited to the IT platform itself but could be in applications using that platform, perhaps GeodeticRegister would be more correct. The current definition for the class is "Operations supported in the Coordinate Operation package". If someone has a better description that covers our four functions (and leaves open the possibility of additions) and a term that describes the collection of functions that will also be fine.

[RogerLott]

19111:2007 used the role name 'conversion' for the aggregation named Definition from DerivedCRS to Conversion. If we change this to 'derivingConversion' as suggested above, do we introduce backward compatibility issues?

[jetgeo]

For basic names like the one we are discussing here, I would prefer to not use the same name in different standards, as it may lead to some confusion. But as @RogerLott says, 19127 don't have a UML model. And the term is not defined in the ISO/TC211 term database either, so I an OK with this. Perhaps this class may be the foundation for a UML model of the geodetic register in the future?

On the role names: Yes, I believe changing the role name from 'conversion' to 'derivedConversion' introduces BC issues. Then I suppose we should keep 'conversion'?

New figure bellow, with new name and operations for GeodeticRegister.

[RogerLott]

The role name for the DerivedCRS to conversion association needs changing: conversion was used in 19111:2007 derivingConversion used in 19162:2014 as a WKT keyword (no UML model)

Despite the backward compatibility problem my preference would be for compatibility with 19162. Can we explain the backward compaibility as a typo and updated to correspond to 19162? Or is consistency with 19111:2007 essential?

[RogerLott]

The title of the 19127 document is "Geodetic register". Currently it has no UML model. That is likely to remain, as its model is essentially that of 19111 and 19135, but it is conceivable that it could introduce a subclass of 19135's Register class and if it were to do so then 'GeodeticRegister' would be a logical choice. So although low risk, we should probably not use that.

What about 'RegisterOperations'?

[desruisseaux]

RegisterOperations is fine for me.

About backward of DerivedCRS to Conversion association name, I have no strong opinion. We already have some incompatible changes, so one more may be acceptable. I think that names with geodetic meaning have long term advantages. Whether it outweigh the more short-term compatibility break, I could not said. On a personal point of view, I would choose geodetic meaning.

[jetgeo]

The backwards compatibility issues can be described in an annex, ref ISO/TC211 resolution 744:

ISO/TC 211 strongly recommends that revisions of standards and technical specifications include an informative annex which describes how backward compatibility is addressed. This annex may include crosswalks, mappings or similar mechanisms, which evidence the degree of compatibility.

Do we then settle on 'RegisterOperations'?

[RogerLott]

Yes. 19111 doc already has an Annex G.

So with these changes discussed today, I think we can close this issue.

[jetgeo]

Agree, if this figure is OK?

[desruisseaux]

Do we show the association from RegisterOperations to CI_Citation on this figure or is it intended to be shown elsewhere?

[jetgeo]

Sorry, I have forgot about that one. I'll look into it.

[jetgeo]

I am not sure about the CI_Citation association: Could someone specify role name and multiplicity? I suppose it can be shown both in the Operations part 1 diagram and in the Register operationsdiagram.

[desruisseaux]

For the role name, I suggest "authority". This would be consistent with the "authority" role in MD_Identifier (and will often be the same value when the MD_Identifier is for a CRS).

For multiplicity, I have hesitation between 0…1 or 1…1.

[RogerLott]

Role name of authority looks fine.

Multiplicity: if running the function against multiple registers is a possibility, for interoperability I can see that 0..1 might be problematic: running the function against two registers that contained same ID for different entities. So should the cardinallity be 1..*? Or would this be wrong, each return can only have one citation? I am struggling to find a use case of when having 1 would prove problematic. (What is the difference between 1 and 1..1?)

Figures: in the 19111 document I have no plans to include a separate register operations diagram. It can all be included in the Operations part 1 diagram without difficulty.

[desruisseaux]

1…1 was my mistake, it is the same than 1.

A multiplicity of 1 implies that if a user wants to run against multiple registers, said EPSG and OGC, then he would have to use two distinct RegisterOperations instances, one for each authority. This would avoid the identifier collision issue if two authorities use the same codes. This would also avoid the difficulty of specifying what should be the behavior of findCoordinateOperations(CRS, CRS) and areMembersOfSameEnsemble(CRS, CRS) functions if the two CRS given in arguments come from different authorities.

[jetgeo]

[RogerLott]

The role name for the DerivedCRS to Conversion association should be changed: derivedConversion should be derivingConversion

[jetgeo]

Ok, done.