Hrm; so you noticed that the "parser" was okay for GPX? And it was only the one time use technology used to generate the beans that could be done again? Hopefully the your question about FileGeoResource is related to something else...
Have a look at the unsupported/referencing module; but be advised I am probably just going to remove it as a failed experiment in working between GeoServer and uDig. The goal of that module is to offer implementors a bit of help holding all their "DataStore" like stuff in a local repository; so they don't create dupicate connection pools to databases; or open the same file up twice etc... I trust you guys will sort out what is going on GPX; not sure I am following what is going on. Jody > Thanks for the info Jody. I like the name "FileGeoResource". I'll > incorporate it into my GPX code and will also make it available as a > generic class. Can I find an existing FileGeoResource in the UDig > source code? > > Landon > > On Mon, May 19, 2008 at 2:15 PM, Jody Garnett <[EMAIL PROTECTED]> wrote: > >> There is, but it is kind of from the uDig project ... we had the concept of >> a Registry which contained Services and GeoResrouces. that would be >> subclassed to represent a FileService / FileGeoResource if needed. >> >> But basically GeoSrever and uDig both run their own abstraction at this >> level; using GeoTools as needed when actually getting around to talking to >> the data. >> >> For the case of your GPXFile that would be an implementation detail inside >> your GPXDataStore, you can see something similar in ShapefileDataStore when >> they break out an AttributeReader for each of the files they are working >> with. We need experiment with making these kind of details available early >> on (with the hopes of doing Joins) but there was not much interest in it. >> >> Cheers, >> Jody >> >> Sunburned Surveyor wrote: >> >>> I'm wondering if there is a way to represent data files that are a >>> source of features. I'm not really talking about the DataStore >>> interface, but something similiar that is slightly LESS abstract. I >>> just want a generic interface that could represent actual files (not >>> streams or databases) that can be a source of SimpleFeatures. I'd like >>> to create a class that can represent GPX files on a computer, and if >>> there is such an interface I would like to implement it. >>> >>> (I searched the 2.5 Javadoc, but didn't see a class or interface like >>> this.) >>> >>> Does such a class or interface exist? Has it been considered? >>> >>> Perhaps I should post an example of the GPXFile class so we could >>> discuss what, if any, of the methods might be moved to this interface >>> I describe? >>> >>> Landon >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >> ------------------------------------------------------------------------- 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
