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

Extensions for route/track color, line width or map calibration

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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.