Thanks for the feedback Andrea: Just going to try and sum up where we got to (so I can think about it offline).
-"go further" with description, that is describe what "xpath" expressions would be valid. Q: Would something similar to command completion work? Ie given an xpath expression list the valid next strings? I only ask as that could be done, the result would be similar to TreeModel, and would let us handle recursive structures etc... For an example consider Road and Junction. - "slice" so only some attributes are fetched rather then all of them Cheers, Jody PS. I ment CSW (or CAT) or whatever the silly thing is where Gabriel's BNF form for Filter is defined. > Jody Garnett ha scritto: (hi Gabriel, something for you too hidden in > this discussion). >> Hi Andrea, sorry my coding time is falling behind your feedback! >>> The touted benefits of this are, apparently, that it makes it easier >>> to link whatever data you have already in your application, and that >>> you can write code that mix-ins gt2 parts and "native" parts. >>> >> Yes. >>> Its existance also implies that going the other way, that is, >>> extending AbstractDataStore and building wrappers that implement the >>> Feature interface is too hard. >>> >> This is not the focus of the API - the focus is trying to find at >> least naming conventions we can follow >> when hooking our library up to other content. As stated in the class >> header I have followed Open Web Services >> naming conventions (their is a useful OGC PDF that goes through the >> exercise of defining a "resource" and building an >> open web service around it). > > Never had the time to read it... > >> DataAccess should be viewed as the starting point for a CSW client >> and a GCE replacement. > > CSW? You mean WCS? > >> Building wrappers (making everything look like feature) is not >> desirable in the CSW case, an argument can be made for GridCoverage >> (but that really depends on how things shake out between RobA and >> Bryce near as I can tell from here). > > Here I second Chris, I don't really see a strict need for having an api > that is able to deal with vector and raster data the same way... > > >>> Describing type by returning the "native" type as in Object describe() >>> is useless in my opinion, because it makes it impossible to write >>> generic reading code. >>> >> See GridSource as an example - where a generic description has been >> provided with a specific method. > > It's just the same interface, with slight modification on the comments? > If it has no extra methods, providing the same extras docs in Source > as examples has the same effect. > >> I created a FeatureAccess, FeatureSource2 and FeatureStore2: >> - as a proof of concept to confirm no method name collisions occur >> (there was one) >> - to not let the discussion get abstract (you can see getFeatureType >> is quite happy next to a describe method) >> - provide a second example which more people will be interested while >> we wait for feedback on GridAccess > > I reiterate, I don't like this direction unless it can be turned into > something that we can transition cleanly to. If it just adds tons of > instanceof in our code, it does more harm than good. > Can I recode all udig and geoserver read only stuff to target just > Source? If so good, if not, thumbs down. > >>> Source >>> ------------------- >>> >>> Here we have three content methods: >>> * content() should be removed in my opinion, it's just very little >>> convenience instead of content(Filter.INCLUDE). >>> * content(String query, String queryLanguage) >>> This seems to open the door to Source specific query languages. >>> >> This door is opened by the CSW2 specification, I am only the >> messenger (hoping to use Gabriels code). > > Well, I don't see why we could have the conversion in an external > code and have Source deal with stronly typed Query objects (Query > being at least an opengis Filter and a set of attributes to be > extracted). > >>> Interesting, but how in the world I do ask something using a >>> gt2 Query? Simple answer is, I can't, unless I go thru the >>> hoops of encoding the Query in xml and then decoding it... >>> a very long road for the most straightforward case. >>> >> We will need to steal the CSW2 wording to make this clear. > > Here I do not follow you. > >>> Moreover, I would ask to force every Source implementation to at >>> least >>> be able to properly process a gt2 Query, in order to guarantee >>> a minimum level of generic functionality. >>> >> I am not sure what gt2 Query is, if you mean our Query object I am >> *not* interested, I am doing my best to >> drag the ideas that the interface suggests into the FeatureCollection >> class. > > I've noticed this trend, and failed to see what it buys us, besides > pain fixing the code... > >>> I'd like to have at least content(String[] propertyPaths, Filter >>> filter) >>> Since this returns something which is a black box, property slicing >>> could become a suggestion instead of an order, so if your datastore >>> cannot slice its data (the pojo case) it won't. But at least, those >>> that can will benefit greatly from not having to load all >>> the unecessary properties. >>> >> Okay that is a good concern (surprise Andrea worried about speed!) - >> for content datastore I have left this problem >> firmly in the hands of the implementors of FeatureCollection. I view >> the collection as *lazy* and they can provide their own methods to >> slice the collection down to just the attributes needed. > > This is simply unworkable implementation wise. > Would you do a separate query to the database to retrieve extra columns? > If I do care about speed is because I know you simply can't add > performance after the fact. You can improve details, but if the design > disallows optimizations, there's no way you'll get them back. > You cannot drive design by performance considerations, but at the same > time ignoring it is a secure recipe for disaster. > > Cheers > Andrea ------------------------------------------------------------------------- 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
