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 > Geotools-devel@lists.sourceforge.net > 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
