[EMAIL PROTECTED] wrote on 01/23/2006 09:10:48 AM:
> simone giannecchini wrote: > > >>as well, but I think in our context is more correct say that feature > >>are both that same level as well as above coverages. As an instance, > >>in the Geoserver we develop we render coverages wrapping them inside a > >>feature, in order to follow strictly the specification. > >> > >> > Understood. Conceptually, coverages have always been a type of feature. The only question is "does coverage extend feature"? The diagram should probably represent the conceptualization and hide the dirty implementation details. > >I agree, but I wanted to keep third party libraries separated from the > >rest f the stack. Do you think that keeping things this way is > >misleading? > > > > > For right now - yes. If you want to be "pure" just say geometry, and the > fact that we are using JTS Geometry can be an accident of implementation > right now. Agreed. In the OGC/ISO19100 meta-library, Spatial Geometry is a building block from which larger structures are built. In fact, I have one person working on investigating the amount of work it would take to make JTS implement 19107. I have another working on implementing Temporal Geometric Primitives (ISO 19108; and missing from the diagram). :) This is perhaps another way of presenting the topic: the 19100 series defines nearly everything needed to implement a geospatial infrastucture from the ground up. It starts with basic data structures like "collections", "sets", "bag", units, simple "Date" and "Time" types, and moves on to Records, Namespaces, Spatial and Temporal Geometry and Topology, CRS, metadata, feautres, feature catalogues and coverages. The point is, it always builds on itself by refering to previously codified concepts, so the terminology is uniform. Geotools does not implement even half of the required code, but collects together disparate libraries which concentrate on one or two aspects. In this respect, JTS is not much different than java.util.Date, javax.units.*, or javax.xml.namespace.QName. Geotools does not exclusively build on itself, but plays the role of systems integrator. For uniform, vertically integrated conceptual integration, look to the standards. For accidents of implementation, look to Geotools or any other implementation. :) It all depends on specifically what you are trying to show. > >>4. GML is built ontop of Features and XML > >> > >> > >Mmmmhhh, I have a small experience with GML plugin, but shouldn't GML > >be seen at least as a way to represent feature (we extract feature > >from GML and we write features in GML)? > > > > > I am thinking in terms of layers right now. What are > you drawing a diagram of? > > >Besides this I am trying also to point out possible extension points > >therefore, in case we implemented more of the GML spec GML modules > >would be almost everywhere, am I right? I have trouble thinking of GML as anything but a single persistence format. This places it firmly in the realm of a plugin in my mind. (Or multiple plugins: CRS plugin, Feature plugin, Coverage plugin). I must confess I do not know too much about GML, but the little I do know leads me to believe that it is merely a single standardized expression of a collection of concepts, each of which is actually defined elsewhere. > >I agree, but again I designed it this way because I was thinking about > >a possible implementation of a catalog, therefore I thought it would > > > > > Now I am Jealous, I have been wanting to work on a Catalog for ages ;-) > Have fun! Buy 19110 first. :) There is at least the chance that it could pay for itself in the time it saves you. :) (There is, of course, also the chance that it will be a complete waste of money. However, in terms of time, the risk is limited to less than the cost of a man-day.) Bryce ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
