I would be grateful to anyone who can help me with these points:

1.  Is there a gpx convention for describing longitude and lattitude position
formats, for instance hddd mm ss s, hddd mm mm, British Grid, UTM, etc.  Without
this field, how does a gpx file describe the type of
position format of this data?

2.  What is the difference between <ele> and <geoid>?

3.  I don't understand <bounds> - what does a bounding rectangle do?

Answers on a postage stamp, please!

Regards,

Steve Galloway

Hello,

Sunday, September 15, 2002, 12:18:35 PM, Steve wrote:

s> I would be grateful to anyone who can help me with these points:

s> 1.  Is there a gpx convention for describing longitude and
s> latitude position formats, for instance hddd mm ss s, hddd mm mm,
s> British Grid, UTM, etc.  Without this field, how does a gpx file
s> describe the type of position format of this data?

GPX is a data transfer format, not a display format.  GPX always uses
WGS84 datum, decimal degrees.  This ensures that every GPX program
knows how to interpret the lat/lon values they receive from the GPX
file.

GPX-enabled programs can display the GPX data they receive in any
format they wish.  For example, if a GPS Utility user in the UK opened
a GPX file I saved with EasyGPS, it would display in British Grid
coordinates (assuming that was the display format set in GPS Utility)
even though EasyGPS and GPX know nothing about British Grid.

By the way, this is the way your GPS receiver works - all data is
stored in WGS84 datum internally, and it gets converted to your
favorite datum and grid format for display purposes.

s> 2.  What is the difference between <ele> and <geoid>?

<ele> Elevation - I didn't define this very precisely in the
documentation.  It means what you think it means - the height, in
meters above mean sea level, of an object.

<geoidheight> Height, in meters, of WGS-84 earth ellipsoid above mean
sea level at the point. (This value is useful if you're processing the
NMEA GGA message)

Why do we have both?  Kjeld (CetusGPS) wanted to be able to express
all of the data in the standard NMEA messages in GPX.  Geoid Height
was needed for that purpose.  For 99% of the applications out there,
<ele> is all you need.  If you care about geoid height, your GPS will
be happy to tell you the current value, and GPX has a place for you to
store it.

s> 3.  I don't understand <bounds> - what does a bounding rectangle do?

<bounds> is an optional tag which specifies the geographic area
covered by the data in the file.  Imagine that someone wrote a search
engine for GPX files, and you were using it to find all GPX data in
the UK.  If the <bounds> tag was present, the search engine could
quickly determine if the GPX file overlapped any part of the UK.  If
the <bounds> tag wasn't there, the search engine would have to test
each waypoint, route point, and track point in the GPX file to see if
any of them were located inside the UK.

We added a number of metadata tags (<bounds>, <keywords>, etc) to the
main <GPX> element to describe the GPX file to search engines,
websites, and other programs.

Of course, all of the tags discussed above are optional in GPX, so you
can ignore them if your application doesn't need them.

I hope this helps answer some of your questions about GPX!
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups@...

Hi,

Just for the benefit of us lurkers,
Anybody working towards SVG display of the GPX data?
How about XLST conversion from GPX to SVG? (or conversion w/o xlst ?)

Where I'm coming from:
Ok when I got my program downloading data from my Garmin
I went looking for a storage format I wouldn't have to invent.
I was hoping for something XML related - I found this group and GPX.
I read though all the messages in the archives, thought about it and
figured I've got nothing to lose and much to gain.
So now my program reads and writes GPX files. And supports drag and drop
of waypoints/routes/tracks from one GPX file to another.
(it's a hack - I'm parsing the XML in VB myself and I'm sure it'll break
eventually :)

One of the things on my 'shopping list' was displaying the GPS/GPX data in
a graphical format. (on a web page - not a window's picture box)
I go looking at the few sites with GPX samples and I find they show mostly
text/HTML
representations of the data. Some may have GPX information overlaid on JPG's
...
but that's not quite what I'm looking for.
I don't want to dust off my Flash/SWF writing code so, I take a look at SVG
instead.
(it's already XML and I didn't want to add another 20 classes to my project
anyway :)
I've zero experience with XSLT but I'm not shy of VB :) so now my GPX files can
be exported as SVG. (well actually they're 'your' GPX files :)
Kinda simple and clumsy SVG right now but it's early days.

Before I go off charging further down this avenue I figured I should touch base
and find out what the concensus on that avenue is.
My avenue leads to GPX integrated with other content into web pages.
GPX data displayed as SVG in one frame with media content displayed in other
frames.
Click on a waypoint and up comes a picture or pano or web page.
I'm toying with ideas for GPX display in a psuedo/virtual GPS ... (think Flash
thingy's)
with pannable maps and searchable content. At least that's the plan/dream ...

Anybody have any suggestions or comments on all that?

Think that's enough for my first post ...

- Les Johnson

PS: Thanks Dan, Kjeld, et al for all the work you've put into making GPX a real
thing.

Hello,

Wednesday, September 18, 2002, 5:59:12 AM, Les wrote:

L> Just for the benefit of us lurkers,
L> Anybody working towards SVG display of the GPX data?
L> How about XLST conversion from GPX to SVG? (or conversion w/o xlst ?)

L> Where I'm coming from:
L> Ok when I got my program downloading data from my Garmin
L> I went looking for a storage format I wouldn't have to invent.
L> I was hoping for something XML related - I found this group and GPX.
L> I read though all the messages in the archives, thought about it and
L> figured I've got nothing to lose and much to gain.
L> So now my program reads and writes GPX files. And supports drag and drop
L> of waypoints/routes/tracks from one GPX file to another.
L> (it's a hack - I'm parsing the XML in VB myself and I'm sure it'll break
L> eventually :)

L> One of the things on my 'shopping list' was displaying the GPS/GPX data in
L> a graphical format. (on a web page - not a window's picture box)
L> I go looking at the few sites with GPX samples and I find they show mostly
L> text/HTML
L> representations of the data. Some may have GPX information overlaid on JPG's
L> ...
L> but that's not quite what I'm looking for.
L> I don't want to dust off my Flash/SWF writing code so, I take a look at SVG
L> instead.
L> (it's already XML and I didn't want to add another 20 classes to my project
L> anyway :)
L> I've zero experience with XSLT but I'm not shy of VB :) so now my GPX files
can
L> be exported as SVG. (well actually they're 'your' GPX files :)
L> Kinda simple and clumsy SVG right now but it's early days.

L> Before I go off charging further down this avenue I figured I should touch
base
L> and find out what the concensus on that avenue is.
L> My avenue leads to GPX integrated with other content into web pages.
L> GPX data displayed as SVG in one frame with media content displayed in other
L> frames.
L> Click on a waypoint and up comes a picture or pano or web page.
L> I'm toying with ideas for GPX display in a psuedo/virtual GPS ... (think
Flash
L> thingy's)
L> with pannable maps and searchable content. At least that's the plan/dream ...

L> Anybody have any suggestions or comments on all that?

L> Think that's enough for my first post ...

L> - Les Johnson

L> PS: Thanks Dan, Kjeld, et al for all the work you've put into making GPX a
real
L> thing.

Yes, I'm starting to look at SVG as well.

For anyone who doesn't know about Scalable Vector Graphics, it's an
XML language for controlling the display and positioning of text and
graphics.  It's like Flash, only XML-based.  Adobe makes a free SVG
plugin for your web browser, and it's likely that future browsers will
have SVG support built-in.

Some SVG links:
http://www.adobe.com/svg/viewer/install/main.html
http://www.adobe.com/svg/basics/intro.html

GPS tracking with SVG:
http://www.svgopen.org/papers/2002/bennett__gps_tracking_with_svg/

The Bennett demo is worth checking out.  It simulates tracking a car
through Minnesota, and lets you zoom in on maps to get a more detailed
view of any part of the state.

Here's what I've been doing with SVG:
Eventually, I'd like to be able to transform any GPX file into an SVG
map using XSLT.  Since I'm still getting up to speed on SVG and XSLT,
I decided to start by hacking up ExpertGPS to export SVG files
directly.  Once I get that working to my liking, I'll try to create an
XSL transform that converts my GPX output to match my SVG output.

A few general questions:
Does anyone know of a tool, preferably a freeware Win32 app, that will
take a generic XML file, transform it with a generic XSL file, and
output the transformed XML?  This seems like a basic development tool,
but I haven't been able to find one.

My initial attempt to create an XSL file that would transform XML to
SVG failed because Internet Explorer wouldn't recognise the result as
an SVG stream and wouldn't pass it to the Adobe plugin.  Anyone know a
way to do this, preferably without any server-side processing?

I'll try to put up some sample SVG maps in the next week or so.  The
Export SVG functionality will be in the next beta release of
ExpertGPS.

Anyone else using SVG, or interested in working together on a GPX->SVG
converter?

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

Thanks for your help, appreciated.. SJG

--- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
> Hello,
>
> Sunday, September 15, 2002, 12:18:35 PM, Steve wrote:
>
> s> I would be grateful to anyone who can help me with these points:
>
> s> 1.  Is there a gpx convention for describing longitude and
> s> latitude position formats, for instance hddd mm ss s, hddd mm mm,
> s> British Grid, UTM, etc.  Without this field, how does a gpx file
> s> describe the type of position format of this data?
>
> GPX is a data transfer format, not a display format.  GPX always uses
> WGS84 datum, decimal degrees.  This ensures that every GPX program
> knows how to interpret the lat/lon values they receive from the GPX
> file.
>
> GPX-enabled programs can display the GPX data they receive in any
> format they wish.  For example, if a GPS Utility user in the UK opened
> a GPX file I saved with EasyGPS, it would display in British Grid
> coordinates (assuming that was the display format set in GPS Utility)
> even though EasyGPS and GPX know nothing about British Grid.
>
> By the way, this is the way your GPS receiver works - all data is
> stored in WGS84 datum internally, and it gets converted to your
> favorite datum and grid format for display purposes.
>
> s> 2.  What is the difference between <ele> and <geoid>?
>
> <ele> Elevation - I didn't define this very precisely in the
> documentation.  It means what you think it means - the height, in
> meters above mean sea level, of an object.
>
> <geoidheight> Height, in meters, of WGS-84 earth ellipsoid above mean
> sea level at the point. (This value is useful if you're processing the
> NMEA GGA message)
>
> Why do we have both?  Kjeld (CetusGPS) wanted to be able to express
> all of the data in the standard NMEA messages in GPX.  Geoid Height
> was needed for that purpose.  For 99% of the applications out there,
> <ele> is all you need.  If you care about geoid height, your GPS will
> be happy to tell you the current value, and GPX has a place for you to
> store it.
>
> s> 3.  I don't understand <bounds> - what does a bounding rectangle do?
>
> <bounds> is an optional tag which specifies the geographic area
> covered by the data in the file.  Imagine that someone wrote a search
> engine for GPX files, and you were using it to find all GPX data in
> the UK.  If the <bounds> tag was present, the search engine could
> quickly determine if the GPX file overlapped any part of the UK.  If
> the <bounds> tag wasn't there, the search engine would have to test
> each waypoint, route point, and track point in the GPX file to see if
> any of them were located inside the UK.
>
> We added a number of metadata tags (<bounds>, <keywords>, etc) to the
> main <GPX> element to describe the GPX file to search engines,
> websites, and other programs.
>
> Of course, all of the tags discussed above are optional in GPX, so you
> can ignore them if your application doesn't need them.
>
> I hope this helps answer some of your questions about GPX!
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups@t...

> A few general questions:
> Does anyone know of a tool, preferably a freeware Win32 app, that
will
> take a generic XML file, transform it with a generic XSL file, and
> output the transformed XML?  This seems like a basic development
tool,
> but I haven't been able to find one.

Yup. On MSDN you'll find msxsl.exe, a command line tool that will do
this. The syntax is

msxsl generic.xml generic.xsl -o transformed.xml

Go to http://msdn.microsoft.com/downloads/default.asp?
URL=/code/sample.asp?url=/msdn-files/027/001/485/msdncompositedoc.xml

or, in case Yahoo munged the URL, just search msdn on "msxsl.exe" -
one result is returned.

Binary and source is available for download.

Don

--- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
> Hello,
>
> Anyone else using SVG, or interested in working together on a GPX-
>SVG
> converter?
>
I'm interested in using SVG, but with a slightly different twist.
I'd like to use the SVG coordinate transform as a way of
Georeferencing basemaps. SVG requires that both PNG and JPEG image
types be supported. What I'd do is publish a GPX file with a
reference to the SVG basemap, which in turn would reference either
PNG or JPEG image data. The SVG and associated JPEG/PNG data would
be output by the program at the time that the GPX file was written.

This SVG basemap data would serve as a sort of universal screen dump
of the GPX file. I think that the basemap could also include the
vector representation of the GPX trails in SVG format, or the trail
could be output without the SVG.

I don't have the time to develop this idea in the next few months
because of both employment and continuing education.

But I'm very interested in SVG as a method of representing image
data (of all kinds.)

Dave


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

Hi, Crew.

I've not (yet) asked the user whence said file came, but it's an
interesting question.   What localization is legal in a GPX file?
Is "1.00001" treated identically to "1,00001"?

I'm handing the data to sscanf which claims to be able to handle this.
But before I get into bits and bytes with the user, I'd like help
determing what exactly is legal in this regard in well-formed GPX.

Assume that "gpx" in his question below means my implementation of
the GPX reader in gpsbabel via expat and not the actual file format.

Thanx,
RJL





> To: "Robert Lipe" <robertlipe@...>
>
>    A  friend in the Netherlands tested a pre-release of gpsbabel with
>    holux support, but the program didn't work for him.
>
>    After I looked at his files I found  the problem.
>
>    The gpx file he created used "," as a decimal point.
>
>    In most European countries ","  (comma) is the decimal point and gpx
>    cant work with it.
>
>    Is there a way ( like an option or better two options, one for input
>    and one for output ) to implement this into gpsbabel?


----

Gpsbabel now supports Garmin and Windows.   See http://gpsbabel.sourceforge.net

Hello,

Sunday, September 22, 2002, 10:39:13 PM, Robert wrote:

R> Hi, Crew.

R> I've not (yet) asked the user whence said file came, but it's an
R> interesting question.   What localization is legal in a GPX file?
R> Is "1.00001" treated identically to "1,00001"?

R> I'm handing the data to sscanf which claims to be able to handle this.
R> But before I get into bits and bytes with the user, I'd like help
R> determing what exactly is legal in this regard in well-formed GPX.

A quick check with SAXCount.exe shows that lat="1,0001" contains
invalid characters for the latitudeType defined in GPX.xsd

If you have a question about whether some GPX data is valid, your
first step should be to check the validator.  That's what it's for.
http://www.topografix.com/gpx_validation.asp

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

Hello,

Several of us are working on programs that can use a bitmap image as a
basemap.  I'd like to start a discussion about exchanging map
calibration information using GPX.  I've included a sample XML snippet
below, which shows the "gpxmap" structure that I've been using as a
prototype.  The <mappt> structures hold the georeferencing information
- they associate a lat/lon coordinate pair with a specific pixel
location on the map.

<gpxmap:map url="D:\MyMaps\SampleMap.jpg">
  <name>Hiking Trails in the Middlesex Fells Reservation</name>
  <mappt lat="42.449383000" lon="-71.086467000" x="342.0" y="117.0"/>
  <mappt lat="42.443667000" lon="-71.072100000" x="877.0" y="403.0"/>
  <mappt lat="42.437933000" lon="-71.082850000" x="479.0" y="692.0"/>
</gpxmap:map>

Is anyone else interested in creating a public definition for map
calibration information?

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

--- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
>  I'd like to start a discussion about exchanging map
> calibration information using GPX.

How about using the "world file" specs instead of creating another
format or "standard"?
  Aerial photographs and scanned topo-maps in JPG and TIFF format are
georeferenced using six numbers that describe the pixel size, the
latitude/longitude of the southwest corner, and the rotation of the
image (usually zero). The units used are UTM meters, so it should be
easy to plot GPS data over the image. The graphics would be in a
format compatible with other graphics and GIS projects. World files
have the extentions JGW and TFW.
  Terraserver delivers images and "world files" in this format.

Kevin Haywood

--- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
> Hello,
>
> Several of us are working on programs that can use a bitmap image
as a
> basemap.  I'd like to start a discussion about exchanging map
> calibration information using GPX.  I've included a sample XML
snippet
> below, which shows the "gpxmap" structure that I've been using as a
> prototype.  The <mappt> structures hold the georeferencing
information
> - they associate a lat/lon coordinate pair with a specific pixel
> location on the map.
>
> <gpxmap:map url="D:\MyMaps\SampleMap.jpg">
>  <name>Hiking Trails in the Middlesex Fells Reservation</name>
>  <mappt lat="42.449383000" lon="-71.086467000" x="342.0"
y="117.0"/>
>  <mappt lat="42.443667000" lon="-71.072100000" x="877.0"
y="403.0"/>
>  <mappt lat="42.437933000" lon="-71.082850000" x="479.0"
y="692.0"/>
> </gpxmap:map>
>
> Is anyone else interested in creating a public definition for map
> calibration information?
>
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups@t...

I think that the concept could be extended to include other metadata
as well. I published 50 copies of Wissenbach map, but I couldn't get
too much of Idaho on one CD. I'd like to convert my DRG files to PNG
files. (Pretty easy, just run tif2png), but I lose the metadata
necessary to georeference. A format like this one would let me put
the georeference information back. But I think that other metadata
might be useful as well.

This is probably way more complicated than what you're thinking, but
consider a PNG or JPEG format replacement for geotiff as a use case.
I prefer to use PNG because the compression is lossless, but I'd use
JPEG if I had to.

Hello,

Tuesday, September 24, 2002, 10:17:48 AM, I wrote:

D> Is anyone else interested in creating a public definition for map
D> calibration information?

I made the classic mistake of including technical information along
with a philosophical question, so the responses I got back focused on
the technical side of things.

Here are the real questions I have.  Answers that start with "Yes" or
"No" are appreciated.

Should we extend the public definition of GPX to include related sets
of information?

Is "Map calibration information" (in some form or another) related
enough to be included in the public definition of GPX?

Is "Real-time positioning information" (in some form or another) related
enough to be included in the public definition of GPX?

Are there other sets of information that should be included in the
public definition of GPX?



Why am I asking these questions?
I believe that GPX should be extended to include vocabularies for
related sets of information.  We discussed this earlier in the GPX
forum, and one of the founding goals of GPX was that it would be
extensible.  Andrzej made a strong case for consolidating related
vocabularies with his GPSml schemas, where each "vocabulary set" had
its own schema.

I will be adding XML-based map calibration and real-time positioning
features to my ExpertGPS software.  I believe that these two features
are general enough that other software programs would benefit from a
public definition for exchanging this data.  If there's no interest in
developing a public definition, I'll define this elements as private
elements in my topografix: schema, and leave this discussion group
alone.  If there is interest within the group for creating a public
definition, or at least for collaborating on a private definition,
then I'll work with the interested parties to create a format for
interchanging this data.

I look forward to hearing your thoughts and opinions on this topic.

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

Hi there

It's been a while but I definitely haven't lost my interest in GPX.

>Here are the real questions I have.  Answers that start with "Yes" or
>"No" are appreciated.

Sorry but I have chosen to forget about the "Yes" and "No" stuff at each
question and instead tell what I think :-)

>Should we extend the public definition of GPX to include related sets
>of information?

In principle I like the idea of extending the GPX with related information
like Map calibration and definitely real time positioning information.

I am no expert into XML but maybe you could help me (and others) a little
by showing an example for each "information type".

One thing I like about GPX 1.0 tough is that it is simple to implement if
you just need to for instance read a waypoint list or a track.

To the extent possible I believe we should try to maintain this simplicity
for those who only need the data sets available in 1.0 and therefore I like
the idea of different vocabularies (one basic that represents 1.0, one for
map calibration info and one for real time positioning info).

Bottom line is "yes" but I would like to see some examples written by those
of you who knows more about XML than I do :-)

Kjeld

______________________
Kjeld Jensen
N 55° 22' E 10° 24'
Email: kjeld@...
http://www.CetusGPS.dk

Hello,

Wednesday, October 9, 2002, 3:50:45 PM, Kjeld wrote:

>>Should we extend the public definition of GPX to include related sets
>>of information?

K> In principle I like the idea of extending the GPX with related information
K> like Map calibration and definitely real time positioning information.

K> I am no expert into XML but maybe you could help me (and others) a little
K> by showing an example for each "information type".

K> One thing I like about GPX 1.0 though is that it is simple to implement if
K> you just need to for instance read a waypoint list or a track.

K> To the extent possible I believe we should try to maintain this simplicity
K> for those who only need the data sets available in 1.0 and therefore I like
K> the idea of different vocabularies (one basic that represents 1.0, one for
K> map calibration info and one for real time positioning info).

K> Bottom line is "yes" but I would like to see some examples written by those
K> of you who knows more about XML than I do :-)

If we expand GPX, we should do it in a way that preserves the
simplicity it has today.

The way to extend GPX while preserving the simplicity is to create new
namespaces to describe the new features.  GPX authors then only have
to worry about the namespaces that they care about.  We already have
the existing GPX namespace, which you include in your GPX documents
this way:

xmlns="http://www.topografix.com/GPX/1/0"

Some of us include our own private namespaces, which add additional
features which only our programs use:

xmlns:topografix="http://www.topografix.com/GPX/Private/TopoGrafix/0/1"
xmlns:wissenbach="http://www.cableone.net/cdwissenbach"

If you don't care about TopoGrafix Active Points, or Wissenbach Map
Layers, you don't need to include those namespaces in your documents,
or extend your GPX parser to interpret them correctly.  This would
also apply to any public extensions to GPX we create.  They are
entirely optional, and you can ignore them and just use the main GPX
namespace if you only care about waypoints, routes, and tracks.

There are two areas that have been mentioned as possible candidates
for their own public GPX extensions: maps, and real-time tracking.
There are probably other areas for extension as well.  Feel free to
suggest some.

Adding a public map extension would allow you to specify a map to go
along with your GPS data, and optionally provide calibration
information that allows a mapping program to position your GPS data on
the map at the correct locations.  I've already created my own private
namespace for expressing this in GPX, and have a working demo in which
a GPX file can be displayed on my website as a graphic map (using SVG)
and then downloaded and opened in ExpertGPS, where the data is
displayed over a jpeg image specified in the GPX file.

Here's a hypothetical namespace for GPX maps, and a sample:
xmlns:gpxmap="http://www.topografix.com/GPX/Map/1/0"

<!-- the waypoints in this GPX file were taken from this map -->
<gpxmap:map url="http://www.grandcanyon.com/fakeURL/trailmap.jpg">
  <gpxmap:width>640</gpxmap:width>
  <gpxmap:height>640</gpxmap:height>
  <gpxmap:height>480</gpxmap:height>
  <gpxmap:name>Trail Map of the Grand Canyon</gpxmap:name>
</gpxmap:map>

There are lots of optional things that can be included in map data.
The only required thing is the location of the map.  In addition to
the size of the map and the name of the map, you could also have:
  - map publication date
  - copyright/author info
  - calibration information for georeferencing the map
All of this would get wrapped up in the gpxmap schema.

Another area where several of us have expressed an interest in
extending GPX is in the real-time reporting of location data.  Andrzej
had a demo where he had a GPS attached to a cellphone, sending back
data about its speed and location to a web server using XML.  Others
on this list have an interest in tracking mobile users, to keep track
of delivery vans or to locate lost hikers.  Others may want to
experiment with transmitting NMEA data across the Internet in an XML
format.

I'll attempt to create an example of a real-time tracking extension to
GPX below.  While I've given it some thought, I haven't come up with a
good way to express time-sensitive information in XML yet.  And that's
my reason for wanting to create a public extension - to hear what all
you think!

Here's a hypothetical namespace for GPX tracking, and a sample:
xmlns:gpxtracking="http://www.topografix.com/GPX/Tracking/1/0"

<!-- www.bountyhunter.com - last known tracking data for fugitive Dan Foster -->
<gpxtracking:info>
  <gpxtracking:time>2002-07-25T03:27:54Z</gpxtracking:time>
  <gpxtracking:lat>42.5109</gpxtracking:lat>
  <gpxtracking:lon>42.5109</gpxtracking:lon>
  <gpxtracking:speed>75</gpxtracking:speed>
</gpxtracking:info>

Optional things that I could imagine being part of tracking object:
  - lat/lon
  - speed
  - timestamp
  - object ID (for tracking more than one object at a time)

Most of the difficulty I see for the tracking extension is figuring
out how to handle issues related to streaming data between devices.
It's not too hard to imagine how to send a position update to a web
server once per hour using GPX, but consider trying to send all the
data in a standard NMEA stream between devices every second.

Let me know if you'd like to see more examples of how using separate
namespaces can allow us to extend GPX while keeping the simplicity.
Just a reminder - the examples I gave above are just examples of what
a public definition COULD look like.  If we decide to go ahead with a
public collaboration, we'd follow the same process we used when
designing the original GPX spec.

Here's a complete sample of a GPX file containing a map reference (at
the end of the file)  I included three calibration points, as well as
specifying the name and size of the jpeg map that goes with the
waypoints in the file.

blue_hills.gpx:

<?xml version="1.0" standalone="yes"?>
<?xml-stylesheet type="text/xsl" href="details.xsl"?>
<gpx
  version="1.0"
  creator="ExpertGPS 1.1.1 - http://www.topografix.com"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://www.topografix.com/GPX/1/0"
  xmlns:gpxmap="http://www.topografix.com/GPX/Map/0/1"
  xsi:schemaLocation="http://www.topografix.com/GPX/1/0
http://www.topografix.com/GPX/1/0/gpx.xsd http://www.topografix.com/GPX/Map/0/1
http://www.topografix.com/GPX/Map/0/1/gpxmap.xsd">
<name><![CDATA[Blue Hills Reservation]]></name>
<desc><![CDATA[Riding in the Blue Hills is a mix of fast fire roads and
technical rock gardens.  Oh, and there's a hill around every corner, too.
Watch out for horses on the fire roads, and pick up a mountain bike trail map at
the Headquarters trailhead.  Trails marked in red are off-limits to bikes. 
Every intersection in the Blue Hills is marked with a 4 digit number, shown on
the map.
The Blue Hills are a great place to hike, as well!]]></desc>
<author><![CDATA[Dan Foster]]></author>
<email>trails@...</email>
<url><![CDATA[http://www.nemba.org/ridingzone/p_Blue_Hills_Reservation.html]]></\
url>
<urlname><![CDATA[Blue Hills description at NEMBA]]></urlname>
<time>2002-04-19T02:47:17Z</time>
<keywords><![CDATA[blue hills, mountain biking, milton]]></keywords>
<bounds minlat="42.204420" minlon="-71.123630" maxlat="42.228312"
maxlon="-71.069634"/>
<wpt lat="42.209547" lon="-71.119025">
  <ele>86.258400</ele>
  <time>2001-06-24T20:59:47Z</time>
  <name><![CDATA[LOOKOUT]]></name>
  <desc><![CDATA[Lookout Rock]]></desc>
  <sym>Summit</sym>
  <type><![CDATA[rock]]></type>
</wpt>
<wpt lat="42.218051" lon="-71.112672">
  <ele>114.041260</ele>
  <time>2001-10-13T23:50:58Z</time>
  <name><![CDATA[1072]]></name>
  <desc><![CDATA[1072]]></desc>
  <sym>Dot</sym>
  <type><![CDATA[Dot]]></type>
</wpt>
<gpxmap:map url="blue_hills_trail_map.jpg">
  <gpxmap:name>Blue Hills Mtn Bike Trails</gpxmap:name>
  <gpxmap:width>940</gpxmap:width>
  <gpxmap:height>600</gpxmap:height>
  <gpxmap:mappt lat="42.228475501" lon="-71.120628643" x="1.0" y="1.0"/>
  <gpxmap:mappt lat="42.228338019" lon="-71.064200124" x="939.0" y="1.0"/>
  <gpxmap:mappt lat="42.201942738" lon="-71.120819073" x="1.0" y="599.0"/>
</gpxmap:map>
</gpx>

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

I don't think this example of GPS/cell phone position updating-to-the-
internet is done in XML, but it gets the job done:
http://www.findu.com/cgi-bin/find.cgi?N5CV

Doug Cox

--- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
> Hello,
>
>
> If we expand GPX, we should do it in a way that preserves the
> simplicity it has today.
>
> The way to extend GPX while preserving the simplicity is to create
new
> namespaces to describe the new features.  GPX authors then only have
> to worry about the namespaces that they care about.  We already have
> the existing GPX namespace, which you include in your GPX documents
> this way:
>
> xmlns="http://www.topografix.com/GPX/1/0"
>
> Some of us include our own private namespaces, which add additional
> features which only our programs use:
>
>
xmlns:topografix="http://www.topografix.com/GPX/Private/TopoGrafix/0/1
"
> xmlns:wissenbach="http://www.cableone.net/cdwissenbach"
>
> If you don't care about TopoGrafix Active Points, or Wissenbach Map
> Layers, you don't need to include those namespaces in your
documents,
> or extend your GPX parser to interpret them correctly.  This would
> also apply to any public extensions to GPX we create.  They are
> entirely optional, and you can ignore them and just use the main GPX
> namespace if you only care about waypoints, routes, and tracks.
>
> There are two areas that have been mentioned as possible candidates
> for their own public GPX extensions: maps, and real-time tracking.
> There are probably other areas for extension as well.  Feel free to
> suggest some.
>
> Adding a public map extension would allow you to specify a map to go
> along with your GPS data, and optionally provide calibration
> information that allows a mapping program to position your GPS data
on
> the map at the correct locations.  I've already created my own
private
> namespace for expressing this in GPX, and have a working demo in
which
> a GPX file can be displayed on my website as a graphic map (using
SVG)
> and then downloaded and opened in ExpertGPS, where the data is
> displayed over a jpeg image specified in the GPX file.
>
> Here's a hypothetical namespace for GPX maps, and a sample:
> xmlns:gpxmap="http://www.topografix.com/GPX/Map/1/0"
>
> <!-- the waypoints in this GPX file were taken from this map -->
> <gpxmap:map url="http://www.grandcanyon.com/fakeURL/trailmap.jpg">
>  <gpxmap:width>640</gpxmap:width>
>  <gpxmap:height>640</gpxmap:height>
>  <gpxmap:height>480</gpxmap:height>
>  <gpxmap:name>Trail Map of the Grand Canyon</gpxmap:name>
> </gpxmap:map>
>
> There are lots of optional things that can be included in map data.
> The only required thing is the location of the map.  In addition to
> the size of the map and the name of the map, you could also have:
>  - map publication date
>  - copyright/author info
>  - calibration information for georeferencing the map
> All of this would get wrapped up in the gpxmap schema.
>
> Another area where several of us have expressed an interest in
> extending GPX is in the real-time reporting of location data.
Andrzej
> had a demo where he had a GPS attached to a cellphone, sending back
> data about its speed and location to a web server using XML.  Others
> on this list have an interest in tracking mobile users, to keep
track
> of delivery vans or to locate lost hikers.  Others may want to
> experiment with transmitting NMEA data across the Internet in an XML
> format.
>
> I'll attempt to create an example of a real-time tracking extension
to
> GPX below.  While I've given it some thought, I haven't come up
with a
> good way to express time-sensitive information in XML yet.  And
that's
> my reason for wanting to create a public extension - to hear what
all
> you think!
>
> Here's a hypothetical namespace for GPX tracking, and a sample:
> xmlns:gpxtracking="http://www.topografix.com/GPX/Tracking/1/0"
>
> <!-- www.bountyhunter.com - last known tracking data for fugitive
Dan Foster -->
> <gpxtracking:info>
>  <gpxtracking:time>2002-07-25T03:27:54Z</gpxtracking:time>
>  <gpxtracking:lat>42.5109</gpxtracking:lat>
>  <gpxtracking:lon>42.5109</gpxtracking:lon>
>  <gpxtracking:speed>75</gpxtracking:speed>
> </gpxtracking:info>
>
> Optional things that I could imagine being part of tracking object:
>  - lat/lon
>  - speed
>  - timestamp
>  - object ID (for tracking more than one object at a time)
>
> Most of the difficulty I see for the tracking extension is figuring
> out how to handle issues related to streaming data between devices.
> It's not too hard to imagine how to send a position update to a web
> server once per hour using GPX, but consider trying to send all the
> data in a standard NMEA stream between devices every second.
>
> Let me know if you'd like to see more examples of how using separate
> namespaces can allow us to extend GPX while keeping the simplicity.
> Just a reminder - the examples I gave above are just examples of
what
> a public definition COULD look like.  If we decide to go ahead with
a
> public collaboration, we'd follow the same process we used when
> designing the original GPX spec.
>
> Here's a complete sample of a GPX file containing a map reference
(at
> the end of the file)  I included three calibration points, as well
as
> specifying the name and size of the jpeg map that goes with the
> waypoints in the file.
>
> blue_hills.gpx:
>
> <?xml version="1.0" standalone="yes"?>
> <?xml-stylesheet type="text/xsl" href="details.xsl"?>
> <gpx
>  version="1.0"
>  creator="ExpertGPS 1.1.1 - http://www.topografix.com"
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>  xmlns="http://www.topografix.com/GPX/1/0"
>  xmlns:gpxmap="http://www.topografix.com/GPX/Map/0/1"
>  xsi:schemaLocation="http://www.topografix.com/GPX/1/0
http://www.topografix.com/GPX/1/0/gpx.xsd
http://www.topografix.com/GPX/Map/0/1
http://www.topografix.com/GPX/Map/0/1/gpxmap.xsd">
> <name><![CDATA[Blue Hills Reservation]]></name>
> <desc><![CDATA[Riding in the Blue Hills is a mix of fast fire roads
and technical rock gardens.  Oh, and there's a hill around every
corner, too.
> Watch out for horses on the fire roads, and pick up a mountain bike
trail map at the Headquarters trailhead.  Trails marked in red are
off-limits to bikes.  Every intersection in the Blue Hills is marked
with a 4 digit number, shown on the map.
> The Blue Hills are a great place to hike, as well!]]></desc>
> <author><![CDATA[Dan Foster]]></author>
> <email>trails@t...</email>
> <url><![CDATA
[http://www.nemba.org/ridingzone/p_Blue_Hills_Reservation.html]]
></url>
> <urlname><![CDATA[Blue Hills description at NEMBA]]></urlname>
> <time>2002-04-19T02:47:17Z</time>
> <keywords><![CDATA[blue hills, mountain biking, milton]]></keywords>
> <bounds minlat="42.204420" minlon="-71.123630" maxlat="42.228312"
maxlon="-71.069634"/>
> <wpt lat="42.209547" lon="-71.119025">
>  <ele>86.258400</ele>
>  <time>2001-06-24T20:59:47Z</time>
>  <name><![CDATA[LOOKOUT]]></name>
>  <desc><![CDATA[Lookout Rock]]></desc>
>  <sym>Summit</sym>
>  <type><![CDATA[rock]]></type>
> </wpt>
> <wpt lat="42.218051" lon="-71.112672">
>  <ele>114.041260</ele>
>  <time>2001-10-13T23:50:58Z</time>
>  <name><![CDATA[1072]]></name>
>  <desc><![CDATA[1072]]></desc>
>  <sym>Dot</sym>
>  <type><![CDATA[Dot]]></type>
> </wpt>
> <gpxmap:map url="blue_hills_trail_map.jpg">
>  <gpxmap:name>Blue Hills Mtn Bike Trails</gpxmap:name>
>  <gpxmap:width>940</gpxmap:width>
>  <gpxmap:height>600</gpxmap:height>
>  <gpxmap:mappt lat="42.228475501" lon="-71.120628643" x="1.0"
y="1.0"/>
>  <gpxmap:mappt lat="42.228338019" lon="-71.064200124" x="939.0"
y="1.0"/>
>  <gpxmap:mappt lat="42.201942738" lon="-71.120819073" x="1.0"
y="599.0"/>
> </gpxmap:map>
> </gpx>
>
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups@t...

I was implementing track suport in gpsbabel and came across what appears
to be either an error in the DTD or the spec.

If I mimic the <trkseg> tags in Dan's sample files, my output will validate.
But the string "trkseg" does not appear in the GPX specification.   This
doesn't seem right.

I can live with this being a correction to 1.0, but is it time for an erratum?

Which is considered authoritative, the spec or the validator?

RJL

Hello Robert,

Monday, October 28, 2002, 9:57:17 PM, you wrote:

R> I was implementing track suport in gpsbabel and came across what appears
R> to be either an error in the DTD or the spec.

R> If I mimic the <trkseg> tags in Dan's sample files, my output will validate.
R> But the string "trkseg" does not appear in the GPX specification.   This
R> doesn't seem right.

R> I can live with this being a correction to 1.0, but is it time for an
erratum?

R> Which is considered authoritative, the spec or the validator?

The GPX schema is authoritative.  I'll update the user's guide to
include the <trkseg> element from the schema.

While I'm updating the website, I'll be updating the list of GPX
applications and web services.  If you'd like your project listed at
http://www.topografix.com/gpx_resources.asp, let me know.  (I've
already heard from Scott M.)

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

Please have a look at:

http://www.gpskabel.de/geovcard/geovcardint.htm

I finally put it up. Please send any feedback, corrections, etc, to:
audiovisual@...




- Carsten
--
Carsten Kurz
TOMA MULTIVISION
Cologne/Germany
carsten.kurz@...

Hello,

I just updated the GPX website to include some new GPX programs and
websites, and I fixed the documentation to include <trkseg> and
correct some typos.

I've been using GPX in some larger mapping projects, and I have found
some things that I think should be included in GPX.  We added a <type>
element to <wpt>, <rtept>, and <trkpt> to allow users to classify
point data for their specific applications.  Example types:
"geocache", "intersection", "fire hydrant", "coffee shop".

I'd like to add a <type> element to <rte> and <trk> as well.  Example
types: "highway", "unpaved road", "pipeline", "tracklog from Magellan
GPS", "saved track".  Because it's a text field, users can store
anything they want there.  I'd like to be able to pass my mountain
bike trails from ExpertGPS to Wissenbach Map and TopoFusion and other
GPX programs, and still be able to sort my tracks based on the type of
trail surface.

What do you think?  Should we add <type> as an optional element to
<rte> and <trk>?

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

Dan Foster wrote:

> Hello,
>
> I just updated the GPX website to include some new GPX programs and
> websites, and I fixed the documentation to include <trkseg> and
> correct some typos.
>
> I've been using GPX in some larger mapping projects, and I have found
> some things that I think should be included in GPX.  We added a <type>
> element to <wpt>, <rtept>, and <trkpt> to allow users to classify
> point data for their specific applications.  Example types:
> "geocache", "intersection", "fire hydrant", "coffee shop".
>
> I'd like to add a <type> element to <rte> and <trk> as well.  Example
> types: "highway", "unpaved road", "pipeline", "tracklog from Magellan
> GPS", "saved track".  Because it's a text field, users can store
> anything they want there.  I'd like to be able to pass my mountain
> bike trails from ExpertGPS to Wissenbach Map and TopoFusion and other
> GPX programs, and still be able to sort my tracks based on the type of
> trail surface.
>
> What do you think?  Should we add <type> as an optional element to
> <rte> and <trk>?


Yes. Has my vote 100%.

PS> Any chance of moving this group to sourceforge instead of the yahoo
spambot? It's really getting on my tits.


---

I don't suffer from Insanity...  | Linux User #16396
	 I enjoy every minute of it... |
					 |
http://www.travellingkiwi.com/  |

Hello,

Monday, November 4, 2002, 11:01:50 AM, Hamish wrote:

PS>> Any chance of moving this group to sourceforge instead of the yahoo
H> spambot? It's really getting on my tits.

For anyone who might not know, Sourceforge is a website for Open
Source software development and collaboration.
http://www.sourceforge.net

I'd be more than happy to leave Yahoo Groups, if that's what the group
wants to do.  We originally picked Yahoo because we thought it would
be good to have a file repository and archives.  The file dump has
gotten a bit of use, but not much.  Sourceforge has files and
archives, and puts everything out in the open so people can browse
through our group before deciding to join the mailing list.  Moving to
Sourceforge would probably increase the number of open source projects
using GPX, which would be good for all of us.

I don't have any experience with Sourceforge mailing lists - anyone
care to comment?

Are there other standards groups using Sourceforge?  Most of the open
source projects on the site are applications.  We're a little
different - we'd be using Sourceforge for discussions of an open
interchange standard, with no actual source code on their site.

What do you all think?
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups@...

Dan Foster wrote:

> some things that I think should be included in GPX.  We added a <type>
> element to <wpt>, <rtept>, and <trkpt> to allow users to classify
> point data for their specific applications.  Example types:
> "geocache", "intersection", "fire hydrant", "coffee shop".

The problem with this is the same as the problem with our waypoint
icon id's: since they're free-form text they're difficult to use
programmatically.

But if it solves some problems for some people, go for it...

RJL

> gotten a bit of use, but not much.  Sourceforge has files and
> archives, and puts everything out in the open so people can browse
> through our group before deciding to join the mailing list.

Yes, it lowers the entry barrier for casual shoppers.

> Moving to Sourceforge would probably increase the number of open
> source projects using GPX, which would be good for all of us.

It's let GPX show up in a place more programmers are more likely to look.

> I don't have any experience with Sourceforge mailing lists - anyone
> care to comment?

I have experience with both.

Sourceforge uses the excellent 'mailman' mailing list manager that allows
you to turn knobs on archiving, searching, spam filtering, and so on.
Yahoo makes it really painful to read messages from the archives by
hijacking your pages  while sf merely adds a tag to th bottom of the
message.

> Are there other standards groups using Sourceforge?  Most of the
> open source projects on the site are applications.  We're a little

Project UDI (a standard for portable drivers that I'm involved in)
was one of the early projects on sf.  In the beginning, we used only
the mailling lists and later added code for a reference implementation.
We used the bug tracking system to track open issues in the spec and
so on.   It wasn't a terrible fit, but it was a little forced.

I think if you sold the "project" as the DTD or the spec instead of
actual code, you'd probably be welcomed.

RJL

--- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
> Hello,
>
> I just updated the GPX website to include some new GPX programs and
> websites, and I fixed the documentation to include <trkseg> and
> correct some typos.
>
> I've been using GPX in some larger mapping projects, and I have
found
> some things that I think should be included in GPX.  We added a
<type>
> element to <wpt>, <rtept>, and <trkpt> to allow users to classify
> point data for their specific applications.  Example types:
> "geocache", "intersection", "fire hydrant", "coffee shop".
>
> I'd like to add a <type> element to <rte> and <trk> as well.
Example
> types: "highway", "unpaved road", "pipeline", "tracklog from
Magellan
> GPS", "saved track".  Because it's a text field, users can store
> anything they want there.  I'd like to be able to pass my mountain
> bike trails from ExpertGPS to Wissenbach Map and TopoFusion and
other
> GPX programs, and still be able to sort my tracks based on the
type of
> trail surface.
>
> What do you think?  Should we add <type> as an optional element to
> <rte> and <trk>?
>
> --

I'm going to recycle my post number 90 below! Yes, we should add
<type> as an optional element, but I think that this should be an
enumeration, so that a program such as your gpx to svg converter can
interpret the data in a uniform manner. (I'd expect that the range
of values for this type is constantly changing, though.) While we're
at this, please consider the <mode> tag, as well. This tag would
provide further differentiation, such as pedestrian only, etc.
Perhaps there should be one <mode> tag for each allowed mode. While
we're adding tags, what about adding another top level tag called
<region>? I know that from time to time Farmer Brown comes onto the
GPS newsgroups and asks for a way to measure his fields.

Recycled post follows. Substitude type for <way>.

I recently purchased a trail map for an area of interest, the trails
of the Boise Front, so that I can use the proper trail names when
coding in XML format. A couple of features of this map that we are
missing in current format are the ability to describe the type of
road or trail, such as Roads, Streets, Gravel Roads, Primitive
Roads, Dual-track trails, ATV trails, single-track trails, and also
the ability to describe the modes of travel allowed (or possible).
Such as 4-WD, Motorized, Non-Motorized, pedestrian only, horse and
pedestrian only (Mountain Bike excluded), etc.

I think that this is something like a link, where in a route between
waypoints we might want all of these properties. I think that for a
trail we would also want all of these properties.

With this added data, I could post a trail or route without
misleading a person into the type of travel possible.

We could use tags such as <way>, one only, for air, road, street,
trail, etc, and <mode>, multiple allowed, for modes of travel.

What do you all think?

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

Hello,

Monday, November 4, 2002, 10:29:51 PM, Dave W. wrote:


d> Yes, we should add
d> <type> as an optional element, but I think that this should be an
d> enumeration, so that a program such as your gpx to svg converter can
d> interpret the data in a uniform manner. (I'd expect that the range
d> of values for this type is constantly changing, though.)

As a general principle, I don't like enumerated types in GPX.
Enumerated types make you choose from a list, and that means that
everyone who uses GPX is restricted to the choices we offer.
Restrictions are bad.

We didn't use an enumerated type for <sym>, even though it's possible
to track down every GPS ever created and make an exhaustive list of
all possible symbol names.  That would cause us to have to update the
spec whenever a new GPS is created with different symbols.

The free text in <sym> doesn't mean your application can't use an
enumerated type.  I use a drop list of symbol types in my programs,
and so I'll only emit <sym> data from that list.  If you send me
<sym>Watermelon</sym>, I'll just ignore it and use the default symbol
for your GPS, since I have no idea how to tell your GPS to draw a
watermelon.

<type> would be even more complicated to enumerate.  We could start
with the official list of USGS types, but that ignores entire
industries which might want to use <type> for their specialized data.
Why should we restrict the powerful monorail lobby from creating GPX
files that contain <type>Monorail</type>?

Another reason to avoid enumerated types is to keep the schema
understandable and maintainable.  A list of several dozen <type>
enumerations will double the size of the current schema.  What happens
when the list grows to a few hundred?

There are other ways to achieve compatibility between applications.
One, already mentioned, would be for the applications that need to
have compatibility to restrict user choices by using a droplist.

The other way is through documentation - if my map drawing program
only handles three types (trail, lake, road), I should make that part
of the documentation.  Users will quickly learn that if they want to
create a document that works with my map drawing program, they'll
need to restrict themselves to those three types.

I'm all for making "canonical lists" available for all to use.  I'm
currently verifying all the symbol names used in all the GPS receivers
my programs support, and I'll make this data publicly available when
it's done (draft at http://www.topografix.com/gps.xml).  I see that
Dave keeps a similar list on his website.

Any other thoughts on enumerated types?
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups@...

Over the years, when situations like this have come up, where there amounts
to an open ended list, we've adopted various approaches, and the one i like
best is:

1) Make the list 'open-ended' in the spec, meaning that there can always be
unspeced additions

2) Make the list 'open-ended' in implementation, usually by doing things
like having a drop down list but also a fill-in blank

3) Set up a 'standard' set of items that all implementations are expected to
deal with.

4) Set up 'reasonable' behavior for an implementation when the
implementation sees a 'non-standard' item from the list.

> -----Original Message-----
> From: Dan Foster [mailto:egroups@...]
> Sent: Tuesday, November 05, 2002 7:07 AM
> To: davewissenbach
> Subject: [gpsxml] enumerated types
>
>
> Hello,
>
> Monday, November 4, 2002, 10:29:51 PM, Dave W. wrote:
>
>
> d> Yes, we should add
> d> <type> as an optional element, but I think that this should be an
> d> enumeration, so that a program such as your gpx to svg
> converter can
> d> interpret the data in a uniform manner. (I'd expect that the range
> d> of values for this type is constantly changing, though.)
>
> As a general principle, I don't like enumerated types in GPX.
> Enumerated types make you choose from a list, and that means that
> everyone who uses GPX is restricted to the choices we offer.
> Restrictions are bad.
>
> We didn't use an enumerated type for <sym>, even though it's possible
> to track down every GPS ever created and make an exhaustive list of
> all possible symbol names.  That would cause us to have to update the
> spec whenever a new GPS is created with different symbols.
>
> The free text in <sym> doesn't mean your application can't use an
> enumerated type.  I use a drop list of symbol types in my programs,
> and so I'll only emit <sym> data from that list.  If you send me
> <sym>Watermelon</sym>, I'll just ignore it and use the default symbol
> for your GPS, since I have no idea how to tell your GPS to draw a
> watermelon.
>
> <type> would be even more complicated to enumerate.  We could start
> with the official list of USGS types, but that ignores entire
> industries which might want to use <type> for their specialized data.
> Why should we restrict the powerful monorail lobby from creating GPX
> files that contain <type>Monorail</type>?
>
> Another reason to avoid enumerated types is to keep the schema
> understandable and maintainable.  A list of several dozen <type>
> enumerations will double the size of the current schema.  What happens
> when the list grows to a few hundred?
>
> There are other ways to achieve compatibility between applications.
> One, already mentioned, would be for the applications that need to
> have compatibility to restrict user choices by using a droplist.
>
> The other way is through documentation - if my map drawing program
> only handles three types (trail, lake, road), I should make that part
> of the documentation.  Users will quickly learn that if they want to
> create a document that works with my map drawing program, they'll
> need to restrict themselves to those three types.
>
> I'm all for making "canonical lists" available for all to use.  I'm
> currently verifying all the symbol names used in all the GPS receivers
> my programs support, and I'll make this data publicly available when
> it's done (draft at http://www.topografix.com/gps.xml).  I see that
> Dave keeps a similar list on his website.
>
> Any other thoughts on enumerated types?
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups@...
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/2U_rlB/TM
> --------------------------------------------------------------
> -------~->
>
> 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/
>
>

--- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
> Hello,
>
> Monday, November 4, 2002, 10:29:51 PM, Dave W. wrote:
>
>
> d> Yes, we should add
> d> <type> as an optional element, but I think that this should be
an
> d> enumeration, so that a program such as your gpx to svg
converter can
> d> interpret the data in a uniform manner. (I'd expect that the
range
> d> of values for this type is constantly changing, though.)
>
> As a general principle, I don't like enumerated types in GPX.
> Enumerated types make you choose from a list, and that means that
> everyone who uses GPX is restricted to the choices we offer.
> Restrictions are bad.
>
> We didn't use an enumerated type for <sym>, even though it's
possible
> to track down every GPS ever created and make an exhaustive list of
> all possible symbol names.  That would cause us to have to update
the
> spec whenever a new GPS is created with different symbols.
>
> The free text in <sym> doesn't mean your application can't use an
> enumerated type.  I use a drop list of symbol types in my programs,
> and so I'll only emit <sym> data from that list.  If you send me
> <sym>Watermelon</sym>, I'll just ignore it and use the default
symbol
> for your GPS, since I have no idea how to tell your GPS to draw a
> watermelon.
>
> <type> would be even more complicated to enumerate.  We could start
> with the official list of USGS types, but that ignores entire
> industries which might want to use <type> for their specialized
data.
> Why should we restrict the powerful monorail lobby from creating
GPX
> files that contain <type>Monorail</type>?
>
> Another reason to avoid enumerated types is to keep the schema
> understandable and maintainable.  A list of several dozen <type>
> enumerations will double the size of the current schema.  What
happens
> when the list grows to a few hundred?
>
> There are other ways to achieve compatibility between applications.
> One, already mentioned, would be for the applications that need to
> have compatibility to restrict user choices by using a droplist.
>
> The other way is through documentation - if my map drawing program
> only handles three types (trail, lake, road), I should make that
part
> of the documentation.  Users will quickly learn that if they want
to
> create a document that works with my map drawing program, they'll
> need to restrict themselves to those three types.
>
> I'm all for making "canonical lists" available for all to use.  I'm
> currently verifying all the symbol names used in all the GPS
receivers
> my programs support, and I'll make this data publicly available
when
> it's done (draft at http://www.topografix.com/gps.xml).  I see that
> Dave keeps a similar list on his website.
>

Keeping well-known lists in the documentation might do the trick. I
advanced the idea of the enumerated type because of the confusion
that many people had with the <sym> element. I think that also we
might have similar confusion with the <type> element as used in
waypoints. I've got a couple of type values that my stylesheet keys
on, such as photograph, to instruct the stylesheet to display a
photo in the converted html.

Perhaps there's a way in the schema to create an open-ended type.
Those w3c guys seem to have thought of everything.

> Any other thoughts on enumerated types?
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups@t...

Agreed 100%

the data should not "have" meaning, it should "give" meaning (within an
application for example)...

if you know what i mean ;-)

c.

At 03:56 06/11/2002 +0000, you wrote:
>--- In gpsxml@y..., Dan Foster <egroups@t...> wrote:
> > Hello,
> >
> > Monday, November 4, 2002, 10:29:51 PM, Dave W. wrote:
> >
> >
> > d> Yes, we should add
> > d> <type> as an optional element, but I think that this should be
>an
> > d> enumeration, so that a program such as your gpx to svg
>converter can
> > d> interpret the data in a uniform manner. (I'd expect that the
>range
> > d> of values for this type is constantly changing, though.)
> >
> > As a general principle, I don't like enumerated types in GPX.
> > Enumerated types make you choose from a list, and that means that
> > everyone who uses GPX is restricted to the choices we offer.
> > Restrictions are bad.
> >
> > We didn't use an enumerated type for <sym>, even though it's
>possible
> > to track down every GPS ever created and make an exhaustive list of
> > all possible symbol names.  That would cause us to have to update
>the
> > spec whenever a new GPS is created with different symbols.
> >
> > The free text in <sym> doesn't mean your application can't use an
> > enumerated type.  I use a drop list of symbol types in my programs,
> > and so I'll only emit <sym> data from that list.  If you send me
> > <sym>Watermelon</sym>, I'll just ignore it and use the default
>symbol
> > for your GPS, since I have no idea how to tell your GPS to draw a
> > watermelon.
> >
> > <type> would be even more complicated to enumerate.  We could start
> > with the official list of USGS types, but that ignores entire
> > industries which might want to use <type> for their specialized
>data.
> > Why should we restrict the powerful monorail lobby from creating
>GPX
> > files that contain <type>Monorail</type>?
> >
> > Another reason to avoid enumerated types is to keep the schema
> > understandable and maintainable.  A list of several dozen <type>
> > enumerations will double the size of the current schema.  What
>happens
> > when the list grows to a few hundred?
> >
> > There are other ways to achieve compatibility between applications.
> > One, already mentioned, would be for the applications that need to
> > have compatibility to restrict user choices by using a droplist.
> >
> > The other way is through documentation - if my map drawing program
> > only handles three types (trail, lake, road), I should make that
>part
> > of the documentation.  Users will quickly learn that if they want
>to
> > create a document that works with my map drawing program, they'll
> > need to restrict themselves to those three types.
> >
> > I'm all for making "canonical lists" available for all to use.  I'm
> > currently verifying all the symbol names used in all the GPS
>receivers
> > my programs support, and I'll make this data publicly available
>when
> > it's done (draft at
> <http://www.topografix.com/gps.xml).>http://www.topografix.com/gps.xml).
> I see that
> > Dave keeps a similar list on his website.
> >
>
>Keeping well-known lists in the documentation might do the trick. I
>advanced the idea of the enumerated type because of the confusion
>that many people had with the <sym> element. I think that also we
>might have similar confusion with the <type> element as used in
>waypoints. I've got a couple of type values that my stylesheet keys
>on, such as photograph, to instruct the stylesheet to display a
>photo in the converted html.
>
>Perhaps there's a way in the schema to create an open-ended type.
>Those w3c guys seem to have thought of everything.
>
> > Any other thoughts on enumerated types?
> > --
> > Dan Foster
> > TopoGrafix - GPS Software, Waypoints, and Maps
> > <http://www.topografix.com>http://www.topografix.com - mailto:egroups@t...
>
>
>To unsubscribe from this group, send an email to:
>gpsxml-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to the
><http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.

Dan Foster wrote:

> As a general principle, I don't like enumerated types in GPX.
> Enumerated types make you choose from a list, and that means that
> everyone who uses GPX is restricted to the choices we offer.
> Restrictions are bad.

But guidelines are good.

GPSBabel, for example, swims in waypoint types.  It knows about dozens
of receiver combinations and tries to paper things up at the outer edges
but in the absence of guidelines on what's in GPX, most stuff just ends
up as "default"

> <type> would be even more complicated to enumerate.  We could start
> with the official list of USGS types, but that ignores entire
> industries which might want to use <type> for their specialized data.

But if we could offer suggested spellings for the most common types, it
would be a Good Thing.

If I spell it "Geocache - Virtual" and Irish spells it "Geocache" and
you call it "Virtual", we've failed in our goal of interoperability.

> I'm all for making "canonical lists" available for all to use.  I'm

That would solve it for me.  I'm not suggesting that we have cast a
formal, definitive list on clay tables but I think that a list of
suggested spellings for these sorts of things would further our goal.

RJL