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

Need clarification on gpx_style element

Expand Messages
  • David S. Wissenbach
    All, In message number 486, Dan Foster posted the proposal for the gpx_style schema and examples. I m updating Wissenbach Map3D to support mapping and
    Message 1 of 3 , Feb 14, 2004
    • 0 Attachment
      All,

      In message number 486, Dan Foster posted the proposal for the
      gpx_style schema and examples.

      I'm updating Wissenbach Map3D to support mapping and visualizing ski
      areas. To do this, I need color and line width support--beginner
      trails in green, advanced trails in blue, expert trails in black,
      dangerous trails in yellow, etc.

      In the posted examples demo.gpx, gpx_style is applied directly to a
      waypoint but not to a track--for track color the private
      topografix:color is applied.

      Should I add gpx_style:line properties directly to the track element
      (which I believe requires a schema change) or should I place this
      gpx_style:element within an <extensions> tag? I would prefer the
      placement of the gpx_style:line attributes directly within the track
      and not within an <extensions> element, although I have currently
      prototyped with the line attributes applied within the extensions
      wrapper.

      Also, what are the units of line width? I am assuming millimeters,
      because we are using metric units elsewhere in gpx.

      I also think that the ability to specify a dash pattern could also
      be useful.

      Thanks for any clarification--remember that any user of Wissenbach
      Map3D is a potential user of your programs as well! (Although I'm
      currently seeing only about 90 downloads a month).

      Regards,
      Dave Wissenbach
    • Dan Foster
      Hello, Saturday, February 14, 2004, 11:06:58 AM, Dave wrote: D In message number 486, Dan Foster posted the proposal for the D gpx_style schema and examples.
      Message 2 of 3 , Feb 17, 2004
      • 0 Attachment
        Hello,

        Saturday, February 14, 2004, 11:06:58 AM, Dave wrote:

        D> In message number 486, Dan Foster posted the proposal for the
        D> gpx_style schema and examples.

        D> In the posted examples demo.gpx, gpx_style is applied directly to a
        D> waypoint but not to a track--for track color the private
        D> topografix:color is applied.

        This was an error on my part. I edited an existing GPX file from
        ExpertGPS to add in the new gpx_style elements. Because there was no
        way to express color previously, I was using my own topografix:color
        extension to <trk>. With gpx_style, this becomes obsolete.

        D> Should I add gpx_style:line properties directly to the track element
        D> (which I believe requires a schema change) or should I place this
        D> gpx_style:element within an <extensions> tag?

        Anything that isn't in namespace "gpx" should go in <extensions>.
        (gpx_style, gpx_overlay, topografix, wissenbach, groundspeak)

        D> Also, what are the units of line width? I am assuming millimeters,
        D> because we are using metric units elsewhere in gpx.

        Pixels?

        Meters would make sense if we were actually specifying the width
        of the trail on the ground. I've never seen a map that shows trail
        widths to scale - you wouldn't be able to see the tracks on most maps.

        I've been using the Windows pen width as line width. I doubt there's
        much of a difference on Mac OSX or Linux.
        Line width 1 is the smallest visible width.
        Line width 4 is 4x thicker than #1.

        D> I also think that the ability to specify a dash pattern could also
        D> be useful.

        I think an SVG-style dash pattern would be appropriate.

        D> Thanks for any clarification--remember that any user of Wissenbach
        D> Map3D is a potential user of your programs as well! (Although I'm
        D> currently seeing only about 90 downloads a month).

        Thanks for pointing out the ambiguities! This is a good time to nail
        them down, as I'm just starting to implement gpx_style and gpx_overlay
        in ExpertGPS now. There is at least one other vendor working on
        styles and map overlays, so we will have plenty of opportunity for
        interoperability testing.

        --
        Dan Foster
        TopoGrafix - GPS Software, Waypoints, and Maps
        http://www.topografix.com - mailto:egroups@...
      • David S. Wissenbach
        ... element ... this ... OK. I ll keep style within extensions. ... millimeters, ... maps. ... there s ... I agree that we don t want to scale line width with
        Message 3 of 3 , Feb 17, 2004
        • 0 Attachment
          --- In gpsxml@yahoogroups.com, Dan Foster <egroups@t...> wrote:
          > Hello,
          >
          ...
          >
          > D> Should I add gpx_style:line properties directly to the track
          element
          > D> (which I believe requires a schema change) or should I place
          this
          > D> gpx_style:element within an <extensions> tag?
          >
          > Anything that isn't in namespace "gpx" should go in <extensions>.
          > (gpx_style, gpx_overlay, topografix, wissenbach, groundspeak)
          >

          OK. I'll keep style within extensions.

          > D> Also, what are the units of line width? I am assuming
          millimeters,
          > D> because we are using metric units elsewhere in gpx.
          >
          > Pixels?
          >
          > Meters would make sense if we were actually specifying the width
          > of the trail on the ground. I've never seen a map that shows trail
          > widths to scale - you wouldn't be able to see the tracks on most
          maps.
          >
          > I've been using the Windows pen width as line width. I doubt
          there's
          > much of a difference on Mac OSX or Linux.
          > Line width 1 is the smallest visible width.
          > Line width 4 is 4x thicker than #1.
          >

          I agree that we don't want to scale line width with the overall
          scale of the map. What I've done is scale line width to the screen
          resolution, even on the 3D view.

          Windows uses 72 or 96 dpi, Macintosh 92, I believe. On Linux the
          screen resolution is user-settable. The native resolution of most
          moniters at 0.25 mm dot pitch is more like 100 dpi. And when
          printing from my HP 7350 the resolution is 300, 600 or 1200 dpi
          depending on printer driver setting. That's why I proposed mm. But
          if we chose "points", where a point was about a 72 of an inch that
          could work too. Then just multiply line widths by 8 or so when
          printing.

          For better precision, the screen or printer resolution can be found
          as follows:

          int pixelsPerInch = pDC->GetDeviceCaps(LOGPIXELSX);

          > D> I also think that the ability to specify a dash pattern could
          also
          > D> be useful.
          >
          > I think an SVG-style dash pattern would be appropriate.
          >

          How about this?

          <trk>
          ...
          <extensions>
          <gpx_style:line>
          <gpx_style:color>0000ff</gpx_style:color>
          <gpx_style:width>3.00000</gpx_style:width>
          <gpx_style:dasharray>6.0 3.0</gpx_style:dasharray>
          </gpx_style:line>
          </extensions>
          </trk>

          Thanks for the reply. Let me know what you decide on units--we don't
          need an endless debate--good enough is good enough. I'll switch to
          using dots interpreted as points, where 1 dot is assumed to equal 72
          dpi for now. Then lines will look OK regardless of whether the
          widths are scaled to precise screen resolution or not.

          Dave

          > --
          > Dan Foster
          > TopoGrafix - GPS Software, Waypoints, and Maps
          > http://www.topografix.com - mailto:egroups@t...
        Your message has been successfully submitted and would be delivered to recipients shortly.