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
