Bryce L Nordgren wrote: > 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. > Got it; do something first - and then do automation.
>> 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. > That said I am not *sure* - would need to read the specifications again. >> 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). > And this is where we need somebody to look at RasterSymbolizer. I *strongly* suspect that they use expression to extract out different bands from a coverage, produce complicated expressions with sine and cosine etc on the way to mapping into a visible RGB color space. We simply must look at RasterSymbolizer before going further (as it is part of the "landscape" we wish to integrate with). So for my question; if not using Expression how do you extract values from a coverage? > Corrolary: Does Filter/Expression operate on "Properties"/attributes which > are Lists/arrays, and how are these arrays indexed? > Yes it does, you can use xpath to grab out values: ie VALUES[12] or VALUES[X] or [EMAIL PROTECTED] VALUES[X*43+Y]. Of course if a coverage is defined by an operation then raster symbolizer must have a way to let us get at that information .... >> e) you can write code, a BNF is also available >> > yeah, baby. Looking. > CSW-2 spec for the BNF, There is a FilterFactory if you want to make java code examples. >> 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? > This crap is part of the FeatureType (at least); The javadocs are very clear that this is not stored. > 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. > putClientProperties and getClientProperties conventions comes from Swing - and the names are kept to make people feel at home. > While we're talking about GeoAPI interfaces, can we do a global search and > replace? Opperation -> Operation (and lowercase version of same). > sorry I am a terrible speller. >> 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. > As I said was waiting for your feedback, since justin and I did not have a need for operations we did not feel it wise to chase this one down until driven by someone with a real problem. >> 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"? > None; you can make the change yourself. We really were just waiting to talk to you. >> 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. > True but it is also a specification; so we want to check what information they provide us when they request data out of the coverage - it may give us some clues. > To be honest, I'm not thinking that far ahead yet. :) > Well let's check - if it does not do any expression (or operation madness) we may be able to shelf have the work/ideas I have brought out for your learning pleasure. 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
