Mandatory Parts Constraints on Operation Sequencing

3.5 Mandatory Parts

In order to make client software as easy as possible to write, all of the interfaces specified in each package are mandatory, with the exception of the ‘Authority’ factories. The reason for this is that if portions of the specification are optional, then, in practice, client software will be programmed to use only the mandatory parts. For example, if an implementation were to implement the CS_CoordinateSystem interface, but not the CS_GeographicCoordinateSystem, CS_ProjectedCoordinateSystem, etc., interfaces, then the only way to establish the type of a CS_CoordinateSystem object would be to decode either the WKT or the XML. This does not however mean that all portions of the specification have to be implemented. For example, an implementation could support the CS_CoordinateSystemFactory interface, but not support the createVerticalCoordinateSystem method. In this version of the document, the XML Definition is ‘informative’, and is therefore optional. See also Parameterized Transforms .

3.6 Constraints on Operation Sequencing

Since all interfaced objects are specified to be immutable, there do not need to be any constraints on operation sequencing. This means that these interfaces can be used in parallel computing environments e.g. internet servers. Page 13 of 117 OGC Document Number 01-009 4 Coordinate System Identity This specification uses two character strings for coordinate system identity. The first string identifies the “authority” or “nameSpace” that specifies multiple standard reference systems, e.g. “EPSG”. The second string specifies the “authority code” or “name” of a particular reference system specified by that authority. In the case of “EPSG”, the “authority code” will be a string representation of an integer. See CS_Info Class and Well-Known Text format : AUTHORITY . This specification does not currently support editions or versions of reference systems. That is, no explicit way is provided to represent the edition of a reference system “authority” or “authority code”. If multiple editions exist for a reference system, the interfaces assume that the latest edition is intended. Page 14 of 117 OGC Document Number 01-009 5 Domains of Validity Every GIS coordinate system, math transform, and coordinate transformation has a domain of validity, which is known as its ‘domain’. For a GIS coordinate system, the domain is the set of coordinates that correspond to a position in the real world, to an acceptable level of accuracy. For a math transform, the domain is the set of coordinate positions that can be transformed without mathematical problems, such as dividing by zero. For a coordinate transformation, the domain can be imagined as the intersection of three domains: two domains from the source and target coordinate systems, and the domain of the math transform. In fact, its not quite this simple, since the intersection cannot be formed until the three domain shapes are in the same coordinate system. While working inside a single coordinate system, the domain is usually not critical. Since many GIS systems but not all use floating-point coordinates, you can place points slightly outside the coordinate system domain without causing any immediate problem. So the interface method to get the domain of a coordinate system can be quite simple. See CS_CoordinateSystem.getDefaultEnvelope. However, while transforming coordinates, the exact shape of these domains is often critical, since you cannot work outside them without problems, but you often want to work right up to the edges of them. Since math transform domains can, and often do have highly irregular shapes, it is not possible to have an interface method that returns the shape explicitly. Instead, the math transform domain is described implicitly. This means that you have to ask whether a particular ‘elementary shape’ is inside the domain, outside the domain, or partially inside and partially outside. The elementary shape that the CT_MathTransform interface uses is the convex hull. A convex hull is a shape in a coordinate system, where if two positions A and B are inside the shape, then all positions in the straight line between A and B are also inside the shape. So in 3D a cube and a sphere are both convex hulls. Other less obvious examples of convex hulls are straight lines, and single points. A single point is a convex hull, because the positions A and B must both be the same - i.e. the point itself. So the straight line between A and B has zero length. Some examples of shapes that are NOT convex hulls are donuts, and horseshoes. The simplest type of complex hull is a single point. So you can easily ask whether a point is inside, or outside the domain of a math transform. Page 15 of 117 OGC Document Number 01-009 6 Profiles All packages have been profiled for COM, CORBA and Java. In order to make the different DCP profiles as compatible as possible, we have avoided using too