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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
