As I understand it at least part of the motivation for these interfaces is to provide interfaces for the common parts of all GIS APIs. Consider the similarities between GridCoverage, Feature and Topology models.
These interfaces provide a way of obtaining the common information between them. It will also help make the design of future APIs similar since they can all derive from these common interfaces. So from these interfaces you know how to obtain information such as bounds, name, data type etc... Sure there isn't a generic way to access the information but if you consider Feature and GridCoverage... well there is very little commonality when it comes to accessing and processing the data. So this is a higher level I suppose. That's my interpretation. I'm not saying that these are the ideal interfaces necessarily but that is why you see methods like: content( String query, Query language) and content(filter). Both of those are content independent. But the Geotools Query is content dependent. Does this make sense? Jesse On 12-Dec-06, at 9:59 AM, Jody Garnett wrote: > Andrea Aime wrote: >> Nope, when you're rendering you're using just the "flat", simple part >> of it, or you would not be able to use it, no? > no. > > You can actually choose to render your content based on attributes of > things they are related to etc... >>> 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 we cannot "reflect", "inspect" at least the simple properties out >> of that Source thing, then I'm against having it around. >> It just adds confusion and provides little value imho. >> Of course it's a matter that the PMC should discuss, so if mine it's >> the only -1 with two vote sessions you can get away anyways. > You are correct Andrea, and it is important to have this conversation > right now (rather then a vote). It is too late to change things for > the > milestone release; but when we get around to planning we can try > and get > a handle on the problem. > > These interfaces are only the start of the conversation; the next > stage > is to set things up so everyone is happy :-) > > IMHO we will not be able to make everyone happy this time around > (because to do so would be to ask too much - ie FM, update datastores, > complex feature branch salvaged etc...), I would rather ensure we > removed as many obstacles to the FM rollout as possible. > > 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 ------------------------------------------------------------------------- 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
