Sunburned Surveyor wrote: > Paul wrote: "Here are the requirements I have. > Here are the requirements I had: - http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Design+Discussion
Each "aspect" has a discussion and happy little icons.... This should answer some of your questions.... > Ids can be any type not just an int > Yes - can be backed onto anything (or several somethigns) but is made available as an opaque feature id > Properties can contain complex objects including other features or POJO > Yes, (we had the need for all three subclasses of property: attributes, associations and operations) > Properties can contain a collection (List or Set) value > Nope - we ended up doing this as repeating properties with the same name. When you use query on the Feature you get a List or Set. The factory here is when repeating groups of attributes have order that is significant to the application. > Features don't have to have a schema (useful when transforming a > feature from one schema to another) " > Bingo - and also importantly Features do not have to be valid against there Schema (also important). > 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. > Well settled on; and doing the work are too different things :-) We welcome collaboration ! I will point out that we are making use of GeoAPI for the feature model; as it already has the policies in place for inter project communication (and a formal review process). GeoTools is about implementation (and getting the job done) - we also like to leave the interfaces up to the experts. > 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. > Cheers, Jody > 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 > ------------------------------------------------------------------------- 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
