[Geotools-devel] DataAccess review

[Jody G. <jga...@re...>]

Thanks for the detailed feedback Andrea going to try to field these 
quickly before my workday...
> 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.
>   
Indeed this is where I wanted to talk to someone - but we place the 
topic at the end of the meeting agendas :-(
> 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.
>   
We can write generic reading code (expression), but you are correct we 
cannot determine what those expressions should look like without prior 
knowledge. That prior knowledge can be provided in the form of an SLD 
file, but we still need a solution.

The solution is a model, which one? Well some options were listed.
> Something using this simply cannot be added to Geoserver, and it's a
> shame, because it would be nice to be able and serve pojo out of it, no?
>   
It would but you are going to need a lot more, namely to take on the 
model problem in a responsible enough fashion to do transformations 
between model descriptions. Aka UML to GML, ISO to UML to GML etc...
> What I'm thinking is, if you can provide property accessors to your
> "content", then you can also sum up all the conceivable property 
> accessors for your type and make something that looks like a FeatureType 
> out of it, no?
>   
Well I could, but we are serving up rich content here - so the result 
does not look like FeatureType, it looks like a schema of FetureTypes 
with relationships etc...
> Why, instead of simply returning a useless "Object", can't we return
> something that implements an interfaces that _looks like_ Feature type?
> Maybe something that can list all "simple" properties around, those that
> geotools is able to handle at the moment, and a default geometry.
> Or, as a second alternative, provide services that turn these object
> description into something that can be understood at the geotools
> api level without any external intervention?
>   
An implementation can do all these things, an implementation that is 
close is on the FM branch.

Andrea GeoServer (and generating GML) is not my only concern here; I 
would like to open the door to rich content beyond our feature model. 
Since we have failed to produce one (and something like EMF seems to be 
taking over) it seems best to sit on the sidelines.
> If I know what the properties are I can conceivably write a WFS 
> DescribeFeatureType response, and a GetFeature too (more on this later
> thought), turning the value of this proposition into something that
> can be accepted in gt2 and provide value too.
>   
Not sure there is any solution other then "knowing what the properties 
are", aka an improved feature model.

So checkpoints:
- similar to DataStore - yes
- could be used to serve up Features - yes, DataStore extends DataAccess 
would be a step for GeoTools 2.5

Questions:
- Metadata - can we use this to describe a catalog? That is content is 
Collection<Record> and describe Metadata
- GridCoverage
- etc...

Jody