Everytime I think I am close to understanding I get more confused. :] Jody wrote: "Are you sure you want to do this?"
Not after reading your last post to this thread... Jody wrote: "The reason I ask is the factory may be provided to you by the end users; perhaps they have a specific implementation of Feature they would like you to create (you can do this to have POJOs that implement the Feature interface created for example). If your data store ignores these settings you close the door on that kind of functionality." Whoa! I never thought about that. It is an intriguing idea, but also sort of twisted. In OpenJUMP all of our "readers" provide an implementation of Feature, which is like the GeoTools interface. I can't imagine anyone wanting something less from an OpenJUMP reader. ...But when I think about GeoTools I realize that people might want all types of different feature implementations from GPX files read by my code. (See, I'm already starting to think "GeoTools" instead of OpenJUMP.) After reading your last post (and benefiting from the light bulb clicking on) I think I will do the following: - Provide DataObjects that can be sucked into a FeatureFactory provided by client code to create any number of Feature implementations. I was going to do that anyways, but now I understand most client code in GeoTools is going to want the raw data as a DataObject, or even one step lower, as a GPX entity. At first I thought they would only be interested in an implementation of SimpleFeature. They acutally could want to use my code at a lower level to create their own implementation of SimpleFeature. - I'll provide my own implementation of SimpleFeature that adds some GPX specific behavior. The only reason I can think it would be worthwhile to create SimpleFeatureImpl objects from my code is if UDig can't handle a custom SimpleFeature implementation. Do you have any thoughts on this? Landon On Thu, May 22, 2008 at 2:26 PM, Jody Garnett <[EMAIL PROTECTED]> wrote: > Sunburned Surveyor wrote: >> >> Jody, >> >> I need to follow up on my earlier question about a SimpleFeature >> implementation. I'm really looking for the object that I would create >> to represent a GPX entity like a waypoint as a SimpleFeature. So in >> some sense I'd actually be trying to implement FeatureFactory. >> > > Are you sure you want to do this? The reason I ask is the factory may be > provided to you by the end users; perhaps they have a specific > implementation of Feature they would like you to create (you can do this to > have POJOs that implement the Feature interface created for example). If > your data store ignores these settings you close the door on that kind of > functionality. > > That said lets see what you have to work with; lets check out what > implements SimpleFeature... > > SimpleFeature > - DecoratingFeature - used to wrap around an origional feature and add > functionality > - ResultSetFeature - probably for JDBC? > - SimpleFeatureImpl - a good choice for your needs > -- BaseFeatureCollection > -- DefaultFeature - our old feature implementation (is listed here as well > supporting the new interface for migration purposes) > -- MutableFIDFeature - used for datastores like WFS that explicitly need to > set the ID of the feature (usually during a commit?) > - TransactionStateDiff.NULL - a singleton used to indicate lack of a feature > >> Maybe it would make sense to create my own implementation of SimpleFeature >> called GPXSimpleFeature that could support behavior unique to GPX entities? >> > > That is totally an option for you; do what you think is best. I would ask > that you actually wrap it up in a SimpleFeatureFactory so that others can > use it to create "GPX entities" (say from oracle XYZM data). >> >> Please share with me your thoughts. >> > > I would recommend using SimpleFeatureImpl as long as you can get away with > it; over the next couple of weeks I expect to see more Feature > implementations made available (we had an "array" based one that was fast; > and now that geoserver is going into a optimization run I expect to see more > examples along those lines). > > Cheers, > Jody > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
