Loading ...
Sorry, an error occurred while loading the content.

Representation of time in track logs

Expand Messages
  • davewissenbach@yahoo.com
    - Time will be expressed in UTC, which seems to be expressed in XML like this: 20001108T093014Z (that s Nov 11, 2001, 09:30:14 UTC) Reference:
    Message 1 of 16 , Sep 27, 2001
    View Source
    • 0 Attachment
      - Time will be expressed in UTC, which seems to be expressed in XML
      like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
      Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445

      This guiding principle for the representation of time is OK for a
      waypoint, but I think that it lacks precision for a track log where
      someone desires to measure speed. So I suggest that this <date-time>
      element (or attribute?) be part of a waypoint, track header, and
      route, but that a track log be allowed an additional optional time
      element which is a decimal offset, in seconds, from the base time.
    • Chris Wilder-Smith
      Dave, I agree with the concept of using a time offset in the track logs. It almost seems to me that there has to be a different waypoint element for use in
      Message 2 of 16 , Sep 27, 2001
      View Source
      • 0 Attachment
        Dave,

        I agree with the concept of using a time offset in the track logs. It
        almost seems to me that there has to be a different waypoint element for
        use in tracklogs than in routes or as standalone waypoints if you want
        to have support for validating the XML. The question is how would you
        handle this DTD-wise? The easy way is to make it all optional, but that
        puts more requirements on the parser side. I personally think that
        tracks are different enough from routes that they should be explicitly
        different elements. Something like this:

        <track>
        <point> <!-- initial point -->
        <time>20010927T093014Z</time>
        <lat>42.34567</lat>
        <lon>-71.34567</lon>
        <alt>57.234</alt>
        </point>
        <track-point>
        <time-offset>12.34</time-offset>
        <lat>42.456789</lat>
        <lon>-71.456789</lon>
        <alt>57.234</alt>
        </track-point>
        ....
        </track>

        Where a route is built of all <point> elements. You still run into the
        problem, DTD-wise where <time> should be optional in a route or waypoint
        and you need it in the track for the initial point. You could make it a
        separate element of track for the initial time and deal with duplicate
        information where the optional time used in the initial <point> could be
        ignored by the parser. That seems like it might be a better solution,
        DTD and parser wise.

        What do you think?

        Regards,

        Chris

        davewissenbach@... wrote:

        >- Time will be expressed in UTC, which seems to be expressed in XML
        >like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
        >Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445
        >
        >This guiding principle for the representation of time is OK for a
        >waypoint, but I think that it lacks precision for a track log where
        >someone desires to measure speed. So I suggest that this <date-time>
        >element (or attribute?) be part of a waypoint, track header, and
        >route, but that a track log be allowed an additional optional time
        >element which is a decimal offset, in seconds, from the base time.
        >
        >
        >
        >To unsubscribe from this group, send an email to:
        >gpsxml-unsubscribe@yahoogroups.com
        >
        >
        >
        >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >
      • randyday@yahoo.com
        Is the offset from the last point or from the initial point? When does it wrap? Wouldn t it be simpler to just use a time format that has adequate precision?
        Message 3 of 16 , Sep 27, 2001
        View Source
        • 0 Attachment
          Is the offset from the last point or from the initial point? When
          does it wrap? Wouldn't it be simpler to just use a time format that
          has adequate precision? This would make parsing much easier and track
          manipulation much easier...say for example turning a track into a
          back-track route. It also makes each data element much more self-
          describing, which is a worth-while goal.

          --- In gpsxml@y..., Chris Wilder-Smith <chris@w...> wrote:
          > Dave,
          >
          > I agree with the concept of using a time offset in the track logs.
          It
          > almost seems to me that there has to be a different waypoint
          element for
          > use in tracklogs than in routes or as standalone waypoints if you
          want
          > to have support for validating the XML. The question is how would
          you
          > handle this DTD-wise? The easy way is to make it all optional, but
          that
          > puts more requirements on the parser side. I personally think that
          > tracks are different enough from routes that they should be
          explicitly
          > different elements. Something like this:
          >
          > <track>
          > <point> <!-- initial point -->
          > <time>20010927T093014Z</time>
          > <lat>42.34567</lat>
          > <lon>-71.34567</lon>
          > <alt>57.234</alt>
          > </point>
          > <track-point>
          > <time-offset>12.34</time-offset>
          > <lat>42.456789</lat>
          > <lon>-71.456789</lon>
          > <alt>57.234</alt>
          > </track-point>
          > ....
          > </track>
          >
          > Where a route is built of all <point> elements. You still run into
          the
          > problem, DTD-wise where <time> should be optional in a route or
          waypoint
          > and you need it in the track for the initial point. You could make
          it a
          > separate element of track for the initial time and deal with
          duplicate
          > information where the optional time used in the initial <point>
          could be
          > ignored by the parser. That seems like it might be a better
          solution,
          > DTD and parser wise.
          >
          > What do you think?
          >
          > Regards,
          >
          > Chris
          >
          > davewissenbach@y... wrote:
          >
          > >- Time will be expressed in UTC, which seems to be expressed in
          XML
          > >like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
          > >Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445
          > >
          > >This guiding principle for the representation of time is OK for a
          > >waypoint, but I think that it lacks precision for a track log
          where
          > >someone desires to measure speed. So I suggest that this <date-
          time>
          > >element (or attribute?) be part of a waypoint, track header, and
          > >route, but that a track log be allowed an additional optional time
          > >element which is a decimal offset, in seconds, from the base time.
          > >
          > >
          > >
          > >To unsubscribe from this group, send an email to:
          > >gpsxml-unsubscribe@y...
          > >
          > >
          > >
          > >Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
          > >
          > >
          > >
        • Chris Wilder-Smith
          Randy, I think it might make sense to have a higher precision timestamp in some cases. At least a tenth of a second seems reasonable. Offsets in the track log
          Message 4 of 16 , Sep 28, 2001
          View Source
          • 0 Attachment
            Randy,

            I think it might make sense to have a higher precision timestamp in some cases.  At least a tenth of a second seems reasonable.  Offsets in the track log are nice because you can easily determine leg speed and compute averages without having to deal with a full timestamp each time. I would give the offset from the previous point, versus as a cumulative value from the initial point.  

            In my vision of things, a route wouldn't have times associated with it, but if you were to go in that direction (for instance to give time estimates for a back track, you'd have the offset associated with the point available).  When you get down to it, all the manipulations will happen on data structures in memory and whatever calculations are needed can be done as the document is parsed and the object representation is built.  There are probably three different rules you could use for making these decisions - what's easiest for a program to output, what's easiest for a program to read in, or what's easiest to use directly for whatever calculations are likely.   I guess that my initial opinion was to optimize for the particular calculations that I envisioned.  A question we need to ask is for which scenario should we optimize? After we decide on that, and the follow on questions that answer implies, we'll have an easier time on the design of the markup.

            Regards,

            Chris

            randyday@... wrote:
            Is the offset from the last point or from the initial point? When 
            does it wrap? Wouldn't it be simpler to just use a time format that
            has adequate precision? This would make parsing much easier and track
            manipulation much easier...say for example turning a track into a
            back-track route. It also makes each data element much more self-
            describing, which is a worth-while goal.

            --- In gpsxml@y..., Chris Wilder-Smith <chris@w...> wrote:
            Dave,

            I agree with the concept of using a time offset in the track logs.
            It 
            almost seems to me that there has to be a different waypoint 
            element for 
            use in tracklogs than in routes or as standalone waypoints if you 
            want 
            to have support for validating the XML.  The question is how would 
            you 
            handle this DTD-wise?  The easy way is to make it all optional, but 
            that 
            puts more requirements on the parser side.  I personally think that 
            tracks are different enough from routes that they should be
            explicitly 
            different elements.  Something like this:

            <track>
            <point> <!-- initial point -->
            <time>20010927T093014Z</time>
            <lat>42.34567</lat>
            <lon>-71.34567</lon>
            <alt>57.234</alt>
            </point>
            <track-point>
            <time-offset>12.34</time-offset>
            <lat>42.456789</lat>
            <lon>-71.456789</lon>
            <alt>57.234</alt>
            </track-point>
            ....
            </track>

            Where a route is built of all <point> elements. You still run into
            the 
            problem, DTD-wise where <time> should be optional in a route or 
            waypoint 
            and you need it in the track for the initial point.  You could make 
            it a 
            separate element of track for the initial time and deal with 
            duplicate 
            information where the optional time used in the initial <point> 
            could be 
            ignored by the parser.  That seems like it might be a better 
            solution, 
            DTD and parser wise.

            What do you think?

            Regards,

            Chris

            davewissenbach@y... wrote:

            - Time will be expressed in UTC, which seems to be expressed in 
            XML 
            like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
            Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445

            This guiding principle for the representation of time is OK for a
            waypoint, but I think that it lacks precision for a track log
            where 
            someone desires to measure speed. So I suggest that this <date-
            time> 
            element (or attribute?) be part of a waypoint, track header, and 
            route, but that a track log be allowed an additional optional time
            element which is a decimal offset, in seconds, from the base time.



            To unsubscribe from this group, send an email to:
            gpsxml-unsubscribe@y...



            Your use of Yahoo! Groups is subject to
            http://docs.yahoo.com/info/terms/ 




            ------------------------ Yahoo! Groups Sponsor ---------------------~-->
            Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!
            http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/2U_rlB/TM
            ---------------------------------------------------------------------~->

            To unsubscribe from this group, send an email to:
            gpsxml-unsubscribe@yahoogroups.com



            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




            -- 
            
                       Misanthropist
            
            N42 15.900 W071 21.069 Alt 56.7m/186'
            

          • Dan Foster
            Hello, Friday, September 28, 2001, 7:32:24 AM, Chris wrote: CWS  When you get down to it, all the manipulations will happen on data structures CWS in memory
            Message 5 of 16 , Sep 28, 2001
            View Source
            • 0 Attachment
              Hello,

              Friday, September 28, 2001, 7:32:24 AM, Chris wrote:

              CWS>  When you get down to it, all the manipulations will happen on data structures
              CWS> in memory and whatever calculations are needed can be done as the document
              CWS> is parsed and the object representation is built.  There are probably three
              CWS> different rules you could use for making these decisions - what's easiest
              CWS> for a program to output, what's easiest for a program to read in, or what's
              CWS> easiest to use directly for whatever calculations are likely.   I guess that
              CWS> my initial opinion was to optimize for the particular calculations that I
              CWS> envisioned.  A question we need to ask is for which scenario should we optimize?
              CWS> After we decide on that, and the follow on questions that answer implies,
              CWS> we'll have an easier time on the design of the markup.

              I think Chris brings up a very important point. Without an
              agreement on what scenario we're designing and optimizing the XML
              format for, we won't be able to reach consensus on questions about
              individual elements and attributes.

              In the initial mailing I sent out, I proposed that we focus on the
              *interchange* of data between apps, rather than on a native storage
              format or a format that mirrored our internal object models. Some
              of us are writing new programs, and some of us have existing
              programs with much invested in our current objects.

              Everyone's going to be doing conversions of one sort or another to
              parse the text XML into binary objects in our applications. My
              preference would be to keep the XML interchange format limited to a
              small number of base elements with a limited number of required
              attributes. This will keep the work required to implement a 100%
              compliant parser to a minimum. On top of that, we should layer
              optional attributes that some subset of us might be able to
              interchange. If your application can't understand an optional
              attributes, no problem, you should just skip it.

              I don't know if everyone got the original message I sent out, so
              I'll post it again to the mailing list.

              --
              Dan Foster
              TopoGrafix - GPS Software, Waypoints, and Maps
              http://www.topografix.com - mailto:egroups@...
            • Dan Foster
              Hello, Before we get to the task of building a common XML format for GPS data interchange, we need to agree on some basic principles and guidelines for
              Message 6 of 16 , Sep 28, 2001
              View Source
              • 0 Attachment
                Hello,

                Before we get to the task of building a common XML format for GPS data
                interchange, we need to agree on some basic principles and guidelines
                for defining our format. I've tried to express my thoughts and the
                comments I received from others in the message below. Please let me
                know what you think of this proposal, especially if there are sections
                you don't agree with.

                ------
                Guiding principles:
                - A common XML data format for the exchange of GPS and
                location-based information between computers benefits everyone. It is
                in our interests and the interests of our users to create a common
                data exchange standard.

                - This is an open standard. It is controlled by no one person, and
                it is free from copyright and other legal meddling.

                - This is a data exchange format, not a data storage format.
                Applications are free to implement as much of the format as needed,
                and ignore parts of the data stream. The only requirement is that an
                application must be able to parse an arbitrary data stream without
                crashing.

                - This format allows for expansion. Private elements and attributes
                can be added to the format. To the extent possible, we will work
                together to define public structures that multiple applications can
                use, but any developer is free to add their own private data
                structures to any public element.

                - This standard is of no use unless people use it. To that end, it
                should be lightweight, easy to implement, and flexible enough to
                accommodate new features as it matures.

                - This format is about data exchange, not data validation.
                Device-specific details like the number of characters in a waypoint
                name do not belong in the exchange format, they belong in the
                end applications.


                On-disk representation:
                This format needs a standard file representation on disk. The
                proposed file extension is .gpx (combining GPS and eXchange...).
                Eventually, the format should have a common set of icons.


                Standard Data Types:
                The format will use standard data types (strings, floating point
                numbers, integers, etc) to represent data.


                Coordinate System and Units:
                - Coordinates will use WGS84 datum and signed decimal degrees
                format.

                - Time will be expressed in UTC, which seems to be expressed in XML
                like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
                Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445

                - The metric system will be used for other measures. Elevations are
                in meters, for example.


                Waypoint Symbols:
                Most handheld GPS units associate an integer value with the waypoint
                symbol. This integer is useless without knowing what model of GPS is
                being referenced since some integers map to different symbols
                depending on the GPS model. Instead of using the integer value, this
                format will use the text associated with the waypoint symbol.
                - examples: Trail Head, Church, Diver Down


                Public vs. Private Data Structures
                To prevent collisions between publicly-adopted data structures and
                private data, a simple naming convention will be used.
                public names: short, generic words or abbreviations with no underscore
                - examples: ele, lat, id, name
                private names: must begin with program/developer abbreviation and
                underscore to prevent collisions with other private data.
                - examples: tg_userdata, tg_routecolor (TopoGrafix extensions)


                --
                Dan Foster
                TopoGrafix - GPS Software, Waypoints, and Maps
                http://www.topografix.com - mailto:egroups@...
              • Kevin Read
                Dan said ... I certainly agree with this point. If the final GPX specification promotes the publicly-adopted data structures as a mandatory base for private
                Message 7 of 16 , Sep 28, 2001
                View Source
                • 0 Attachment
                  Dan said

                  > Snip
                  > In the initial mailing I sent out, I proposed that we focus on the
                  > *interchange* of data between apps, rather than on a native storage
                  > format or a format that mirrored our internal object models. Some
                  > of us are writing new programs, and some of us have existing
                  > programs with much invested in our current objects.
                  > Snip

                  I certainly agree with this point. If the final GPX specification promotes
                  the publicly-adopted data structures as a mandatory base for private usage,
                  I see no reason why other mini standars cannot be spawned that extend GPX
                  for other more specific requiremnets. i.e.

                  The obvious one to me is Geocaching. Whilst the base spec satisfies most
                  data requirements, standard extensions to GPX can be employed to provide
                  additional geocache related information such as a narrative section for
                  cache descriptions or a reference to the geocache user who planted the
                  cache.

                  Another extension could be in the aviation field where additional tags can
                  be used for radio freqs and runway directions when route planning.

                  Whilst the each of the examples show that GPX will not satisfy ALL
                  requirements it does provide a great starting point for the base set of
                  tags/attributes and structure of the XML packet. Perhaps a register can be
                  kept along side the GPX spec to record the extensions to the base format.

                  Kevin
                • larrywjames@yahoo.com
                  I would like to argue for track points as a separate element from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as
                  Message 8 of 16 , Sep 28, 2001
                  View Source
                  • 0 Attachment
                    I would like to argue for track points as a separate element from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as separate things. When you are importing from an exchange file to transfer to a GPS receiver, the software needs to know whether to send the point to the receiver as a track point or a waypoint. There is also the concept of whether the point starts a new track log or is a continuation of the same tracklog. One can imagine a real-time recorded file with a named waypoint which was marked in the middle of a bunch of unnamed track points.

                    The time for a tracklog point should be the absolute time to fractional second accuracy (how about 20011108T093014.673Z which might actually work in some current parsers), not a differential time from some other point. People regularly use text editors to remove some points or groups of points from track log files. If they remove the reference track point, then all the other differentially-timed points become useless.

                    Larry James
                    James Associates
                    303-258-0576
                  • Dan Foster
                    Hello, Friday, September 28, 2001, 2:08:31 PM, Larry wrote: lyc I would like to argue for track points as a separate element from waypoints. Most GPS
                    Message 9 of 16 , Sep 28, 2001
                    View Source
                    • 0 Attachment
                      Hello,

                      Friday, September 28, 2001, 2:08:31 PM, Larry wrote:

                      lyc> I would like to argue for track points as a separate element from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as separate things. When you are
                      lyc> importing from an exchange file to transfer to a GPS receiver, the software needs to know whether to send the point to the receiver as a track point or a waypoint. There is also the concept of
                      lyc> whether the point starts a new track log or is a continuation of the same tracklog. One can imagine a real-time recorded file with a named waypoint which was marked in the middle of a bunch of
                      lyc> unnamed track points.

                      Let me try to explain a reason for keeping trackpoints and waypoints
                      the same. At the very simplest level, I think about these basic
                      elements in terms of their basic form. I strip away everything that I
                      possibly can from waypoints and tracklogs while still keeping them
                      valid. For example, a waypoint can still be a waypoint without
                      elevation. Can it be a waypoint without latitude? I don't believe so.
                      The very simplest waypoint is just a lat/lon pair. A route is just a
                      bunch of lat/lon pairs in an ordered collection. A tracklog is
                      identical to a route in its simplest form. In my thinking, I treat
                      routes and tracks identically. The fact that one is usually created
                      by adding waypoints to a list and the other is created by moving a
                      GPS around and recording data doesn't alter their common basic
                      structure.

                      But, as Larry points out, there are things that appear in tracklogs
                      that don't make much sense in waypoints. Things like "begin new
                      track". I can think of two ways to handle this, illustrated
                      below. I'm going to use <point> and <path> to represent my "minimal"
                      waypoint and route/track elements.

                      1. make it an optional tag for all points, even though it only makes
                      sense for those points that are included in a tracklog.
                      <path name="example tracklog with two sections">
                      <point lat="40.1" lon="-70.1" />
                      <point lat="40.2" lon="-70.2" />
                      <point lat="40.3" lon="-70.3" />
                      <point lat="50.1" lon="-80.1" new_track="true" />
                      <point lat="50.2" lon="-80.2" />
                      <point lat="50.3" lon="-80.3" />
                      </path>

                      2. add a new element into <path>. I'll make up a new element <link>
                      which describes the implied line segment connecting the two <point>
                      elements.
                      <path name="example tracklog with two sections">
                      <point lat="40.1" lon="-70.1" />
                      <point lat="40.2" lon="-70.2" />
                      <point lat="40.3" lon="-70.3" />
                      <link connected="false" />
                      <point lat="50.1" lon="-80.1" />
                      <point lat="50.2" lon="-80.2" />
                      <point lat="50.3" lon="-80.3" />
                      </path>

                      I prefer the 2nd approach myself. I can use this new <link> element
                      to describe a route, as well:
                      <path name="example route">
                      <point lat="40.1" lon="-70.1" />
                      <link description="US Route 40 East" />
                      <point lat="40.2" lon="-70.2" />
                      <link description="Highway 12" />
                      <point lat="40.3" lon="-70.3" />
                      </path>

                      I believe that three basic elements <point> <path> and <link>, plus a
                      bunch of completely optional attributes are sufficient to describe the
                      things most of us would want to exchange between GPS and mapping
                      programs:
                      waypoints
                      routes
                      routepoints
                      legs (descriptions of the things that connect the routepoints)
                      tracks
                      trackpoints
                      map annotations
                      areas
                      polygons
                      text labels

                      Take the example of a user drawing a polygon on a map in one of our
                      programs (not mine - I don't support it!). Perhaps this describes a
                      restricted area on a map. The program writes out some XML data like
                      this:
                      <path foo_shape="poly" foo_color="blue">
                      <point lat="40.1" lon="-70.1" />
                      <point lat="40.2" lon="-70.2" />
                      <point lat="40.3" lon="-70.3" />
                      </path>

                      My software has absolutely no idea what foo_shape and foo_color are,
                      but it knows to interpret <path> as a route by default. So it brings
                      in the polygon as a route which shows up on my map where the user can
                      see it and edit it.

                      Contrast this against using separate elements to describe each
                      slightly different data type:
                      <private_poly foo_color="blue">
                      <polypoint lat="40.1" lon="-70.1" />
                      <polypoint lat="40.2" lon="-70.2" />
                      <polypoint lat="40.3" lon="-70.3" />
                      </private_poly>

                      Here, my software doesn't know what a <private_poly> or a <polypoint>
                      is, so it ignores it. Nothing shows up after the import.

                      I prefer reusing elements as much as possible, to maximize the amount
                      of data that can be successfully exchanged between applications with
                      varied purposes, while minimizing the size and complexity of our
                      parsers.

                      How do others feel about this issue?

                      lyc> The time for a tracklog point should be the absolute time to fractional second accuracy (how about 20011108T093014.673Z which might actually work in some current parsers), not a differential
                      lyc> time from some other point. People regularly use text editors to remove some points or groups of points from track log files. If they remove the reference track point, then all the other
                      lyc> differentially-timed points become useless.

                      I agree completely on this.

                      --
                      Dan Foster
                      TopoGrafix - GPS Software, Waypoints, and Maps
                      http://www.topografix.com - mailto:egroups@...
                    • randyday@yahoo.com
                      ... from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as separate things. When you are ... the software needs to
                      Message 10 of 16 , Sep 28, 2001
                      View Source
                      • 0 Attachment
                        --- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
                        > Hello,
                        >
                        > Friday, September 28, 2001, 2:08:31 PM, Larry wrote:
                        >
                        > lyc> I would like to argue for track points as a separate element
                        from waypoints. Most GPS applications, as well as storage within the
                        GPS receiver, treat these as separate things. When you are
                        > lyc> importing from an exchange file to transfer to a GPS receiver,
                        the software needs to know whether to send the point to the receiver
                        as a track point or a waypoint. There is also the concept of
                        > lyc> whether the point starts a new track log or is a continuation
                        of the same tracklog. One can imagine a real-time recorded file with
                        a named waypoint which was marked in the middle of a bunch of
                        > lyc> unnamed track points.
                        >
                        > Let me try to explain a reason for keeping trackpoints and waypoints
                        > the same. At the very simplest level, I think about these basic
                        > elements in terms of their basic form. I strip away everything
                        that I
                        > possibly can from waypoints and tracklogs while still keeping them
                        > valid. For example, a waypoint can still be a waypoint without
                        > elevation. Can it be a waypoint without latitude? I don't believe
                        so.
                        > The very simplest waypoint is just a lat/lon pair. A route is just
                        a
                        > bunch of lat/lon pairs in an ordered collection. A tracklog is
                        > identical to a route in its simplest form. In my thinking, I treat
                        > routes and tracks identically. The fact that one is usually created
                        > by adding waypoints to a list and the other is created by moving a
                        > GPS around and recording data doesn't alter their common basic
                        > structure.
                        >
                        > But, as Larry points out, there are things that appear in tracklogs
                        > that don't make much sense in waypoints. Things like "begin new
                        > track". I can think of two ways to handle this, illustrated
                        > below. I'm going to use <point> and <path> to represent
                        my "minimal"
                        > waypoint and route/track elements.
                        >
                        > 1. make it an optional tag for all points, even though it only makes
                        > sense for those points that are included in a tracklog.
                        > <path name="example tracklog with two sections">
                        > <point lat="40.1" lon="-70.1" />
                        > <point lat="40.2" lon="-70.2" />
                        > <point lat="40.3" lon="-70.3" />
                        > <point lat="50.1" lon="-80.1" new_track="true" />
                        > <point lat="50.2" lon="-80.2" />
                        > <point lat="50.3" lon="-80.3" />
                        > </path>
                        >
                        > 2. add a new element into <path>. I'll make up a new element <link>
                        > which describes the implied line segment connecting the two <point>
                        > elements.
                        > <path name="example tracklog with two sections">
                        > <point lat="40.1" lon="-70.1" />
                        > <point lat="40.2" lon="-70.2" />
                        > <point lat="40.3" lon="-70.3" />
                        > <link connected="false" />
                        > <point lat="50.1" lon="-80.1" />
                        > <point lat="50.2" lon="-80.2" />
                        > <point lat="50.3" lon="-80.3" />
                        > </path>
                        >
                        > I prefer the 2nd approach myself. I can use this new <link> element
                        > to describe a route, as well:
                        > <path name="example route">
                        > <point lat="40.1" lon="-70.1" />
                        > <link description="US Route 40 East" />
                        > <point lat="40.2" lon="-70.2" />
                        > <link description="Highway 12" />
                        > <point lat="40.3" lon="-70.3" />
                        > </path>
                        >
                        > I believe that three basic elements <point> <path> and <link>, plus
                        a
                        > bunch of completely optional attributes are sufficient to describe
                        the
                        > things most of us would want to exchange between GPS and mapping
                        > programs:
                        > waypoints
                        > routes
                        > routepoints
                        > legs (descriptions of the things that connect the routepoints)
                        > tracks
                        > trackpoints
                        > map annotations
                        > areas
                        > polygons
                        > text labels

                        I guess I need more explanation of a <link> element. I'm not sure I
                        appreciate its purpose or usefulness. If a track has two different
                        sections, why not something like:
                        <path name="section 1">
                        <point lat="40.1" lon="-70.1" />
                        <point lat="40.2" lon="-70.2" />
                        <point lat="40.3" lon="-70.3" />
                        </path>
                        <path name="section 2">
                        <point lat="50.1" lon="-70.1" />
                        <point lat="50.2" lon="-70.2" />
                        <point lat="50.3" lon="-70.3" />
                        </path>


                        > Take the example of a user drawing a polygon on a map in one of our
                        > programs (not mine - I don't support it!). Perhaps this describes
                        a
                        > restricted area on a map. The program writes out some XML data like
                        > this:
                        > <path foo_shape="poly" foo_color="blue">
                        > <point lat="40.1" lon="-70.1" />
                        > <point lat="40.2" lon="-70.2" />
                        > <point lat="40.3" lon="-70.3" />
                        > </path>
                        >
                        > My software has absolutely no idea what foo_shape and foo_color are,
                        > but it knows to interpret <path> as a route by default. So it
                        brings
                        > in the polygon as a route which shows up on my map where the user
                        can
                        > see it and edit it.
                        >
                        > Contrast this against using separate elements to describe each
                        > slightly different data type:
                        > <private_poly foo_color="blue">
                        > <polypoint lat="40.1" lon="-70.1" />
                        > <polypoint lat="40.2" lon="-70.2" />
                        > <polypoint lat="40.3" lon="-70.3" />
                        > </private_poly>
                        >
                        > Here, my software doesn't know what a <private_poly> or a
                        <polypoint>
                        > is, so it ignores it. Nothing shows up after the import.
                        >
                        > I prefer reusing elements as much as possible, to maximize the
                        amount
                        > of data that can be successfully exchanged between applications with
                        > varied purposes, while minimizing the size and complexity of our
                        > parsers.
                        >
                        > How do others feel about this issue?

                        The example of a poly as a <path> versus a <private_poly> is very
                        well put.


                        >
                        > lyc> The time for a tracklog point should be the absolute time to
                        fractional second accuracy (how about 20011108T093014.673Z which
                        might actually work in some current parsers), not a differential
                        > lyc> time from some other point. People regularly use text editors
                        to remove some points or groups of points from track log files. If
                        they remove the reference track point, then all the other
                        > lyc> differentially-timed points become useless.
                        >
                        > I agree completely on this.
                        >
                        > --
                        > Dan Foster
                        > TopoGrafix - GPS Software, Waypoints, and Maps
                        > http://www.topografix.com - mailto:egroups@t...
                      • Dan Foster
                        Hello, Saturday, September 29, 2001, 2:36:56 AM, Randy wrote: ryc I guess I need more explanation of a element. I m not sure I ryc appreciate its
                        Message 11 of 16 , Sep 30, 2001
                        View Source
                        • 0 Attachment
                          Hello,

                          Saturday, September 29, 2001, 2:36:56 AM, Randy wrote:

                          ryc> I guess I need more explanation of a <link> element. I'm not sure I
                          ryc> appreciate its purpose or usefulness.

                          <link> would describe any additional information about the connection
                          between two <points> in a <path>. Things like speed wouldn't go in
                          <link>, since they can be calculated directly from the two <points>.

                          Imagine converting driving directions from MapBlast into GPX format.
                          You'd have a list of <points>, but no place to store things like what
                          highway you're travelling on. The highway isn't associated with point
                          A or point B, it's associated with the connection between point A and
                          point B.

                          For most "pure" GPS applications where you're just recording data in
                          and out of the GPS, <link> wouldn't get much use. If you've looked at
                          the Garmin transfer protocol, you'll recall seeing link mentioned in
                          their route protocol. They define things like "snap to road". I
                          would add things like Larry's "start new track segment" to <link>,
                          since it describes the fact that the section between two <points> has
                          been broken due to a lost GPS signal.

                          [Just in case anyone isn't familiar with this "start new track"
                          situation, on a Garmin GPS if the user loses GPS signal or turns off
                          the GPS while recording a tracklog, and then restores the signal, the
                          GPS will keep the whole thing as one tracklog, but won't connect the
                          trackpoints across the dropout when it displays the tracklog on the
                          screen. It reports "start new track" when you read back the
                          trackpoint where the signal was restored.]

                          ryc> If a track has two different sections, why not something like:
                          ryc> <path name="section 1">
                          ryc> <point lat="40.1" lon="-70.1" />
                          ryc> <point lat="40.2" lon="-70.2" />
                          ryc> <point lat="40.3" lon="-70.3" />
                          ryc> </path>
                          ryc> <path name="section 2">
                          ryc> <point lat="50.1" lon="-70.1" />
                          ryc> <point lat="50.2" lon="-70.2" />
                          ryc> <point lat="50.3" lon="-70.3" />
                          ryc> </path>

                          By making them into two separate <paths>, you've lost the fact that
                          they were part of the same track.

                          Maybe <link> isn't the best way to solve this particular case. The
                          "start new track" situation comes about when the GPS loses lock (or
                          when the user turns the GPS off, etc). Since people are going to want
                          to store accuracy and signal strength info for <points>, maybe this
                          problem can be addressed there. Maybe through a "valid" flag or some
                          other mechanism.

                          Although, when I think about it more, in Larry's situation, the
                          <points> on either side of the "track dropout" are valid, and it's
                          really the "segment between the points" that needs to be marked as "no
                          data present".

                          --
                          Dan Foster
                          TopoGrafix - GPS Software, Waypoints, and Maps
                          http://www.topografix.com - mailto:egroups@...
                        • randyday@yahoo.com
                          ... connection ... what ... point ... and ... Ok, I see the functionality you are after. A construct like is dependent on the prior and after:
                          Message 12 of 16 , Oct 2, 2001
                          View Source
                          • 0 Attachment
                            --- In gpsxml@y..., Dan Foster <egroups@t...> wrote:

                            > <link> would describe any additional information about the
                            connection
                            > between two <points> in a <path>. Things like speed wouldn't go in
                            > <link>, since they can be calculated directly from the two <points>.
                            >
                            > Imagine converting driving directions from MapBlast into GPX format.
                            > You'd have a list of <points>, but no place to store things like
                            what
                            > highway you're travelling on. The highway isn't associated with
                            point
                            > A or point B, it's associated with the connection between point A
                            and
                            > point B.

                            Ok, I see the functionality you are after. A construct like <link> is
                            dependent on the <point> prior and after: should a track be edited,
                            then there is potential for trouble. Should a <link> have references
                            to its endpoints? Also, I'm not sure that I'd want to model driving
                            directions in this manner...

                            > ryc> If a track has two different sections, why not something like:
                            > ryc> <path name="section 1">
                            > ryc> <point lat="40.1" lon="-70.1" />
                            > ryc> <point lat="40.2" lon="-70.2" />
                            > ryc> <point lat="40.3" lon="-70.3" />
                            > ryc> </path>
                            > ryc> <path name="section 2">
                            > ryc> <point lat="50.1" lon="-70.1" />
                            > ryc> <point lat="50.2" lon="-70.2" />
                            > ryc> <point lat="50.3" lon="-70.3" />
                            > ryc> </path>
                            >
                            > By making them into two separate <paths>, you've lost the fact that
                            > they were part of the same track.

                            Is it important to retain the fact that they are part of the same
                            track? (Serious question.) If a track is compossed of 1 or more
                            sections, then why not model it as such?

                            <path>
                            <section>
                            <point blah.../>
                            <point blah.../>
                            </section>
                            <section>
                            <point blah.../>
                            <point blah.../>
                            </section>
                            </path>

                            Extrapolating this idea to the driving directions example, if a
                            portion of the drive is along I-90, and we want to associate this
                            with a set of points, then that information would be attributes of
                            the <section> of the <path> in question. The next portion of the
                            route that's along I-5 would be a new <section>, with new attributes.

                            This seems more general than the <link> construct in that it can
                            apply to 2, 3, 4, or more points, not just two. It also solves the
                            problem of making a <link> actually refer to the <points> in question.

                            >
                            > Maybe <link> isn't the best way to solve this particular case. The
                            > "start new track" situation comes about when the GPS loses lock (or
                            > when the user turns the GPS off, etc). Since people are going to
                            want
                            > to store accuracy and signal strength info for <points>, maybe this
                            > problem can be addressed there. Maybe through a "valid" flag or
                            some
                            > other mechanism.

                            Yes, I agree that accuracy and signal strength and number of stats
                            used for the fix are things that people will want.

                            >
                            > Although, when I think about it more, in Larry's situation, the
                            > <points> on either side of the "track dropout" are valid, and it's
                            > really the "segment between the points" that needs to be marked
                            as "no
                            > data present".
                            >
                            > --
                            > Dan Foster
                            > TopoGrafix - GPS Software, Waypoints, and Maps
                            > http://www.topografix.com - mailto:egroups@t...
                          • Dan Foster
                            Hello, Wednesday, October 03, 2001, 2:10:44 AM, Randy wrote: ... ryc connection ... ryc what ... ryc point ... ryc and ... ryc Ok, I see the functionality
                            Message 13 of 16 , Oct 14, 2001
                            View Source
                            • 0 Attachment
                              Hello,

                              Wednesday, October 03, 2001, 2:10:44 AM, Randy wrote:

                              ryc> --- In gpsxml@y..., Dan Foster <egroups@t...> wrote:

                              >> <link> would describe any additional information about the
                              ryc> connection
                              >> between two <points> in a <path>. Things like speed wouldn't go in
                              >> <link>, since they can be calculated directly from the two <points>.
                              >>
                              >> Imagine converting driving directions from MapBlast into GPX format.
                              >> You'd have a list of <points>, but no place to store things like
                              ryc> what
                              >> highway you're travelling on. The highway isn't associated with
                              ryc> point
                              >> A or point B, it's associated with the connection between point A
                              ryc> and
                              >> point B.

                              ryc> Ok, I see the functionality you are after. A construct like <link> is
                              ryc> dependent on the <point> prior and after: should a track be edited,
                              ryc> then there is potential for trouble. Should a <link> have references
                              ryc> to its endpoints?

                              I think the implied order of the file takes care of this. For
                              example, it's clear that the following three points are connected in
                              order:
                              <path>
                              <point> ... </point>
                              <point> ... </point>
                              <point> ... </point>
                              </path>

                              ryc> Also, I'm not sure that I'd want to model driving
                              ryc> directions in this manner...

                              I'm also struggling to find a good solution here. It may be that the
                              <link> element I proposed to store the "per-leg" information I keep in
                              my software doesn't have universal-enough appeal to make it into the
                              spec. Fine by me...

                              >> ryc> If a track has two different sections, why not something like:
                              >> ryc> <path name="section 1">
                              >> ryc> <point lat="40.1" lon="-70.1" />
                              >> ryc> <point lat="40.2" lon="-70.2" />
                              >> ryc> <point lat="40.3" lon="-70.3" />
                              >> ryc> </path>
                              >> ryc> <path name="section 2">
                              >> ryc> <point lat="50.1" lon="-70.1" />
                              >> ryc> <point lat="50.2" lon="-70.2" />
                              >> ryc> <point lat="50.3" lon="-70.3" />
                              >> ryc> </path>
                              >>
                              >> By making them into two separate <paths>, you've lost the fact that
                              >> they were part of the same track.

                              ryc> Is it important to retain the fact that they are part of the same
                              ryc> track? (Serious question.)

                              I think so. But I don't think it's so important that it requires a
                              new element. I prefer inserting an optional attribute into the first
                              point of the new segment to indicate that GPS lock was lost earlier.

                              ryc> If a track is compossed of 1 or more
                              ryc> sections, then why not model it as such?

                              ryc> <path>
                              ryc> <section>
                              ryc> <point blah.../>
                              ryc> <point blah.../>
                              ryc> </section>
                              ryc> <section>
                              ryc> <point blah.../>
                              ryc> <point blah.../>
                              ryc> </section>
                              ryc> </path>

                              I'd simplify things even more, and allow <path> to optionally contain other
                              <path> elements. Here are some examples - the last one is the
                              interesting one.

                              <path type="rte" desc="Route">
                              <point type="wpt" lat="42.1" lon="-71.2"/>
                              <point type="wpt" lat="42.2" lon="-71.2"/>
                              <point type="wpt" lat="42.3" lon="-71.2"/>
                              <point type="wpt" lat="42.4" lon="-71.2"/>
                              </path>

                              <path type="trk" desc="Garmin Tracklog No Breaks">
                              <point type="wpt" lat="42.1" lon="-71.2"/>
                              <point type="wpt" lat="42.2" lon="-71.2"/>
                              <point type="wpt" lat="42.3" lon="-71.2"/>
                              <point type="wpt" lat="42.4" lon="-71.2"/>
                              </path>

                              <path type="trk" desc="Garmin Tracklog No Breaks - Another Valid Version">
                              <path type="trk">
                              <point type="wpt" lat="42.1" lon="-71.2"/>
                              <point type="wpt" lat="42.2" lon="-71.2"/>
                              <point type="wpt" lat="42.3" lon="-71.2"/>
                              <point type="wpt" lat="42.4" lon="-71.2"/>
                              </path>
                              </path>

                              <path type="trk" desc="Garmin Tracklog With Breaks">
                              <path type="trk">
                              <point type="wpt" lat="42.1" lon="-71.2"/>
                              <point type="wpt" lat="42.2" lon="-71.2"/>
                              </path>
                              <path type="trk">
                              <point type="wpt" lat="42.3" lon="-71.2"/>
                              <point type="wpt" lat="42.4" lon="-71.2"/>
                              </path>
                              </path>


                              Thoughts?
                              --
                              Dan Foster
                              TopoGrafix - GPS Software, Waypoints, and Maps
                              http://www.topografix.com - mailto:egroups@...
                            • Dan Foster
                              Hello Alan, Tuesday, October 16, 2001, 7:28:40 PM, you wrote: AMG I commentated that I thought the file format (as seen in the sample) was very wasteful in
                              Message 14 of 16 , Oct 16, 2001
                              View Source
                              • 0 Attachment
                                Hello Alan,

                                Tuesday, October 16, 2001, 7:28:40 PM, you wrote:

                                AMG> I commentated that I thought the file format (as seen in the sample) was very wasteful in that too much was duplicated in the file and that it is very bloated with non-information padding.
                                ...
                                AMG> By having one single file format with a pair of characters defining the line type it would be very easy for application software to use or discard any line of information.

                                AMG> Any 'non-proprietary' like information could be added by having a 'comment' character ( ; ) start to that line. A later version could possibly incorporate that line type into the standard
                                AMG> specification.

                                I'd need to see an example, but what you're describing sounds like a
                                flat file format, and not an XML file. XML, while being rather
                                wordy, has the advantage that it's self describing, and can be
                                easily transformed into many other forms.

                                There are already several "standard" flat file formats for
                                describing GPS data. This group was formed to develop an XML
                                format.

                                --
                                Dan Foster
                                TopoGrafix - GPS Software, Waypoints, and Maps
                                http://www.topografix.com - mailto:egroups@...
                              • Alan Morris G4ENS
                                I ve just joined this new list and read the previous postings on the web site. I sent an e-mail to the link on the Topografix site and received a reply. I
                                Message 15 of 16 , Oct 16, 2001
                                View Source
                                • 0 Attachment
                                  I've just joined this new list and read the previous postings on the web site. I sent an e-mail to the link on the Topografix site and received a reply.

                                  I commentated that I thought the file format (as seen in the sample) was very wasteful in that too much was duplicated in the file and that it is very bloated with non-information padding.

                                  I was asked to "suggest ways to make our example file less wordy?"

                                  I suggested the use a single, or pair of characters to define a type of line.


                                  Dan Foster <egroups@...> replying to Randy wrote in [gpsxml]:-

                                  >>> Imagine converting driving directions from MapBlast into GPX format. You'd have a list of <points>, but no place to store things like what highway you're travelling on. The highway isn't associated point A or point B, it's associated with the connection between point A and point B.


                                  > I'm also struggling to find a good solution here. It may be that the <link> element I proposed to store the "per-leg" information I keep in my software doesn't have universal-enough appeal to make it into the spec. Fine by me...

                                  It depends on how one expects to use the data. I use my Garmin 75 when on holiday. I live in the UK and went to Germany as the example. At the end of each day, or when the track memory filled; I saved my GPS log onto my Psion 5.

                                  I can now plot each days travel onto a map (also on my Psion 5) of Germany. By editing this file, I could add extra details like places of interest or campsites used. This could then appear as waypoints on my maps. At present the waypoints are downloaded separately and converted into 'overlay' files, which are similar to Microsoft AutoRoute pushpin files (but unlike MS files can be exported !)

                                  When my photographs are returned from processing, I use the date/time printing on the back (APS film) with the GPS log, to tell me which town building is on any print. I could use this to make an overlay file of all photos taken and even include a text description of certain prints.

                                  Others would want to keep details of a future route where the road number and description between points of change in the route occur.

                                  By having one single file format with a pair of characters defining the line type it would be very easy for application software to use or discard any line of information.

                                  Any 'non-proprietary' like information could be added by having a 'comment' character ( ; ) start to that line. A later version could possibly incorporate that line type into the standard specification.
                                  --
                                  Alan R Morris, G4ENS.
                                  Bury St Edmunds, Suffolk, UK.
                                  No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.
                                • Alan Morris G4ENS
                                  Dan Foster wrote:- ... I accept the function of this group, but does all data have to be bracketed between wordy keywords ? Would it
                                  Message 16 of 16 , Oct 18, 2001
                                  View Source
                                  • 0 Attachment
                                    Dan Foster <egroups@...> wrote:-

                                    > I'd need to see an example, but what you're describing sounds like a flat file format, and not an XML file. XML, while being rather wordy, has the advantage that it's self describing, and can be easily transformed into many other forms.

                                    > There are already several "standard" flat file formats for describing GPS data. This group was formed to develop an XML format.

                                    I accept the function of this group, but does all data have to be bracketed between wordy keywords ? Would it be acceptable to have line entries within certain sections of the XML file ?

                                    As well as being wordy (and therefore files being significantly larger) the format style would suggest to me, a much slower rate for any application reading that data, which ever method of file reading (char, line or disk sector) is used. I would have thought that implementing an efficient parsing procedure would also be much slower, but I'm willing to learn if this is not the case.

                                    Is the function of this group to produce a very pure XML file in preference to a possibly more efficient and practical file. I'm not being awkward here, only asking for the ground rules. If I'm out of step, then let me know.

                                    I'm also involved with another group that is just about to start producing a common exchange file for campsite data which also incorporates GPS data. As those with motorhomes, or RVs as Americans call them, would want to send these files by e-mail from other countries; file size is very important when using a mobile phone and palm size computing devices.

                                    As palm size computers are used by an increasing number of GPS users, should this not be taken into account ? Or does this belong elsewhere ?
                                    --
                                    Alan R Morris, G4ENS.
                                    Bury St Edmunds, Suffolk, UK.
                                    No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.
                                  Your message has been successfully submitted and would be delivered to recipients shortly.