Coordinate Metadata

[jetgeo]

Create new class CoordinateMetadata with attributes

• position:DirectPositionv[1..*]
• crs:CRS -epoch:Measure[0..1]

[jetgeo]

Roger will come up with a better name for the class

[jetgeo]

From @RogerLott: As discussed yesterday, I am not happy with the name 'coordinate set' for the container for CRS and CoordinateEpoch which John discussed in Tuesday's meeting. I have talked to a couple of folks still here in Stockholm and we think that 'Coordinate Metadata' is a better term. Could you use that when you update the CoordinateOperations with Data Epoch diagram to show the container, please. (Note: I use the word 'container' rather loosely – if it has meaning in modelling I do not imply that).

Note that in Tuesday's discussions we used "CRS + Epoch". Because there are four subtypes of epoch and this is just one of them, we should be making it clearer and be using "CRS + CoordinateEpoch".

I don't know how you are intending to model this container and where it would go, but I wondered whether we might need a new package to hold this container and DataEpoch. Whatever you decide on this will be fine with me.

[jetgeo]

Done?

[jetgeo]

I am not sure about the name "CoordinateMetadata". As I understand it, it is a group of positions with common crs and epoch. To me, "CoordinateSet", "PositionSet", or "..Container" seems better.

[RogerLott]

Coordinate Set is not possible as it is already in use (in the 19111 text and also in the TC211 TMG spreadsheet so possibly used by other standards too). There are secondary reason why I don't like it as John used it – it might be abbreviated to CS which is also used for coordinate system. But the main issue is that it is already in use, so we have to find something else.

I have used Coordinate Metadata in the WD text I have updated since Stockholm. It seems to work ok as a heading for clause 6 and the following requirements: Requirements class: static CRS coordinate metadata Requirement 1: All coordinate tuples in a coordinate set shall be referenced to the same static coordinate reference system. Requirements class: dynamic CRS coordinate metadata CRS is described in clause 9 and reference frame in clause 11. The following subtypes of CRS may have a dynamic reference frame and therefore may be dynamic CRSs: geodetic, geographic, vertical, projected and derived variants of these subtypes. Note that CRSs of these subtypes are not necessarily dynamic; their reference frame attributes need to be examined to clarify this. Requirement 2: All coordinate tuples in a coordinate set shall be referenced to the same dynamic coordinate reference system and to the same coordinate epoch.

I am not sure that Position Set will work as well in the text. But it is ok as a UML class. Let's go with that.

[jetgeo]

I have been thinking about this, and looked at the description in the new version of the document. From the description in clause 6 (figure 2 and 3), I think this can be modelled a bit different, and more similar to the "non-UML-figures". I believe that what's important here is to make sure that all coordinates in a set are connected to the same CRS (and epoch if relevant). And as I see it, there is no difference between a single tuple and a set, we need only one operation. Sorry if I have misunderstood this.

[jetgeo]

• [ ] Check the 19107 model for DirectPosition. Can it be used instead of CoordinateTuple? It has crs and dimention.

Add constraints describing the connection between

• [ ] CoordinateOperation.sourceCRS and CoordinateMetadata.crs (for input to the operation transform)
• [ ] CoordinateOperation.sourceEpoch and CoordinateMetadata.coordinateEpoch (for input to the operation transform)
• [ ] CoordinateOperation.targetCRS and CoordinateMetadata.crs (for output from the operation transform)
• [ ] CoordinateOperation.targetEpoch and CoordinateMetadata.coordinateEpoch (for output from the operation transform transform)

[RogerLott]

Is the data type correct for CoordinateTuple.coordinate? Could be integer. And must have units. (Clause 4 definition 4.5 refers: coordinate one of a sequence of n numbers designating the position of a point in n-dimensional space Note 1 to entry: In a coordinate reference system, the coordinate numbers are qualified by units.

Better as Measure?

[jetgeo]

DirectPosition includes rsid (19107 data type) and dimension (integer). I believe that we do not want to have those attached to the positions in a CoordinateSet in the 19111 model. Instead, we want the coordinates with a crs and possibly an epoch. Therefore, I do not think we can use DirectPosition. And DirectPosition can't be a subtype of CoordinateTuple, unless the 19107 EC creates the 19107 model that way. The 19111 model can't change the 19107 model.

On data type: I have used the same data type as in DirectPosition, but I agree that Measure seems better. Not sure how the unit is given in 19107.

Furthermore, I have tried to add the constraints, see the figure bellow. DirectPosition is also included in the figure, for the sake of the discussion.

[RogerLott]

Some random thoughts:

CoordinateTuple, CoordinateSet and CoordinateMetadata model in UML terms the description of concepts in clause 6. But should the constraint currently on Geometry (in the Relation to Geometry diagram) "{crs.datum.oclAsType(DynamicReferenceFrame or DynamicVerticalReferenceFrame) implies count(epoch)=1} be on the CoordinateSet class?

Questions are a) how does CoordinateSet relate to Geometry? b) how does the attribute coordinate in CoordinateTuple map to coordinate in DirectPosition?

CoordinateSet is just a collection of points; it knows nothing about their geometry. May it be a subset of Geometry? It does not have to be, because a set of times (in a temporal CRS) have no spatial geometry. Does the UML in 19111 need to be integrated with the UML in 19107 – not much of a harmonised model if they do not! Is some sort of optional association or note linking CoordinateSet to Geometry needed? Note attached to CoordinateSet: "Geometry described in 19107" ?? Then remove the Relationship to Geometry diagram?

Re how does the attribute coordinate in CoordinateTuple map to coordinate in DirectPosition, what is the significance of the note in the definition of coordinate ("In a coordinate reference system, the coordinate numbers are qualified by units")? Is that qualification in the number itself or in the CRS to which the numbers are referenced? Is the note saying "the coordinate numbers are qualified by units through a coordinate reference system"? If yes, the data type for coordinate should be Number (not Real, to allow for integers). Else the data type for coordinate should be Measure.

[jetgeo]

CoordinateTuple, CoordinateSet and CoordinateMetadata model in UML terms the description of concepts in clause 6. But should the constraint currently on Geometry (in the Relation to Geometry diagram) "{crs.datum.oclAsType(DynamicReferenceFrame or DynamicVerticalReferenceFrame) implies count(epoch)=1} be on the CoordinateSet class?

I think yes, if we are going to keep and use the CoordinateSet class. But I am also thinking that maybe the Geometry interface from 19107 with the relations specified in 19111 might be better. Through those associations, we make sure Geometry is connected to CRS and DataEpoch in 19111. However - will this work for temporal? And Geometry is using DirectPosition, with coordinates as real.

Also: Shall the association from Geometry to DataEpoch be named "coordinateEpoch" instead of just "epoch"?

[RogerLott]

It is important that we connect Geometry and CRS. We have to have a good reason for not doing so.

I think the above model is basically ok. Geometry may be more than just points, it could have line type information. But I do not see any reason why transform(Geometry) could be problematic - it is sufficiently general.

It does however cover only the spatial part. It is still necessary to have simething to transform coordinates between temporal CRSs. That might be something like transform(TemporalCoordinateSet). But if we are doing that, why would we not generalise it to transform(CoordinateSet)? Is including transforms for both Geometry and CoordinateSet out of the question?

CoordinateSet or CoordinateSequence (CoordinateList)? CoordinateSet is defined as a collection of coordinate tuples, a coordinate tuple is defined as a tuple composed of a sequence of coordinates, and a tuple as an ordered list of values. So a coordinate tuple constrains the order of coordinates, but coordinate set does not constrain the order of coordinate tuples. Is that a requirement? If so it seems to be a new one. Is it something for an abstract specification, or for an implementation specification? CoordinateSet may be new to the UML model, but it is not new to 19111. I suggest we retain it and the ballot process can collect comments if change needs to be considered.

Shall the association from Geometry to DataEpoch be named "coordinateEpoch" instead of just "epoch"? At last an easy question! Definitely. We have identified four types of epoch, two of which may be transformation parameters, and it is important to clarify what is being described. So to clarify/emphasise the point I would extend this beyond the Geometry/DataEpoch association and also have the associations from coordinate operation to data epoch being sourceCoordEpoch and TargetCoordEpoch

[jetgeo]

Ok, so here's a new suggestion: I think we can use DirectPosition instead of CoordinateTuple anyway. The rsid attribute on DirectPosition is derived, and can be so from the crs attribute in CoordinateMetadata. By using DirectPosition we get the connection to 19107, and we may still transform time positions, as DirectPosition is just positions, not necessarily geometry. there is still a question about unit for the positions, though. The positions in DirectPosition is data type real.

[RogerLott]

I am ok with this approach.

there is still a question about unit for the positions, though. The positions in DirectPosition is data type real.

So we take it that the units for coordinates are part of the CRS description. The coordinates therefore are not Measure but some form of number. There are definitely cases where these numbers will be integers. If Real can include integer (and from 19103:2015 figure 9 I think it can) then Real is ok. Else it ought to be Number and DirectPosition is, in my view, in need of change to this.

19103:2015 Figure 9. «interface» Integer «interface» Number

• asReal(): Real
• (Number): Number
• +(Number*): Number
• -(Number*): Number
• /(Number*): Number
• <(Number*): Boolean
• <=(Number*): Boolean
• <>(Number*): Boolean
• =(Number*): Boolean

• (Number*): Boolean

• =(Number*): Boolean

• abs(): Number
• asInteger(): Integer
• asReal(): Real
• asString(): CharacterString
• max(Number*): Number
• min(Number*): Number
• negate(): Number
• asReal(): Real
• div(Integer*): Integer
• mod(Integer*): Integer «interface» Decimal «interface» Real
• absoluteValue(): Real
• asDecimal(Integer*): Decimal
• floor(): Integer Figure 9 — Number and subtypes 19103:2015 clause 7.2.8.1 Semantics Real (see Figure 9) is a signed real (floating point) number consisting of a mantissa and an exponent, which represents a value to a precision given by the number of digits shown, but is not necessarily the exact value. The length of a real is encapsulation and usage dependent. The common binary real implementation uses base 2. Since such real numbers can approximate any measure where absolute accuracy is not possible, this form of numeric is most often used for measures. In cases were absolute accuracy is needed, such as currencies, then a decimal representation may be preferred (assuming the currency is decimal, such as the US dollar or British pound). Where there are no subunits possible, integer numbers may be preferred. A real can be considered as an integer part followed by a fractional part given in multiples of powers of 1/2 (halves). See ISO/IEC 11404:2007, 8.1.10 for further description. EXAMPLE 23.501, – 1234E-4, – 23.0..

[RogerLott]

A possibly naïve question. In the Coordinates.CoordinateMetadata class, is the data type for the coordinateEpoch attribute correct? Should it be DataEpoch (from where the Measure data type is obtained)?

[jetgeo]

Agree, done. This will make the model more harmonized, with all the coordinateEpoch associations and attributes based on the same class.