Thank you for giving us that advice David. The Sunburned Surveyor
On 6/7/07, David Zwiers <[EMAIL PROTECTED]> wrote: > 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
