Jody Garnett <[EMAIL PROTECTED]> wrote on 11/13/2006 06:18:06 PM:
> Bryce L Nordgren wrote: > > We might be able to make Coverage extend feature. We might also just want > > to provide a coverage implementation of the Feature interface. The second > > one might be more in line with the spirit of 19100. I haven't really > > resolved this issue in my own mind yet. > > > I wonder w/ respect to Coverage extending Feature if they are just > advertising a few attributes (such as bounds?) They are advertising a few _Properties_. Some properties are attributes (rangeType, extent, commonPointRule), some properties are operations (list, select, find, evaluate, evaluateInverse). > > We could make a POJO<->Feature adapter which exposes public fields as > > Feature attributes and public method signatures as Feature operations. > > Then we just write Coverage as a POJO and adapt it into the Feature > > interface. But we'd have to allow run-time extension. I think this is why > > I was looking at EMF. I'll have to dwell on this one. > > > I have been thinking about that (and you can see the work occurring on > the various Pojo datastores), however I am also attracted to the earlier > suggestion of defining "Mix-ins" where an an operation is defined > against a set of specific attributes (captured with Java interface or > data structure?) and then we can make a wrapper for each feature that > has the correct attributes; this would separate the definition of > operation code from the identification of types where the operation can > be used. You seem to be thinking of a Java implementation of a Data Product Specification (19131), which is unique because 19131 exists to help people write human-readable data product descriptions. Essentially, you have a pre-existing registry of well-defined Features and another registry of well defined properties. A data product is specified by requiring the presence of items from these registries. So, you can say "the MODIS fire product contains a raster coverage which is a fire product classification, and a fire point coverage." The raster classification and the fire point coverages are defined in external registries, so you know the meanings of the values in the various attributes. You don't know how these data are divided into attributes and operations but you know what conceptual entities the dataset must contain, so the human reader knows they can use it. It sounds like you want to be able to write code to manipulate and query a Java Data Product Specification, and write adapters from a particular incarnation of that data product to the specification. I think it's a good idea. I think you can make a Data Product Mapper which could offer the human user the opportunity to connect concepts from the data product specification to the actual data in the data store. Presumably they could save a particular mapping for later use, and perhaps trade it with their friends. I'm pretty sure that automated mapping would be hard. > > Righto. I need to delve into archives w.r.t. Expression. Gotcha. > > > The following page should be sufficient (the long and short of it is > that expression is starting to work against features, featuretypes and > pojos - with xpath support): > - http://docs.codehaus.org/display/GEOTOOLS/Expression+Improvements Ow my brain hurts. How can you call an operation with this system? Has the <Property/> tag been appropriated so it only represents attributes? What is this Expression interface? Do I have to access data with XML snippets or can I write code? In the GeoAPI Feature interface, what is putClientProperty? Does that add a named property to the feature or does it set the value? Does setting the value of an operation make any sense? Would that mean setting a functor object to actually perform the operation? I guess let me start small and slow: how do I call an operation if my starting point is an org.opengis.feature.Feature? Mamma, are we there yet? :) > Bryce have you looked at GeoAPI Feature Model recently? We have Complex > (the supertype of Feature) and is very similar to your ISO Record. > Mostly we are breaking appart due to problems with ISO use of Name (and > TypeName literally being the super of Record or some madness). Just did. Did you write down the tags on the truck that just hit me? > I see so rather then use Complex (or GeoAPI Record) you would back > yourself onto another dynamic type system - namely JDBC ResultSet (and > ResultSetMetadata) or the different table models. The interface should stay the same. I'd say it's more a matter of what a particular implemenatation uses as a data store. > Well if you want have a look at RasterSymbolizer (the point of contact > between coverage and expression) and then we can have a nice IRC chat. I think I need coffee. :) Learning sucks. Bryce ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
