Hello, Don't worry, I'm not offended that easily :)
The modules I'm talking about are the GeoTools module structure modules: gt-xml-gpx under modules/unsupported/xml-gpx, providing packages: org.geotools.gpx org.geotools.gpx.bean org.geotools.gpx.binding and gt-gpx under modules/unsupported/gpx, providing packages: org.geotools.data.gpx org.geotools.data.gpx.temporal The first one is the low level access module, the second is the GeoTools/OpenGis interface. Peter Sunburned Surveyor wrote: > Jody wrote: "Landon did I understand your aims correctly?" > > Yes. > > I did'nt realize that a gt-xml-gpx package existed, or I would have > taken a closer look at it. I thought there was only the following > three (3) packages: > > org.geotools.gpx > org.geotools.gpx.bean > org.geotools.gpx.binding > > I was looking here for documentation on GPX related packages: > > http://javadoc.geotools.fr/2.5/ > > Peter wrote: "I think that you give a much greater importance to the > low level access of the file, than you should." > > As Jody stated, I think my approach evolved significant differences as > I began to learn more about your code. It's not that your code was > wrong, its just that I saw room for an alternative. I think the two > approaches probably stems from our different end goals. I think you > had UDig in mind, while I was thinking about what I could do to > support GPX in OpenJUMP. > > I was definitely interested in providing programmer friendly access at > a lower level. This allows different FOSS programs to do with the GPX > entities what they desire. I couldn't do this if I only provided a > GeoTools SimpleFeature implementation from GPX files. > > That's why I figured I should start playing around in a separate > package structure, and in the SurveyOS SVN repository, at least to > start. > > I hope I haven't offended Peter. His code inspired me to work on > supporting GPX for OpenJUMP. I'll complete my little experiment in the > next few weeks and will then have interested programmers take another > look. > > Landon > > > > On Fri, May 23, 2008 at 10:24 AM, Jody Garnett <[EMAIL PROTECTED]> wrote: >> 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
