From: Sunburned S. <sun...@gm...> - 2008-05-23 20:01:32
|
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 <jga...@re...> 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 >>> Geo...@li... >>> 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 >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > |