source: osm/applications/editors/josm/plugins/opendata/includes/org/opengis/feature/type/package.html@ 28000

Last change on this file since 28000 was 28000, checked in by donvip, 12 years ago

Import new "opendata" JOSM plugin
File size: 6.9 KB
Line 
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2
3<HTML>
4<HEAD>
5<TITLE>package org.opengis.feature.type</TITLE>
6</HEAD>
7<BODY>
8Feature model ISO 19109 with allowances for usability.
9
10<p>This package captures the type information for a general feature model. This feature model has been produced after review of the ISO 19109
11specification, and a review of several java implementations. </p>
12
13<p>Capabilities:
14<ul>
15 <li>Provide information for the creation of new feature data and the validaiton of existing feature data
16 <li>Provide enough description to support the use of a Query Language for data access. We have tested with
17 the Filter 1.0, Filter 1.0 and Common Query Lanague at this time.
18 <li>Capture enough information to permit the seamless handling of models
19 taken from XML specifications, in particular the use of Sequence,
20 Choice and support XPath access have proven a challenge.
21 <li>Provide for a definition of a SimpleFeatureType similar in spirit to
22 the previous GeoAPI feature model in which access methods may be used
23 directly and are based around simple Strings.
24 <li>Consistent with common java usage conventions
25</ul>
26
27Possibilities for future work:
28<ul>
29<li>Representation of application schema as a first class object
30<li>Using naming consistent with ISO 19109 specification
31</ul>
32
33<h2>Type System</h2>
34
35PropertyType forms a class hierarchy representing type information for the feature model.
36
37<center><img src="doc-files/feature_type.gif"></center>
38
39<p>The following ideas are central to the functioning of this package as
40a feature model:
41<ul>
42 <li>AttributeType is the base "Type" in the system, it is bound against
43 a java Class and may be reused.
44
45 <li>AttributeType may indicate available operations using
46 "OperationDescriptors", these descriptors have an OperationType
47 describing their required parameters as list of AttributeTypes
48
49 <li>AttributeType contains set of Filters that are used to "constrain"
50 the permissible value
51
52 <li>AttributeType is allowed to be an extension of a super type. This
53 presents one known issue: the bound java classes may not be compatible
54 even if the modelling a subset is properly represented <br>
55 (An example is Integer representing a subset of BigInteger).
56
57 <li>ComplexType contains additional PropertyDescriptors describing
58 attributes and associations along with cardinality information. Each
59 descriptor is named (in a similar fashion to Java fields being named
60 in a Class).
61
62 <li>FeatureType explicitly represents a spatial type, with additional
63 information such as CRS and default geometry.
64</ul>
65</p>
66Identified objects allow for a String "ID" that; the use of which is application specific.
67Some applications, such as GML, have strict guidelines on the use of identifiers.
68</p>
69
70<p>As pointed out above ComplexType can be used to represent data with interesting
71internal structure. Descriptors are provided to document formally what information is
72available for retrieval by a query language.
73</p>
74
75<center><img src="doc-files/descriptor.GIF"></center>
76
77Descriptors are used to describe the composition and relationships between entities in our feature model.
78AssociationDescriptors are used describe relationships between entities; AttributeDescriptors are used
79to describe aggregation. Several specific subclasses of AttributeDescriptor are available for working
80with specific kind of content such as GeometryDescriptor.
81
82
83<h2>Differences from ISO 19103 with respect to Naming</h2>
84
85<p>We have explicitly made the following break with ISO 19103:
86<ul>
87 <li>Name - we have adopted a simple definition of Name based on QName.
88 The ISO implementation combined the responsibilities of naming with the
89 implementation of a chained linked list of names. The result was heavy
90 weight, and strange and has not proved intuitive in practice.
91 <li>Namespace - implemented as Set<Name>, this is also a tagged with its
92 own Namespace. The ISO implementation combined the responsibilities of
93 lookup with those of maintaining a namespace scope for a provided name
94 (ie bidirectional link between Namespace and Name). The required
95 backpointer prevented Name from being lightweight and has been removed.</li>
96</ul>
97As indicated above we have removed the "back pointers" required to navigate from Name to
98its "context", instead we have provided a URI which should be used with your lookup system
99of choice. This choice may in fact be Namespace (and is when working with TypeNames
100in a Schema), however the actual implementation should be provided by the hosting
101language in many cases.
102
103<center><img src="doc-files/name.png"></center>
104
105Many applicaitons will make use of their own register when resolving names;
106we offer the use of javax.naming.Name API as a recommendation.
107
108<h2>Differences from ISO 19109 with respect to General Feature Model</h2>
109
110<p>We have explicitly made the following break with ISO 19109:
111<ul>
112 <li>TypeName - we have separated out the concerns of TypeDefinition
113 from TypeName, in ISO 19109 these were combined and caused great
114 confusion when implementing.
115 <li>AttributeName - also separated from AttributeType in a similar
116 manner.
117</ul>
118Numerous other changes have been made to leverage Java collection API
119where appropriate. These represent a direct mapping onto the language
120constructs and may or may not prove significant to those arriving from an
121ISO 19109 background.
122</p>
123
124<h2>Relationship to ISO 19109 Primer</h2>
125<p>This work is greatly informed from a proposal included in the ISO
12619109 primer - written by Bryce. In particular the requirement for
127operations, associations and detailed review of ISO19109, and EMF was a
128great asset. This primer also served as the only public documentation of
129the ISO 19109 material available for open development.
130<p>Differences from Bryce's proposal:
131<ul>
132 <li>Name, TypeName and Namespace as above
133 <li>Schema - we once again do not combine implementation with
134 identification (the proposal for Package extended ScopedName). We have
135 implemened a Schema class as a Map<TypeName ,AttributeType> this works
136 out nicely as the keySet ends up being the Namespace for the Schema.
137 <li>Factory and Type separation, we have explicitly not extended our
138 type Schema class in order to make a FeatureFactory. A requirement of
139 the type system is to allow for application supplied FeatureType
140 creation, this is a seperate concern then modeling and grouping feature
141 types.
142</ul>
143The definition of Record and Name wsere unresolved at the time of this
144work and has not been integrated. In particular the definition of Name
145was taken as "too complicated".
146</p>
147<p>We also disagreed with one of the goals of the proposal: <i>convention
148that the creation of objects inside an application schema is the
149responsibility of the schema author</i>. This goal is in conflict with
150our need to allow applications to create instances of their own
151devising. This need is particulary apparent when an application needs to
152ensure the use of a specific base class (for example to work with a
153persistence system Jaxtor, or modeling system like EMF).</p>
154</BODY>
155
156</HTML>
Note: See TracBrowser for help on using the repository browser.