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. One of the best thing about JUMP is that it has a simple Feature model and that it works!!! If you want to move to a more complex model you should be aware that you may end up losing simplicity and 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. If you want to use GT DataStores, you could write a simple adapter that converts between their Feture model and JUMP on the fly.
Bye Paolo Rizzi > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto di > Sunburned Surveyor > Inviato: martedì 5 giugno 2007 1.29 > A: List for discussion of JPP development and use. > Cc: Geotools-Devel list > Oggetto: Re: [JPP-Devel] Common Feature model > > > There is almost too much good stuff going on around here to > keep up with. :] > > Paul wrote: "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." > > You should definitely get more involved with the GeoTools folks. We > had some pretty extensive discussion about this very issue not to long > ago on this mailing list. Some of the GeoTools folks participated, as > did Frank Wammerdam. (Frank is no longer subscribed.) > > I think we identified some of the reasons why adopting the GeoTools > feature model into OpenJUMP at "one time" isn't practical. However, we > had some general agreement that it would be good to move OpenJUMP > towards using the GeoTools feature model as we move forward. > > I will be using the GeoTools feature model in my FeatureCache > implementation, which will allow me to store features from and data > source for which there exists a GeoTools driver. One of my goals in > the use of the GeoTools feature model in this project was to see how > well it will play with OpenJUMP. It will give me a chance to get to > know the GeoTools code that is involved, and will help me identify > challenges that exist in our eventual migration of OpenJUMP to the > GeoTools feature model. > > A key first step in making this migration is creating an class that > can convert between GeoTools Feature objects and JUMP Feature objects. > Edgar Soldin has already done some work in this area and I hope to > continue it. > > In summary, we are a long ways towards sharing a common feature model > with UDig, but I think we are starting to explore that possibility > with some concrete steps. I think there is wisdom in this, because "if > the open source GIS community can agree on a single in memory Java > representation for geographic features" it will be the one in > GeoTools. > > Paul wrote: "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) " > > I'm almost positive that the GeoTools folks have already considered > many of these issues. In the end developers have to find the balance > between the ultimate flexibility and a system that can be used. By its > very nature a system must have some structure to be usable, and > structure means constraints. For example, the most flexible way to > represent geographic features in Java would be to just have them > extend of the Object class. But that doesn't do anyone a lot of good, > does it? > > You need to be able to assume some things about the Feature you are > working with, and that means it has to obey some rules. I think it > would be foolish to debate again what has already been debated by some > of the smart folks at GeoTools. I think they must have good reasons > for settling on the feature model they chose. > > I really don't think the best solution is significantly changing > OpenJUMP's feature model, but adopting and then working to improve the > GeoTools feature model. > > The Sunburned Surveyor > > > > On 6/4/07, Paul Austin <[EMAIL PROTECTED]> wrote: > > The reason I was thinking of Object type for Ids is that > then you could use > > a Long, Integer or String for the feature ID depending on > the type of data. > > I normally use Long but some models may use String based > globally unique > > ids, I wouldn't want to use String for numeric fields all the time. > > > > On the schema issue, I still like to have a schema > associated with a feature > > but not making it mandatory, having the schema there allows > you to do > > validation on the feature to make sure it conforms to the > schema (e.g. type > > and allowed values for enumerations). > > > > When I'm looking at a feature model I'm looking at it for > passing around in > > a processing pipeline for transformation, spatial > processing and validation > > rather than just for the display in JUMP. > > > > Paul > > > > > > Michaël Michaud wrote: > > Hi Paul, > > 1. Do you really need Object type for ids (I think ids are Strings > > in > GeoTools - don't know if there is performance penality compared to int > > > ids, or some cases where a genaral Object type is needed) > 2/3. If I can > > remember, GeoTools complex feature model fulfill 2 and 3 > requirements, and > > define a subclass (SimpleFeature ?) looking like > jump's feature model (more > > or less) > 4. I already thought that a feature should't have a schema. > > > Fundamentally, I think a feature is like a map with attribute/value > pairs, > > and that feature schema belong to the feature collection level. > It would be > > interesting to know why jump's designers have choosen to > include a > > featureschema reference in each feature. > > Michaël > > Paul Austin a écrit : > > > > 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. > > 1. Ids can be any type not just an int > 2. Properties can contain > > complex objects including other features > or POJO > 3. Properties can contain > > a collection (List or Set) value > 4. 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 > > > > > > > -------------------------------------------------------------- > ----------- > > 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 > ------------------------------------------------------------------------- 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
