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/java/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?) 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]/msg07996.html -Justin Sunburned Surveyor wrote: > 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/ > _______________________________________________ > Geotools-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4007,4664a06c249061431913854! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
