Paolo, Thank you very much for your input. You make some very good points, and some of these same points were brought out in our earlier discussions on this topic.
Paolo wrote: "Maybe the situation has improved in the last year or so, but one of the reason why we decided to abandon uDig and GeoServer was indeed the GeoTools Feature model. They keep changing it, adding more and more new functionalities, without bothering for stability...About using GeoTools DataStores (aka drivers) to access data, that was one other reason why we abandoned it. DataStores for PostGIS and Oracle had many bugs, but no one cared to fix them. And the changing Feature model prevented us to fix them on our own, without wasting a lot of time keeping in sync with the changes." I think we can all agree that there are some issues with how the GeoTools Feature Model is managed. I have decided, at least for the time being, to try and work with the developers at GeoTools to correct these issues. I'm going to start incorporating the GeoTools feature model in my own work when I can, and I'm going to scream bloody murder whenever they change the public API. I think part of the problem with GeoTools is that they don't have enough "end users" of their API that are willing to pitch a fit when the continue to change things. I plan on being that end user. :] My goal is to help GeoTools change the way they manage their feature model for the better. I realize this will not be easy, but I think it is worth the effort. Paolo wrote: "If you want to move to a more complex model you should be aware that you may end up losing simplicity and stability." I really agree with you strongly on this. I worry about changing what is a really simple feature model. It's easy to use and understand. Look at what happened when they moved from GML 2 to GML 3. I think we could run into the same type of problems if we aren't careful. Paolo wrote: "If you want to use GT DataStores, you could write a simple adapter that converts between their Feture model and JUMP on the fly." I'm already planning on this. Jody Garnett has pointed me to some documentation that explains part of what I need to know about the GeoTools feature model. I also was told about some code by Edgar Solding that could convert between GeoTools Features and JUMP Features. I'm going to look at this closely in the next few weeks. (If I can ever stop reading and responding to all of these e-mails.) :] Jody Garnett has been very supportive of my efforts to start using GeoTools in OpenJUMP. I really want to see if we can get a good working relationship with the GeoTools community because I think we have the opportunity to share a lot of code if we play our cards right. If for some reason this effort at collaboration doesn't work out I think we will need to give some serious thought to splitting out some of JUMP's code into a reusable library that can compete with GeoTools. I believe it is pretty difficult for newcomers to use parts of JUMP's code base without confusion. This is one advantage of GeoTools that we will need to address if we don't want to hop into bed with them and plan on being a valid alternative to what they offer. (This should be a last resort for us. I believe the colloboration with GeoTools is going to work well in the long run.) The Sunburned Surveyor On 6/5/07, P.Rizzi Ag.Mobilità Ambiente <[EMAIL PROTECTED]> wrote: > > IDs can be multi fielded too. > > Bye > Paolo Rizzi > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > conto di Paul Austin > Inviato: martedì 5 giugno 2007 0.36 > A: List for discussion of JPP development and use. > Oggetto: [JPP-Devel] Common Feature model > > I agree if the open source GIS community can agree on a single in memory > Java representation for geographic features that would make all the tools > more interoperable. Right now I'm using my own schema and feature model but > would prefer not to maintain that in the future. Here are the requirements I > have. > > > Ids can be any type not just an int > Properties can contain complex objects including other features or POJO > Properties can contain a collection (List or Set) value > Features don't have to have a schema (useful when transforming a feature > from one schema to another) > > Paul > > > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- 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
