Project

General

Profile

1
<?xml version="1.0" encoding="utf-8"?>
2
<xs:schema targetNamespace="http://www.isotc211.org/2005/gss" elementFormDefault="qualified" version="0.1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gss="http://www.isotc211.org/2005/gss">
3
	<!-- ================================= Annotation ================================ -->
4
	<xs:annotation>
5
		<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>
6
	</xs:annotation>
7
	<!-- ================================== Imports ================================== -->
8
	<xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="../gml/gml.xsd"/>
9
	<xs:import namespace="http://www.isotc211.org/2005/gco" schemaLocation="../gco/gco.xsd"/>
10
	<!-- ########################################################################### -->
11
	<!-- ########################################################################### -->
12
	<!-- ================================== Classes ================================= -->
13
	<!-- ........................................................................ -->
14
	<!--==XCGE: gml:Point==-->
15
	<!-- ........................................................................ -->
16
	<xs:complexType name="GM_Point_PropertyType">
17
		<xs:sequence minOccurs="0">
18
			<xs:element ref="gml:Point"/>
19
		</xs:sequence>
20
		<xs:attributeGroup ref="gco:ObjectReference"/>
21
		<xs:attribute ref="gco:nilReason"/>
22
	</xs:complexType>
23
	<!-- =========================================================================== -->
24
	<!-- ........................................................................ -->
25
	<!--==XCGE: gml:AbstractGeometry==-->
26
	<!-- ........................................................................ -->
27
	<xs:complexType name="GM_Object_PropertyType">
28
		<xs:sequence minOccurs="0">
29
			<xs:element ref="gml:AbstractGeometry"/>
30
		</xs:sequence>
31
		<xs:attributeGroup ref="gco:ObjectReference"/>
32
		<xs:attribute ref="gco:nilReason"/>
33
	</xs:complexType>
34
	<!-- =========================================================================== -->
35
</xs:schema>
(1-1/2)