Closed jetgeo closed 7 years ago
jetgeo
commented
7 years ago Ok, think this ihas been done now. Still left:
New figures in https://github.com/ISO-TC211/ISO19111/tree/master/Figures/Alternative%20version
RogerLott
commented
7 years ago I don't know how much of the 19111 meeting you managed to pick up, but we agreed that:
a) For coordinate operations a conversion is a coordinate operation used within the description of a derived CRS in which the source and target CRSs are implied, and that a transformation is a coordinate operation in which the source and target CRSs are explicitly given. So the terms remain but with changed definitions. We feel that as far as the model is concerned, there does not need to be separate Conversion and Transformation classes, and that their removal will not lead to any implementation issues as both map back to [single] Coordinate Operation. So… b) The model should not differentiate between Conversion and Transformation as subtypes of single coordinate operation. These classes should be removed from the model. c) The model should retain the derived CRS class. d) The model should retain image CRS, image datum and pixel in cell classes but not the IndexCRS or IndexCS classes, nor the +index attribute added to the Axis Unit class.
So going forward I think the starting point is https://github.com/ISO-TC211/ISO19111/tree/master/Figures/Alternative%20version%20Transformation but I am not completely sure about this as I don't think that any of the main or alternative versions is exactly what is needed – see below. So you might want to assume some other point for going forward.
Changes needed for any starting point (to meet (d) above) are: i) Delete the IndexCRS class ii) Delete the IndexCS class iii) Remove +index attribute from the AxisUnit class
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?
Then there is a question regarding the role names for the associations from DerivedCRS to SingleOperation (currently +conversion) and from VerticalCRS to SingleOperation (currently +transformation). With the removal of the Conversion and Transformation classes are these role names still appropriate? My personal inclination is to leave them as they are, as it might help in the textual description of the implicit/explicit inclusion of source and target CRS in operation descriptions. But is that appropriate?
(Digression: I think that if we had the opportunity to start again we might have used a different name for the SingleOperation class (??CoordinateOperation??) which would have meant a different name for the current CoordinateOperation class (??GeneralCoordinateOperation??) but we are too far down the road to get into class name changes like this).
Grateful if you would amend the UML model to reflect these changes.
jetgeo
commented
7 years ago Closing this, following up conclusions as separate issues
[From Roger Lott]: (Don't throw away the current model – we need this parallel one for discussion purposes first) (Separate branch for discussion)
The objectives are (i) to simplify coordinate operations through the removal of the distinction between conversion and transformation, and (ii) to simplify the modelling of derived CRSs by removing the derivedCRS class and allowing derivedCRSs to either inherit their baseCRSs datum (or datum.ensemble) or to have their own datum. For vertical CRSs the possibility of their reference frame being levelling, geoid or tidal based remains.
A. CRS Package 3.1 Remove the aggregation currently from DerivedCRS to Conversion and replace it with one from SingleCRS to SingleOperation (note: SingleCRS to SingleOperation rather than CRS to CoordinateOperation as I drew during the meeting – I think that may have been wrong). The cardinality will need to be changed from 1 to 0..1 (which I think may be a deficiency with this alternative model).
3.2 Delete the association currently from DerivedCRS to SingleCRS and replace it with a recursive association on SingleCRS. I think it would be best if this association be named – does DerivedCRS seem ok?
3.3 If we are naming the recursive association in (3.2), then we should also add the name DerivedCRS to the association from ProjectedCRS to GeodeticCRS
3.4 Change the subtyping of ProjectedCRS to be off SingleCRS
3.5 Move the aggregation (named HeightTransformation after (2) above) currently from VerticalCRS to Conversion to be from VerticalCRS to SingleOperation.
3.6 Remove the DerivedCRS class
This I think will leave the CRS package diagram as in the attached, except that as I have sketched it the SingleOperation class appears twice and this needs to be corrected to appear only once. Despite removing the derivedCRS class in the model we still want to have the concept of a derived CRS (naming the association DerivedCRS says this). For a derived CRS the two new associations from SingleCRS (named derivedCRS and Definition) are both required: is there any way of linking them together in UML? (Constraint on SingleCRS {count(baseCRS+conversion)=0 or count(baseCRS+conversion)=2 implies singleCRS is derived} ??)
Question: There are constraints in the derivedCRS class. Are they still needed and if so where do they go?
B. Coordinate Operations package 3.7 Delete the Conversion and Transformation classes
The SingleOperation class will have associations from SingleCRS (3.1 above) and verticalCRS (3.5 above). As these define CRSs and will be shown in the CRS package diagram I don't think they will be necessary in the Coordinate Operations package diagram. However in this first pass at tye alternative model I suggest including them as it may make the identification of any circular modelling easier.