ISO-TC211 / ISO19111

Revision of ISO19111 - Spatial referencing by coordinates.
2 stars 0 forks source link

Add updated Context Diagrams #14

Closed jetgeo closed 6 years ago

jetgeo commented 7 years ago

Add updated contect diagrams for all classes, once the model is stable.

RogerLott commented 6 years ago

On the assumption that issue #36 and #37 is now finalised and with one minor change to issue #36 (discussed below), I hope we can produce final diagrams.

There is at least two further changes required.

  1. The IdentifiedObjects diagrams are missing the GeneralCoordinateSystemAxis subtyping off IdentifiedObject. (issue #36).

  2. The role name for the DerivedCRS to Conversion association should be changed: derivedConversion should be derivingConversion (as used in ISO 19162) (issue #37).

And one further request. I think that the two associations named Deformation (from GeodeticCRs to PointMotionOperation and from VerticalCRS to PointMotionOperation, issue #37) in implementation will probably be considered to be an attribute of a CRS, so should be shown in the CRS diagram. They are not required to define a PointMotionOperation: the sourceCRS provides the information, so I think they can be removed from the CoordinateOperations Part 1 diagram, but I don't mind if they stay there (more important is that they appear in the CRS diagram).

RogerLott commented 6 years ago

Just seen another minor correction needed and posted to #36. Copy here: In 19111:2007 the CoordinateSystemAxis class attribute was axisUnitID, not axisUnit as in yesterday's version of the model above. Do we have any good reason to change this? I suggest it should be as in 2007, +axisUnitID:UnitOfMeasure.

jetgeo commented 6 years ago

OK? coordinate systems

coordinate reference systems

identified object with subtypes

RogerLott commented 6 years ago

In the CRS diagram, should the association names be on VerticalCRS to Transformation (HeightTransformation), VerticalCRs and GeodeticCRS to PointMotionOperation (Deformation) and DerivedCRS to Conversion (Definition)?

Otherwise looks fine.

jetgeo commented 6 years ago

coordinate reference systems

RogerLott commented 6 years ago

I have been through the 19111 draft document and found some minor errors together with some minor suggestions for improvements in the current diagrams, There also are some questions where the text has some legacy provisions and is inconsistent with the current diagrams; the text and model need harmonising but before changing the text I need @jetgeo to confirm that these texts are now obsolete and that the current model is appropriate. And lastly there is a new proposal (which might be considered a compromise from earlier proposals) I have just added to issue #36 . All of these are in the attached. 19111 UML diagrams 2017-12-13 errata.docx

jetgeo commented 6 years ago

I have fixed 1-7 from the document above, and uploaded new figures.

8): There are no connections from DefiningParameter to any other class. But this association exists from OperationParameterValue. Maybe the text has been duplicated from there? Or should DefiningParameter be in the same hierarchy as OperationParameterValue? I have no idea, the use of these are beyond my knowledge.

9): Yes, I believe we removed these constraints because they are in the SingleOperation subclasses that these classes will use.

10): I don't remember why we defined just one value in the Calendar code list. But a code list can be extended, so it is not a problem to have a code list with just one value. But given that a code list may be extended, the text is wrong. I think it should rather be just "Only one of the listed attributes shall be supplied".

RogerLott commented 6 years ago

Identified Objects with Subtypes does not need to show the constraint on CoordinateSystemAxis. It overwrites the box below. I have reverted to the version of 2nd October. But at your convenience you should update the master figure. All others look fine, thank you.

RogerLott commented 6 years ago

I spoke too soon. Minor issue with the CoordinateReferenceSystems diagram. The role name derivingConversion overwrites the association to Conversion arrowhead (in bottom left of diagram).

Also the note on CRS in this diagram ("See DataEpoch diagram for relations to geometry") does not make much sense in the 19111 document as there is no DataEpoch diagram. Better as "For relations to Geometry see Relationship of Coordinates and Coordinate Metadata diagram". Even better as "For relations to Geometry see Relationship of Coordinates and Coordinate Metadata diagram in clause 7".

jetgeo commented 6 years ago

OK, both the above are done. Not sure what to do with question 8?

RogerLott commented 6 years ago

Thanks for diagram updates. Regarding question 8, I suspect it is a copy and paste error in the text so I wll delete it there.

RogerLott commented 6 years ago

@jetgeo During today's teleconference we decided that one change to the UML diagrams should be made. We felt that the CRS diagram is incomplete as it currently is. In particular the CRS diagram must not give the impression that Datum is optional. So...

The Datums.DatumEnsemble class and its associations to SingleCRS and Datums.Datum should be included in this diagram, together with showing the count constraint in SingleCRS, should be included in this diagram.

This will duplicate information shown in the Datums diagram, but we think this is best. For both CRS and Datum, the diagram reader needs to be given the full picture of how these three classes (Single CRS, Datum and DatumEnsemble) relate to each other.

jetgeo commented 6 years ago

Ok, I'll do as you want, but as you say, it will duplicate information. And make the CRS diagram less readable. But here it is: https://github.com/ISO-TC211/ISO19111/blob/master/Figures/Coordinate%20Reference%20Systems.png

coordinate reference systems

RogerLott commented 6 years ago

@jetgeo , please update the Relation to Geometry with the additional constraint in both the Geometry and CoordinateMetadata classes.

jetgeo commented 6 years ago

Done.