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
