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

(Mostly) working GPX download available at TrailRegistry.com

Expand Messages
  • bogamo
    Currently I m just puting out text in xml format, I m sure there are problems with escaping names of features that have symbols in them, but for the most part
    Message 1 of 23 , Jun 10, 2003
    • 0 Attachment
      Currently I'm just puting out text in xml format, I'm sure there are
      problems with escaping names of features that have symbols in them,
      but for the most part it works. If anyone knows of a better way to
      output XML in java, please let me know. (Performance is somewhat of an
      issue).

      The website is at http://www.trailregistry.com

      You'll need to create a user, then there will be a "Download GPS
      data" link at the top of every trail page.

      The system will convert the trail data that it has in the database to
      a GPX track, and all any waypoints that lay within ~0.5 miles of the
      trail.


      Also, I noticed that geocaching is using the mime type
      application/xml-loc, so I used that too. I'm not sure if that's the
      right one though.

      Please tell me what you think, and anything I can do better.


      Thanks in advance,

      -Geoff
    • Dan Foster
      Hello, Tuesday, June 10, 2003, 11:07:32 AM, Geoff wrote: b Also, I noticed that geocaching is using the mime type b application/xml-loc, so I used that too.
      Message 2 of 23 , Jun 22, 2003
      • 0 Attachment
        Hello,

        Tuesday, June 10, 2003, 11:07:32 AM, Geoff wrote:

        b> Also, I noticed that geocaching is using the mime type
        b> application/xml-loc, so I used that too. I'm not sure if that's the
        b> right one though.

        application/xml-gpx is a better choice. Geocaching also distributes
        files in a different XML format with the .loc extension, and they use
        xml-loc for that. Perhaps they didn't change their settings when they
        started using GPX.

        --
        Dan Foster
        TopoGrafix - GPS Software, Waypoints, and Maps
        http://www.topografix.com - mailto:egroups@...
      • Geoffrey Borggaard
        Thanks. I ll make the change the next time I push up a new version of the site. -Geoff ... __________________________________ Do you Yahoo!? SBC Yahoo! DSL -
        Message 3 of 23 , Jun 23, 2003
        • 0 Attachment
          Thanks. I'll make the change the next time I push up a new version of the
          site.

          -Geoff

          --- Dan Foster <egroups@...> wrote:
          > Hello,
          >
          > Tuesday, June 10, 2003, 11:07:32 AM, Geoff wrote:
          >
          > b> Also, I noticed that geocaching is using the mime type
          > b> application/xml-loc, so I used that too. I'm not sure if that's the
          > b> right one though.
          >
          > application/xml-gpx is a better choice. Geocaching also distributes
          > files in a different XML format with the .loc extension, and they use
          > xml-loc for that. Perhaps they didn't change their settings when they
          > started using GPX.
          >
          > --
          > Dan Foster
          > TopoGrafix - GPS Software, Waypoints, and Maps
          > http://www.topografix.com - mailto:egroups@...
          >
          >
          >
          > 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/
          >
          >


          __________________________________
          Do you Yahoo!?
          SBC Yahoo! DSL - Now only $29.95 per month!
          http://sbc.yahoo.com
        • Dan Foster
          Hi, I m interested in talking with any other developers who would be interested in using GPX to express line width, style, and color for routes and tracks, or
          Message 4 of 23 , Jul 8, 2003
          • 0 Attachment
            Hi,

            I'm interested in talking with any other developers who would be
            interested in using GPX to express line width, style, and color for
            routes and tracks, or to exchange map calibration data. This could be
            done through a new version of the GPX public spec, or through private
            namespace extensions. I'm currently using a private topografix:color
            tag for route color.

            --
            Dan Foster
            TopoGrafix - GPS Software, Waypoints, and Maps
            http://www.topografix.com - mailto:egroups@...
          • Charles Jones
            Dan, Sorry about not posting something along this line earlier. I certainly am interested discussing this... as well as the map calibration data. Charles
            Message 5 of 23 , Jul 8, 2003
            • 0 Attachment
              Dan,
                  Sorry about not posting something along this line earlier.  I certainly am interested discussing this... as well as the map calibration data. 
               
              Charles Jones
              Digital Trails
               
              ----- Original Message -----
              Sent: Tuesday, July 08, 2003 3:21 PM
              Subject: [gpsxml] Extensions for route/track color, line width or map calibration

              Hi,

              I'm interested in talking with any other developers who would be
              interested in using GPX to express line width, style, and color for
              routes and tracks, or to exchange map calibration data.  This could be
              done through a new version of the GPX public spec, or through private
              namespace extensions.  I'm currently using a private topografix:color
              tag for route color.

              --
              Dan Foster
              TopoGrafix - GPS Software, Waypoints, and Maps
              http://www.topografix.com - mailto:egroups@...



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



              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            • Sandro Franchi @ American Outland
              We too. ... From: Charles Jones [mailto:kodiak@phonet.com] Sent: Martes, 08 de Julio de 2003 06:34 p.m. To: gpsxml@yahoogroups.com Subject: Re: [gpsxml]
              Message 6 of 23 , Jul 8, 2003
              • 0 Attachment
                Message
                We too.
                -----Original Message-----
                From: Charles Jones [mailto:kodiak@...]
                Sent: Martes, 08 de Julio de 2003 06:34 p.m.
                To: gpsxml@yahoogroups.com
                Subject: Re: [gpsxml] Extensions for route/track color, line width or map calibration

                Dan,
                    Sorry about not posting something along this line earlier.  I certainly am interested discussing this... as well as the map calibration data. 
                 
                Charles Jones
                Digital Trails
                 
                ----- Original Message -----
                Sent: Tuesday, July 08, 2003 3:21 PM
                Subject: [gpsxml] Extensions for route/track color, line width or map calibration

                Hi,

                I'm interested in talking with any other developers who would be
                interested in using GPX to express line width, style, and color for
                routes and tracks, or to exchange map calibration data.  This could be
                done through a new version of the GPX public spec, or through private
                namespace extensions.  I'm currently using a private topografix:color
                tag for route color.

                --
                Dan Foster
                TopoGrafix - GPS Software, Waypoints, and Maps
                http://www.topografix.com - mailto:egroups@...



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



                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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



                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
              • gpsexpl@tiscali.no
                This sounds interesting! I would at the moment be most interested in exchanging map calibration data. In that case the information should at least contain:
                Message 7 of 23 , Jul 9, 2003
                • 0 Attachment
                  This sounds interesting!

                  I would at the moment be most interested in exchanging map calibration data.
                  In that case the information should at least contain:
                  -File name of map
                  -Pixels to positions (or world point to pos in case of calibrating a WMF)
                  -Datum
                  -Size of map (x and y)
                  -Projection
                  -Path to last known location on disk.

                  Could in addition contain much more:
                  -Name of each calibration point
                  -Links to Routes, Tracks or Waypoints that always should be added to map
                  - Suggestions? :-)

                  Steinar
                • Sandro Franchi @ American Outland
                  Projection parameters is an issue, due that every projection may have different projection parameters. They can be called Param1 ... ParamX , shouldn t be
                  Message 8 of 23 , Jul 9, 2003
                  • 0 Attachment
                    Projection parameters is an issue, due that every projection may have
                    different projection parameters. They can be called "Param1" ... "ParamX",
                    shouldn't be mandatory (some projections has no parameters) and the program
                    reading shall understand each parameter meaning, but a common set of
                    parameters for known or supported projection methods would be more usable,
                    for example:

                    Projection ID (from a list of supported projection names, can be a number or
                    a short string, i.e. UTM, TM, GK, etc.)
                    Central Meridian (-180 to 180)
                    Parallel One (-90 to 90)
                    Parallel Two (-90 to 90)
                    Zone Number (not only for UTM, many TM projections use that parameter)
                    Zone Letter (A..Z, a..z)
                    Hemisphere (N/S)
                    Scale Factor (0..1)
                    Etc.

                    I do prefer this approach so every program using this will have to store and
                    read from the same formal parameters, don't leaving "Param1..ParamX" to the
                    imagination of each one.

                    -----Original Message-----
                    From: gpsexpl@... [mailto:gpsexpl@...]
                    Sent: MiƩrcoles, 09 de Julio de 2003 10:00 a.m.
                    To: gpsxml@yahoogroups.com
                    Subject: RE: [gpsxml] Extensions for route/track color, line width or map
                    calibration


                    This sounds interesting!

                    I would at the moment be most interested in exchanging map calibration data.
                    In that case the information should at least contain: -File name of map
                    -Pixels to positions (or world point to pos in case of calibrating a WMF)
                    -Datum -Size of map (x and y) -Projection -Path to last known location on
                    disk.

                    Could in addition contain much more:
                    -Name of each calibration point
                    -Links to Routes, Tracks or Waypoints that always should be added to map
                    - Suggestions? :-)

                    Steinar



                    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/
                  • davewissenbach
                    ... could be ... private ... topografix:color ... I think that a public specification for line width, color, etc. might be a good thing. My program does not
                    Message 9 of 23 , Jul 13, 2003
                    • 0 Attachment
                      --- In gpsxml@yahoogroups.com, Dan Foster <egroups@t...> wrote:
                      > Hi,
                      >
                      > I'm interested in talking with any other developers who would be
                      > interested in using GPX to express line width, style, and color for
                      > routes and tracks, or to exchange map calibration data. This
                      could be
                      > done through a new version of the GPX public spec, or through
                      private
                      > namespace extensions. I'm currently using a private
                      topografix:color
                      > tag for route color.
                      >

                      I think that a public specification for line width, color, etc.
                      might be a good thing. My program does not allow the direct
                      specification of line color or style, but the SVG output function
                      will pass a wissenbach:style element through to SVG. The contents of
                      the style element becomes the value of a CSS style attribute for the
                      track. As an alternative, an optional CSS style attribute could be
                      added to tracks and routes as is currently done with HTML4.0,
                      XHTML1.0/1.1, and SVG1.0. Or perhaps we just add optional CSS style
                      to everything, so that waypoint names can also be styled.

                      Dave


                      > --
                      > Dan Foster
                      > TopoGrafix - GPS Software, Waypoints, and Maps
                      > http://www.topografix.com - mailto:egroups@t...
                    • Dan Foster
                      Hello, Sunday, July 13, 2003, 4:53:38 PM, Dave wrote: d I think that a public specification for line width, color, etc. d might be a good thing. My program
                      Message 10 of 23 , Jul 16, 2003
                      • 0 Attachment
                        Hello,

                        Sunday, July 13, 2003, 4:53:38 PM, Dave wrote:

                        d> I think that a public specification for line width, color, etc.
                        d> might be a good thing. My program does not allow the direct
                        d> specification of line color or style, but the SVG output function
                        d> will pass a wissenbach:style element through to SVG. The contents of
                        d> the style element becomes the value of a CSS style attribute for the
                        d> track. As an alternative, an optional CSS style attribute could be
                        d> added to tracks and routes as is currently done with HTML4.0,
                        d> XHTML1.0/1.1, and SVG1.0. Or perhaps we just add optional CSS style
                        d> to everything, so that waypoint names can also be styled.

                        I like the idea of staying as close to CSS or SVG as possible. However, I
                        think that allowing the full range of CSS style attributes in a single
                        <style> tag would make it difficult to parse when reading the file
                        back into any of our programs. For example, CSS allows font size to
                        be specified as any of the following: 12pt, larger, 150%, 1.5em. To
                        keep things simple, we're probably better off just using point sizes
                        only.

                        I suggest defining a subset of style elements that mapping programs
                        would be likely to use, and using tags and data values that match SVG
                        as much as possible. For example:
                        <wpt lat="42.451731173" lon="-71.548814064">
                        <desc>Styled Waypoint</desc>
                        <gpx_style:font-family>Arial</gpx_style:font-family>
                        <gpx_style:font-weight>bold</gpx_style:font-weight>
                        <gpx_style:font-size>24</gpx_style:font-size>
                        <gpx_style:color>ffffff</gpx_style:color>
                        </wpt>
                        <rte>
                        <desc>Styled Route</desc>
                        <gpx_style:stroke-width>3</gpx_style:stroke-width>
                        <gpx_style:stroke>ffffff</gpx_style:stroke>
                        </rte>

                        --
                        Dan Foster
                        TopoGrafix - GPS Software, Waypoints, and Maps
                        http://www.topografix.com - mailto:egroups@...
                      • Dan Foster
                        Hello, Wednesday, July 9, 2003, 10:39:31 AM, Sandro wrote: S Projection parameters is an issue, due that every projection may have S different projection
                        Message 11 of 23 , Jul 16, 2003
                        • 0 Attachment
                          Hello,

                          Wednesday, July 9, 2003, 10:39:31 AM, Sandro wrote:

                          S> Projection parameters is an issue, due that every projection may have
                          S> different projection parameters. They can be called "Param1" ... "ParamX",
                          S> shouldn't be mandatory (some projections has no parameters) and the program
                          S> reading shall understand each parameter meaning, but a common set of
                          S> parameters for known or supported projection methods would be more usable,
                          S> for example:

                          S> Projection ID (from a list of supported projection names, can be a number or
                          S> a short string, i.e. UTM, TM, GK, etc.)
                          S> Central Meridian (-180 to 180)
                          S> Parallel One (-90 to 90)
                          S> Parallel Two (-90 to 90)
                          S> Zone Number (not only for UTM, many TM projections use that parameter)
                          S> Zone Letter (A..Z, a..z)
                          S> Hemisphere (N/S)
                          S> Scale Factor (0..1)
                          S> Etc.

                          S> I do prefer this approach so every program using this will have to store and
                          S> read from the same formal parameters, don't leaving "Param1..ParamX" to the
                          S> imagination of each one.

                          I like this approach. I've already done some experiments with using
                          GPX to store map calibration data (everything except the projection
                          parameters). Here are two examples. The first isn't calibrated, the
                          second has three calibration points.

                          <topografix:map url="D:\sample.jpg">
                          <topografix:name>sample.jpg</topografix:name>
                          <topografix:width>1031</topografix:width>
                          <topografix:height>901</topografix:height>
                          </topografix:map>

                          <topografix:map url="D:\TopoGrafix Data\MA\Stow\Stow Street Map 256.png">
                          <topografix:name>Stow Street Map</topografix:name>
                          <topografix:width>1523</topografix:width>
                          <topografix:height>1830</topografix:height>
                          <topografix:mappt lat="42.461548000" lon="-71.538146000" x="288.0" y="119.0"/>
                          <topografix:mappt lat="42.394430000" lon="-71.480885000" x="1301.0" y="1707.0"/>
                          <topografix:mappt lat="42.394152000" lon="-71.541412000" x="245.0" y="1725.0"/>
                          </topografix:map>

                          The schema for these private extensions is available at
                          http://www.topografix.com/GPX/Private/TopoGrafix/0/2/topografix.xsd

                          Perhaps we should work on a sample schema for several common
                          projections. The projections of most interest to me are UTM,
                          Transverse Mercator, and Lambert Conformal Conic.

                          --
                          Dan Foster
                          TopoGrafix - GPS Software, Waypoints, and Maps
                          http://www.topografix.com - mailto:egroups@...
                        • Sandro Franchi @ American Outland
                          Great, let start working with those projections, are pretty common in this side of the world too. I ll think about it a moment and will send you something. ...
                          Message 12 of 23 , Jul 16, 2003
                          • 0 Attachment
                            Message
                            Great, let start working with those projections, are pretty common in this side of the world too. I'll think about it a moment and will send you something.
                            -----Original Message-----
                            From: Dan Foster [mailto:egroups@...]
                            Sent: MiƩrcoles, 16 de Julio de 2003 12:40 p.m.
                            To: gpsxml@yahoogroups.com
                            Subject: Re[2]: [gpsxml] Extensions for map calibration

                            Hello,

                            Wednesday, July 9, 2003, 10:39:31 AM, Sandro wrote:

                            S> Projection parameters is an issue, due that every projection may have
                            S> different projection parameters. They can be called "Param1" ... "ParamX",
                            S> shouldn't be mandatory (some projections has no parameters) and the program
                            S> reading shall understand each parameter meaning, but a common set of
                            S> parameters for known or supported projection methods would be more usable,
                            S> for example:

                            S> Projection ID (from a list of supported projection names, can be a number or
                            S> a short string, i.e. UTM, TM, GK, etc.)
                            S> Central Meridian (-180 to 180)
                            S> Parallel One (-90 to 90)
                            S> Parallel Two (-90 to 90)
                            S> Zone Number (not only for UTM, many TM projections use that parameter)
                            S> Zone Letter (A..Z, a..z)
                            S> Hemisphere (N/S)
                            S> Scale Factor (0..1)
                            S> Etc.

                            S> I do prefer this approach so every program using this will have to store and
                            S> read from the same formal parameters, don't leaving "Param1..ParamX" to the
                            S> imagination of each one.

                            I like this approach.  I've already done some experiments with using
                            GPX to store map calibration data (everything except the projection
                            parameters).  Here are two examples.  The first isn't calibrated, the
                            second has three calibration points.

                            <topografix:map url="D:\sample.jpg">
                            <topografix:name>sample.jpg</topografix:name>
                            <topografix:width>1031</topografix:width>
                            <topografix:height>901</topografix:height>
                            </topografix:map>

                            <topografix:map url="D:\TopoGrafix Data\MA\Stow\Stow Street Map 256.png">
                            <topografix:name>Stow Street Map</topografix:name>
                            <topografix:width>1523</topografix:width>
                            <topografix:height>1830</topografix:height>
                            <topografix:mappt lat="42.461548000" lon="-71.538146000" x="288.0" y="119.0"/>
                            <topografix:mappt lat="42.394430000" lon="-71.480885000" x="1301.0" y="1707.0"/>
                            <topografix:mappt lat="42.394152000" lon="-71.541412000" x="245.0" y="1725.0"/>
                            </topografix:map>

                            The schema for these private extensions is available at
                            http://www.topografix.com/GPX/Private/TopoGrafix/0/2/topografix.xsd

                            Perhaps we should work on a sample schema for several common
                            projections.  The projections of most interest to me are UTM,
                            Transverse Mercator, and Lambert Conformal Conic.

                            --
                            Dan Foster
                            TopoGrafix - GPS Software, Waypoints, and Maps
                            http://www.topografix.com - mailto:egroups@...



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



                            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                          • Jeremy Irish
                            I vote an emphatic no regarding the additions of extensions for map calibration. GPX should be restricted to waypoint, track, and route sharing with the
                            Message 13 of 23 , Jul 17, 2003
                            • 0 Attachment
                              Message
                              I vote an emphatic no regarding the additions of extensions for map calibration. GPX should be restricted to waypoint, track, and route sharing with the addition of display specifics. Maps should be in its own XML spec and separate from GPX.
                               
                              Track display options, however, have its place in GPX.
                               
                              Just the tracks, m'aam.
                               
                              JMO
                               
                              Jeremy
                               
                               
                            • Sandro Franchi @ American Outland
                              And what s your emphatic reason for that? If a program has not mapping functionality wont use them, there is no overhead for it nor for its users. A standard
                              Message 14 of 23 , Jul 17, 2003
                              • 0 Attachment
                                Message
                                And what's your emphatic reason for that? If a program has not mapping functionality wont use them, there is no overhead for it nor for its users.
                                 
                                A standard must conform to all the needs of a "problem", if the GPX model ignores mapping issues, the same incompatibilty we suffer day to day with "data" will continue happening with "maps".
                                 
                                Why a map produced by the software brabd "XXX" shouldn't be opened with the mapping solution "YYYY"?
                                -----Original Message-----
                                From: Jeremy Irish [mailto:jeremy@...]
                                Sent: Jueves, 17 de Julio de 2003 01:13 p.m.
                                To: gpsxml@yahoogroups.com
                                Subject: RE: Re[2]: [gpsxml] Extensions for map calibration

                                I vote an emphatic no regarding the additions of extensions for map calibration. GPX should be restricted to waypoint, track, and route sharing with the addition of display specifics. Maps should be in its own XML spec and separate from GPX.
                                 
                                Track display options, however, have its place in GPX.
                                 
                                Just the tracks, m'aam.
                                 
                                JMO
                                 
                                Jeremy
                                 
                                 


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



                                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                              • Sandro Franchi @ American Outland
                                Where says brabd , read named :) ... From: Sandro Franchi @ American Outland [mailto:sandro_franchi@american-outland.com] Sent: Jueves, 17 de Julio de 2003
                                Message 15 of 23 , Jul 17, 2003
                                • 0 Attachment
                                  Message
                                  Where says "brabd", read "named" :)
                                  -----Original Message-----
                                  From: Sandro Franchi @ American Outland [mailto:sandro_franchi@...]
                                  Sent: Jueves, 17 de Julio de 2003 01:53 p.m.
                                  To: gpsxml@yahoogroups.com
                                  Subject: RE: Re[2]: [gpsxml] Extensions for map calibration

                                  And what's your emphatic reason for that? If a program has not mapping functionality wont use them, there is no overhead for it nor for its users.
                                   
                                  A standard must conform to all the needs of a "problem", if the GPX model ignores mapping issues, the same incompatibilty we suffer day to day with "data" will continue happening with "maps".
                                   
                                  Why a map produced by the software brabd "XXX" shouldn't be opened with the mapping solution "YYYY"?
                                  -----Original Message-----
                                  From: Jeremy Irish [mailto:jeremy@...]
                                  Sent: Jueves, 17 de Julio de 2003 01:13 p.m.
                                  To: gpsxml@yahoogroups.com
                                  Subject: RE: Re[2]: [gpsxml] Extensions for map calibration

                                  I vote an emphatic no regarding the additions of extensions for map calibration. GPX should be restricted to waypoint, track, and route sharing with the addition of display specifics. Maps should be in its own XML spec and separate from GPX.
                                   
                                  Track display options, however, have its place in GPX.
                                   
                                  Just the tracks, m'aam.
                                   
                                  JMO
                                   
                                  Jeremy
                                   
                                   


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



                                  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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



                                  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                • Jeremy Irish
                                  ... Sandro Franchi @ American Outland [sandro_franchi@american-outland.com]: A standard must conform to all the needs of a problem , if the GPX model ignores
                                  Message 16 of 23 , Jul 17, 2003
                                  • 0 Attachment
                                    Message
                                    ---------
                                    Sandro Franchi @ American Outland [sandro_franchi@...]:
                                     
                                    A standard must conform to all the needs of a "problem", if the GPX model ignores mapping issues, the same incompatibilty we suffer day to day with "data" will continue happening with "maps".
                                    ------------

                                    GPX should ignore mapping issues. One problem at a time, Sandro!
                                     
                                    What I suggest is that additional display parameters for tracks, routes and waypoints are perfectly acceptable in GPX, which it's intent (correct me if I'm wrong) is an open standard to exchange data between GPS receivers. As GPS receivers get more sophisticated I wouldn't be surprised if you will be able to suggest display parameters for data. We already have this for the GPS symbol freetext.
                                     
                                    If you want maps, use GML, which was specifically designed for mapping, both vector and raster. For GPX, existing data like routes, tracks and waypoints can and should have additional parameters, like track width, color, border color, show points, or display. But layered maps of any kind have no place in GPX.
                                     
                                    Chuck, I agree that some information in the spec can be ignored, but I won't put a pig in a chicken coop, even if there is space for the pig. I don't object to shoving information in the GPX file about mapping, but it should be a separate namespace, much like TopoGrafix does it now.
                                     
                                    Jeremy
                                    -----Original Message-----
                                    From: Charles Jones [mailto:kodiak@...]
                                    Sent: Thursday, July 17, 2003 11:04 AM
                                    To: gpsxml@yahoogroups.com
                                    Subject: Re: Re[2]: [gpsxml] Extensions for map calibration

                                    I'm a firm believer in keeping things simple.  However you suggest the addition of display specfics.. but what are maps if not a specific subclass... ie a display type?  It makes sense to me that if an application uses GPX information for the display/map that that information be included as a standard part of the GPX specification.  Least we all forget, just because the information is in the spec, doesn't mean everyone HAS to include it.
                                     
                                  • Charles Jones
                                    MessageI m a firm believer in keeping things simple. However you suggest the addition of display specfics.. but what are maps if not a specific subclass... ie
                                    Message 17 of 23 , Jul 17, 2003
                                    • 0 Attachment
                                      Message
                                      I'm a firm believer in keeping things simple.  However you suggest the addition of display specfics.. but what are maps if not a specific subclass... ie a display type?  It makes sense to me that if an application uses GPX information for the display/map that that information be included as a standard part of the GPX specification.  Least we all forget, just because the information is in the spec, doesn't mean everyone HAS to include it.
                                       
                                      Chuck
                                      ----- Original Message -----
                                      Sent: Thursday, July 17, 2003 11:13 AM
                                      Subject: RE: Re[2]: [gpsxml] Extensions for map calibration

                                      I vote an emphatic no regarding the additions of extensions for map calibration. GPX should be restricted to waypoint, track, and route sharing with the addition of display specifics. Maps should be in its own XML spec and separate from GPX.
                                       
                                      Track display options, however, have its place in GPX.
                                       
                                      Just the tracks, m'aam.
                                       
                                      JMO
                                       
                                      Jeremy
                                       
                                       


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



                                      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                    • Sandro Franchi @ American Outland
                                      GPS receivers can do nothing with GPX data without a program, so GPX is a standard intended for those programs, not for the receiver itself, or not only to it
                                      Message 18 of 23 , Jul 17, 2003
                                      • 0 Attachment
                                        Message
                                        GPS receivers can do nothing with GPX data without a program, so GPX is a standard intended for those programs, not for the receiver itself, or not only to it at least, that's the reason I would include mapping as a "must have".
                                         
                                        I've no problem with a different namespace, but why don't make just one, complete, including this? There is no overhead for users nor programs if the current namespace does include mapping parameters, they will be used only for those interested in it.
                                         
                                        As an example, MapSource will ignore map information because it only uses its own maps, but OZIExplorer and Fugawi can show a map created in any of both. MapSource will only read the "data" portion of the file, and others programs all of it, or can be a user option.
                                        -----Original Message-----
                                        From: Jeremy Irish [mailto:jeremy@...]
                                        Sent: Jueves, 17 de Julio de 2003 02:53 p.m.
                                        To: gpsxml@yahoogroups.com
                                        Subject: RE: Re[2]: [gpsxml] Extensions for map calibration

                                        ---------
                                        Sandro Franchi @ American Outland [sandro_franchi@...]:
                                         
                                        A standard must conform to all the needs of a "problem", if the GPX model ignores mapping issues, the same incompatibilty we suffer day to day with "data" will continue happening with "maps".
                                        ------------

                                        GPX should ignore mapping issues. One problem at a time, Sandro!
                                         
                                        What I suggest is that additional display parameters for tracks, routes and waypoints are perfectly acceptable in GPX, which it's intent (correct me if I'm wrong) is an open standard to exchange data between GPS receivers. As GPS receivers get more sophisticated I wouldn't be surprised if you will be able to suggest display parameters for data. We already have this for the GPS symbol freetext.
                                         
                                        If you want maps, use GML, which was specifically designed for mapping, both vector and raster. For GPX, existing data like routes, tracks and waypoints can and should have additional parameters, like track width, color, border color, show points, or display. But layered maps of any kind have no place in GPX.
                                         
                                        Chuck, I agree that some information in the spec can be ignored, but I won't put a pig in a chicken coop, even if there is space for the pig. I don't object to shoving information in the GPX file about mapping, but it should be a separate namespace, much like TopoGrafix does it now.
                                         
                                        Jeremy
                                        -----Original Message-----
                                        From: Charles Jones [mailto:kodiak@...]
                                        Sent: Thursday, July 17, 2003 11:04 AM
                                        To: gpsxml@yahoogroups.com
                                        Subject: Re: Re[2]: [gpsxml] Extensions for map calibration

                                        I'm a firm believer in keeping things simple.  However you suggest the addition of display specfics.. but what are maps if not a specific subclass... ie a display type?  It makes sense to me that if an application uses GPX information for the display/map that that information be included as a standard part of the GPX specification.  Least we all forget, just because the information is in the spec, doesn't mean everyone HAS to include it.
                                         


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



                                        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                      • Jeremy Irish
                                        Unless you can come up with a better reason than why not? , I don t see a reason why it should be part of the spec. Maps are extremely complicated which is
                                        Message 19 of 23 , Jul 17, 2003
                                        • 0 Attachment
                                          Message
                                           
                                          Unless you can come up with a better reason than "why not?", I don't see a reason why it should be part of the spec. Maps are extremely complicated which is why there are already dedicated specifications outside GPX. Last thing I want to see is GPX bloat from unnecessary additions. Create your own GML lite and point to that namespace if you want to include it in a GPX file.
                                           
                                          Mapping may be a "must have" for you, but it isn't a "must have" for GPX.
                                           
                                          Jeremy
                                          -----Original Message-----
                                          From: Sandro Franchi @ American Outland [mailto:sandro_franchi@...]
                                          Sent: Thursday, July 17, 2003 11:35 AM
                                          To: gpsxml@yahoogroups.com
                                          Subject: RE: Re[2]: [gpsxml] Extensions for map calibration

                                          GPS receivers can do nothing with GPX data without a program, so GPX is a standard intended for those programs, not for the receiver itself, or not only to it at least, that's the reason I would include mapping as a "must have".
                                           
                                          I've no problem with a different namespace, but why don't make just one, complete, including this? There is no overhead for users nor programs if the current namespace does include mapping parameters, they will be used only for those interested in it.
                                           
                                          As an example, MapSource will ignore map information because it only uses its own maps, but OZIExplorer and Fugawi can show a map created in any of both. MapSource will only read the "data" portion of the file, and others programs all of it, or can be a user option.
                                        • Sandro Franchi @ American Outland
                                          Why not is not my opinion, is your conception of my opinion, I did explain why yes and my reasons, you don t have to agree with me, obviously. Regards. ...
                                          Message 20 of 23 , Jul 17, 2003
                                          • 0 Attachment
                                            Message
                                            "Why not" is not my opinion, is your conception of my opinion, I did explain "why yes" and my reasons, you don't have to agree with me, obviously.
                                             
                                            Regards.
                                            -----Original Message-----
                                            From: Jeremy Irish [mailto:jeremy@...]
                                            Sent: Jueves, 17 de Julio de 2003 04:08 p.m.
                                            To: gpsxml@yahoogroups.com
                                            Subject: RE: Re[2]: [gpsxml] Extensions for map calibration

                                             
                                            Unless you can come up with a better reason than "why not?", I don't see a reason why it should be part of the spec. Maps are extremely complicated which is why there are already dedicated specifications outside GPX. Last thing I want to see is GPX bloat from unnecessary additions. Create your own GML lite and point to that namespace if you want to include it in a GPX file.
                                             
                                            Mapping may be a "must have" for you, but it isn't a "must have" for GPX.
                                             
                                            Jeremy
                                            -----Original Message-----
                                            From: Sandro Franchi @ American Outland [mailto:sandro_franchi@...]
                                            Sent: Thursday, July 17, 2003 11:35 AM
                                            To: gpsxml@yahoogroups.com
                                            Subject: RE: Re[2]: [gpsxml] Extensions for map calibration

                                            GPS receivers can do nothing with GPX data without a program, so GPX is a standard intended for those programs, not for the receiver itself, or not only to it at least, that's the reason I would include mapping as a "must have".
                                             
                                            I've no problem with a different namespace, but why don't make just one, complete, including this? There is no overhead for users nor programs if the current namespace does include mapping parameters, they will be used only for those interested in it.
                                             
                                            As an example, MapSource will ignore map information because it only uses its own maps, but OZIExplorer and Fugawi can show a map created in any of both. MapSource will only read the "data" portion of the file, and others programs all of it, or can be a user option.


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



                                            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                          • davewissenbach
                                            ... However, I ... single ... to ... To ... sizes ... SVG ... That looks like a good way to keep the parsing easy. (Use CSS symantics with XML syntax). I could
                                            Message 21 of 23 , Jul 18, 2003
                                            • 0 Attachment
                                              --- In gpsxml@yahoogroups.com, Dan Foster <egroups@t...> wrote:
                                              > Hello,
                                              >
                                              > I like the idea of staying as close to CSS or SVG as possible.
                                              However, I
                                              > think that allowing the full range of CSS style attributes in a
                                              single
                                              > <style> tag would make it difficult to parse when reading the file
                                              > back into any of our programs. For example, CSS allows font size
                                              to
                                              > be specified as any of the following: 12pt, larger, 150%, 1.5em.
                                              To
                                              > keep things simple, we're probably better off just using point
                                              sizes
                                              > only.
                                              >
                                              > I suggest defining a subset of style elements that mapping programs
                                              > would be likely to use, and using tags and data values that match
                                              SVG
                                              > as much as possible. For example:
                                              > <wpt lat="42.451731173" lon="-71.548814064">
                                              > <desc>Styled Waypoint</desc>
                                              > <gpx_style:font-family>Arial</gpx_style:font-family>
                                              > <gpx_style:font-weight>bold</gpx_style:font-weight>
                                              > <gpx_style:font-size>24</gpx_style:font-size>
                                              > <gpx_style:color>ffffff</gpx_style:color>
                                              > </wpt>
                                              > <rte>
                                              > <desc>Styled Route</desc>
                                              > <gpx_style:stroke-width>3</gpx_style:stroke-width>
                                              > <gpx_style:stroke>ffffff</gpx_style:stroke>
                                              > </rte>
                                              >

                                              That looks like a good way to keep the parsing easy. (Use CSS
                                              symantics with XML syntax). I could go with that.

                                              As far as the scanned map stuff, I'm with the people who suggest
                                              another namespace. But perhaps the GPX format could include a
                                              basemap tag, to confine the included map data to a well-defined
                                              section of the document. My interest here is fairly casual--I'm
                                              more interested in vector maps at the moment.

                                              Dave
                                            • Dan Foster
                                              Hello, I read through all the messages posted about map calibration extensions, and it sounds like keeping map calibration data in its own namespace is a
                                              Message 22 of 23 , Jul 24, 2003
                                              • 0 Attachment
                                                Hello,

                                                I read through all the messages posted about map calibration
                                                extensions, and it sounds like keeping map calibration data in its own
                                                namespace is a solution that everyone would be willing to live with.
                                                There is value in keeping the base GPX namespace simple. The schema
                                                is several pages long right now, and it's already difficult enough to
                                                read for most people. Having map calibration in a separate namespace
                                                makes it very easy for people to ignore it if they don't plan to
                                                support calibrated maps in their application. For programs that do
                                                support map calibration, it's a simple matter to include the
                                                additional namespace.

                                                There are already several examples of private namespace extensions to GPX.
                                                groundspeak, topografix, and wissenbach are the ones I know of. Each
                                                of these is a private extension, with a single person or company
                                                dictating the namespace extension, and free to change it at will.

                                                We've talked in the past about creating public namespace extensions,
                                                but until now we haven't implemented any. Public namespace extensions
                                                would be identical to private ones, but this group (or some subset of
                                                the group) would define the schema definition and approve changes to
                                                it. Presumably, public namespace extensions would be for things that
                                                are general enough that they would be exchanged between multiple
                                                programs. Perhaps to keep them distinguished from private extensions,
                                                they should use namespaces starting with gpx_. (gpx_mapcal, gpx_url, etc)

                                                I feel that private and public namespace extensions are the best way
                                                to extend the functionality of GPX while keeping the base GPX
                                                namespace simple. We have several candidates for public namespaces
                                                that have been brought up recently (or not so recently):
                                                map calibration
                                                multiple URLs per waypoint, route, etc
                                                display font size, style, color
                                                route width and color
                                                real-time tracking or NMEA data
                                                text annotations on maps

                                                I'd like to see us pick one or two of these, and have an interested
                                                subset of the group implement a public namespace extension. If the
                                                results are acceptable, I think this will become the preferred way for
                                                extending GPX in the future.

                                                What do you all think?

                                                --
                                                Dan Foster
                                                TopoGrafix - GPS Software, Waypoints, and Maps
                                                http://www.topografix.com - mailto:egroups@...
                                              • Sandro Franchi @ American Outland
                                                A separate namespace sounds perfect to me. Go ahead. Thanks. ... From: Dan Foster [mailto:egroups@topografix.com] Sent: Jueves, 24 de Julio de 2003 03:20 p.m.
                                                Message 23 of 23 , Jul 24, 2003
                                                • 0 Attachment
                                                  Message
                                                  A separate namespace sounds perfect to me. Go ahead.
                                                   
                                                  Thanks.
                                                  -----Original Message-----
                                                  From: Dan Foster [mailto:egroups@...]
                                                  Sent: Jueves, 24 de Julio de 2003 03:20 p.m.
                                                  To: gpsxml@yahoogroups.com
                                                  Subject: [gpsxml] Public namespace extensions

                                                  Hello,

                                                  I read through all the messages posted about map calibration
                                                  extensions, and it sounds like keeping map calibration data in its own
                                                  namespace is a solution that everyone would be willing to live with.
                                                  There is value in keeping the base GPX namespace simple.  The schema
                                                  is several pages long right now, and it's already difficult enough to
                                                  read for most people.  Having map calibration in a separate namespace
                                                  makes it very easy for people to ignore it if they don't plan to
                                                  support calibrated maps in their application.  For programs that do
                                                  support map calibration, it's a simple matter to include the
                                                  additional namespace.

                                                  There are already several examples of private namespace extensions to GPX.
                                                  groundspeak, topografix, and wissenbach are the ones I know of.  Each
                                                  of these is a private extension, with a single person or company
                                                  dictating the namespace extension, and free to change it at will.

                                                  We've talked in the past about creating public namespace extensions,
                                                  but until now we haven't implemented any.  Public namespace extensions
                                                  would be identical to private ones, but this group (or some subset of
                                                  the group) would define the schema definition and approve changes to
                                                  it.  Presumably, public namespace extensions would be for things that
                                                  are general enough that they would be exchanged between multiple
                                                  programs.  Perhaps to keep them distinguished from private extensions,
                                                  they should use namespaces starting with gpx_. (gpx_mapcal, gpx_url, etc)

                                                  I feel that private and public namespace extensions are the best way
                                                  to extend the functionality of GPX while keeping the base GPX
                                                  namespace simple.  We have several candidates for public namespaces
                                                  that have been brought up recently (or not so recently):
                                                  map calibration
                                                  multiple URLs per waypoint, route, etc
                                                  display font size, style, color
                                                  route width and color
                                                  real-time tracking or NMEA data
                                                  text annotations on maps

                                                  I'd like to see us pick one or two of these, and have an interested
                                                  subset of the group implement a public namespace extension.  If the
                                                  results are acceptable, I think this will become the preferred way for
                                                  extending GPX in the future.

                                                  What do you all think?

                                                  --
                                                  Dan Foster
                                                  TopoGrafix - GPS Software, Waypoints, and Maps
                                                  http://www.topografix.com - mailto:egroups@...



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



                                                  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                                Your message has been successfully submitted and would be delivered to recipients shortly.