Hi, The problem with the timestamps come up in the case of the tracks. For waypoints - a point feature - you can store the geographic coordinates in the geometry, and the timestamp as an attributte. But with tracks - which intuitively should be a linestring - you can have timestamps for every and each node, so you can't store that as an attributte. The current implementation of the GPX datastore in the repository extends JTS to use 4 coordinates for every point, so it can store the timestamp along with the geometry, and I could even define a compound CRS with 4 axes (lat, lon, elevation, time), but no other part of the library suports this construct. For example if I try to load a track into udig, it will try to transform it to an other CRS, but that will fail.
My ideas for a solution: - Instead of a linestring, tracks are loaded as series of point features. This way timstamps can be saved. - Just drop timestamps, and add the start time and end time as attributtes. This is the way how Google Earth use GPX files. But this way is only plausible if using as read-only datastore, as it looses information. - I don't really understand "complex features", but if I'm right, with those the two previous solution could be combined: tracks would load as an assosication between a linestring and point features for each node of the linestring. My current opinion is that both the first and second solution should be implemented, and the user should be able to choose between them with hints. Peter Sunburned Surveyor wrote: > 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 >>> 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
