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

Re: [gpsxml] GPX 1.1 and

Expand Messages
  • Michael A. Peters
    ... You mean actually use the X in XML? ;) That sounds like the proper way to do things to me. officially sanctioned extensions to GPX. That way GPX itself
    Message 1 of 16 , Jun 23, 2009
    View Source
    • 0 Attachment
      Paul Tomblin wrote:
      >
      >
      >
      > On Tue, Jun 23, 2009 at 9:16 PM, Simon
      > Slavin<slavins@...
      > <mailto:slavins%40hearsay.demon.co.uk>> wrote:
      > > I think we should head for a GPX 2.0. Not a big standard, but one
      > > which manufacturers of all types of equipment will see as simple, easy
      > > to implement, and useful. But researching all the GPX-related domains
      > > needed to design a good one is too much work for me alone to do. Or
      > > perhaps I'm just not sufficiently motivated. As a group we could do
      > > it -- we need a runner, a hiker, and climber, a mapmaker, a driver, a
      > > sailor, a pilot, a photographer, etc. -- it we want to.
      >
      > Maybe the solution isn't a new GPX, but some sort of standard library
      > of extensions. I have a pretty decent (in my opinion) GPX extension
      > schema for aviation waypoint data, and I'd be really disappointed if
      > somebody who needed similar but slightly different data would design
      > their own extension schema instead of cooperating with me to extend
      > mine.

      You mean actually use the X in XML? ;)

      That sounds like the proper way to do things to me.
      'officially' sanctioned extensions to GPX.

      That way GPX itself can be kept small and to the point, and the
      extensions can be updated as needed without needing to update GPX itself.

      Kind of like how MathML can be updated w/o needing to update XHTML - and
      the MathML extension can be used with far more than just XHTML.

      I could see the extensions being useful to other formats (IE kml) if
      they are kept separate from GPX - which would make life easier when
      converting from one xml format to another.
    • Robert Lipe
      ... Yes, that s been exactly the problem so far. :-) ... I m reluctant to turn GPX into the kitchen sink. Ask a runner and a sailor what s important to each
      Message 2 of 16 , Jun 24, 2009
      View Source
      • 0 Attachment
        Simon:

        > But I want all the features in it I want (direction and tilt) and I
        > will deride features I don't care about (heartrate) as obvious bloat.

        Yes, that's been exactly the problem so far. :-)


        > I think we should head for a GPX 2.0. Not a big standard, but one
        > which manufacturers of all types of equipment will see as simple, easy
        > to implement, and useful. But researching all the GPX-related domains
        > needed to design a good one is too much work for me alone to do. Or
        > perhaps I'm just not sufficiently motivated. As a group we could do
        > it -- we need a runner, a hiker, and climber, a mapmaker, a driver, a
        > sailor, a pilot, a photographer, etc. -- it we want to.

        I'm reluctant to turn GPX into the kitchen sink. Ask a runner and a sailor
        what's
        important to each of them and they'll give opposite answers and then declare
        the other
        half as "obvious bloat", much as you just did.

        I'm liking the small core kernel of GPX, a blessed set of extensions for the
        things that
        are common now (direction and tilt, temperature, etc.), and the use of the
        <extensions>
        tag for domain-specific problems that can be integrated into "blessed" status
        once they
        get enough exposure to be proven to be workable and useful.

        Once those extensions have been implemented by enough programs to be proven
        useful, they can
        be frozen in future versions of GPX itself.

        It seems a pretty natural progression: experimental->one program->several
        programs->a proposed GPX extension->a holy GPX extension->official GPX.


        Victor:

        > Ok. In such a case, for example, will limit the information that is
        contained in
        > $ GPGLL and $ GPRMC of NMEA protocol sentensies?

        GPX can already capture most of that. I think GLL is covered. Speed and
        course in RMC were already mentioned as something we probably should care
        about. What specifically are you missing?

        >> While there are
        >> GPS devices that record speed via Doppler, they're a minority. The number
        >> that expose it outside the receiver is even smaller.

        > This, to put it mildly, not so.

        I only support a couple hundred models of GPS receivers and a few million
        users. Your experience in other markets may vary.

        The GPSMap 60 in your example does not present speed in any stored format and
        not even int he GPX it writes in its later firmware versions. The only
        references to speed in all of Garmin's non-realtime protocol specs are in
        reference to flightbook records or their workout devices or in their D800 PVT
        packets, which are never stored by the devices themselves.

        > If you only know the coordinates, it is not a simple task that requires some
        analysis [ ... ] the speed at this point is practically equal to zero

        Just to play devil's advocate, whether the distance is practically equal to
        zero or the speed is practically equal to zero doesn't really change things
        much for most programmers.


        While <speed> and <course> have excuses, I think we're all agreeing they have
        a place in a formal GPX extension.

        RJL
      • Simon Slavin
        ... This would be great and it s how I always assumed GPX worked, but since joining this list I ve found it doesn t work. Because there is no mechanism for
        Message 3 of 16 , Jun 24, 2009
        View Source
        • 0 Attachment
          On 24 Jun 2009, at 8:41pm, Robert Lipe wrote:

          > It seems a pretty natural progression: experimental->one program-
          > >several
          > programs->a proposed GPX extension->a holy GPX extension->official
          > GPX.

          This would be great and it's how I always assumed GPX worked, but
          since joining this list I've found it doesn't work. Because there is
          no mechanism for performing some of the arrows like

          a proposed GPX extension->a holy GPX extension

          because nobody (here in this list or elsewhere) cares, or perhaps even
          knows how to make it happen even if they do care. So if your
          progression is to work, part of the 'rescue' job is to work out how to
          trigger and effect each of the arrows.

          Simon.
        • Dan Foster
          Hello, [maybe it s time to start changing the subject line to better reflect what we re discussing] ... There are two holy GPX extension schemas, gpx_overlay
          Message 4 of 16 , Jun 24, 2009
          View Source
          • 0 Attachment
            Hello,

            [maybe it's time to start changing the subject line to better reflect
            what we're discussing]

            Wednesday, June 24, 2009, 4:11:12 PM, Simon wrote:

            > This would be great and it's how I always assumed GPX worked, but
            > since joining this list I've found it doesn't work. Because there is
            > no mechanism for performing some of the arrows like

            > a proposed GPX extension->a holy GPX extension

            > because nobody (here in this list or elsewhere) cares, or perhaps even
            > knows how to make it happen even if they do care. So if your
            > progression is to work, part of the 'rescue' job is to work out how to
            > trigger and effect each of the arrows.

            There are two "holy" GPX extension schemas, gpx_overlay and gpx_style.
            I proposed both of them back in 2004, and after some minimal input
            from members of this list, (even back then, not many people cared)
            they were blessed, given a "gpx_" prefix, and moved into the same
            folder hierarchy as the gpx 1.1 schema on
            http://www.topografix.com/gpx/ to indicated their holiness.

            I was hoping at the time that other extension schemas would follow.
            None did. I didn't have any urgent need for further compatibility
            with other programs after that, so the few changes I've made to my GPX
            output since then have gone in a private extension schema.

            As I recall, the "rules" we had in place for accepting an extension
            schema as holy went something like this:

            - you want it? you propose it, create and host a schema. feel free
            to use this mailing list to recruit others to help, but it's your
            project.
            - implement support for your schema in your app.
            - get a second person to implement support for your schema (proving
            that data can actually be exchanged between the two)
            - come back to this email list and ask for it to be made a standard
            gpx extension
            - respond to whatever feedback you get here, making changes to your
            schema if needed
            - after two weeks have passed with no new objections, your schema
            gets holy, gets a gpx_ prefix, and gets to live next to the main gpx
            schema.


            I really hate trying to find things in the GPSXML archives on Yahoo
            Groups, but here's one of the original posts on this topic:
            http://tech.groups.yahoo.com/group/gpsxml/message/463

            Are these still the "rules" we want to play by? If not, how should we
            proceed?



            I'm ready to start collaborating on a handful of extension schemas
            related to map calibration, POIs, geotagging photos, and typed or
            untyped data (similar to
            http://code.google.com/apis/kml/documentation/extendeddata.html ) and
            I promise to comment on and contribute to any other proposed schemas
            that others take the lead on.



            --
            Dan Foster
          Your message has been successfully submitted and would be delivered to recipients shortly.