featuretype.html
来自「Geotools是一个开源的Java GIS工具包,可利用它来开发符合标准的地理」· HTML 代码 · 共 989 行 · 第 1/4 页
HTML
989 行
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><!--NewPage--><HTML><HEAD><!-- Generated by javadoc (build 1.4.2_13) on Tue Jun 05 11:36:24 GMT-05:00 2007 --><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><TITLE>FeatureType (Geotools 2.3.x 2.3.2 API)</TITLE><META NAME="keywords" CONTENT="org.geotools.feature.FeatureType interface"><META NAME="keywords" CONTENT="getNamespace()"><META NAME="keywords" CONTENT="getTypeName()"><META NAME="keywords" CONTENT="isDescendedFrom()"><META NAME="keywords" CONTENT="isAbstract()"><META NAME="keywords" CONTENT="getAncestors()"><META NAME="keywords" CONTENT="getDefaultGeometry()"><META NAME="keywords" CONTENT="getAttributeCount()"><META NAME="keywords" CONTENT="getAttributeType()"><META NAME="keywords" CONTENT="find()"><META NAME="keywords" CONTENT="getAttributeTypes()"><META NAME="keywords" CONTENT="hasAttributeType()"><META NAME="keywords" CONTENT="duplicate()"><META NAME="keywords" CONTENT="create()"><META NAME="keywords" CONTENT="equals()"><META NAME="keywords" CONTENT="hashCode()"><LINK REL ="stylesheet" TYPE="text/css" HREF="../../../stylesheet.css" TITLE="Style"><SCRIPT type="text/javascript">function windowTitle(){ parent.document.title="FeatureType (Geotools 2.3.x 2.3.2 API)";}</SCRIPT></HEAD><BODY BGCOLOR="white" onload="windowTitle();"><!-- ========= START OF TOP NAVBAR ======= --><A NAME="navbar_top"><!-- --></A><A HREF="#skip-navbar_top" title="Skip navigation links"></A><TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0" SUMMARY=""><TR><TD COLSPAN=3 BGCOLOR="#EEEEFF" CLASS="NavBarCell1"><A NAME="navbar_top_firstrow"><!-- --></A><TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3" SUMMARY=""> <TR ALIGN="center" VALIGN="top"> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A> </TD> <TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="class-use/FeatureType.html"><FONT CLASS="NavBarFont1"><B>Use</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../../index-all.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD> </TR></TABLE></TD><TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM></EM></TD></TR><TR><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2"> <A HREF="../../../org/geotools/feature/FeatureList.html" title="interface in org.geotools.feature"><B>PREV CLASS</B></A> <A HREF="../../../org/geotools/feature/GeometryAttributeType.html" title="interface in org.geotools.feature"><B>NEXT CLASS</B></A></FONT></TD><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2"> <A HREF="../../../index.html" target="_top"><B>FRAMES</B></A> <A HREF="FeatureType.html" target="_top"><B>NO FRAMES</B></A> <SCRIPT type="text/javascript"> <!-- if(window==top) { document.writeln('<A HREF="../../../allclasses-noframe.html"><B>All Classes</B></A>'); } //--></SCRIPT><NOSCRIPT> <A HREF="../../../allclasses-noframe.html"><B>All Classes</B></A></NOSCRIPT></FONT></TD></TR><TR><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2"> SUMMARY: NESTED | FIELD | CONSTR | <A HREF="#method_summary">METHOD</A></FONT></TD><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">DETAIL: FIELD | CONSTR | <A HREF="#method_detail">METHOD</A></FONT></TD></TR></TABLE><A NAME="skip-navbar_top"></A><!-- ========= END OF TOP NAVBAR ========= --><HR><!-- ======== START OF CLASS DATA ======== --><H2><FONT SIZE="-1">org.geotools.feature</FONT><BR>Interface FeatureType</H2><DL><DT><B>All Known Implementing Classes:</B> <DD><A HREF="../../../org/geotools/feature/DefaultFeatureType.html" title="class in org.geotools.feature">DefaultFeatureType</A>, <A HREF="../../../org/geotools/data/vpf/VPFFeatureClass.html" title="class in org.geotools.data.vpf">VPFFeatureClass</A>, <A HREF="../../../org/geotools/data/vpf/VPFFeatureType.html" title="class in org.geotools.data.vpf">VPFFeatureType</A>, <A HREF="../../../org/geotools/data/vpf/file/VPFFile.html" title="class in org.geotools.data.vpf.file">VPFFile</A></DD></DL><HR><DL><DT>public interface <B>FeatureType</B></DL><P>A metadata template for a Feature of arbitrary complexity. <p> Notes: <ul> <li>that this documentation should be read in conjunction with the <A HREF="../../../org/geotools/feature/Feature.html" title="interface in org.geotools.feature"><CODE>Feature</CODE></A>API. <li>the attributes described by this FeatureType <b>and its ancestors </b> define the complete schema for a Feature </p> <p> This interface answers the question: How do we represent features within GeoTools? Of course, the most general answer would be: features can be any Java object. However, this is also the least useful solution because it means that users of features have essentially no way to find out about the meaning of features other than using Java introspection/reflection. This is too cumbersome and is insufficient for the goal of creating a simple framework for manipulating and accessing generic geographic data. The opposite approach might be to define a very constrained set of possible attributes (that, for example, mirrored Java primitives and OGC simple geometries) and only allow features of this type. </p> <p> This interface takes a different approach: it defines a minimal ontology for representing a feature and serves as a consistent framework for defining more constrained (and, therefore, often more meaningful) feature types. A <code>FeatureType</code> represents features as an object that contains zero or more attribute objects, one of which will generally be a geometry, but no geometry and multiple geometries are allowed, according to implementation. Note that instances of implementations of this class are henceforth referred to as schemas. </p> <p> With oneexceptions, the type of an attribute is considered to be its cannonical definition by the FeatureType. For example, an attribute type might be a <code>javax.sound.midi.Sequence</code> object, which contains a <code>float</code> public field called PPQ. The fact that this attribute exists is not known by the <code>FeatureType</code> itself. If a caller asks this <code>FeatureType</code> for all of its attributes, the <code> FeatureType</code> will tell the caller that it has an attribute of type <code>javax.sound.midi.Sequence</code>, but not that this attribute has a sub-attribute (field) called PPQ. It is the responsibility of the callers to understand the objects it is asking for and manipulate them appropriately. </p> <p> The exceptions is for: <ul> <li>if the type stored in the <code>FeatureType</code> is a <code>org.geotools.datasource.Feature</code> type. <br> In this case, all information about sub-attributes are stored and passed to calling classes upon request. The style of reference (XPath) is defined in and mediated by <code>FeatureType</code> implementations. </ul> Question: how does one determine the schema for the attribute defined as a FeatureType? I suspect that FeatureType may be a valid AttributeType? (One needs this schema information before xpath can be used to query the Feature value. </p> <p> It is the responsibility of the implementing class to ensure that the <code>FeatureType</code> is always in a valid state. This means that each attribute tuple must be fully initialized and valid. The minimum valid <code>FeatureType</code> is one with nulls for namespace, type, and attributes; this is clearly a trivial case, since it is so constrained that it would not allow for any feature construction. There are a few conventions of which implementers of this interface must be aware in order to successfully manage a <code>FeatureType</code>: </p> <ol> <li><b>Immutability </b> <br> <i>FeatureTypes must be implemented as immutable objects! </i> All setting methods have been removed from this interface, that functionality is now available in the mutable <A HREF="../../../org/geotools/feature/FeatureTypeFactory.html" title="class in org.geotools.feature"><CODE>FeatureTypeFactory</CODE></A></li> <li><b>Default Geometries </b> <br> Note that the FeatureType contains a special methods for handling geometries. The primary geometry retrieval methods are in <code>Feature</code> because they may change over the life of the feature, while the schema may not. In cases where there are more than one geometries it is up to the implementor to determine which is the default geometry. <code>getDefaultGeometry</code> may return <code>null</code> if there are no geometries in the FeatureType, but if there is one or more geometry then the method must return one of them, <code>null</code> is never an acceptable return value.</li> <li><b>XPath </b> <br> XPath is the standard used to access all attributes (flat, nested, and multiple), via a single, unified string. Using XPath to access attributes has the convenient side-benefit of making them appear to be non-nested and non-multiple to callers with no awareness of XPath. This greatly simplifies accessing and manipulating data. However, it does put extra burden on the implementers of <code>FeatureType</code> to understand and correctly implement XPath pointers. Note that the <code>Feature</code> object does not understand XPath at all and relies on implementors of this interface to interpret XPath references. Fortunately, XPath is quite simple and has a clearly written <a href="http://www.w3.org/TR/xpath">specification </a>.</li> <li><b>Feature Creation </b> <br> FeatureType also must provide methods for the creation of Features, as specified in FeatureFactory. The creating FeatureType should check to see if the passed in objects validate against its AttributeTypes, and if it does should return a new Feature.</li> </ol> <h2>Redesign Notes (feature-exp2)</h2> The main design goal of this is to have FeatureType extend AttributeType. This allows us to nesting of features much more nicely. We already are going in this direction, with the FeatureAttributeType buried in DefaultAttribute. This is just making it explicit, so it works with the complex objects GML can return a lot more sensible. So much of the work in this class is figuring out what concepts are the same. Some stuff may need to be rethought a bit, as there are a few subtle assumptions that we are working with flat files. We will revisit this when we implement choice and multiplicity. <ul> <li>got rid of deprecated getNamespace() method that returned a string, replaced it with a URI return. This has been deprecated for a bit, and was done out of a desire to keep backwards compatibility with 2.0, but that mission failed, so we're just moving on. This change will break a few things, but is a good one, people just need to update their client code a bit. <li>Deprecated getTypeName() to be getName(). They are the same thing, would be nice to get rid of getTypeName, but it's used super extensively. Though perhaps we could consider keeping it as a convenience, a bit more explicit, but it seems like overkill. <li>Updated comments of the AttributeType operations that are inhierited to say what they mean in the context of a FeatureType. </ul> <h2>Redesign Notes (factory-hints)</h2> The factory-hints design is finally coming through on the promiss of the great geotools factory design. This design is actualy placing the factory system under application (rather than 'default') control, as such it is really showing every last place where we did not follow our architecture. <ul> Use Cases: <li>Custom Feature: <br> Application spedcifies the use of a custom feature implementation. This is used so an application interface is supported by each and every feature created. <li>optiomized coordinate storage <br> LiteRenderer2 wants Shape2d specific CoordinateSequenceFactory used for all Geometry creation. The point is to allow only the xy information to be retrieved, and in a format suitable for rapid reprojection and coversion to a Java2D Shape. Any OpenGL (or Java3D) based renderer would also run into this need. </ul> The second use case is interesting in that LiteRenderer2 will be using the Datastore at the same time as other threads that want the normal coordinate sequence. So this is a per Query hint. </ul> <p> Consequence: Since FeatureType is immutable, and CoordianteSequence is specified by the GeometryFactory of the DefaultGeometryAttribute this implys that we have a per Query SchemaType. </p> <p> It strikes me that this is a bad separation of concerns the "schema" should be exactly the same, it is just the GeometryFactory that controls construction that is in the wrong spot. It should be a hint, not attached to GeomtryAttributeType. </p><P><P><DL><DT><B>Author:</B></DT> <DD>Rob Hranac, VFNY, Chris Holmes, TOPP, David Zwiers, Refractions, Jody Garnett, Refractions</DD>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?