Peter, You wrote: "So if I might suggest a path how to get involved, there is a much more GIS related problem with the GPX datastore, than the xml parsing. It is the temporal capabilities, that is only very coarsly supported by geotools (and I guess by any other GIS toolkit), and makes it hard to integrate the datastore into uDig, with being able to maintain integrity of the original data after a save."
Could you clarify this a little bit for me? What temporal capabilities would you like to see added to the GeoTools support for GPX? Do you have any specific examples? I was considering the use of Joda to support the timestamp element of Waypoints, Routes, and Tracks... Landon On Mon, May 19, 2008 at 2:09 PM, "Bolla, Péter" <[EMAIL PROTECTED]> wrote: > Hi, > > I just read this thread, and as the "owner" of the code I would clarify some > points :) > > First, what I meant by "Though Justin said that even he doesn't use > that now, but an other way." in my answer to Landon, is that the method, how > I _generated_ the beans were outdated, but as far as I know, not the parsing > method itself. Now the parsing module (gt-xml-gpx) depends only on gt-core, > and the xml parsing is done by the JDK. (Originally I wrote a pull parser > implementation too, but for reducing dependencies, I droped that, in favor > of this one.) Justin might be able to provide more information on pros and > cons. > > So if I might suggest a path how to get involved, there is a much more GIS > related problem with the GPX datastore, than the xml parsing. It is the > temporal capabilities, that is only very coarsly supported by geotools (and > I guess by any other GIS toolkit), and makes it hard to integrate the > datastore into uDig, with being able to maintain integrity of the original > data after a save. > > > Peter > > > Sunburned Surveyor wrote: >> >> I'm starting to see more of the puzzle now, based on your comments. >> >> I think JAXB might be overkill at this point. I don't really need a >> binding framework. I think I might use JDOM initially, although I know >> this will impose a RAM limitation on the size of the GPX files that >> can be supported. However, I don't think a GPX file will be as large >> as data stored in most other formats, like SHP or DXF. This is because >> GPX was really created for recreational grade GPS recievers. Most of >> them store only a few hundred waypoints. >> >> At any rate, I can swap out JDOM with an XML pull parser in the future. >> >> I won't need JDOM if I can get Paul's stuff to work, but I think I may >> run into trouble resolving some of his dependencies. We'll have to >> see. >> >> Landon >> >> On Fri, May 16, 2008 at 3:40 PM, Jody Garnett <[EMAIL PROTECTED]> >> wrote: >>> >>> Sunburned Surveyor wrote: >>>> >>>> Jody wrote: Interesting; do you know what parser Peter was using? >>>> >>>> I should have included an excerpt of my conversation with Peter. Here it >>>> is... >>>> >>>> Landon asked Peter: Thanks so much for taking the time to respond! I >>>> look forward to working on the GPX module for GeoTools. I've got a quick >>>> question for >>>> you to begin: >>>> >>>> How did you handle the actual parsing of the GPX xml file to produce >>>> the org.geotools.gpx.bean package? Did you use an xml binding >>>> framework like Castor? >>>> >>>> Peter answered: I did it in the way described here: >>>> http://docs.codehaus.org/display/GEOTDOC/XML+Developers+Guide with >>>> some help from Justin. Though Justin said that even he doesn't use >>>> that now (or at least last August), but an other way. And after the >>>> code generation I edited some parts by hand too, so as it is now, it's >>>> not programmatically reproduceable. >>>> >>> So if I fill in the blanks; it looks like justin has started making >>> EObjects >>> for the data model; and using a single "binding" class (that uses >>> reflection) for the parser configuration; we are doing something similar >>> for >>> WPS. If GPX is a simple format then this is over kill (but fun), if you >>> plan >>> to embed mixed content into it then you may wish to continue with the >>> binding idea. >>> >>> The "binding" framework in geotools; is related to but not the same as >>> Castor; the bindings are to specific xml elements it is true; but the >>> parser >>> looks at the schema information in order to handles cases (like GML) >>> where >>> someone has extended base elements (like Feature). >>>> >>>> Jody wrote: "If you do bring Paul's code over make sure we have >>>> permission >>>> to; or publish the jar to the maven repository etc..." >>>> >>>> I already talked to Paul about this and got his permission. I'll likely >>>> incorporate his Java files directly, instead of using a separate JAR >>>> file. >>>> >>> Sounds fine. The metadata module has started using JAXB, so if that is >>> an >>> option for you it may be fun? And would save another xml tech getting in >>> the >>> mix. >>>> >>>> Paul did mention his code was released under the Apache license. Will >>>> I need to get it under the LGPL if I want to include his source files >>>> directly in my module? If I package them in a separate JAR on which my >>>> module depends, can they stay under the Apache license? >>>> >>> Good questions; I think we will need a bit of research to answer. >>>> >>>> I think Paul is pretty flexible on this issue. I want to do what is >>>> easiest. >>>> >>>> >>> Easiest is he signs a contributor agreement. >>> Jody >>> >> >> ------------------------------------------------------------------------- >> 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
