Hi Andrea, sorry my coding time is falling behind your feedback! I just need to make sure that working through the DataAccess api does not get lost in these discussions about process. > As I see, you want to provide data in its native format, assuming > that you can build appropriate property accessors in order to play > with whatever is returned. > - check
Other point is I want to learn from what FeatureStore got right, and got wrong, so some of these methods, like getNames(), should be checked against Justin's requirements coming out of the FM branch. > 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). DataAccess should be viewed as the starting point for a CSW client and a GCE replacement. 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). Building wrappers It is at least not needed for the simple case, if wrappers are provided (and the content can be made to look like feature) an application would be able to work with more of our library (say GML generation). > DataAccess > ----------------- > > The interface does not say anything about being able to provide > read only or read write accessors. I see that there's a Store > interface that extends Source, but it's completely empty. > Sorry review was intentended for Simone, the write methods were in the grid coverage example (I have moved them over). Collections are available in read-only and read-write form (with no override of method - which causes such a performance hit currently). > 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. 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 > 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). > 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. > Can't we have a Query interface instead, even an empty one, > that can be implemented in various ways? If jpox likes the > string road, it can have a JPoxQuery implementation with a > string inside. > Andrea we can remove this method if needed, I did consider making a strongly typed QueryLanguage object that would take a String and produce a Filter from it. Perhaps Gabriel can be asked if that is a good idea. > 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'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. > All in all I still prefer to have the datastore forced to be > able and understand a gt2 Query, it's more rich, you can write > more and better generic reading code against it. > See codebase, DataStore still understands Query ... but I am locking down exactly what this means in terms of FeatureCollection methods (using Query to drive the requirements rather then GeoAPI 2.0). > I keep on asking for this because one condition to accept > these in geotools is that we don't need to write code that handles > Source and FeatureSource by two parallel paths, I hope you agree > this would turn into a maintenance nightmare. > Agreed. > For describe(), the same critics as above. > Same response. > setTransaction(t) is a nice addition > > How to avoid double paths? Well, I see two ways: > * have FeatureSource implement Source, DataStore implement DataAccess, > and have the abstract classes we have around provide hooks. This would > leave out in the water people that have implemented FeatureSource > directly. > Have a look in the data module for examples of the above idea - classes marked as @since 2.4 and @deprecated Proposed API etc... > A final requirement is that all developers feel these new interfaces > do provide value to geotools. To us Geoserver/uDig as direct users I > don't see any, but I like the fact that we would allow people to > use both Geoserver and uDig as building blocks that can be added to > existing applications seamlessly. This is something that has been > requested in the past too, and the above seem to be a good way forward. > Cool - thanks Andrea! 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
