Summary: - Bryce is looking at Filter / Expression and the Feature Model - Justin: can you help answer some questions, he will have more then I can keep up with - Simone: can you help us understand RasterSymbolizer, in particular how it knows to call an operation to extract values; and does it use Expression to do any of that?
Bryce L Nordgren wrote: >> 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). > lol - I stand corrected. Or maybe by the stage crawl. >>> We could make a POJO<->Feature adapter which exposes public fields as >>> ...Then we just write Coverage as a POJO and adapt it into the Features >>> > why > I am pretty sure they were just after a quick way to bridge the gap, formally having coverage extend feature seems a better option. Let's move on. > 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. I was casting my mind back to a suggested made back in feb; and then using the words from Sun's "Fortress" language I learned about at OOPSLA. ie. Define operations in reference to "Traits", Trait lists methods and required attributes etc... > 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. > Interesting; I need to balance what you say with what RobA is always talking about (there is considerable overlap). Bah I need to take one of you guys out for beer and sort out what ISO numbers mean what, and which ones we care about. > 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). >> 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? > a) your poor brain 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) 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) e) you can write code, a BNF is also available This spec matters as it is also used for: a) metadata query (by catalog specification) b) feature model property constraints (ie restrictions) c) style layer descriptor, both for engaging rules (ie filter) and extracting values (expression) > 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>. > 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 WHAT IT SHOULD BE -------------------------- 1. grab the feature 2. feature.invoke( operationName, arg1, arg2, ... ) > Mamma, are we there yet? :) > Nope we were waiting for you. >> 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? > Better I know the driver, ... Justin are you around? >> 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. > At some point we need to make the information available to others, the question is in what manner do we do so? >> 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. Thanks again Bryce, Jody ------------------------------------------------------------------------- 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
