A geometric object shall be a combination of a coordinate geometry and a coordinate reference system. In all of the operations, all geometric calculations shall be done in the coordinate reference system of the first geometric object accessed, which is normally the object whose operation is being invoked. Returned objects shall be in the coordinate reference system in which the calculations are done unless explicitly stated otherwise. The interface protocols defined in this section are basically those of set theory. In general a geometric object is a set of geometric points, represented by DirectPosition (see 6.4.1). Object instantiations of geometric objects are GM_Objects. Object instantiations of geometric points, when used as values, are DirectPositions. General set theory operations defined at GM_Object differentiate further down the class hierarchy depending on whether or not the boundary DirectPositions are included as set elements. Subtypes of GM_Primitive do not contain boundary points, while subtypes of GM_Complex do.<br /></p><p>GM_Object and GM_Primitive are purely abstract in the sense that no object or data structure from an application schema can instantiate them directly. Instances of these classes must be instances of one of their non-abstract subtypes, such as GM_Point, GM_Curve, or GM_Surface.  This is not the case for GM_Complex, which can be directly instantiated by an application schema, and need not be an instance of one of the non-abstract subclasses of GM_Composite. Although GM_Complex is not explicitly implemented by this International Standard, it would be valid for an application schema to include a concrete class called "GM_Complex" in a class library conformant to this International Standard. Recall that the name space of the application schema is different form that of the standard and such seemingly logical abuses of name are valid. This is not the case for the abstract classes within this standard. These classes are logically incapable of supporting an implementation directly. Constructors on these classes result in instances of concrete subclasses of these types, not in direct logical instances of the abstract type. <br /></p><p>This is a stricter interpretation of "abstract" than is commonly used in UML, but it is appropriate here as a guide to application schema developers.<br /></p>