Just a quick 2 cents -- Geoapi is very complex and should be avoided within Jump. The added complexity will only confuse developers, increasing there frustration creating workable solutions.
We would also need to keep a fork of the code as these interfaces change all too frequently -- at which time we have already thwarted the goals that were set out, so we might as well save the developer effort ... David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Atkinson Sent: June 4, 2007 6:08 PM To: Justin Deoliveira Cc: List for discussion of JPP development and use.; Sunburned Surveyor; Geotools-Devel list Subject: Re: [JPP-Devel] [Geotools-devel] Common Feature model good one, Justin. Justin Deoliveira wrote: > Hi, > > A common java feature model would be great. This is essentially what the > geoapi project strives to achieve. > > http://sourceforge.net/projects/geoapi/ > > > Last year a couple of developers took a run at the interfaces for a > feature model that definitely meets the requirements you list below. You > can look at the interfaces here: > > http://geoapi.svn.sourceforge.net/viewvc/geoapi/trunk/geoapi/src/main/ja va/org/opengis/feature/ > > The simple package is where you probably want to focus most of your > attention. The model is somewhat verbose and a bit intimidating. But the > point of the simple package was to develop interfaces that people coming > from the current geotools model, or the JUMP feature model would > understand and could work with. > > We also were able to get a geotools implementation to turn over. That > implementation is currently being used as a base for the "complex > features project" in GeoServer. > > http://docs.codehaus.org/display/GEOS/Complex+Datastore > http://docs.codehaus.org/display/GEOTOOLS/Community+Schema+Road+Map > > (Rob,Gabriel: is there a link to any more recent docs?) > > I've just re-established editing rights, and want to update where we are at, but essentially we have a vastly improved, from the ground up approach supported by a real schema parser. This means that we have a way to create the in-memory model from an external configuration, which would be necessary to share in-memory features between different application layers. The reality is that neither the persistence schema (database metadata) or the XML schema (community schema) hold all the information - often a schema will have abstract types that instances should realise with a specialised equivalent. I.e. the community schema is an interface, the configured featureType is an implementation. Keeping these concerns neatly separated is the key. IMHO there is scope for an extra configuration layer here - a "profile" that contains hints about how to interpret the schema, and this would allow in-memory features to be realised in a consistent way. > Another bit of info you may find interesting is summed up here, it is > essentially an annuncement that we got some funding to support getting > the geoapi feautre model fully implemented on geotools trunk. > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg0799 6.html > > We need to have a transition plan from the project just winding up into this one - what can we do to help? Rob Atkinson ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
