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 ------------------------------------------------------------------------- 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
