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
