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

Re: Optimizing the XML format: Track Logs

Expand Messages
  • 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 1 of 16 , Oct 2, 2001
    • 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 2 of 16 , Oct 14, 2001
      • 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 3 of 16 , Oct 16, 2001
        • 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 4 of 16 , Oct 16, 2001
          • 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 5 of 16 , Oct 18, 2001
            • 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.