1 |
9559
|
tao
|
<?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>
|