DerivedCRS and its associations

[jetgeo]

From @RogerLott:

For derived CRS we have agreed that · the derived CRS inherits the datum of its base CRS and we want the model to show this. · a derived CRS does not necessarily have to be of the same type as its base CRS. · the derivedCRS type depends upon its CS. Put another way, the constraints on CS-CRS associations apply to derivedCRSs. So for example a derivedEngineeringCRS has the same constraint in being associated to an EngineeringCS as does an EngineeringCRS.

We forced the datum inheritance through the constraints in DerivedCRS {count(baseCRS.datum)=1 implies datum=baseCRS.datum} and {count(baseCRS.ensemble)=1 implies ensemble=baseCRS.ensemble} (in combination with the constraint {count(datum + ensemble)=1} in the SingleCRS class). I think we need to continue to force datum inheritance through these constraints.

The second of the above bullets is new. Because we had previously had a derivedCRS having an association to a conversion and conversion was defined as a coordinate operation without change of datum, we had assumed that a derivedCRS had to be the same type as its base CRS type. This was reflected in the DerivedCRS diagram. But now it is to be allowed for example for an engineering CRS to inherit a geodetic datum. I think this new thinking invalidates the derivedCRS diagram. So if the derivedCRS diagram is to be replaced, how do we show in the UML that the derivedCRS subtypes associations to CS are constrained? Do we need a version of the CS-CRS associations diagram but showing each of the derived*CRS subclasses associated to the appropriate CS class?

[jetgeo]

Ok, think I have done this now:

• Removed multiple inheritance for DerivedCRSs
• Moved inheritance for DerivedGeographicCRS from DerivedCRS to GeographicCRS (this was missing in the old version - is it correct this way?)
• Added identical CS Associations for DerivedCRSs as for "main" CRSs.
• Created separate CS-DerivedCRSs diagram

New figures in https://github.com/ISO-TC211/ISO19111/tree/master/Figures/Main%20version

[jetgeo]

From @RogerLott:

• [x] One omission. In the CS-DerivedCRS diagram, CartesianCS should be subtyped off Affine CS so that a DerivedImageCRS is associated with both affine and Cartesian.

• [x] On the CS-CRS diagram I think it would be useful if there was a note on DerivedCRS to say "See part 2 for CS-DerivedCRS associations". (This would refer to the CS-DerivedCRs diagram).

• [x] Is it correct for DerivedGeographicCRS to be a subtype of DerivedGeodeticCRS? A GeographicCRS is subtyped off GeodeticCRS so that it can be associated to the geodetic reference frame (datum). But derived CRSs get their datum from the constraint in the derived CRS class. So should not DerivedGeographicCRS just be subtyped of DerivedCRS?

• [x] The CRS diagram does not fill a complete A4 page (see "CRS diag.jpg" attached). It might be possible to squeeze all of the derived CRS classes into the bottom of the CRS diagram, so eliminating the need for the derivedCRS diagram - see attached "CRS with derivedCRS.png". Could you see if the two diagrams can be combined into one? (Don't delete the CRS or DerivedCRS diagrams yet in case the one diagram is too small to read).

[jetgeo]

OK, done. I have no strong feelings about subtyping for DerivedGeographicCRS, my thinking was just that it should be the same structure as for the main CRS. I guess it will work either way. https://github.com/ISO-TC211/ISO19111/tree/master/Figures/Main%20version

[jetgeo]

From @RogerLott (2017-05-17): Derived CRS. We were not sure that we are there yet with this part of the model. We again discussed grids derived from map grids, i.e. CRSs derived from projected CRSs. As projected CRS is itself a derivedCRS, this is a double derivation! We think it would be useful if the model showed that a CRS may be derived from a projectedCRS. In the last iteration we made some changes to the model to show derived CRS classes subtyped off DerivedCRS which was subtyped off SingleCRS. This allows continuous iteration but we are not happy with its generality – a derived[type]CRS can only have a [type]CRS as its base because of the datum inheritance issue.

• [x] This previous iteration removed the attached derived CRS diagram showing that derivedCRSs are subtypes of a CRS of the same type (e.g. verticalDerivedCRs is a subtype of verticalCRS). We think removing this may have been a mistake and that we need to revert to having this derivedCRS diagram (and the note referencing it in the CRS diagram).

• [x] But in addition we would like a new derived CRS class to be subtyped off projected CRS. To match the other derived CRS subtypes it would be called "derivedProjectedCRS" but because projected CRS is itself derived we think this may be confusing. Might "derivedFromProjectedCRS" be better?

[jetgeo]

OK, I have reverted back to a previous version with multiple inheritance for DerivedCRSs. I don't think I have done any other changes after that version, so it should be OK. I added the subclass for ProjectedCRS, but I think it is better to name it "DerivedProjectedCRS". This is in line with the structure for the other DerivedCRSs, and the name "derivedFromProjectedCRS" is more of a operation name, not a class name. The confusion should not be more then it allready is in this diagram :). Question: What shall be the baseCRS of a DerivedProjectedCRS? I suppose it shall be ProjectedCRS? As it is now, it is inherited from ProjectedCRS, which means it is a GeodeticCRS. Should there be a baseCRS association from DerivedCRS to ProjectedCRS? New diagrams in https://github.com/ISO-TC211/ISO19111/tree/master/Figures/Main%20version

[RogerLott]

Derived CRSs

See attached 'rules' for derived CRSs.

Derived CRSs 2017-05-18.docx

[RogerLott]

Derived CRSs 2017-05-18v2.docx

Sorry, a bit missing from the previous upload, corrected here with missing text in blue.

[RogerLott]

Are the 'rules' for derived CRSs met through the existing diagrams but with this addition:

[jetgeo]

New diagram: