That is an approach we take often Peter; for example the gt-wps module is going to offer a "no abstraction" access to a web processing service. Then a high level gt-process module can offer the easier api for Java programmers.
Landon is trying to do something slightly different (ie he has different goals): - he wants a low level data access api that he can share with other communities - he wants to layer the high level geotools datastore api on top of it Landon did I understand your aims correctly? Jody > Hello, > > I think that you give a much greater importance to the low level access > of the file, than you should. I'm not a GeoTools expert, but my > understanding is that the point in the whole thing is to generalize the > way the data could be accessed. This is why I didn't care about names of > propertyes, but let them reflect to the element names in the file (wpt, > trk, rte). Also, the gt-xml-gpx module is the low level access modul, > that parses the file into java objects, and vice versa, and there is a > gt-gpx module, which supports the GeoTools data access interface > implementations, and translates between the low level gpx java objects, > and higher level GeoTools/OpenGis objects (FeatureType, Feature). > > GIS applications, in my opinion, generally don't need to know what type > of data source they are using. This is one advantage of using a toolkit > like GeoTools. You could open a wide selection of GIS datasources, and > hadle them the same way. So why would anyone need direct access to the > low level GPX objects? > > Anyways, I don't say that my implementation of the low level part is the > only/best way to do it, but I don't see the point in the design > considerations and modifications you made. > > Peter > > Sunburned Surveyor wrote: > >> You can find my experimental GPX code here: >> >> http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/gpx/src/ >> >> The code is documented or unit tested yet, and some of the methods are >> stubs. I'm fooling around with some techniques for accessing and >> managing GPX that are a little different from the ones Peter chose. >> Some of these differences are listed below: >> >> - My initial reader and writer will be based on JDOM. >> - I'll be supporting the extensions element via the JDOM Element object. >> - I'll be supporting the time element via the Joda DateTime element. >> - I'm using "user friendly" names like getRoute instead of getRte, or >> getWaypoint instead of getWpt. >> - I'll be providing low-level access to the entities stored in a GPX >> file. This means you could use this code to convert a GPX file into a >> DXF file or SVG file without dealing with any Feature object, for >> example. Another example is the ability to get at the raw double >> values representing the ordinates of the GPX file bounding box without >> dealing with an Envelope class from GeoTools. (This access will be >> provided at a higher level for GeoTools clients.) >> - I'll be providing access to GPX entities as DataObjects. This access >> will be provided one level "below" the access that I will provide to >> GPX entities as implementations of org.geotools.feature.SimpleFeature. >> This will allow programs like OpenJUMP to access GPX files without the >> need to deal with the GeoTools feature model. >> - I'll be supporting access to a representation to GPX files as some >> sort of GeoFileResource class. This will allow client code to query a >> directory containing GPX files for all the GPX files by the same >> author, after a certain date, or within a particular envelope. >> >> All of these ideas are very preliminary, but I thought I would throw >> them out for discussion. I'm sure Peter will have some comments. My >> main challenge will be implementing the higher level of the library, >> in which I will need to allow access to a SimpleFeature implementation >> in the "GeoTools way" (likely trough a DataStore). >> >> Landon >> >> P.S. - I was looking for a DataStore implementation in Peter's code, >> but didn't see it in the Javadoc for the three GPX packages. Is it >> related to the org.geotools.gpx.bean.ObjectFactory class? >> >> ------------------------------------------------------------------------- >> 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 > ------------------------------------------------------------------------- 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
