<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:gco="http://www.isotc211.org/2005/gco"
           xmlns:gml="http://www.opengis.net/gml" targetNamespace="http://www.isotc211.org/2005/gss"
           elementFormDefault="qualified"
           version="0.1">
  <!-- ================================= Annotation ================================ -->
  <xs:annotation>
    <xs:documentation>This file was generated from ISO TC/211 UML class diagrams == 01-26-2005
      12:14:37 ====== The geometry packages (Figure 4) contain the various classes for coordinate
      geometry. All of these classes through the root class GM_Object inherit an optional
      association to a coordinate reference system. All direct positions exposed through the
      interfaces defined in this standard shall be in the coordinate reference system of the
      geometric object accessed. All elements of a geometric complex, composite, or aggregate shall
      be associated to the same coordinate reference system. When instances of GM_Object are
      aggregated in another GM_Object (such as a GM_Aggregate, or GM_Complex) which already has a
      coordinate reference system specified, then these elements are assumed to be in that same
      coordinate reference system unless otherwise specified. - The geometry package has several
      internal packages that separate primitive geometric objects, aggregates and complexes, which
      have a more elaborate internal structure than simple aggregates. Figure 4 shows the
      dependencies between the geometry packages as well as a list of classes for each package -
      Figure 5 shows the basic classes defined in the geometry packages. Any object that inherits
      the semantics of the GM_Object acts as a set of direct positions. Its behavior will be
      determined by which direct positions it contains. Objects under GM_Primitive will be open,
      that is, they will not contain their boundary points; curves will not contain their end
      points, surfaces will not contain their boundary curves, and solids will not contain their
      bounding surfaces. Objects under GM_Complex will be closed, that is, they will contain their
      boundary points. This leads to some apparent ambiguity. A representation of a line as a
      primitive must reference its end points, but will not contain these points as a set of direct
      positions. A representation of a line as a complex will also reference its end points, and
      will contain these points as a set of direct positions. This means that identical digital
      representations will have slightly different semantics depending on whether they are accessed
      as primitives or complexes. - This difference of semantics is most striking in the
      GM_CompositeCurve. Composite curves are used to represent features whose geometry could also
      be represented as curve primitives. From a cartographic point of view, these two
      representations are not different. From a topological point of view, they are different. This
      distinction appears in the inheritance diagram (Figure 5) as an inheritance relationship
      between GM_CompositeCurve and GM_OrientableCurve. The primary semantics of a GM_CompositeCurve
      (see 6.6.5) is as a closed GM_Object, but it may also act as an open GM_Object under
      GM_Primitive operations (see 6.3.10). Interface protocols depending upon the topological
      details of this object will have to be distinguished as to whether they have been inherited
      from GM_Primitive or GM_Complex, where the distinction first occurs. Even though these
      protocols have been inherited from the same operations defined at GM_Object, they will act
      differently depending upon the branch of the inheritance tree from which they have inherited
      semantics. Creators of implementation profiles may take this into account and use a proxy
      mechanism for realization relationships that cause semantic dissonance. Such a procedure will
      be necessary in object-oriented programming and databases in systems that disallow multiple
      inheritance or make limiting assumptions about method binding.
    </xs:documentation>
  </xs:annotation>
  <!-- ================================== Imports ================================== -->
  <xs:import namespace="http://www.opengis.net/gml" schemaLocation="../gml/gml.xsd"/>
  <xs:import namespace="http://www.isotc211.org/2005/gco" schemaLocation="../gco/gco.xsd"/>
  <!-- ########################################################################### -->
  <!-- ########################################################################### -->
  <!-- ================================== Classes ================================= -->
  <!-- ........................................................................ -->
  <!--==XCGE: gml:Point==-->
  <!-- ........................................................................ -->
  <xs:complexType name="GM_Point_PropertyType">
    <xs:sequence minOccurs="0">
      <xs:element ref="gml:Point"/>
    </xs:sequence>
    <xs:attributeGroup ref="gco:ObjectReference"/>
    <xs:attribute ref="gco:nilReason"/>
  </xs:complexType>
  <!-- =========================================================================== -->
  <!-- ........................................................................ -->
  <!--==XCGE: gml:AbstractGeometry==-->
  <!-- ........................................................................ -->
  <xs:complexType name="GM_Object_PropertyType">
    <xs:sequence minOccurs="0">
      <xs:element ref="gml:AbstractGeometry"/>
    </xs:sequence>
    <xs:attributeGroup ref="gco:ObjectReference"/>
    <xs:attribute ref="gco:nilReason"/>
  </xs:complexType>
  <!-- =========================================================================== -->
</xs:schema>