Jody Garnett <[EMAIL PROTECTED]> wrote on 11/14/2006 02:00:00 PM:
> > 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. > > > I am hoping that it would not be a question of automatic mapping; only > of mapping in an operation when specific properties are available > (specific to the point of exact match? or specific in terms of derived > attribute? answer is the "Trait" probable has to let us known know the > rules of where it can be applied). If we have human-directed mapping first, maybe we can use it enough that we learn how to write an automated mapper. Right now I don't think it's an option. > a) your poor brain sniffle. > b) not sure you can call an operation with this system (it is only used > to filter out content, which you could then call an operation with) ah, I'll stop trying then. > c) the property tag has probably been appropriated to mean data access > in the context of filtering > d) the expression interface is what we went to great lengths to preserve > with our feature model work (being sure that the same xpath could be > used to navigate the object model and the xml model) We need a nomenclature standard. ;) Property means any of attribute, association, or operation unless we're in Filter land, where it means only attribute. got it. Here's the big question: Do you intend for Filter/Expression to operate on individual range values of a coverage? Or should Filter/Expression be limited to operating on Coverages themselves (not the spatially varying data). Corrolary: Does Filter/Expression operate on "Properties"/attributes which are Lists/arrays, and how are these arrays indexed? > e) you can write code, a BNF is also available yeah, baby. Looking. > > 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? > > > putClientProperty is for exactly what it says in the javadoc - giving > programmers a place to store their > crap so we do not see tones of code with Map<FeatureType,Object>. How is this different than adding an attribute to the FeatureType (and subsequently to all Feature instances)? Is this a mechanism intended to allow freeform annotation of individual Feature Instances? Or to allow Features with different attributes to share a common FeatureType? Is this crap part of the Feature and stored with it? If it's not related to a Feature Property (Attributes, Associations, and Operations), I think it might be best to find another name for it. The "crapKubby" comes to mind. While we're talking about GeoAPI interfaces, can we do a global search and replace? Opperation -> Operation (and lowercase version of same). > > I guess let me start small and slow: how do I call an operation if my > > starting point is an org.opengis.feature.Feature? > > > Yeah! This is a dicussion I have wanted to have with you since February: > AS IT STANDS NOW > ------------------------ > 1. grab the feature type from the feature > 2. navigate through the model to find the operation you want for that > feature > 3. invoke the operation with the feature as the first parameter, and the > remaining arguments following Icky. > WHAT IT SHOULD BE > -------------------------- > 1. grab the feature > 2. feature.invoke( operationName, arg1, arg2, ... ) Yeah baby! When do we get this? This appears to be an easy score. Is there hidden complexity which prevents us from writing a Feature.invoke() method which does the 3-step process in "AS IT STANDS NOW"? > > > [snip] Let's table the discussion of tabular data for now... > >> 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. > > > We can always cheat, simone should of looked at raster symbolizer > perhaps he can answer questions on the subject. RasterSymbolizer is a portrayal concern. We may very well have different implementations of it for a generic grid point coverage and for the special case of 2D data. To be efficient, it probably needs to know the implementation details of a particular coverage implementation. We're probably not going to have just one. To be honest, I'm not thinking that far ahead yet. :) 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
