GPX is an open standard, and anyone is welcome to participate in its development and evolution. Click to join the current GPX Developers Mailing List. If you will be exporting or outputting GPX data from your software, hardware, or website, you are *strongly encouraged* to join the mailing list, share samples of your validated GPX output, and ensure that your design follows best practices and will be compatible with all other GPX implementations.
From 2001 until 2019, the GPX Developers mailing list was hosted at the now-defunct Yahoo Groups. An archive of those early discussions and GPX design decisions is hosted below. (Click a subject line or scroll down for full text of all archived messages)
Representation of time in track logsdavewissenbach+yahoo.com on Thu Sep 27 05:52:16 2001 (link)
- Time will be expressed in UTC, which seems to be expressed in XML like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC) Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445 This guiding principle for the representation of time is OK for a waypoint, but I think that it lacks precision for a track log where someone desires to measure speed. So I suggest that this <date-time> element (or attribute?) be part of a waypoint, track header, and route, but that a track log be allowed an additional optional time element which is a decimal offset, in seconds, from the base time.
chris+wilder-smith.org on Thu Sep 27 14:24:46 2001 (link)
Dave,
I agree with the concept of using a time offset in the track logs. It
almost seems to me that there has to be a different waypoint element for
use in tracklogs than in routes or as standalone waypoints if you want
to have support for validating the XML. The question is how would you
handle this DTD-wise? The easy way is to make it all optional, but that
puts more requirements on the parser side. I personally think that
tracks are different enough from routes that they should be explicitly
different elements. Something like this:
<track>
<point> <!-- initial point -->
<time>20010927T093014Z</time>
<lat>42.34567</lat>
<lon>-71.34567</lon>
<alt>57.234</alt>
</point>
<track-point>
<time-offset>12.34</time-offset>
<lat>42.456789</lat>
<lon>-71.456789</lon>
<alt>57.234</alt>
</track-point>
....
</track>
Where a route is built of all <point> elements. You still run into the
problem, DTD-wise where <time> should be optional in a route or waypoint
and you need it in the track for the initial point. You could make it a
separate element of track for the initial time and deal with duplicate
information where the optional time used in the initial <point> could be
ignored by the parser. That seems like it might be a better solution,
DTD and parser wise.
What do you think?
Regards,
Chris
davewissenbach+yahoo.com wrote:
>- Time will be expressed in UTC, which seems to be expressed in XML
>like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)
>Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445
>
>This guiding principle for the representation of time is OK for a
>waypoint, but I think that it lacks precision for a track log where
>someone desires to measure speed. So I suggest that this <date-time>
>element (or attribute?) be part of a waypoint, track header, and
>route, but that a track log be allowed an additional optional time
>element which is a decimal offset, in seconds, from the base time.
>
>
>
>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/
>
>
>
randyday+yahoo.com on Thu Sep 27 18:47:58 2001 (link), replying to msg
Is the offset from the last point or from the initial point? When does it wrap? Wouldn't it be simpler to just use a time format that has adequate precision? This would make parsing much easier and track manipulation much easier...say for example turning a track into a back-track route. It also makes each data element much more self- describing, which is a worth-while goal. --- In gpsxml+y..., Chris Wilder-Smith <chris+w...> wrote: > Dave, > > I agree with the concept of using a time offset in the track logs. It > almost seems to me that there has to be a different waypoint element for > use in tracklogs than in routes or as standalone waypoints if you want > to have support for validating the XML. The question is how would you > handle this DTD-wise? The easy way is to make it all optional, but that > puts more requirements on the parser side. I personally think that > tracks are different enough from routes that they should be explicitly > different elements. Something like this: > > <track> > <point> <!-- initial point --> > <time>20010927T093014Z</time> > <lat>42.34567</lat> > <lon>-71.34567</lon> > <alt>57.234</alt> > </point> > <track-point> > <time-offset>12.34</time-offset> > <lat>42.456789</lat> > <lon>-71.456789</lon> > <alt>57.234</alt> > </track-point> > .... > </track> > > Where a route is built of all <point> elements. You still run into the > problem, DTD-wise where <time> should be optional in a route or waypoint > and you need it in the track for the initial point. You could make it a > separate element of track for the initial time and deal with duplicate > information where the optional time used in the initial <point> could be > ignored by the parser. That seems like it might be a better solution, > DTD and parser wise. > > What do you think? > > Regards, > > Chris > > davewissenbach+y... wrote: > > >- Time will be expressed in UTC, which seems to be expressed in XML > >like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC) > >Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445 > > > >This guiding principle for the representation of time is OK for a > >waypoint, but I think that it lacks precision for a track log where > >someone desires to measure speed. So I suggest that this <date- time> > >element (or attribute?) be part of a waypoint, track header, and > >route, but that a track log be allowed an additional optional time > >element which is a decimal offset, in seconds, from the base time. > > > > > > > >To unsubscribe from this group, send an email to: > >gpsxml-unsubscribe+y... > > > > > > > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > >
chris+wilder-smith.org on Fri Sep 28 04:32:33 2001 (link)
<html>
<head>
</head>
<body>
Randy,<br>
<br>
I think it might make sense to have a higher precision timestamp in some
cases. At least a tenth of a second seems reasonable. Offsets in the track
log are nice because you can easily determine leg speed and compute averages
without having to deal with a full timestamp each time. I would give the
offset from the previous point, versus as a cumulative value from the initial
point. <br>
<br>
In my vision of things, a route wouldn't have times associated with it, but
if you were to go in that direction (for instance to give time estimates
for a back track, you'd have the offset associated with the point available).
When you get down to it, all the manipulations will happen on data structures
in memory and whatever calculations are needed can be done as the document
is parsed and the object representation is built. There are probably three
different rules you could use for making these decisions - what's easiest
for a program to output, what's easiest for a program to read in, or what's
easiest to use directly for whatever calculations are likely. I guess that
my initial opinion was to optimize for the particular calculations that I
envisioned. A question we need to ask is for which scenario should we optimize?
After we decide on that, and the follow on questions that answer implies,
we'll have an easier time on the design of the markup.<br>
<br>
Regards,<br>
<br>
Chris<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:randyday+yahoo.com">randyday+yahoo.com</a> wrote:<br>
<blockquote type="cite" cite="mid:9p0ks9+2jou+eGroups.com">
<pre wrap="">Is the offset from the last point or from the initial point? When <br>does it wrap? Wouldn't it be simpler to just use a time format that <br>has adequate precision? This would make parsing much easier and track <br>manipulation much easier...say for example turning a track into a <br>back-track route. It also makes each data element much more self-<br>describing, which is a worth-while goal.<br><br>--- In gpsxml+y..., Chris Wilder-Smith <a class="moz-txt-link-rfc2396E" href="mailto:chris+w..."><chris+w...></a> wrote:<br></pre>
<blockquote type="cite">
<pre wrap="">Dave,<br><br>I agree with the concept of using a time offset in the track logs. <br></pre>
</blockquote>
<pre wrap=""><!---->It <br></pre>
<blockquote type="cite">
<pre wrap="">almost seems to me that there has to be a different waypoint <br></pre>
</blockquote>
<pre wrap=""><!---->element for <br></pre>
<blockquote type="cite">
<pre wrap="">use in tracklogs than in routes or as standalone waypoints if you <br></pre>
</blockquote>
<pre wrap=""><!---->want <br></pre>
<blockquote type="cite">
<pre wrap="">to have support for validating the XML. The question is how would <br></pre>
</blockquote>
<pre wrap=""><!---->you <br></pre>
<blockquote type="cite">
<pre wrap="">handle this DTD-wise? The easy way is to make it all optional, but <br></pre>
</blockquote>
<pre wrap=""><!---->that <br></pre>
<blockquote type="cite">
<pre wrap="">puts more requirements on the parser side. I personally think that <br>tracks are different enough from routes that they should be <br></pre>
</blockquote>
<pre wrap=""><!---->explicitly <br></pre>
<blockquote type="cite">
<pre wrap="">different elements. Something like this:<br><br><track><br> <point> <!-- initial point --><br> <time>20010927T093014Z</time><br> <lat>42.34567</lat><br> <lon>-71.34567</lon><br> <alt>57.234</alt><br> </point><br> <track-point><br> <time-offset>12.34</time-offset><br> <lat>42.456789</lat><br> <lon>-71.456789</lon><br> <alt>57.234</alt><br> </track-point><br> ....<br></track><br><br>Where a route is built of all <point> elements. You still run into <br></pre>
</blockquote>
<pre wrap=""><!---->the <br></pre>
<blockquote type="cite">
<pre wrap="">problem, DTD-wise where <time> should be optional in a route or <br></pre>
</blockquote>
<pre wrap=""><!---->waypoint <br></pre>
<blockquote type="cite">
<pre wrap="">and you need it in the track for the initial point. You could make <br></pre>
</blockquote>
<pre wrap=""><!---->it a <br></pre>
<blockquote type="cite">
<pre wrap="">separate element of track for the initial time and deal with <br></pre>
</blockquote>
<pre wrap=""><!---->duplicate <br></pre>
<blockquote type="cite">
<pre wrap="">information where the optional time used in the initial <point> <br></pre>
</blockquote>
<pre wrap=""><!---->could be <br></pre>
<blockquote type="cite">
<pre wrap="">ignored by the parser. That seems like it might be a better <br></pre>
</blockquote>
<pre wrap=""><!---->solution, <br></pre>
<blockquote type="cite">
<pre wrap="">DTD and parser wise.<br><br>What do you think?<br><br>Regards,<br><br>Chris<br><br>davewissenbach+y... wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">- Time will be expressed in UTC, which seems to be expressed in <br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->XML <br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC)<br>Reference: <a class="moz-txt-link-freetext" href="http://www.ietf.org/rfc/rfc2445.txt?number=2445">http://www.ietf.org/rfc/rfc2445.txt?number=2445</a><br><br>This guiding principle for the representation of time is OK for a <br>waypoint, but I think that it lacks precision for a track log <br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->where <br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">someone desires to measure speed. So I suggest that this <date-<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->time> <br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">element (or attribute?) be part of a waypoint, track header, and <br>route, but that a track log be allowed an additional optional time <br>element which is a decimal offset, in seconds, from the base time.<br><br><br><br>To unsubscribe from this group, send an email to:<br>gpsxml-unsubscribe+y...<br><br><br><br>Your use of Yahoo! Groups is subject to <br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-freetext" href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a> <br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><br><br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!----><br><br>------------------------ Yahoo! Groups Sponsor ---------------------~--><br>Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!<br><a class="moz-txt-link-freetext" href="http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/2U_rlB/TM">http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/2U_rlB/TM</a><br>---------------------------------------------------------------------~-><br><br>To unsubscribe from this group, send an email to:<br><a class="moz-txt-link-abbreviated" href="mailto:gpsxml-unsubscribe+yahoogroups.com">gpsxml-unsubscribe+yahoogroups.com</a><br><br> <br><br>Your use of Yahoo! Groups is subject to <a class="moz-txt-link-freetext" href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a> <br><br><br><br></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
Misanthropist
N42 15.900 W071 21.069 Alt 56.7m/186'
</pre>
<br>
</body>
</html>
egroups+topografix.com on Fri Sep 28 09:40:00 2001 (link), replying to msg
Hello, Friday, September 28, 2001, 7:32:24 AM, Chris wrote: CWS> ?When you get down to it, all the manipulations will happen on data structures CWS> in memory and whatever calculations are needed can be done as the document CWS> is parsed and the object representation is built. ?There are probably three CWS> different rules you could use for making these decisions - what's easiest CWS> for a program to output, what's easiest for a program to read in, or what's CWS> easiest to use directly for whatever calculations are likely. ? I guess that CWS> my initial opinion was to optimize for the particular calculations that I CWS> envisioned. ?A question we need to ask is for which scenario should we optimize? CWS> After we decide on that, and the follow on questions that answer implies, CWS> we'll have an easier time on the design of the markup. I think Chris brings up a very important point. Without an agreement on what scenario we're designing and optimizing the XML format for, we won't be able to reach consensus on questions about individual elements and attributes. In the initial mailing I sent out, I proposed that we focus on the *interchange* of data between apps, rather than on a native storage format or a format that mirrored our internal object models. Some of us are writing new programs, and some of us have existing programs with much invested in our current objects. Everyone's going to be doing conversions of one sort or another to parse the text XML into binary objects in our applications. My preference would be to keep the XML interchange format limited to a small number of base elements with a limited number of required attributes. This will keep the work required to implement a 100% compliant parser to a minimum. On top of that, we should layer optional attributes that some subset of us might be able to interchange. If your application can't understand an optional attributes, no problem, you should just skip it. I don't know if everyone got the original message I sent out, so I'll post it again to the mailing list. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Fri Sep 28 09:43:12 2001 (link), replying to msg
Hello, Before we get to the task of building a common XML format for GPS data interchange, we need to agree on some basic principles and guidelines for defining our format. I've tried to express my thoughts and the comments I received from others in the message below. Please let me know what you think of this proposal, especially if there are sections you don't agree with. ------ Guiding principles: - A common XML data format for the exchange of GPS and location-based information between computers benefits everyone. It is in our interests and the interests of our users to create a common data exchange standard. - This is an open standard. It is controlled by no one person, and it is free from copyright and other legal meddling. - This is a data exchange format, not a data storage format. Applications are free to implement as much of the format as needed, and ignore parts of the data stream. The only requirement is that an application must be able to parse an arbitrary data stream without crashing. - This format allows for expansion. Private elements and attributes can be added to the format. To the extent possible, we will work together to define public structures that multiple applications can use, but any developer is free to add their own private data structures to any public element. - This standard is of no use unless people use it. To that end, it should be lightweight, easy to implement, and flexible enough to accommodate new features as it matures. - This format is about data exchange, not data validation. Device-specific details like the number of characters in a waypoint name do not belong in the exchange format, they belong in the end applications. On-disk representation: This format needs a standard file representation on disk. The proposed file extension is .gpx (combining GPS and eXchange...). Eventually, the format should have a common set of icons. Standard Data Types: The format will use standard data types (strings, floating point numbers, integers, etc) to represent data. Coordinate System and Units: - Coordinates will use WGS84 datum and signed decimal degrees format. - Time will be expressed in UTC, which seems to be expressed in XML like this: 20001108T093014Z (that's Nov 11, 2001, 09:30:14 UTC) Reference: http://www.ietf.org/rfc/rfc2445.txt?number=2445 - The metric system will be used for other measures. Elevations are in meters, for example. Waypoint Symbols: Most handheld GPS units associate an integer value with the waypoint symbol. This integer is useless without knowing what model of GPS is being referenced since some integers map to different symbols depending on the GPS model. Instead of using the integer value, this format will use the text associated with the waypoint symbol. - examples: Trail Head, Church, Diver Down Public vs. Private Data Structures To prevent collisions between publicly-adopted data structures and private data, a simple naming convention will be used. public names: short, generic words or abbreviations with no underscore - examples: ele, lat, id, name private names: must begin with program/developer abbreviation and underscore to prevent collisions with other private data. - examples: tg_userdata, tg_routecolor (TopoGrafix extensions) -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
kevin+synergysa.com.au on Fri Sep 28 10:01:19 2001 (link), replying to msg
Dan said > Snip > In the initial mailing I sent out, I proposed that we focus on the > *interchange* of data between apps, rather than on a native storage > format or a format that mirrored our internal object models. Some > of us are writing new programs, and some of us have existing > programs with much invested in our current objects. > Snip I certainly agree with this point. If the final GPX specification promotes the publicly-adopted data structures as a mandatory base for private usage, I see no reason why other mini standars cannot be spawned that extend GPX for other more specific requiremnets. i.e. The obvious one to me is Geocaching. Whilst the base spec satisfies most data requirements, standard extensions to GPX can be employed to provide additional geocache related information such as a narrative section for cache descriptions or a reference to the geocache user who planted the cache. Another extension could be in the aviation field where additional tags can be used for radio freqs and runway directions when route planning. Whilst the each of the examples show that GPX will not satisfy ALL requirements it does provide a great starting point for the base set of tags/attributes and structure of the XML packet. Perhaps a register can be kept along side the GPX spec to record the extensions to the base format. Kevin
larrywjames+yahoo.com on Fri Sep 28 11:08:36 2001 (link), replying to msg
I would like to argue for track points as a separate element from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as separate things. When you are importing from an exchange file to transfer to a GPS receiver, the software needs to know whether to send the point to the receiver as a track point or a waypoint. There is also the concept of whether the point starts a new track log or is a continuation of the same tracklog. One can imagine a real-time recorded file with a named waypoint which was marked in the middle of a bunch of unnamed track points. The time for a tracklog point should be the absolute time to fractional second accuracy (how about 20011108T093014.673Z which might actually work in some current parsers), not a differential time from some other point. People regularly use text editors to remove some points or groups of points from track log files. If they remove the reference track point, then all the other differentially-timed points become useless. Larry James James Associates 303-258-0576
egroups+topografix.com on Fri Sep 28 12:22:13 2001 (link), replying to msg
Hello,
Friday, September 28, 2001, 2:08:31 PM, Larry wrote:
lyc> I would like to argue for track points as a separate element from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as separate things. When you are
lyc> importing from an exchange file to transfer to a GPS receiver, the software needs to know whether to send the point to the receiver as a track point or a waypoint. There is also the concept of
lyc> whether the point starts a new track log or is a continuation of the same tracklog. One can imagine a real-time recorded file with a named waypoint which was marked in the middle of a bunch of
lyc> unnamed track points.
Let me try to explain a reason for keeping trackpoints and waypoints
the same. At the very simplest level, I think about these basic
elements in terms of their basic form. I strip away everything that I
possibly can from waypoints and tracklogs while still keeping them
valid. For example, a waypoint can still be a waypoint without
elevation. Can it be a waypoint without latitude? I don't believe so.
The very simplest waypoint is just a lat/lon pair. A route is just a
bunch of lat/lon pairs in an ordered collection. A tracklog is
identical to a route in its simplest form. In my thinking, I treat
routes and tracks identically. The fact that one is usually created
by adding waypoints to a list and the other is created by moving a
GPS around and recording data doesn't alter their common basic
structure.
But, as Larry points out, there are things that appear in tracklogs
that don't make much sense in waypoints. Things like "begin new
track". I can think of two ways to handle this, illustrated
below. I'm going to use <point> and <path> to represent my "minimal"
waypoint and route/track elements.
1. make it an optional tag for all points, even though it only makes
sense for those points that are included in a tracklog.
<path name="example tracklog with two sections">
<point lat="40.1" lon="-70.1" />
<point lat="40.2" lon="-70.2" />
<point lat="40.3" lon="-70.3" />
<point lat="50.1" lon="-80.1" new_track="true" />
<point lat="50.2" lon="-80.2" />
<point lat="50.3" lon="-80.3" />
</path>
2. add a new element into <path>. I'll make up a new element <link>
which describes the implied line segment connecting the two <point>
elements.
<path name="example tracklog with two sections">
<point lat="40.1" lon="-70.1" />
<point lat="40.2" lon="-70.2" />
<point lat="40.3" lon="-70.3" />
<link connected="false" />
<point lat="50.1" lon="-80.1" />
<point lat="50.2" lon="-80.2" />
<point lat="50.3" lon="-80.3" />
</path>
I prefer the 2nd approach myself. I can use this new <link> element
to describe a route, as well:
<path name="example route">
<point lat="40.1" lon="-70.1" />
<link description="US Route 40 East" />
<point lat="40.2" lon="-70.2" />
<link description="Highway 12" />
<point lat="40.3" lon="-70.3" />
</path>
I believe that three basic elements <point> <path> and <link>, plus a
bunch of completely optional attributes are sufficient to describe the
things most of us would want to exchange between GPS and mapping
programs:
waypoints
routes
routepoints
legs (descriptions of the things that connect the routepoints)
tracks
trackpoints
map annotations
areas
polygons
text labels
Take the example of a user drawing a polygon on a map in one of our
programs (not mine - I don't support it!). Perhaps this describes a
restricted area on a map. The program writes out some XML data like
this:
<path foo_shape="poly" foo_color="blue">
<point lat="40.1" lon="-70.1" />
<point lat="40.2" lon="-70.2" />
<point lat="40.3" lon="-70.3" />
</path>
My software has absolutely no idea what foo_shape and foo_color are,
but it knows to interpret <path> as a route by default. So it brings
in the polygon as a route which shows up on my map where the user can
see it and edit it.
Contrast this against using separate elements to describe each
slightly different data type:
<private_poly foo_color="blue">
<polypoint lat="40.1" lon="-70.1" />
<polypoint lat="40.2" lon="-70.2" />
<polypoint lat="40.3" lon="-70.3" />
</private_poly>
Here, my software doesn't know what a <private_poly> or a <polypoint>
is, so it ignores it. Nothing shows up after the import.
I prefer reusing elements as much as possible, to maximize the amount
of data that can be successfully exchanged between applications with
varied purposes, while minimizing the size and complexity of our
parsers.
How do others feel about this issue?
lyc> The time for a tracklog point should be the absolute time to fractional second accuracy (how about 20011108T093014.673Z which might actually work in some current parsers), not a differential
lyc> time from some other point. People regularly use text editors to remove some points or groups of points from track log files. If they remove the reference track point, then all the other
lyc> differentially-timed points become useless.
I agree completely on this.
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com
randyday+yahoo.com on Fri Sep 28 23:36:58 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Friday, September 28, 2001, 2:08:31 PM, Larry wrote: > > lyc> I would like to argue for track points as a separate element from waypoints. Most GPS applications, as well as storage within the GPS receiver, treat these as separate things. When you are > lyc> importing from an exchange file to transfer to a GPS receiver, the software needs to know whether to send the point to the receiver as a track point or a waypoint. There is also the concept of > lyc> whether the point starts a new track log or is a continuation of the same tracklog. One can imagine a real-time recorded file with a named waypoint which was marked in the middle of a bunch of > lyc> unnamed track points. > > Let me try to explain a reason for keeping trackpoints and waypoints > the same. At the very simplest level, I think about these basic > elements in terms of their basic form. I strip away everything that I > possibly can from waypoints and tracklogs while still keeping them > valid. For example, a waypoint can still be a waypoint without > elevation. Can it be a waypoint without latitude? I don't believe so. > The very simplest waypoint is just a lat/lon pair. A route is just a > bunch of lat/lon pairs in an ordered collection. A tracklog is > identical to a route in its simplest form. In my thinking, I treat > routes and tracks identically. The fact that one is usually created > by adding waypoints to a list and the other is created by moving a > GPS around and recording data doesn't alter their common basic > structure. > > But, as Larry points out, there are things that appear in tracklogs > that don't make much sense in waypoints. Things like "begin new > track". I can think of two ways to handle this, illustrated > below. I'm going to use <point> and <path> to represent my "minimal" > waypoint and route/track elements. > > 1. make it an optional tag for all points, even though it only makes > sense for those points that are included in a tracklog. > <path name="example tracklog with two sections"> > <point lat="40.1" lon="-70.1" /> > <point lat="40.2" lon="-70.2" /> > <point lat="40.3" lon="-70.3" /> > <point lat="50.1" lon="-80.1" new_track="true" /> > <point lat="50.2" lon="-80.2" /> > <point lat="50.3" lon="-80.3" /> > </path> > > 2. add a new element into <path>. I'll make up a new element <link> > which describes the implied line segment connecting the two <point> > elements. > <path name="example tracklog with two sections"> > <point lat="40.1" lon="-70.1" /> > <point lat="40.2" lon="-70.2" /> > <point lat="40.3" lon="-70.3" /> > <link connected="false" /> > <point lat="50.1" lon="-80.1" /> > <point lat="50.2" lon="-80.2" /> > <point lat="50.3" lon="-80.3" /> > </path> > > I prefer the 2nd approach myself. I can use this new <link> element > to describe a route, as well: > <path name="example route"> > <point lat="40.1" lon="-70.1" /> > <link description="US Route 40 East" /> > <point lat="40.2" lon="-70.2" /> > <link description="Highway 12" /> > <point lat="40.3" lon="-70.3" /> > </path> > > I believe that three basic elements <point> <path> and <link>, plus a > bunch of completely optional attributes are sufficient to describe the > things most of us would want to exchange between GPS and mapping > programs: > waypoints > routes > routepoints > legs (descriptions of the things that connect the routepoints) > tracks > trackpoints > map annotations > areas > polygons > text labels I guess I need more explanation of a <link> element. I'm not sure I appreciate its purpose or usefulness. If a track has two different sections, why not something like: <path name="section 1"> <point lat="40.1" lon="-70.1" /> <point lat="40.2" lon="-70.2" /> <point lat="40.3" lon="-70.3" /> </path> <path name="section 2"> <point lat="50.1" lon="-70.1" /> <point lat="50.2" lon="-70.2" /> <point lat="50.3" lon="-70.3" /> </path> > Take the example of a user drawing a polygon on a map in one of our > programs (not mine - I don't support it!). Perhaps this describes a > restricted area on a map. The program writes out some XML data like > this: > <path foo_shape="poly" foo_color="blue"> > <point lat="40.1" lon="-70.1" /> > <point lat="40.2" lon="-70.2" /> > <point lat="40.3" lon="-70.3" /> > </path> > > My software has absolutely no idea what foo_shape and foo_color are, > but it knows to interpret <path> as a route by default. So it brings > in the polygon as a route which shows up on my map where the user can > see it and edit it. > > Contrast this against using separate elements to describe each > slightly different data type: > <private_poly foo_color="blue"> > <polypoint lat="40.1" lon="-70.1" /> > <polypoint lat="40.2" lon="-70.2" /> > <polypoint lat="40.3" lon="-70.3" /> > </private_poly> > > Here, my software doesn't know what a <private_poly> or a <polypoint> > is, so it ignores it. Nothing shows up after the import. > > I prefer reusing elements as much as possible, to maximize the amount > of data that can be successfully exchanged between applications with > varied purposes, while minimizing the size and complexity of our > parsers. > > How do others feel about this issue? The example of a poly as a <path> versus a <private_poly> is very well put. > > lyc> The time for a tracklog point should be the absolute time to fractional second accuracy (how about 20011108T093014.673Z which might actually work in some current parsers), not a differential > lyc> time from some other point. People regularly use text editors to remove some points or groups of points from track log files. If they remove the reference track point, then all the other > lyc> differentially-timed points become useless. > > I agree completely on this. > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
egroups+topografix.com on Sun Sep 30 18:26:10 2001 (link), replying to msg
Hello, Saturday, September 29, 2001, 2:36:56 AM, Randy wrote: ryc> I guess I need more explanation of a <link> element. I'm not sure I ryc> appreciate its purpose or usefulness. <link> would describe any additional information about the connection between two <points> in a <path>. Things like speed wouldn't go in <link>, since they can be calculated directly from the two <points>. Imagine converting driving directions from MapBlast into GPX format. You'd have a list of <points>, but no place to store things like what highway you're travelling on. The highway isn't associated with point A or point B, it's associated with the connection between point A and point B. For most "pure" GPS applications where you're just recording data in and out of the GPS, <link> wouldn't get much use. If you've looked at the Garmin transfer protocol, you'll recall seeing link mentioned in their route protocol. They define things like "snap to road". I would add things like Larry's "start new track segment" to <link>, since it describes the fact that the section between two <points> has been broken due to a lost GPS signal. [Just in case anyone isn't familiar with this "start new track" situation, on a Garmin GPS if the user loses GPS signal or turns off the GPS while recording a tracklog, and then restores the signal, the GPS will keep the whole thing as one tracklog, but won't connect the trackpoints across the dropout when it displays the tracklog on the screen. It reports "start new track" when you read back the trackpoint where the signal was restored.] ryc> If a track has two different sections, why not something like: ryc> <path name="section 1"> ryc> <point lat="40.1" lon="-70.1" /> ryc> <point lat="40.2" lon="-70.2" /> ryc> <point lat="40.3" lon="-70.3" /> ryc> </path> ryc> <path name="section 2"> ryc> <point lat="50.1" lon="-70.1" /> ryc> <point lat="50.2" lon="-70.2" /> ryc> <point lat="50.3" lon="-70.3" /> ryc> </path> By making them into two separate <paths>, you've lost the fact that they were part of the same track. Maybe <link> isn't the best way to solve this particular case. The "start new track" situation comes about when the GPS loses lock (or when the user turns the GPS off, etc). Since people are going to want to store accuracy and signal strength info for <points>, maybe this problem can be addressed there. Maybe through a "valid" flag or some other mechanism. Although, when I think about it more, in Larry's situation, the <points> on either side of the "track dropout" are valid, and it's really the "segment between the points" that needs to be marked as "no data present". -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
randyday+yahoo.com on Tue Oct 02 23:10:47 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > <link> would describe any additional information about the connection > between two <points> in a <path>. Things like speed wouldn't go in > <link>, since they can be calculated directly from the two <points>. > > Imagine converting driving directions from MapBlast into GPX format. > You'd have a list of <points>, but no place to store things like what > highway you're travelling on. The highway isn't associated with point > A or point B, it's associated with the connection between point A and > point B. Ok, I see the functionality you are after. A construct like <link> is dependent on the <point> prior and after: should a track be edited, then there is potential for trouble. Should a <link> have references to its endpoints? Also, I'm not sure that I'd want to model driving directions in this manner... > ryc> If a track has two different sections, why not something like: > ryc> <path name="section 1"> > ryc> <point lat="40.1" lon="-70.1" /> > ryc> <point lat="40.2" lon="-70.2" /> > ryc> <point lat="40.3" lon="-70.3" /> > ryc> </path> > ryc> <path name="section 2"> > ryc> <point lat="50.1" lon="-70.1" /> > ryc> <point lat="50.2" lon="-70.2" /> > ryc> <point lat="50.3" lon="-70.3" /> > ryc> </path> > > By making them into two separate <paths>, you've lost the fact that > they were part of the same track. Is it important to retain the fact that they are part of the same track? (Serious question.) If a track is compossed of 1 or more sections, then why not model it as such? <path> <section> <point blah.../> <point blah.../> </section> <section> <point blah.../> <point blah.../> </section> </path> Extrapolating this idea to the driving directions example, if a portion of the drive is along I-90, and we want to associate this with a set of points, then that information would be attributes of the <section> of the <path> in question. The next portion of the route that's along I-5 would be a new <section>, with new attributes. This seems more general than the <link> construct in that it can apply to 2, 3, 4, or more points, not just two. It also solves the problem of making a <link> actually refer to the <points> in question. > > Maybe <link> isn't the best way to solve this particular case. The > "start new track" situation comes about when the GPS loses lock (or > when the user turns the GPS off, etc). Since people are going to want > to store accuracy and signal strength info for <points>, maybe this > problem can be addressed there. Maybe through a "valid" flag or some > other mechanism. Yes, I agree that accuracy and signal strength and number of stats used for the fix are things that people will want. > > Although, when I think about it more, in Larry's situation, the > <points> on either side of the "track dropout" are valid, and it's > really the "segment between the points" that needs to be marked as "no > data present". > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
jfmezei+videotron.ca on Fri Oct 12 00:55:51 2001 (link)
Ok, I have gone to the http://www.topografix.com/xml.asp page. I have seen the general idea of the XML format for waypoints. But the page talks about being THE place for the actual format definition, but I can't see to find the actual format definition. Is there some text document or must I run some of those windows applications to generate some sample XML format to see what the definitions are ?
chris+wilder-smith.org on Fri Oct 12 04:02:32 2001 (link)
jfmezei+videotron.ca wrote: >Ok, I have gone to the http://www.topografix.com/xml.asp page. > >I have seen the general idea of the XML format for waypoints. But the >page talks about being THE place for the actual format definition, but >I can't see to find the actual format definition. > >Is there some text document or must I run some of those windows >applications to generate some sample XML format to see what the >definitions are ? > Hi, As far as I know, there's no DTD yet. When some of the details are firmed up, a DTD should be created. Before that happens, the best you can do is to read the discussions and look at the example xml source. Regards, Chris
egroups+topografix.com on Sun Oct 14 10:05:24 2001 (link), replying to msg
Hello,
Wednesday, October 03, 2001, 2:10:44 AM, Randy wrote:
ryc> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
>> <link> would describe any additional information about the
ryc> connection
>> between two <points> in a <path>. Things like speed wouldn't go in
>> <link>, since they can be calculated directly from the two <points>.
>>
>> Imagine converting driving directions from MapBlast into GPX format.
>> You'd have a list of <points>, but no place to store things like
ryc> what
>> highway you're travelling on. The highway isn't associated with
ryc> point
>> A or point B, it's associated with the connection between point A
ryc> and
>> point B.
ryc> Ok, I see the functionality you are after. A construct like <link> is
ryc> dependent on the <point> prior and after: should a track be edited,
ryc> then there is potential for trouble. Should a <link> have references
ryc> to its endpoints?
I think the implied order of the file takes care of this. For
example, it's clear that the following three points are connected in
order:
<path>
<point> ... </point>
<point> ... </point>
<point> ... </point>
</path>
ryc> Also, I'm not sure that I'd want to model driving
ryc> directions in this manner...
I'm also struggling to find a good solution here. It may be that the
<link> element I proposed to store the "per-leg" information I keep in
my software doesn't have universal-enough appeal to make it into the
spec. Fine by me...
>> ryc> If a track has two different sections, why not something like:
>> ryc> <path name="section 1">
>> ryc> <point lat="40.1" lon="-70.1" />
>> ryc> <point lat="40.2" lon="-70.2" />
>> ryc> <point lat="40.3" lon="-70.3" />
>> ryc> </path>
>> ryc> <path name="section 2">
>> ryc> <point lat="50.1" lon="-70.1" />
>> ryc> <point lat="50.2" lon="-70.2" />
>> ryc> <point lat="50.3" lon="-70.3" />
>> ryc> </path>
>>
>> By making them into two separate <paths>, you've lost the fact that
>> they were part of the same track.
ryc> Is it important to retain the fact that they are part of the same
ryc> track? (Serious question.)
I think so. But I don't think it's so important that it requires a
new element. I prefer inserting an optional attribute into the first
point of the new segment to indicate that GPS lock was lost earlier.
ryc> If a track is compossed of 1 or more
ryc> sections, then why not model it as such?
ryc> <path>
ryc> <section>
ryc> <point blah.../>
ryc> <point blah.../>
ryc> </section>
ryc> <section>
ryc> <point blah.../>
ryc> <point blah.../>
ryc> </section>
ryc> </path>
I'd simplify things even more, and allow <path> to optionally contain other
<path> elements. Here are some examples - the last one is the
interesting one.
<path type="rte" desc="Route">
<point type="wpt" lat="42.1" lon="-71.2"/>
<point type="wpt" lat="42.2" lon="-71.2"/>
<point type="wpt" lat="42.3" lon="-71.2"/>
<point type="wpt" lat="42.4" lon="-71.2"/>
</path>
<path type="trk" desc="Garmin Tracklog No Breaks">
<point type="wpt" lat="42.1" lon="-71.2"/>
<point type="wpt" lat="42.2" lon="-71.2"/>
<point type="wpt" lat="42.3" lon="-71.2"/>
<point type="wpt" lat="42.4" lon="-71.2"/>
</path>
<path type="trk" desc="Garmin Tracklog No Breaks - Another Valid Version">
<path type="trk">
<point type="wpt" lat="42.1" lon="-71.2"/>
<point type="wpt" lat="42.2" lon="-71.2"/>
<point type="wpt" lat="42.3" lon="-71.2"/>
<point type="wpt" lat="42.4" lon="-71.2"/>
</path>
</path>
<path type="trk" desc="Garmin Tracklog With Breaks">
<path type="trk">
<point type="wpt" lat="42.1" lon="-71.2"/>
<point type="wpt" lat="42.2" lon="-71.2"/>
</path>
<path type="trk">
<point type="wpt" lat="42.3" lon="-71.2"/>
<point type="wpt" lat="42.4" lon="-71.2"/>
</path>
</path>
Thoughts?
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com
alan+computerweekly.net on Tue Oct 16 15:29:33 2001 (link)
I've just joined this new list and read the previous postings on the web site. I sent an e-mail to the link on the Topografix site and received a reply. I commentated that I thought the file format (as seen in the sample) was very wasteful in that too much was duplicated in the file and that it is very bloated with non-information padding. I was asked to "suggest ways to make our example file less wordy?" I suggested the use a single, or pair of characters to define a type of line. Dan Foster <egroups+topografix.com> replying to Randy wrote in [gpsxml]:- >>> Imagine converting driving directions from MapBlast into GPX format. You'd have a list of <points>, but no place to store things like what highway you're travelling on. The highway isn't associated point A or point B, it's associated with the connection between point A and point B. > I'm also struggling to find a good solution here. It may be that the <link> element I proposed to store the "per-leg" information I keep in my software doesn't have universal-enough appeal to make it into the spec. Fine by me... It depends on how one expects to use the data. I use my Garmin 75 when on holiday. I live in the UK and went to Germany as the example. At the end of each day, or when the track memory filled; I saved my GPS log onto my Psion 5. I can now plot each days travel onto a map (also on my Psion 5) of Germany. By editing this file, I could add extra details like places of interest or campsites used. This could then appear as waypoints on my maps. At present the waypoints are downloaded separately and converted into 'overlay' files, which are similar to Microsoft AutoRoute pushpin files (but unlike MS files can be exported !) When my photographs are returned from processing, I use the date/time printing on the back (APS film) with the GPS log, to tell me which town building is on any print. I could use this to make an overlay file of all photos taken and even include a text description of certain prints. Others would want to keep details of a future route where the road number and description between points of change in the route occur. By having one single file format with a pair of characters defining the line type it would be very easy for application software to use or discard any line of information. Any 'non-proprietary' like information could be added by having a 'comment' character ( ; ) start to that line. A later version could possibly incorporate that line type into the standard specification. -- Alan R Morris, G4ENS. Bury St Edmunds, Suffolk, UK. No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.
egroups+topografix.com on Tue Oct 16 15:47:34 2001 (link), replying to msg
Hello Alan, Tuesday, October 16, 2001, 7:28:40 PM, you wrote: AMG> I commentated that I thought the file format (as seen in the sample) was very wasteful in that too much was duplicated in the file and that it is very bloated with non-information padding. ... AMG> By having one single file format with a pair of characters defining the line type it would be very easy for application software to use or discard any line of information. AMG> Any 'non-proprietary' like information could be added by having a 'comment' character ( ; ) start to that line. A later version could possibly incorporate that line type into the standard AMG> specification. I'd need to see an example, but what you're describing sounds like a flat file format, and not an XML file. XML, while being rather wordy, has the advantage that it's self describing, and can be easily transformed into many other forms. There are already several "standard" flat file formats for describing GPS data. This group was formed to develop an XML format. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
jfmezei+videotron.ca on Wed Oct 17 04:01:16 2001 (link)
I would like to see a field in waypoints added (optional, of course) to include text describing the source of the waypoint. example: I would like to provide a list of waypoints for a bike trip across australia. Some of these waypoints come from my GPS , some come from AUSLIG and some come from Auslig's predecessor (MAN200R at erin.gov.au) Since each of these have their own precision (or lack thereof), if someone is to rely on that list I provide, it would be nice for them to be able to know which waypoints might be more precice (taken by GPS) and which might be off by some distance (MAN200R). Not sure there would be a need to defide the contents of that field. One could expect each provider of XML data sets to provide a description of that "source" field if it is to be used. comments ?
egroups+topografix.com on Wed Oct 17 14:10:48 2001 (link), replying to msg
Hello, I'd like to start putting together a list of attributes that might be included in the public version of the <point> element. Please add anything you think your application might use, or that you think others would benefit from. My take on this is that <point> should have a bare minimum of required attributes, and everything else should be optional. Here's a starting list. Please add your suggestions. For now, let's not debate what anything means or whether it should be on the list. Once we get a full list, we can combine similar items as needed and debate whether things belong as required, optional, or private. The format for the list below is: attribute, short description, format, units, example|example2 required for point: lat, latitude, double, WGS84 degrees, 45.1 lon, longitude, double, WGS84 degrees, -71.22344 type, what type of <point> element, text,, wpt|icon optional for point: ele, elevation, double, meters, 150.0 time, timestamp, text, 20001108T093014Z.120 (That's Nov 08, 2000 at 9:30:14.120 GMT) sym, waypoint symbol, text,, Trail Head wpt, waypoint id for GPS, text,, NEWYRK com, waypoint comment for GPS, text,, NEW YORK CITY desc, user's description, text,, Park your car here. map, user's map, text,, USGS 7.5 Boston North url, link to web, text,, http://www.weather.com/weather/local/USNY0996 hyp, text for url, text,, Weather Forecast for NYC kind, kind of waypoint, text,, Shopping Center src, source of data, text,, MAN200R at erin.gov.au hdop, Horiz Dilution of Precision, double,, 2.0 vdop, Vert Dilution of Precision, double,, 6.0 fix, Type of GPS Fix, text,, 2D|3D|no -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Oct 17 19:42:34 2001 (link), replying to msg
Hello, Wednesday, October 17, 2001, 10:10:21 PM, Henry wrote: HCS> Dan - HCS> This looks pretty good. A few things come to mind when I look at this: HCS> First, why only 3 or 4 character tags? I thought the point in XML was to HCS> have descriptive tags. For instance: <hyp> - I had to think for a minute HCS> to realize this means <hypertext>. I was trying to find a balance between readability and wordiness. For things that aren't obvious from the short form (I think lat="42.134" is pretty clear) the tags should be as long as needed to make it readable. HCS> Proximity waypoints - I don't use these myself but some people do. How about: HCS> proximity, proximity alarm distance, double, (See next comment), 50.0 sounds good. HCS> Why are units (and format) specified? I think these should be attributes: HCS> <latitude datum="WGS84" format="DMS" direction="N">40 25 23.9</latitude> HCS> <longitude datum="WGS84" format="degrees">-79.919467</longitude> HCS> <elevation unit="feet" base="MSL">1150</elevation> HCS> Can we even generalize this to handle UTM and Maidenhead Grid references? HCS> How about: HCS> <northing format="UTM">4475301</northing> HCS> <easting>0591663</easting> HCS> <zone>17T</zone> HCS> (is the attribute format="UTM" necessary, or is it implied by having a HCS> northing or easting tag?) HCS> and: HCS> <grid datum="maidenhead">FN00ak</grid> We discussed this in some of the earlier e-mails (archives are at http://groups.yahoo.com/group/gpsxml/messages) See the thread about XML Format: The Basics for some of the discussion. This is an interchange format, so it's designed to be easy for you to read my data with a minimal amount of work. If we passed the datum as an attribute, I could send you a bunch of waypoints in Qatar National Datum. Would you be able to convert it correctly? By standardizing on WGS84, decimal degrees, you're guaranteed that you'll be able to deal with incoming data. As long as you can convert to and from WGS84 deg.deg format into your preferred internal format, you can handle any GPSXML file coming your way. HCS> Of course, this necessitates defining what to do if an application doesn't HCS> understand an attribute. This could also be used to handle vendor specific HCS> information: HCS> <symbol garmin-icon="10/0">House</symbol> It's really up to the application to determine what to do with data it doesn't understand. For optional attributes you don't understand, you should ignore them. I'd ignore your proximity attributes, even though they are part of the public spec, since my app doesn't deal with proximity waypoints. The format allows for private attributes as well, so you'll need to be able to successfully parse this: <point type="wpt" lat="42.1" lon="-71.23" tg_active="true"/> Each of us as program writers will have to decide how to handle missing attributes that our programs might be expecting. For example, most GPS units want a waypoint to have an id, but it's currently an optional attribute in the spec. I'd handle that by keeping a counter and naming the waypoint WPT001, WPT002, etc, but this is really a program implementation issue and not part of the XML spec. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Wed Oct 17 21:03:42 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: I think that we should also consider a method of including an image with a type of point which is a landmark. I'm thinking here of the gpx format being used as a sort of a trail guide. But who knows how this will be used? One of the users of my unreleased freeware is using this to log Canoe trips. Who knew? I'm not too happy about the idea of the <point> element being all things too all people, although if the group agrees on this approach I'll deal with it. I suggest as an alternative something like the following, where a simple point is embedded in a more complicated landmark or waypoint. Or instead of embedding, we could define other elements which are kinds of points with different sets of attributes or included elements. <landmark id="L101"> <point lat="45.0" lon="-116" alt="800" date-time="whenever"> <name>Foote House</name> <description>This is the cabin of Mary Hallock Foote, whose diary was featured in Wallace Stegner's book, Angle of Repose </description> <image> image data goes here </image> </landmark> > Hello, > > I'd like to start putting together a list of attributes that might be > included in the public version of the <point> element. Please add > anything you think your application might use, or that you think > others would benefit from. My take on this is that <point> should > have a bare minimum of required attributes, and everything else should > be optional. > > Here's a starting list. Please add your suggestions. For now, let's > not debate what anything means or whether it should be on the list. > Once we get a full list, we can combine similar items as needed and > debate whether things belong as required, optional, or private. > > The format for the list below is: > attribute, short description, format, units, example|example2 > > required for point: > lat, latitude, double, WGS84 degrees, 45.1 > lon, longitude, double, WGS84 degrees, -71.22344 > type, what type of <point> element, text,, wpt|icon > > optional for point: > ele, elevation, double, meters, 150.0 > time, timestamp, text, 20001108T093014Z.120 (That's Nov 08, 2000 at > 9:30:14.120 GMT) > sym, waypoint symbol, text,, Trail Head > wpt, waypoint id for GPS, text,, NEWYRK > com, waypoint comment for GPS, text,, NEW YORK CITY > desc, user's description, text,, Park your car here. > map, user's map, text,, USGS 7.5 Boston North > url, link to web, text,, http://www.weather.com/weather/local/USNY0996 > hyp, text for url, text,, Weather Forecast for NYC > kind, kind of waypoint, text,, Shopping Center > src, source of data, text,, MAN200R at erin.gov.au > hdop, Horiz Dilution of Precision, double,, 2.0 > vdop, Vert Dilution of Precision, double,, 6.0 > fix, Type of GPS Fix, text,, 2D|3D|no > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
jfmezei+videotron.ca on Wed Oct 17 22:59:16 2001 (link), replying to msg
A few comments: re: WGS84. I tend to agree that the interchange format should be standardized. Since my GPS unit wants units in WGS84 during data transfers, I am biased towards that standard. However, if this is to be a long term flexible standard, shouldn't there be a way to define the datum used in the header ? WGS84 could be defined as the default datum if not specified. for instance: <loc version="1.0" src="EasyGPS" datum="WSG84"> ---- One "problem" I have with the definitions/terminology is the ability to provide different names to a waypoint. on the web site, a construct such as: <waypoint><name id="CACHE">FellsFolly Geocache</name> is used. id= would probably correspond to the "wpt" field in your list. (so perhaps "wpt" should be renamed to "ID". Would "FellsFolly Geocache" be considered the "com" (comment) ? The Garmin basic waypoint contains the indent X(6) and a "comment" field X(40). But in practice, I am not sure that the "comment" name is appropriate. I would rather call it "full name". ----- Is there a reason why "type" would be a required field ? ------ What is the use for "url" and "hyp" ???? ----------- Garmin has a new waypoint type, described at: http://www.garmin.com/support/pdf/d109.txt I find it interesting that they differentiate between depth and altitude.
jfmezei+videotron.ca on Wed Oct 17 23:02:06 2001 (link), replying to msg
General question: should the XML definition provide a "basic" lowest common denominator for data interchange, or should its definition be comprehensive to allow any/all vendors to use that format to store all of the data that their units are capable of ? For instance, should all of the fields used by Garmin, Trimble, Magellan etc etc be combined into one large definition (with most fields optional, of course) or should the definition be fairly simple where the XML format would be seen only as a basic import/export format ?
egroups+topografix.com on Thu Oct 18 06:38:14 2001 (link), replying to msg
Hello, Thursday, October 18, 2001, 12:03:38 AM, Dave wrote: dyc> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote: dyc> I think that we should also consider a method of including an image dyc> with a type of point which is a landmark. I'm thinking here of the dyc> gpx format being used as a sort of a trail guide. But who knows how dyc> this will be used? One of the users of my unreleased freeware is dyc> using this to log Canoe trips. Who knew? I do this with my products, but I don't embed the image in the file. I use the hyperlink_text and url fields to link to an image on the Internet. This obviously requires that the images be available on the Internet, but it saves having to put 100KB or more data directly into the file. dyc> I'm not too happy about the idea of the <point> element being all dyc> things too all people, although if the group agrees on this approach dyc> I'll deal with it. I suggest as an alternative something like the dyc> following, where a simple point is embedded in a more complicated dyc> landmark or waypoint. Or instead of embedding, we could define other dyc> elements which are kinds of points with different sets of attributes dyc> or included elements. Sounds like it's time to start another discussion thread. Look for my <point> types message to follow... dyc> <landmark id="L101"> dyc> <point lat="45.0" lon="-116" alt="800" date-time="whenever"> dyc> <name>Foote House</name> dyc> <description>This is the cabin of Mary Hallock Foote, whose diary was dyc> featured in Wallace Stegner's book, Angle of Repose dyc> </description> dyc> <image> image data goes here </image> dyc> </landmark> I'd code this as: <point type="landmark" lat="45.0" lon="-116" id="L101" alt="800" date-time="whenever"> <name>Foote House</name> <description>This is the cabin of Mary Hallock Foote, whose diary was featured in Wallace Stegner's book, Angle of Repose </description> <image> image data goes here </image> </point> -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Oct 18 06:48:06 2001 (link), replying to msg
Hello jfmezei, Thursday, October 18, 2001, 1:59:11 AM, you wrote: jvc> A few comments: jvc> re: WGS84. jvc> I tend to agree that the interchange format should be standardized. jvc> Since my GPS unit wants units in WGS84 during data transfers, I am jvc> biased towards that standard. Me too. jvc> However, if this is to be a long term flexible standard, shouldn't jvc> there be a way to define the datum used in the header ? WGS84 could be jvc> defined as the default datum if not specified. jvc> for instance: jvc> <loc version="1.0" src="EasyGPS" datum="WSG84"> Why put it there? - in case WGS84 is replaced by WGS2002. (okay, I can understand that.) - in case I want to specify a different datum. (not everyone will be able to accept that datum. - other reason? jvc> One "problem" I have with the definitions/terminology is the ability to jvc> provide different names to a waypoint. jvc> on the web site, a construct such as: jvc> <waypoint><name id="CACHE">FellsFolly Geocache</name> is used. jvc> id= would probably correspond to the "wpt" field in your list. (so jvc> perhaps "wpt" should be renamed to "ID". There's no reason to stick with the names I used for my internal 1.0 spec. jvc> Would "FellsFolly Geocache" be considered the "com" (comment) ? It would be the "desc" (description). The comment would probably be something like FELLSFOLLYGEOCACHE jvc> The jvc> Garmin basic waypoint contains the indent X(6) and a "comment" field jvc> X(40). But in practice, I am not sure that the "comment" name is jvc> appropriate. I would rather call it "full name". Agreed. jvc> Is there a reason why "type" would be a required field ? See the new "<point> types" e-mail. jvc> What is the use for "url" and "hyp" ???? To specify a url, and the Text for the url, which leads to some information the user has associated with the waypoint. The example I usually use is the weather forecast for the area, on weather.com Others might link to a digital photo they took at the waypoint. jvc> Garmin has a new waypoint type, described at: jvc> http://www.garmin.com/support/pdf/d109.txt jvc> I find it interesting that they differentiate between depth and jvc> altitude. I still haven't figured out why they did this. My code looks something like: if altitude is negative, d109_depth = 0-altitude otherwise d109_altitude = altitude Makes no sense to me. Ideas? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Oct 18 07:08:08 2001 (link), replying to msg
Hello, Thursday, October 18, 2001, 2:02:03 AM, you wrote: jvc> General question: jvc> should the XML definition provide a "basic" lowest common denominator jvc> for data interchange The required tags provide a basic lowest common denominator for data interchange. jvc> or should its definition be comprehensive to jvc> allow any/all vendors to use that format to store all of the data that jvc> their units are capable of ? The optional tags and the private tags provide the comprehensiveness. This format should be a higher level of abstraction than the binary representation used by the GPS vendors. Example: Garmin GPS symbol: 8210 GPSXML encoding sym="Movie Theater" NOT sym="8210" NOT <sym src="garmin">8210</sym> jvc> For instance, should all of the fields used by Garmin, Trimble, jvc> Magellan etc etc be combined into one large definition (with most jvc> fields optional, of course) or should the definition be fairly simple jvc> where the XML format would be seen only as a basic import/export format jvc> ? There are some formats that do this. Here's an example of what they're doing at http://acro.harvard.edu/JL/XML/ ... <ids id3="STR" id5="STRLN" id6="STRLNG" id10="Sterling" CAI="Sterling" FAA="3b3" /> ... They've got waypoints (ids) defined for every possible length (although they missed the 8-characters used by Lowrance and others). They probably did this because in their competitions, having exact names for airports is important. I don't think it's that way for us. If I send you a waypoint from my eTrex Legend, the waypoint id will be "NEWYORKCTY". If you need a 6 character waypoint id for your Magellan GPS, it's up to you to determine how that gets chopped down. My direct answer to your question is that we should try to find the best combination of usable and meaningful tags that allows us to express the data we'd like to move between applications. There's a tradeoff to make. The fewer tags we pick, the more likely it is that your data will be understood by my application. The more tags we pick, the more data can be expressed. That's why we're making a list of the tags that each of our applications would use. If a few of us can agree on a definition of a certain tag that our apps could exchange, we'll include it in the XML spec. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Oct 18 07:23:09 2001 (link), replying to msg
Hello, Thursday, October 18, 2001, 9:31:18 AM, Dave wrote: dyc>> I'm not too happy about the idea of the <point> element being all dyc>> things too all people, although if the group agrees on this approach dyc>> I'll deal with it. I suggest as an alternative something like the dyc>> following, where a simple point is embedded in a more complicated dyc>> landmark or waypoint. Or instead of embedding, we could define other I've proposed having <point> contain a required tag "type" which would distinguish between higher-level constructs like "waypoint", "landmark", "text_annotation_on_map", etc. Dave suggests that perhaps <point> should be embedded inside these higher constructs like: <text_annotation_on_map> <point lat="42.1" lon="-71.2"> <text>This is a caption on the map<text> </text_annotation_on_map> Here's how I'd encode it: <point type="text_annotation_on_map" lat="42.1" lon="-71.2" text="This is a caption on the map"> If my app understood the text_annotation_on_map tag, it would know exactly what to do with the <point> data. If it didn't know what text_annotation_on_map meant, it has two choices for handling the unknown type tag: - ignore the point - fall back on some default behavior The app might bring in the point as a default waypoint, so when the user looked on the map, instead of a caption, he'd see a waypoint called "This is a caption on the map". I think this is a benefit to using the <point> type scheme. --- <text_annotation_on_map> <point lat="42.1" lon="-71.2"> <text>This is a caption on the map<text> </text_annotation_on_map> In Dave's construct, I don't feel good about parsing into an element that I don't recognize. So the data gets ignored, even though it contains a perfectly good <point> element that I could import into my app. Thoughts? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Oct 18 07:34:48 2001 (link), replying to msg
Hello, Let's start a list of point-specific concepts that might be useful to share between GPS or mapping applications. I think having such a list will be helpful when we discuss what tags and elements to include in the XML spec. GPS Waypoint: a <point> that's intended to be sent to a GPS and used as a navigation aide. GPS Trackpoint: a <point> marking a position along a path. Map Annotation: a <point> on a map with some formatted text or a symbol. Map Calibration Point: a <point> on a map that ties a lat/lon <point> to an x/y pixel location. Destination: a <point> to which you are navigating. Others? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
alan+computerweekly.net on Thu Oct 18 14:49:59 2001 (link)
jfmezei+videotron.ca wrote:- > Since each of these have their own precision (or lack thereof), if someone is to rely on that list I provide, it would be nice for them to be able to know which waypoints might be more precice (taken by GPS) and which might be off by some distance (MAN200R). > Not sure there would be a need to defide the contents of that field. One could expect each provider of XML data sets to provide a description of that "source" field if it is to be used. > comments ? This is a subject that I have been giving much thought to for some time now. I have a few years of collected waypoints from various sources and the precision of the posit cannot be recorded in existing file formats that I have seen. Three methods come to mind. 1. A field with the possible error in miles, Km or metres - disadvantages: needs to be worked-out & takes up more space. Useful for items such as campsite posits taken from printed guides that often are a mile or more in error of an actual GPS fix. 2. A single byte indicator. This could be added to any posit at the end, just like a programming variable. $,#,!,% etc. No indicator would indicate unknown precision. Different characters could also indicate a different source for the data, with a key table earlier in the file, so #2 could indicate a different source to #49. 3. Reduce the number of significant digits from the right. The receiving software would need to take this into account. This is the method used by radio hams when transmitting their posit, which is displayed in real time on maps. Allows any required lack of precision. ie for privacy. This method could also be used with the time field. > 20001108T093014Z.120 (Nov 08, 2000 at 9:30:14.120 GMT) allowing 200011 to indicate the month of Nov 2000. -- Alan R Morris, G4ENS. Bury St Edmunds, Suffolk, UK. No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.
alan+computerweekly.net on Thu Oct 18 14:50:05 2001 (link)
Dan Foster <egroups+topografix.com> wrote:- > I'd need to see an example, but what you're describing sounds like a flat file format, and not an XML file. XML, while being rather wordy, has the advantage that it's self describing, and can be easily transformed into many other forms. > There are already several "standard" flat file formats for describing GPS data. This group was formed to develop an XML format. I accept the function of this group, but does all data have to be bracketed between wordy keywords ? Would it be acceptable to have line entries within certain sections of the XML file ? As well as being wordy (and therefore files being significantly larger) the format style would suggest to me, a much slower rate for any application reading that data, which ever method of file reading (char, line or disk sector) is used. I would have thought that implementing an efficient parsing procedure would also be much slower, but I'm willing to learn if this is not the case. Is the function of this group to produce a very pure XML file in preference to a possibly more efficient and practical file. I'm not being awkward here, only asking for the ground rules. If I'm out of step, then let me know. I'm also involved with another group that is just about to start producing a common exchange file for campsite data which also incorporates GPS data. As those with motorhomes, or RVs as Americans call them, would want to send these files by e-mail from other countries; file size is very important when using a mobile phone and palm size computing devices. As palm size computers are used by an increasing number of GPS users, should this not be taken into account ? Or does this belong elsewhere ? -- Alan R Morris, G4ENS. Bury St Edmunds, Suffolk, UK. No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.
davewissenbach+yahoo.com on Fri Oct 19 05:45:57 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Let's start a list of point-specific concepts that might be useful to > share between GPS or mapping applications. I think having such a list > will be helpful when we discuss what tags and elements to include in > the XML spec. > > GPS Waypoint: > > GPS Trackpoint: > Map Annotation: > Map Calibration Point: > Destination: I don't think that destination is a type of point. I think that origin and destination are required elements contained in every path or sub-path. The origin and destination should be named points, which means to me what the wpt/id attribute is required for origin and destination. > Others? > > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
alan+computerweekly.net on Fri Oct 19 14:42:38 2001 (link)
"Henry C. Schmitt" <Henry+Schmitt.org> wrote:- > <grid datum="maidenhead">FN00ak</grid> Maidenhead is not a datum, it is a special format for displaying Lat/Long in one short code. It is used by radio hams and replaced an earlier system known as 'QRA' locator, (I was at ZL08d) which only covered Europe. Whereas Maidenhead is world wide. The format was finalised in the UK town of Maidenhead, hence it's name, and at that time the use of a datum was never concidered (or even known about). Today, WGS84 is the accepted datum for Maidenhead. -- Alan R Morris, G4ENS. Bury St Edmunds, Suffolk, UK. No HTML, using a Psion 5mx & Nokia 6210e at 9.6Kb.
egroups+topografix.com on Mon Oct 22 08:06:09 2001 (link), replying to msg
Hello, Friday, October 19, 2001, 5:45:41 AM, Kjeld wrote: KJ> In order to follow up on my previous comments I would suggest that instead KJ> of requiring a <type> for each <point> (which actually makes the "point" KJ> information redundant) then let us use different names for each type of KJ> points. KJ> This way we can distinguish between the relevant data for each point type KJ> but still merge all info into one dtd. KJ> For instance: KJ> <wpt>[relevant tags for a waypoint]</wpt> KJ> <trkpt>[relevant tags for a track point]</trkpt> KJ> <rtept>[relevant tags for a route point]</rtept> I can see that this approach makes it easier to validate with a DTD, and if we're going to stick with a small number of <point> types, it may be the better way to go. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Mon Oct 22 21:01:30 2001 (link), replying to msg
I really like the compact coding of attributes in the point element. We need to decide what information is coded as attributes and what information is contained in other elements. I'm now emitting the following for a trackpoint: <point type="trackpoint" lat="43.1234" lon="-116.2354" alt="894" time="20011021T142002Z"/> although I prefer the following: <trkpt lat="43... /> I think that for a waypoint, additional information such as description should be coded as elements rather than attributes, to keep from getting absurdly long tags. The way I currently parse is to look ahead at the next tag to decide what the next element will be, and then let that element parse itself. That's why I prefer knowing from the tag what kind of element I'll be parsing. I wonder if we could get farther, faster by working on some specific use cases and nailing down the coding for these, and then extending the format as necessary to converge on a workable standard? --- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Friday, October 19, 2001, 5:45:41 AM, Kjeld wrote: > > KJ> In order to follow up on my previous comments I would suggest that instead > KJ> of requiring a <type> for each <point> (which actually makes the "point" > KJ> information redundant) then let us use different names for each type of > KJ> points. > > KJ> This way we can distinguish between the relevant data for each point type > KJ> but still merge all info into one dtd. > > KJ> For instance: > > KJ> <wpt>[relevant tags for a waypoint]</wpt> > KJ> <trkpt>[relevant tags for a track point]</trkpt> > KJ> <rtept>[relevant tags for a route point]</rtept> > > I can see that this approach makes it easier to validate with a DTD, > and if we're going to stick with a small number of <point> types, it > may be the better way to go. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
egroups+topografix.com on Mon Oct 22 21:18:48 2001 (link), replying to msg
Hello davewissenbach, Tuesday, October 23, 2001, 12:01:25 AM, you wrote: dyc> I really like the compact coding of attributes in the point element. dyc> We need to decide what information is coded as attributes and what dyc> information is contained in other elements. dyc> I'm now emitting the following for a trackpoint: dyc> <point type="trackpoint" lat="43.1234" lon="-116.2354" alt="894" dyc> time="20011021T142002Z"/> dyc> although I prefer the following: dyc> <trkpt lat="43... /> dyc> I think that for a waypoint, additional information such as dyc> description should be coded as elements rather than attributes, to dyc> keep from getting absurdly long tags. Let's try to keep things predictable, though. Can we agree on a scheme like: attributes: tags with finite (< 20 characters?) data length elements: tags with no restrictions on data length (text) dyc> The way I currently parse is to look ahead at the next tag to decide dyc> what the next element will be, and then let that element parse dyc> itself. That's why I prefer knowing from the tag what kind of element dyc> I'll be parsing. dyc> I wonder if we could get farther, faster by working on some specific dyc> use cases and nailing down the coding for these, and then extending dyc> the format as necessary to converge on a workable standard? Sounds good. Everyone should take a chunk of representative data from their application and try to encode it in XML. Let's see if we can reach a consensus on some of the basic elements and tags. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Tue Oct 23 14:29:59 2001 (link), replying to msg
Hello, Tuesday, October 23, 2001, 12:01:25 AM, Dave wrote: dyc> I wonder if we could get farther, faster by working on some specific dyc> use cases and nailing down the coding for these, and then extending dyc> the format as necessary to converge on a workable standard? Here are some examples of the waypoint data I'd be emitting from my software. Key to the abbreviated tags I'm using in the examples below: Attributes: lat - latitude (required) lon - longitude (required) id - waypoint id, waypoint name cmt - waypoint comment (older Garmins, Magellan GPS) sym - waypoint symbol ele - elevation (meters) Elements: desc - user description of waypoint type - user category of waypoint url - hyperlink associated with waypoint 1. Waypoint showing most fields from my software: <wpt lat="44.27053" lon="-71.30417" ele="1919.6" id="WASHINGTON" sym="Summit"> <desc>Mount Washington, highest peak in New Hampshire</desc> <type>Summit</type> <url text="Mount Washington Observatory: Home Page">http://www.mountwashington.org/</url> </wpt> 2. Waypoint showing basic fields from Magellan 315 GPS: <wpt lat="44.21932" lon="71.3695" id="MIZPAH" cmt="MIZPAH HUT" sym="Filled Circle"/> 3. Waypoint with only required data: <wpt lat="44.21932" lon="71.3695"/> -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Tue Oct 23 14:52:12 2001 (link), replying to msg
Hello, Here are some examples of the route data I'd be emitting from my software. 1.Route showing most fields from my software: <rte id="TOWER HIKE"> <desc>Hike to the tower at the top of Bear Hill</desc> <url text="Middlesex Fells Reservation">http://www.state.ma.us/mdc/fells.htm</url> <rtept lat="42.43091" lon="-71.1079" ele="30.5" id="PARK" cmt="PARKING LOT" sym="Car"> <desc>Parking Lot</desc> <type>Parking</type> </rtept> <rtept lat="42.43091" lon="-71.10763" ele="36.6" id="POND" cmt="POND" sym="Fishing Area"> <desc>Bellevue Pond</desc> <type>Water</type> </rtept> <rtept lat="42.43272" lon="-71.1051" ele="61" id="TOWER" cmt="STONE TOWER" sym="House"> <desc>Stone Tower</desc> <type>Tower</type> </rtept> </rte> 2. Route showing basic fields from Magellan 315 GPS: <rte id="TOWER HIKE"> <rtept lat="42.43091" lon="-71.1079" id="PARK" cmt="PARKING LOT" sym="Car"/> <rtept lat="42.43091" lon="-71.10763" id="POND" cmt="POND" sym="Fishing Area"/> <rtept lat="42.43272" lon="-71.1051" id="TOWER" cmt="STONE TOWER" sym="House"/> </rte> 3. Route with only required data: <rte> <rtept lat="42.43091" lon="-71.1079"/> <rtept lat="42.43091" lon="-71.10763"/> <rtept lat="42.43272" lon="-71.1051"/> </rte> -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Tue Oct 23 15:08:18 2001 (link), replying to msg
Hello, Here are some examples of the track data I'd be emitting from my software. 1.Track showing most fields from my software: <trk id="TOWER TRACK"> <desc>Tracklog from hike to the tower at the top of Bear Hill</desc> <url text="Middlesex Fells Reservation">http://www.state.ma.us/mdc/fells.htm</url> <trkpt lat="42.43091" lon="-71.1079" ele="30.5" time="20011021T142002Z.1"/> <trkpt lat="42.43091" lon="-71.10763" ele="36.6" time="20011021T142003Z.293"/> <trkpt lat="42.43272" lon="-71.1051" ele="61" time="20011021T142004Z"/> </trk> 2. Track showing basic fields from GPS (and a track with two segments): <trk id="TOWER TRACK"> <desc>Tracklog from hike to the tower at the top of Bear Hill</desc> <url text="Middlesex Fells Reservation">http://www.state.ma.us/mdc/fells.htm</url> <trkpt lat="42.43091" lon="-71.1079" ele="30.5" time="20011021T142002Z.1"/> <trkpt lat="42.43091" lon="-71.10763" ele="36.6" time="20011021T142003Z.293"/> <trkpt lat="42.43272" lon="-71.1051" ele="61" time="20011021T142004Z"/> <trkpt lat="42.43285" lon="-71.10124" ele="1000" time="20011021T142215Z" new_track="true"/> <trkpt lat="42.43285" lon="-71.10125" ele="1001" time="20011021T142216Z"/> </trk> 3. Track with only required data: <trk> <trkpt lat="42.43091" lon="-71.1079"/> <trkpt lat="42.43091" lon="-71.10763"/> <trkpt lat="42.43272" lon="-71.1051"/> </trk> I'm not completely satisfied with the representation of time. Maybe fractional seconds should be their own tag: <trkpt lat="42.43091" lon="-71.10763" ele="36.6" time="20011021T142003Z" millisecs="293"/> -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Oct 23 21:17:07 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > > I'm not completely satisfied with the representation of time. Maybe > fractional seconds should be their own tag: > <trkpt lat="42.43091" lon="-71.10763" ele="36.6" time="20011021T142003Z" millisecs="293"/> > I was asking for more precision in time a while back, but I was way off base. The garmin unit doesn't even give fractional time, and I have no plans to support anything other GPS unit. I like using the international standard, and this was relatively easy for me to both generate and parse in my MFC Windows application. I would agree that we shouldn't corrupt a known standard. I think that millisecs would be a much better way extend the time field where greater precision is required. The examples look great. I'll try to generate something like these within the next week or so. I've taken down my old Web site because I've changed internet service providers. The new one will try to conform to our emerging standard as much as possible. One thing I do wonder about is the url element, though. I'll confess that I know almost nothing about XML, but my reference, "XML in a Nutshell", by Harold and Means, publisher O'Reilly, talks about xlink attributes in an element, rather than URL's. I will probably never get so sophisticated in my application as to use a URL. But I think that we've tended to agree that existing standards and precedent are important. I would also like clarification on the difference between a waypoint and a routepoint. I've used these interchangeably. Is a waypoint a landmark which is not part of a route? Or does a routepoint contain all the information of a waypoint, plus turning instructions "Go left when you see the white rabbit?"
egroups+topografix.com on Wed Oct 24 07:38:21 2001 (link), replying to msg
Hello davewissenbach, Wednesday, October 24, 2001, 12:17:05 AM, you wrote: dyc> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote: >> >> I'm not completely satisfied with the representation of time. Maybe >> fractional seconds should be their own tag: >> <trkpt lat="42.43091" lon="-71.10763" ele="36.6" dyc> time="20011021T142003Z" millisecs="293"/> >> dyc> I was asking for more precision in time a while back, but I was way dyc> off base. The garmin unit doesn't even give fractional time, and I dyc> have no plans to support anything other GPS unit. I like using the dyc> international standard, and this was relatively easy for me to both dyc> generate and parse in my MFC Windows application. Garmin GPS will put out fractional time if you're logging an NMEA data stream. The waypoint timestamps are rounded to the nearest second. dyc> I would agree that we shouldn't corrupt a known standard. I think dyc> that millisecs would be a much better way extend the time field where dyc> greater precision is required. Unless anyone objects, let's adopt this as the new time format. Maybe shorten millisecs to msecs? time="20011021T142003Z" msecs="293" time="20011021T142003Z" msecs="1" (note: this means 0.001 millisecs, not 1/10th of a second!) time="20011021T142003Z" msecs="100" (note: 1/10th of a second) dyc> The examples look great. I'll try to generate something like these dyc> within the next week or so. I've taken down my old Web site because dyc> I've changed internet service providers. The new one will try to dyc> conform to our emerging standard as much as possible. dyc> One thing I do wonder about is the url element, though. I'll confess dyc> that I know almost nothing about XML, but my reference, "XML in a dyc> Nutshell", by Harold and Means, publisher O'Reilly, talks about xlink dyc> attributes in an element, rather than URL's. I'm fairly ignorant of xlink, but I thought it was a way to link to other XML data. The URL field I use is just a link to some web data the user wants to associate with a waypoint or route (a .jpg photo, a trip report, a website, etc). dyc> I will probably never get so sophisticated in my application as to dyc> use a URL. But I think that we've tended to agree that existing dyc> standards and precedent are important. If someone proposes a standard way of expressing it, I'm all for it. I admit very little knowledge of either xlink or DTDs. dyc> I would also like clarification on the difference between a waypoint dyc> and a routepoint. I've used these interchangeably. Is a waypoint a dyc> landmark which is not part of a route? Or does a routepoint contain dyc> all the information of a waypoint, plus turning instructions "Go left dyc> when you see the white rabbit?" I've also used them interchangably in my applications and in my prior XML format. The reason to make them different elements was to make it easier to validate with a DTD, as someone stated earlier. <rtept> will end up containing all the valid tags for <wpt>, and probably add some additional ones. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Mon Oct 29 15:03:10 2001 (link), replying to msg
Hello, I think we're getting close to a consensus on some aspects of the new GPS exchange format. I'd like to start listing things we can agree on, so that people who want to start using the format can begin coding, and so we can document our progress. Here's a list of things I haven't heard any objections to in a few weeks. If you don't agree with something listed here, please speak up. Also, feel free to add things that I've left out. Anything that survives on this list for a week will become part of the standard. I'll start a second list of things that are still being debated, and we'll try to bring those to a consensus soon. Things we can agree on: 1. This is an XML interchange format. 2. It's called GPX, or GPS Exchange Format. The file extension is .gpx. 3. All data in GPX is between the <gpx></gpx> tags. 4. There are three "first-level" tags defined so far, which are valid within <gpx></gpx>. They are: <wpt> a waypoint <rte> a route <trk> a tracklog 5. Within <rte>, there is one "second-level" tag defined so far. It is <rtept>. 6. Within <trk>, there is one "second-level" tag defined so far. It is <trkpt>. 7. The only required tags for <wpt>, <rtept>, and <trkpt> are "lat" and "lon". These are attributes. 8. "lat" and "lon" are specified in decimal degrees, WGS84 only. 9. Private tags are allowed at any point within the XML file. Private tags must begin with an abbreviation of the application or company name followed by an underscore, to prevent collisions with other private tags and public tags. (Example: tg_active, tg_src for private tags defined by TopoGrafix.) 10. To be a "compliant GPX application", a program must only be able to read any GPX file without crashing. There is no requirement to actually parse and import any or all of the data in the file. Any tag can be ignored by the application. However, any program that produces an error on well-formed GPX data is not compliant. We'll have a suite of test files from various applications for everyone to test against for compliance. 11. The Metric system is to be used for all applicable units. (meters for altitude, for example). 12. Time is expressed in UTC. ...others?... -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Mon Oct 29 15:14:50 2001 (link), replying to msg
Hello, Here's a list of things that we haven't reached agreement on. Please add additional items to the list. Let's see if we can reach consensus on any of these items in the near future. Things we're still discussing: 1. How to best represent time, including the treatment of fractional seconds? Proposals so far: 1. time="20011021T142003Z" msecs="293" 2. time="20011021T142003.293Z" 2. How to decide between elements and attributes? Proposals so far: 1. required tags == attributes; optional tags == elements 2. based on length: elements for anything over 20 characters 3. How to deal with breaks in tracklogs? ...others?... -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Oct 30 05:07:27 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > I think we're getting close to a consensus on some aspects of the new > GPS exchange format. I'd like to start listing things we can agree > on, so that people who want to start using the format can begin > coding, and so we can document our progress. > > Things we can agree on: > > I agree with all points except for 9 and 10. I apologize for my earlier silence on the subject of private tags. I'd like to suggest an alternative for you all to consider. I think that number 9 and 10 here go together. If we are going to write a DTD for the format, and I think that we should, number 10 should also include the requirement that the document validate against the DTD. My first published format did validate against the DTD. I went to the trouble of validating the format by downloading the xerces XML parser and running one of their test applications which also validates. I think that requiring an application to validate against the DTD would go a long way towards ensuring that other gpx-aware applications which parse the data output by a rogue application don't crash! Allowing private tags anywhere in the XML format might make it impossible to write a DTD, or at least one that has any meaning. So I would suggest that vendor-unique data be encapsulated in a specific tag, which can be inserted in any element. We might also go a step further and use namespaces for the private tags. Each elements which allows for private data could then allow one or more of the specific private tag, which would then use the ANY syntax in the DTD for the elements. (The vendor tag would be required!). This scheme does not allow for private attributes, however. Such as <trk> <trkpt> <trkpt> <private vendor="DaveWissenbach"> <overlay layer="plan"/> </private> <trk> In other words, encapsulate all of the "anything goes" stuff. > 9. Private tags are allowed at any point within the XML file. Private > tags must begin with an abbreviation of the application or company > name followed by an underscore, to prevent collisions with other > private tags and public tags. (Example: tg_active, tg_src for private > tags defined by TopoGrafix.) > > 10. To be a "compliant GPX application", a program must only be able to > read any GPX file without crashing. There is no requirement to > actually parse and import any or all of the data in the file. Any tag > can be ignored by the application. However, any program that produces > an error on well-formed GPX data is not compliant. We'll have a > suite of test files from various applications for everyone to test > against for compliance. > > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
egroups+topografix.com on Tue Oct 30 19:48:29 2001 (link), replying to msg
Hello, Tuesday, October 30, 2001, 12:58:30 AM, Kjeld wrote: KJ> Hi, >>I think we're getting close to a consensus on some aspects of the new >>GPS exchange format. I'd like to start listing things we can agree >>on, so that people who want to start using the format can begin >>coding, and so we can document our progress. KJ> Good idea... mayby you could take this a bit farther by proposing examples KJ> for waypoints, tracks and routes? KJ> I would also like to get started asap, maybe we should focus on just the KJ> waypoints, tracks and routes at first? KJ> I am ready to implement the XML standard we may agree on in this forum. KJ> Perhaps we should consider making a "beta" release in order to test it KJ> thoroughly before agreeing on the "1.0" standard? I'm also ready to start implementing GPX for test purposes in my apps, and don't mind changing things if we change things. Let's try to start a list of tags that we already agree upon so we can get the basics implemented. Things like tracklogs and timestamps aren't ready yet, but lat, lon, ele, id, and others are probably okay to start using. I'll start a new message with a proposed list. KJ> Some apps (like Cetus GPS for now :-) only write .gpx files. I would say KJ> that any app that writes wellformed XML in the .gpx format but do not read KJ> .gpx is also a compliant app. Agreed. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Tue Oct 30 19:53:21 2001 (link), replying to msg
Hello, Tuesday, October 30, 2001, 1:06:03 AM, Kjeld wrote: KJ> Hi, >>Here's a list of things that we haven't reached agreement on. Please >>add additional items to the list. Let's see if we can reach consensus >>on any of these items in the near future. >>1. How to best represent time, including the treatment of fractional >>seconds? >> Proposals so far: >> 1. time="20011021T142003Z" msecs="293" >> 2. time="20011021T142003.293Z" KJ> I haven't seen the 20011021T142003Z standard before but if it is a well KJ> known standard I don't think we should tamper with it hence I would vote KJ> for 1. KJ> On the other hand if it isn't that well known I would say 2. as it is KJ> simpler and in my eyes also better. KJ> Somebody... make a decission here :-) I'm interested to see whether either of these two formats can be easily expressed in the DTD, or transformed with XSL. I'll try to research whether there's any consensus on the Net about representing timestamps in XML. >>2. How to decide between elements and attributes? >> Proposals so far: >> 1. required tags == attributes; optional tags == elements >> 2. based on length: elements for anything over 20 characters KJ> As said before I am not that religious about this issue. One thing I like KJ> about 1 though is that it makes a strict seperation between when to use KJ> elements and when to use attributes. KJ> I may foresee some problems with 2 due to differences of the apps that KJ> support .gpx say for instance that an element in one app should really be KJ> an attribute in another app if rules are to be followed. KJ> A good thing about elements is that they are very easy to read on a small KJ> display like for instance a Palm... but then again they tend to occupy more KJ> space in al limited environment. I initially proposed #2, and now you've convinced me to support #1. Everything you wrote makes sense to me. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Tue Oct 30 19:58:24 2001 (link), replying to msg
Hello, Tuesday, October 30, 2001, 8:07:20 AM, Dave wrote: dyc> I agree with all points except for 9 and 10. dyc> I apologize for my earlier silence on the subject of private tags. dyc> I'd like to suggest an alternative for you all to consider. dyc> I think that number 9 and 10 here go together. If we are going to dyc> write a DTD for the format, and I think that we should, number 10 dyc> should also include the requirement that the document validate dyc> against the DTD. My first published format did validate against the dyc> DTD. I went to the trouble of validating the format by downloading dyc> the xerces XML parser and running one of their test applications dyc> which also validates. I think that requiring an application to dyc> validate against the DTD would go a long way towards ensuring that dyc> other gpx-aware applications which parse the data output by a rogue dyc> application don't crash! dyc> Allowing private tags anywhere in the XML format might make it dyc> impossible to write a DTD, or at least one that has any meaning. So I dyc> would suggest that vendor-unique data be encapsulated in a specific dyc> tag, which can be inserted in any element. We might also go a step dyc> further and use namespaces for the private tags. dyc> Each elements which allows for private data could then allow one or dyc> more of the specific private tag, which would then use the ANY syntax dyc> in the DTD for the elements. (The vendor tag would be required!). dyc> This scheme does not allow for private attributes, however. dyc> Such as dyc> <trk> dyc> <trkpt> dyc> <trkpt> dyc> <private vendor="DaveWissenbach"> dyc> <overlay layer="plan"/> dyc> </private> dyc> <trk> You've convinced me. Having a format that can be validated by a DTD is a good reason to make this change. As I've said before, DTDs aren't my strong suit, so I hope you'll help define the DTD for GPX once we start putting the pieces together. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Oct 31 18:41:09 2001 (link), replying to msg
Hello, Here are some tags that I haven't heard debated recently. Any objections, or can we start using these in early GPX implementations? lat type: required; attribute valid in: <wpt>, <rtept>, <trkpt> meaning: latitude of the point units: decimal degrees, WGS84 datum format: number example: lat="42.1234" lon type: required; attribute valid in: <wpt>, <rtept>, <trkpt> meaning: longitude of the point units: decimal degrees, WGS84 datum format: number example: lon="-71.1234" ele type: optional; element valid in: <wpt>, <rtept>, <trkpt> meaning: elevation of the point units: meters format: number example: <ele>123.45</ele> id type: optional; element valid in: <wpt>, <rtept> meaning: GPS Waypoint name; short identifier for point units: n/a format: text example: <id>NEWYRK</id> cmt type: optional; element valid in: <wpt>, <rtept> meaning: GPS Waypoint comment; long identifier for point units: n/a format: text example: <cmt>NEW YORK CITY</cmt> desc type: optional; element valid in: <wpt>, <rtept> meaning: User's description of the point units: n/a format: text example: <desc>New York City is also known as the Big Apple.</desc> sym type: optional; element valid in: <wpt>, <rtept> meaning: GPS Symbol for the point units: n/a format: text example: <sym>Building</sym> others? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Fri Nov 02 05:34:01 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: I think that we're all XML novices here, but I'll write a DTD and validate output (yours and mine) just as soon as we can code some samples. I actually had finished converting my program to write your last sample formats, without the DTD, but I'm going to spend a little time to code the optional attributes as elements, per the most recent discussions here. One thing that won't be covered by the DTD is a design decision that I had to make--that I would only separately output waypoints which are not part of routes. The Garmin GPSs give us the waypoints twice, but I see no reason to encode all of these twice, once as a routepoint, and once as a waypoint. > > As I've said before, DTDs aren't my strong suit, so I hope you'll help > define the DTD for GPX once we start putting the pieces together. > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
egroups+topografix.com on Wed Nov 07 20:08:48 2001 (link), replying to msg
Hello, Here's a sample GPX file containing some waypoints and a route from a hike I took recently. Comments? Anyone else have sample data at this point? Eventually, we should have a set of GPX files to validate against. Hike.gpx <?xml version="1.0"?> <gpx version="1.0" src="EasyGPS"> <wpt lat="42.723617" lon="-71.912150"> <id>BINNEYPOND</id> <desc>Binney Ponds</desc> <type>Pond</type> <sym>Fishing Area</sym> </wpt> <wpt lat="42.730400" lon="-71.918250"> <id>LUNCH</id> <desc>Lunch Rocks</desc> <ele>517.300000</ele> <type>Summit</type> <sym>Picnic Area</sym> </wpt> <wpt lat="42.696767" lon="-71.892517"> <id>WATATIC</id> <desc>Mount Watatic</desc> <ele>568.500000</ele> <type>Summit</type> <sym>Summit</sym> </wpt> <wpt lat="42.711233" lon="-71.898167"> <id>STATELINE</id> <desc>NH-MA State Line</desc> <ele>485.600000</ele> <type>Intersection</type> <sym>Dot</sym> </wpt> <wpt lat="42.696850" lon="-71.904567"> <id>PARKING</id> <desc>Parking Lot</desc> <ele>417.300000</ele> <type>Parking</type> <sym>Car</sym> </wpt> <wpt lat="42.733017" lon="-71.919000"> <id>PRATTMOUNT</id> <desc>Pratt Mountain</desc> <type>Summit</type> <sym>Summit</sym> </wpt> <wpt lat="42.720267" lon="-71.912383"> <id>STREAM</id> <desc>Stream Crossing</desc> <type>Stream</type> <sym>Dot</sym> </wpt> <rte> <rtept lat="42.696850" lon="-71.904567"> <id>PARKING</id> <desc>Parking Lot</desc> <ele>417.300000</ele> <type>Parking</type> <sym>Car</sym> </rtept> <rtept lat="42.696767" lon="-71.892517"> <id>WATATIC</id> <desc>Mount Watatic</desc> <ele>568.500000</ele> <type>Summit</type> <sym>Summit</sym> </rtept> <rtept lat="42.711233" lon="-71.898167"> <id>STATELINE</id> <desc>NH-MA State Line</desc> <ele>485.600000</ele> <type>Intersection</type> <sym>Dot</sym> </rtept> <rtept lat="42.720267" lon="-71.912383"> <id>STREAM</id> <desc>Stream Crossing</desc> <type>Stream</type> <sym>Dot</sym> </rtept> <rtept lat="42.723617" lon="-71.912150"> <id>BINNEYPOND</id> <desc>Binney Ponds</desc> <type>Pond</type> <sym>Fishing Area</sym> </rtept> <rtept lat="42.730400" lon="-71.918250"> <id>LUNCH</id> <desc>Lunch Rocks</desc> <ele>517.300000</ele> <type>Summit</type> <sym>Picnic Area</sym> </rtept> <rtept lat="42.733017" lon="-71.919000"> <id>PRATTMOUNT</id> <desc>Pratt Mountain</desc> <type>Summit</type> <sym>Summit</sym> </rtept> </rte> </gpx> -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Wed Nov 07 21:16:56 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Here's a sample GPX file containing some waypoints and a route from a > hike I took recently. Comments? Anyone else have sample data at this > point? Eventually, we should have a set of GPX files to validate > against. > > Hike.gpx > I've posted sample data at my incomplete web site. Deep link to the URL www.cableone.net/cdwissenbach/FileFormat.gpx The document is not valid against the DTD because I did not define the tags contained in the <private> element. The ANY keyword does not absolve one from the responsibility of defining the other elements. My reading of the XML specification indicates that we should be able to have both an external DTD and inline portion. I'll let you know if this works. Also, although my application outputs gpx format, the application doesn't read its own output! That's next week's job. I've not finished the DTD. I'll Add K.J.'s stuff and the attributes of gpx, version and src, and correct any other omissions.
egroups+topografix.com on Thu Nov 08 07:21:47 2001 (link), replying to msg
Hello, Tuesday, October 30, 2001, 10:47:28 PM, I wrote: >>>1. How to best represent time, including the treatment of fractional >>>seconds? >>> Proposals so far: >>> 1. time="20011021T142003Z" msecs="293" >>> 2. time="20011021T142003.293Z" Do a google search for "XML timestamp" and you'll find references to the ISO 8601 spec, which gives a way to represent timestamps: ccyy-mm-ddThh:mm:ss.fffffffffZ (Z means this is UTC) ccyy-mm-ddThh:mm:ss.fffffffff+HH:MM (local time with UTC offset) The example time above: Oct 21, 2000 at 14:20:03 and 293 milliseconds UTC would be expressed as follows: 2001-10-21T14:20:03.293Z 2001-10-21T14:15:03.293-05:00 (US East coast at UTC-5) Most of the punctuation is optional, but I'd suggest requiring it for readability. I'd also suggest only supporting the UTC version. I can't think of any reason why it would be important to know the timezone where the point was recorded, especially on every point in the file. Any objections to this as the timestamp format? ccyy-mm-ddThh:mm:ss.fffffffffZ 2001-10-21T14:20:03.293Z -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Nov 08 07:53:00 2001 (link), replying to msg
Hello, Thursday, November 08, 2001, 9:37:08 AM, Kjeld wrote: KJ> I (myself) can also live without the timezone information. But every time I KJ> try to do something in UTC only, I get a mailstorm from my users who KJ> complaints that if you have a rather big offset it also influences the date KJ> for instance in the evening. Hence it may be a little confusing without, if KJ> you go for a walk and manually add some waypoints along the trip. KJ> I would therefore like to be able to add an optional <utc> element to solve KJ> this problem. For a normal waypoint there's not much usage of millisecs, if KJ> the local time can have an offset of several hours :-) Isn't this just a display issue for your software? For example, in my software, I store all timestamps in UTC, and I have a preference that lets the user choose how to display dates and times: - local 12 hr - local 24 hour - UTC If they want to see data in local time, I do the conversion to/from UTC using the time zone information on their computer. (I don't know if this is available on Palm - you can always ask the user for a UTC offset) To me, this is like feet vs. meters. Nobody here in the US knows what a meter is, but we can still use meters in the GPX format because the software applications can convert to whatever format the user wants to use to display information on the screen. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Nov 08 08:36:03 2001 (link), replying to msg
Hello, Thursday, November 08, 2001, 3:21:05 AM, Kjeld wrote: KJ> Hi.... KJ> A few comments... KJ> The owerall format looks great and mine is very similar to it. I am not KJ> sure if we have to put a </xml> tag at the bottom in order to "close" the KJ> <?xml....> tag? None of the XML files I've seen do this. KJ> I would consider src="EasyGPS" as optional which by your current format KJ> should then be coded as an element? We haven't talked about this yet, and I just put it in my example file because it was already in my old XML format. I think it would be good to have some indication of the application used to create the file, for the following reasons: - if you find a non-conforming GPX file, you know who to alert. - if someone who's never heard of GPX gets a file, they might be able to figure out that they can open it with the application listed. Making this optional info is fine with me, although that makes it harder to track down bad file generators. KJ> Perhaps we should save the <id> tag for numbering of tracks and routes and KJ> then use <name> instead for the name? Agreed. Use <name> for the waypoint name. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Nov 08 09:22:40 2001 (link), replying to msg
Hello, Thursday, November 08, 2001, 11:03:21 AM, Kjeld wrote: KJ> I see your point, but my idea with the <src> was somewhat different. KJ> I haven't thought about the "who created this file" issue. My idea was KJ> something like a "Who created this waypoint" element. KJ> Knowing from where the data originates you may be able to tell something KJ> about the accuracy. I for instance lists <src>App name and version KJ> (detected GPS receiver)</src>. KJ> If the .gpx file comes from a database changing the <src> to the database KJ> name causes this information to disappear, and if you maintain a KJ> compilation of several waypoints it would be nice to know which app and GPS KJ> did create each waypoint. KJ> Maybe we need both? something like.... KJ> <gpx version="0.1" creator="myWptDb"> KJ> <wpt lat="10.000" lon="10.000" > KJ> ... KJ> <src>theNameOfMyAppOrGPS</src> KJ> </wpt> KJ> </gpx> KJ> Comments please... I agree that there can be a need for both. "who created this file?" and "who created this waypoint?" and "how accurate is this waypoint?" are all valid questions that GPX should be able to answer. So how do we answer the questions? 1. who created this file? A text string identifying the app or DB that created the file: <gpx creator="MyApp v1.23 http://www.myapp.com/"> 2. who created this point? How do you answer this question? How do you answer it such that another app can interpret the answer? Possible answers: - Retrieved from GPS. - Retrieved from Garmin eTrex. - Retrieved from Magellan GPS in DGPS mode. - User entered coordinates. - Digitized from map. - others? 3. how accurate is this point? How do you answer this question? How do you answer it such that another app can interpret the answer? Possible answers: - <hdop>2.0</hdop> - <fix>3D</fix> (or 2D, DGPS, etc) - others? Questions 2 and 3 are difficult to answer in a standardized way. I know some of you were thinking about data averaging and accuracy in your apps. Any thoughts on how to represent this in GPX? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Thu Nov 08 21:36:07 2001 (link), replying to msg
--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote: > Hi.... > > A few comments... > > > Perhaps we should save the <id> tag for numbering of tracks and routes and > then use <name> instead for the name? > > Why is ID a required attribute of a trkpt and a rtpte? (Remember that we have previously agreed that required attributes of an element would be coded with the XML attribute syntax, and that optional data would be coded as elements.) Have we changed this rule while I was offline? If so, I'd suggest that we use id in the XML sense of the word, as a special kind of attribute that must be unique from all other attributes. The Garmin GPS requires that all waypoints be unique, and the ID is used for display purposes. Usability would be improved if the source application could control the ID which is displayed on the Garmin unit, which therefore implies that all waypoints have a Unique ID. And because routes are composed of waypoints, routepoints must also have unique ID's. But I'd make these optional. So my view of the GPS/GPX world is in conflict with the numbered ID sequence which you propose below. Or is what I'm referring to above as an ID now to be called a name? What is the purpose of sequentially numbering points within a track or route? If the purpose is just to detect loss of lock on the GPS, or a break in a track, can we code this in some other way? > <wpt lat="42.723617" lon="-71.912150"> (no id necessary) > ... > </wpt> > > <route> > <rtept id="1" lat="42.723617" lon="-71.912150"> > ... > </rtept> > <rtept id="2" lat="42.723617" lon="-71.912150"> > ... > </rtept> > <rtept id="3" lat="42.723617" lon="-71.912150"> > ... > </rtept> > </route> > > <track> > <trkpt id="1" lat="42.723617" lon="-71.912150"> > ... > </trkpt> > <trkpt id="2" lat="42.723617" lon="-71.912150"> > ... > </trkpt> > <trkpt id="3" lat="42.723617" lon="-71.912150"> > ... > </trkpt> > </track> > > > I will make a few changes to the Cetus GPS software today in order to adapt > some of the features in your sample file. Then I will then post the result > here.. > > Kjeld > > > ______________________ > Kjeld Jensen > N 55� 22' E 10� 24' > Email: gps+c... > http://www.cetus.dk/gps
kevin+synergysa.com.au on Thu Nov 08 22:07:53 2001 (link), replying to msg
I agree somewhat....
rather than "id" for trackpoints perhaps a sequence is inferred here
instead.
taking the sample this would equate to
> <route>
> <rtept seq="1" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> <rtept seq="2" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> <rtept seq="3" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> </route>
this would allow for an application to confidently sort the route/track
using DOM or XSLT for purposes such as track reversal
Kevin
-----Original Message-----
From: davewissenbach+yahoo.com [mailto:davewissenbach+yahoo.com]
Sent: Friday, 9 November 2001 4:06 PM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] Re: GPX Sample File: Hike.gpx
--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
> Hi....
>
> A few comments...
>
>
> Perhaps we should save the <id> tag for numbering of tracks and
routes and
> then use <name> instead for the name?
>
>
Why is ID a required attribute of a trkpt and a rtpte? (Remember that
we have previously agreed that required attributes of an element
would be coded with the XML attribute syntax, and that optional data
would be coded as elements.) Have we changed this rule while I was
offline? If so, I'd suggest that we use id in the XML sense of the
word, as a special kind of attribute that must be unique from all
other attributes. The Garmin GPS requires that all waypoints be
unique, and the ID is used for display purposes. Usability would be
improved if the source application could control the ID which is
displayed on the Garmin unit, which therefore implies that all
waypoints have a Unique ID. And because routes are composed of
waypoints, routepoints must also have unique ID's. But I'd make these
optional.
So my view of the GPS/GPX world is in conflict with the numbered ID
sequence which you propose below. Or is what I'm referring to above
as an ID now to be called a name?
What is the purpose of sequentially numbering points within a track
or route? If the purpose is just to detect loss of lock on the GPS,
or a break in a track, can we code this in some other way?
> <wpt lat="42.723617" lon="-71.912150"> (no id necessary)
> ...
> </wpt>
>
> <route>
> <rtept id="1" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> <rtept id="2" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> <rtept id="3" lat="42.723617" lon="-71.912150">
> ...
> </rtept>
> </route>
>
> <track>
> <trkpt id="1" lat="42.723617" lon="-71.912150">
> ...
> </trkpt>
> <trkpt id="2" lat="42.723617" lon="-71.912150">
> ...
> </trkpt>
> <trkpt id="3" lat="42.723617" lon="-71.912150">
> ...
> </trkpt>
> </track>
>
>
> I will make a few changes to the Cetus GPS software today in order
to adapt
> some of the features in your sample file. Then I will then post the
result
> here..
>
> Kjeld
>
>
> ______________________
> Kjeld Jensen
> N 55? 22' E 10? 24'
> Email: gps+c...
> http://www.cetus.dk/gps
Yahoo! Groups Sponsor
ADVERTISEMENT
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.
------=_NextPart_000_0002_01C1693C.D626B620
davewissenbach+yahoo.com on Sun Nov 11 20:57:23 2001 (link)
Periodically we post a digest of things that we've agreed on, and I attempted, about a week ago, to encode these in a DTD. I ran into trouble when I attempted to validate this DTD against my own private elements, as the private elements aren't known to the DTD. One way to solve this problem might be to use both an internal and external DTD subset, but I think instead that we should switch to using XML Schema, which is a new recommendation from the WWW3 consortiom. A variant of this is already supported by Internet Explorer. The advantage is that the XML-Schema is open. The existence of private elements, such as my overlay data, need not be documented in the DTD for validity. Another advantage is that the XML-schema provides a better description of data types. Dan Foster in his excellent digests always provides units and format, and we should not lose this information. So I withdraw my previous offer to maintain a DTD, an already obsolete version of which is part of the preamble to my sample format at www.cableone.net/cdwissenbach/FileFormat.gpx. I'll be updating the file format to change "id" to "name", and to include punctuation - - : : to dates to improve readability, as was previously suggested here. I'd like to keep the specification as formal as possible, in order to avoid a proliferation of programs which speak slightly different dialects and are therefore all incompatible. Do we have a listener who knows something about XML-Schema who is willing to provide a first draft?
davewissenbach+yahoo.com on Sun Nov 18 06:54:35 2001 (link)
I've completed the conversion of my trail mapping program to our evolving gpx format. I read both <id> and <name> tags, but output <name> for names of all tracks, routes, and waypoints. My previously published sample used waypt instead of <wpt>, and I have corrected that error. I output first-level elements in the order <wpt>,<rte>,<trk>. I have successfully read Dan Foster's previously posted snippet of data from EasyGPS, which contains a route only. We need to reach agreement on a set of names for symbols, though. Dan uses "Fishing Area" but I use "Fish", so his "Fishing Area" comes out on my program as a dot. I have used the <private> tag encapsulating layer information for my maps. I originally proposed the usage of this tag to encapsulate private data, but if we go away from a rigid DTD in favor of using XML Schema, this encapsulation is no longer necessary. I think that we should go back a variant of Dan's original proposal for private tags--He proposed wissenbach_layer, or yourprogram_display as a means of distinguishing tags. I'd use XML namespace syntax instead, and say wissenbach:layer or foster:display or jensen:precision for our favorite private tags. I think that ignoring the contents of <private> tags other than our own will add too much complexity to the parsing. The sample program and data files are available at the URL http://www.cableone.net/cdwissenbach Please do not share this link, as the file format is of course rapidly changing!!
egroups+topografix.com on Mon Nov 19 09:33:18 2001 (link), replying to msg
Hello, Sunday, November 18, 2001, 9:54:26 AM, Dave wrote: dyc> I've completed the conversion of my trail mapping program to our dyc> evolving gpx format. I read both <id> and <name> tags, but output dyc> <name> for names of all tracks, routes, and waypoints. Looks great! I'm going to spend the next day or so adding GPX support to my apps, and testing with your sample data. dyc> My previously published sample used waypt instead of <wpt>, and I dyc> have corrected that error. I output first-level elements in the order dyc> <wpt>,<rte>,<trk>. dyc> I have successfully read Dan Foster's previously posted snippet of dyc> data from EasyGPS, which contains a route only. We need to reach dyc> agreement on a set of names for symbols, though. Dan uses "Fishing dyc> Area" but I use "Fish", so his "Fishing Area" comes out on my program dyc> as a dot. I think this is fine. This problem was brought on us by the GPS vendors, and I don't know a great way to solve it without getting them to all agree. As long as we use the exact names of the waypoint symbols as given by the GPS vendors, exact matches will always work. If apps want to have a second level of matching, that's even better. dyc> I have used the <private> tag encapsulating layer information for my dyc> maps. I originally proposed the usage of this tag to encapsulate dyc> private data, but if we go away from a rigid DTD in favor of using dyc> XML Schema, this encapsulation is no longer necessary. I think that dyc> we should go back a variant of Dan's original proposal for private dyc> tags--He proposed wissenbach_layer, or yourprogram_display as a means dyc> of distinguishing tags. I'd use XML namespace syntax instead, and say dyc> wissenbach:layer or foster:display or jensen:precision for our dyc> favorite private tags. I think that ignoring the contents of dyc> <private> tags other than our own will add too much complexity to the dyc> parsing. I like this. I'll be using topografix:private from now on. dyc> The sample program and data files are available at the URL dyc> http://www.cableone.net/cdwissenbach One thing I noticed was that Internet Explorer saved the .gpx file as .gpx.xml Is anyone else seeing this happen? I've seen cases of IE "sniffing" the contents of files before... -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Nov 20 16:16:33 2001 (link), replying to msg
--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote: > Here are some samples which were created using the current beta release og > Cetus GPS and Cetus TrackLog available at http://www.cetus.dk/gps > > To the tracklog I have added a few elements which we need to discuss. > > <mag> is the magnetic deviation measured at the beginning of the track sample. > What are the units? Looks like radians, not degrees. > <speed> and <course> are the values provided by the GPS. They are relevant > for users who wants to perform simple analysis using for instance Excel and > I belive we should support them as optional elements. Anyone who does not > need them could just trash the information. > I think that we could have lots of optional elements, but that's OK. Once we introduce any optional element, our parsers can probably handle all optional elements. To make these optional elements usable, we should describe them in the Schema/DTD. > Maybe we should Dan talk him into concluding on the current status of our > format description - not as a DTD but a simple description of the things we > have agreed on. > Until we know how to write a DTD, or schema, I agree. Once we (or I) learn how to write a Schema, I think that we should go that route, or go with a web page which describes the format. I'm having a bit of trouble sorting through all 74 messages and keeping them straight. > We need to make a decission about the versioning of gps. I suggest that we > create a "sloppy" version "0.2" or so for practical testing purposes. > It could be based on Dan's description, when we have agreed on this. > We can probably go with the sloppy version once we know that we successfully exchange data. I think that will be within the next few weeks. We still have a few things to iron out. For instance, Dan's last sample used id instead of name. In my last sample, I used <ele> to describe both the elevation of a waypoint, and the altitude of a trackpoint. I see that you are using a strict interpretation of the words, but I recently switched to <ele> in both to conform to Dan's hand-written samples. Can we switch to <ele> in both? Or should we allow eacher. Until then no data exchange is possible. (Actually it is if we treat both as optional elements). That's what I've done with our switch from <id> to <name>. > I suggest we use it for let say a few months in which our programs support > it officially. Then we should have enough experience to go to a more strict > format description "1.0". > The format still needs a lot of work. There were lots of good ideas about routes and links expressed early on in the newsgroup, and I think that we need to express these ideas in the format. That might require some significant change. I'd like some assurance that the data which I produce in the interim period will still be valid once we go to "1.0", if this is possible. > Another issue is how do we extend the use of gpx to other than us here on > the list? I plan to add a page on my homepage dedicated to avertising for > all apps that are capable of importing data from my apps using gpx, but > what do you guys have in mind regarding this? > I'm not going to push my application very much, so no thanks. I think that we need to pay more attention to how we publish the trails. One thing that I'm a bit worried about is how we keep from distributing copywrited data on our web sites (illegal in the United States of America, once people convert to this format. I think that we should have a required copywrite/data ownership field in every gpx file. I'll begin publishing all of the trails in the Boise, Idaho area in GPX format once we agree on the format, in copyleft format. (No copyright). I'd like to be able to ensure that this work to be freely available. (Lots of the map data originated with government data in the US but is controlled and distributed by just a few map companies.) I'd like to break this paradigm and produce data which is publicly owned! > Format deleted. I'll parse both ele and alt for now and try to read this. > ______________________ > Kjeld Jensen > N 55� 22' E 10� 24' > Email: gps+c... > http://www.cetus.dk/gps
egroups+topografix.com on Wed Nov 21 12:55:31 2001 (link), replying to msg
Hello , Wednesday, November 21, 2001, 1:05:40 PM, Kjeld wrote: KJ> I was just a little curious about what you plan to do and would like to KJ> hear some suggestions on how we can market the GPX format. Perhaps a nice KJ> homepage with a detailed technical description of the format (the sloppy KJ> description we talked about) along with a general description of the ideas KJ> behind GPX would be a good idea (Dan.... :-) I will update http://www.topografix.com/xml.asp to reflect the current version of the GPX project, and provide a technical overview for interested developers, as well as a "what's this and why should I care?" section for users. I'll also provide links to any program or developer who uses GPX and wants to be listed. In one of the past emails, someone asked what requirements we should put on the use of GPX by other developers. My thoughts are that GPX should be available for use by anyone who agrees to the following points: - make sure your implementation works well with other implementations. - don't "steal" the file-type extension .gpx for your application without asking the user first. (for Windows developers) - participate in the GPX development forum (this mailing list). - identify yourself or your application in a <src> tag in the GPX header, so we can track you down if something is broken. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Nov 21 13:12:30 2001 (link), replying to msg
Hello, Wednesday, November 21, 2001, 1:05:40 PM, Dave and Kjeld, wrote: Dave: >>I'll begin publishing all of the trails in the Boise, Idaho area in >>GPX format once we agree on the format, in copyleft format. (No >>copyright). I'd like to be able to ensure that this work to be >>freely available. (Lots of the map data originated with government >>data in the US but is controlled and distributed by just a few map >>companies.) I'd like to break this paradigm and produce data which >>is publicly owned! Kjeld: KJ> Perhaps we should include the optional element <license> in the <wpt> and KJ> <trk> (before the first <trkpt>) in order to be able to add copyright KJ> information. Then if your parser sees this element, you know it is KJ> copyrighted, and you cannot use/distribute the data unless you get an exact KJ> match on the element data with some copyright strings you are allowed to KJ> distribute. KJ> <license>Copyright by Kjeld Jensen, free distribution allowed</license> KJ> No <license> equals copyfree. I won't be writing out the <license> tag, for the following reasons: 1. I don't put any restrictions on the use of data generated by my programs. 2. At the same time, I can't write <license>free</license> arbitrarily, because someone may be bringing licensed data into my app and then exporting it. As far as reading the <license> tag, I'm torn between actually doing something with the data, and ignoring it completely. If I did read it, it seems like I ought to show the license restriction to the user, and that bothers me. Because I know some of my data providers would like nothing better than a chance to pop up their legal statements everytime someone opens one of their files. Maybe I'll end up with an "About this file" command that shows everything in the GPX header (created by, license, etc). -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Nov 21 13:25:15 2001 (link), replying to msg
Hello, Wednesday, November 21, 2001, 3:15:49 PM, Kjeld wrote: >> - identify yourself or your application in a <src> tag in the GPX >> header, so we can track you down if something is broken. KJ> I thought we had changed that one to creator=" " and use <src> as an KJ> optional element for where the data originates from. If it is just me who KJ> had that thought, I want to suggest that we do :-) KJ> For instance: KJ> <?xml version="1.0" standalone="yes"?> KJ> <gpx version="0.1" creator="Cetus GPS 1.0b15"> KJ> <wpt lat="63.4267483" lon="10.4106717"> KJ> <ele>67.40</ele> KJ> <name>Test1</name> KJ> <desc>Some text here</desc> KJ> <time>2001-11-18T18:38:57.000Z</time> KJ> <fix>3D</fix> KJ> <sat>7</sat> KJ> <hdop>2.1</hdop> KJ> <src>GARMIN GPS</src> KJ> </wpt> KJ> </gpx> Kjeld is right. I was sloppy when I wrote that. Another reason why I need to get an updated list of the elements we've agreed upon posted on the website. A quick recap: creator - the app that made the file src - the source of the data (GPS, map, etc) ele - elevation name - waypoint name No longer used: alt - use ele for elevation id - use name for waypoint name By the way, I've updated my software to read the sample GPX files produced by Dave and Kjeld. I'll get the new software, my sample files, and the website updated and available in the next week. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
adrius42+hotmail.com on Sun Nov 25 12:49:28 2001 (link)
I am concerned that all the implications of the UTC question have not been hammered out. As its late I will simply say that.... Time and UTC implicates veracity of date. For individuals that cross date and timezones are there not, likely to be implications, as yet not fully explored, of ignoring "local" time. "In the spirit of XML" was used as a comment earlier, my sense of that spirit requires UNDERSTANDABLE, accurate, reliable & reasonably comprehensive means of transferring data. For me the understandable is key, removing/ignoring data that simply impacts "comprehensive" is defensible, but were the lack of data impacts understanding there is clearly an issue. I can be argued both ways but I fear we may be missing key data by ignoring the possibility of requiring timezone offsets. Adrian
adrius42+hotmail.com on Sun Nov 25 13:15:39 2001 (link), replying to msg
--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote: > Hi, > > >Why is ID a required attribute of a trkpt and a rtpte? (Remember that > >we have previously agreed that required attributes of an element > >would be coded with the XML attribute syntax, and that optional data > >would be coded as elements.) Have we changed this rule while I was > >offline? > > No :-) > > If so, I'd suggest that we use id in the XML sense of the > >word, as a special kind of attribute that must be unique from all > >other attributes. The Garmin GPS requires that all waypoints be > >unique, and the ID is used for display purposes. Usability would be > >improved if the source application could control the ID which is > >displayed on the Garmin unit, which therefore implies that all > >waypoints have a Unique ID. And because routes are composed of > >waypoints, routepoints must also have unique ID's. But I'd make these > >optional. > > >So my view of the GPS/GPX world is in conflict with the numbered ID > >sequence which you propose below. Or is what I'm referring to above > >as an ID now to be called a name? > > >What is the purpose of sequentially numbering points within a track > >or route? If the purpose is just to detect loss of lock on the GPS, > >or a break in a track, can we code this in some other way? > > The id was changed to name yes, and I thought id could be a sequential > numbering of all track/route records. > **************** **************** Having read to the end ( A great body of work) the only concern I have ((after the Time Zone question)) is the question of uniqueness of NAME (See below) I believe this one will bite if Name is not required to be Unique within each .GPX file, or am I missing a trick? Am I the only paranoid thinking this? *************** *************** > But to me the name is not necessarily unique. I see the requirement for a > unique id (for the purpose you describe) the same way as limitations on > string lengths and so on. Limitations that may be convenient for one > application should not cause limitations in the gpx standard. If you for > instance export let say 100 waypoints from a database it is quite difficult > to make sure that each name is unique at least in some applications. > > If we define that trackpoints must follow in a sequence, then I guess the > id="" is not that necessary. Actually I like the element name seq="" better > because it tells more about what it is, so if we are to include a > sequential number for tracks and routes, then I think it should be called > seq rather than id. > > Kjeld > > ______________________ > Kjeld Jensen > N 55� 22' E 10� 24' > Email: gps+c... > http://www.cetus.dk/gps Adrian Email: adrius42+hotmail.com
gpsxml+yahoogroups.com on Sun Nov 25 22:04:25 2001 (link)
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the gpsxml group. File : /Schema/gpx1.xsd Uploaded by : kevin+synergysa.com.au Description : Draft 1 GPX XSD You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/Schema/gpx1.xsd To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, kevin+synergysa.com.au
kevin+synergysa.com.au on Sun Nov 25 23:52:37 2001 (link)
Hi All
Here's a quick first draft of the XSD for .gpx - I have also placed it
in the files section of yahoogroups.com
A few more sample XML packets would be good perhaps members of the list
can put some of their sample GPS xml packets up also
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema id="gpx"
targetNamespace="http://groups.yahoo.com/group/gpsxml"
xmlns="http://groups.yahoo.com/group/gpsxml"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"
attributeFormDefault="qualified" elementFormDefault="qualified">
<xsd:element name="gpx">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="wpt" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ele" type="xsd:string" minOccurs="0"
msdata:Ordinal="0" />
<xsd:element name="name" type="xsd:string" minOccurs="0"
msdata:Ordinal="1" />
<xsd:element name="sym" type="xsd:string" minOccurs="0"
msdata:Ordinal="2" />
<xsd:element name="desc" type="xsd:string" minOccurs="0"
msdata:Ordinal="6" />
</xsd:sequence>
<xsd:attribute name="lat" form="unqualified"
type="xsd:string" />
<xsd:attribute name="lon" form="unqualified"
type="xsd:string" />
<xsd:attribute name="gpx_Id" type="xsd:int" use="prohibited"
/>
</xsd:complexType>
</xsd:element>
<xsd:element name="rte" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="rtept" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"
minOccurs="0" msdata:Ordinal="0" />
<xsd:element name="sym" type="xsd:string"
minOccurs="0" msdata:Ordinal="1" />
<xsd:element name="ele" type="xsd:string"
minOccurs="0" msdata:Ordinal="5" />
<xsd:element name="desc" type="xsd:string"
minOccurs="0" msdata:Ordinal="6" />
</xsd:sequence>
<xsd:attribute name="lat" form="unqualified"
type="xsd:string" />
<xsd:attribute name="lon" form="unqualified"
type="xsd:string" />
<xsd:attribute name="rte_Id" type="xsd:int"
use="prohibited" />
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="rte_Id" msdata:AutoIncrement="true"
type="xsd:int" msdata:AllowDBNull="false" use="prohibited" />
<xsd:attribute name="gpx_Id" type="xsd:int" use="prohibited"
/>
</xsd:complexType>
</xsd:element>
<xsd:element name="trk" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="0"
msdata:Ordinal="0" />
<xsd:element name="desc" type="xsd:string" minOccurs="0"
msdata:Ordinal="1" />
<xsd:element name="trkpt" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ele" type="xsd:string"
minOccurs="0" msdata:Ordinal="0" />
<xsd:element name="time" type="xsd:dateTime"
minOccurs="0" msdata:Ordinal="4" />
</xsd:sequence>
<xsd:attribute name="lat" form="unqualified"
type="xsd:string" />
<xsd:attribute name="lon" form="unqualified"
type="xsd:string" />
<xsd:attribute name="trk_Id" type="xsd:int"
use="prohibited" />
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="trk_Id" msdata:AutoIncrement="true"
type="xsd:int" msdata:AllowDBNull="false" use="prohibited" />
<xsd:attribute name="gpx_Id" type="xsd:int" use="prohibited"
/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="gpx_Id" msdata:AutoIncrement="true"
type="xsd:int" msdata:AllowDBNull="false" use="prohibited" />
<xsd:attribute name="version" form="unqualified" type="xsd:string"
/>
<xsd:attribute name="creator" form="unqualified" type="xsd:string"
/>
</xsd:complexType>
</xsd:element>
<xsd:element name="NewDataSet" msdata:IsDataSet="true"
msdata:Locale="en-AU">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="gpx" />
</xsd:choice>
</xsd:complexType>
<xsd:unique name="rte_Constraint1"
msdata:ConstraintName="Constraint1" msdata:PrimaryKey="true">
<xsd:selector xpath=".//rte" />
<xsd:field xpath="+rte_Id" />
</xsd:unique>
<xsd:unique name="trk_Constraint1"
msdata:ConstraintName="Constraint1" msdata:PrimaryKey="true">
<xsd:selector xpath=".//trk" />
<xsd:field xpath="+trk_Id" />
</xsd:unique>
<xsd:unique name="Constraint1" msdata:PrimaryKey="true">
<xsd:selector xpath=".//gpx" />
<xsd:field xpath="+gpx_Id" />
</xsd:unique>
<xsd:keyref name="gpx_trk" refer="Constraint1"
msdata:IsNested="true">
<xsd:selector xpath=".//trk" />
<xsd:field xpath="+gpx_Id" />
</xsd:keyref>
<xsd:keyref name="trk_trkpt" refer="trk_Constraint1"
msdata:IsNested="true">
<xsd:selector xpath=".//trkpt" />
<xsd:field xpath="+trk_Id" />
</xsd:keyref>
<xsd:keyref name="gpx_rte" refer="Constraint1"
msdata:IsNested="true">
<xsd:selector xpath=".//rte" />
<xsd:field xpath="+gpx_Id" />
</xsd:keyref>
<xsd:keyref name="rte_rtept" refer="rte_Constraint1"
msdata:IsNested="true">
<xsd:selector xpath=".//rtept" />
<xsd:field xpath="+rte_Id" />
</xsd:keyref>
<xsd:keyref name="gpx_wpt" refer="Constraint1"
msdata:IsNested="true">
<xsd:selector xpath=".//wpt" />
<xsd:field xpath="+gpx_Id" />
</xsd:keyref>
</xsd:element>
</xsd:schema>
Kevin Read
S Y N E R G Y S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au
syn.er.gy.
The interaction of two or more agents or forces so that their combined
effect is greater than the sum of their individual effects.
Cooperative interaction among groups that creates an enhanced combined
effect.
egroups+topografix.com on Mon Nov 26 11:43:47 2001 (link), replying to msg
Hello, Monday, November 26, 2001, 2:52:02 AM, Kevin wrote: KR> Here's a quick first draft of the XSD for .gpx - I have also placed it KR> in the files section of yahoogroups.com KR> A few more sample XML packets would be good perhaps members of the list KR> can put some of their sample GPS xml packets up also Thanks Kevin!!! This looks really good! I can follow most of it, but I'm having trouble with some of the *_Id and *_Constraint syntax towards the bottom. Can you post a sample GPX file that uses the schema? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
kevin+synergysa.com.au on Mon Nov 26 14:43:37 2001 (link), replying to msg
The _id etc are auto generated to allow for template processing in XSLT as well as DOM manipulation - consider them a place holder for the processor to assign unique keys. The schema tells the processor to auto create them. Makes it a little more efficient. I took a copy of David Wissenbach's XML -from his site. I took out his extensions and processed that. I would love other exampls to play with also. Do you have any ? Kevin -----Original Message----- From: Dan Foster [mailto:egroups+topografix.com] Sent: Tuesday, 27 November 2001 6:07 AM To: Kevin Read Subject: Re: [gpsxml] Schema - first go Hello, Monday, November 26, 2001, 2:52:02 AM, Kevin wrote: KR> Here's a quick first draft of the XSD for .gpx - I have also placed it KR> in the files section of yahoogroups.com KR> A few more sample XML packets would be good perhaps members of the list KR> can put some of their sample GPS xml packets up also Thanks Kevin!!! This looks really good! I can follow most of it, but I'm having trouble with some of the *_Id and *_Constraint syntax towards the bottom. Can you post a sample GPX file that uses the schema? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com Yahoo! Groups Sponsor <http://rd.yahoo.com/M=212180.1701098.3252983.1269402/D=egroupweb/S=1706 030390:HM/A=812074/R=0/*http://www.verisign.com/cgi-bin/go.cgi?a=b153340 270003000> <http://us.adserver.yahoo.com/l?M=212180.1701098.3252983.1269402/D=egrou pmail/S=1706030390:HM/A=812074/rand=570797438> 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 <http://docs.yahoo.com/info/terms/> . ------=_NextPart_000_0006_01C17723.AE1B7400
davewissenbach+yahoo.com on Tue Nov 27 05:45:32 2001 (link), replying to msg
--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote:
> Hi All
>
> Here's a quick first draft of the XSD for .gpx - I have also
placed it
> in the files section of yahoogroups.com
>
> A few more sample XML packets would be good perhaps members of the
list
> can put some of their sample GPS xml packets up also
>
I've been trying to evaluate my own XML with a similar schema and
have run into a few problems. One problem is getting the order of
the elements straight. I didn't strictly follow the order of Dan's
first examples when I wrote my XML, probably because we didn't have
a schema! One construct in the schema which I found can allow a
flexible order of elements in the waypoint is this:
By putting in the "choice" element, and allowing many choices, this
loosens the schema to allow the elements to occur in any order. I
would recommend that we adopt this more flexible aproach, if the
other participating applications can also parse elements in any
order.
while tag != "/wpt"
{
if(tag == "ele")
else if(tag == "name")
else if(tag == "src")
else if(tag ==
}
<complexType>
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="ele" type="decimal" minOccurs="0"/>
<element name="time" type="string" minOccurs="0"/><!-- Use
dateTime -->
<element name="name" type="string" minOccurs="0"/>
<element name="cmt" type="string" minOccurs="0"/>
<element name="desc" type="string" minOccurs="0"/>
<element name="src" type="string" minOccurs="0"/>
<element name="type" type="string" minOccurs="0"/>
<element name="sym" type="string" minOccurs="0"/>
</choice>
<any namespace="other" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="lat" type="decimal" use="required"/>
<attribute name="lon" type="decimal" use="required"/>
</complexType>
davewissenbach+yahoo.com on Sat Dec 01 10:08:56 2001 (link)
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?
egroups+topografix.com on Tue Dec 11 10:02:54 2001 (link), replying to msg
Hello, I've added support for GPX to all three of my products. You can use the Open and Save As dialogs to read and write GPX data, or convert between GPX and my native LOC file format. I've got a group of testers who may be interested in passing data between my programs and some of the other software out there (Cetus GPS, for example). If you've got a GPX-enabled program that's ready to have some testing, let me know, and I'll mention it in my next beta software mailing. Download the new software: EasyGPS: http://www.easygps.com/beta.asp PanTerra: http://www.topografix.com/beta.asp ExpertGPS: http://www.expertgps.com/beta.asp -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Dec 11 21:43:55 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: I downloaded ExpertGPS beta, read from my GPS, wrote to .gpx file format, and attempted to input to my Map program, at http://www.cableone.net/cdwissenbach. I had to manually edit the end tag of a track to get the gpx file to load. Bug report--GPX outputs the format control %s instead of /trk. Easily fixable, I assume. Other than this minor glitch, a successful transfer of 2000 trackpoints. However, the reverse direction, from file http://www.cableone.net/cdwissenbach/FileFormat.gpx or other Map.exe output to ExpertGPX input does not work. ExpertGPS can read its own gpx file output. (I have changed my sample file slightly and may have broken something, or added unexpected attributes and tags.) > Hello, > > I've added support for GPX to all three of my products. You can use > the Open and Save As dialogs to read and write GPX data, or convert > between GPX and my native LOC file format. > > I've got a group of testers who may be interested in passing data > between my programs and some of the other software out there (Cetus > GPS, for example). If you've got a GPX-enabled program that's ready > to have some testing, let me know, and I'll mention it in my next beta > software mailing. > > Download the new software: > > EasyGPS: http://www.easygps.com/beta.asp > > PanTerra: http://www.topografix.com/beta.asp > > ExpertGPS: http://www.expertgps.com/beta.asp > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
kevin+synergysa.com.au on Tue Dec 11 23:47:49 2001 (link), replying to msg
I assume that the EasyGPS output (minus the little bug) is the release candidate for the GPX format If so, i'll update/rewrite the schema to this and post it for all to see. Can we lock this in then as RC1 ???????? Kevin -----Original Message----- From: davewissenbach [mailto:davewissenbach+yahoo.com] Sent: Wednesday, 12 December 2001 4:14 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: TopoGrafix apps now support GPX --- In gpsxml+y..., Dan Foster <egroups+t...> wrote: I downloaded ExpertGPS beta, read from my GPS, wrote to .gpx file format, and attempted to input to my Map program, at http://www.cableone.net/cdwissenbach. I had to manually edit the end tag of a track to get the gpx file to load. Bug report--GPX outputs the format control %s instead of /trk. Easily fixable, I assume. Other than this minor glitch, a successful transfer of 2000 trackpoints. However, the reverse direction, from file http://www.cableone.net/cdwissenbach/FileFormat.gpx or other Map.exe output to ExpertGPX input does not work. ExpertGPS can read its own gpx file output. (I have changed my sample file slightly and may have broken something, or added unexpected attributes and tags.) > Hello, > > I've added support for GPX to all three of my products. You can use > the Open and Save As dialogs to read and write GPX data, or convert > between GPX and my native LOC file format. > > I've got a group of testers who may be interested in passing data > between my programs and some of the other software out there (Cetus > GPS, for example). If you've got a GPX-enabled program that's ready > to have some testing, let me know, and I'll mention it in my next beta > software mailing. > > Download the new software: > > EasyGPS: http://www.easygps.com/beta.asp > > PanTerra: http://www.topografix.com/beta.asp > > ExpertGPS: http://www.expertgps.com/beta.asp > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > 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 Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . ------=_NextPart_000_0047_01C18339.269FB5A0
kevin+synergysa.com.au on Wed Dec 12 02:52:22 2001 (link), replying to msg
Hi dan Did a test and found a small issue, consider the following snippet of a LOC file saved as GPX: <wpt lat="-27.519783" lon="153.022617"> <name>GC8E2</name> <desc>drewgong moogsie & Spider by Drewgong Moogsie & Spider</desc> <type>geocache</type> <sym>Waypoint</sym> </wpt> The & char in a text area needs to be either escaped or be part of a CDATA section. & is invalid in this location. It should be: <wpt lat="-27.519783" lon="153.022617"> <name>GC8E2</name> <desc>drewgong moogsie & Spider by Drewgong Moogsie & Spider</desc> <type>geocache</type> <sym>Waypoint</sym> </wpt> While you're there you may as well check for all these too. Char, Replacewith <, < &, & >, > ", " ', ' Kevin -----Original Message----- From: Dan Foster [mailto:egroups+topografix.com] Sent: Wednesday, 12 December 2001 4:30 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] TopoGrafix apps now support GPX Hello, I've added support for GPX to all three of my products. You can use the Open and Save As dialogs to read and write GPX data, or convert between GPX and my native LOC file format. I've got a group of testers who may be interested in passing data between my programs and some of the other software out there (Cetus GPS, for example). If you've got a GPX-enabled program that's ready to have some testing, let me know, and I'll mention it in my next beta software mailing. Download the new software: EasyGPS: http://www.easygps.com/beta.asp PanTerra: http://www.topografix.com/beta.asp ExpertGPS: http://www.expertgps.com/beta.asp -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=215002.1711356.3237013.1261774/D=egroupweb/S=1706 030390:HM/A=847665/R=0/*http://ads.x10.com/?bHlhaG9vbW9uc3RlcjcuZGF0=100 8093775%3eM=215002.1711356.3237013.1261774/D=egroupweb/S=1706030390:HM/A =847665/R=1> <http://us.adserver.yahoo.com/l?M=215002.1711356.3237013.1261774/D=egrou pmail/S=1706030390:HM/A=847665/rand=441025301> 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 <http://docs.yahoo.com/info/terms/> . ------=_NextPart_000_0060_01C18352.22A35150
egroups+topografix.com on Wed Dec 12 09:23:13 2001 (link), replying to msg
Hello, Wednesday, December 12, 2001, 12:43:51 AM, Dave wrote: d> --- In gpsxml+y..., Dan Foster <egroups+t...> wrote: d> I downloaded ExpertGPS beta, read from my GPS, wrote to .gpx file d> format, and attempted to input to my Map program, at d> http://www.cableone.net/cdwissenbach. I had to manually edit the end d> tag of a track to get the gpx file to load. Bug report--GPX outputs d> the format control %s instead of /trk. Easily fixable, I assume. d> Other than this minor glitch, a successful transfer of 2000 d> trackpoints. d> However, the reverse direction, from file d> http://www.cableone.net/cdwissenbach/FileFormat.gpx or other Map.exe d> output to ExpertGPX input does not work. ExpertGPS can read its own d> gpx file output. (I have changed my sample file slightly and may d> have broken something, or added unexpected attributes and tags.) Thanks for pointing out the broken </trk> tag - I've fixed this. I'm working on making my parser read Dave's FileFormat.gpx sample. Dave - you've got the same illegal characters that my programs have (see Kevin's email). I'd prefer to use the CDATA[] method to wrap strings, rather than parse all strings for escaped characters. Any other thoughts? Do we need to support both ways? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Thu Dec 13 04:55:55 2001 (link), replying to msg
--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote: > I assume that the EasyGPS output (minus the little bug) is the release > candidate for the GPX format > > If so, i'll update/rewrite the schema to this and post it for all to > see. > > Can we lock this in then as RC1 ???????? > > Kevin Kevin, When you rewrite the schema, please look at my version at www.cableone.net/cdwissenbach/gpx.xsd. The features of interest are the use of choice, to allow elements in any order, and also the use of the any element, restricted to other namespace. This allows validation of the wissenbach:layer, and other private tags while still rejecting addiditional tags. (I'm validating with the Xerces 1_5_2 parser, which only seems to support the noNamespace Schema location. Dave
davewissenbach+yahoo.com on Thu Dec 13 05:18:38 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > you've got the same illegal characters that my programs have (see > Kevin's email). > > I'd prefer to use the CDATA[] method to wrap strings, rather than > parse all strings for escaped characters. Any other thoughts? Do we > need to support both ways? > Yikes. Thanks for pointing this out. I guess that's a good reason for using an XML-compliant parser. Right now, I've got an extremely simple parser. But given that we're calling our format an XML 1.0 format, we'd better be able to parse both to be in compliance with the XML1.0 standard. Which means that we need to parse both methods. But for now, I'll use CDATA as well, to postpone the problem of unwrapping those pesky escaped characters. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
kevin+synergysa.com.au on Thu Dec 13 05:57:41 2001 (link)
Hi Guys Can you email to me (via the list if you like) a full sample of the GPXML you are producing. I need some sample to test against the schema, I'll also be creating some Java classes to handle the packets as well if any one is interested. At this stage, i'll ignore other namespace extensions and concentrate on the base schema for: Waypoints, Tracks and Routes I'm especially interested in locking down (in my mind) the mandatory and optional elements alomg with the constraints for each type. If you can send some files, I'll be able to get the next schema done over the weekend. Dan: How's the revised beta of EasyGPS going? Kevin Kevin Read S Y N E R G Y S A Phone. 08 8278 6296 Fax. 08 8278 6296 Mobile. 0419 61 7100 Email. kevin+synergysa.com.au Web. http://www.synergysa.com.au <http://www.synergysa.com.au/> Synergy SA Logo <http://www.synergysa.com.au/images/sml_logo.jpg> syn.er.gy. 1. The interaction of two or more agents or forces so that their combined effect is greater than the sum of their individual effects. 2. Cooperative interaction among groups that creates an enhanced combined effect. _____ ------=_NextPart_001_007F_01C18435.FBA56C20
egroups+topografix.com on Fri Dec 14 10:23:39 2001 (link), replying to msg
Hello, Thursday, December 13, 2001, 8:56:32 AM, Kevin wrote: KR> Dan: How's the revised beta of EasyGPS going? I fixed all the problems that were found in my previous GPX implementation, and wrapped description strings in CDATA. http://www.easygps.com/beta.asp http://www.expertgps.com/beta.asp -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
kevin+synergysa.com.au on Fri Dec 14 18:05:37 2001 (link)
Hi All
here it is:
Draft #2 of the Release candidate for the Schema
I'll Upload it to the site as well.
<?xml version="1.0" encoding="utf-8"?><xsd:schema
xmlns="http://groups.yahoo.com/group/gpsxml"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" id="gpx"
targetNamespace="http://groups.yahoo.com/group/gpsxml/1.0/GPX">
<xsd:element name="gpx">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="wpt" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ele" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="name" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="sym" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="desc" type="xsd:string" minOccurs="0"
use="optional"/>
</xsd:sequence>
<xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
<xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="rte" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="rtept" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"
minOccurs="0" use="optional"/>
<xsd:element name="sym" type="xsd:string"
minOccurs="0" use="optional"/>
<xsd:element name="ele" type="xsd:string"
minOccurs="0" use="optional"/>
<xsd:element name="desc" type="xsd:string"
minOccurs="0" use="optional"/>
</xsd:sequence>
<xsd:attribute name="seq" type="xsd:decimal"
use="optional"/>
<xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
<xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="trk" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="desc" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="trkpt" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ele" type="xsd:string"
minOccurs="0" use="optional"/>
<xsd:element name="time" type="xsd:dateTime"
minOccurs="0" use="optional"/>
</xsd:sequence>
<xsd:attribute name="seq" type="xsd:decimal"
use="optional"/>
<xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
<xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="version" type="xsd:string" use="optional"/>
<xsd:attribute name="creator" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Kevin Read
S Y N E R G Y S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au
syn.er.gy.
The interaction of two or more agents or forces so that their combined
effect is greater than the sum of their individual effects.
Cooperative interaction among groups that creates an enhanced combined
effect.
gpsxml+yahoogroups.com on Fri Dec 14 18:07:03 2001 (link)
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the gpsxml group. File : /Schema/gpsxml_1.0.xsd Uploaded by : kevin_read2001 <kevin+synergysa.com.au> Description : GPS XML Schema RC 1.0 You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/Schema/gpsxml_1.0.xsd To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, kevin_read2001 <kevin+synergysa.com.au>
kevin+synergysa.com.au on Fri Dec 14 18:15:56 2001 (link), replying to msg
Bugger - uploaded too soon.
I made a quick change to the targetNamespace attribute to match the
storage on Yahoo.
Its now:
http://groups.yahoo.com/group/gpsxml/files/Schema
Or should it be:
http://groups.yahoo.com/group/gpsxml/files/Schema/gpsxml_1.0.xsd
Who knows (or cares )
Kevin
-----Original Message-----
From: Kevin Read [mailto:kevin+synergysa.com.au]
Sent: Saturday, 15 December 2001 12:35 PM
To: gpsxml+yahoogroups.com
Subject: [gpsxml] Schema Rel Candidate 1.0
Hi All
here it is:
Draft #2 of the Release candidate for the Schema
I'll Upload it to the site as well.
<?xml version="1.0" encoding="utf-8"?><xsd:schema
xmlns="http://groups.yahoo.com/group/gpsxml"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" id="gpx"
targetNamespace="http://groups.yahoo.com/group/gpsxml/1.0/GPX">
<xsd:element name="gpx">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="wpt" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ele" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="name" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="sym" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="desc" type="xsd:string" minOccurs="0"
use="optional"/>
</xsd:sequence>
<xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
<xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="rte" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="rtept" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"
minOccurs="0" use="optional"/>
<xsd:element name="sym" type="xsd:string"
minOccurs="0" use="optional"/>
<xsd:element name="ele" type="xsd:string"
minOccurs="0" use="optional"/>
<xsd:element name="desc" type="xsd:string"
minOccurs="0" use="optional"/>
</xsd:sequence>
<xsd:attribute name="seq" type="xsd:decimal"
use="optional"/>
<xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
<xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="trk" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="desc" type="xsd:string" minOccurs="0"
use="optional"/>
<xsd:element name="trkpt" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ele" type="xsd:string"
minOccurs="0" use="optional"/>
<xsd:element name="time" type="xsd:dateTime"
minOccurs="0" use="optional"/>
</xsd:sequence>
<xsd:attribute name="seq" type="xsd:decimal"
use="optional"/>
<xsd:attribute name="lat" type="xsd:decimal"
use="required"/>
<xsd:attribute name="lon" type="xsd:decimal"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="version" type="xsd:string" use="optional"/>
<xsd:attribute name="creator" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Kevin Read
S Y N E R G Y S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au
syn.er.gy.
The interaction of two or more agents or forces so that their combined
effect is greater than the sum of their individual effects.
Cooperative interaction among groups that creates an enhanced combined
effect.
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/
kevin+synergysa.com.au on Fri Dec 14 20:12:30 2001 (link)
Hi All
Proposal: Change the Sequence attribute to be required - was optional.
Currently the Schema defines the "seq" attribute of tracks and routes to
be optional, given that processing of an XML file can, in theory, be
done in any order by the processor, i do believe that we should change
seq to required to ensure processing is done in the correct order when
required.
Change would be:
<xsd:attribute name="seq" type="xsd:decimal" use="optional"/>
to:
<xsd:attribute name="seq" type="xsd:decimal" use="required"/>
this change would be for both tracks and routes - if you app is unable
to supply a sequence order - just populate with 0's (zeros) - but
1-2-3-4-5-6-7 would be great. This also means I can use order-by
select="+seq" desc in the XSLT to display the reverse track in one easy
swoop.
Kevin
Kevin Read
S Y N E R G Y S A
Phone. 08 8278 6296
Fax. 08 8278 6296
Mobile. 0419 61 7100
Email. kevin+synergysa.com.au
Web. http://www.synergysa.com.au <http://www.synergysa.com.au/>
Synergy SA Logo <http://www.synergysa.com.au/images/sml_logo.jpg>
syn.er.gy.
1. The interaction of two or more agents or forces so that their
combined effect is greater than the sum of their individual effects.
2. Cooperative interaction among groups that creates an enhanced
combined effect.
_____
------=_NextPart_001_0019_01C18576.B0EDBC90
gpsxml+yahoogroups.com on Fri Dec 14 21:02:50 2001 (link)
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the gpsxml group. File : /Sample XML Files/Kevin Read Untitled.gpx Uploaded by : kevin_read2001 <kevin+synergysa.com.au> Description : KR: Sample GPX file You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/Sample%20XML%20Files/Kevin%20Read%20Untitled.gpx To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, kevin_read2001 <kevin+synergysa.com.au>
gpsxml+yahoogroups.com on Fri Dec 14 21:04:00 2001 (link)
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the gpsxml group. File : /Misc/gpx xslt.zip Uploaded by : kevin_read2001 <kevin+synergysa.com.au> Description : XSLT Stylesheet to transform and view GPX files You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/Misc/gpx%20xslt.zip To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, kevin_read2001 <kevin+synergysa.com.au>
davewissenbach+yahoo.com on Sat Dec 15 16:55:02 2001 (link), replying to msg
--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote: > > http://groups.yahoo.com/group/gpsxml/files/Schema/gpsxml_1.0.xsd > > Who knows (or cares ) > > Kevin > > > -----Original Message----- > From: Kevin Read [mailto:kevin+s...] > Sent: Saturday, 15 December 2001 12:35 PM > To: gpsxml+y... > Subject: [gpsxml] Schema Rel Candidate 1.0 > > > Hi All > > here it is: > ... <xsd:element name="ele" type="xsd:string" minOccurs="0" use="optional"/> I've played with this and have a few nits to pick: The xerces 1_5_2 parser (which I'm not using in my applications but am using to validate samples) complains about the use attribute in this and other element declarations. I believe that this is because the use attribute is a contstraint valid for attributes, not elemements. Also, in my samples I am using the element src in wpt, trk, and rte, for a line of text such as "logged by Dave Wissenbach with Garmin GPS". I believe that this usage is consistent with our previous discussion on the group, and that therefore src should be valid and added to the schema. My newer sample FileFormat.gpx adds the src element after desc. This tag wasn't in my original FileFormat.gpx. For some reason having to do with the target namespace, I wasn't able to even attempt to validate with an unmodified schema. But I believe that this is a limitation of the xerces parser. How do you validate XML and test the schema? I think that if I can use the same reference parser I'll be way ahead. (I'd validate only sample files produced by my application-- I'm using my own parsing internally which will not validate. Thanks for posting the latest Schema, Dave And of course there's still the question of providing a method for the private tags.
davewissenbach+yahoo.com on Sat Dec 15 16:59:42 2001 (link), replying to msg
--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote: > Hi All > > > Proposal: Change the Sequence attribute to be required - was optional. > > Currently the Schema defines the "seq" attribute of tracks and routes to > be optional, given that processing of an XML file can, in theory, be > done in any order by the processor, i do believe that we should change > seq to required to ensure processing is done in the correct order when > required. > > Change would be: > > <xsd:attribute name="seq" type="xsd:decimal" use="optional"/> > > to: > > <xsd:attribute name="seq" type="xsd:decimal" use="required"/> > > this change would be for both tracks and routes - if you app is unable > to supply a sequence order - just populate with 0's (zeros) - but > 1-2-3-4-5-6-7 would be great. This also means I can use order-by > select="+seq" desc in the XSLT to display the reverse track in one easy > swoop. > > Kevin > This might also be useful for people who for whatever reason want to manually edit, and is easy to do. So I'm not opposed to this change-- but I'd like to see comments from others before agreeing.
egroups+topografix.com on Sun Dec 16 15:24:37 2001 (link), replying to msg
Hello, Friday, December 14, 2001, 11:12:10 PM, Kevin wrote: KR> Proposal: Change the Sequence attribute to be required - was optional. KR> Currently the Schema defines the "seq" attribute of tracks and routes to KR> be optional, given that processing of an XML file can, in theory, be KR> done in any order by the processor, i do believe that we should change KR> seq to required to ensure processing is done in the correct order when KR> required. Are there any known examples of XML parsers that exhibit this behavior? Is this a problem in theory, or in practice? KR> Change would be: KR> <xsd:attribute name="seq" type="xsd:decimal" use="optional"/> KR> to: KR> <xsd:attribute name="seq" type="xsd:decimal" use="required"/> KR> this change would be for both tracks and routes - if you app is unable KR> to supply a sequence order - just populate with 0's (zeros) - but KR> 1-2-3-4-5-6-7 would be great. I have a hard time imagining how an application would be able to handle this correctly for cases other than 1-2-3... Have you considered all the strange sequences you'll now be accepting? 7-2-5-4... 1-2-3-7-8-9... 1-2-3-2-3-4-5... KR> This also means I can use order-by KR> select="+seq" desc in the XSLT to display the reverse track in one easy KR> swoop. One of the first decisions we made was that we would optimize GPX for *transferring* data, and that *transforming* data would take a secondary role in the format. At this point, I don't see a significant benefit in requiring the "seq" element that would offset the additional parsing and processing burden on all GPX-enabled applications. But I'm completely open to further discussions. What do others think? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Sun Dec 16 18:01:17 2001 (link), replying to msg
--- In gpsxml+y..., "Kevin Read" <kevin+s...> wrote: > Hi Guys > > Can you email to me (via the list if you like) a full sample of the > GPXML you are producing. > Latest version of gpsxml provided by Map 1.2 is at my web page http://www.cableone.net/cdwissenbach/FileFormat.gpx This version, Map 1.2, inserts CDATA sections only when special characters are detected.
davewissenbach+yahoo.com on Tue Dec 18 06:23:30 2001 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Thursday, December 13, 2001, 8:56:32 AM, Kevin wrote: > > KR> Dan: How's the revised beta of EasyGPS going? > > I fixed all the problems that were found in my previous GPX > implementation, and wrapped description strings in CDATA. > > http://www.easygps.com/beta.asp > http://www.expertgps.com/beta.asp > Contact! ExpertGPS can now read the gpx format output from my program, Map, and Map can read the output of ExpertGPS. By the way, I really like the automatic downloading of map data from the internet provided by ExpertGPS and the user interface for trail selection and display. This is a really nice program. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
davewissenbach+yahoo.com on Tue Jan 01 15:31:25 2002 (link), replying to msg
I've switched to Xerces-C++ parser version 1.6.0, for schema validation. This parser now provides full support for schema. On my web site, the file http://www.cableone.net/cdwissenbach/FileFormat.gpx now references two schemas, http://www.cableonenet/cdwissenbach/gpsxml_0.3.xsd and http://www.cableone.net/cdwissenbach/wissenbach.xsd for validating public and private namespaces, respectively. This example is fully valid using the sample SAXCount application provided with the xerces parser. In the gpsxml_0.3.xsd I experiment with the derivation of wpt, trkpt, and rtept from a basic point type, and the definition of a modelGroup for descriptive data about tracks, waypoints, and routes. However, doing this required a slight modification of the order, as elements from the base type need to always come first! I also added partial annotation, because I thing that a usable schema needs to explain itself. I believe that this new approach to the Schema provides better clarity and maintainability than the Russian Doll design previously used--I learned this from the book, Professional XML Schemas by Duckett, Griffin et Al. Wrox Press. ISBN 1-861005-47-4. Comments? If this approach is further acceptable I'll add better examples to the annotation.
carsten.kurz+toma.de on Thu Jan 03 10:25:38 2002 (link)
Hi there, I am a dedicated user of Palm PDA GPS applications (and I am doing some businiess with Palm/PDA-GPS interfacing). I started an initiative among Palm/PDA GPS application programmers to develop a standard for exchange of waypoints/poi among different palm applications. The Palm PDA has user definable address book fields, and my idea was to store location information in one of those fields to add geo locations to an address. Some programmers suggested using an XML tag like synthax. Kjeld Jensen then pointed me towards GPX. Well, here I am now. Our goal is, of course, much simpler than that of GPX - so far we only need some kind of waypoint definition. What people suggested were lat/lon, elevation, timestamp, IconID, datum, etc.. With XML I guess this is open for any kind of extension. A few people came up with the limited memory ressources on PDA platforms. Kjeld told me that GPX has quite short tag names, and I liked what I saw from his CETUS GPX examples. My questions now: -Is there a simple, text-like definition of GPX? I found some files in the file area, but it seems there is no tag definition or something. -Some programmers want to use IconIDs. I browsed the archive and found that GPX doesn't like IconIDs, probably because there is no standard for them, and IDs are too abstract. I can understand that, but if an application want's to store/exchange an Icon, it would have to maintain a full text table of all Icons, and there would have to be at least a minimum recommended Icon text table somewhere? Can someone please clear this up for me? At first I thought it would be the easiest to simply adopt Garmins symbol table. There is a Palm Waypoint Tool for Garmins (GPilotS) which stores and displays the GII+ icon set. This would certainly be no problem until other manufacturers get on board. Any ideas how to handle this? - Are you sure you do not want a <datum> tag? I know WGS84 is widely used for navigation end enduser apps, but there are still a lot of scientific applications with different reference systems - Though the GPX tags are short, space in those address fields is limited to 255bytes. What do you think about simply using the basic type tag, and not the full XML header for storage, like simply writing <wpt lat="50.9789900" lon="6.7845000"> </wpt> into the data field? The sample GPX Waypoint including the full header from CETUS written to a memopad is already more than 260 chars. Any suggestions?
davewissenbach+yahoo.com on Thu Jan 03 20:28:30 2002 (link), replying to msg
--- In gpsxml+y..., "c_kurz" <carsten.kurz+t...> wrote: > Hi there, > > I am a dedicated user of Palm PDA GPS applications (and I am doing > some businiess with Palm/PDA-GPS interfacing). I started an initiative > among Palm/PDA GPS application programmers to develop a standard for > exchange of waypoints/poi among different palm applications. The Palm > PDA has user definable address book fields, and my idea was to store > location information in one of those fields to add geo locations to an > address. Some programmers suggested using an XML tag like synthax. > Kjeld Jensen then pointed me towards GPX. Well, here I am now. > > Our goal is, of course, much simpler than that of GPX - so far we only > need some kind of waypoint definition. > > What people suggested were lat/lon, elevation, timestamp, > IconID, datum, etc.. With XML I guess this is open for any kind of > extension. > > A few people came up with the limited memory ressources on PDA > platforms. Kjeld told me that GPX has quite short tag names, and I > liked what I saw from his CETUS GPX examples. > > My questions now: > > -Is there a simple, text-like definition of GPX? I found some files in > the file area, but it seems there is no tag definition or something. > Eventually, we'll get around to fully annotating the Schema. See the schema at www.cableone.net/cdwissenbach/gpsxml_0.3.xsd for an example of annotation. > -Some programmers want to use IconIDs. I browsed the archive and found > that GPX doesn't like IconIDs, probably because there is no standard > for them, and IDs are too abstract. I can understand that, but if an > application want's to store/exchange an Icon, it would have to > maintain a full text table of all Icons, and there would have to be at > least a minimum recommended Icon text table somewhere? Can someone > please clear this up for me? > At first I thought it would be the easiest to simply adopt Garmins > symbol table. There is a Palm Waypoint Tool for Garmins (GPilotS) > which stores and displays the GII+ icon set. This would certainly be > no problem until other manufacturers get on board. > Any ideas how to handle this? > What I support in my Map application is the subset of Garmin symbols which are supported by the eTrex Summit. Unknown symbols just default to the flag symbol. > - Are you sure you do not want a <datum> tag? I know WGS84 is widely > used for navigation end enduser apps, but there are still a lot of > scientific applications with different reference systems > > - Though the GPX tags are short, space in those address fields is > limited to 255bytes. What do you think about simply using the basic > type tag, and not the full XML header for storage, like simply writing > > <wpt lat="50.9789900" lon="6.7845000"> </wpt> > > into the data field? The sample GPX Waypoint including the full > header from CETUS written to a memopad is already more than 260 chars. Only the attributes are required, so the above example conforms to the gpsxml standard, such as it is. > Any suggestions?
carsten.kurz+toma.de on Fri Jan 04 10:04:01 2002 (link), replying to msg
> What I support in my Map application is the subset of Garmin symbols > which are supported by the eTrex Summit. Unknown symbols just > default to the flag symbol. But how do you match the symbol/icon entries in an GPX file to those of your application or to those of a specific receiver? By full string matching? Excuse me, I'm not that familiar with GPX right now - I saw a few GPX samples with 'summit' in them. Does GPX also contain data to identify a specific receivers Icon table? I will try to find my way through this schema, though I don't know much about XML. - Carsten
egroups+topografix.com on Fri Jan 04 10:24:00 2002 (link), replying to msg
Hello, Friday, January 04, 2002, 1:04:02 PM, Carsten wrote: >> What I support in my Map application is the subset of Garmin symbols >> which are supported by the eTrex Summit. Unknown symbols just >> default to the flag symbol. c> But how do you match the symbol/icon entries in an GPX file to those c> of your application or to those of a specific receiver? By full string c> matching? Exactly. If your application has a symbol called "Summit" available, you use that symbol. If it doesn't, you use the default symbol, as defined by your program. The user will understand this. If he's exchanging data with another user who has the same GPS, the symbols will always match. If he's exchanging data with someone using a different manufacturer's GPS, he should expect that the symbols won't come across. He may even get lucky: if Garmin and Magellan both have a "House" symbol, it will come through intact, even though Garmin uses a 16 bit integer, and Magellan uses a letter to represent House. To make this work, you should use the exact name of the symbol as shown on the GPS. For example, "Trail Head" (Garmin eTrex), and not "Trailhead" or "trail head". If you're writing a Palm app to act as a GPS, you should consider naming your symbols in a way that will allow compatibility with the named symbols used by Garmin, Magellan, etc. If I was doing this, I'd consider adopting the Garmin eTrex symbol set, which is likely the most popular one in use. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
carsten.kurz+toma.de on Mon Jan 07 12:43:15 2002 (link)
Does anyone know wether there is demo of Mac GPS Pro available somewhere? I can't find any hint on the Mac GPS Pro site, but I keep hearing about a demo. - Carsten
egroups+topografix.com on Thu Jan 10 13:59:38 2002 (link), replying to msg
Hello, I'm going to spend some time this week documenting our work on GPX, and trying to wrap up some unfinished decisions, so we can start deploying GPX 1.0 applications. To keep it easier to follow the conversations, I'll post each issue as a separate e-mail with a relevant subject line. I encourage you, if you have remaining questions or concerns about GPX, to share your ideas or questions now. Best wishes in 2002 to all of you! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Jan 10 14:04:18 2002 (link), replying to msg
Hello, Are Schemas required in GPX? Dave proposed a method for specifying a public and a private schema for GPX validation. It looks good, and I haven't heard any counter-proposals. But we haven't discussed whether schemas are: A. required? B. optional? C. forbidden? B is the default answer. Anyone care to argue for A or C? Assuming we go with A or B, it seems like we should all refer to a master public schema. I'd be happy to host it (and the rest of the GPX documentation) here at http://www.topografix.com/gpx/ Or we can use the http://groups.yahoo.com/group/gpsxml/ file area, but that isn't accessible without logging in. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Fri Jan 11 21:53:34 2002 (link), replying to msg
Kjeld, I don't think that the schema is necessary, but I think that it can make the format a lot easier to figure out. The sample schema gpsxml_0.3.xsd on my web site also includes annotations, which ultimately could be extended to also provide examples. But there is the downside to the schema in that it enforces a particular order on elements, which is not actually enforced by the applications. Right now my program, which I'm calling Wissenbach Map, interoperates well with ExpertGPS with beta gpsxml support, even though ExpertGPS doesn't exactly conform to the schema. (It can't, because I changed the element order after Dan published!). The problem right now is the order of elements, which I arbitrarily changed in order to use the principle of inheritance in the schema. (Allowing arbitrary element order would make the schema very complicated, which is a downside to using a schema.) But the schema can provide a central place to insert documentation, including a recommendation that applications which conform to the GPS standard should be written with a high degree of tolerance for such things as order and unexpected tags. So I'd say that applications should attempt to conform to the schema, but not to validate against the schema. (I validate my own output at development time, but I don't validate yours at run time.) Then, when you add new tags, with explanation, such as hdop and vdop to the schema, you alter the schema to include these new tags, with examples and annotation. I'll accept Dan's offer to maintain and explain, or at least host, the schema. I found that I had to put a copy on my personal web page in order to see it and validate. Without the support of an authoring program such as ExpertGPS and a reading program such as EasyGPS the gpsxml format won't reach critical mass. In the long run the presence of a well-documented, professionally presented schema, with sample output which corresponds exactly to that schema, will be the only way to enable others to interoperate with our applications. The 100-odd messages in this discusssion group have become way too complex for any of us to follow. Remember that standards are what made the World Wide Web possible in the first place. Dave --- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote: > > >Dave proposed a method for specifying a public and a private schema > >for GPX validation. It looks good, and I haven't heard any > >counter-proposals. But we haven't discussed whether schemas are: > >A. required? > >B. optional? > >C. forbidden? > > Well let me try arguing for C (for GPX version 1.0) > > The way I see it we nee to publish a version "1.0" of GPX in order to gain > some experience. In my opinion this format should be quite simple to > implement which will have the following advantages: > > - for people who haven't participated in the discussions it is easier to > get the idea without having to focus on schemes which requires some degree > of XML knowledge. > > - we will probably get more people to support it as it is easier to > implement (everybody have to start from scratch) > > - it will be easier for us to implement > > I therefore suggest, that we publish this first version of GPX without > support for XML schemes. Instead it should be based on a number of simple > XML compliant directives (authored by Dan and supported by the rest of us) > published on a dedicated GPX homepage. The homepage should also maintain a > list of applications which supports the GPX 1.0 format (measured on that > all the directives are followed). > > This will definitely cause problems, but it is the only way to... > > - move to "working release" as soon as possible (January) > - gain some valuable experience > > When we discover problems - probably mostly due to the lack of strict > directives, we discuss them and implement them in 1.01 and so on. > > Along with this we should start focusing on version 1.1 which I believe > should contain optional use of XML schemes. > > My five (euro) cents > > Kjeld > > ______________________ > Kjeld Jensen > N 55� 22' E 10� 24' > Email: gps+c... > http://www.cetus.dk/gps
egroups+topografix.com on Wed Jan 16 11:15:36 2002 (link), replying to msg
Hello,
Thursday, January 10, 2002, 5:01:32 PM, I wrote:
DF> Are Schemas required in GPX?
I didn't hear anyone argue that we should *never* support schemas.
(Kjeld argued that we should support them at a later date). So it
sounds like there's consensus that schemas are a good thing, and GPX
should eventually support them.
Unfortunately, if we're to have backwards compatibility, we need to
make some decisions now (like the order of elements) so that we'll be
able to apply a reasonable schema to GPX in the future.
As I sat down to start writing documentation, it became clear that the
detail I was putting into each element description was really just a
schema in English. Also, I started thinking about how we were going
to "certify" new GPX developers (to make sure their GPX output was
valid). Having a schema is a very fast way to write a validation
checker - just see if the new files validate against the schema!
So, here are my recommendations:
1. We should create an official schema before releasing GPX 1.0.
2. We should agree on an official validation tool and method for
certifying that GPX files are valid.
3. We should adopt a namespace versioning method so that new versions
of GPX each have a new schema.
4. I should write some documentation to accompany the GPX schema,
since reading schemas is a bit tricky. (But the schema is still
the official definition of GPX.)
I've read through the schemas proposed by Kevin and Dave, and created
a new version 0.4 schema which draws on both ideas. Strangely, I
found that the great documentation in Dave's latest schema actually
made it harder to read, so I've stuck with inline comments. I stuck
with Dave's element ordering, but used the flat format of Kevin's
schema to make it easier (to my mind) to determine what tags are
allowed for each object.
To support versioning, I've created sub-folders at
http://www.topografix.com/GPX/ for the major and minor versions of the
standard, so version 0.4 lives at
http://www.topografix.com/GPX/0/4/gpx.xsd
As far as validation goes, I've started using the Xerces 1.6.0 parser
as suggested by Dave, and suggest that we adopt it as our validation
tool. I'll put together some instructions for validating GPX files if
we choose to go this route. (Dave: I'm using the following options:
"saxcount -n -s -f -v=always test_gpx_file.gpx")
I've updated my software to reference this schema, and have created a
private schema for testing purposes.
http://www.topografix.com/GPX/Private/TopoGrafix/0/1/topografix.xsd
I'll post later tonight once new beta versions of my software are
available for use.
Please give some thought to the recommendations I've proposed, and
share your comments.
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Wed Jan 16 21:34:45 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > ... > > I've read through the schemas proposed by Kevin and Dave, and created > a new version 0.4 schema which draws on both ideas. Strangely, I > found that the great documentation in Dave's latest schema actually > made it harder to read, so I've stuck with inline comments. I stuck > with Dave's element ordering, but used the flat format of Kevin's > schema to make it easier (to my mind) to determine what tags are > allowed for each object. > Yes, as I was writing the 0.3 schema I came to the same realization, and my intention was to patch it up with examples in the annotation. And of course you recognize that some of the documentation in that schema was lifted straight out of your own posts. What I was doing was experimenting with the idea of inheritance in the schema. I think that going back to the anonymous type method proposed by Kevin Read is OK. The schema will probably be slightly more difficult to maintain and extend, but much easier to read. > To support versioning, I've created sub-folders at > http://www.topografix.com/GPX/ for the major and minor versions of the > standard, so version 0.4 lives at > http://www.topografix.com/GPX/0/4/gpx.xsd > I think that versioning will work well. I assume that a version 0.5 schema will validate a 0.4 document--or that we'll try to keep backward compatibility as the schema is extended to include more concepts. > As far as validation goes, I've started using the Xerces 1.6.0 parser > as suggested by Dave, and suggest that we adopt it as our validation > tool. I'll put together some instructions for validating GPX files if > we choose to go this route. (Dave: I'm using the following options: > "saxcount -n -s -f -v=always test_gpx_file.gpx") > I used the same command line but left off the -v=always. > I've updated my software to reference this schema, and have created a > private schema for testing purposes. > http://www.topografix.com/GPX/Private/TopoGrafix/0/1/topografix.xsd > > I'll post later tonight once new beta versions of my software are > available for use. > > Please give some thought to the recommendations I've proposed, and > share your comments. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
egroups+topografix.com on Fri Jan 18 10:43:35 2002 (link), replying to msg
Hello, I've updated my beta software to read/write GPX 0.4. The new software can be downloaded from: EasyGPS: http://www.easygps.com/beta.asp PanTerra: http://www.topografix.com/beta.asp ExpertGPS: http://www.expertgps.com/beta.asp -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Fri Jan 18 17:35:09 2002 (link), replying to msg
Hello, I've written several GPX documents to provide an overview of GPX (for developers and for GPS users). I still need to write a developer's document explaining the specifics of writing a GPX. Please feel free to comment on the documentation. Offline comments can be sent to gpx+topografix.com Overview: http://www.topografix.com/gpx.asp Links to: GPX for GPS Users GPX for Developers Validating your GPX output GPX Resources GPX Schema 0.4 If you'd like your GPX application or webpage listed on the GPX Resources page, send me your URL. I won't list your app unless you request it, since we're all still in development. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Sun Jan 20 21:03:00 2002 (link), replying to msg
--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote:
...
> They are added below the <type> element definition. <fix> should
be either
> "2D" or "3D" but I don't know how to specify this (Dave?)
>
Here's an equivalent example from my private elements, which I
tested and found to work. (This is from the schema which evaluates
my private elements. Because nobody else will use the layer element,
this element fits into the any wildcard slot from the output of my
GPS program, which I vainly call "Wissenbach Map". I think that the
type definition can be anywhere in the schema, but I'm not sure
about this.
<xs:simpleType name="LayerType">
<xs:restriction base="xs:string">
<xs:enumeration value="plan_log"/>
<xs:enumeration value="trailmap"/>
</xs:restriction>
</xs:simpleType>
<xs:element name = "layer" type="LayerType"/>
>
> What do you think of all this?
>
> Best regards
> Kjeld Jensen
>
> ______________________
> Kjeld Jensen
> N 55� 22' E 10� 24'
> Email: kjeld+C...
> http://www.CetusGPS.dk
egroups+topografix.com on Tue Jan 22 09:19:39 2002 (link), replying to msg
Hello, I've got a few questions about units for some of the new GPX tags. Also, any objections to adding the <src> tag to <rte> and <trk> in addition to <rtept> and <trkpt>? For many tracks, I'd just tag the source of the <trk> element since the source doesn't change for any of the <trkpt> elements. Sunday, January 20, 2002, 6:32:14 AM, Kjeld wrote: KJ> <fix> should be either KJ> "2D" or "3D" Can we also add a representation for "no fix"? Many GPS will allow you to write a new trackpoint at a set time interval, and if this occurs when no satellite lock is present, you'll get a trackpoint with no fix. There are at least two ways to express this. What do you think of the following: <fix>None</fix> or: <sat>0</sat> I prefer <fix>None</fix> - it seems to me to be more explicit. For the elements below, we need to agree on units. Here's what NMEA uses: KJ> <xsd:element name="course" type="gpx:course" minOccurs="0"/> degrees, true. Is this what you intended? KJ> <xsd:element name="speed" type="xsd:decimal" minOccurs="0"/> NMEA: knots (nautical miles per hour). GPX: we agreed to use metric. meters/second would be the obvious choice. Thoughts? KJ> <xsd:element name="fix" type="xsd:string" minOccurs="0"/> type="xsd:string" gets replaced with an enum, as per Dave's email. There are two NMEA messages that report fix, and they use different values: GSA: 1 = fix not available 2 = 2D 3 = 3D GGA: 0 = fix not available 1 = GPS SPS Mode 2 = Differential GPS, SPS Mode 3 = PPS Mode (military signal) KJ> <xsd:element name="sat" type="xsd:positiveInteger" minOccurs="0"/> non-negative integer if we allow <sat>0</sat> KJ> <xsd:element name="hdop" type="xsd:decimal" minOccurs="0"/> KJ> <xsd:element name="vdop" type="xsd:decimal" minOccurs="0"/> KJ> <xsd:element name="pdop" type="xsd:decimal" minOccurs="0"/> I've never been able to find an exact definition of these terms which includes units. We'll just use the raw numbers from the GPS. KJ> Since memory is limited on a Palm I will probably remove the schema KJ> reference from the waypoint gpx files generated by Cetus GPS when we reach KJ> 1.0. But as long as we still make modifications to the schema I will leave KJ> it there. I think this is a bad idea. A GPX file without a reference to the schema won't validate. The reference does take up some space in the file, but no more than one or two waypoints or tracks in the file. I'd expect that the entire GPX header including schema reference adds less than 1% to the average GPX file. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Jan 22 21:02:39 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > I've got a few questions about units for some of the new GPX tags. > > Also, any objections to adding the <src> tag to <rte> and <trk> in > addition to <rtept> and <trkpt>? For many tracks, I'd just tag the > source of the <trk> element since the source doesn't change for any of > the <trkpt> elements. > That's a difference between the content model of my unofficial 0.3 schema and the official 0.4 revision. My Wissenbach Map program failed validation against the 0.4 schema only because I used <src> in both <rte> and <trk>, so of course I heartily endorse this change! > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
hamish+travellingkiwi.com on Wed Jan 23 04:35:45 2002 (link)
Kjeld Jensen wrote:
> ... with the
>
> <fix>none</fix>
>
> If this (optional) element is found in the <wpt>, <trk> or <rte>
> element
> this means that all navigation related information is invalid...
>
> That includes lat and lon.
>
> I didn't think of this before but if we allow the "none" option it
> implies
> a rather complex evaluation of each record:
>
> 1. is there a <fix> element included?
> 2. is it "none"
> 3. if it is then we have to dischard all information...
>
> It would be much easier if all records inherently contains valid data.
>
> Based on this I recommend that we only allow <wpt>, <trk> and <rte>
> elements with a valid fix i.e. we do not allow the "none" option.
>
Then how do you specify waypoints created by point & click on a map?
--
I don't suffer from Insanity... | Linux User #237369
I enjoy every minute of it... |
|
http://www.travellingkiwi.com/ |
andrzej+chaeron.com on Wed Jan 23 06:41:34 2002 (link)
Kjeld said: > I see your point, but it is not that easy to overcome the size limitations > on handheld units. That does apply to the current crop of Palm devices, and your suggestion of using a compressed (non-XML) format for track storage is the way to go for the moment. However, Moore's law does appy to PDA's, and the next wave of Palm devices will likely be 32/64MB units (and more with SD or CF slots) running on 200mhz+ ARM processors. I believe that within a year or so, the extra storage will be a non-issue even on PDA's (mobile phone devices might still not be there though). The beauty of XML is it's portability and human-readability. I can see some users editing the XML directly to change/fix their waypoints. You don't want to sacrifice the strengths/benefits of XML due to a (short term) limitation of handheld devices. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
hamish+travellingkiwi.com on Wed Jan 23 07:41:27 2002 (link)
Kjeld Jensen wrote:
> >Then how do you specify waypoints created by point & click on a map?
>
> Well they are inherently valid and in my opinion such a waypoint
> specified
> aa <wpt></wpt> should not include any of the optional elements:
>
> <fix>
> <sat>
> <hdop>
> <vdop>
> <pdop>
Right. No problem. Thanks. I missed that... Sorry about that... Doh!!
(Hammer goes my head on the desk)...
--
I don't suffer from Insanity... | Linux User #237369
I enjoy every minute of it... |
|
http://www.travellingkiwi.com/ |
egroups+topografix.com on Wed Jan 23 10:47:40 2002 (link), replying to msg
Hello, I gathered up all the feedback on the 0.4 schema, and created a candidate 0.5. Take a look, and suggest any changes you'd like to see it in before we lock it down as the official 0.5 http://www.topografix.com/GPX/0/5 Changes made: added fix, sat, hdop, vdop, pdop to wpt, trkpt, rtept added src to trk, rte added fix enumerations bumped version number and namespace to 0.5 -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Jan 24 11:36:15 2002 (link), replying to msg
Hello, Wednesday, January 23, 2002, 3:33:58 PM, Kjeld wrote: KJ> You did not include the <course> and <speed> elements in the <trk> element. KJ> Regarding the <fix> we need to figure out a principle for validation of KJ> each record if we are to include the "none" option. KJ> lat and lon are required and for all other options of any element they hold KJ> a valid position. But when a <fix>none</fix> element is present this is not KJ> the case. KJ> Should we requre the lat/lon values to be set to "" then or should the KJ> import feature simply disregard the value? KJ> I vote for the exclusion of the "none" option as it complicates the format KJ> and it should be fairly easy for a programmer to avoid adding records for KJ> positions that are not valid . I've updated the 0.5 spec to include <course> and <speed> in <trkpt>. This <fix> discussion is bringing us back to one of our earliest debates, which was "how to represent a tracklog where GPS lock was lost between two points?" Fix isn't a good way to solve this, since at point A and at point B, the GPS has a good fix. However, between A and B the GPS lost the fix, and many GPS and mapping programs show this by not connecting the line segment between A and B. How can we express this in GPX? I proposed an element to describe the connecting segment (called <link> or <leg>). I still think that this is an important concept that's missing from GPX now. Any other ideas or suggestions? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Jan 24 13:36:59 2002 (link), replying to msg
Hello,
Thursday, January 24, 2002, 4:02:32 PM, Kjeld wrote:
KJ> I don't know how important this is, but since the elements must appear in
KJ> order, maybe we should consider structuring this a little?
KJ> It might be an idea to for instance define a structure like...
KJ> <trkpt>(or waypt or rtept)
KJ> navigation data retrieved from the gps (elevation, time, course, speed)
KJ> data precision info from the gps (fix, sat, hdop, vdop, pdop)
KJ> other info (name, cmt, desc, src, sym, type)
KJ> </trkpt>
KJ> It is not important to me which order the groups have, but I think we
KJ> should at least regroup them a little.
KJ> Comments?
I'm starting to get uneasy about the lack of structure, as well.
We're backing ourselves into a wall with the current rules:
1. all optional tags are attributes.
2. tags must be listed in order.
I like the idea of arranging all the navigation data together, but
what happens when we add a new navigation tag? It has to go at the
end to be compatible with the older schemas.
I'm also worried that we have no way to address Kjeld's earlier
question: what happens when the data in one tag (fix=none) means
that other tags aren't allowed to exist?
Maybe we should discuss turning some of these "groups of related
tags" into their own elements. Just an example:
<trkpt>
<position lat="42.1" lon="-71.2" ele="300.0" time="..."\>
<nav_info course="45" speed="20.4" cross_track_error="-345.0"\>
<precision fix="3d" sats="7" hdop="2.3" vdop="2.3"\>
<name>TRKPT3</name>
<src>Garmin eTrex</src>
</trkpt>
Thoughts? It might be helpful to start thinking about additional data
that might be included in future versions of GPX, and how those
concepts would be broken down into elements. Some ideas off the top
of my head:
NMEA or real-time positioning data (nav_info above)
how data should be displayed on a map (Dave's layers, my route color)
statistical data for waypoint averaging
map calibration data
Others?
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com
hamish+travellingkiwi.com on Thu Jan 24 15:45:11 2002 (link)
Dan Foster wrote:
> Hello,
>
> Thursday, January 24, 2002, 4:02:32 PM, Kjeld wrote:
>
> KJ> I don't know how important this is, but since the elements must
> appear in
> KJ> order, maybe we should consider structuring this a little?
>
> KJ> It might be an idea to for instance define a structure like...
>
> KJ> <trkpt>(or waypt or rtept)
> KJ> navigation data retrieved from the gps (elevation, time, course,
> speed)
> KJ> data precision info from the gps (fix, sat, hdop, vdop, pdop)
> KJ> other info (name, cmt, desc, src, sym, type)
> KJ> </trkpt>
>
> KJ> It is not important to me which order the groups have, but I think
> we
> KJ> should at least regroup them a little.
>
> KJ> Comments?
>
> I'm starting to get uneasy about the lack of structure, as well.
> We're backing ourselves into a wall with the current rules:
> 1. all optional tags are attributes.
> 2. tags must be listed in order.
>
Umm... I wondered about this... Why must all tags be in order? (Besides
that's the way the spec is written, is the a really really cool reason
I've overlooked?)
--
I don't suffer from Insanity... | Linux User #237369
I enjoy every minute of it... |
|
http://www.travellingkiwi.com/ |
davewissenbach+yahoo.com on Thu Jan 24 20:17:24 2002 (link), replying to msg
--- In gpsxml+y..., Hamish Marson <hamish+t...> wrote: > > > > I'm starting to get uneasy about the lack of structure, as well. > > We're backing ourselves into a wall with the current rules: > > 1. all optional tags are attributes. > > 2. tags must be listed in order. > > > > Umm... I wondered about this... Why must all tags be in order? (Besides > that's the way the spec is written, is the a really really cool reason > I've overlooked?) > The only reason for this is that the schema is easy to write. In my one bootleg version of the schema, 0.3, I made parameter groups, and it was difficult to do this without enforcing an order. However, there is a way out, which I have tested (and even published in this forum.) Now that we have a flat schema, we can wrap the entire content model of each element in a choice block, and allow multiple occurences of that choice. This construct prevents us from disallowing that an element occur more than once, while freeing us from the constraint that elements have to occur in a particular order! I'd recommend that all applications code to a rigid sequence that follows the schema but allow any order of elements when parsing. I believe that's what the topografix applications do, and that's what my application does.
davewissenbach+yahoo.com on Fri Jan 25 13:44:54 2002 (link)
I have updated my Boise area trail map web site to the 0.5 gpsxml standard. All of the maps reference the 0/5/gpx.xsd schema at the topografix web site, and sample output from Wissenbach Map 1.4 validated, so I assume that all of the maps on the site are valid. A copy of Wissenbach Map 1.4 is also downloadable from the map web site at the URL below: http://www.cableone.net/cdwissenbach
egroups+topografix.com on Fri Jan 25 16:40:34 2002 (link), replying to msg
Hello, Friday, January 25, 2002, 1:48:36 AM, Dave wrote: d> I have updated my Boise area trail map web site to the 0.5 gpsxml d> standard. All of the maps reference the 0/5/gpx.xsd schema at the d> topografix web site, and sample output from Wissenbach Map 1.4 d> validated, so I assume that all of the maps on the site are valid. A d> copy of Wissenbach Map 1.4 is also downloadable from the map web d> site at the URL below: d> http://www.cableone.net/cdwissenbach I found some errors in my XML parser after opening Dave's BoiseFront.gpx file. It's a good stress test - over half a megabyte of trails! Dave, I noticed that some of your waypoint symbols aren't being recognized by my software. I use the exact spelling of the symbol name as listed on the GPS, so there's a mismatch between some of your "compressed" names (WaypointDot, BoatRamp, FirstAid, etc) and my names (Waypoint, Boat Ramp, First Aid, etc). I actually found a few mistakes in my symbol list as I checked this. (I had one called Boat/Boat Ramp which is now just Boat Ramp.) -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Fri Jan 25 17:04:30 2002 (link), replying to msg
Hello, Friday, January 25, 2002, 4:21:35 AM, Kjeld wrote: >> 2. tags must be listed in order. KJ> 2. I suppose that's because of the schema as dave said, but why is this a KJ> limitation. KJ> Suppose an application supports GPX 1.0 (structured as in the current 0.5) KJ> and you create a lot of GPX files with it. Then you upgrade to GPX 1.1 KJ> which contains more elements inserted at different places. The new GPX 1.1 KJ> will be able to read the 1.0 files without any problems as the elements are KJ> optional and the old files just don't contain any of them. KJ> So I can't follow you when you say that the order is a problem and that KJ> this prevents us from regrouping the elements now as I suggested? Suppose I write my app to import GPX 1.0 files, and I strictly enforce the order that is specified in the schema, but allow unknown element at the end of each element (like the schema currently permits). You upgrade your app to write GPX 1.1 files, which have a new element inserted between two of the old 1.0 elements. You send this GPX file to my 1.0 app. It won't work. Old 1.0 files would validate against the 1.1 schema, but 1.1 files wouldn't validate against the 1.0 schema. We should be able to specify things so that new files can be validated against the old schema. [As Dave points out in an earlier email, most of us aren't enforcing the order when we parse documents, so this isn't much of an issue in practice...] -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
andrzej+chaeron.com on Mon Jan 28 18:58:54 2002 (link)
Hi all: I decided to post an early release of the GPSml XMLSchema for GPS information to allow some feedback. GPSml V0.5 is now up at http://www.chaeron.com/gps The design goals for GPSml are: - Be an XML format for all GPS-generated data, both real-time position related data and collections (such as waypoints, tracks, routes) - Be easy to generate in software, even apps without XML understanding. = Be easy for modern XML parsers to parse and feed in to applications. - Let a single file contain real-time position information and arbitrary collections (such as waypoints, tracks, routes) - Scale gracefully to handle both simple and complex requirements - Be flexible and extensible since the GPS arena is evolving rapidly - Follow current XMLSchema best practices (where known) The distribution contains a detailed readme file, XMLSpy generated documentation and the full GPSml schema. Be sure to read the Design Notes in the readme and keep in mind that this is a very early draft and so is a bit rough around the edges and not complete yet. Any/all feedback is much appreciated. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
andrzej+chaeron.com on Mon Jan 28 19:21:46 2002 (link)
The correct URL for GPSml V0.5 (and the Java GPS Access Library V 0.96 beta) is http://www.chaeron.com/gps.html Sorry! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
davewissenbach+yahoo.com on Tue Jan 29 05:43:24 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > > I found some errors in my XML parser after opening Dave's > BoiseFront.gpx file. It's a good stress test - over half a megabyte > of trails! > > Dave, I noticed that some of your waypoint symbols aren't being > recognized by my software. I use the exact spelling of the symbol > name as listed on the GPS, so there's a mismatch between some of your > "compressed" names (WaypointDot, BoatRamp, FirstAid, etc) and my names > (Waypoint, Boat Ramp, First Aid, etc). I actually found a few > mistakes in my symbol list as I checked this. (I had one called > Boat/Boat Ramp which is now just Boat Ramp.) > The next version of Wissenbach Map will match the symbols used by ExpertGPS (I've tested this already). When I publish Wissenbach Map 1.5 and update the web site I'll also update the samples to use the new symbol names. Right now my ftp connection is down, so this will have to wait. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
andrzej+chaeron.com on Wed Jan 30 08:20:42 2002 (link)
Kjeld Jensen wrote: > First of all I am a little surprised to see your posting here. This > mailing list was created to support the development of a generic GPS > position exchange format which yours is not. GPSml can encode all of the data that GPX allows (or will very shortly if something is missing) but also allows a lot more GPS-related data to be encoded. You can add arbitrary tags (in the <other/> blocks) so that applications developers can extend their data output/input capabilities without breaking other programs use of the main data. Much more detail is also allowed for waypoints and such, but most of these tags are optional, so an application program is free to ignore the tags it is not interested in, just as a program need only specify a very small number of mandatory tags (which are very few in number). GPSml also allows for inclusion of real-time position information. So from this perspective, GPSml is a superset (sematically) of GPX and provides a much higher degree of flexibility and extensibility (a stated goal of GPSml). Why are you surprised? I posted the notice here because GPSml might be of interest to the group. Because I promised Dan Foster that I would. Because the techniques used in the GPSml schema (based on current industry best practices) might help improve GPX. Because you might find that GPX does not meet future requirements and a more flexible/extensible markup dialect is required. These all sound like good reasons to post here. > Your format apparantly supports all data that one may retrieve from a GPS > receiver. This is, however, not that relevant for the exchange of data > between several applications/databases. That is correct. In the documentation that comes with GPSml I specifically state: "GPSml is a markup language (and XMLSchema) that meets a growing requirement for a standard way of sharing GPS (Global Position System) location information between disparate systems, devices and users." and... "Be an XML format for all GPS-generated data, both real-time position related data and collections (such as waypoints, tracks, routes)" GPSml would allow you to share what you currently share, plus allow for distribution of location information as well. Again as the docs state: "For example, to transmit location data from a GPS-enabled client application (possibly running on a handheld device) to a central server running location- aware Web Services." Which is something that GPX cannot do, but there is a growing interest in and need for (In fact, I am building an application that does just that in conjunction with some hardware vendors). The intention of GPSml is also to be comprehensive and flexible enough to allow various GPS hardware manufacturers, major mapping application developers, GIS users (eg. City Urban planners), etc. to all be able to use a common markup to handle position information and exchange this information across many disparate applications. > For exchange of information you need to focus on the applications that the > data information be used for rather than the information itself. This is > why the GPX format is superior to GPSml. I disagree with this statement as it binds your thinking into a very small and narrow world definited by a single or a few applications. That is not always a bad thing, when a number of application developers/vendors band together to facilitate data sharing. But it does eventually limit the ability to add new vendors to the mix....or to use or extend the data in novel ways that the initial applications did not consider. On of XML's strengths is to decouple information encoding from the often parochial interests of application programs, and this theme continues even more strongly with XMLSchemas. Quoting from an XMLSchema Best Practices document: "Too often schemas are designed in a static, fixed, rigid fashion. Everything is hardcoded when the schema is designed. There is no variability. This is not reflective of nature [or the real world...ajt]. Nature constantly changes and evolves. Nothing is fixed. As a general rule of thumb: more dynamic capability = better schema.....Definition of Dynamic: the ability of a shcema to change at run-time (ie. schema validation time). Contrast this with rigid, fixed, static schemas where everything is predetermined and unchanging". GPX is already beginning to suffer from this approach. Handling of track segments has been recently discussed here, but the solutions proposed are tending towards a rigid approach that is being "hacked" on top of GPX. There is no over-arching information-design paradigm that allows such things to be easily incorporated in GPX without breaking existing programs. There has also been talk of adding real-time GPS data support. Again, it looks like it will be grafted onto the existing GPX schema....and eventually you may end up with a mess on your hands. By spending more time up front on structure, extensibility and design issues, GPSml is trying to avoid this trap. The whole world of GPS/Position-enabled systems is evolving extremely rapidly right now. I do not presume to know where it will end up, so it seems prudent to me to design schemas in this domain to take this rate of change into account. Furthermore, GPSml is trying to address a much larger, more dynamic and difficult requirement that might have the potential to unite the whole marketplace, not just facilitate waypoint exchange (which is a much smaller and easier problem to handle). > I also find your GPSml format quite complex and cumbersome as you support > writing the same data in different ways, which makes it unnecessary > complex and hence difficult to implement for developers Unfortunately, with flexibility and extensibility does come some level of increased complexity. I believe (for reasons stated above) that this tradeoff is worth it. But that is just my NSHO. I'm not sure what you are referring to when you state "writing the same data in different ways". Yes, you can write lat/longs or distances with different units of measure (degrees, radians, feet, meters). But that provides a lot more flexibility to interface with existing systems (like GIS applications for example) and makes it a lot easier to output valid XML. Yes, this does make importing the data a bit more effort. However, I believe that we will eventually see packaged components/libraries that do this for you automatically (a good case in point is my own open source java-based GPS Access Library). So a developer will not have to do their own parsing of GPSml....but will use a much higher level API that gives them the benefit of the flexibility/extensibility and a wider range of applications they can "talk" to with less work. It is also possible to use a subset of GPSml, by convention/agreement, by layering a restricting schema on top of GPSml (to eliminate the formats you don't wish to support), or by writing a XSLT transform that will convert a more flexible/generic format into a more specific one your application wants. Many ways to skin that cat. Also keep in mind that I clearly stated that this release of GPSml is a "rough cut" first draft. As it evolves, redundancies will be eliminated where it makes sense to do so. It is by no means perfect or even close to it. I am VERY open to suggestions as to how it could be improved (I did notice you did not offer any such suggestions and you also stuck to very general statements that you have not chosen to back up with concrete examples). > difficult for the applications which runs on low capacity platforms like > the Palm. Again, the GPSml docs make my position on this quite clear...to whit: "XML is a "verbose" format regardless. If you want the ultimate in small filesizes then use a proprietary binary storage format instead. It is debatable, even with short forms for tag names and maximal use of attributes, if XML is currently suitable for devices with limited resources, such as mobile phones, Palm PDA's, though Moore's law will probably make GPSml practical at the small device level sooner rather than later." The rate of evolution of small devices might make your design decisions obsolete within a year. GPSml is being designed to have a long life span, taking account this technological rate of change and increase in capability. In fact, I would suggest that if you don't want to use a binary format on a small devices, that you create an extremely stripped down and cryptic schema for such devices and supply an XSLT transform to "inflate" the data into a more flexible/readable form on larger platforms. BTW....my GPS access library code runs on palms and even smaller devices. Howerver, I do not recommend that users use the XML features on such platforms at this time. > In my opinion your work clearly shows that this is a product of one man's > (or company's) idea, rather than the product of a co-operation between > several developers which needs and ideas covers a much broader area of > applications. You must pardon me, Kjeld, if this statement of yours made me laugh (which it did). GPSml handles everything that GPX can currently do plus is designed for much broader applicability, extensibility and flexibility. Your definition of "broader" is amusing indeed. As for one man versus design by committee, I have a lot of thoughts on that, which will probably make you upset. That is not my intention. However, since you brought it up: Design by committee is too slow (GPX suffers from this syndrome). And a committee process rarely comes up with a "great" design (though it may be adequate). Better to have a much smaller group (possible only one or two people, if they have the right skill sets) design the core, and make it simple, extensible, based on best practices and comprehensive enough so that a proper foundation is laid for future evolution. GPX does not seem to have a solid enough foundation to accomplish this, in the context of the larger problem space that GPSml is attempting to address (and which GPX is not by your own admissions). > My conclusion is that you have probably created a good standard for > storing GPS generic data, but it is not suitable for exchange of > waypoint/track/route information between different applications. Here the > GPX format does a much better job. You have not provided any conclusive reasons nor backup information to warrant such a conclusion and in fact, I believe I have refuted most of your generalisms earlier in this email. Furthermore, "better" is a subjective label....better in what way and why? I'm sure that the other readers of this forum would very much appreciate elaboration as to why and for what reasons you think GPX is "better"...in detail. I'll kick this off by noting some of my observations about GPX: 1) The tags are too cryptic and short in GPX. One of the key benefits of XML is human readability. This is compromised by the choice of short forms for tags (eg. lat instead of latitude, though that is probably one of the poorer examples). You could argue that handhelds are too memory constrained to allow for more natural and descriptive terms, but I believe that Moore's law and rapid increasing handheld capability will make this a moot point very quickly, and so to maximize future capability and readability, I think longer tags make more sense. 2) The GPX schema design is rather simplistic and does not follow current best practices. GPSml adheres to current best practices in schema design, yet provides for simple markup syntax for instance documents. 3) The GPX schema is not currently designed to be extensible and flexible, which will limit it's ability to evolve and encompass new location-based semantics (which is a growing market and interest area on the part of many vendors). 4) Some design choices are not very ideal from an information architecture perspective (eg. lat/long as attributes instead of sub-elements). These choices will cause some problems in the future as new requirements need to be adopted. 5) I don't believe the GPX group has a very indepth knowledge of XML technologies (especially schema design issues). It seems more a group of hobbyists to me. That is not a bad thing in and of itself....just incompatible with and unlikely to produce what I think the market needs/wants/will accept. All of the above are just MNSHO's.....so don't get your nose out of joint about it. I just wanted to make my thoughts on the whole subject (and GPX) clear. > I have therefore no plans of supporting your proposed GPSml format. <with tongue firmly planted in cheek> I do not recall asking you to, Kjeld. Many of your comments strike me as stemming from a childish "it's my toy and how dare you criticize it or try to invade my sandbox" view. Then again, I might be reading something into your post that is not there, and if that is the case, my apologies. </with tongue firmly planted in cheek> GPSml is still in a rough state. I have released this early version to solicit comments/feedback that might make a closer fit to it's stated goals (and maybe improve other such efforts in the process). It may just be the "bootstrap" the industry needs to define the "real" standard for future position data exchange. Or it might help improve GPX. I have no problem with that. I believe that users/developers benefit from having, and understanding many different alternatives, so they can make an educated choice about what tools/standards/schemas they should use for the task that faces them. Life and such decisions are about compromise. For specific requirements, GPX may well be more suitable than GPSml. But how can a developer determine that if they don't know the design foundations, the directions, and the tradeoffs that are inherent in any specific solution? Anyway, to conclude, I believe that a dialog on this issue will result in benefits to all constituencies (you, me, GPX, GPSml and the position-enabled application space in general) which is why I have taken the time to reply in some length and detail. If GPX evolves into a flexible, comprehensive shema for position-information then great. If it stays as a simple/lightweight waypoint transfer protocol (which is not necessarily a bad thing...simplicity has it's virtues) then great. If the GPSml becomes a standard then great. If both are supported then great (hopefully with XSLT's for easy conversions back and forth). If the industry comes up with some other standard for position-info exchange then great. GPS and position-enabled technology and applications are so nascent and evolving so fast that no-one can forsee where the space will end up. However, if GPX and/or GPSml can help address some of these evolving requirements and "show the way" for whatever comes then it will have been worth the effort. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
andrzej+chaeron.com on Wed Jan 30 08:28:56 2002 (link)
....for those that have been curious and have visited the GPSml web page (http://www.chaeron.com/gps.html), you might have noticed that I do have a link there to GPX. Also links to other Schemas that are related (eg. GIS, NVML, etc.). I believe that it is beneficial for users/developers to see all the alternatives, regardless of their final choice, and putting my money where my mouth is, I included links to "competing" and "related" schemas as a convenience to people looking for such beasties. I wonder if the "official custodians of GPX" will respond in kind? The answer to that question will be rather illuminating regardless of what it is, n'est-ce pas? <grins> Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
andrzej+chaeron.com on Thu Jan 31 18:59:52 2002 (link)
Kjeld said: > Based on your work I have no doubt that you know much about XML, and GPX > could probably benefit a lot from your insight. But apparantly you have no > interest in contributing to the ideas behind GPX, as you rather want to > create a "competing" standard. I have put GPSml into the public domain...doing so could easily contribute to the ideas that GPX incorporates, since you are free to copy and use any part or idea of GPSml. As I told Dan, I think that GPX does not have a solid enough foundation (design, flexibility or extensibility) to make it worth building on top of. You have not said anything as to why you think GPX is a better "foundation". GPSml is designed and intended to handle a much broader range of data sharing requirements and a larger target "market" than GPX, so it does not really compete. > Competing standards are not what the world of GPS enabled applications > (hereby I mean databases, programs for different platforms and so on) needs > by now. There are already plenty of them and yet you propose another > standard well knowing that other people already work on this across the > world. I don't know of any other GPS-targetted markup languages other than GPSml and GPX. That is precious little competition for what bodes to be a huge market. GPX has taken a fair amount of time and has produced very little so far...so it's not like there is much of a legacy to worry about. > I can't say that I disagree with you when reagarding the slow progres of > the GPX definition. I takes a long time and I have several times asked if > we could speed this up by releasing a simple version, so we could get som > practical experience. Bingo! I do not see GPX development going any faster any time soon. Another good reason to support a more comprehensive, flexible, extensible standard that is evolving really fast. > But instead of publishing "your" idea you could have suggested to > contribute to the development of the GPX work Why? That would take too much time and effort and has a poor chance of succeeding, given the weak foundation and difficulties of "design by committee". . I for one would be willing > to adopt many ideas from one with a high level of XML experience. But it > seems to me that you are not interested in this because the GPX is not your > idea. Whether GPX is my idea or not is not at issue. I could care less. I said as much in my last post. Offering GPSml, it's design ideas and the schema itself to the public domain, easily contributes to GPX if others want it to. I have never said that I will not participate in the GPX discussion. Maybe knowing that there is some strong competition around the corner might help GPX by lighting a fire under the groups collective butts (though from the lack of response from anyone but yourself, I would not hold my breath about this if I were you). Your comments make too many assumptions about my intentions, and are rather arrogant and insulting on your part. > And this seems very unprofessional to me. A while ago I myself suggested > the definition of a common exchange format on the sci.geo.satellite-nav. > When I learned that Dan Foster was alreay some steps ahead of me I > immediately teamed up and since that I have put into this forum what I feel > that I could contribute with. And your point is? I looked at GPX very closely....even considered making GPSml an "extension" of GPX. But I found it to be lacking some fundamentals and believe it would not be a good foundation for the intent behind GPSml. I am participating in this forum (and if anyone else steps in with questions/comments about GPX or GPSml I shall be happy to participate if I have anything valuable to add). What is unprofessional about that? Why should I bow to what I feel is an inferior design, with slower progress and other problems? It's not like GPX is a world standard or even close to it. My considered judgement was that it was not worth it. Evaluate all the alternatives (which I did), see if you can avoid "re-inventing the wheel" (which I did), make sure you have your goals and targets clear (which I did), and then make a decision and run with it (which I also did). That, I would submit, is the mark of a "true" professional. > You refer to us as hobbyists even though you don't know anything about us. I said "It seems more a group of hobbyists to me". Just like you said I "seem unprofessional". These are opinions, and nothing has been said to change mine as of yet. There is nothing wrong with hobbyists. I just don't think that a group of "hobbyists" will be able to create a global industry GPS data exchange standard, which is the intent behind GPSml. That may be the intent behind GPX, but the progress has been rather less than inspiring. > One thing I have learned over the years is that data integrity and format > simplicty goes above almost all other requirements. True....but real world applications typically come with complexity. Being too simplistic about requirements is also not a good thing. > Being able to express the same generic data in several formats is > definitely not a good idea, as it interently leads to complexity and hence > probable errors. Naturally there are good arguments for the use, but they > all fall apart when software bugs start to emerge... I disagree. There is good reason for having different units of measure available to applications. This was a feature added to GPSml after much thought and deliberation. You will notice that the defaults have been implemented in such a way to make the most common cases easy. The format is also quite simple in that regard. Writing a XSLT transform that converts a GPSml-compliant instance document to a "common" uom would be a rather simple matter, and would handle the situation of applications that can only handle the "simple" case. Data integrity is another issue all together and is not compromised by adding flexibility. > There is no doubt to me that using decimal degrees referred to WGS-84 and > Syst? International d'Unit?(SI) unuts for lenght, time and deriative > units are the best way to ensure integrity and simplicty. There are many situations where this is NOT the case. Many GIS and mapping programs do not use WGS-84. Many Urban Planners that I have spoken to want more flexibilty in co-ordinate specification and conversions. On smaller devices, it is also less processing and code to write out data in a native format/uom, and let other more powerful machines (servers, pc's etc) or translation processes (XSLT, et al) do conversion to whatever units they require and can accept. > Also simplicity is an inherent property which all platform would benefit > from. Even though it almost seems that the computing and storage capacity > tends to infinity as time goes, it does not mean that creating a complex > structure is better than a simpler structure with the same generic > properties. It depends on what problem space you are trying to tackle and your definition of simplicity. The instance document format for GPSml is quite simple and easy to understand (it is also more consistent in it's use of elements vs. attributes than GPX). Sure the schema is complex....but that is transparent to most programmers and users so it does not matter. > The most obvious problem is the ties I see between your > company and the GPSml format. Since GPSml has been put into the public domain for people to do as they like with, your argument does not make sense. > The second most obvious problem with GPSml is > the unnecessary complexity due to the allowance of different formats of the > same generic data. We shall have to disagree on this point. I see this as a valuable feature (which is also optional as noted above) based on my industry contacts and knowledge. > I hope this clears up some of your questions. If you continue this debate > using expressions like in the previous email we have nothing further to > discuss. You mean like accusing me of not being professional? Try getting a sense of humour, Kjeld and lightening up a bit. This stuff is not life and death nor even a way of making a living for most of us. It is supposed to be fun. Life is too short for it not to be. > If you agree that joining forces into defining one common standard would be > better than two different competing standards, then maybe this could be a > platform to start at. You might be well served to take your own advice and thus look forward to your assistance with GPSml. <grins> > But you have to realize that this also means that you > have to listen to ideas and arguments and accept compromises just like the > rest of os have been doing for some time now. I have been listening.....but have not yet heard anything that leads me to believe that my approach is wrong (again given the larger scope that GPSml is trying to address). As for compromises, sometimes they lead to inferior solutions, which is something I am not willing to put my name and reputation to. > I for one have no problem tearing the current GPX format apart if it would > result in a more flexible and extensible format based on best practice as > you mention. But simplicity *is* an important issue - and so is time. Life is rarely that simple. GPSml is designed so that developers can use just the parts of it that make sense for them. What could be more simple than that? But it can also encompass much more complex problems, which are already surfacing in the GPS world. > If you would rather continue your work on GPSml by yourself I specifically asked for ideas and feeback and I am happy to debate the directions and constructs in GPSml and evolve it to suit real requirements. That is not exaclty "working by myself". You might also keep in mind that the most successful open source projects around (Linux, Apache, etc.) all have a very experienced "gatekeeper" that has final say over what goes in or out of the release. Design by committee and pure compromise never works, in my experience. Someone has to be the final arbiter of the product. > then I cannot > see why this discussion should continue on this mailing list. Because maybe GPX can benefit from the work I am doing on the public domain GPSml? I> As stated before I will not support your work on GPSml and to be frankly I > don't think you will get much response as many developers will see this as > "just another format created by a single company". Kjeld....your unsubstatiated opinions grow tiresome. What part of "IT'S IN THE PUBLIC DOMAIN" don't you understand? > I know it is only three > days ago that you posted the same info on sci.geo.satellite-nav. But the > response so far aren't exactly overwhelming at least not in the usenet > group. I posted there as a courtesy to the few people that are interested in such things. Most posters on that group seem to be consumers that want to know what GPS to buy....where to find a cable....and the like. I did not expect much response from that forum. I have received a lot of private interest however. > But I would certainly support you if you decide to team up with the > rest of us under the conditions listed below. Your implied conditions are unacceptable. I intend to continue to work on GPSml. If I have something to offer GPX discussion I will do that as well. If GPX comes up with some interesting ideas, I will happily incorporate them in GPSml. > Adding your XML experience to > the idea of a generic standard free from individual interest would be an > advantage. GPX is NOT a generic standard at this time, and with it's current base and slow speed of development is likely never to be. It is, by your own words, intended as a way to share waypoint, route and track data. GPSml is intended to be a comprehensive standard for all forms of GPS data. > Please notice that these comments states my personal opinion only. There > are currently 42 subscribers to the mailing list... And it would be nice to hear from some of them. ;-) > Guiding principles: > - A common XML data format for the exchange of GPS and > location-based information between computers benefits everyone. It is > in our interests and the interests of our users to create a common > data exchange standard. Exactly the purpose of GPSml, except that I believe GPSml has a better chance of getting there in a reasonable period of time than GPX and has more likelyhood of evolving gracefully over an extended time without breaking prior applications that use it. > - This is an open standard. It is controlled by no one person, and > it is free from copyright and other legal meddling. As is GPSml. > - This is a data exchange format, not a data storage format. GPSml and GPX could be used for both. Though the primary purpose for both is exchange and not storage. What's your point? > Applications are free to implement as much of the format as needed, > and ignore parts of the data stream. The only requirement is that an > application must be able to parse an arbitrary data stream without > crashing. Sounds like GPSml to me. ;-) > - This format allows for expansion. Private elements and attributes > can be added to the format. To the extent possible, we will work > together to define public structures that multiple applications can > use, but any developer is free to add their own private data > structures to any public element. Which will break validating parsers the way GPX is evolving. GPSml is designed already to allow such expansion almost anywhere, while still allowing for full schema validation. Shall we discuss your vaunted data integrity in this light? ;-) > - This standard is of no use unless people use it. To that end, it > should be lightweight, easy to implement, and flexible enough to > accommodate new features as it matures. Preaching to the converted are we? > - This format is about data exchange, not data validation. Just a while back you were talking about data integrity. That is a key role of data validation. When you do validation is debatable (compile time or runtime) though, especially on limited devices. Are you now saying that data integrity is not required? ;-) > Device-specific details like the number of characters in a waypoint > name do not belong in the exchange format, they belong in the > end applications. No argument there. But the "format" should be flexible enough to handle a wide variety of application requirements. In any case, I am not finding this discussion very productive. I will not be responding to any more such emails in public. If you want to continue this discussion, Kjeld, then feel free to email me privately. If you wish to discuss technical issues of GPX or GPSml, how they might compare in various implementation details, or how to best to implement a specific feature/requirement, I shall continue to respond to such here, since it might be of interest to others on the group. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
egroups+topografix.com on Fri Feb 01 08:20:59 2002 (link), replying to msg
Hello, As best I can tell, there are five things yet to do before we finalize GPX 1.0: 1. rearrange the order of elements (Kjeld's proposal). 2. write a user document (my job). 3. agree on any last-minute element additions (see below). 4. make any structural changes to the schema. 5. agree we're done, and freeze the 1.0 spec. My contributions: 2. I'll write the user document next week. 3. I'd like to see the following elements added to the spec: <number> - integer - valid for <rte>, <trk> - Many GPS models identify routes and tracks by number instead of name. <number>5</number> <url> - text string - valid for all elements - specifies a URL associated with the object. <url>http://www.trail.com/traildesc.html</url>, e.g. <url_name> - text string - valid for all elements - specifies the text for a URL associated with the object. <url_name>Link to Trail Description</url_name>, e.g. The other tasks: 1. Kjeld, do you want to propose a new order for the elements? 4. Anyone? 5. I'm as anxious to wrap this up as everyone else. My apps are about 2 weeks away from the next release, so I hope we can get this finalized soon. Is there anything I've missed that needs to be done before we can release a 1.0 version of GPX? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Fri Feb 01 09:16:04 2002 (link), replying to msg
Hello, Friday, February 01, 2002, 11:51:30 AM, Kjeld wrote: KJ> <urlname> would be fine with me Fine with me too. KJ> I have looked at the NMEA data and there are a few others which we might as KJ> well include as optional elements. I see no reason to leave anything out KJ> which is a part of the most used NMEA sentences RMC, GGA, GSA. That would KJ> be: KJ> <mag> magnetic variation in degrees KJ> <geoidheight> Height of geoid (mean sea level) above WGS84 ellipsoid KJ> <dgpsupdate> time in seconds since last DGPS update KJ> <dgpsid> DGPS station ID number KJ> And then we can state that GPX supports these three sentences. Without disrupting the work on GPX 1.0, I'd like to spin off a new discussion topic about the syntax for real-time positioning information and NMEA. >>The other tasks: >> 1. Kjeld, do you want to propose a new order for the elements? KJ> Well yes, I just want to propose that we group them. The order within the KJ> group is not that important I think. If we use the three groups Position, KJ> Accuracy and Information we would get this for the track element: KJ> Position related data KJ> <xsd:element name="ele" type="xsd:decimal" minOccurs="0"/> KJ> <xsd:element name="time" type="xsd:dateTime" minOccurs="0"/> KJ> <xsd:element name="course" type="gpx:degreesType" minOccurs="0"/> KJ> <xsd:element name="speed" type="xsd:decimal" minOccurs="0"/> KJ> <mag> KJ> <geoidheight> KJ> Accuracy related KJ> <xsd:element name="fix" type="gpx:fixType" minOccurs="0"/> KJ> <xsd:element name="sat" type="xsd:nonNegativeInteger" minOccurs="0"/> KJ> <xsd:element name="hdop" type="xsd:decimal" minOccurs="0"/> KJ> <xsd:element name="vdop" type="xsd:decimal" minOccurs="0"/> KJ> <xsd:element name="pdop" type="xsd:decimal" minOccurs="0"/> KJ> <dgpsupdate> KJ> <dgpsid> KJ> Information related KJ> <xsd:element name="name" type="xsd:string" minOccurs="0"/> KJ> <number> KJ> <xsd:element name="desc" type="xsd:string" minOccurs="0"/> KJ> <xsd:element name="cmt" type="xsd:string" minOccurs="0"/> KJ> <xsd:element name="src" type="xsd:string" minOccurs="0"/> KJ> <xsd:element name="sym" type="xsd:string" minOccurs="0"/> KJ> <xsd:element name="type" type="xsd:string" minOccurs="0"/> KJ> <url> KJ> <urlname> Thanks. KJ> We still have the problem with fix = "none". Take another look at the GPGGA sentance - it allows fix=none, so if we're going to mirror NMEA for real-time positioning, we need something like this, outside of tracklogs. KJ> Should we disallow this option KJ> and instead go for the KJ> <trkbkn><cause>nofix</cause><time>datetimetype</time></trkbkn> This only makes sense for tracklogs. KJ> Any other ideas? KJ> Second we are starting to get problems with the tag names. I noticed that KJ> Andrzej format is more readable and I think we should consider copying the KJ> the use of capital letters where appropriate like for instance: <URLname>, KJ> <Fix>, <Time>, <GeoidHeight>, <DGPSId>, <DgpsUpdate>, <HDOP> and so on. Any KJ> comments on this? I see at least three different capitalization schemes in your examples! I prefer capitalizing the first letter of every word, and all letters in acronyms: URLName Fix Time GeoidHeight DGPSID DGPSUpdate HDOP I also like all lowercase, with_underscores_between words. url_name fix time geoid_height dgps_id dgps_update hdop -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Fri Feb 01 09:51:04 2002 (link), replying to msg
Hello, Friday, February 01, 2002, 12:25:10 PM, we wrote: KJ> Hi >>Without disrupting the work on GPX 1.0, I'd like to spin off a new >>discussion topic about the syntax for real-time positioning >>information and NMEA. KJ> I agree but should I take this as you do not think we should implement KJ> those optional elements also? No, I don't have any problem with basic navigation elements like those in GPX 1.0. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Fri Feb 01 09:51:04 2002 (link), replying to msg
Hello, Friday, February 01, 2002, 12:25:10 PM, Kjeld wrote: >>Take another look at the GPGGA sentance - it allows fix=none, so if >>we're going to mirror NMEA for real-time positioning, we need >>something like this, outside of tracklogs. KJ> You are right... but the problem is that we use attributes for the lat/lon KJ> and naturally they become invalid. We could actually solve the problem by KJ> allowing "none" and omitting the use of attributes in GPX (let <lat></lon> KJ> simply be elements instead). This way it makes sense in all three cases I KJ> suppose (a track entry without position corresponds to your earlier KJ> link/leg idea or my trkbkn idea) [this applies to all <pt> elements...] I think it's perfectly reasonable to have a lat/lon point even though fix=none. All my GPS act this way, and NMEA does too. When the GPS doesn't have a fix, it outputs the last known point. Some systems do a "dead reckoning" solution by maintaining the current speed/heading. Since you know that fix=none, you can treat the data as suspect. Most systems flash the display to indicate a loss of GPS lock. I'd prefer the following: lat/lon are always required. You're welcome to set them to zero if you like. when fix=none, behavior is application dependent. [now back to the problem of breaks in tracklogs...] fix=none isn't the right thing to do here. As an example, take the [extremely short] trip from A to B to C to D, with automatic track point recording every 5 minutes. There's a tunnel between B and C. I get valid fixes at A, B, C, and D, so fix=none never occurs. But the track is discontinuous between B and C due to the tunnel. How you you represent this in GPX? I like the concept of a track segment in GPSml. So... <Trk> <TrkSegment> <Trkpt A> <Trkpt B> </TrkSegment> <TrkSegment> <Trkpt C> <Trkpt D> </TrkSegment> </Trk> Other solutions? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Fri Feb 01 10:11:03 2002 (link), replying to msg
Hello, I'd like to start a general discussion about representing real-time positioning and navigation info in XML. There are some interesting issues that don't have anything to do with GPX or GPSml, but might have bearing on our future development. I'd love to be able to sit at work and watch somebody with a wireless Internet connection out mapping trails and sending back an XML stream of GPS data! Better yet, I'd volunteer to collect the data while you all sit at work! Existing applications: Does anyone know of a service or website that is currently offering real-time navigation info over a public web connection? DGPS corrections? APRS? hurricane tracks? others? Here's one example (not XML): http://208.139.198.171/AVLDemo/ (tracking the bus in Boulder, CO) Real-time considerations: Data needs to be organized intelligently so that it arrives quickly. As an example of a bad way to do things, you could decide to group everything together by common timestamp, but then you wouldn't send an XML packet until a new timestamp showed up in your source NMEA stream, which would introduce a time delay. Backwards compatibility with NMEA: It seems like a good goal that any XML stream should be able to be transformed into a valid NMEA stream using XSL. Streaming: So how do you stream XML, anyway? It's not valid XML until that final tag closes... -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Fri Feb 01 13:19:23 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > As best I can tell, there are five things yet to do before we finalize > GPX 1.0: > 1. rearrange the order of elements (Kjeld's proposal). > 2. write a user document (my job). > 3. agree on any last-minute element additions (see below). I have a last-minute addition to propose, related to trail publishing. If we add <name> <src> (or author) and <desc> as top- level elements in the root element, then the gpx file will be self- describing. The way I would use these elements is to extract the description as the opening paragraph in an html document which describes the trail. I have already written and tested a style sheet which extracts this data from tracks, routes, waypoints, and routepoints, and produces an html document which describes the trail. (I'd probably create a dialog box in the Mapping program to also display this data, although that isn't really necessary, as the information can just as easily be manually inserted into the GPX file with a text editor.) The style sheet could be applied to the .gpx file on the server with a style sheet processor. (I'm using apache xalan right now, and tested this with data on my web site.) The proposed new elements at the top level would then tranform into the html title, primary heading/map name, and introductory paragraph. The sample style sheet (not including the transformation for the proposed new elements but for all of the other top level elements) is at http://www.cableone.net/cdwissenbach/GPXContents.xsl Other than that proposal, my approach to the rest of the changes here will be to follow as quickly as I can with a compatible application. GPX should be ready for the next backpacking season! I prefer TitleCase to title_case, by the way. > 4. make any structural changes to the schema. > 5. agree we're done, and freeze the 1.0 spec. > ... > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
egroups+topografix.com on Fri Feb 01 13:48:45 2002 (link), replying to msg
Hello, Friday, February 01, 2002, 4:19:16 PM, Dave wrote: d> I have a last-minute addition to propose, related to trail d> publishing. If we add <name> <src> (or author) and <desc> as top- d> level elements in the root element, then the gpx file will be self- d> describing. The way I would use these elements is to extract the d> description as the opening paragraph in an html document which d> describes the trail. I'd like to see the following (optional) in the top-level <gpx>: <Name> Descriptive name of File <Desc> File description <Author> File author name <Email> File Author email <URL> File URL <Creator> File Creator Program <Time> File Creation Timestamp <Keywords> File keywords <BoundsLatMin> Extents of the data in the file <BoundsLatMax> (these should probably be a complex struct) <BoundsLonMin> ... <BoundsLonMax> Picture an app that can search a central database for all GPX files describing mountain bike rides within 20 miles of Boise! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Fri Feb 01 15:14:51 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > > I'd like to see the following (optional) in the top-level <gpx>: > <Name> Descriptive name of File > <Desc> File description > <Author> File author name > <Email> File Author email > <URL> File URL > <Creator> File Creator Program > <Time> File Creation Timestamp > <Keywords> File keywords > <BoundsLatMin> Extents of the data in the file > <BoundsLatMax> (these should probably be a complex struct) > <BoundsLonMin> ... > <BoundsLonMax> > Thanks for accepting this idea. I look forward to seeing it in the next revision of the schema. (GPX format 1.0?). > Picture an app that can search a central database for all GPX files > describing mountain bike rides within 20 miles of Boise! > That won't be easy! I've only logged about a quarter of the trail miles near Boise on my GPS. Tomorrow I'll go log a ski trail up North at Ponderosa State Park in McCall. By the way, I'm still gainfully employed and working on Wissenbach Map just as a hobby. I'm home today because of equipment problems at my workplace! > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
kevin+synergysa.com.au on Fri Feb 01 17:34:20 2002 (link), replying to msg
Hi All Thought I'd jump back in at this stage (just got out of hospital). I have been reading some of the many emails for the group since I was last infront of the PC. One really quick first. Somehow Capitalisation has crept in again for tags. Trust me, we DON'T want this is the long term, as most parsers and translators are case-sensitive, its important that the consumer knows what each element is called and hows its spelt and the case used. After quite some time developing enterprise solutions using SOAP and XML most of my "bugs" seem to be in stupid things like typing "HundredOf" instead of "Hundredof" in Xpath and XSLT. Of all the XML content we have to deal with all my programmers agree that capatialisation is a bitch. All of our internal schemas are lower case for good reason. The original GPX schemas that I produced upto 1.1 has lowercase tags. My 2 cents worth. Now back to the rest of the emails :-) Kevin
jlinsche+hotmail.com on Sun Feb 03 21:32:32 2002 (link)
I must say that today has been a day of exciting discoveries for me. First, when my father showed me his new Garmin receiver I made a comment as to the lack of quality software available for my Magellan GPS 315, he turned my on to EasyGPS. I downloaded it and it was exactly what I've been looking for. I then perused the EasyGPS web site for all of the goodness it could provide and came upon this project. This is an awesome idea guys! I just wonder why it hasn't been done before. I guess it makes too much sense :) I realize that you are not quite ready to release a final spec yet, but I do have a couple of questions: 1. Are there specified field widths for elements such as cmt and desc? From the proposed schema I figured that there probably isn't, but I thought I'd ask anyway. 2. I noticed that waypoints are redefined in their entirety if included in a route. Will the spec specify which has priority? In other words, if they are different, which waypoint would be written back to the receiver? Or is this up to the developer? Also, will there be a version of free version EasyGPS supporting the final .gpx format? I almost hate asking, sort of like looking a gift horse in the mouth! I hope you find widespread acceptance of this file exchange format. Any chance that the GPS makers, and the GIS community will embrace it as well? At the very least it will provide an invaluable aid to everyone who does use it. I'm primarily interested in importing .gpx files into my own applications. I collect fossils as a hobby and have found the GPS data collection to database connection to be very cumbersome. It appears that will no longer be the case. Good work! James Linscheid Lake Oswego, Oregon USA
hamish+travellingkiwi.com on Mon Feb 04 05:40:41 2002 (link)
Dan Foster wrote:
> Hello,
>
> I'd like to start a general discussion about representing real-time
> positioning
> and navigation info in XML. There are some interesting issues that
> don't have anything to do with GPX or GPSml, but might have bearing
> on our future development.
>
> I'd love to be able to sit at work and watch somebody with a
> wireless Internet connection out mapping trails and sending back an
> XML stream of GPS data! Better yet, I'd volunteer to collect the
> data while you all sit at work!
>
> Existing applications:
> Does anyone know of a service or website that is currently offering
> real-time navigation info over a public web connection? DGPS
> corrections? APRS? hurricane tracks? others?
DGPS is available over the Internet... Sorry. Most of my files are
offline from here... But if noone else volunteers I can provide the
address tomorrow maybe...
>
>
> Here's one example (not XML):
> http://208.139.198.171/AVLDemo/ (tracking the bus in Boulder, CO)
>
> Real-time considerations:
> Data needs to be organized intelligently so that it arrives quickly.
>
> As an example of a bad way to do things, you could decide to group
> everything together by common timestamp, but then you wouldn't send
> an XML packet until a new timestamp showed up in your source NMEA
> stream, which would introduce a time delay.
>
> Backwards compatibility with NMEA:
> It seems like a good goal that any XML stream should be able to be
> transformed into a valid NMEA stream using XSL.
>
> Streaming:
> So how do you stream XML, anyway? It's not valid XML until that
> final tag closes...
>
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+topografix.com
>
>
>
> Yahoo! Groups Sponsor
ADVERTISEMENT
>
> 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.
--
I don't suffer from Insanity... | Linux User #237369
I enjoy every minute of it... |
|
http://www.travellingkiwi.com/ |
egroups+topografix.com on Mon Feb 04 06:49:40 2002 (link), replying to msg
Hello, Monday, February 04, 2002, 12:32:28 AM, James wrote: j> I do have a couple of questions: j> 1. Are there specified field widths for elements such as cmt and j> desc? No. While your GPS might impose a maximum width, GPX has no restrictions. j> 2. I noticed that waypoints are redefined in their entirety if j> included in a route. Will the spec specify which has priority? In j> other words, if they are different, which waypoint would be written j> back to the receiver? Or is this up to the developer? GPX doesn't specify this. Presumably, if you were including the same point as a waypoint and as a route point, it would have identical data. j> Also, will there be a version of free version EasyGPS supporting the j> final .gpx format? I almost hate asking, sort of like looking a gift j> horse in the mouth! Yes. You can get an advance copy at http://www.easygps.com/beta.asp j> I'm primarily interested in importing .gpx files into my own j> applications. I collect fossils as a hobby and have found the GPS j> data collection to database connection to be very cumbersome. It j> appears that will no longer be the case. Let us know how things work out! Best wishes, -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Mon Feb 04 14:03:43 2002 (link), replying to msg
Hello,
Friday, February 01, 2002, 11:18:12 AM, I wrote:
DF> Hello,
DF> As best I can tell, there are five things yet to do before we finalize
DF> GPX 1.0:
DF> 1. rearrange the order of elements (Kjeld's proposal).
DF> 2. write a user document (my job).
DF> 3. agree on any last-minute element additions (see below).
DF> 4. make any structural changes to the schema.
DF> 5. agree we're done, and freeze the 1.0 spec.
I've created a 0.6 GPX schema at
http://www.topografix.com/gpx/0/6/gpx.xsd
This should have all the new elements that were suggested. Please
take a look and propose any changes now so we can finalize the spec.
I added the <trkseg> element to wrap sections of <trkpt>s and solve
the "broken tracklog" problem. Here's an example:
<gpx>
<trk>
<trkseg>
<trkpt A>
<trkpt B>
</trkseg>
<trkseg>
<trkpt C>
<trkpt D>
</trkseg>
</trk>
</gpx>
I've updated my software to read/write
the proposed 0.6 schema, so feel free to use them for testing:
http://www.easygps.com/beta.asp
http://www.expertgps.com/beta.asp
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com
syeameha+yahoo.com on Mon Feb 04 15:18:29 2002 (link)
Hi:
Iam a novice in the field of GPS so i need some information regarding
GPS system.
1). How these Devices work.
2). Does these devices work with Palm Pc.
3). I want to use this device in my town, can i use it ?.
Waiting for u ppl's response.
Bilgrami
davewissenbach+yahoo.com on Mon Feb 04 17:02:59 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > > I added the <trkseg> element to wrap sections of <trkpt>s and solve > the "broken tracklog" problem. Here's an example: > <gpx> > <trk> > <trkseg> > <trkpt A> > <trkpt B> > </trkseg> > <trkseg> > <trkpt C> > <trkpt D> > </trkseg> > </trk> > </gpx> > This is great! I notice that you've added an optional sequence attribute, so I intend to write this attribute, as others (Kevin) have indicated that it might be useful. But I need clarification on usage. I assume that we will start the <seq> at 1 with the beginning of each <trk>, and continue the sequence number from <trkseg> to <trkseg>, rather than starting over. I'll change Wissenbach Map to conform to the new schema and update my samples as soon as possible. By the way, I've GPL'd Wissenbach Map and provided the source code on my web site. (Because in this case I am indeed a "hobby" programmer.) > > I've updated my software to read/write > the proposed 0.6 schema, so feel free to use them for testing: > http://www.easygps.com/beta.asp > http://www.expertgps.com/beta.asp > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
egroups+topografix.com on Tue Feb 05 06:15:07 2002 (link), replying to msg
Hello, Monday, February 04, 2002, 8:02:24 PM, Dave wrote: d> I notice that you've added an optional sequence attribute, so I d> intend to write this attribute, as others (Kevin) have indicated d> that it might be useful. But I need clarification on usage. I assume d> that we will start the <seq> at 1 with the beginning of each <trk>, d> and continue the sequence number from <trkseg> to <trkseg>, rather d> than starting over. Is anyone planning to use this? I thought we'd decided to remove <seq>, based on some emails that went around about parsing any sequence other than 1,2,3. My software won't handle <seq> correctly - will anyone else's? I had actually seen and removed <seq> when I made the 0.6 schema, but it slipped back in as I corrected some errors when I tried to validate the document. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
andrzej+chaeron.com on Tue Feb 05 07:31:11 2002 (link)
Kjeld said:
> Besides our verbal controversies I must say that I have to agree with you
> on many of your ideas and arguments. I believe this discussion could become
> rewarding so I think we should continue it here for a while. It is not like
> there's so much email trafic here anyway :-)
Agreed.
> - As far as I can see the XML data below constitutes the lowest common
> denominator when regards to information for a waypoint or a track. Am I
> right in this? Probably not as I don't see information about the units used
> (meters/feet for altitude and so on).
Units default to degrees (lat/long), WGS84 (Datum) and Meters (distance) so if those
defaults are acceptable, you don't need to specify them in your XML.
> - As we have agreed time is an important issue here. When would we as
> developers be able to use a full featured version "1.0" of GPSml for our
> purposes?
By end of February I would think, but it depends on how much feedback I receive of course.
> - I don't know that much about XML. Would I be able to incorporate
> additional "cetus" tags like for instance if I wanted to express the
> calculated variance in a waypoint determined by averaging and if so then
> how would I do it?
yes. You can add a construct like the following:
<Other>
<CetusTag1>my data 1</CetusTag1>
<CetusTa21>my data 1</CetusTag2>
etc...
</Other>
You can include Other blocks at the end of almost any type in GPSml. So you can have
one inside your Waypoint specification and/or in the Position or Identification blocks.
Another (possibly with a different structure) inside a Track or Route, one at the end of a
Collection, etc.
Using your waypoint example, you could do this (admittedly a bit overboard, but it does
show the flexibility in extending GPSml formats).
(XML header removed)
<GPSData>
<Collection>
<Waypoint>
<Position>
<Latitude>-45.707661705091596</Latitude>
<Longitude>80.33008656464517</Longitude>
<Altitude>210.41272</Altitude>
<Other>
<CetusPosition>where Kjeld is sitting</CetusPosition>
<CetusVelocity>how fast Kjeld is typing</CetusVelocity>>
</Other>
</Position>
<Identification>
<Identifier>AMBUSH</Identifier>
<Other>
<CetusID>Jensen</CetusCetusID>
</Other>
</Identification>
<Other>
<CetusWaypoint>Custom Cetus Waypoint data</CetusWaypoint>
</Other>
</Waypoint>
<Other>
<CetusWaypointCollection>Kjeld's Waypoints</CetusWaypointCollection>
</Other>
</Collection>
</GPSData>
> mentioned XLT's how does this work?
XSLT will let your write a transformation that can be applied to an XML document to turn it
into something else. Another XML document (ie. GPX -> GPSml transform), into HTML
that a browser can render, SVG graphic, or just about anything you want to imagine. It is
my intent to deliver a simple GPX<=>GPSml XSLT transform with my next release (time
allowing), since that would be very useful to people that already have GPX implemented or
need to talk to a GPX-enabled app but would rather implement GPSml (for whatever
reason).
> More important do you see any way that
> we can make GPSml usable for programmers who have written a simple GPS
> application or database which only handles for instance the WGS84 datum,
> decimal minutes and knots/nautical miles/feet units.
The GPSml default units for datum and lat/long are already WGS84 and decimal minutes,
so you don't have to specify them in your XML. I did this deliberately to make the encoding
easier for the simple cases. As for distance, I've been using meters as the default since
that seems to be the common output from a GPS unit (I could be wrong on that). I will be
adding the ability to specify units overrides at higher levels.....say for a whole collection, so
that if you want to override the default consistently for all waypoints (for example) you
would only have to specify the value once. Something like this.....
<GPSData>
<Collection distanceUOMDefault="feet">
<Waypoint>...</Waypoint>
<Waypoint>...</Waypoint>
<Waypoint>...</Waypoint>
</Collection>
</GPSData>
This is raising some interesting validation issues though...which I have not yet resolved.
> With usable I mean
> able to exchange data with a database on the net which is also built by a
> programmer with limited knowledge of XML.
XML is pretty easy to learn, especially since there are pre-written parsers out there (I'll be
using a modified Java SAX parser that will run on smaller devices like the Palm for my GPS
Access Library code base). Not sure what you mean by this?
> I know you have written a Java library to handle this, but it should also
> be possible for a programmer/web database designer to do without the
> library.
Which means they would have to/should use a prewritten parser to convert their XML into a
format that they can then manipulate with their code (DOM/JDOM trees or SAX
events)....that is if they are not storing the XML directly in their DBMS.
> By the way have you considered the precision to which you store lat/lon
> data in your example? It may be a little out of bounds to illustrate them
> using a precision of less than one nanometer.
Yes. I found that to convert Garmin semicircles to degrees and back again exactly (ie. no
rounding errors or changes), I had to use a double precision value. Otherwise if you did the
conversion back and forth a few times, the value would change from the original. Granted
that lat/longs are not that accurate, but I felt it was not a good thing to add to that
inaccuracy because of mathematical precision issues.
------------------------------------------------------
Dan suggests:
> prefer capitalizing the first letter of every word, and
> all letters in acronyms:
> URLName
> Fix
> Time
> GeoidHeight
> DGPSID
> DGPSUpdate
> HDOP
I agree with Dan's approach here....and need to review the tags used in GPSml to ensure
that they stick to this appoach (I think they do for the most part). There are some tags that
are a bit problematic. Trackpoint....is this one word or two? I chose to treat it as one word,
since most people write Waypoint (not WayPoint) and Trackpoint seemed to be akin to that.
> I like the concept of a track segment in GPSml. So...
Thanks! See....releasing GPSml HAS helped GPX! <grins....it's a joke, Kjeld>
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
andrzej+chaeron.com on Tue Feb 05 07:31:16 2002 (link)
Dan opens an interesting area of discussion:
> I'd like to start a general discussion about representing real-time positioning
> and navigation info in XML. There are some interesting issues that
> don't have anything to do with GPX or GPSml, but might have bearing
> on our future development.
Yup...I've been thinking about this very issue.
> I'd love to be able to sit at work and watch somebody with a
> wireless Internet connection out mapping trails and sending back an
> XML stream of GPS data! Better yet, I'd volunteer to collect the
> data while you all sit at work!
Funny...I'm working on a JavaOne demo where a Radio Shack RC (Radio
Controlled) 4x4 toy truck will have a GPS unit mounted on it. That will be
connected to a Systronix board (embedded Java chip application...way kewl
stuff) and have a GPRS wireless connection. We'll be streaming the trucks
position over the wireless to a back end J2EE server that will be logging the
data, and displaying it on a console (probably using a simple moving map
display). We're also considering a quick implementation of the "messages
posted in the air" idea (see:
http://www.newscientist.com/hottopics/phones/phones.jsp?id=23194900 )
where the truck can pick up messages posted at various locations. Of course,
a key aspect of this demo is sending and receiving a stream of GPS data.
> Existing applications:
> Does anyone know of a service or website that is currently offering
> real-time navigation info over a public web connection? DGPS
> corrections? APRS? hurricane tracks? others?
Let me know if you find one. We're building one for the demo...but likely will
not go public with the server side stuff.
> Data needs to be organized intelligently so that it arrives quickly.
> As an example of a bad way to do things, you could decide to group
> everything together by common timestamp, but then you wouldn't send
> an XML packet until a new timestamp showed up in your source NMEA
> stream, which would introduce a time delay.
I am thinking along the lines of having the application generate the timestamp
using it's internal clock and differentiating that timestamp from the one that is
transmitted by the GPS unit (which would be included using a different tag).
This gives you sequential ordering of the data based on when the remote
application got the info from the GPS. In fact, 0.6 of GPSml will use this
approach to tag the Trackpoint entries with a timestamp (using an optional
<TimeStamp> tag) rather than putting this data into a <Time> object (which I
want to reserve for the return of GPS time info....UTC time, etc.).
> Backwards compatibility with NMEA:
> It seems like a good goal that any XML stream should be able to be
> transformed into a valid NMEA stream using XSL.
That should not be very difficult. However, one XML fragment might need to
generate multiple NMEA sentences depending on the structure of the XML
document (which may not and probably should not mirror the NMEA sentence
structure exactly). GPSml also allows an application to "pass through" the
original NMEA sentence into the event stream as a convenience. This way
you can capture exactly what the GPS unit has sent to the app. Good for
testing your code base if you don't have a GPS unit attached or can't get a
lock (ie indoors).
> Streaming:
> So how do you stream XML, anyway? It's not valid XML until that
> final tag closes...
There are a few ways to handle this that I have thought of:
1) You drop the requirement for validation and just transmit XML fragments.
Basically one fragment per event transmitted. If the receiving app needs to
collate all the fragments into a valid document, all it would need to do is add
the XML header info, opening tag, all the fragments and finally the closing tag.
The GPSml schema is designed to allow such an approach. In fact, you could
probably validate each fragment using a similar approach, but why bother?
I'm considering using a wrapper tag for each event, sort of like the following:
<GPSEvent>
<TimeStamp>system clock</TimeStamp>
<Position>....</Position>
</GPSEvent>
<GPSEvent>
<TimeStamp>system clock</TimeStamp>
<Accuracy>....</Accuracy>
</GPSEvent>
<GPSEvent>
<TimeStamp>system clock</TimeStamp>
<NMEASentence>$GPGLL,....</NMEASentence>
</GPSEvent>
This might give you an insight into why some of the structures in GPSml (like
Position, Accuracy, etc.) are defined the way they are. They can be reused
easily inside points (Waypoints, Trackpoints and allow data that is not
intrinsically part of a point (accuracy) to be added from GPS events, if the GPS
does not include this in a point for you)....and can be used as "standalone"
events to model the stream of data coming in from the GPS. To illustrate:
<GPSData>
<Collection>
<Waypoint>
<Position>
<Latitude>-45.707661705091596</Latitude>
<Longitude>80.33008656464517</Longitude>
<Altitude>210.41272</Altitude>
</Position>
</Waypoint>
</Collection>
<GPSEvent>
<TimeStamp>system clock</TimeStamp>
<Position>
<Latitude>-46.3333333333333</Latitude>
<Longitude>79.6666666666666</Longitude>
<Altitude>200.000</Altitude>
</Position>
</GPSEvent>
</GPSData>
Note how the same Position structure is used for both the Waypoint and the
GPS event. This allows an application developer to write a single parsing
method for Position info, and thus reuse it for handling collections of points
and also real time data feeds. I'm trying to "genericize" the data structures so
that you don't end up with multiple ways to specify common domain entities
(like Position in this case) for different uses. This may not always be possible,
but so far seems to make sense and is working out.
2) Each event could be a fully formed XML document......including header and
start/end tags. Sounds like a lot of overhead for no good reason though.
As a side note, the demo (4x4 RC truck) I mentioned earlier will be using
SOAP over HTTP as the transport protocol. Embedding fragments of XML (so
long as they are well formed) is not a big deal in this case since we won't be
storing the data in XML form at the server side.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
andrzej+chaeron.com on Tue Feb 05 07:31:22 2002 (link)
Dan suggests: > I'd like to see the following (optional) in the top-level <gpx>: > <Name> Descriptive name of File > <Desc> File description > <Author> File author name > <Email> File Author email > <URL> File URL > <Creator> File Creator Program > <Time> File Creation Timestamp > <Keywords> File keywords > <BoundsLatMin> Extents of the data in the file > <BoundsLatMax> (these should probably be a complex struct) > <BoundsLonMin> ... > <BoundsLonMax> > > Picture an app that can search a central database for all GPX files > describing mountain bike rides within 20 miles of Boise! Great idea....I'll been planning to add something similar to GPSml, and your list looks good. Most (if not all) such tags should be optional though. I'll probably add a <Description/> wrapper for such stuff and make it optional at the top level. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
andrzej+chaeron.com on Tue Feb 05 07:39:50 2002 (link)
Writing GPS XML data is pretty easy.....best way is usually to just hardcode the tag generation in a few method, so there really is no issue there. The difficulty comes in when you try to read in XML data. The parsing issue is non-trivial and tends to push one towards using an already written parser (probably using SAX rather than DOM/JDOM for efficiency reasons). However, smaller devices do not always provide the I/O library support required to use a standard parser (like Xerces or some such)....and do not need the full "power/complexity" of a validating parser. Just wondering what approach others are using to read in XML data? Hardcoded logic? Commonly available parser? Customized parser code? I'm working on a stripped down SAX parser (based on an open source implementation) to use for my Java GPS Access Library. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
egroups+topografix.com on Tue Feb 05 07:55:47 2002 (link), replying to msg
Hello, Tuesday, February 05, 2002, 10:38:30 AM, Andrzej wrote: AJT> Just wondering what approach others are using to read in XML data? AJT> Hardcoded logic? Commonly available parser? Customized parser code? I'm using a generic parser I wrote in C++. It's a state machine with around 15 states, and is able to tokenize XML docs in one pass, without backtracking. Once the document has been tokenized, I've got GPX-specific code which looks for tokens it recognizes, and ignores the rest. I tried a number of other parsers, but rejected them for being too slow or too bulky for my needs. I don't validate the XML before parsing, but use the Xerces SAXCount app to validate any files that don't parse correctly. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
andrzej+chaeron.com on Tue Feb 05 14:44:51 2002 (link)
> I had actually seen and removed <seq> when I made the 0.6 schema, but > it slipped back in as I corrected some errors when I tried to validate > the document. Sequence numbers seem rather redundant to my thinking. The track points are in logical sequence anyway in the XML (or should be since there is not really any reason to transmit them in anything but chronological sequence). A timestamp makes more sense, since it provides an explicit sequencing, but one that can provide additional value. eg. You can calculate velocities, accel/decel and such across many points. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
andrzej+chaeron.com on Tue Feb 05 14:44:51 2002 (link)
Dan: > I'm using a generic parser I wrote in C++. It's a state machine with > around 15 states, and is able to tokenize XML docs in one pass, > without backtracking. Once the document has been tokenized, I've got > GPX-specific code which looks for tokens it recognizes, and ignores > the rest. Thanks for the insight. > I tried a number of other parsers, but rejected them for being too > slow or too bulky for my needs. There are some rather fast SAX parsers out there (I would stay away from DOM/JDOM since they need to store the whole parse tree in memory...not good for something like a tracklog or large collection of waypoints, especially on handheld devices). Aelfred seems to be a good Java-based one I am evaluating. My thinking is that XML parsers are becoming a standard "toolbox" item, so it's probably not worth writing one from scratch. It also facilitates incorporation of newer W3C XML standards, since it's easier (typically) to upgrade a parser that is being used rather than rejig your own, and also enhances one's ability to react to schema changes (eg GPX or GPSml changes). > I don't validate the XML before parsing, but use the Xerces SAXCount > app to validate any files that don't parse correctly. I agree. Validation should probably be a development time (or problem determination) activity. Not a runtime thing. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
kevin+synergysa.com.au on Wed Feb 06 01:58:16 2002 (link), replying to msg
Strongly disagree I use XPATH extensively to manage waypoints. Most of my XNL comes from a native XML DB so I'm dealing with XML only not a prog specific class that is loaded via XML. Sequencing is used to sort and re-order waypoints as well as routes and tracks trather than manipulating the timestamp and modifying the base data. For example: <..... Sort-by='trk[seq] desc'> If I want to re-order a planned route all I need do is change the sequence and viola. Leaving the orginal track info intact so point to point time caculations can still be made based on the orginal sequence. Seq - I'll be using it regardless, remember those of us using XSLT and XML:DBs please Kevin -----Original Message----- From: Andrzej Jan Taramina [mailto:andrzej+chaeron.com] Sent: Wednesday, 6 February 2002 9:14 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: Sequence numbers > I had actually seen and removed <seq> when I made the 0.6 schema, but > it slipped back in as I corrected some errors when I tried to validate > the document. Sequence numbers seem rather redundant to my thinking. The track points are in logical sequence anyway in the XML (or should be since there is not really any reason to transmit them in anything but chronological sequence). A timestamp makes more sense, since it provides an explicit sequencing, but one that can provide additional value. eg. You can calculate velocities, accel/decel and such across many points. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com 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/
egroups+topografix.com on Wed Feb 06 05:43:11 2002 (link), replying to msg
Hello Kevin, Wednesday, February 06, 2002, 4:57:42 AM, you wrote: KR> Strongly disagree KR> I use XPATH extensively to manage waypoints. Most of my XNL comes from KR> a native XML DB so I'm dealing with XML only not a prog specific class KR> that is loaded via XML. KR> Sequencing is used to sort and re-order waypoints as well as routes and KR> tracks trather than manipulating the timestamp and modifying the base KR> data. KR> For example: KR> <..... Sort-by='trk[seq] desc'> KR> If I want to re-order a planned route all I need do is change the KR> sequence and viola. Leaving the orginal track info intact so point to KR> point time caculations can still be made based on the orginal sequence. KR> Seq - I'll be using it regardless, remember those of us using XSLT and KR> XML:DBs please KR> Kevin Does that mean you'll be producing XML files with out-of-order sequences? Do you have any reply to my earlier statement that I can't correctly parse an out-of-order sequence? (I assume this is the case for other apps as well.) Since <seq> is optional, what do you do about all the files we're producing without <seq>? <seq> isn't defined for waypoints. I can see the usefulness of sorting a list of waypoints by various criteria (elevation, timestamp). Other than reversing a route, why would you want to sort a route/track? Can you make a small example GPX and XSLT file to demonstrate how you'd use <seq>? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
murphy+enterprise.net on Wed Feb 06 06:17:44 2002 (link)
Hi All, On 5 Feb 2002 04:09:36 -0000, "jlinscheid2000" <jlinsche+hotmail.com> wrote: >2. I noticed that waypoints are redefined in their entirety if >included in a route. Will the spec specify which has priority? In >other words, if they are different, which waypoint would be written >back to the receiver? Or is this up to the developer? > It is important to specify what happens when a route contains duplicate waypoint identifiers, but different coordinates, symbols, comments etc. Are they to be treated as 1. Distinct and separate waypoints, but then what happens when the user wishes to pick one of these to go into a route? 2. The second waypoint overwrites the first 3. The second waypoint is ignored 4. What does identical mean? The same coordinate, but different symbol, or the same symbol and different coordinate, everything identical including the comment including upper/lower case etc etc.. ? This can get quite messy. I have not followed all your discussions, but I do feel it is important to allow routes to be defined just in terms of waypoint IDs - that is without any coordinate, routepoint comment, symbol etc. This would get over some of the above problems. Thus: <rte> <name>A via B twice to F</name> <rtept> <name>A</name> </rtept> <rtept> <name>B</name> </rtept> <rtept> <name>C</name> </rtept> <rtept> <name>D</name> </rtept> <rtept> <name>B</name> </rtept> <rtept> <name>F</name> </rtept> </rte> However, this does assume that the waypoints have either 1. already been transmitted earlier in the file or 2. are pre-known by the recipient of the data. This might be the case in when for some reason the waypoint coordinates or other descriptive information (symbols, comments etc.) are not available, or for security/copyright reasons they should or could not be transmitted. The format should support the transmission of Routes which contain only waypoint identifiers. Of course this does raise a few subsequent questions. e.g. 1. the treatment of 'orphaned' routepoints (when the waypoint ID is not known at the receiver) 2. What happens when the receiving system does have duplicate waypoint IDs in its database? - which one to pick? The answers to these questions are not as difficult as the previous set and they can probably be simply left to the implementer. An alternative format for ID only route points could be something like: <rtept name="A"> </rtept> As I said I have not followed all your discussions and apologies if this has already been covered and/or I have not understood some of your aims. Alan Murphy http://www.gpsu.co.uk/ at approx N51�00' W001�22'
hamish+travellingkiwi.com on Wed Feb 06 08:25:04 2002 (link)
Hamish Marson wrote:
> Dan Foster wrote:
>
> > Hello,
> >
> > I'd like to start a general discussion about representing
> real-time
> > positioning
> > and navigation info in XML. There are some interesting issues
> that
> > don't have anything to do with GPX or GPSml, but might have
> bearing
> > on our future development.
> >
> > I'd love to be able to sit at work and watch somebody with a
> > wireless Internet connection out mapping trails and sending back
> an
> > XML stream of GPS data! Better yet, I'd volunteer to collect the
> > data while you all sit at work!
> >
> > Existing applications:
> > Does anyone know of a service or website that is currently
> offering
> > real-time navigation info over a public web connection? DGPS
> > corrections? APRS? hurricane tracks? others?
>
> DGPS is available over the Internet... Sorry. Most of my files are
> offline from here... But if noone else volunteers I can provide the
> address tomorrow maybe...
>
OK.. I found it. (Took about 3 secs through google searching for "dgps
internet"
<http://www.wsrcc.com/wolfgang/gps/dgps-ip.html>
Includes sources for the server and client, docs etc...
>
> >
> >
> > Here's one example (not XML):
> > http://208.139.198.171/AVLDemo/ (tracking the bus in Boulder, CO)
> >
> > Real-time considerations:
> > Data needs to be organized intelligently so that it arrives
> quickly.
> >
> > As an example of a bad way to do things, you could decide to group
>
> > everything together by common timestamp, but then you wouldn't
> send
> > an XML packet until a new timestamp showed up in your source NMEA
> > stream, which would introduce a time delay.
> >
> > Backwards compatibility with NMEA:
> > It seems like a good goal that any XML stream should be able to be
>
> > transformed into a valid NMEA stream using XSL.
> >
> > Streaming:
> > So how do you stream XML, anyway? It's not valid XML until that
> > final tag closes...
> >
> > --
> > Dan Foster
> > TopoGrafix - GPS Software, Waypoints, and Maps
> > http://www.topografix.com - mailto:egroups+topografix.com
> >
> >
> >
> > Yahoo! Groups Sponsor
> ADVERTISEMENT
>
>
> >
> > 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.
>
> --
>
> I don't suffer from Insanity... | Linux User #237369
> I enjoy every minute of it... |
> |
> http://www.travellingkiwi.com/ |
>
>
>
>
> Yahoo! Groups Sponsor
ADVERTISEMENT
>
> 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.
--
I don't suffer from Insanity... | Linux User #237369
I enjoy every minute of it... |
|
http://www.travellingkiwi.com/ |
egroups+topografix.com on Wed Feb 06 09:49:57 2002 (link), replying to msg
Hello, Wednesday, February 06, 2002, 8:18:50 AM, Alan wrote: AM> It is important to specify what happens when a route contains AM> duplicate waypoint identifiers, but different coordinates, symbols, AM> comments etc. This is something that should be left up to the program receiving the information, and not part of GPX. Early on, we made the decision that GPX would be free of GPS-receiver-imposed limitations. Things like waypoint length, waypoint naming restrictions, and duplicate identifiers are the responsibility of the receiving program. Otherwise, GPX would be forced to limit everything to the least common denominator, and we'd never be able to transfer anything that my old Garmin GPX 38 couldn't understand. AM> I have not followed all your discussions, but I do feel it is AM> important to allow routes to be defined just in terms of waypoint IDs AM> - that is without any coordinate, routepoint comment, symbol etc. AM> This would get over some of the above problems. I can see one benefit to have this, but several reasons to keep it out. Yes, it's shorter. Now for the counter-arguments: 1. Waypoint IDs aren't guaranteed unique in GPX. (again, that would be a GPS-restriction, but even then only in the case where the whole data file is transferred to the GPS at once. USA.gpx might contain two waypoints called SMITHFIELD, for example. ) 2. It creates two different ways to say the same thing. Added complexity; added work for GPX parsers... 3. It breaks the 'self-containedness' of GPX. Imagine a XSLT that strips out everything but the routes. It creates a valid GPX file if the route points are specified explicitly, but breaks if it only has a reference to the waypoints in the route. Even if your software uses a "referenced-waypoint" model for creating routes, you should be able to create and receive valid GPX files. When creating GPX, simply look up the waypoint, and write out all the data in routepoint. When reading GPX, it's entirely up to you how you treat the routepoints. You could create new waypoints for each routepoint, or try to do some intelligent matching using the lat/lon and the name. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
blalor+yahoo.f6bdbf+ithacabands.org on Thu Feb 07 07:26:43 2002 (link)
Hey all. I found out about gpx a couple of days ago. I've hacked together a quick script in python using pygarmin and xml.dom.minidom to dump the waypoints, routes and tracks in my eTrex out to a gpx document. Looks like a pretty solid document description! Is there any documentation, outside of the mailing list, about what each of the fields means and how to best use them? I also don't see anything in the .xsd for 0.6 that says anything about units or datums (I'm assuming wgs84). Thanks, B -- Brian Lalor blalor+ithacabands.org
davewissenbach+yahoo.com on Sun Feb 10 14:43:22 2002 (link), replying to msg
--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote: > Works fine with me as it is. Saxcount has not problems validating my tracks > and waypoints. > > 0.6 support is now implemented into the latest public Cetus GPS for Palm > beta and GPS TrackLog beta for Windows. > I've finally got sample GPX 0.6 data, with supporting application Wissenbach Map. I've tested the samples against the latest ExpertGPS beta with good results. My sample data now includes the descriptive bounds data, and I'll soon modify the GPX-to-XHTML stylesheet to extract the descriptive data. For GPX samples see http://www.cableone.net/cdwissenbach
davewissenbach+yahoo.com on Sat Feb 16 07:41:43 2002 (link)
I have written a stylesheet to allow a web browser to display the title, author, description, author-email, and area URL information and map contents (waypoint, track, and route names and descriptions) in the web browser. For this to work with Internet Explorer, the file suffix on the server must be .xml, and a processing instruction is inserted into the preamble of the gps xml file. The demonstration file is http://www.cableone.net/cdwissenbach/BogusBasin.xml The stylesheet is http://www.cableone.net/cdwissenbach/GPXContents.xsl I think that I might want to publish trails on the web as .xml files, rather than as .gpx files. (The transformed document contains instructions to save the file locally as a .gpx file.) But I don't know if it is (yet) possible to get the web browser to associate the document type of gpx with a program. The stylesheet can also be used with a stylesheet processor such as xalan from http://www.apache.org to transform the .gpx file on the server side to an html document.
n8004016+ccs.iitb.ernet.in on Tue Feb 19 01:47:17 2002 (link), replying to msg
Hi, Please let me know about the database schema that you are talking about. I wanted to know details about this project > Hi, > > I would like to know what you think we need in order to step from 0.6 to 1.0? > > As I have no problems with the current 0.6 schema I wouldn't mind going to > 1.0 soon... > > Kjeld With best regards, S.Q.Salman _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Syed Qutub Salman, B-tech Fourth year Residential address _/ _/ Dept. of Civil Engineering D-6/100; DAE colony; _/ _/ Indian Institute of Technology,Bombay ECIL post; Hyderabad _/ _/ Powai, Mumbai-400076 500062; Andhra Pradesh _/ _/ Hostel-3. Room #319 India. _/ _/ Phone: +91-040-7120072 Phone:+91-040-7120072 _/ _/ +91-022-5720095 _/ _/ Email: N8004016+ccs.iitb.ac.in _/ _/ : http://sqsalman.tripod.com _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
egroups+topografix.com on Tue Feb 19 13:16:48 2002 (link), replying to msg
Hello, Tuesday, February 19, 2002, 4:31:30 AM, Kjeld wrote: KJ> I would like to know what you think we need in order to step from 0.6 to 1.0? KJ> As I have no problems with the current 0.6 schema I wouldn't mind going to KJ> 1.0 soon... I made some progress on a GPX manual last week: http://www.topografix.com/gpx_manual.asp Please let me know what else you'd like to see in there. I think it needs some larger examples and a reference to some of the "GPX guiding philosophy" we talked about early on. I still have concerns about the <seq> element that's in 0.6 I asked some questions, but never got a reply back. I'd like to see <seq> dropped in 1.0, but other than that, I'm ready to move to a final definition for GPX 1.0. Dave W. pointed out some GPX implementation errors in my latest beta software, and I'll be correcting those this week. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
jlinsche+hotmail.com on Tue Feb 19 20:28:46 2002 (link), replying to msg
Hi all, I'm new to this discussion, but have been lurking for a while. Dan wrote >I'd like to see <seq> >dropped in 1.0, but other than that, I'm ready to move to a final >definition for GPX 1.0. If the GPX specification states that GPX files will be created in the proper order in the case of routes and tracks, then the <seq> tag is redundant, and such information can easily be added in post processing. The only issue would be if any GPS units require this information. My only experience is with Magellan, but I gather from previous postings that this is not the case. I also read in an earlier posting about adding support for real-time data collection. This might be something to consider. Although a well- adopted standard does exist, NMEA strings, it makes sense to add a provision for encoding it into the GPX format. Like tracks, NMEA represents an automatic collection of positional information over time. By encoding this information into GPX we can leverage GPX handlers to transfer the data. I'm bringing this up very late in the game, so perhaps waiting for 2.0 would be appropriate. My real fear is that it will be implemented as an extension, or worse, several different extensions that will have to be dealt with. Of course this may be a non-issue as the <trkpt> has all of the information that a NMEA stream provides. If <trkpt> is intended for both NMEA data and the standard track feature, then like I said, this is a non-issue. The only thing I would suggest would be either an attribute stating that the source of the data is NMEA, or adding a <nmeapt> tag that could be used in place of <trkpt> when appropriate. The real question however is whether such a distinction is necessary at all. As a side-note I am finishing up a C++ implementation of a GPX parser. It's based on libxml http://xmlsoft.org/, and compiles under Cygwin http://sources.redhat.com/cygwin/ at the moment. It works great, but needs quite a bit of clean up in order to make it presentable. I basically wrapped up libxml into a class called GPX_Parser, which has just a few public interfaces for parsing a file and grabbing structures that contain waypoint data. I'll post this when it's ready. If anyone feels a real need to play with it in its very alpha state I'd be happy to pass it along. Just let me know. I'm pretty satisfied that the API won't change, but the guts need a lot of work. James Linscheid
erich+lodgenet.com on Wed Feb 20 10:00:49 2002 (link)
Howdy, I've been following this group for a while, and finally found time to actually do something with Gpx. I generally download gps data to my handspring, but want to be able to use a desktop program with the data too. I've done some throwaway java apps, and a palm app for gps data. But now I'm mainly using GPilotS and ExpertGPS. My idea of how palm devices and gpx fit together is that palm/gps apps should have a conduit to do the Gpx translation. They shouldn't have to do any gpx processing natively. I've got a rough start on a gpx sync conduit. I can save routes/tracks/waypoints from GPilotS (originally downloaded from a GPS12) in gpx format on my pc. Then I can read the gpx docs in ExpertGPS. The unimplemented features now are: * Only a few waypoint/track/route types of GPilotS are implemented * Only export works, sync and import don't * only GPilotS is implemented, but other apps should be straightforward to add. I'm still sorting out what to do with this thing, as far as release, open source, licensing, etc... So if it's something that you might be interested in, let me know. Thanks, Eric
egroups+topografix.com on Thu Feb 21 07:59:37 2002 (link), replying to msg
Hello, I've posted the 1.0 schema and supporting documentation at http://www.topografix.com/gpx.asp Direct link to the schema: http://www.topografix.com/GPX/1/0/gpx.xsd Changes from 0.6: dropped <seq>. changed capitalization of elements in <bounds>. This is the official 1.0 schema. Please take a close look, and point out any corrections as soon as possible. There's still the chance to make corrections or small changes, but after next week, we'll be locking down the definition for GPX 1.0. I'll post again when 1.0-enabled versions of my software are available, probably late today or tomorrow. We should start a collection of sample files for testing against each other's output. We can store them on the Yahoo Groups site (below), or each author can maintain their own data files on the web and I'll collect the links on a webpage. The Yahoo Groups site requires a login, so I'd prefer to use the web for storage. http://groups.yahoo.com/group/gpsxml/files/Sample%20XML%20Files/ -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Feb 21 14:00:01 2002 (link), replying to msg
Hello, I've updated my software to conform to the GPX 1.0 spec: http://www.easygps.com/beta.asp http://www.topografix.com/beta.asp http://www.expertgps.com/beta.asp -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Thu Feb 21 22:25:18 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > I've posted the 1.0 schema and supporting documentation at http://www.topografix.com/gpx.asp > Direct link to the schema: http://www.topografix.com/GPX/1/0/gpx.xsd > I have updated the Southwestern Idaho Trails Website to the new standard, and published Wissenbach Map 1.7 See my website http://www.cableone.net/cdwissenbach for sample maps, windows application, source code, and links to our programs. > > I'll post again when 1.0-enabled versions of my software are > available, probably late today or tomorrow. > I've downloaded the new ExpertGPS and EasyGPS Beta versions and they display my trails as expected.
davewissenbach+yahoo.com on Sun Feb 24 13:22:13 2002 (link), replying to msg
--- In gpsxml+y..., Kjeld Jensen <gps+c...> wrote: > Hi > > - sorry for the delayed response... > > Looks good to me except that I noticed that some of the date fields are > represented as strings. Wouldn't it be better if all time-date related > elements follows the "gpx date-time format"? > Good catch. I think that this should be xsd:dateTime, which is the same thing as our gpx date-time format but slightly less restrictive in that time zone offsets are allowed. I was using string instead of dateTime in some earlier sample dtd's because Xerces didn't support this before version 1.6. I also noticed one shortcoming with track names. For waypoint, I can use cmt for a more descriptive long name, but with trk this option is not available. Right now I'm storing a long track name, as opposed to a short display name, in a private wissenbach:longname element in the track data. > Kjeld > > > ______________________ > Kjeld Jensen > N 55� 22' E 10� 24' > Email: kjeld+C... > http://www.CetusGPS.dk
egroups+topografix.com on Mon Feb 25 10:48:28 2002 (link), replying to msg
Hello, Sunday, February 24, 2002, 4:22:09 PM, Dave and Kjeld wrote: >> Looks good to me except that I noticed that some of the date d> fields are >> represented as strings. Wouldn't it be better if all time-date d> related >> elements follows the "gpx date-time format"? >> d> I also noticed one shortcoming with track names. For waypoint, I can d> use cmt for a more descriptive long name, but with trk this option d> is not available. I've updated the schema and manual to reflect these changes to GPX 1.0. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Feb 27 08:01:05 2002 (link), replying to msg
Hello, Wednesday, February 27, 2002, 7:17:30 AM, Kjeld wrote: KJ> I have validated my track and waypoint data against the modified gpx.xsd KJ> 1.0 and I have succesfully imported track and waypoint data from Cetus GPS KJ> into the latest Topografix beta. KJ> I vote for a lock of GPX 1.0 without further changes asap... I'm also in favor of locking GPX 1.0 now. If you've got final comments on GPX 1.0, speak up now! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Wed Feb 27 14:15:55 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Wednesday, February 27, 2002, 7:17:30 AM, Kjeld wrote: > > KJ> I have validated my track and waypoint data against the modified gpx.xsd > KJ> 1.0 and I have succesfully imported track and waypoint data from Cetus GPS > KJ> into the latest Topografix beta. > > KJ> I vote for a lock of GPX 1.0 without further changes asap... > > I'm also in favor of locking GPX 1.0 now. > > If you've got final comments on GPX 1.0, speak up now! > The current version is pretty good, and meets the goals of this project! So I think that we can release the schema at any time. We might want to consider using the built-in type xsd:anyURI instead of string for the url elements, but I haven't tested this change to see if it works OK. I'm out sick today, so I've updated my web site to use a style transformation on every link. I even borrowed Dan Foster's idea and inserted a link to a sample photograph Tamarack.jpg in the Ponderosa.gpx sample file--the stylesheet looks for a waypoint type of "photograph" and replaces this with the tag <image> for the browser display! See http://www.cableone.net/cdwissenbach Southwestern Idaho Trail Maps You can link to this page for gps samples. Use http://www.cableone.net/cdwissenbach/map.html if an existence proof of other supporting applications is needed to get the ball rolling. If not, leave the link off -- the link is available on the Southwestern Idaho Trail maps page already. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
jlinsche+hotmail.com on Wed Feb 27 23:57:22 2002 (link)
Hi all, I'm not sure if this is a problem or not, but I thought I'd report it as the release of 1.0 is imminent. I've created a file with the ExpertGPS GPS Beta (V1.1b1). It contains URLS from topozone for some of the waypoints. When I load the GPX file into my parser it bombs, so I thought I'd give it a .xml extension and load it into IE6. It also had an error: ***** IE6 error follows ***** The XML page cannot be displayed Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. ---------------------------------------------------------------------- ---------- A semi colon character was expected. Error processing resource 'file:///D:/devel/gis/gpx2shape/cpp/0.0/bluebooksites.gpx.xml '. Line 35, Position 45 <url>http://www.topozone.com/map.asp? z=11&n=5007844&e=332282&s=25&size=l</url> --------------------------------------------^ **** End error dump **** My thinking is that perhaps the URL field needs to be cdata? My parser is based on libxml if that helps. It doesn't concern me that my parser blew up as I'm still working on it and it's bound to be buggy, but the fact that IE barfed on it has me concerned. I've uploaded the file to the files area under sample GPX files for analysis. James
egroups+topografix.com on Thu Feb 28 13:32:38 2002 (link), replying to msg
Hello, Thursday, February 28, 2002, 2:57:20 AM, jlinscheid2000 wrote: j> I'm not sure if this is a problem or not, but I thought I'd report it j> as the release of 1.0 is imminent. j> I've created a file with the ExpertGPS GPS Beta (V1.1b1). It contains j> URLS from topozone for some of the waypoints. j> When I load the GPX file into my parser it bombs... This is a problem in ExpertGPS, not GPX. I've corrected ExpertGPS to wrap the <url> data in CDATA tags. Any data field that a user can enter should probably be wrapped with CDATA. Even waypoint name and comment are vulnerable - the new Magellan Meridian series allows "-.'/!+#<" as a valid waypoint name! In other news, I updated the GPX 1.0 schema to use xsd:anyURI for <url>, as requested earlier. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
jlinsche+hotmail.com on Thu Feb 28 22:07:50 2002 (link), replying to msg
> This is a problem in ExpertGPS, not GPX. Glad to hear that it's not a fundamental issue. I hope I didn't alarm anyone. I just wanted to be sure. James
egroups+topografix.com on Fri Mar 01 10:40:25 2002 (link), replying to msg
Hello, The GPX 1.0 schema is now official! Congratulations, everyone! It took a while, but our discussions and debates made for a better solution in the end. Now let's get some GPX-enabled applications and websites out there! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
blalor+yahoo.f6bdbf+ithacabands.org on Fri Mar 01 11:52:50 2002 (link)
I guess this is more of a general XML question, but are there any tools that, given a GPX file and the gpx.xsd file, will validate the GPX file? -- Brian Lalor blalor+ithacabands.org
egroups+topografix.com on Fri Mar 01 12:02:17 2002 (link), replying to msg
Hello Brian, Friday, March 01, 2002, 2:52:45 PM, you wrote: BL> I guess this is more of a general XML question, but are there any tools BL> that, given a GPX file and the gpx.xsd file, will validate the GPX file? This is described at http://www.topografix.com/gpx.asp Use the Xerces SAXCount program to validate your GPX file against the schema. http://www.topografix.com/gpx_validation.asp -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Fri Mar 01 21:41:50 2002 (link)
I took a look at my website from the office, where I use Internet Explorer 5.5 instead of Internet Explorer 6.0. The xslt stylesheet transformations do not work correctly with Internet Explorer 5.0 and 5.5 because those browsers were developed before the release of xslt and xpath as W3C Recommendations. The trail contents are complete gobbledegook in Internet Explorer 5.5. So stylesheet transformations of gpx documents to display contents may not be such a good idea after all, or at least not universally applicable! If you are going to publish trails to a wide audience using a stylesheet such as http://www.cableone.net/cdwissenbach/GPXContents.xsl you should be mindful of this incompatibility. I looked at one other stylesheet transformation of GPX both at work (ID 5.5) and later at home (IE 6.0) and noticed a huge difference in appearance and had assumed that the stylesheet had been reposted. What I now realize is that what had changed was the browser.
gps_maps+yahoo.com on Sat Mar 02 02:49:20 2002 (link)
Hello, I'm Doug Adomatis. I guess you'd call me a more of a publisher than a developer. GPX has caught my interest because its proliferation will have an impact on what I do. More about me can be found at my web. Doug Adomatis www.travelbygps.com
gps_maps+yahoo.com on Sat Mar 02 02:51:15 2002 (link)
There's a current thread at sci.geo.sat-nav that I thought someone from this group would reply to. I want to know more about how this issue is handeled in the GPS format. , Doug
gps_maps+yahoo.com on Sun Mar 03 04:35:10 2002 (link), replying to msg
Oops, I ment to write "how is (waypoint naming) handled in GPX / XML format. More specifically, what are the guidelines for waypoint names (number of characters) and what is the waypoint symbol set used in the GPX/XML format? Using these guidlines, how will these waypoint names and symbols look after being converted to a form that can eventually be intrupreted by specific brand/models of GPS receivers? Clearly, I'm a newbie at understanding these development issues, but please humor me with a reply. Doug --- In gpsxml+y..., "gps_maps" <gps_maps+y...> wrote: > There's a current thread at sci.geo.sat-nav that I thought someone > from this group would reply to. I want to know more about how this > issue is handeled in the GPS format. > , Doug
egroups+topografix.com on Sun Mar 03 15:29:33 2002 (link), replying to msg
Hello, Sunday, March 03, 2002, 7:35:06 AM, Doug wrote: g> Oops, I ment to write "how is (waypoint naming) handled in GPX / XML g> format. More specifically, what are the guidelines for waypoint g> names (number of characters) and what is the waypoint symbol set used g> in the GPX/XML format? Using these guidlines, how will these g> waypoint names and symbols look after being converted to a form that g> can eventually be intrupreted by specific brand/models of GPS g> receivers? g> Clearly, I'm a newbie at understanding these development issues, but g> please humor me with a reply. g> Doug GPX is a data exchange format, so there are no limitations placed on the waypoint names or symbols. It's up to the application that transfers the GPX data to the GPS to impose any restrictions. If we made GPX device-dependant, we'd be forced to adopt the least common denominator out of all the GPS units. My Brunton GPS is restricted to 6 character names, and no waypoint symbols! Symbols are specified by name in GPX. <sym>Parking Area</sym>, for example. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Sun Mar 03 16:16:56 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > GPX is a data exchange format, so there are no limitations placed on the > waypoint names or symbols. It's up to the application that transfers > the GPX data to the GPS to impose any restrictions. > > If we made GPX device-dependant, we'd be forced to adopt the least > common denominator out of all the GPS units. My Brunton GPS is > restricted to 6 character names, and no waypoint symbols! > > Symbols are specified by name in GPX. <sym>Parking Area</sym>, for > example. > I'm letting a little bit of device-dependence creep into my sample trails. What I've been doing is to use the name field as a short name that will fit on my eTrex Summit display. 6 characters for a waypoint, or 13 characters for a trail. Then I'm using the cmt field as a longer version of the name. And, I think that I'll also repeat the trail name as the first sentence of the description. However, I have the luxury of supporting only the eTrex in my application. The application itself doesn't enforce this restriction, except by using extremely short display windows in the trail and waypoint name dialog boxes, and by calling the <cmt> field the long name. <name>NYC</name> <cmt>New York City</cmt> <desc>New York City. First settled by the Dutch, this city as become the capital of the world.</desc> But the format doesn't enforce this particular usage, because, as Dan points out, we shouldn't go to the least common denominator in naming trails and waypoints. I think that we might eventually be able to converge on a common usage, though. As far as waypoint names, I was never able to find any Garmin documentation for the topografix names. Instead, I just matched the topografix output and documented this on my program website. The main reason that I repeat the long name as the first sentence of the description for trails is so that I can see the long trail name in ExpertGPS, in an effort to get the most utility for the greatest amount of people. I think that ultimately, the publishers of trail websites and users of the GPX application will get to set the usage pattern. This might be a better topic for the map_authors group. (That's probably the first place to announce this format.)
ithork+yahoo.com on Sun Mar 03 23:07:05 2002 (link)
Hi, I was looking at delveloping a Java program that supports GPX format. I'm still learning about XML in general, but from what I've read, JAXB looked like a good API for this. Until, though, I noticed that you guys were not using a DTD for this (JAXB v1.0 only supports DTD right now). Can anyone suggest an alternative Java API, or has anyone written a DTD for GPX? Thanks! Thor
chris+wilder-smith.org on Mon Mar 04 05:38:58 2002 (link)
Thor, Current versions of Xerces (http://xml.apache.org) support XML schema validation. Chris ithork wrote: >Hi, > >I was looking at delveloping a Java program that supports GPX >format. I'm still learning about XML in general, but from what I've >read, JAXB looked like a good API for this. Until, though, I noticed >that you guys were not using a DTD for this (JAXB v1.0 only supports >DTD right now). Can anyone suggest an alternative Java API, or has >anyone written a DTD for GPX? > >Thanks! >Thor > > > >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/ > > >
gps_maps+yahoo.com on Tue Mar 05 18:54:11 2002 (link), replying to msg
Thanks Dan, Dave. I think I beginning to get a handel on the this. Let me see if I have it straight. If I publish trail maps in gpx format, my readers will need an appilication that can translate gpx into a format that can be uploaded to a GPSR or imported into a mapping program. Right? Kinda like I'm using EasyGPS now - thanks to TopoGrafix. I can see where it is a good idea to have a common format that all readers can use. On one hand, that would make my life easier - not having to publish in multiple formats to reach a larger audience. On the other hand(s), there are other issues that come to mind. Two of my first questions would be: Where will my patrons find these applications? Will they have to pay for them? Clearly, I've gone beyond the subject of this thread. Feel free to reply with a new subject, say "GPX for Publishers" , Doug --- In gpsxml+y..., "davewissenbach" <davewissenbach+y...> wrote: > --- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > > Hello, > > > > GPX is a data exchange format, so there are no limitations placed > on the > > waypoint names or symbols. It's up to the application that > transfers > > the GPX data to the GPS to impose any restrictions. > > > > If we made GPX device-dependant, we'd be forced to adopt the least > > common denominator out of all the GPS units. My Brunton GPS is > > restricted to 6 character names, and no waypoint symbols! > > > > Symbols are specified by name in GPX. <sym>Parking Area</sym>, for > > example. > > > > I'm letting a little bit of device-dependence creep into my sample > trails. What I've been doing is to use the name field as a short > name that will fit on my eTrex Summit display. 6 characters for a > waypoint, or 13 characters for a trail. Then I'm using the cmt field > as a longer version of the name. And, I think that I'll also repeat > the trail name as the first sentence of the description. However, I > have the luxury of supporting only the eTrex in my application. The > application itself doesn't enforce this restriction, except by using > extremely short display windows in the trail and waypoint name > dialog boxes, and by calling the <cmt> field the long name. > > <name>NYC</name> > <cmt>New York City</cmt> > <desc>New York City. First settled by the Dutch, this city as become > the capital of the world.</desc> > > But the format doesn't enforce this particular usage, because, as > Dan points out, we shouldn't go to the least common denominator in > naming trails and waypoints. I think that we might eventually be > able to converge on a common usage, though. > > As far as waypoint names, I was never able to find any Garmin > documentation for the topografix names. Instead, I just matched the > topografix output and documented this on my program website. The > main reason that I repeat the long name as the first sentence of the > description for trails is so that I can see the long trail name in > ExpertGPS, in an effort to get the most utility for the greatest > amount of people. > > I think that ultimately, the publishers of trail websites and users > of the GPX application will get to set the usage pattern. This might > be a better topic for the map_authors group. (That's probably the > first place to announce this format.)
egroups+topografix.com on Wed Mar 06 06:48:31 2002 (link), replying to msg
Hello, Tuesday, March 05, 2002, 7:11:17 PM, Doug wrote: g> If I publish trail maps in gpx g> format, my readers will need an appilication that can translate gpx g> into a format that can be uploaded to a GPSR or imported into a g> mapping program. Right? Kinda like I'm using EasyGPS now - thanks g> to TopoGrafix. I can see where it is a good idea to have a common g> format that all readers can use. On one hand, that would make my g> life easier - not having to publish in multiple formats to reach a g> larger audience. On the other hand(s), there are other issues that g> come to mind. Two of my first questions would be: Where will my g> patrons find these applications? Will they have to pay for them?
andrzej+chaeron.com on Wed Mar 06 08:36:26 2002 (link)
This might have some interest to the members of this list, so I have posted it here: The purpose of the Mobile GPS Demonstration Platform (MGDP) project is to demonstrate a proof of concept for the integration of a number of emerging technologies including: Embedded/Realtime Java, Mobile, position-based applications, GPS (Global Position System) technologies, Wireless/Mobile connectivity, Web Services (XML, SOAP, WSDL, JAX-RPC, etc.), and server- side J2EE (including EJB and DBMS persistence). The MGDP has been constructed using commonly available, inexpensive hardware and software (including open source software) to illustrate that applications of this nature are very feasible using existing tools and technologies. It is hoped that the MGDP project inspires others to push the threshold of what can be done with position- based computing and the Java platform. This project will be demonstrated at JavaOne 2002 in San Francisco (March 25-29, 2002). Drop by the Systronix booth in the JavaOne Vendor Pavillion and see the MGDP in action! A detailed white paper describing the MGDP project, architecture and technologies is available (in .pdf format) at: http://www.chaeron.com Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
gps_maps+yahoo.com on Wed Mar 06 12:40:13 2002 (link), replying to msg
Dan, Thank you for the very detailed information. You've given me a lot to think about here. I had a look the examples, viewed the source, and saw the 'hidden' GPS data. I now understand that the stylesheet defines what data in the gpx file is displayed and how it is to be displayed. Now it seems that I need to study up on what I can do with stylesheets. , Doug --- Dan Foster <egroups+topografix.com> wrote: > Hello, > > Tuesday, March 05, 2002, 7:11:17 PM, Doug wrote: > > g> If I publish trail maps in gpx > g> format, my readers will need an appilication that > can translate gpx > g> into a format that can be uploaded to a GPSR or > imported into a > g> mapping program. Right? Kinda like I'm using > EasyGPS now - thanks > g> to TopoGrafix. I can see where it is a good idea > to have a common > g> format that all readers can use. On one hand, > that would make my > g> life easier - not having to publish in multiple > formats to reach a > g> larger audience. On the other hand(s), there are > other issues that > g> come to mind. Two of my first questions would > be: Where will my > g> patrons find these applications? Will they have > to pay for them? > > From http://www.topografix.com/gpx.asp : > > What are the benefits of GPX? > Here are some of the benefits that GPX provides: > GPX allows you to exchange data with a growing list > of programs for Windows, MacOS, Linux, Palm, and > PocketPC. > GPX can be transformed into other file formats using > a simple webpage or converter program. > GPX is based on the XML standard, so many of the new > programs you use (Microsoft Excel, for example) can > read GPX files. > GPX makes it easy for anyone on the web to develop > new features which will instantly work with your > favorite programs. > > What programs already support GPX? > http://www.topografix.com/gpx_resources.asp > > Publishing GPS data in GPX gives you flexibility in > reaching a wider > audience of users. Let's consider three types of > users: > > 1. Uses a GPX-enabled program already. > GPX files can be opened directly in the user's > favorite program. > You could keep a list of GPX-enabled programs on > your website's > resources page, or even create your own XSL > stylesheet that > mentions them. (see #3) > > 2. Uses a non-GPX-enabled program. > Quite possibly, someone has written (or will soon > write) an XSL > stylesheet to transform GPX files into that > program's format. For > example, Kevin Read wrote an XML to OziExplorer > converter. Once GPX > is introduced to the public, expect the XML-savvy > users to start > writing converters. > http://www.kevinread.com/HTMLTemplates/locform.html > Once GPX starts to gain acceptance, expect more > GPS program authors > to support it. > > 3. Doesn't use any GPS software. > Remember, a GPX file on the web doesn't have to > look like XML. If > you've provided a link to your custom XSLT > stylesheet in your GPX > files, you can make the GPX file look as pretty > as you like. > Dave's trails are good examples of how you could > create something > that reads like a trail guide, but contains all > the info your GPS > needs, too! > Here are two examples: > Dave's Idaho trail page: > http://www.cableone.net/cdwissenbach/ > Dan's sample: > http://www.topografix.com/gpx/samples/topografix/gpx_sample_mbta.gpx > > > You should realize that GPX 1.0 is still only a week > old, and that it > will take a bit of time before GPX-enabled apps show > up. Try > creating a GPX file with one of the apps on the GPX > Resources page, > and see how it looks in some of the other > applications. You might > find it worthwhile to look at the sample files > above, and begin > learning about using XSLT to create your own "house > format" stylesheet > for GPX pages you publish. > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - > mailto:egroups+topografix.com > > > ------------------------ Yahoo! Groups Sponsor > > To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
egroups+topografix.com on Tue Mar 12 19:07:53 2002 (link), replying to msg
Hello, I've updated the beta versions of all my software to add improved GPX 1.0 support. I added several private elements (route color, leg name, leg description, and leg url) to the GPX files produced by my programs so that my users could save their data as GPX without losing any info. I added a File Info dialog similar to Dave's, which also allows the advanced user to specify an XSLT stylesheet for the GPX file. I added a "Publish to Web" feature which allows you to upload your GPX files to your favorite FTP server. An example of the output can be found at: http://home.attbi.com/~topografix/mystic_basin_trail.gpx For more info, see http://home.attbi.com/~topografix/ The new software is at: http://www.easygps.com/beta.asp http://www.topografix.com/beta.asp http://www.expertgps.com/beta.asp -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Fri Mar 29 03:30:49 2002 (link)
I have posted an announcement of Version 2.0 of Wissenbach Map on the map_authors group http://groups.yahoo.com/group/map_authors in the hope that people will begin to use the format. I am also now distributing a local-version CD of the Wissenbach Map program in the Boise area to try to get a few other trails websites out there, and I've added my web site to the search list on http://www.travelbygps.com I hope to see other announcements of programs with support for our new format out there soon! (In fact, I'm counting on it, as I won't be supporting my own program with any particular diligence!) Dave
gps_maps+yahoo.com on Sat Mar 30 02:41:43 2002 (link)
It would be a cruel world without cordless screwdrivers, ATM machines, and wysiwyg HTML editors. What do you use to edit your XML? Please dont' tell me "notebook"! , Doug
davewissenbach+yahoo.com on Sat Mar 30 05:42:56 2002 (link), replying to msg
--- In gpsxml+y..., "gps_maps" <gps_maps+y...> wrote: > It would be a cruel world without cordless screwdrivers, ATM > machines, and wysiwyg HTML editors. What do you use to edit your > XML? Please dont' tell me "notebook"! > , Doug I rarely, if ever, edit .gpx files directly. But when I do, I use wordpad to edit raw text. (I also ride a bicycle to work, every day, rain or shine, cold or hot.) You might visit http://www.xslt.com for a listing of stylesheet editors to transform xml documents. (I even saw a stylesheet debugger there, visual XSTL). I tend to be adverse to expensive new tools, although I do own a cordless screwdriver!
andrzej+chaeron.com on Sun Mar 31 09:15:18 2002 (link)
Doub inquires: > It would be a cruel world without cordless screwdrivers, ATM > machines, and wysiwyg HTML editors. What do you use to edit your > XML? Please dont' tell me "notebook"! Well....I have been known to use notebook for quick on-the-fly changes to small XML-encoded config files. Usually use JPadPro or sometimes XMLSpy otherwise. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
js_sms+yahoo.com on Thu Apr 04 11:48:08 2002 (link)
I am starting a group about GPS (Global Positioning System) in Europe. Everybody is invited to join http://groups.yahoo.com/group/gps-europe/ to join, just send ANY email to: gps-europe-subscribe+yahoogroups.com
robertlipe+yahoo.com on Thu Apr 04 19:21:51 2002 (link)
Hello.
I've started an implementation of a program using GPX 1.0. I intend to
make it freely available. Though I'm not a an XML jock, I have a few
questions and I hope you can help me capture the intent of GPX.
1) <time> is specified as "conforming to ISO 8601" but that allows a
plethora of potential encodings. Is a conforming GPX reader expected
to handle any of them? Could I get a clarification on the precise
allowable members of this field? Bonus points for providing suitable
strftime (as in ISO/IEC 9899:1999) specifiers to make it completely
unambiguous.
2) By my reading, the example file is illegal.
http://groups.yahoo.com/group/gpsxml/files/Sample%20XML%20Files/Kevin%20Read%20Untitled.gpx
This file, among other deviations, contains "lat" and "lon" instead
of "latitude" and "longitude". Are abbreviations for the tag names
really allowed?
3) Does the <url> tag include protocol? ("http://www.mountwashington.org")
4) Are there guidelines for <sym>? Tables for Magellan and Garmin would
be helpful.
5) There is a reference a the elements in <gpx> that links to "Private
elements" but there is no such tag on the page. Is additional
information on this available?
Additionally, this isn't strictly an GPX question, but I suspect this
group has experience on this subject. Is there a table of "real
world" field sizes for the various makers of GPSRs available? For
example, I've learned that Magellan supports 8 character waypoints
and 30 character descriptions in Magellan protocol but the NMEA
limits are 6 and 20. (I've also learned that at least one well known
commercial program crashes when it gets waypoints from my 330 that have
descriptions longer than 20 bytes, so I suspect this is not exactly a
route well travelled.) Similarly, are there published "best practices"
for adapting "portable" data for the various receivers? "Truncate this
field from the right, preserving any trailing numeric data", etc.
Thanx for any help you can offer.
RJL
egroups+topografix.com on Fri Apr 05 06:07:16 2002 (link), replying to msg
Hello, Thursday, April 04, 2002, 10:21:48 PM, Robert wrote: RL> I've started an implementation of a program using GPX 1.0. I intend to RL> make it freely available. Though I'm not a an XML jock, I have a few RL> questions and I hope you can help me capture the intent of GPX. Keep us posted on your progress, Robert, and let us know if you run into other areas of GPX that aren't sufficiently clear. In general, GPX was designed with these goals in mind: - Easy to parse (only ONE way to represent things) - Easy for humans to read RL> 1) <time> is specified as "conforming to ISO 8601" but that allows a RL> plethora of potential encodings. Is a conforming GPX reader expected RL> to handle any of them? Could I get a clarification on the precise RL> allowable members of this field? Bonus points for providing suitable RL> strftime (as in ISO/IEC 9899:1999) specifiers to make it completely RL> unambiguous.
robertlipe+yahoo.com on Fri Apr 05 11:29:01 2002 (link), replying to msg
Hello, Dan.
Thanx for the reply.
> Keep us posted on your progress, Robert, and let us know if you run
I'm largely successfuly parsing the inputs. I haven't started on the
output side yet. It was interesting that I started laying out my
data structures before learning about GPX and had to make very few
changes to accomodate it. I'll probably use it as my primary storage
format.
> In general, GPX was designed with these goals in mind:
> - Easy to parse (only ONE way to represent things)
> - Easy for humans to read
I'm appreciate both goals.
To go to your first point, could you distinguish why some of the
example fields are encoded as CDATA while others have the tag data
directly in the bodies?
The falls creek example contains:
<sym>Dot</sym>
<type><![CDATA[Intersection]]></type>
yet the spec doesn't distinguish those two tags in any way that I see
that allows the different content styles. Perhaps this is one of
those things that's obvious to XML jocks in which case, please just
point me politly to an authoritative paper.
> GPX 1.0 is more strict, and only allows two representations: ("Easy
to Parse")
Do I need to file some kind of formal erratum to get the official
spec clarified, or are message like this enough? Is there any kind
of revision scheme in place since we've just made an incompatible
change to "1.0" or is slipstreaming it accepted practice here? (I
don't mind - I'm just trying to understand the guidelines.)
> 1. <time>2002-02-10T21:01:29.250Z</time> (fractional seconds)
>
> 2. <time>2002-02-10T21:01:29Z</time> (no fractional seconds)
This, for example, should be spelled out in the spec, becuase I could
(and did!) fill that with an ISO 8601-compliant string that was
against the intent. Spell it out very plainly. Are leading zeros
required or optional? Is 12-hour format with AM/PM ever acceptable,
etc. (Don't answer the questions; fix the spec. :-)
Similary, clarifying the meaning of the "T" and "Z" in your example
would be helpful. To this moment, I don't know what they are.
> lat and lon are the correct tag names. "latitude" and "longitude"
> aren't allowed. The guiding rule was "choose a tag name that's long
OK, good.
> I've corrected the manual to remove references to "latitude" and
> "longitude". Please excuse my earlier error.
I've been involved in specifications more complex than this one. I
understand. :-)
> RL> 4) Are there guidelines for <sym>? Tables for Magellan and
> becomes a guessing game. Even Garmin has trouble keeping the names
> straight - they've switched names on several GPS models, and their
> MapSource software doesn't always use the same names.
That's indeed the rub. I was looking for tables from industry
leaders to help guide and normalize any output I may generate - after
all, avoiding yet MORE divergence in this area would be a Good Thing.
Magellan makes things even ickier by using different icon identifier
to token mappings in different models and even different f/w versions.
> EasyGPS includes the names for many brands of GPS. You're welcome
to
> use those for reference. As mentioned above, nobody does a perfect
> job with the names, but in places where two programs share the same
> name for a symbol, GPX will do the right thing.
I can't spot such a list at http://www.easygps.com/manual.asp.
Can you please provide a more precise reference?
> RL> 5) There is a reference a the elements in <gpx> that links to
"Private
> RL> elements" but there is no such tag on the page. Is
additional
> RL> information on this available?
>
> You can put any tags you want at the end of any element in GPX. You
> need to provide your own schema for these tags. You can look at the
> topografix or wissenbach private data for examples:
Interesting. This would be good text to put in the dangling internal
href link to:
http://www.topografix.com/gpx_manual.asp#gpx_private
> RL> route well travelled.) Similarly, are there published "best
practices"
> RL> for adapting "portable" data for the various receivers?
"Truncate this
> It's more complicated than just data length, since each GPS model
> has it's own list of acceptable characters.
Oh, there's a form of joy I wasn't even expecting. Thanx for the
tip.
> Converting "+MyCar" (Magellan
> Meridian) to "MYCAR " (Garmin 38) is a difficult task. My own
method
> is:
> 1. Remove all illegal characters.
> 2. Truncate to maximum length.
So you don't try to get clever with making "+mycarisa78pinto" from
"+mycarisa71mustang" into seperate names, just letting them collide
after you apply the heuristics above?
If it's a problem you haven't seen fit to solve, then I'll feel a lot
better about not worrying about it. :-)
> GPX doesn't impose any restrictions on data length or contents, so
"My
> very 1st waypoint with ASCII JunK!$#+$$$" is a valid waypoint name.
> It's up to your program to impose any restrictions before sending to
> a GPS.
I agree that "cleansing" the data at the edges is most appropriate. I
was just looking for guidance on the mechanics of that cleansing since
I figured this crowd had dealt with those issues.
> Hope this helps!
Indeed it does. Thanx very much!
robertlipe+usa.net
davewissenbach+yahoo.com on Fri Apr 05 17:54:11 2002 (link), replying to msg
--- In gpsxml+y..., Robert Lipe <robertlipe+y...> wrote: > Hello. > > I've started an implementation of a program using GPX 1.0. I intend to > make it freely available. > > 2) By my reading, the example file is illegal. ... > > http://groups.yahoo.com/group/gpsxml/files/Sample%20XML% 20Files/Kevin%20Read%20Untitled.gpx > > The required version attribute tells the story here. <gpx version="0.2" ... The released version is 1.0. That sample probably may not have been validated against the version 0.2 schema. There is a different schema for each version of the format. The schemaLocation should select a schema to match the version. Protect your application against schema changes by ignoring unknown elements. Protect other applications from yours by validating test files from your application against the schema. Regarding symbols. Tough question. I've put the ones I use for the Garmin eTrex on my web page http://www.cableone.net/cdwissenbach/map.html > > RJL
robertlipe+yahoo.com on Sat Apr 06 09:04:37 2002 (link), replying to msg
--- In gpsxml+y..., "davewissenbach" <davewissenbach+y...> wrote: > --- In gpsxml+y..., Robert Lipe <robertlipe+y...> wrote: > > 2) By my reading, the example file is illegal. > > ... > > > http://groups.yahoo.com/group/gpsxml/files/Sample%20XML% > 20Files/Kevin%20Read%20Untitled.gpx > > > > > The required version attribute tells the story here. > > <gpx version="0.2" ... > > The released version is 1.0. That sample probably may not have been Aaaah. I'd missed that detail. Perhaps the samples in the 'files' section of the yahoo group should be updated or at least more clearly marked as being for a prototype version. > validated against the version 0.2 schema. There is a different > schema for each version of the format. The schemaLocation should > select a schema to match the version. Forgive my XML virginity here, but I don't know what a 'schema' is. Just reading it, it appears somewhat like what we dinosaurs would call a 'grammar'. In 50 words are less, can anyone offer an explanation of what a schema is and why we'd care? (References to books or URLs or whatever are fine; I'm not expecting a free education here. :-) > Tough question. I've put the ones I use for the Garmin eTrex on my > web page > > http://www.cableone.net/cdwissenbach/map.html Thanx for the reference. There is a substantial overlap betweeen this table and the five (grrrrr.) magellan tables. There are some gratituous differences, but since this would ultimately fall into a case insensitive table match anyway, I think I can handle this pretty easily with just some slightly redundant table entries. Besides, at the end of the day if an icon gets an inexact translation, it's not a traumatic event. This disucssion will help me honor the adage of: "Be liberal in what you accept and conservative in what you generate..." Thanx! RJL
Helen+CastellarPelster.com on Mon Apr 08 01:46:06 2002 (link), replying to msg
Thor, I have recently started using JAXB for another (unrelated) project. I've been very impressed so far. There are a few little glitches, but no show-stoppers. I'd like to see the GPX schema have a companion DTD for now... there seem to still be a bunch of tools that only support DTDs. I'll take a closer look at the schema when I get a chance - maybe it would be an easy conversion to a DTD. -Helen --- In gpsxml+y..., "ithork" <ithork+y...> wrote: > Hi, > > I was looking at delveloping a Java program that supports GPX > format. I'm still learning about XML in general, but from what I've > read, JAXB looked like a good API for this. Until, though, I noticed > that you guys were not using a DTD for this (JAXB v1.0 only supports > DTD right now). Can anyone suggest an alternative Java API, or has > anyone written a DTD for GPX? > > Thanks! > Thor
davewissenbach+yahoo.com on Tue Apr 09 22:17:40 2002 (link), replying to msg
--- In gpsxml+y..., "robertlipe" <robertlipe+y...> wrote: > > > > The released version is 1.0. That sample probably may not have been > > Aaaah. I'd missed that detail. Perhaps the samples in the 'files' > section of the yahoo group should be updated or at least more clearly > marked as being for a prototype version. > I've posted newer samples for GPX1.0 in the Files section. > Forgive my XML virginity here, but I don't know what a 'schema' is. > Just reading it, it appears somewhat like what we dinosaurs would call > a 'grammar'. In 50 words are less, can anyone offer an explanation of > what a schema is and why we'd care? (References to books or URLs or > whatever are fine; I'm not expecting a free education here. :-) > An XML Schema is an XML document which defines the grammar for an XML application such as GPS eXchange. See the standard with supporting documentation at http://www.w3.org/XML/Schema I've bought two XML books so far: XML In a Nutshell, O'REILLY, ISBN: 0-596-00058-8 and Professional XML Schemas, WROX, ISBN: 1-861005-47-4 > > Thanx! > RJL
threadhead+mac.com on Sat Apr 13 11:35:11 2002 (link)
I am finish my app for doing some GPSR management and I would like to use the GPX format for saving all files. But I would like to include some application specific info (like window positions, preferences, etc.) in the <gpx>. I couldn't file a spcification for private data in the GPX dev man. Where should it go? Or, is there no allowance for private data? Karl
davewissenbach+yahoo.com on Sat Apr 13 15:08:03 2002 (link), replying to msg
--- In gpsxml+y..., "ThreadHead1" <threadhead+m...> wrote: > I am finish my app for doing some GPSR management and I > would like to use the GPX format for saving all files. But I would > like to include some application specific info (like window > positions, preferences, etc.) in the <gpx>. > > I couldn't file a spcification for private data in the GPX dev man. > Where should it go? Or, is there no allowance for private data? > > Karl There is a provision for private data. But shouldn't window positions and preferences go in the registry? (If this is a windows program). Look at the Schema, url below: http://www.topografix.com/GPX/1/0/gpx.xsd Private data must be qualified in your namespace and can be inserted into the document anywhere you see <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" /> If you think that the rest of us might also eventually use this information then we should talk about creating a new version of the schema which allows this. To validate that your application's output (and you should)conforms to the schema, you'll need your own auxiliary schema. You can see examples of how this is done in my samples at http://www.cableone.net/cdwissenbach <gpx xmlns="http://www.topografix.com/GPX/1/0" version="1.0" creator="Wissenbach Map 1.7" xmlns:wissenbach="http://www.cableone.net/cdwissenbach" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.cableone.net/cdwissenbach http://www.cableone.net/cdwissenbach/wissenbach.xsd"> The private schema is http://www.cableone.net/cdwissenbach/ where I insert a <wissenbach:layer> tag to assign trails, routes and waypoints to a permanent layer or to a working layer. ExpertGPS uses the same technique to assign a color to tracks and routes. Notice the additional namespace declaration and the additional pair of URLs in the schemaLocation attribute to match the additional namespace to the schema for the private data. You should be able to validate a sample document without complaint from the Zerces, or other schema-aware, validating parser.
lupitacox+yahoo.com on Mon Apr 22 18:49:28 2002 (link)
Thanks to TopoGrafix for starting this GPS data standard! I was going to change the data file format in USAPhotoMaps to include more data, and the GPX standard looks like a great idea. Doug Cox
egroups+topografix.com on Tue Apr 23 10:12:54 2002 (link), replying to msg
Hello, Monday, April 22, 2002, 9:49:27 PM, Doug wrote: l> Thanks to TopoGrafix for starting this GPS data standard! l> I was going to change the data file format in USAPhotoMaps to include l> more data, and the GPX standard looks like a great idea. It's great to have you on board, Doug! Let us know how your progress goes, and tell us if there's anything unclear about the standard or the documentation. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Tue Apr 23 10:34:05 2002 (link), replying to msg
Hello, I've added some more examples of using GPX for publishing trail descriptions. This mountain biking site uses Active Server Pages to transform the GPX data on the server side, and deliver HTML to the web browser. It uses XSL to present several views of the GPX data. http://www.topografix.com/team/trails.asp One page filters the GPX data to just the waypoints, and then uses an HTML form to send the data to Kevin Read's GPX to Ozi Explorer converter. Hopefully others will create some web-based converters for other data formats. My GPX trails page shows what you can do without using fancy scripting on the server side. I used ExpertGPS to upload GPX data directly to my free website. http://home.attbi.com/~topografix/ -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Apr 23 19:41:16 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > I've added some more examples of using GPX for publishing trail > descriptions. > ... > > > My GPX trails page shows what you can do without using fancy > scripting on the server side. I used ExpertGPS to upload GPX data > directly to my free website. > http://home.attbi.com/~topografix/ > I really like bicycling, so I appreciate the team Topografix bicycle trails pages. I never go anywhere without my GPS. The really neat thing about the simple website is the usage of the map index page to index to the other trails pages! I'm going to copy this concept to create an index page for my own website. The kayak trip is really neat. I know avid fishermen who are using their GPS receivers to mark fishing holes, and to gauge their progress on the river to watch out for the big rapids, and to make sure that they don't float too fast, wasting the day, or too slow, endangering themselves caught out after dark. I may ask a couple of friends from work for text format output from their cereal box GPS programs to try to develop a few more stylesheets, time permitting. You should cross-post the two sample trails URLs to the map_authors yahoo group as well!
gps_maps+yahoo.com on Wed Apr 24 05:11:04 2002 (link), replying to msg
All the examples I've seen lack richness. I'm talking about layout. Dan and Dave's examples read vertically, from top to bottom using font and indention to set apart content. What are the possibilities? Can you specifiy a background; include a picture, right margin justified; use buttons, ... ? I like the idea of using a standard file format, but I'm not convinced that I should be using GPX showcase file descriptions. Currently, my plans are to link to a GPX file from the description page as I have done at www.travelbygps.com/guides/borrego/borrego.htm Is this a good approach or am I still not "getting it"? , Doug --- Dan Foster <egroups+topografix.com> wrote: > Hello, > > I've added some more examples of using GPX for > publishing trail > descriptions. > > This mountain biking site uses Active Server Pages > to transform the > GPX data on the server side, and deliver HTML to > the web browser. > It uses XSL to present several views of the GPX > data. > http://www.topografix.com/team/trails.asp > > One page filters the GPX data to just the > waypoints, and then uses > an HTML form to send the data to Kevin Read's GPX > to Ozi Explorer > converter. Hopefully others will create some > web-based converters > for other data formats. > > > My GPX trails page shows what you can do without > using fancy > scripting on the server side. I used ExpertGPS to > upload GPX data > directly to my free website. > http://home.attbi.com/~topografix/ > > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - > mailto:egroups+topografix.com > > > ------------------------ Yahoo! Groups Sponsor > > To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
lupitacox+yahoo.com on Wed Apr 24 07:10:27 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote:
> It's great to have you on board, Doug! Let us know how your
> progress goes, and tell us if there's anything unclear about the
> standard or the documentation.
>
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+t...
The GPX standard covers all the waypoint data Magellan GPS
can send to a PC, but newer Garmins can send and receive
more data. I have an old Garmin Map12 (that only sends and
receives the basic data that a Magellan sends and receives),
so I don't really know if newer Garmins lose waypoint data
if you download it to a PC and then upload only the basic
waypoint data back. But if Garmins do lose data when it's
truncated in a GPX waypoint file and then sent back, then I
think the standard should be expanded. I realize this is a
judgment call, since even if some data was lost, it doesn't
look too necessary. Here's the Garmin waypoint data
structure for the newest Garmins:
typedef
struct /* size */
{
byte dtyp; /* data packet type (0x01 for
D109)1 */
byte wpt_class; /*
class 1 */
byte dspl_color; /* display & color (see
below) 1 */
byte attr; /* attributes (0x70 for
D109) 1 */
Symbol_Type smbl; /* waypoint
symbol 2 */
byte subclass[18]; /*
subclass 18 */
Semicircle_Type posn; /* 32 bit
semicircle 8 */
float alt; /* altitude in
meters 4 */
float dpth; /* depth in
meters 4 */
float dist; /* proximity distance in
meters 4 */
char state[2]; /*
state 2 */
char cc[2]; /* country
code 2 */
longword ete; /* outbound link ete in
seconds 4 */
/* char ident[]; variable length
string 1-51 */
/* char comment[]; waypoint user
comment 1-51 */
/* char facility[]; facility
name 1-31 */
/* char city[]; city
name 1-25 */
/* char addr[]; address
number 1-51 */
/* char cross_road[]; intersecting road
label 1-51 */
} D109_Wpt_Type;
All fields are defined the same as D108 except as noted below.
dtyp - Data packet type, must be 0x01 for D109.
dsp_color - The 'dspl_color' member contains three fields; bits 0-4
specify
the color, bits 5-6 specify the waypoint display attribute and bit 7
is unused
and must be 0. Color values are as specified for D108 except that the
default
value is 0x1f. Display attribute values are as specified for D108.
attr - Attribute. Must be 0x70 for D109.
ete - Estimated time en route in seconds to next waypoint. Default
value is
0xffffffff.
lupitacox+yahoo.com on Wed Apr 24 07:25:18 2002 (link)
This group-posting software does an automatic wordwrap at the end of the 58th character on a line, so everyone writing a message here should write it in Notepad (or whatever), and do a hard carriage return (press Enter) before a word crosses that 58th character on a line (like I'm doing). Doug Cox
egroups+topografix.com on Wed Apr 24 07:31:28 2002 (link), replying to msg
Hello, Wednesday, April 24, 2002, 8:11:03 AM, Doug wrote: DA> All the examples I've seen lack richness. I'm talking DA> about layout. Dan and Dave's examples read vertically, DA> from top to bottom using font and indention to set DA> apart content. What are the possibilities? Can you DA> specifiy a background; include a picture, right margin DA> justified; use buttons, ... ? DA> I like the idea of using a standard file format, but DA> I'm not convinced that I should be using GPX showcase DA> file descriptions. Currently, my plans are to link to DA> a GPX file from the description page as I have done at DA> www.travelbygps.com/guides/borrego/borrego.htm DA> Is this a good approach or am I still not "getting DA> it"? The possibilities are endless... Assuming you can figure out the XSL statements to use! Here's a general strategy for converting your HTML layout to GPX/XSL: Your website has a look. On each page, the text changes, but certain things (background picture, fonts, margin sizes) remain the same. Let's call the changing text "content", and the common style a "template". The content for each page will live in a GPX file, and the common template will be an XSL file. The XSL will display your HTML page, and insert pieces of GPX data as content. (Think of the Mail Merge command in Microsoft Word...) The first thing to do is to strip away all the content and create a template with placeholders for the content. For example, on the page you offered, "Anza-Borrego State Park" becomes [file-name], and "Most folks envision the desert as a wasteland..." becomes [file-description]. Do this for all the changing content on your page. Now look at the list of placeholders, and try to match them up with GPX tags: [file-name] = <gpx:name> [file-description] = <gpx:desc> [file-photo] = !!! doesn't exist in GPX !!! ... Notice that there's no way to specify a photo for the GPX file. If you can't include the picture information in the GPX file, you won't be able to use it as content on your page. (This is different from including the same picture on every page - that's part of your template!) You have three choices: 1. Remove [file-photo] from your template. 2. Create your own private GPX tag for [file-photo], and edit your GPX files by hand. 3. Suggest to this group that we include a [file-photo] tag in the next version of GPX. Let's assume you chose option #1 for all placeholders that didn't match up with GPX tags. You now have a list of GPX tags to insert in your XSL template. Don't replace any yet. XSL can be really difficult to debug when you make a mistake, so let's add the tags one at a time. First, start with an XSL document that only displays your stripped down template. Here's mine: saved as test.xsl: <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:gpx="http://www.topografix.com/GPX/1/0"> <xsl:template match="gpx:gpx"> <html> <head> <title>[file-title]</title> </head> <body> <h2>[file-title]</h2> <p> [file-description] </p> </body> </html> </xsl:template> </xsl:stylesheet> Now let's replace the [file-title] placeholder with the <gpx:name> tag: saved as test.xsl: <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:gpx="http://www.topografix.com/GPX/1/0"> <xsl:template match="gpx:gpx"> <html> <head> <title><xsl:apply-templates select="gpx:name"/></title> </head> <body> <h2><xsl:apply-templates select="gpx:name"/></h2> <p> [file-description] </p> </body> </html> </xsl:template> <xsl:template match="gpx:name"> <xsl:value-of select="."/> </xsl:template> </xsl:stylesheet> As you can see, I replaced all [file-title] placeholders with: <xsl:apply-templates select="gpx:name"/> and I added a new template: <xsl:template match="gpx:name"> <xsl:value-of select="."/> </xsl:template> Keep doing that with all your placeholders, and you'll end up with your finished XSL transform document to use with all your GPX files. Here's the stripped-down sample GPX data I was using: saved as borrego3.xml: <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> <?xml-stylesheet type="text/xsl" href="test.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:topografix="http://www.topografix.com/GPX/Private/TopoGrafix/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/Private/TopoGrafix/0/1 http://www.topografix.com/GPX/Private/TopoGrafix/0/1/topografix.xsd"> <name><![CDATA[Anza-Borrego State Park]]></name> <desc><![CDATA[Most folks envision the desert as a wasteland completely void of hospitable scenery and lacking in varied topography, but the quintessential picture of the Borrego Desert is a California Palm Oasis with the costal mountain range as backdrop. These palm oases are the object of a popular activity, called "oasis bagging." You drive for miles on jeep trails up arroyos and washes, get out and hike up canyons, then walk around to find the perfect location to photograph these desert rarities. Download this GPS Map to help you locate many of the Palm Oases and other points fo interest in the Borrego Dessert. The Anza-Borrego State Park is located two hours east of San Diego. RVs pulling off-road vehicles are a common site along the routes between the desert and the population centers of southern California. Accommodations for RV camping are as plentiful and varied as the 4-wheel drive trails on which to ride. Likewise, other lodging facilities include budget motels, bed-and-breakfasts, and even a five-star hotel. ]]></desc> </gpx> This is just a basic example to get you started with XSL. I didn't attempt to describe what any of those XSL statements meant, because at first, you won't care, and later, you'll use other people's examples or Google or a book to figure things out. XSL is tough stuff. I'm still struggling to learn it, and I suspect others are as well. I'd be happy to host some sample XSL files on my website if others want to contribute some tutorial snippets. If you have specific XSL questions, post them here, and someone may have already figured out the answer. Q. how do I turn <url> into a hyperlink? A. <xsl:template match="gpx:url"> <p>Related website: <xsl:text disable-output-escaping="yes"><a href="</xsl:text> <xsl:value-of select="."/> <xsl:text disable-output-escaping="yes">" target="_blank"></xsl:text> <xsl:value-of select="../gpx:urlname"/> <xsl:text disable-output-escaping="yes"></a> </xsl:text> </p> </xsl:template> Good luck! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Apr 24 08:02:08 2002 (link), replying to msg
Hello, Wednesday, April 24, 2002, 10:08:44 AM, Doug wrote: l> The GPX standard covers all the waypoint data Magellan GPS l> can send to a PC, but newer Garmins can send and receive l> more data. I have an old Garmin Map12 (that only sends and l> receives the basic data that a Magellan sends and receives), l> so I don't really know if newer Garmins lose waypoint data l> if you download it to a PC and then upload only the basic l> waypoint data back. But if Garmins do lose data when it's l> truncated in a GPX waypoint file and then sent back, then I l> think the standard should be expanded. I realize this is a l> judgment call, since even if some data was lost, it doesn't l> look too necessary. Most of those data fields are used for specifying routes that contain waypoints from aviation databases built into the GPS. (Jeppesen data, for example) I've never seen a file format that included those data elements. I supply a custom version of EasyGPS to an aviation flight-planning service. We don't include any of the Garmin aviation fields in our file exchange. There are certainly some elements of the Garmin private data that could be included in GPX. <depth>120</depth> makes sense for exchanging data between fish-finders. <subclass>???</subclass> doesn't make much sense outside of the Garmin world, though. That's why you have the ability to define private data tags in GPX. To answer your question about whether Garmins lose data, they don't. What happens is that if you send the GPX-stripped version of an aviation routepoint back to the GPS, it will create a user waypoint rather than using the matching airport in the Jeppesen database. So you end up with one extra waypoint in memory. Not a big issue for most people, and pilots expect this when using 3rd party software. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
lupitacox+yahoo.com on Wed Apr 24 09:55:53 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Most of those data fields are used for specifying routes that contain > waypoints from aviation databases built into the GPS. (Jeppesen data, > for example) I've never seen a file format that included those data > elements. > > I supply a custom version of EasyGPS to an aviation flight-planning > service. We don't include any of the Garmin aviation fields in our > file exchange. > > There are certainly some elements of the Garmin private data that > could be included in GPX. <depth>120</depth> makes sense for > exchanging data between fish-finders. <subclass>???</subclass> > doesn't make much sense outside of the Garmin world, though. > That's why you have the ability to define private data tags in GPX. > > > To answer your question about whether Garmins lose data, they don't. > What happens is that if you send the GPX-stripped version of an aviation > routepoint back to the GPS, it will create a user waypoint rather than > using the matching airport in the Jeppesen database. So you end up > with one extra waypoint in memory. Not a big issue for most people, > and pilots expect this when using 3rd party software. > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t... Thanks a lot for the quick reply! That all sounds good to me! Doug Cox
gps_maps+yahoo.com on Thu Apr 25 04:47:21 2002 (link), replying to msg
Wow. Thanks for the detailed reply, Dan. This will take some indigesting. , Doug --- Dan Foster <egroups+topografix.com> wrote: > Hello, > > Wednesday, April 24, 2002, 8:11:03 AM, Doug wrote: > > DA> All the examples I've seen lack richness. I'm > talking > DA> about layout. Dan and Dave's examples read > vertically, > DA> from top to bottom using font and indention to > set > DA> apart content. What are the possibilities? Can > you > DA> specifiy a background; include a picture, right > margin > DA> justified; use buttons, ... ? > DA> I like the idea of using a standard file format, > but > DA> I'm not convinced that I should be using GPX > showcase > DA> file descriptions. Currently, my plans are to > link to > DA> a GPX file from the description page as I have > done at > DA> www.travelbygps.com/guides/borrego/borrego.htm > DA> Is this a good approach or am I still not > "getting > DA> it"? > > The possibilities are endless... Assuming you can > figure out the > XSL statements to use! > > Here's a general strategy for converting your HTML > layout to GPX/XSL: > > Your website has a look. On each page, the text > changes, but > certain things (background picture, fonts, margin > sizes) remain the > same. Let's call the changing text "content", and > the common style a > "template". The content for each page will live in > a GPX file, and > the common template will be an XSL file. The XSL > will display your > HTML page, and insert pieces of GPX data as > content. (Think of the > Mail Merge command in Microsoft Word...) > > The first thing to do is to strip away all the > content and create a > template with placeholders for the content. For > example, on the page > you offered, "Anza-Borrego State Park" becomes > [file-name], and > "Most folks envision the desert as a wasteland..." > becomes > [file-description]. Do this for all the changing > content on your > page. > > Now look at the list of placeholders, and try to > match them up with > GPX tags: > [file-name] = <gpx:name> > [file-description] = <gpx:desc> > [file-photo] = !!! doesn't exist in GPX !!! > ... > > Notice that there's no way to specify a photo for > the GPX file. > If you can't include the picture information in the > GPX file, you won't > be able to use it as content on your page. (This > is different from > including the same picture on every page - that's > part of your > template!) You have three choices: > 1. Remove [file-photo] from your template. > 2. Create your own private GPX tag for > [file-photo], and edit your > GPX files by hand. > 3. Suggest to this group that we include a > [file-photo] tag in the > next version of GPX. > > Let's assume you chose option #1 for all > placeholders that didn't > match up with GPX tags. You now have a list of GPX > tags to insert in > your XSL template. Don't replace any yet. XSL can > be really > difficult to debug when you make a mistake, so > let's add the tags one > at a time. > > First, start with an XSL document that only > displays your stripped > down template. Here's mine: > > saved as test.xsl: > <?xml version="1.0"?> > <xsl:stylesheet version="1.0" > xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > xmlns:gpx="http://www.topografix.com/GPX/1/0"> > <xsl:template match="gpx:gpx"> > > <html> > <head> > <title>[file-title]</title> > </head> > <body> > <h2>[file-title]</h2> > <p> > [file-description] > </p> > </body> > </html> > > </xsl:template> > </xsl:stylesheet> > > Now let's replace the [file-title] placeholder with > the <gpx:name> > tag: > > saved as test.xsl: > <?xml version="1.0"?> > <xsl:stylesheet version="1.0" > xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > xmlns:gpx="http://www.topografix.com/GPX/1/0"> > <xsl:template match="gpx:gpx"> > > <html> > <head> > <title><xsl:apply-templates > select="gpx:name"/></title> > </head> > <body> > <h2><xsl:apply-templates select="gpx:name"/></h2> > <p> > [file-description] > </p> > </body> > </html> > > </xsl:template> > > <xsl:template match="gpx:name"> > <xsl:value-of select="."/> > </xsl:template> > > </xsl:stylesheet> > > As you can see, I replaced all [file-title] > placeholders with: > <xsl:apply-templates select="gpx:name"/> > > and I added a new template: > <xsl:template match="gpx:name"> > <xsl:value-of select="."/> > </xsl:template> > > Keep doing that with all your placeholders, and > you'll end up with > your finished XSL transform document to use with all > your GPX files. > > Here's the stripped-down sample GPX data I was > using: > saved as borrego3.xml: > <?xml version="1.0" encoding="ISO-8859-1" > standalone="yes"?> > <?xml-stylesheet type="text/xsl" href="test.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:topografix="http://www.topografix.com/GPX/Private/TopoGrafix/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/Private/TopoGrafix/0/1 > http://www.topografix.com/GPX/Private/TopoGrafix/0/1/topografix.xsd"> > <name><![CDATA[Anza-Borrego State Park]]></name> > <desc><![CDATA[Most folks envision the desert as a > wasteland completely void of hospitable scenery and > lacking in varied topography, but the quintessential > picture of the Borrego Desert is a California Palm > Oasis with the costal mountain range as backdrop. > These palm oases are the object of a popular > activity, called "oasis bagging." You drive for > miles on jeep trails up arroyos and washes, get out > and hike up canyons, then walk around to find the > perfect location to photograph these desert > rarities. Download this GPS Map to help you locate > many of the Palm Oases and other points fo interest > in === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
Helen+CastellarPelster.com on Thu Apr 25 06:55:51 2002 (link), replying to msg
--- In gpsxml+y..., "davewissenbach" <davewissenbach+y...> wrote: > --- In gpsxml+y..., "gps_maps" <gps_maps+y...> wrote: > > It would be a cruel world without cordless screwdrivers, ATM > > machines, and wysiwyg HTML editors. What do you use to edit your > > XML? Please dont' tell me "notebook"! > > , Doug > > I rarely, if ever, edit .gpx files directly. But when I do, I use > wordpad to edit raw text. (I also ride a bicycle to work, every day, > rain or shine, cold or hot.) > > You might visit > > http://www.xslt.com > > for a listing of stylesheet editors to transform xml documents. (I > even saw a stylesheet debugger there, visual XSTL). I tend to be > adverse to expensive new tools, although I do own a cordless > screwdriver! Since I *love* expensve new tools, I do have XMLSpy (www.xmlspy.com), and use it a good deal. However, I do walk to work, which gives you the idea that I use notepad or vi at least half the time for XML editing. Here are my thoughts on XMLSpy: 1.) It has very nice tools that can help you understand new schemas, such as a schema documentation generator and a handy feature called "Generate Sample XML". 2.) You get all the convenience of clicking on a button to check for well-formedness (is it legal XML?) and for validation (does it adhere to the schema?) 3.) It has many, many other features that you may never need to use. For example, it has a whole setup whereby you can define a "form" for editing a particular type of XML (say GPSXML...) and then an end-user can edit that XML via your form and the XMLSpy "Document Editor." 4.) The XMLSpy Suite (includes everything, including the form and document editing described above) runs $400. The XMLSpy IDE only runs $200 - this is the license that I bought. That being said, unless you are designing schemas or working with new schemas often, I think that XMLSpy is overkill for just editing xml files. Whew... posting this had made me think that I should consider finding a tool "lighter" than XMLSpy, but "heftier" than notepad. OK, I have a team member working on editing some XML files today, I will have her try Xeena (http://www.alphaworks.ibm.com/tech/xeena) and report back! Cheers, Helen
egroups+topografix.com on Thu May 09 08:51:38 2002 (link), replying to msg
Hello GPX-ers, Since there hasn't been much GPX discussion lately, I thought I'd pass this on. Any suggestions for her? On a more serious note, any suggestions for GPX 1.1? Any progress on new GPX apps? I received this GPX query in this morning's email. For those of you outside the US, GPX is a brand of cheap electronics sold at Kmart and other stores. It's also an XML data format, but apparently she missed that part of the webpage... Hello I just recently purchased a GPX cd player, that played wonderful music from radio to the cds the sound was beautiful. I have only used it 6 times (I only have one cd so far) sinced I purchased it and lately the radio is playing but not the cd player it said it can't detect it, that there is no cd in there. The purpose for buying the brand GPX was so that i could listen to music. This has made me very upset, that your cd does not own up to the quality that you supposedli offered. Please contact my ragarding this at name_removed_to_protect_the_ignorant+aol.com -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
robertlipe+usa.net on Thu May 09 09:32:09 2002 (link), replying to msg
Dan Foster wrote: > Any suggestions for her? None that would be appropriate to share. :-) > any suggestions for GPX 1.1? I've generally found GPX 1.0 to be expressive enough. I don't know if it's 1.1 material, but I've found it a bit clumsy that there are no guidelines for <sym>. Something as simple as "park" may be spelled differently in the icon maps of various receivers and it's hard to do a fuzzy match to get the mappings sane to go to a variety of targets. "Red Buoy" may be expressible to one target but have to be truncated to "Buoy" on another. I've mentioned it before, but I think that nailing down the verbiage on <time> would be helpful, too. The 'T' and 'Z' in the example are unspecified. Additionally, I don't find the description of <number> to be adequate. It's also not obvious (nor do I see it explained) why the file format differentiates tracks and routes nor why trkpt, rtept, and waypt look to overlap 100%. Perhaps a few paragraphs of prose would help developers like me choose the "right" tags for various data. If it's not in the spec, that's fine; just point us to it. > Any progress on new GPX apps? I have two POSIX-ish programs in the oven that'll read or write GPX. Both validate OK and are just waiting me to complete the "working" part of the code. A) I have a waypoint (and later, route) converting program. It slurps up waypoints from one or more input files (magellan mapsend, gpsman, gpsutil, magellan serial protocol, gpx, geocaching .loc, etc.) and write them to one of the above. (Sidebar to Dan, are the file formats for Easy/Expert published? Is this is a road I should go down at all?) I used libexpat to parse the XML. Works under Linux, OpenServer, and OpenUNIX. B) I have another program in the works that I can't talk as much about (it's not mine; I'm just enhancing someone else's) that I've made emit GPX as a way of hooking it up to (A) above so I can get waypoints into my magellan. Developer quality source copies of (A) are available for the asking but I'm not ready to unleash end-users onto it. Happy travels. RJL
egroups+topografix.com on Thu May 09 10:56:32 2002 (link), replying to msg
Hello, I recently added cut/copy/paste support to EasyGPS and ExpertGPS, and decided to implement it with GPX. You can now copy waypoints, routes, or tracks out of EasyGPS and paste valid GPX data into any text editor, or into a form on a webpage (like Kevin's GPX->Ozi converter). You can also paste GPX data directly into EasyGPS to add the GPS data to the file. Drag and drop between apps works as well. For Windows programmers who might be interested: I'm writing the data to the clipboard as CF_TEXT and using delayed rendering. Beta versions are available at: http://www.easygps.com/beta.asp http://www.expertgps.com/beta.asp The beta builds have one major bug - they won't open the XML files created by geocaching.com. Corrected builds will be posted by Saturday at the above URLs. I'll be travelling during the next two months and won't be contributing much to the discussion until late June. Enjoy your break from me! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
lupitacox+yahoo.com on Tue May 21 06:59:10 2002 (link)
They're almost done... Doug Cox
davewissenbach+yahoo.com on Fri May 31 06:04:17 2002 (link)
I've got a Alpha version of terrain visualization added to Wissenbach Map. The program reads 7 1/2 minute, 30 Meter DEM files into memory and then renders triangles using OpenGL. Tracks, but not waypoints yet, are displayed over the terrain. This program is based on a viewer which I wrote for a graduate-level OpenGL programming class which I took by satellite link from F.S. Hill at the University of Massachusetts several years ago. I'll publish the source code after I make the program a bit more robust and add the GPL headers. See http://www.cableone.net/cdwissenbach/map.html for a screen shot and setup program.
donreith+rogers.com on Mon Jun 03 12:50:53 2002 (link)
Hi, I'm new to this list. I'm a happy ExpertGPS user but want to be able to exchange .gpx data with Microsoft MapPoint. I haven't found anything to do this yet in my web travels so I've put this project onto my programming to-do list. Before I start on this thing, which will probably be a add-in for MapPoint, I thought I would check to see if anyone is aware of an existing or soon-to-be existing solution for gpx <-> MapPoint data exchange. I've checked out some of the MapPoint communities ( <http://www.mp2kmag.com> www.mp2kmag.com, <http://www.directionsmag.com> www.directionsmag.com) but gps, let alone gpx, doesn't have a lot of visibility with MapPoint users. I guess there is a lot of people using it to figure out where to build the next Taco Bell or McDonalds.. Another item on my list is to add online browsing of the .gpx files that I have posted on my website, building on the cool samples Dan has on his site. Its been a good way to get up to speed on XSL, another item that's been on my to-do list for a long time... Don Reith http://homepage.mac.com/donreith ------=_NextPart_000_002F_01C20B16.6FB341C0
jeremy+groundspeak.com on Mon Jun 03 18:24:37 2002 (link), replying to msg
I've played with the com objects in MapPoint to generate maps on the Geocaching.com site. The com objects are horribly enabled, most likely due to M$ desire to cripple the application so people will use their new .NET solution. Probably the best bet would be to have a conversion tool from GPX to MapPoint files. Jeremy -----Original Message----- From: Don Reith [mailto:donreith+rogers.com] Sent: Monday, June 03, 2002 12:50 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] MapPoint & .gpx Hi, I'm new to this list. I'm a happy ExpertGPS user but want to be able to exchange .gpx data with Microsoft MapPoint. I haven't found anything to do this yet in my web travels so I've put this project onto my programming to-do list. Before I start on this thing, which will probably be a add-in for MapPoint, I thought I would check to see if anyone is aware of an existing or soon-to-be existing solution for gpx <-> MapPoint data exchange. I've checked out some of the MapPoint communities ( <http://www.mp2kmag.com> www.mp2kmag.com, <http://www.directionsmag.com> www.directionsmag.com) but gps, let alone gpx, doesn't have a lot of visibility with MapPoint users. I guess there is a lot of people using it to figure out where to build the next Taco Bell or McDonalds.. Another item on my list is to add online browsing of the .gpx files that I have posted on my website, building on the cool samples Dan has on his site. Its been a good way to get up to speed on XSL, another item that's been on my to-do list for a long time... Don Reith http://homepage.mac.com/donreith To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. ------=_NextPart_000_020B_01C20B2B.E8A54640
robertlipe+usa.net on Mon Jun 03 18:52:23 2002 (link), replying to msg
Jeremy Irish wrote: > Probably the best bet would be to have a conversion tool from GPX > to MapPoint files. I have a program in progress that reads and writes waypoints and routes in arbitrary formats. GPX is one of the formats. I don't use (or honestly, care much about) MapPoint but if anyone could provide me with the file format documentation, a few sample files to work with, and so on I'd take a stab at adding that back-end and sharing the code or work with someone on adding such a back-end. If the file format is at all sensible, it's probably under a hundred lines of "real" code to slot it in. RJL
blalor+yahoo.f6bdbf+ithacabands.org on Mon Jun 03 18:57:13 2002 (link), replying to msg
On Mon, 3 Jun 2002, Robert Lipe wrote:
> I have a program in progress that reads and writes waypoints and routes
> in arbitrary formats.� GPX is one of the formats.� I don't use (or
Will you be able to handle the MapSource formats?
--
Brian Lalor | http://introducingthelalors.org/
blalor+ithacabands.org (email) | blalor+jabber.ithacabands.org (jabber)
N33�27.369' W111�56.304' (Earth)
jeremy+groundspeak.com on Mon Jun 03 19:05:51 2002 (link), replying to msg
You can actually import all kinds of formats into MapPoint. Unless you specifically want to generate maps (or have some automated tool), there's no real point in working on something. Comma delimited works fine. Geobuddy.com is one such tool that does it already with the old .LOC format we came up with. I know he's planning to upgrade it to support GPX. Jeremy -----Original Message----- From: Robert Lipe [mailto:robertlipe+usa.net] Sent: Monday, June 03, 2002 6:52 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] MapPoint & .gpx Jeremy Irish wrote: > Probably the best bet would be to have a conversion tool from GPX > to MapPoint files. I have a program in progress that reads and writes waypoints and routes in arbitrary formats. GPX is one of the formats. I don't use (or honestly, care much about) MapPoint but if anyone could provide me with the file format documentation, a few sample files to work with, and so on I'd take a stab at adding that back-end and sharing the code or work with someone on adding such a back-end. If the file format is at all sensible, it's probably under a hundred lines of "real" code to slot it in. RJL 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/
robertlipe+usa.net on Mon Jun 03 19:09:33 2002 (link), replying to msg
Brian Lalor wrote: > > On Mon, 3 Jun 2002, Robert Lipe wrote: > > I have a program in progress that reads and writes waypoints and > routes > > in arbitrary formats. GPX is one of the formats. I don't use (or > Will you be able to handle the MapSource formats? Just a few hours ago, someone handed me a MapSource file. I couldn't find any documentation on the file format used and there were some ambiguities in the sample file I got but it looked pretty straightforward. So I sketched in the code and am awaiting feedback from the requester to see of MapSource will slurp up the results. It doesn't read the file yet, but it writes them. 84 lines of C. I have a copy of mapsource on the way, but if you know of authoritative documentation on the format that would greatly help that cause. RJL
robertlipe+usa.net on Mon Jun 03 19:15:10 2002 (link), replying to msg
Jeremy Irish wrote: > You can actually import all kinds of formats into MapPoint. Unless > you specifically want to generate maps (or have some automated > tool), there's no real point in working on something. Comma Automatibilty is a specific goal of my program. It reads and writes files as directed via command line. No UI. > Geobuddy.com is one such tool that does it already with the old .LOC It's not automatable, not cross-platform, and the author wouldn't make source available. But it surely does solve some problems for some people. Since I now recognize your name, I'll mention that my program reads and writes the strain of waypointing XML used on your site, too. :-) RJL
donreith+rogers.com on Wed Jun 05 15:51:56 2002 (link), replying to msg
I don't agree with the "horribly enabled" comment. Not that I'm a Microsoft cheerleader but MapPoint's object model, which has been updated for MapPoint 2002 by the way, is reasonably robust for what and doesn't get in the way for what I want to accomplish. The objects it exposes make sense if you are familiar with MapPoint, and it is relatively easy to use. I don't see any crippling there. The MapPoint web service, their .NET version of MapPoint, is also kinda interesting as well, something that I'm going to check out after this project. From a modern web architecture standpoint it makes sense; financially though it may be a different story. Besides, if you have a choice between using an exposed and supported API that can get the job done, versus hacking into a private file format, a format that is likely to change in subsequent releases of the software, the pragmatic side of me thinks this is a no-brainer. Also, by pluging into the MapPoint UI you avoid having to go through a separate utility everytime you want to exchange data... Don --- In gpsxml+y..., "Jeremy Irish" <jeremy+g...> wrote: > I've played with the com objects in MapPoint to generate maps on the > Geocaching.com site. The com objects are horribly enabled, most likely > due to M$ desire to cripple the application so people will use their new > .NET solution. Probably the best bet would be to have a conversion tool > from GPX to MapPoint files. > > Jeremy
jeremy+groundspeak.com on Wed Jun 05 16:39:23 2002 (link), replying to msg
I'm curious. How much have you worked with the API? I'm currently using 2002. Try to: 1. Save a map to a filename (e.g. c:\mymap.jpg) 2. Look up an address, output lat/lon coordinates. 3. Look up and save 150 maps If you have worked with the API, give me an idea what you've done with your application and MapPoint. From my experience it has been horribly crippled. It's probably pretty easy to prove me wrong. Jeremy -----Original Message----- From: donreith [mailto:donreith+rogers.com] I don't agree with the "horribly enabled" comment. Not that I'm a Microsoft cheerleader but MapPoint's object model, which has been updated for MapPoint 2002 by the way, is reasonably robust for what and doesn't get in the way for what I want to accomplish. The objects it exposes make sense if you are familiar with MapPoint, and it is relatively easy to use. I don't see any crippling there.
donreith+rogers.com on Thu Jun 06 15:20:57 2002 (link), replying to msg
Well, as we've been doing different things we may both be right of our assessment of MapPoint's api. So far it has done what I've needed but we can't say the same for you :-). The outputting of lat/long is a headache. Apparantly MS cannot provide that functionality because of a licensing issue with the map data they use, or so I understand. Sounds a bit strange to me. However, there is a workaround that is documented here: http://www.mp2kmag.com/articles.asp?ArticleID=13 I haven't had to save maps to a file so I haven't looked into that. The absence of that functionality doesn't totally surprise me, as once you can do that you can more or less (mostly less, since its not a real server) use MapPoint to generate maps over the web, something MS would probably not be too happy about. The .NET version probably deals with this but I haven't looked into the cost/licensing of that version. I'm not optimistic about how accessible it will be for casual application use such as this. For what I want to do in this project the api provides what is needed: - convert waypoints into pushpins (no problem). - create a route in MapPoint out of the track/route data in the gpx problem (no problem), or perhaps just draw the route using the drawing tools in MP (haven't decided). One thing I am unsure of is how MP will react to a route with hundreds of waypoints. Don --- In gpsxml+y..., "Jeremy Irish" <jeremy+g...> wrote: > I'm curious. How much have you worked with the API? I'm currently using > 2002. Try to: > > 1. Save a map to a filename (e.g. c:\mymap.jpg) > 2. Look up an address, output lat/lon coordinates. > 3. Look up and save 150 maps > > If you have worked with the API, give me an idea what you've done with > your application and MapPoint. From my experience it has been horribly > crippled. It's probably pretty easy to prove me wrong. > > Jeremy
donreith+rogers.com on Tue Jun 11 13:10:36 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello Kevin, > > Wednesday, February 06, 2002, 4:57:42 AM, you wrote: > > KR> Strongly disagree > > KR> I use XPATH extensively to manage waypoints. Most of my XNL comes from > KR> a native XML DB so I'm dealing with XML only not a prog specific class > KR> that is loaded via XML. > > KR> Sequencing is used to sort and re-order waypoints as well as routes and > KR> tracks trather than manipulating the timestamp and modifying the base > KR> data. > > KR> For example: > > KR> <..... Sort-by='trk[seq] desc'> > > KR> If I want to re-order a planned route all I need do is change the > KR> sequence and viola. Leaving the orginal track info intact so point to > KR> point time caculations can still be made based on the orginal sequence. > > KR> Seq - I'll be using it regardless, remember those of us using XSLT and > KR> XML:DBs please > > KR> Kevin > > Does that mean you'll be producing XML files with out-of-order > sequences? > > Do you have any reply to my earlier statement that I can't correctly > parse an out-of-order sequence? (I assume this is the case for > other apps as well.) > > Since <seq> is optional, what do you do about all the files we're > producing without <seq>? > > <seq> isn't defined for waypoints. I can see the usefulness of > sorting a list of waypoints by various criteria (elevation, > timestamp). Other than reversing a route, why would you want to > sort a route/track? > > Can you make a small example GPX and XSLT file to demonstrate how > you'd use <seq>? > > -- > Dan Foster Yeah, this is an ancient thread, but I didn't see a response, so here goes. I'm having a somewhat related problem right now: using XSLT I want to display the starting & ending waypoint of a route/track on the generated web page, something that is not too unreasonable. Having a sequence # would let me find these track elements easily using a filter or xsl:key. I'm currently thumbing through my xml references for an alternate solution to this, so speak up if you have any ideas. Don
donreith+rogers.com on Tue Jun 11 13:21:56 2002 (link), replying to msg
--- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote: > Brian Lalor wrote: > > > > On Mon, 3 Jun 2002, Robert Lipe wrote: > > > I have a program in progress that reads and writes waypoints and > > routes > > > in arbitrary formats. GPX is one of the formats. I don't use (or > > Will you be able to handle the MapSource formats? > > Just a few hours ago, someone handed me a MapSource file. I couldn't > find any documentation on the file format used and there were > some ambiguities in the sample file I got but it looked pretty > straightforward. So I sketched in the code and am awaiting feedback > from the requester to see of MapSource will slurp up the results. It > doesn't read the file yet, but it writes them. 84 lines of C. > > I have a copy of mapsource on the way, but if you know of authoritative > documentation on the format that would greatly help that cause. > > > RJL I would be interested to see how it deals with routes, as I believe that MapPoint only saves the starting & end point of the route. The actual route legs are calculated when the MapPoint file is opened. Of course, the actual legs are also available using the API... Don
donreith+rogers.com on Tue Jun 11 16:10:24 2002 (link), replying to msg
> Yeah, this is an ancient thread, but I didn't see a response, so > here goes. > > I'm having a somewhat related problem right now: using XSLT I want > to display the starting & ending waypoint of a route/track on the > generated web page, something that is not too unreasonable. Having a > sequence # would let me find these track elements easily using a > filter or xsl:key. I'm currently thumbing through my xml references > for an alternate solution to this, so speak up if you have any ideas. > > Don Ignore my post. A little digging through my XSL reference unearthed a way to index into a element list. Don
donreith+rogers.com on Tue Jun 11 19:09:08 2002 (link)
Attached to this message is a small .xsl file that demonstrates how to
access the first and last waypoint for each track in the .gpx file. It
also shows conditional output, sorting, and use of variables (more on
that below) in case you haven't played with those features.
It turns out the it was pretty simple to do reference specific trkpt
nodes, although I'm still having to do something that doesn't seem quite
right.
Referencing the first trackpoint is easy:
<xsl:apply-templates select="gpx:trkpt[1]"\>
Getting the last trackpoint should also be easy:
<xsl:apply-templates select="gpx:trkpt[count(gpx:trkpt)]"/>
but I couldn't get this to work. However, if I do the count and put it
into a variable, then reference the variable, I get the desired result:
<xsl:variable name="numtrkpt" select="count(gpx:trkpt)"/>
<xsl:apply-templates select="gpx:trkpt[$numtrkpt]"/>
Perhaps the MSXML parser doesn't like a function inside the [ ]?
Don
------=_NextPart_001_005F_01C21194.99F075A0
blalor+yahoo.f6bdbf+ithacabands.org on Tue Jun 11 20:37:20 2002 (link), replying to msg
On Tue, 11 Jun 2002, Don Reith wrote:
> Referencing the first trackpoint is easy:
>
> <xsl:apply-templates select="gpx:trkpt[1]"\>
>
> Getting the last trackpoint should also be easy:
>
> <xsl:apply-templates select="gpx:trkpt[count(gpx:trkpt)]"/>
>
> but I couldn't get this to work. However, if I do the count and put it
Hrm. I've never worked with XSL before, so forgive my naivety. Wouldn't
the *first* element in a list be index zero, not one? By that same
rational, count(gpx:trkpt) would be one *past* the last element in the
list.
--
Brian Lalor | http://introducingthelalors.org/
blalor+ithacabands.org (email) | blalor+jabber.ithacabands.org (jabber)
N33�27.369' W111�56.304' (Earth)
donreith+rogers.com on Wed Jun 12 04:23:08 2002 (link), replying to msg
> Hrm. I've never worked with XSL before, so forgive my naivety. Wouldn't > the *first* element in a list be index zero, not one? By that same > rational, count(gpx:trkpt) would be one *past* the last element in the > list. > > -- > Brian Lalor | http://introducingthelalors.org/ > blalor+i... (email) | blalor+j... (jabber) > N33�27.369' W111�56.304' (Earth) That's what I would have expected as well, but XSL ain't C. In XSL functions that operate on node sets, the first node in a list has position *1*. Don
robertlipe+usa.net on Wed Jun 12 09:47:21 2002 (link), replying to msg
donreith wrote: > --- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote: > > > Brian Lalor wrote: > > > > > On Mon, 3 Jun 2002, Robert Lipe wrote: > > > > > > > I have a program in progress that reads and writes > > > > waypoints and routes in arbitrary formats. GPX is one of > > > > the formats. I don't use (or > > > > > > Will you be able to handle the MapSource formats? > > > > Just a few hours ago, someone handed me a MapSource file. I > > couldn't find any documentation on the file format used and > > there were some ambiguities in the sample file I got but it > > looked pretty straightforward. So I sketched in the code and am > > awaiting feedback from the requester to see of MapSource will > > slurp up the results. It doesn't read the file yet, but it > > writes them. 84 lines of C. > > > > I have a copy of mapsource on the way, but if you know of > > authoritative documentation on the format that would greatly help > > that cause. > > I would be interested to see how it deals with routes, as I > believe that MapPoint only saves the starting & end point of the > route. The actual route legs are calculated when the MapPoint file > is opened. Of course, the actual legs are also available using I think we have too many programs called mapSOMETHING. :-) Brian asked about Garmin MapSource format, which I've not accomplished (sorta) via providing PCX. (I'm still looking for documentation on the "reaL' mapsend .mps format.) Your question seems to be about MapPoint which I know nothing about. RJL
blalor+yahoo.f6bdbf+ithacabands.org on Thu Jun 13 10:45:36 2002 (link)
I've whacked together a quick and dirty package[1] for reading and writing
GPX[2] files in python. It is not feature complete and will allow you to
create GPX documents that will not validate. The interface is clunky at
best, but I believe I've got the basic data structures down. I encourage
you to take a look at it and add to it as you see fit! Download it and
take a look!
[1] http://ithacabands.org/~blalor/GPX/
[2] http://www.topografix.com/gpx.asp
Thanks,
B
--
Brian Lalor | http://introducingthelalors.org/
blalor+ithacabands.org (email) | blalor+jabber.ithacabands.org (jabber)
N33�27.369' W111�56.304' (Earth)
lemire1+attbi.com on Mon Jun 24 19:17:07 2002 (link)
Does anyone know if there exists an open source C++ class available that would take an XML file (ideally using a standard like GPX) and upload it to a Garmin unit? I wrote a C++ application that parses HTML output from a mapping web site like Maps On Us. You build a route on the web site and save the source code which has lattitude and longitude embedded for each waypoint in the route. My app takes the HTML and constructs a csv file, passing it to Ron Henderson's G7toW app which uploads it to a Garmin unit. I'm trying to come up with a more elegant solution, including dynamic web transactions, and at the same time I'd like to take advantage of XML standards in whatever form they are available. XML would seem to make sense, especially if source code is already available to do the translation between XML and the various proprietary interface formats used by GPS units. Code developers could write any number of applications like mine for various purposes that generate the same XML code, using these open source XML->GPS interface classes. The only things available I can find are EasyGps and ExpertGps which could read in the XML files but this would mean using a two-step process. I'd prefer a more seamless approach by including the XML->GPS interface class directly in my program. There is also the Chaeron Java-based classes (ChaeronGPS) which would be exactly what I want (http://www.chaeron.com/gps.html#JavaLibrary), but I'm looking for something in C or C++ and think I'd prefer to use GPX instead of GPSml which is what ChaeronGPS uses. Does anyone have any suggesting? Thanks very much!! Mark Lemire (lemire1+attbi.com)
davewissenbach+yahoo.com on Wed Jun 26 11:28:39 2002 (link), replying to msg
There isn't something packaged exactly the way that you would like it. But as a starting point you might look at the source code for my Mapping program which does what you want, more or less. You'll just need to discard the viewing code and keep the document serialization code and GPS download. This works for Garmin eTrex, and probably Garmin eMap, but you'll need to modify this further if you're going to use older Garmin units. http://www.cableone.net/cdwissenbach/map.html describes the program. The source code for this MFC-based application is zipped together as http://www.cableone.net/cdwissenbach/MapSource.zip --- lemire1 <lemire1+attbi.com> wrote: > Does anyone know if there exists an open source C++ > class available that > would take an XML file (ideally using a standard > like GPX) and upload it to > a Garmin unit? > > I wrote a C++ application that parses HTML output > from a mapping web site > like Maps On Us. You build a route on the web site > and save the source code > which has lattitude and longitude embedded for each > waypoint in the route. > My app takes the HTML and constructs a csv file, > passing it to Ron > Henderson's G7toW app which uploads it to a Garmin > unit. > > I'm trying to come up with a more elegant solution, > including dynamic web > transactions, and at the same time I'd like to take > advantage of XML > standards in whatever form they are available. XML > would seem to make sense, > especially if source code is already available to do > the translation between > XML and the various proprietary interface formats > used by GPS units. Code > developers could write any number of applications > like mine for various > purposes that generate the same XML code, using > these open source XML->GPS > interface classes. > > The only things available I can find are EasyGps and > ExpertGps which could > read in the XML files but this would mean using a > two-step process. I'd > prefer a more seamless approach by including the > XML->GPS interface class > directly in my program. > > There is also the Chaeron Java-based classes > (ChaeronGPS) which would be > exactly what I want > (http://www.chaeron.com/gps.html#JavaLibrary), but > I'm > looking for something in C or C++ and think I'd > prefer to use GPX instead of > GPSml which is what ChaeronGPS uses. > > Does anyone have any suggesting? > > Thanks very much!! > > Mark Lemire (lemire1+attbi.com) > > __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
amandapaixaom+yahoo.com.br on Sun Jun 30 10:44:45 2002 (link)
http://www.geocities.com/nineamf/index.html --------------------------------- Yahoo! Encontros - O lugar certo para encontrar a sua alma g?a. --0-25811992-1025459084=:14276
amandapaixaom+yahoo.com.br on Sun Jul 21 09:28:38 2002 (link)
http://www.geocities.com/zemaplata/index.html --------------------------------- Yahoo! Encontros - O lugar certo para encontrar a sua alma g?a. --0-1342488013-1027268917=:20500
robertlipe+usa.net on Mon Jul 29 21:46:44 2002 (link)
I'll give this group a little head start on a program I'm releasing in the hopes that a group of programmers will be kinder to their own. :-) GPS Babel is a free (in both senses) utlity to read and write waypoints in a variety of forms. GPX input and output works well. Other backends include Magellan serial protocol, Geocaching.com *.loc, GPSMan, Garmin PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau Tiger, and CSV for S&A 9. It works on POSIXy operating systems and is ISO C. I've run it on OpenUNIX 8, Solaris 8, UnixWare 7, OpenServer 5, Linux, and Cygwin. (Non-Intel processors choke on Magellan's Mapsend files becuase of silliness involving FP formats.) Ports to OSes that start with an "M" are welcome as long as they don't gunk up the code too much. Other contributions or comments are similarly welcome. The output validates OK, and I've successfully interchanged data with EasyGPS, demos of ExpertGPS. The code seems solid enough and I've used it to process a few thousand waypoints of differing kinds. Things like doc, web pages, and such are sort of shaky. That's the only reason for the downgraded "sub 1.0" version number. It has a temporary home at: http://robertlipe.0catch.com/gpsbabel/index.html I'll move it somewhere else within a few days. RJL
davewissenbach+yahoo.com on Tue Jul 30 05:57:03 2002 (link), replying to msg
This is great. I downloaded this and noticed that you've published under the GPL. Maybe this fall I'll attempt to use this on Windows-- unless someone else does first. I don't have much spare time right now, or rather, I'm busy hiking and bicycling and don't spend too much time indoors. One format that would be very useful is for National Geographic Topo. This program is being aggressively marketed and I think that we'll see output from this program everywhere. --- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote: > > I'll give this group a little head start on a program I'm releasing in > the hopes that a group of programmers will be kinder to their own. :-) > > GPS Babel is a free (in both senses) utlity to read and write waypoints > in a variety of forms. GPX input and output works well. Other backends > include Magellan serial protocol, Geocaching.com *.loc, GPSMan, Garmin > PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau Tiger, and > CSV for S&A 9. > > It works on POSIXy operating systems and is ISO C. I've run it on > OpenUNIX 8, Solaris 8, UnixWare 7, OpenServer 5, Linux, and Cygwin. > (Non-Intel processors choke on Magellan's Mapsend files becuase of > silliness involving FP formats.) Ports to OSes that start with an "M" > are welcome as long as they don't gunk up the code too much. Other > contributions or comments are similarly welcome. The output validates > OK, and I've successfully interchanged data with EasyGPS, demos of > ExpertGPS. > > The code seems solid enough and I've used it to process a few thousand > waypoints of differing kinds. Things like doc, web pages, and such are > sort of shaky. That's the only reason for the downgraded "sub 1.0" > version number. > > It has a temporary home at: > > http://robertlipe.0catch.com/gpsbabel/index.html > > I'll move it somewhere else within a few days. > > RJL
robertlipe+usa.net on Tue Jul 30 07:42:19 2002 (link), replying to msg
davewissenbach wrote: > This is great. Thank you. > I downloaded this and noticed that you've published under the GPL. Since the problem i was trying to solve would have been less of a problem if the various programs were Free Software, it would have been wrong for me to solve the problem with anything else. I thought it would be of special interest to this groups since it includes an example of using expat to process GPX and it makes a reasonable "stepping stone" since I think most of us are using GPX AND something else. > Maybe this fall I'll attempt to use this on Windows-- > unless someone else does first. I verified it builds and passes the testsuite under Cygwin but don't know if that really is an an "acceptable" approach for someone that actually likes to use Windows. > One format that would be very useful is for National Geographic > Topo. This program is being aggressively marketed and I think that > we'll see output from this program everywhere. Is the file format documented? If it's a sensible format at all, a backend can probably be slotted in in about an hour. RJL
polt+snaptek.com on Tue Jul 30 10:53:54 2002 (link)
i have all ready reversed engineered the TOPO format and garmins MAPSOURCE file formats. i use those programs the most myself and wanted to be able to use them for my geocaching site. TOPO actually uses bilinear interpolation which was quite a pain... but i got a little help from one of the engineers in the right direction. if you want to take a look at what my code outputs get and idea take a look at my site http://www.azgeocaching.com if ya would like i could help contribute the code to the project... it is in php right now... jason poulter davewissenbach wrote: > This is great. I downloaded this and noticed that you've published > under the GPL. Maybe this fall I'll attempt to use this on Windows-- > unless someone else does first. I don't have much spare time right > now, or rather, I'm busy hiking and bicycling and don't spend too > much time indoors. > > One format that would be very useful is for National Geographic > Topo. This program is being aggressively marketed and I think that > we'll see output from this program everywhere. > > > --- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote: > > > > I'll give this group a little head start on a program I'm > releasing in > > the hopes that a group of programmers will be kinder to their > own. :-) > > > > GPS Babel is a free (in both senses) utlity to read and write > waypoints > > in a variety of forms. GPX input and output works well. Other > backends > > include Magellan serial protocol, Geocaching.com *.loc, GPSMan, > Garmin > > PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau > Tiger, and > > CSV for S&A 9. > > > > It works on POSIXy operating systems and is ISO C. I've run it on > > OpenUNIX 8, Solaris 8, UnixWare 7, OpenServer 5, Linux, and Cygwin. > > (Non-Intel processors choke on Magellan's Mapsend files becuase of > > silliness involving FP formats.) Ports to OSes that start with > an "M" > > are welcome as long as they don't gunk up the code too much. Other > > contributions or comments are similarly welcome. The output > validates > > OK, and I've successfully interchanged data with EasyGPS, demos of > > ExpertGPS. > > > > The code seems solid enough and I've used it to process a few > thousand > > waypoints of differing kinds. Things like doc, web pages, and > such are > > sort of shaky. That's the only reason for the downgraded "sub 1.0" > > version number. > > > > It has a temporary home at: > > > > http://robertlipe.0catch.com/gpsbabel/index.html > > > > I'll move it somewhere else within a few days. > > > > RJL > > > *Yahoo! Groups Sponsor* > Click here to visit our exclusive feature of ACUVUE2 Colours at > LensExpress.com! > Click here to find your contact lenses! > > <http://rd.yahoo.com/M=225674.2075965.3644786.1829184/D=egroupweb/S=1706030390:HM/A=1153156/R=0/*http://www.lensexpress.com/tracker/trackclick.aspx?Page=ACUVUE%202%20Colors&AffUrl=273&AffCode=14> > > > > 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 > <http://docs.yahoo.com/info/terms/>.
joel+coastaloutdoors.com on Tue Jul 30 11:17:44 2002 (link)
Jason:
I could really use that code in php. I'm trying to put together a page where folks can input their waypoints and download their waypoints now. That input/output should be converted to EasyGPS so they can use Dan's program to upload/download to their GPS. That would sure save a lot of time.
Thanks in advance,
Joel E. Williams, Jr.
www.coastaloutdoors.com
----- Original Message -----
From: Jason Poulter
To: gpsxml+yahoogroups.com
Sent: Tuesday, July 30, 2002 1:53 PM
Subject: Re: [gpsxml] Re: ANN: a GPX reader/writer.
i have all ready reversed engineered the TOPO format and garmins
MAPSOURCE file formats. i use those programs the most myself and wanted
to be able to use them for my geocaching site.
TOPO actually uses bilinear interpolation which was quite a pain... but
i got a little help from one of the engineers in the right direction.
if you want to take a look at what my code outputs get and idea take a
look at my site http://www.azgeocaching.com
if ya would like i could help contribute the code to the project...
it is in php right now...
jason poulter
davewissenbach wrote:
> This is great. I downloaded this and noticed that you've published
> under the GPL. Maybe this fall I'll attempt to use this on Windows--
> unless someone else does first. I don't have much spare time right
> now, or rather, I'm busy hiking and bicycling and don't spend too
> much time indoors.
>
> One format that would be very useful is for National Geographic
> Topo. This program is being aggressively marketed and I think that
> we'll see output from this program everywhere.
>
>
> --- In gpsxml+y..., Robert Lipe <robertlipe+u...> wrote:
> >
> > I'll give this group a little head start on a program I'm
> releasing in
> > the hopes that a group of programmers will be kinder to their
> own. :-)
> >
> > GPS Babel is a free (in both senses) utlity to read and write
> waypoints
> > in a variety of forms. GPX input and output works well. Other
> backends
> > include Magellan serial protocol, Geocaching.com *.loc, GPSMan,
> Garmin
> > PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau
> Tiger, and
> > CSV for S&A 9.
> >
> > It works on POSIXy operating systems and is ISO C. I've run it on
> > OpenUNIX 8, Solaris 8, UnixWare 7, OpenServer 5, Linux, and Cygwin.
> > (Non-Intel processors choke on Magellan's Mapsend files becuase of
> > silliness involving FP formats.) Ports to OSes that start with
> an "M"
> > are welcome as long as they don't gunk up the code too much. Other
> > contributions or comments are similarly welcome. The output
> validates
> > OK, and I've successfully interchanged data with EasyGPS, demos of
> > ExpertGPS.
> >
> > The code seems solid enough and I've used it to process a few
> thousand
> > waypoints of differing kinds. Things like doc, web pages, and
> such are
> > sort of shaky. That's the only reason for the downgraded "sub 1.0"
> > version number.
> >
> > It has a temporary home at:
> >
> > http://robertlipe.0catch.com/gpsbabel/index.html
> >
> > I'll move it somewhere else within a few days.
> >
> > RJL
>
>
> *Yahoo! Groups Sponsor*
> Click here to visit our exclusive feature of ACUVUE2 Colours at
> LensExpress.com!
> Click here to find your contact lenses!
>
> <http://rd.yahoo.com/M=225674.2075965.3644786.1829184/D=egroupweb/S=1706030390:HM/A=1153156/R=0/*http://www.lensexpress.com/tracker/trackclick.aspx?Page=ACUVUE%202%20Colors&AffUrl=273&AffCode=14>
>
>
>
> 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
> <http://docs.yahoo.com/info/terms/>.
Yahoo! Groups Sponsor
ADVERTISEMENT
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.
------?extPart_000_0070_01C237D4.1181AA20
robertlipe+usa.net on Tue Jul 30 11:37:44 2002 (link), replying to msg
Jason Poulter wrote: > i have all ready reversed engineered the TOPO format and garmins > MAPSOURCE file formats. i use those programs the most myself and If you can provide doc or sample code (I can read most languages, but might need help with some details) I'd be very interested in Mapsource format. > look at my site [1]http://www.azgeocaching.com Seeet. > if ya would like i could help contribute the code to the project... > it is in php right now... Bring it on! I'll have this on Sourceforge in the next couple of days. RJL
murphy+enterprise.net on Wed Jul 31 00:27:29 2002 (link), replying to msg
This is just to let you folks know that there is now a Beta Test version of "GPS Utility" (4.10.e) which imports/exports GPX files at: http://www.gpsutility.co.uk/files/gpsu410e.zip You need to download this, unzip and manually install in the existing GPSU program installation directory - probably "C:/Program Files/GPS Utility" (so you will need to download and install the standard version first (4.04.3)). I have not yet implemented every field type, so there will be some transfer limitations. I have tested it against EasyGPS and Wissenbach Map and this seems to work OK, but there could be the odd bug lying around. However it should allow the interchange of some GPS data between GPX applications and the other file formats supported by GPSU. Please let me know by direct email of any problems/shortcomings etc. as I don't check the newsgroup that often. Cheers, Alan Murphy (author GPSU) http://www.gpsu.co.uk/ at approx N50�53.8' W001�23.2'
egroups+topografix.com on Wed Jul 31 07:12:24 2002 (link), replying to msg
Hello, Tuesday, July 30, 2002, 8:03:01 PM, Troy wrote: TH> I agree that TOPO! is an important format to support. I find topo files everywhere and rarely see anything else. The biggest challenge here is .tpo files as they're a proprietary binary format. TH> .tpg files aren't that tough, but if any of you have figured out how to convert routes from a .tpo file to .gpx, I'd love to hear about it. TH> Troy Let them know you want an XML file format for import/export: http://maps.nationalgeographic.com/ngmaps/contact.cfm?topocontact=yes I just wrote them a nice email asking them to support some form of XML for file interchange. If enough of their users write to them, they'll take notice. Take 5 minutes and send them a note. I've looked at the .tpo file format, and it's ugly. I suspect it changes from release to release, but don't have any proof of that. .tpg is the way to go, but apparently they've dropped support for .tpg in their new Topo!Sync program. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Jul 31 07:29:30 2002 (link), replying to msg
Hello, Tuesday, July 30, 2002, 1:53:28 PM, Jason wrote: JP> i have all ready reversed engineered the TOPO format and garmins JP> MAPSOURCE file formats. i use those programs the most myself and wanted JP> to be able to use them for my geocaching site. and then on Tuesday, July 30, 2002, 2:37:41 PM, Robert wrote: RL> If you can provide doc or sample code (I can read most languages, but RL> might need help with some details) I'd be very interested in Mapsource RL> format. Since there seem to be a number of us working on import/export of various file formats, and since we are working on many different platforms (Palm, Linux, Windows, Mac...) and in many different languages (PHP, ASP, C...) I'd like to join Robert in asking for a sharing of knowledge. Source code is good, but documentation of the file format is probably more useful since we've all got different programming requirements and backgrounds. I'd like to propose that we write up some quick descriptions of the file formats we know and put them up on the web "for the benefit of humanity". I can contribute Topo! .tpg and MapTech .mxf, and maybe some others. I'll offer to host some of the files on my website, but due to DMCA nonsense, I'd suggest that file formats with even the most basic of "encryption" be kept on servers outside the US. Any volunteers from saner nations? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
polt+snaptek.com on Wed Jul 31 12:31:28 2002 (link)
ya that sounds like a good idea... i will write up the file description for TOPO and MAPSOURCE.... Dan I did notice that your TOPO algorithm is a little bit off... you loose a couple of digits of precision in your conversion... with a little help from one of the engineers and National Geographic I was able to get my algorithm, to what i've tested, actually match theirs... havent heard any complaints from my users about it being bad either. so we might want to go with mine, or merge the two or something? Dan where should we send them? to your email? jason poulter Dan Foster wrote: > Hello, > > Tuesday, July 30, 2002, 1:53:28 PM, Jason wrote: > JP> i have all ready reversed engineered the TOPO format and garmins > JP> MAPSOURCE file formats. i use those programs the most myself and > wanted > JP> to be able to use them for my geocaching site. > > and then on Tuesday, July 30, 2002, 2:37:41 PM, Robert wrote: > RL> If you can provide doc or sample code (I can read most languages, but > RL> might need help with some details) I'd be very interested in Mapsource > RL> format. > > Since there seem to be a number of us working on import/export of > various file formats, and since we are working on many different > platforms (Palm, Linux, Windows, Mac...) and in many different languages > (PHP, ASP, C...) I'd like to join Robert in asking for a sharing of > knowledge. Source code is good, but documentation of the file format > is probably more useful since we've all got different programming > requirements and backgrounds. I'd like to propose that we write up > some quick descriptions of the file formats we know and put them up on > the web "for the benefit of humanity". I can contribute Topo! .tpg > and MapTech .mxf, and maybe some others. > > I'll offer to host some of the files on my website, but due to DMCA > nonsense, I'd suggest that file formats with even the most basic of > "encryption" be kept on servers outside the US. Any volunteers from > saner nations? > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+topografix.com > > > *Yahoo! Groups Sponsor* > ADVERTISEMENT > <http://rd.yahoo.com/M=231049.2206939.3660593.1971030/D=egroupweb/S=1706030390:HM/A=1175203/R=0/*http://www.gotomypc.com/u/tr/yh/grp/300_06/g22lp?Target=mm/g22lp.tmpl> > > > 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 > <http://docs.yahoo.com/info/terms/>.
egroups+topografix.com on Wed Jul 31 14:23:48 2002 (link), replying to msg
Hello Jason, Wednesday, July 31, 2002, 3:31:24 PM, you wrote: JP> ya that sounds like a good idea... i will write up the file description JP> for TOPO and MAPSOURCE.... JP> Dan I did notice that your TOPO algorithm is a little bit off... you JP> loose a couple of digits of precision in your conversion... with a JP> little help from one of the engineers and National Geographic I was able JP> to get my algorithm, to what i've tested, actually match theirs... JP> havent heard any complaints from my users about it being bad either. JP> so we might want to go with mine, or merge the two or something? I'll be interested to see how yours works. It's been a few years since I wrote mine, so perhaps it needs an update. JP> Dan where should we send them? to your email? You can send them to this email address: egroups+topografix.com Robert already sent me links to several formats - I'm quoting his email below. I'll throw together a webpage to hold all this sometime next week.
robertlipe+usa.net on Tue Aug 06 21:56:36 2002 (link), replying to msg
Robert Lipe wrote: > GPS Babel is a free (in both senses) utlity to read and write waypoints > in a variety of forms. GPX input and output works well. Other backends > include Magellan serial protocol, Geocaching.com *.loc, GPSMan, Garmin > PCX5 for Mapsource, Magellan Mapsend, gpsutil, Census Bureau Tiger, and > CSV for S&A 9. [ blah blah blah ] > It has a temporary home at: It now has a permanent home. (Well, as permanent as anything gets on the web.) It will disappear from the temporary location in coming days. Dan, please add GPSBabel at http://gpsbabel.sourceforge.net/ to the list of programs that read and write GPX. Enjoy. RJL
misbach+yahoo.com on Fri Aug 09 22:45:43 2002 (link)
GPS Users, I just created a new Yahoo group for the new Garmin Rino. If you have not heard or read about this new GPS device you are missing out. The Garmin Rino is the first GPS device to have a GMRS/FRS radio integrated into it. It also is the first GPS device to support the Peer-to-Peer Positioning, this patented technology makes it possible to transmit your location to a friend or family member. What really separates the Rino from the rest of the FRS herd is the ability to "beam" your exact location to another Rino user within a two-mile range using the FRS spectrum. Even if you don't have a Garmin Rino I think you will find this group useful and informative. To go to the website or subscribe to the new yahoo group use the information below. Website: http://groups.yahoo.com/group/garmin-rino To Subscribe: garmin-rino-subscribe+yahoogroups.com Thanks! Matt P.S. I've already got lots of links, files, pictures, calendar items, and polls at the new Yahoo group website. It's going to be a great group for all GPS users.
fouts+fogey.com on Sat Aug 10 14:00:33 2002 (link)
Background:
www.geocaching.com maintains a data base of geocaches. An entry in the data
base is sort of a waypoint, but with a lot of additional information. This
additional information includes such things as a description of the geocache
and logs people enter to describe their attempts to find the cache.
Members of www.geocaching.com can search the database using a feature called
"pocket query". In response to the query, the web site will email a reply
containing those entries that match the search criteria. The web site makes
information available in .loc files so that people can download it into GPS
receivers, and it also makes the additional information available as an
Ebook for people to download to PDAs. They are currently developing an
extension to GPX format to make this additional information available in an
XML format.
You can see an example of a preliminary version of the GPX/geocache
extension at http://www.geocaching.com/media/example.gpx
This extension is being discussed in the geocaching forum, and in the
discussion, two questions have come up that, in my opinion, are general to
the idea of extending GPX, so I thought I'd raise them in this forum.
The Questions:
1) If you examine the example file, you will see that all of the
geocaching.com extension are in a separate 'groundspeak' namespace. This
leads to what I hope will be the easy question: Should this be a recommended
practice for adding extensions to GPX?
I think this is a good thing because it reduces the likelihood of extension
name collision and makes it easier to track extensions back to their source
and to use multiple extension sets in the same GPX file.
I'm curious what other people think.
2) In response to some requests for additions to the extension, Jeremy Irish
is proposing adding some redundant information like lat/long to the
extension. I believe the reasoning has to do with how the xsd for the
extension will be built. (My apologies to Jeremy if I misunderstand.) His
comment in the forum was
Yes. I'll have an xsd available for it, I suspect. Which means I'll
probably have to add
redundant information like lat/lon so if the namespace is used alone,
the Groundspeak
format can be decoded and used.
from the point of view of a software purist, such redundant information is a
Bad Thing (r) but I don't know enough about XML to understand whether the
reasoning should apply here.
Anyway, the question here is: if a datum is an element of the base GPX
specification, should that element be duplicated in an extension?
My own opinion is that no, it shouldn't, because it's an opportunity for
having two watches and never knowing what time it is.
Marty
egroups+topografix.com on Mon Aug 12 04:59:59 2002 (link), replying to msg
Hello, Saturday, August 10, 2002, 5:05:54 PM, Marty wrote: M> Background: M> www.geocaching.com maintains a data base of geocaches. M> They are currently developing an M> extension to GPX format to make this additional information available in an M> XML format. M> You can see an example of a preliminary version of the GPX/geocache M> extension at http://www.geocaching.com/media/example.gpx M> This extension is being discussed in the geocaching forum, and in the M> discussion, two questions have come up that, in my opinion, are general to M> the idea of extending GPX, so I thought I'd raise them in this forum. M> The Questions: M> 1) If you examine the example file, you will see that all of the M> geocaching.com extension are in a separate 'groundspeak' namespace. This M> leads to what I hope will be the easy question: Should this be a recommended M> practice for adding extensions to GPX? Yes. This is the required practice for adding private extensions to GPX. I'm using topografix:foo for my private extensions, and Dave Wissenbach is using wissenbach:foo for his private extensions. As you noted, this prevents namespace collisions. If you've got a set of extensions that might be useful in other GPS applications, it's best to propose them here in the forum. If there's enough interest in getting them into GPX, they could become part of the public GPX format in a future version, or at least you may get a group of people interested in supporting that set of private extensions in their programs. An example of something that might be useful in the public standard or as a common private extension would be map calibration points. M> 2) In response to some requests for additions to the extension, Jeremy Irish M> is proposing adding some redundant information like lat/long to the M> extension. I believe the reasoning has to do with how the xsd for the M> extension will be built. (My apologies to Jeremy if I misunderstand.) His M> comment in the forum was M> Yes. I'll have an xsd available for it, I suspect. Which means I'll M> probably have to add M> redundant information like lat/lon so if the namespace is used alone, M> the Groundspeak M> format can be decoded and used. M> from the point of view of a software purist, such redundant information is a M> Bad Thing (r) but I don't know enough about XML to understand whether the M> reasoning should apply here. M> Anyway, the question here is: if a datum is an element of the base GPX M> specification, should that element be duplicated in an extension? M> My own opinion is that no, it shouldn't, because it's an opportunity for M> having two watches and never knowing what time it is. Again, you're correct. If it's in the public GPX standard, it doesn't need to (and shouldn't be) be duplicated elsewhere. The sample GPX file on the geocaching site isn't valid GPX yet. Jeremy needs to create a schema for his private groundspeak extensions, and reference it in the GPX file. Until it validates as a proper GPX file, it's not valid GPX. See http://www.topografix.com/gpx_validation.asp I know there are a number of geocachers on this list and using GPX-enabled software, and we're all looking forward to having the Geocaching Pocket Queries available in GPX format! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
steve+sprintmail.com on Mon Aug 12 15:58:34 2002 (link)
If anyone is interested, I have written a perl parser to convert EasyGPS xml files to G7toWIN csv files. I run the perl program under Activer Perl which can be downloaded from http://www.activeperl.com The perl program has been uploaded to the files section of this group on yahoogroups at http://groups.yahoo.com/group/gpsxml/files/ If this is not the kind of stuff for this group, let me know and I'll remove it. Steve Brown ------?extPart_000_03E7_01C24229.D7951800
engineering+thewalker.com on Sun Sep 15 09:18:41 2002 (link)
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
egroups+topografix.com on Mon Sep 16 10:14:53 2002 (link), replying to msg
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+topografix.com
lesj+mistycreek.com on Wed Sep 18 02:55:37 2002 (link)
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.
egroups+topografix.com on Wed Sep 18 05:21:26 2002 (link), replying to msg
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+topografix.com
engineering+thewalker.com on Wed Sep 18 06:00:25 2002 (link), replying to msg
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...
donreith+rogers.com on Thu Sep 19 04:51:50 2002 (link), replying to msg
> 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
davewissenbach+yahoo.com on Fri Sep 20 16:30:31 2002 (link), replying to msg
--- 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...
robertlipe+usa.net on Sun Sep 22 19:39:17 2002 (link)
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+usa.net> > > 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
egroups+topografix.com on Tue Sep 24 07:10:11 2002 (link), replying to msg
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+topografix.com
egroups+topografix.com on Tue Sep 24 07:24:13 2002 (link), replying to msg
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+topografix.com
haywoodkb+yahoo.com on Tue Sep 24 17:04:21 2002 (link), replying to msg
--- 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
davewissenbach+yahoo.com on Tue Sep 24 19:53:24 2002 (link), replying to msg
--- 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.
egroups+topografix.com on Fri Sep 27 08:24:59 2002 (link), replying to msg
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+topografix.com
egroups+topografix.com on Wed Oct 09 15:07:43 2002 (link), replying to msg
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+topografix.com</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+topografix.com
lupitacox+yahoo.com on Thu Oct 10 16:37:38 2002 (link), replying to msg
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...
robertlipe+usa.net on Mon Oct 28 18:57:19 2002 (link)
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
egroups+topografix.com on Tue Oct 29 07:44:06 2002 (link), replying to msg
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+topografix.com
egroups+topografix.com on Mon Nov 04 07:31:34 2002 (link), replying to msg
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+topografix.com
hamish+travellingkiwi.com on Mon Nov 04 08:01:54 2002 (link)
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/ |
egroups+topografix.com on Mon Nov 04 08:32:53 2002 (link), replying to msg
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+topografix.com
robertlipe+usa.net on Mon Nov 04 08:47:53 2002 (link), replying to msg
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
robertlipe+usa.net on Mon Nov 04 08:58:22 2002 (link), replying to msg
> 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
davewissenbach+yahoo.com on Mon Nov 04 19:29:57 2002 (link), replying to msg
--- 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...
egroups+topografix.com on Tue Nov 05 07:29:12 2002 (link), replying to msg
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+topografix.com
fouts+fogey.com on Tue Nov 05 15:16:22 2002 (link), replying to msg
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+topografix.com] > 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+topografix.com > > > ------------------------ 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/ > >
davewissenbach+yahoo.com on Tue Nov 05 19:56:33 2002 (link), replying to msg
--- 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...
robertlipe+usa.net on Wed Nov 06 06:46:06 2002 (link), replying to msg
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
egroups+topografix.com on Wed Nov 06 07:06:05 2002 (link), replying to msg
Hello, Monday, November 4, 2002, 10:29:51 PM, Dave wrote: d> While d> we're adding tags, what about adding another top level tag called d> <region>? I know that from time to time Farmer Brown comes onto the d> GPS newsgroups and asks for a way to measure his fields. Can you explain a bit more what you're proposing? What would <region> look like, and how would Farmer Brown use it? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Nov 06 08:02:43 2002 (link), replying to msg
Hello, Assuming the proposal to add <type> to <rte> and <trk> is accepted, it will be added to the GPX schema. Should we increment the GPX version number at this time, to 1.1 (or 1.00001)? It's not necessarily a requirement - if the 1.0 schema were to suddenly include <type>, no existing files or programs would break. The logical place to put the <type> element is at the end of the list of public types, but before the private type catch-all. If you look at the schema now, you'll see that I've added <type> in that location, but commented it out. (I did a quick test to make sure that a sample file including <type> would validate correctly.) My personal feeling is that we should bump the increment the version number each time we make a change. If that's what we choose to do, we should try to lump changes together. To me, changing the major version number (2.x) means that we've done something that is no longer compatible with 1.x. To avoid only being able to make 9 changes to GPX 1.x, we might want to change to a longer version number (1.01 or 1.001). Or is the version number just a number, and 2.7 is has no difference in meaning than 1.2 and 1.7. What do you all think? How should we handle minor additions and drastic changes to the GPX schema? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
hamish+travellingkiwi.com on Wed Nov 06 09:39:08 2002 (link)
Dan Foster wrote: > Hello, > > Assuming the proposal to add <type> to <rte> and <trk> is accepted, > it will be added to the GPX schema. Should we increment the GPX > version number at this time, to 1.1 (or 1.00001)? It's not > necessarily a requirement - if the 1.0 schema were to suddenly include > <type>, no existing files or programs would break. > > The logical place to put the <type> element is at the end of the list > of public types, but before the private type catch-all. If you look > at the schema now, you'll see that I've added <type> in that location, > but commented it out. (I did a quick test to make sure that a sample > file including <type> would validate correctly.) > > My personal feeling is that we should bump the increment the version > number each time we make a change. If that's what we choose to do, > we should try to lump changes together. > > To me, changing the major version number (2.x) means that we've done > something that is no longer compatible with 1.x. To avoid only being > able to make 9 changes to GPX 1.x, we might want to change to a > longer version number (1.01 or 1.001). Or is the version number just > a number, and 2.7 is has no difference in meaning than 1.2 and 1.7. > > What do you all think? How should we handle minor additions and > drastic changes to the GPX schema? What's wrong with just major.minor, where minor increments by one for every change... It doesn't have to just be a decimal number where 1.2 is more than 1.19 Oops... Or does the xml spec indicate otherwise? H -- I don't suffer from Insanity... | Linux User #16396 I enjoy every minute of it... | | http://www.travellingkiwi.com/ |
egroups+topografix.com on Wed Nov 06 10:38:27 2002 (link), replying to msg
Hello, Wednesday, November 6, 2002, 12:12:21 PM, Hamish wrote: H> What's wrong with just major.minor, where minor increments by one for H> every change... It doesn't have to just be a decimal number where 1.2 is H> more than 1.19 H> Oops... Or does the xml spec indicate otherwise? You're entirely correct. I was thinking that version was a number, and that we'd have a problem of "1.10" being the same as "1.1". I should have actually looked at the schema. Version is a string. Problem solved. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
martinp13+earthlink.net on Wed Nov 06 12:20:51 2002 (link), replying to msg
But wouldn't it be cleaner to have the first revision be 1.01, the second 1.02, and the tenth be 1.10? That was there is NO ambiguity. And it allows for 99 minor revisions before you are "forced" to do a major. :) > Martin (from the geocaching side of the house) Dan Foster <egroups+topografix.com> wrote:Hello, Wednesday, November 6, 2002, 12:12:21 PM, Hamish wrote: H> What's wrong with just major.minor, where minor increments by one for H> every change... It doesn't have to just be a decimal number where 1.2 is H> more than 1.19 H> Oops... Or does the xml spec indicate otherwise? You're entirely correct. I was thinking that version was a number, and that we'd have a problem of "1.10" being the same as "1.1". I should have actually looked at the schema. Version is a string. Problem solved. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ --------------------------------- Do you Yahoo!? HotJobs - Search new jobs daily now --0-958601301-1036614050=:2380
techlist+hisys.com on Wed Nov 06 15:46:46 2002 (link)
> But wouldn't it be cleaner to have the first revision be 1.01, the > second 1.02, and the tenth be 1.10? That was there is NO ambiguity. > And it allows for 99 minor revisions before you are "forced" to do a major. :) That makes sense; otherwise even though XML doesn't care, some humans will be confused over the years about 1.11 vs 1.9 etc. All ambiguity can be avoided with 1.09 vs 1.11. And yes, I think it makes sense from human terms to reserve 2.x for major updates. Otherwise, skip the pseudo decimal point and just number with integers from 1 upwards. Zhahai (ps: Hi!) + Zhahai Stewart zhahai+hisys.com + A Meme Gardener + Standard Disclaimer YMMV - Your Maya May Vary
blalor+keyword+yahoo.f6bdbf+ithacabands.org on Wed Nov 06 16:27:19 2002 (link), replying to msg
On Thu, 7 Nov 2002, Kjeld Jensen wrote:
> With <mode> and <way> I believe we are about to introduce tags that
> does not apply to all GPS users. Again I am not saying that we
> shouldn't do it, but we should definitely discuss if we want to go
> this way. Glider pilots want turn point info added to their
> waypoints, and yachting people want buoy tags and so on....
Have we discussed using namespaces at all? I really don't know a great
deal about XML, but it seems like namespaces can make it fairly modular.
We (or other parties) could define modules for boating, soaring,
spelunking, etc. and then include them when they're needed. This would
keep the base GPX spec from becoming polluted and allow infinite
expandability for future uses...
--
Brian Lalor | http://introducingthelalors.org/
blalor+ithacabands.org (email) | blalor+jabber.ithacabands.org (jabber)
N33�27.369' W111�56.304' (Earth)
jeremy+groundspeak.com on Wed Nov 06 16:50:24 2002 (link), replying to msg
Why not just make it an optional attribute? Jeremy -----Original Message----- From: Kjeld Jensen [mailto:gps+cetus.dk] Sent: Wednesday, November 06, 2002 4:24 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: Add <type> element to <rte> and <trk>?
jeremy+groundspeak.com on Wed Nov 06 17:05:47 2002 (link), replying to msg
We'd be happy to host it at Groundspeak, and bypass either option. We have ecartis running here (formerly Listar). Dan can continue as the moderator. Jeremy -----Original Message----- From: Kjeld Jensen [mailto:gps+cetus.dk] Sent: Wednesday, November 06, 2002 4:20 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Sourceforge vs. Yahoo Groups
jeremy+groundspeak.com on Wed Nov 06 17:23:09 2002 (link), replying to msg
True. I'm doing this with cache data in a groundspeak:cache namespace.
-- I take back my last statement. <rte> and <trk> should have a <type>
tag to duplicate the <wpt> tag, though I think it should be an attribute
on all three. Since it is too late to change <wpt> then creating the
<type> makes it uniform.
-- Isn't it straightforward how decimal places work? After Version 1.09
is version 1.10. Next release should be 1.01 or 1.00001 - I don't care
either way :)
-- This hasn't been discussed, but I'd like to add this: There is a
<src> tag but should separate manufacturer and software version from the
model. Like: <src mfr="Garmin" ver="1.2">eTrex Legend</src>
Jeremy
-----Original Message-----
From: Brian Lalor [mailto:blalor+keyword+yahoo.f6bdbf+ithacabands.org]
Sent: Wednesday, November 06, 2002 4:27 PM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Re: Add <type> element to <rte> and <trk>?
On Thu, 7 Nov 2002, Kjeld Jensen wrote:
> With <mode> and <way> I believe we are about to introduce tags that
> does not apply to all GPS users. Again I am not saying that we
> shouldn't do it, but we should definitely discuss if we want to go
> this way. Glider pilots want turn point info added to their waypoints,
> and yachting people want buoy tags and so on....
Have we discussed using namespaces at all? I really don't know a great
deal about XML, but it seems like namespaces can make it fairly modular.
We (or other parties) could define modules for boating, soaring,
spelunking, etc. and then include them when they're needed. This would
keep the base GPX spec from becoming polluted and allow infinite
expandability for future uses...
--
Brian Lalor | http://introducingthelalors.org/
blalor+ithacabands.org (email) | blalor+jabber.ithacabands.org
(jabber)
N33�27.369' W111�56.304' (Earth)
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+yahoo.com on Thu Nov 07 06:12:19 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Monday, November 4, 2002, 10:29:51 PM, Dave wrote: > > d> While > d> we're adding tags, what about adding another top level tag called > d> <region>? I know that from time to time Farmer Brown comes onto the > d> GPS newsgroups and asks for a way to measure his fields. > > Can you explain a bit more what you're proposing? What would <region> > look like, and how would Farmer Brown use it? > Region would be a closed path, but otherwise look just like a track. Farmer Brown would get on his four-wheeler and drive around the boundary of his field. He would name the region "The North Forty". He could then select the region in his gpx application and ask for the area in acres. If he decided that he wanted to irrigate north forty, he could draw tracks across the area at the desired slope, provided that his basemap included elevation data. Farmer Brown might want to use a number of such reasons when he creates his crop plan. I also see another use. Farmer Brown sells Hunter Bob permission to hunt pheasants in the North Forty, and Hunter Joe permission to hunt Geese in the West Cornfield. Farmer Brown might want to give Hunter Bob and Hunter Joe GPX regions to keep these two apart. Boundaries are important to hunters in Idaho because of the "Ask First" law which forbids hunting on private land, posted or not. In general, I would use the regions for defining land boundaries. Here in the Boise area, the land is very fragmented as to ownership. Being able to see a region lets you know when or if you're trespassing. On foot or by bicycle this isn't a problem, but in Ada County, Idaho, driving a motor vehicle on private land, posted or not, without permission is a crime. Another use. Out to the on the snake river plain we have a restricted area used by the National Guard for artillery practice. A pilot would might to stay out of such a region. Another one. The Boise Cascade corporation logged a square mile of old-growth "by accident." A conscientious logger or firewood cutter or mushroom picker might want a GPS receiver capable of telling them whether or not they are within their assigned region. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
egroups+topografix.com on Thu Nov 07 07:42:59 2002 (link), replying to msg
Hello, Thursday, November 7, 2002, 9:12:15 AM, Dave wrote: d> Region would be a closed path, but otherwise look just like a track. Wouldn't something like this be simpler? <trk> <name>Back Forty</name> <closed>true</closed> ... </trk> I'm very much in favor of adding a way to specify that a path is closed, but I don't like the idea of duplicating everything that's already in <rte> and <trk> to do it. In fact, I now believe that we made a bad choice with <rte> and <trk> - I think we should have used one top-level object for point data, and one top-level object for line data. Something like: <path> <name>Back Forty</name> <gps>track</gps> <closed>true</closed> ... </path> <path> <name>Lake Boise</name> <gps>none</gps> <!-- show it on the map, but don't send to GPS! --> <closed>true</closed> ... </path> -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Nov 07 07:51:03 2002 (link), replying to msg
Hello, Wednesday, November 6, 2002, 7:38:17 PM, Kjeld wrote: K> Hi Brian Lalor, >>Have we discussed using namespaces at all? I really don't know a great >>deal about XML, but it seems like namespaces can make it fairly modular. K> As far as I know this is exactly where the private tags are currently K> used by at least Dan and Dave. K> But I was under the impression that they want to include the tags in K> the basic GPX scheme and therefore I wanted to discuss it. I may be K> wrong though. K> Kjeld I'd like to see us start using multiple public namespaces for public tags, and I've even suggest that we remove many of the things that are currently in the public spec and put them in their own namespaces. Most of the things I think should be removed just happen to be things that I lobbied to get included... (type, url, urlname...) The way I see it, the only thing that should be in the default GPX namespace are things having to do with geographic position. Latitude, longitude, elevation, and time are really the only universal things that this group has in common. Even GPS tags like <com> and <sym> aren't really universal - maybe there are weather programs that would output forecasts for world cities in GPX, but don't care a bit about GPS receivers. The GPX namespace would set a base level for data interchange. Programs that support only the GPX namespace can still exchange geographic data without losing the basic info. On top of that, we add public namespaces. The only thing that makes a public namespace different from a private namespace is that public namespaces are agreed upon by a group (possibly this group, or perhaps we'll break up into sub-groups). There are several areas where public namespaces would be appropriate. I'll try to describe them below. Trail description publishing: Dave and I have been doing a lot with this, and things like long text descriptions, <way>, <type> would fall here. Graphical map publishing: As I've said before, I'm interested in working with others on this. Things like map projection data would fall here, as well as display issues (font, color, line size). Real-time tracking: The NMEA stuff from <trkpt> would go here, along with any additional info related to time-based positioning. Kjeld's interested in this, so am I. Geocaching: I know Jeremy is working on a private schema for this. I also know there are a bunch of geocachers on this list who might be interested in contributing to this effort if it was public. I know Kjeld is concerned about increasing the size of GPX files and the complexity of the format. I think that switching to multiple namespaces will decrease the complexity of the base format considerably. If Kjeld has to include the "base GPX" and "GPS stuff" and "tracking stuff" namespaces at the head of each GPX file, the file size will certainly go up a bit. We should talk about those tradeoffs. What do you all think? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
jeremy+groundspeak.com on Thu Nov 07 09:48:56 2002 (link), replying to msg
Seems like spacial data should be separate from waypoint, route and track sharing. Showing a closed loop bike path is one thing (which IMO belongs as part of route data), but defining boundaries fits better within a spacial schema. At that point you're moving into G-XML and GML type schemas, which I don't think belongs in the "light-weight" GPX format. I like the idea of creating <region> tags (especially based on the ideas put forth by Wissenbach), but it seems out of scope for the purpose of the GPX format. I'd suggest other namespaces that define spacial information and keep GPX from encountering scope creep. Jeremy -----Original Message----- From: Dan Foster [mailto:egroups+topografix.com] Sent: Thursday, November 07, 2002 7:10 AM To: davewissenbach Subject: Re: [gpsxml] Re: <region> Hello, Thursday, November 7, 2002, 9:12:15 AM, Dave wrote: d> Region would be a closed path, but otherwise look just like a track. Wouldn't something like this be simpler? <trk> <name>Back Forty</name> <closed>true</closed> ... </trk>
jeremy+groundspeak.com on Thu Nov 07 13:11:35 2002 (link), replying to msg
Wow. I can see how the GPX format could get bloated fast. Is that written in stone? It seems to me the purpose of attributes in XML are to give further information about a specific tag, as long as the information has a restricted length and exists as only one instance. So this is more appropriate for source info? <src mfr="Garmin" model="eTrex Vista" ver="1.2" /> Or even... <src mfr="Garmin" ver="1.2">eTrex Vista</src> seems a lot better than <src>eTrex Vista</src> <src_mfr>Garmin</manufacturer> <src_ver>1.2</version> My reasoning for additional hardware information (including software versions) can help a user understand the validity of the unit's capabilities that generated the info. You could also notify the user if a new software version was available, or react to a firmware issue, etc. And a well-documented source tag will just plain help when managing data. Unfortunately I can't seem to get into the archives, so please enlighten me as to why attributes are required. Jeremy -----Original Message----- From: Kjeld Jensen [mailto:gps+cetus.dk] Sent: Wednesday, November 06, 2002 11:26 PM To: gpsxml+yahoogroups.com Subject: RE: [gpsxml] Re: Add <type> element to <rte> and <trk>? Hi Jeremy Irish, >Why not just make it an optional attribute? When we defined 1.0 we decided (after a long discussion) to use attributes only for required information and elements only for optional information. I prefer that we keep it this way. Kjeld --
martinp13+earthlink.net on Thu Nov 07 13:20:58 2002 (link), replying to msg
I think he meant that if mfr, ver, model were required, then: <src mfr="Garmin" ver="1.2" model="Etrex Vista" /> would be fine... but if they are optional, then: <src> <mfr>Garmin</mfr> <ver>1.2</ver> <model>Etrex Vista</model> </src> was appropriate. Sorry I couldn't paginate that... Yahoo groups editor is the pits. :( > Martin Jeremy Irish <jeremy+groundspeak.com> wrote:Wow. I can see how the GPX format could get bloated fast. Is that written in stone? It seems to me the purpose of attributes in XML are to give further information about a specific tag, as long as the information has a restricted length and exists as only one instance. So this is more appropriate for source info? Or even... eTrex Vista seems a lot better than eTrex Vista Garmin 1.2 My reasoning for additional hardware information (including software versions) can help a user understand the validity of the unit's capabilities that generated the info. You could also notify the user if a new software version was available, or react to a firmware issue, etc. And a well-documented source tag will just plain help when managing data. Unfortunately I can't seem to get into the archives, so please enlighten me as to why attributes are required. Jeremy -----Original Message----- From: Kjeld Jensen [mailto:gps+cetus.dk] Sent: Wednesday, November 06, 2002 11:26 PM To: gpsxml+yahoogroups.com Subject: RE: [gpsxml] Re: Add element to and ? Hi Jeremy Irish, >Why not just make it an optional attribute? When we defined 1.0 we decided (after a long discussion) to use attributes only for required information and elements only for optional information. I prefer that we keep it this way. Kjeld -- To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ --------------------------------- Do you Yahoo!? U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD --0-1826139515-1036704057=:91384
davewissenbach+yahoo.com on Fri Nov 08 06:09:04 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Thursday, November 7, 2002, 9:12:15 AM, Dave wrote: > > d> Region would be a closed path, but otherwise look just like a track. > > Wouldn't something like this be simpler? > <trk> > <name>Back Forty</name> > <closed>true</closed> > ... > </trk> > > I'm very much in favor of adding a way to specify that a path is > closed, but I don't like the idea of duplicating everything that's > already in <rte> and <trk> to do it. In fact, I now believe that we > made a bad choice with <rte> and <trk> - I think we should have used > one top-level object for point data, and one top-level object for line > data. Something like: > <path> > <name>Back Forty</name> > <gps>track</gps> > <closed>true</closed> > ... > </path> > <path> > <name>Lake Boise</name> > <gps>none</gps> <!-- show it on the map, but don't send to GPS! -- > > <closed>true</closed> > ... > </path> > One way to achieve this would be to define a type which is common to route, track, or region, but keep the element name different. Then route, track and region are all elements with type PathType, and waypoint and trackpoint are elements with type PointType. I'm not sure that we have a better or more formal way of expressing inheritance with XML Schema. Another way might be with substitution groups, where elements can be allowed to substitute for each other. The path/point concept will certainly lead to better and simpler implementations. I think that internally in Wissenbach Map I made a poor design choice when I used a separate implementation for route and track, and this is probably also true for the gpx schema itself. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
davewissenbach+yahoo.com on Fri Nov 08 06:32:09 2002 (link), replying to msg
--- In gpsxml+y..., Dan Foster <egroups+t...> wrote: > Hello, > > Wednesday, November 6, 2002, 7:38:17 PM, Kjeld wrote: > > > I'd like to see us start using multiple public namespaces for public tags, > and I've even suggest that we remove many of the things that are > currently in the public spec and put them in their own namespaces. > Most of the things I think should be removed just happen to be things > that I lobbied to get included... (type, url, urlname...) > > The way I see it, the only thing that should be in the default GPX > namespace are things having to do with geographic position. Latitude, > longitude, elevation, and time are really the only universal things > that this group has in common. Even GPS tags like <com> and > <sym> aren't really universal - maybe there are weather programs that > would output forecasts for world cities in GPX, but don't care a bit > about GPS receivers. > > The GPX namespace would set a base level for data interchange. > Programs that support only the GPX namespace can still exchange > geographic data without losing the basic info. > > On top of that, we add public namespaces. The only thing that makes a > public namespace different from a private namespace is that public > namespaces are agreed upon by a group (possibly this group, or perhaps > we'll break up into sub-groups). There are several areas where public > namespaces would be appropriate. I'll try to describe them below. > > Trail description publishing: Dave and I have been doing a lot with > this, and things like long text descriptions, <way>, <type> would fall > here. > > Graphical map publishing: As I've said before, I'm interested in > working with others on this. Things like map projection data would > fall here, as well as display issues (font, color, line size). > > Real-time tracking: The NMEA stuff from <trkpt> would go here, along > with any additional info related to time-based positioning. Kjeld's > interested in this, so am I. > > Geocaching: I know Jeremy is working on a private schema for this. I > also know there are a bunch of geocachers on this list who might be > interested in contributing to this effort if it was public. > > > I know Kjeld is concerned about increasing the size of GPX files and > the complexity of the format. I think that switching to multiple > namespaces will decrease the complexity of the base format > considerably. If Kjeld has to include the "base GPX" and "GPS stuff" > and "tracking stuff" namespaces at the head of each GPX file, the file > size will certainly go up a bit. We should talk about those > tradeoffs. > > What do you all think? Perhaps we should restrict GPX to the application of trip planning and trail logging only. In that context, trail descriptions and waypoint descriptions, are still appropriate. Region might not be. To set the context of the trip, we use a vector basemap, which is described in some other namespace. In many cases we'll create those vector basemaps by transforming GPX data into the vector basemap format. I know that there is activity in the area of a georeferenced SVG extension already out there, so we might just try to figure out how to relate our trip maps to the basemaps. Whatever the format is, this should include level-of-detail, so that at various zoom levels information that isn't so relevant disappears off the screen. I think that the utility of USGS topographic map data is decreasing rapidly. With Digital Elevation Model data, and the national geographic data set, we probably have better ways of describing elevation data that don't clutter up the computer screen so much. But we should probably search for a good XML basemap format before we make our own. But I would like have good agreement on a basemap format. GPX should add tags which allow the referencing of a particular basemap. Eventually, cell phones, PDAs, and GPS receivers will converge into one device, and I'd like to see the mapping format for these devices be public-domain. That's where I think that we're going. > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
robertlipe+usa.net on Fri Nov 08 08:31:53 2002 (link), replying to msg
davewissenbach wrote: > The path/point concept will certainly lead to better and simpler > implementations. I think that internally in Wissenbach Map I made a > poor design choice when I used a separate implementation for route > and track, and this is probably also true for the gpx schema itself. I recall questioning why they were distinguished in the GPX spec. While I certainly haven't pushed the bounds of GPX like you guys have, I wound up handling tracks as "anonymous routes" (the individual waypoints may or may not have names) inside GPSBabel. It really didn't seem like a contrived fit at all. Tracks are just routes of many points that don't have unique names. RJL
egroups+topografix.com on Fri Nov 08 10:42:24 2002 (link), replying to msg
Hello, Friday, November 8, 2002, 11:31:51 AM, Robert wrote: R> I recall questioning why [routes and tracks] were distinguished in the GPX spec. R> While I certainly haven't pushed the bounds of GPX like you guys have, I R> wound up handling tracks as "anonymous routes" (the individual waypoints R> may or may not have names) inside GPSBabel. It really didn't seem like R> a contrived fit at all. Tracks are just routes of many points that R> don't have unique names. I treat tracks the same way as routes in the internals of my programs. They are just routes with the "isTrack" property set. As I recall, one reason we kept <rte> and <trk> separate was that Kjeld had a bunch of NMEA-type data to store in <trkpt>, and it didn't make sense to make it available in <rtept> as well. Also, we introduced the concept of <trkseg> to handle discontinuous tracks, which don't have much use in <rte>. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
joel+coastaloutdoors.com on Sun Nov 10 19:14:42 2002 (link)
Gentlemen: I have followed the discussions with great interest. I confess to not giving the attention to the group it deserves and apologize for any apparent ignorance. The application I have been working on is web based. I already have a simple GPS search and list tool for approximately 15,000 marine waypoints on the US East and Gulf coasts. The next step in the application development will be a trip planner for inshore and offshore fishing trips, and, to allow the users to download the waypoints, routes and tracks for upload to their GPS. I have thousands of land-based coordinates in my database also, but, am currently only using the marine coordinates. Future development of the application calls for inclusion of marine freshwater coordinates. "Support" locations for all the above will be utilized as well. Additionally, we will begin inclusion of recreational land coordinates for hunting, hiking, general boating, etc. The discussions with respect to trails, regions, bounds, map calibration points have been of particular interest to me. To kind of help me differentiate between the namespaces, if someone could, please take a moment to "label" the following correctly for me. I will give my current field name and the purpose of the field. coord_id: the unique identifier in my database for the coordinate. name: common name of the waypoint, in many cases, this may be just a number such as Grays 1 or Grays SW Ledge. cmt: commments about the waypoint. lat: latitude lon: longitude desc: description of the waypoint. date: date the waypoint was acquired. st: the state of the coordinate location. type: the descriptive type of the coordinate, such as boat ramp, marina, hard bottom/live bottom, ledge, wreck, etc. coord_area: the general area in which the coordinate is located, right now I'm using bounds here. area: "common area name" such as "Grays Reef" or "J Reef". material: if the waypoint is an artificial reef, the type material used to create the reef. depth: depth at the waypoint - I would assume this would be geoidheight Thank you for your time. With elucidation on the above, I may be able to contribute in the future. Joel http://www.coastaloutdoors.com
robertlipe+usa.net on Tue Nov 12 00:11:55 2002 (link), replying to msg
Kjeld Jensen wrote:
> >a contrived fit at all. Tracks are just routes of many points that
> >don't have unique names.
>
> No
>
> - at least not following my definition :-)
OK, but I'm still not sure I agree with your definition since you seem
to define them different just to make them easier to grasp and not based
on real a real distinction. ;-)
> Tracks are sets of positions along with information about the current
> state of the tracker at that position. The state may include the time,
> current speed, current course and so on.
Given position, you know current course. Given time, you know current
speed from the last point, right? (If you're storing "current speed" as
"instantaneous speed when this trackpoint was dropped", I'd be a little
suprised.)
> Routes are sets of positions that you in some way want to follow
> sequentially.
Tracks and routes both sets of sequentially ordered waypoints.
Tracks probably have optional <time> records. Routes probably don't.
While the disinction you make might help the developer that wants to
code one very specific task using GPX ("Here, Junior, code me some
XML gibberish that reads section A.B.C of this spec...") gain a quick
understanding, it actually complicates the XML parsers becuase you have
to maintain extra state to know if a waypoint appears in a track or a
route. You have to parse lat/lon as mandatory data in all three (waypt,
track, route) even though you probably want to handle all three in
very similar ways.
I guess I'm saying that routes and tracks are more alike than they are
different and the differences can be handled via the optional data
already defined. If you treat the wpt as the fundamental unit, the
abstraction gets even stronger. You now have on "thingy" that appears
either in isolation or in an ordered sequence.
But I'm the new kid on this block. You GIS and XML guys can just go
nuts with this stuff. :-)
> Maybe our different point of view follows from the fact that I
> spend most time creating those sets of data and you spend most time
> converting, presenting and analyzing them. I don't know, but it
> becomes obvious that this "discussion" way of building up a general
> exchange format is very fruitful although long winded.
Oh, I'm sure perception has a lot to do with it. I don't think we're
really arguing substantially different views. But getting the views of
GPX from a variety of folks using it in different ways was one of the
goals of this discussion originally. It'll hopefully help shape future
directions.
robertlipe+usa.net on Tue Nov 12 10:24:33 2002 (link), replying to msg
> from universities and companys that use Cetus GPS for quite advanced > tasks and I do not think we should cut off this functionality just to > merge routes and tracks. OK, sold. Keep it as an otional tag. > So far we agree :-) - if I could just get you to call it positions > and not waypoints, as route and trackpoints normally does not contain I'm just calling them that becuase we call the tag "wpt" inside gpx. I'm certainly not bent on the term and I do understand the distinction you're making. > to define a basic "position" record containing only the information > that are related to the position itself and the conditions under > which it was obtained. > > Then waypoints would consist of the position record along with > waypoint related information (url, icon and so on). Routes, tracks, > regions, real-time positioning, map calibration points etc. could be > defined the same way. I could go for that. We'd then have one way of expressing a waypoint, er, position instead of three (with more on the horizon) and would gain the simplification I describe and desire. RJL
jeremy+groundspeak.com on Wed Nov 13 07:46:29 2002 (link), replying to msg
I changed the topic since <region> didn't really fit the discussion. Personally, I thought XML was supposed to be both readable and parsable. Normalization is fine and dandy for databases, but I would personally prefer both a trk and rte data since I can quickly discern which is which. It is well known by most users of GPS units, and most GPS software has these options available. I vote to keep it as it is. It seems to me that Trk data is sequential track data indicating an exact defined path, while rte data is a list of sequential waypoints that can be reached by x alternate paths. So, for example if you were going from the Visitor's Center to the geyser, it would show you to take the long path (trail 2), while a route would show you the visitor's center as step one and geyser as step 2. True that all routes could be tracks, but not all tracks are routes. Jeremy
henry_wede+yahoo.com on Sun Nov 24 19:56:45 2002 (link)
Hello - I new here (and new to XML), so this question may have been addressed early on... Why are the waypoint elements on the same 'level' as the route and track elements? Wouldn't it be good to allow groups of waypoints under a waypoint element the same way there can be different routes or tracks under their headings? Henry
chris+groundspeak.com on Mon Nov 25 10:50:53 2002 (link)
Hi Henry, I'm merely a user of GPX-- but I'm fairly sure one of the goals is simplicity. If you're new to XML, you'll soon realize that for everything you work with you'll need to understand the organization of the data (or at least the parts you're interested in). Keeping things simple will greatly speed your development efforts, and your ability to move things in and out of the chosen format. Both routes and tracks are already collections of "points". In almost all cases, having multiple waypoints is a given, and frequently a GPX file may only be waypoints, without tracks or routes-- zo in most cases the GPX file itself is a collection of waypoints, and the need to give it another wrapper is a bit redundant. With most XML software and platforms, you should be able to use simple XPath to build a collection (nodelist) of waypoints: //wpt. Chris henry_wede wrote: > Hello - > > I new here (and new to XML), so this question may have been addressed > early on... > > Why are the waypoint elements on the same 'level' as the route and > track elements? Wouldn't it be good to allow groups of waypoints > under a waypoint element the same way there can be different routes > or tracks under their headings? > > > Henry > > > > *Yahoo! Groups Sponsor* > ADVERTISEMENT > <http://rd.yahoo.com/M=237459.2675695.4055211.2225243/D=egroupweb/S=1706030390:HM/A=1267611/R=0/*http://ad.doubleclick.net/jump/N2524.Yahoo/B1071650;sz=300x250;ord=1038196606310311?> > > > > 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 > <http://docs.yahoo.com/info/terms/>. --------------080604010000070804040003
scmorris+mailcity.com on Wed Dec 11 21:18:12 2002 (link)
Hi All,
I never announced it here, but just wanted to let everyone know that there is another GPX mapping program out there, TopoFusion. We use GPX as our primary storage format. We're quite happy with the concept and specs in GPX; bravo to everyone.
I also wanted to let you know that I'm working on simulating recreational trail users on GPS tracks and am getting people involved collecting data in the GPX format. I'm really insisting on GPX because I need the time component with each data point.
Also, I will soon be extending GPX to include topology information. TopoFusion works with networks of trails and there is currently no way to store topological information in GPX. I will probably make them private extensions for now, but if anyone else is interested in helping (or interested in networks in general), I'd love to hear from you.
More information about all this can be found on our site, www.topofusion.com
Thanks,
Scott Morris
interjunk+shaw.ca on Sun Jan 05 22:24:44 2003 (link)
I don't know if this is the correct group to be posing this question. If not, I apologize. I need to find a software program or utility (freeware or otherwise) to help with the following problem: - We want to be able to download data from the Handheld GPS and export coordinates (as waypoints) to formated text file to import to Mine Modeling/CAD Software. Want to export from Mine Modelling Software and upload to Handheld GPS, as well. The driver for this solution is to minimize manual coordinate entry (time is money). Current Situation: - Using Garmin 12XL handheld GPS for rough mining surveying. We modified the user grid to work in the mine coordinates (on both GPS and MapSource Software). This transformation works well. - Example Situation: We have the Drillhole IDs and coordinates in a formated text file (Exported from Mine Modelling Software) and want to upload the coordinates in order to survey the position using handheld GPS. - Example Situation: We survey testing locations with IDs (stored as waypoints) and we want to download from GPS and import to Mine Modelling Software (or potential to database) I tried the following programs, and they do not work for my situation: - GPS Utility Ver 4.04.6 - GPS TrackMaker Thanks in advance. Todd
davewissenbach+yahoo.com on Wed Jan 08 18:17:27 2003 (link)
I've worked out simple coordinate transformations for drawing trails and waypoints as Scalable Vector Graphics with UTM coordinates. The sample file references TerraServer aerial photo tiles on the SVG. The SVG file is http://myweb.cableone.net/cdwissenbach/BogusBasin.svg This is best viewed with an html wrapper which sets the scale at 2 meters per pixel. http://myweb.cableone.net/cdwissenbach/EmbeddedSVG.html The SVG file was output by a prototype version of Wissenbach Map. The place names shown without waypoints are drawn by making a special waypoint with type="Place Name". What's probably of most interest to the developers who read this group are the viewport and outermost g element transformations which flip the coordinate system to set up the UTM coordinate system, and the transformations to flip the coordinate system back, temporarily, to render text and waypoints. This work was inspired by Dan Foster's SVG effort and by the thread in this group SVG Anyone? and by my desire to learn SVG. I'll be embellishing the SVG output features of Wissenbach Map and publishing a version of the program which allows SVG drawing in the next few months. (As always, this depends on the workload in my real job, and will of course depend on the local skiing conditions--not so good right now.) I intend to use the type fields to provide the hints as to what line types and fills to use in SVG. For example, type="Ski Run" might cause a wide, translucent line to be drawn. type="Ski Lift" would give a thin dotted line.
davewissenbach+yahoo.com on Sat Jan 11 19:37:43 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, Ralf Haselmeier <Ralf.Haselmeier+g...> wrote: > Hi, > > I want to implement waypoints and routes to my gps application > (qpegps.sourceforge.net). > I'll use the gpx format: Is there any open source code which I can use > as a starting point (C++, Qt resp. Qt/embedded, Qtopia) ? > > Thanks for Your help. > Ralf See http://myweb.cableone.net/cdwissenbach/map.html for a link to source code to my program. However, If I had to do this over again, I'd use the same code for routes and tracks, and/or program using the xml document object model, or DOM. (The reason that I would do this is so that my program could work with an existing program but not lose data for tags which I don't implement. For example, my program would lose the topografix trail color information right now, and ExpertGPS eats layer information. So, with a disclaimer, you have source code. (The license is GPL) Dave
lesj+mistycreek.com on Thu Jan 16 13:28:59 2003 (link)
Belated congratulations to Dave W. for the SVG example. I've been away for a while so this response is a bit tardy ... I'm glad to 'see' that progress is being made out there. Keep going Dave. Ok, now the 'nice' stuff is out of the way ... ;) Dave, some questions: (I haven't peeked at the source code yet so bear with me here :) This is mostly picking at nits ... I have no real gripes and find no real faults, just wouldn't want to try vieing it on a dial-up connection. So most of what follows pertains to potential 'bloat'. I've opened it up and am looking at the SVG code. I see the transform="scale(1,-1)" in a lot of places. But in other places I see scale(1,1) ... I have to wonder if all these local transforms are 'needed' or if there's some sort of redundancy going on here. Then I encountered the paths in the last half of the doc. Take 'id="PINE CRK RD"' for instance. It has a <path> object wrapped in a <g> object. Both have transform="scale(1,-1)" ... so, not having tinkered with variations, I have to ask: Are they are cancelling each other out? or Is one is redundant? If they were redundant then that's approx. 50 bytes per double instance that don't need to be there ... Either way is there one transform spec too many or am I showing my ignorance? I told you I was being picky :) The next thing is I noticed is that the drawing primitive lists (<d>) for paths defined for the 'symbols' earlier in the doc are quite different from those used for the track lines (like the PINE CRK RD one) later. The earlier code makes use of the efficient shortcuts like: - relative positions (drops 6 digit absolute coord values down to 2 or 3 digit ones) - dropping redundant commands - successive 'L's not needed Am I correct in guessing that the code is different? (like maybe the earlier stuff came from a graphics program) The last things are just out of curiosity. All those Terrasever maps ... did you have to collect the tiling information manually or is that info derivable by code or program or provided by them? (meaning the values for T,S,X,Y and Z and the tile name) As for symbols, are yours adhoc or is there a clip-art collection in use? Once again, congratulations on this. I wish I had something 'svg'ish to share as well but my code's getting bogged down trying to be too many things :) I'll definitely study your use of the Transforms and maps. And maybe I'll peek at the code ... but if it's C it won't mean that much to me. I can grok the problems of doing your own XML parser instead of a DOM compliant 3rd party standard. I'm wearing myself out with 'parallel' development streams. Arghh! I do wonder if the output would be 'efficient enough' for the picky me though ... :) Keep it up Dave. Lurking and hacking in the background, Les Johnson
davewissenbach+yahoo.com on Thu Jan 16 19:38:56 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, Les Johnson <lesj+m...> wrote: > Belated congratulations to Dave W. for the SVG example. ... > Dave, some questions: > (I haven't peeked at the source code yet so bear with me here :) > This is mostly picking at nits ... > I have no real gripes and find no real faults, just wouldn't want to try vieing > it on a dial-up connection. So most of what follows pertains to potential > 'bloat'. Remember that the SVG standard includes a compressed version svgz. So this might keep the size down. > > I've opened it up and am looking at the SVG code. > I see the transform="scale(1,-1)" in a lot of places. The outermost group inverts the scale. Because of this, text would be printed upside down if not for the (1,-1) transforms. > But in other places I see scale(1,1) ... Usually these are waypoint symbol definitions where I plotted or entered coordinates by hand. > I have to wonder if all these local transforms are 'needed' or if there's > some sort of redundancy going on here. The scale(1,1) tranformations aren't really needed in the waypoint symbols. I think that eventually I'll have to provide an option to output waypoint symbols at different scales depending on the extent of the map. > Then I encountered the paths in the last half of the doc. > Take 'id="PINE CRK RD"' for instance. > It has a <path> object wrapped in a <g> object. > Both have transform="scale(1,-1)" ... so, not having tinkered with variations, > I have to ask: Are they are cancelling each other out? or Is one is redundant? Yes, they are cancelling each other out, but no, one is not redundant. The path is a named path so that when I apply the same path to the text path, I can apply a 1,-1 scale factor to the text plus path. This is necessary so that the text doesn't appear upside down along the text path. (I'm not too pleased with the wacky nature of the text path, so I might not use the SVG text path feature without attempting to smooth the path first.) > If they were redundant then that's approx. 50 bytes per double instance that > don't need to be there ... > Either way is there one transform spec too many or am I showing my ignorance? > > I told you I was being picky :) > As I explained above, I was being clever. But I couldn't find a better way to deal with the inverted coordinate system. > The next thing is I noticed is that the drawing primitive lists (<d>) for paths > defined for > the 'symbols' earlier in the doc are quite different from those used for the > track lines (like the PINE CRK RD one) later. > The earlier code makes use of the efficient shortcuts like: > - relative positions (drops 6 digit absolute coord values down to 2 or 3 digit > ones) > - dropping redundant commands - successive 'L's not needed > Am I correct in guessing that the code is different? > (like maybe the earlier stuff came from a graphics program) > Right. Everything in the <defs></defs> section is boilerplate that defines the drawing of the waypoint symbols. I'm using a trial version of Adobe Illustrator which came with the SAMS book SVG Now to draw the symbols. And of course Adobe is much better at SVG than I am. > The last things are just out of curiosity. > All those Terrasever maps ... did you have to collect the tiling information > manually > or is that info derivable by code or program or provided by them? > (meaning the values for T,S,X,Y and Z and the tile name) > The tiling information is derivable by program. The Terraserver web site contains instructions. See http://terraserver.homeadvisor.msn.com/about.aspxn=AboutLinktoTerrase rver > As for symbols, are yours adhoc or is there a clip-art collection in use? > No clip art. Once you other developers start publishing SVG I'll steal yours. Feel free to use mine. I've added to the collection but haven't had time to publish. > Once again, congratulations on this. > I wish I had something 'svg'ish to share as well but my code's getting bogged > down > trying to be too many things :) > I'll definitely study your use of the Transforms and maps. > And maybe I'll peek at the code ... but if it's C it won't mean that much to > me. > This is C++. > I can grok the problems of doing your own XML parser instead of a DOM compliant > 3rd party standard. I'm wearing myself out with 'parallel' development streams. > Arghh! > I do wonder if the output would be 'efficient enough' for the picky me though > ... :) > > Keep it up Dave. > > Lurking and hacking in the background, > Les Johnson Thanks for your interest. This was a learning exercise for me that seemed to yield some pretty good results. Dave
davewissenbach+yahoo.com on Sat Jan 18 12:44:23 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, "davewissenbach <davewissenbach+y...>" <davewissenbach+y...> wrote: > > The scale(1,1) tranformations aren't really needed in the waypoint > symbols. I think that eventually I'll have to provide an option to > output waypoint symbols at different scales depending on the extent > of the map. > Correction. In waypoint symbols which are symmetric about the X axis, I used scale(1,-1). But because of the inverted coordinate system, the second scale factor in a waypoint symbol should be negative. > I'm using a trial > version of Adobe Illustrator which came with the SAMS book SVG Now > to draw the symbols. And of course Adobe is much better at SVG than > I am. Correction: The book is called "Teach Yourself SVG in 24 Hours" The companion web site is http://www.svgnow.com I've made some more changes to Wissenbach map to support SVG. The wissenbach:type and wissenbach:style elements are now part of a track. (The type element isn't officially part of the standard yet, so I'm keeping this private for now. The type element is used to form a CSS class selector and corresponding attritubes a boilerplate style element at the beginning of the SVG document. (Actually, the program loads this from a file, so that a use can customize and add their own.) Then, if the type element is present, the path uses that type in a class attribute. The style element is used to get refinement on individual tracks. In the BogusBasin.gpx sample, the stroke: brown defined by the Dirt- Road CSS rule is overriden by the style="color: green". A deep default CSS rule for paths is present in the root document's style element to prevent the tracks from being filled and to define the stroke color and width when no other tracks are present. Dave
davewissenbach+yahoo.com on Sun Jan 19 08:46:08 2003 (link)
Geography Markup Language may be an alternative to the GPX format for complex maps. See http://www.opengis.net/gml/02-069/GML2-12.html I'm considering substituting GML for GPX in the trailmap layer of a new program similar to Wissenbach Map (but expressed in JAVA) and using GPX in the planning and logging layer. Then GPX would be used primarily for the originally stated purpose of data exchange. Using the Geographic Markup Language namespace might take the evolutionary pressure off of the GPX schema. Should we supporters of GPX format encourage the use of GML in the open-ended extension slots of GPX? Or would a better policy be returning to the original goal of GPX as an exchange policy and using a separate GML document for trailmap/basemap data? What do you all think?
clindh+homenet.se on Wed Jan 29 04:42:59 2003 (link)
I'm loading a GPX from geocaching.com but my XMLSpy complains: Your schema uses attributeFormDefault="qualified" - you must specify a prefix for your schema namespace "http://www.topografix.com/GPX/1.0 a) I would like to understand the error message; what is wrong b) I assume they did something wrong when producing that gpx-file. Can we help to get it right? It adds elements from their own schema: --------------- <?xml version="1.0" encoding="utf-8"?> <gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" creator="Groundspeak Pocket Query" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.groundspeak.com/cache/1/0 http://www.groundspeak.com/cache/1/0/cache.xsd" xmlns="http://www.topografix.com/GPX/1/0"> <author>Groundspeak</author> ... <wpt lat="57.69665" lon="11.979283"> <time>2001-04-03T00:00:00.0000000-07:00</time> ... <groundspeak:cache id="1538" available="True" xmlns:groundspeak="http://www.groundspeak.com/cache/1/0"> <groundspeak:name>Americana Cache</groundspeak:name> ...
clindh+homenet.se on Wed Jan 29 04:48:12 2003 (link)
I plan on writing an XSL, creating "Map Features" for OziExplorer. I have written one for .loc -> ozi waypoint files already. But before I get busy, has anyone done this already...?
davewissenbach+yahoo.com on Wed Jan 29 19:20:58 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, "clindh2 <clindh+h...>" <clindh+h...>
wrote:
> I'm loading a GPX from geocaching.com but my XMLSpy complains:
>
> Your schema uses attributeFormDefault="qualified" -
> you must specify a prefix for your schema
> namespace "http://www.topografix.com/GPX/1.0
>
> a) I would like to understand the error message; what is wrong
> b) I assume they did something wrong when producing that gpx-
file.
> Can we help to get it right? It adds elements from their own
schema:
>
<gpx
xmlns="http://www.topografix.com/GPX/1/0"
version="1.0" creator="Wissenbach Map 2.0.3"
xmlns:wissenbach="http://www.cableone.net/cdwissenbach"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0
http://www.topografix.com/GPX/1/0/gpx.xsd
http://www.cableone.net/cdwissenbach
http://www.cableone.net/cdwissenbach/wissenbach.xsd">
The above is a output from Wissenbach Map. You'll find many such
files at
http://myweb.cableone.net/cdwissenbach/
I think that what they did wrong is leave out
xmlns="http://www.topografix.com/GPX/1/0"
Because this is xmlns instead of xmlns:gpx, the validator knows that
unqualified attributes are in the GPX namespace. The section on
schema location doesn't help the validator determine which attribute
qualifier goes with which namespace.
They also left out xmlns:groundspeak= in the gpx element. So
although groundspeak documents may validate on their own, they
probably won't.
But really, your guess is as good as mine
Dave
> ---------------
> <?xml version="1.0" encoding="utf-8"?>
> <gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="1.0"
> creator="Groundspeak Pocket Query"
> xsi:schemaLocation="http://www.topografix.com/GPX/1/0
> http://www.topografix.com/GPX/1/0/gpx.xsd
> http://www.groundspeak.com/cache/1/0
> http://www.groundspeak.com/cache/1/0/cache.xsd"
> xmlns="http://www.topografix.com/GPX/1/0">
>
> <author>Groundspeak</author>
> ...
> <wpt lat="57.69665" lon="11.979283">
> <time>2001-04-03T00:00:00.0000000-07:00</time>
> ...
> <groundspeak:cache id="1538" available="True"
> xmlns:groundspeak="http://www.groundspeak.com/cache/1/0">
> <groundspeak:name>Americana
> Cache</groundspeak:name>
> ...
clindh+homenet.se on Thu Jan 30 08:32:35 2003 (link)
Interesting, tell me more ;-)
I completed my XSL for waypoints yesterday; my main use is to import geocaches so I can see them on detailed maps.
----- Original Message -----
From: Chris Schulz
To: gpsxml+yahoogroups.com
Sent: Wednesday, January 29, 2003 21:51
Subject: Re: [gpsxml] GPX to OziExplorer
no, but i have a gpx<->ozi<->gpx parser too!!
perhaps we could swap and steal each others ideas?
c.
At 12:48 29/01/2003 +0000, you wrote:
>I plan on writing an XSL, creating "Map Features" for OziExplorer. I
>have written one for .loc -> ozi waypoint files already.
>
>But before I get busy, has anyone done this already...?
>
>
>
>Yahoo! Groups Sponsor
>ADVERTISEMENT
><http://rd.yahoo.com/M=233351.2876045.4223503.2848452/D=egroupweb/S=1706030390:HM/A=1341247/R=0/*https://www.gotomypc.com/tr/yh/grp/300_mapG/g22lp?Target=mm/g22lp.tmpl>e0ae559.jpg
>
>e0ae5fa.jpg
>
>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.
Yahoo! Groups Sponsor
ADVERTISEMENT
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.
------?extPart_000_05AC_01C2C885.8E5A8DE0
robertlipe+usa.net on Thu Jan 30 09:16:40 2003 (link), replying to msg
> I plan on writing an XSL, creating "Map Features" for OziExplorer. I > have written one for .loc -> ozi waypoint files already. It's not XSL, but GPSBabel (http://gpsbabel.sourceforge.net) reads and writes all three of those formats plus about two dozen others. RJL
robertlipe+usa.net on Thu Jan 30 09:18:58 2003 (link), replying to msg
> I'm loading a GPX from geocaching.com but my XMLSpy complains: That's depressingly easy to do. I frequently get complaints from users of geocaching.com's GPX files that gpsbabel is choking on them. Every time I've analyzed it, it's been illegal characters in logs, but your case looks different. RJL
robertlipe+usa.net on Thu Jan 30 14:48:19 2003 (link), replying to msg
> yes... but not very well... symbols and other attributes are not > transformed, basically lat, lon and name only. They're transformed for some file types and not for others. Contributions to the icon mapping tables are welcome. Since I don't use Ozi, I wasn't motivated to do it. RJL
clindh+homenet.se on Mon Feb 03 02:25:32 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, "clindh2 <clindh+h...>" <clindh+h...> wrote: > I plan on writing an XSL, creating "Map Features" for OziExplorer. OK, if anyone is interested I know have - XSL for transforming GPX to Ozi .wpt-format - XSL for transforming GPX + groundspeak:cache to HTML - Perl-script for splitting the output from the HTML-XSL into individual files I created these to have a local store for information about geocaches in my area. The .wpt-file is created so each waypoint points to an attached file; the HTML-file created by the HTML-converter. Thus it's easy to look up information about caches even when not online.
gpx+andrew-stock.com on Mon Mar 03 01:50:16 2003 (link)
Hi, I have written a program for my pocket pc to plot my position and save the route I've taken as a <rte> in gpx format. The output files from the program validate fine as explained on the topografix website, but when I try to open them in EasyGPS (or GPS Utility) it appears that there's no data there. Below is a cut down extract which also validates and doesn't load. I would really appreciate it if anyone could suggest something that I've missed as I'm fairly new to this. Regards Andrew <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> <gpx version = "1.0" creator = "CE Moving Map" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns = "http://www.topografix.com/GPX/1/0" xmlns:topografix = "http://www.topografix.com/GPX/Private/TopoGrafix/0/2" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.topografix.com/GPX/Private/TopoGrafix/0/2 http://www.topografix.com/GPX/Private/TopoGrafix/0/2/topografix.xsd"> <rte> <name>Test Route</name> <rtept lat="52.1971216666667" lon="0.124701666666667"> <name>Point 1</name> </rtept> <rtept lat="52.197135" lon="0.124698333333333"> <name>Point 2</name> </rtept> <rtept lat="52.1971483333333" lon="0.124701666666667"> <name>Point 3</name> </rtept> <rtept lat="52.1971566666667" lon="0.124695"> <name>Point 4</name> </rtept> <rtept lat="52.19716" lon="0.124683333333333"> <name>Point 5</name> </rtept> </rte> </gpx>
egroups+topografix.com on Mon Mar 03 11:48:10 2003 (link), replying to msg
Hello, Monday, March 3, 2003, 4:43:35 AM, Andrew wrote: a> Hi, a> I have written a program for my pocket pc to plot my position and a> save the route I've taken as a <rte> in gpx format. The output a> files from the program validate fine as explained on the topografix a> website, but when I try to open them in EasyGPS (or GPS Utility) it a> appears that there's no data there. a> Below is a cut down extract which also validates and doesn't load. a> I would really appreciate it if anyone could suggest something that a> I've missed as I'm fairly new to this. a> Regards a> Andrew a> <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> a> <gpx a> version = "1.0" a> creator = "CE Moving Map" a> xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" a> xmlns = "http://www.topografix.com/GPX/1/0" a> xmlns:topografix a> = "http://www.topografix.com/GPX/Private/TopoGrafix/0/2" a> xsi:schemaLocation="http://www.topografix.com/GPX/1/0 a> http://www.topografix.com/GPX/1/0/gpx.xsd a> http://www.topografix.com/GPX/Private/TopoGrafix/0/2 a> http://www.topografix.com/GPX/Private/TopoGrafix/0/2/topografix.xsd"> Your GPX file passes the validator test, so it's a legal file. EasyGPS is broken. I traced the problem to the spacing around the equal sign in lines like version = "1.0" - most XML files are spaced this way: version="1.0". I fixed the problem in EasyGPS and the rest of my programs. By the way, you shouldn't include the TopoGrafix private namespace in your files unless you're actually using something from them. (And I should probably fix EasyGPS to only include them where needed.) Keep us posted on your PocketPC application! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
murphy+enterprise.net on Tue Mar 04 05:20:04 2003 (link), replying to msg
Andrew, Which version of GPS Utility are you using? I used the current standard version of GPSU (4.04.7) to open your extracted file OK. If you have a file that does not open in GPSU 4.04.7, then please send it me so I can examine the problem. Alan Murphy (author GPSU) On 4 Mar 2003 09:32:52 -0000, you wrote: > Date: Mon, 03 Mar 2003 09:43:35 -0000 > From: "andrew_c_stock <gpx+andrew-stock.com>" <gpx+andrew-stock.com> >Subject: Validated file doesn't open > >Hi, > >I have written a program for my pocket pc to plot my position and >save the route I've taken as a <rte> in gpx format. The output >files from the program validate fine as explained on the topografix >website, but when I try to open them in EasyGPS (or GPS Utility) it >appears that there's no data there. > >Below is a cut down extract which also validates and doesn't load. >I would really appreciate it if anyone could suggest something that >I've missed as I'm fairly new to this. > >Regards > >Andrew
acs39+cam.ac.uk on Tue Mar 04 06:43:25 2003 (link)
Hi,
First of all thanks for the support on this! I have attached a file
(Route.gpx) which I have tried opening in GPS Utility 4.04.7. I am not sure
whether this is just me using the program incorrectly! I load the file and
then go to View -> Routes and I get the name "Test Route" appear as one of
the routes, but under it it just says POINT and has only one.
I wondered whether this was a limitation of the free version not having so I
tried with another file with only 5 data points and I can't get this to
appear. It's quite possible that I'm mis-using your program!
Regards
Andrew
----- Original Message -----
From: Alan Murphy
To: gpsxml+yahoogroups.com
Sent: Tuesday, March 04, 2003 1:20 PM
Subject: [gpsxml] Re: Validated file doesn't open
Andrew,
Which version of GPS Utility are you using? I used the current
standard version of GPSU (4.04.7) to open your extracted file OK.
If you have a file that does not open in GPSU 4.04.7, then please send
it me so I can examine the problem.
Alan Murphy (author GPSU)
On 4 Mar 2003 09:32:52 -0000, you wrote:
> Date: Mon, 03 Mar 2003 09:43:35 -0000
> From: "andrew_c_stock <gpx+andrew-stock.com>" <gpx+andrew-stock.com>
>Subject: Validated file doesn't open
>
>Hi,
>
>I have written a program for my pocket pc to plot my position and
>save the route I've taken as a <rte> in gpx format. The output
>files from the program validate fine as explained on the topografix
>website, but when I try to open them in EasyGPS (or GPS Utility) it
>appears that there's no data there.
>
>Below is a cut down extract which also validates and doesn't load.
>I would really appreciate it if anyone could suggest something that
>I've missed as I'm fairly new to this.
>
>Regards
>
>Andrew
Yahoo! Groups Sponsor
ADVERTISEMENT
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.
------?extPart_001_012D_01C2E25C.6AEEAAD0
murphy+enterprise.net on Wed Mar 05 11:10:03 2003 (link), replying to msg
Thanks for your files. The problem is that default length for Waypoint ID name in GPSU is set to 6 characters and GPSU is not changing this default setting on reading a GPX file. Thus your waypoints with names 'POINT 1' etc. are all being truncated to 'POINT ' (6 chars). This is a bug, which I have now fixed. The fix will be in the next version which will be released in a day or so. (4.04.8). The workarounds are 1) Select Options|Field Properties in GPSU and manually set the ID length to, say, 10 characters. GPSU version 4.04.7 will then read your Route2.gpx file. 2). Write your file with IDs no longer than 6 characters. Your 'Route.gpx' file exceeds the capacity limitations of the freeware version and so this file cannot be fully read in. (It contains 346 waypoints). Many thanks for the bug report. Alan Murphy (author GPSU) On 5 Mar 2003 09:38:45 -0000, you wrote: >Message: 2 > Date: Tue, 4 Mar 2003 14:43:27 -0000 > From: "Andrew Stock" <acs39+cam.ac.uk> >Subject: Re: Re: Validated file doesn't open > >Hi, > >First of all thanks for the support on this! I have attached a file >(Route.gpx) which I have tried opening in GPS Utility 4.04.7. I am not sure >whether this is just me using the program incorrectly! I load the file and >then go to View -> Routes and I get the name "Test Route" appear as one of >the routes, but under it it just says POINT and has only one. >I wondered whether this was a limitation of the free version not having so I >tried with another file with only 5 data points and I can't get this to >appear. It's quite possible that I'm mis-using your program! >Regards > >Andrew >
fred96161+usamedia.tv on Wed Mar 05 16:02:44 2003 (link)
GPXchange.com is in development. It will serve as a central database for authors to make their GPX data available on a free or commercial basis. The rapid evolution of our other sites, Offroute.com and Topostore.com will provide a high profile mechanism for encouraging the adoption and use of this valuable file format. Visit www.topostore.com/index.asp?ref=ng for an example of where GPX files will soon be visible. The founders of Offroute, Inc. have a combined history in the Outdoor Industry of approximately 40 years. Both built successful multi-million dollar companies in the past and intend to leverage their knowledge and relationships within the outdoor industry to promote the widespread adoption of GPX. Please visit www.GPXchange.com for more pre-launch information. We are anxious to hear suggestions, comments and criticisms regarding our plans and a link is provided for that purpose. Coming from the perspective of active outdoor enthusiasts, it is our intent to provide a mechanism to disseminate GPX data as it provides access to information that will otherwise remain unavailable on published maps or in guidebooks. Our thanks to all of those who have worked hard to create and maintain the current GPX schema. Fred Williams Co-founder, Offroute, Inc.
gps_maps+yahoo.com on Sun Mar 09 02:42:04 2003 (link)
The announcement of GPXchange motivates me catch-up on GPX
development. Back in April 2002, I commented here (message 256) on
how the examples I'd seen "lack richness." At the time, no one had
published any GPX pages that included elements I felt essential to
describing the embedded GPS data - like pictures and tables. Now,
I've gone back to look at the examples linked from
http://www.topografix.com/gpx_sample_files.asp and it seems that
little has changed in regard to the look of the pages. The examples
still read vertically, from top to bottom using font and indention to
set apart content. Are there other examples I should look at?
- Doug Adomatis
www.travelbygps.com
Moderator, Map Authors Group
http://groups.yahoo.com/group/map_authors/
mroseto+qcicleveland.com on Mon Mar 10 11:21:18 2003 (link)
Is there any way to upload driving directions from an internet source into expertgps? I used to be able to with mapblast but modifications to the website has eliminated this possiblity. Thanks for the help in advance. Mike
murphy+enterprise.net on Tue Mar 11 02:06:07 2003 (link), replying to msg
You could try MapsOnUs (www.mapsonus.com) and GPS Utility (www.gpsu.co.uk). GPSU will read html files produced by MapsOnUs and export the data as a GPX interchange file which you can import to ExpertGPS. See the Help topic on 'MapsOnUs' European users can use Greenflag (www.greenflag.com) instead of MapsOnUs. The freeware version of GPSU is capacity limited, but more or less fully functional. See the Help topic on 'Freeware' for details. HTH Alan Murphy (author GPSU) On 11 Mar 2003 08:25:17 -0000, you wrote: > Date: Mon, 10 Mar 2003 19:21:11 -0000 > From: "mroseto729" <mroseto+qcicleveland.com> >Subject: Driving Directions and Expertgps > >Is there any way to upload driving directions from an internet source >into expertgps? I used to be able to with mapblast but modifications >to the website has eliminated this possiblity. Thanks for the help in >advance. >
pablogh_2000+yahoo.com on Mon Mar 24 08:19:44 2003 (link)
Hi all, I have to develop a GPS tracking application for industry vehicles. What I want to do is: 1. read NMEA data from the GPS devices, 2. read other data specific to vehicles, 3. send it to a sever, where they will put together in a GML file, 4. send this GML file to the GeoServer free application to save the data in a PostGIS database, 5. read the updated data with MapServer. My problem comes in point 3. Do you know how to solve this matter? Thanks in advance, and sorry for any inconviniences. Regards, Pablo Ghiglino
gps_maps+travelbygps.com on Fri Mar 28 03:45:43 2003 (link)
Here is an article I've written in response to the introduction of GPXchange.com. Your comments are welcome. ---------- Finding your way is getting a little easier, but it may cost you a little more. Offroute, Inc.'s GPXchange(tm) promises widespread adoption of a common GPS data format by hosting a large central database and charging for its use. While commercializing the customarily free practice of exchanging GPS data may be distasteful to some, the proposed business model is appealing to freelance authors who create quality trail guide content. Traditionally, if you wanted to find the geographic coordinates for points of interest in poorly documented places, you would post your query to Internet newsgroups. And if you were lucky, some kind soul would reply, pointing you to a collection of GPS data somewhere on the web. GPS data collections found online are mostly lists of coordinates (waypoints) in various forms. If you were just looking for a single point - say a dive site on the Great Barrier Reef - it would be simple enough to write down the latitude and longitude, but if you needed an entire route (a series of waypoints) or an even a more detailed track, you would hope to find a data file. However, there is no standard format for these GPS data files, which makes it difficult to share them unless each person uses software capable of reading the other's files. In September 2001, a forum of developers started creating a common format for exchanging GPS data, called GPX. The GPX format is based on Extensible Markup Language (XML), which is ideally suited for the interchange of data between applications and Internet services. Within a few months, development was completed on the basic GPX schema, which effectively stores and presents GPS waypoints, routes and tracks. The GPX format caught the eye of Offroute, which has adopted it as the basis for a large, commercialized central database - GPXchange. The pre-launch information at www.gpxchange.com describes a plan whereby consumers and contributing authors will be charged fees to download GPX files and pay for use of the database facilities. Authors will be able to charge consumers for downloading their files, which will help them recover subscriptions fees, but - and here's the rub - consumers will have to pay a transaction fee even if the author designates his files as free. In the introduction of GPXchange.com to the GPX developer's forum, three questions were posed to those who object to its commercial aspects. Although I do not necessarily object, I would like to offer my feedback along with some examples of how I address related issues. 1. Will GPX ever truly realize its potential if a high-quality, central database is not in place that provides easy access to the wealth of data it can provide? I think that realization of GPX's potential depends more on how many applications adopt the format, rather than how many databases (or how few) host GPX files. That said, I do believe that GPXchange will indeed help the GPX format flourish in areas where Offroute and its partners have an interest. The basic GPX format can be extended to include more than just GPS data. The pre-launch information indicates that Offroute is developing applications for authors to create and manage GPX files - files that can include guidebook-like images and text. In that respect, it would seem appropriate for traditional authors/ travel writers to use the GPX format for communicating guidebook information. I'll say more about printed materials in a moment. Return now to the idea of exchanging data between GPS navigation and mapping software applications. In the absence of a standard, at Travel by GPS (www.travelbygps.com) I often publish more than one format for the same data. Typically, I will provide a free data file in GPX or another format that can be read by free software. In many cases I also provide data in the format most suited for the adventure. For example, most of my self-drive sightseeing maps are in Delorme's (.dmt) Map Transfer format for use with Street Atlas(r) car-navigation software. This format allows me to use drawing layers and driving directions to more effectively communicate GPS-guided tour information. Publishing multiple formats is a hassle, but until a standard is adopted, I find it necessary. 2. Will the information housed within this centralized database grow dramatically in size and quality without a means to compensate authors for their efforts and expertise? While offering compensation may increase the number of contributions, the quality of the database as a whole may diminish unless measures are taken to discourage authors from cranking out junk and passing it off as first-rate. Quality of content is important to me at Travel by GPS. First and foremost, I am the editor-in-chief, and I enjoy building relationships with every contributor. In addition to my personal assurances, there are quality indicators on each GPS Map description page. Each GPS Map has a data classification rating so that patrons will know what to expect in regard to accuracy of the data provided. Hans Wain, Offroute co-founder, explained the quality measures that are to be employed at GPXchange. Wain explains that every publicly posted GPX file at GPXchange will include user reviews as they become available, and authors will be reviewed and rated separately from the individual files. While compensating authors for quality content is good, protecting their works from unauthorized distribution is even more important. The basic GPX format does not include any copyright protection elements. So, the distributors of protected material must shoulder more of the burden. The founders of GPXchange have shown their intent to keep intellectual property safe, but in reality there is little you can do to prevent someone from acquiring information legitimately and redistributing it. At Travel by GPS, stealing GPS data is not an issue because I seek permission from every contributor to freely provide their information without restriction. 3. And finally, regardless of depth and quality of the database, won't more potential users of this information benefit if it is actively promoted by a network of both physical and online entities that facilitate its use through printed representations as well as downloads alone? Build-it and they will come. The number of people who own a GPS is increasing, and to a lesser degree, the number of people who have the ability and desire to download GPS data is also increasing. Offering GPX data overlays with custom maps and documents will indeed help expand the market to include those who have yet to be bitten by the GPS bug. GPXchange will not be the first online endeavor to offer printable mini-guides for outdoor recreation. Trails.com offers trail guides for activities like hiking, biking, and paddling called eTrails (not to be confused with eTRAIL CD-ROM of UK walking routes by Garmin Europe Ltd/Emap Active Ltd). Each eTrail includes detailed trail descriptions, directions to the trailhead, and custom map images. The eTrail format can be opened by Adobe Acrobat eBook Reader and printed out on your home computer. eTrail downloads do not include GPS data, and they are not authored by individual contributors. eTrail content comes from published guidebooks, like those from Falcon Publishing. Early on, I realized the value of overlaying the GPS data on printable maps and mini-guides. In 1999 and 2000, I published printable GPS Guides as companions to my "17-Mile Drive", "Historic Charleston", "Chattahoochee River", and "Mobile Bay GPS Maps". These guides included map images, detailed waypoint and route descriptions, driving directions, trail length/difficulty tables, and a scenic photo in paper form, which could be stuffed in a back pocket or glove box. I decided to stop producing the printable guides because they took too much time to write and maintain without compensation. Providing a means of compensation is where I believe GPXchange offers a great opportunity for freelance authors. Moreover, GPXchange will provide authors with greater exposure to wider audience - an audience willing to pay for quality trail guides. In regard to the GPXchange business model, Wain explains that the "barriers will be extremely low" for authors and that transaction fees for consumers will be on the order of cents, not dollars. Wain goes on to explain that the profitability of GPXchange will depend more on other commercial aspects and depend less on author subscription and consumer transactions fees. As for Travel by GPS, I plan to continue providing free GPS maps waypoints and tracks for adventure travel. As for Doug Adomatis, freelance author, having another outlet for publishing trail guides is appealing. I hope this helps! Doug Adomatis Owner, Travel by GPS (www.travelbygps.com)
ptomblin+xcski.com on Sun Mar 30 17:58:16 2003 (link)
Allow me to introduce myself. I have a web site, http://navaid.com/, where I allow end users to generate aviation databases for two Palm OS programs used for flight planning, CoPilot (http://navaid.com/CoPilot/) and GPSPilot (http://navaid.com/GPSPilot/). One of the common requests I have is for files that people can load into their GPSes - but I never could figure out what sort of format would be best for each type of GPS. It looks like GPX is exactly what I need. Is anybody out there making GPX files using Perl? Do you have any special tools to do so, or just rolling your own? -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody "I think there is a world market for maybe five computers." --Thomas Watson, chairman of IBM, 1943.
robertlipe+usa.net on Sun Mar 30 18:50:16 2003 (link)
Paul Tomblin <ptomblin+xcski.com> wrote: > One of the common requests I > have is for files that people can load into their GPSes - but I never > could figure out what sort of format would be best for each type of GPS. > It looks like GPX is exactly what I need. Parsing GPX files with XML::Twig isn't too terrible at all. It delivers a callback with members that can be iterated through pretty easily. If I understand the goal of your site correctly, yes, GPX sounds like just the ticket for you. It allows you to deliver the data and then let the end-user pick whatever tool he wants to use for plunking them onto a map or stuffing them into a receiver or so on. There's a growing number of GPX-capable programs at: http://www.topografix.com/gpx_resources.asp
ptomblin+xcski.com on Mon Mar 31 17:25:45 2003 (link)
How much room does your average GPS have for extra text? My CoPilot and GPSPilot databases give all sorts of extra information for the waypoint, like runway designations and lengths and communications frequencies, and I'm wondering how much room I've got for extra information. My Garmin 195 isn't handy right now, but I seem to recall it only had about a hundred characters or of storage for user defined waypoints, so not enough for that sort of thing. Is there any point putting all this extra info in the xml file? If so, what field should I use? Also, can I put newlines in a text field? Do I put real newlines, or "\n"? -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody Quando omni flunkus moritati (when all else fails play dead)
egroups+topografix.com on Tue Apr 01 10:10:07 2003 (link), replying to msg
Hello Paul, Monday, March 31, 2003, 8:24:12 PM, you wrote: P> How much room does your average GPS have for extra text? My CoPilot and P> GPSPilot databases give all sorts of extra information for the waypoint, P> like runway designations and lengths and communications frequencies, and P> I'm wondering how much room I've got for extra information. My P> Garmin 195 isn't handy right now, but I seem to recall it only had about a P> hundred characters or of storage for user defined waypoints, so not enough P> for that sort of thing. P> Is there any point putting all this extra info in the xml file? If so, P> what field should I use? P> Also, can I put newlines in a text field? Do I put real newlines, or P> "\n"? I'd suggest putting as much private information as possible in the GPX files you create. If it's in there, someone will find a way to use it. A good example is the way that geocaching.com is using GPX. They're putting lots of private data in their GPX files, all defined within their private "groundspeak" schema. None of that data makes it to GPS receivers by default, but there's a whole group of add-on programs that have sprung up to convert and display that extra data. A similar thing should be done for aviation data. You might want to get together with the guys at http://www.aeroplanner.com, who already use XML for distributing data, and have expressed an interest in GPX. If you can come to an agreement on a standardized private namespace for aviation extensions to GPX, then you'll probably find that users will start creating applications to use the extra data in your GPX files. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
ptomblin+xcski.com on Tue Apr 01 10:39:20 2003 (link), replying to msg
Quoting Dan Foster (egroups+topografix.com): > > P> Is there any point putting all this extra info in the xml file? If so, > P> what field should I use? > A similar thing should be done for aviation data. You might want to > get together with the guys at http://www.aeroplanner.com, who already > use XML for distributing data, and have expressed an interest in GPX. > If you can come to an agreement on a standardized private namespace > for aviation extensions to GPX, then you'll probably find that users > will start creating applications to use the extra data in your GPX > files. Thanks to Brian Scearce, I now have a copy of gpsbabel. I think, since I already know the format of CoPilot and GPSPilot (and I think FlyByNav, which I reverse engineered a while ago before told me that they'd "make life difficult" if I were to make a waypoint generator for them), I may make my generator for GPX do the basics, and then write translator code for gpsbabel for those format. BTW: This is what I have so far for my wpt records. Does it look right to you? <wpt lat="37.6592777777778" lon="-122.122416666667"> <name>KHWD</name> <elev>50</elev> <cmt><![CDATA[HAYWARD EXECUTIVE,HAYWARD,CA,US]]></cmt> <type><![CDATA[AIRPORT]]></type> <src><![CDATA[FAA]]></src> </wpt> Actually, since "type" and "src" can only have letters, slashes and dashes, I'm probably going to eliminate the CDATA escape for those. -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody Company slogan: The Mandatory Beatings Will Continue Until Morale Improves.
robertlipe+usa.net on Tue Apr 01 10:55:56 2003 (link), replying to msg
Paul Tomblin wrote: > Thanks to Brian Scearce, I now have a copy of gpsbabel. I think, since I While I appreciate Brian's hand, GPSBabel shouldn't be hard to get. It's free and it's open. http://gpsbabel.sourceforge.net > already know the format of CoPilot and GPSPilot (and I think FlyByNav, > which I reverse engineered a while ago before told me that they'd "make > life difficult" if I were to make a waypoint generator for them), I may > make my generator for GPX do the basics, and then write translator code > for gpsbabel for those format. If the code comes with a promise that someone is going to "make life difficult", please feel free to NOT contribute that code to GPSBabel. :-) But you certainly have the right idea: write the data once as GPX and then let converters like GPSBabel sling them to GPSes and other applications that have not yet seen the light of GPX. > BTW: This is what I have so far for my wpt records. Does it look right to > you? The authoritative question is, "how does it look to a validating parser?" Grab a copy of SAXCount (it, too, is free and open) and point it at your output. RJL
ptomblin+xcski.com on Tue Apr 01 12:34:27 2003 (link), replying to msg
Quoting Robert Lipe (robertlipe+usa.net): > Paul Tomblin wrote: > > > Thanks to Brian Scearce, I now have a copy of gpsbabel. I think, since I > > While I appreciate Brian's hand, GPSBabel shouldn't be hard to get. > It's free and it's open. http://gpsbabel.sourceforge.net What I mean is that Brian told me about it. I'd never heard of it before. > > BTW: This is what I have so far for my wpt records. Does it look right to > > you? > > The authoritative question is, "how does it look to a validating > parser?" Grab a copy of SAXCount (it, too, is free and open) and point > it at your output. SAXCount counted the elements. That tells me that it's valid XML, it doesn't tell me if it looks like I've got the wrong idea about what should be going in the <cmt> field or I've got the sign of my longitudes backwards or something. BTW: Does EasyGPS work under Wine? I can't seem to get it to work. -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody Experience is that marvelous thing that enables you recognize a mistake when you make it again. -- F. P. Jones
robertlipe+usa.net on Tue Apr 01 12:44:35 2003 (link)
> SAXCount counted the elements. That tells me that it's valid XML, That's good. > it > doesn't tell me if it looks like I've got the wrong idea about what should > be going in the <cmt> field or I've got the sign of my longitudes > backwards or something. You'll want to do sanity checks by laying them on a mapping program to catch that case. By quick inspection, your stuff looked believable to me. > BTW: Does EasyGPS work under Wine? I can't seem to get it to work. I was never able to make it work, but I'm not much of a Wine-o. Needing something that read geocaching.locs and wrote to magellans that ran under UNIX was the original motivation for what became GPSBabel. :-) RJL
ptomblin+xcski.com on Tue Apr 01 17:56:05 2003 (link)
I've got a preliminary cut of my "GPX Aviation Waypoint Generator" up at http://navaid.com/GPX/ Go there and choose the area of the world and the types of waypoints you want, and it will generate it and you can download it. Obviously I need to do a proper logo for it, but other than that it seems like it's working. -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody UNIX was half a billion (500000000) seconds old on Tue Nov 5 00:53:20 1985 GMT (measuring since the time(2) epoch). -- Andy Tannenbaum
ptomblin+xcski.com on Wed Apr 02 06:05:07 2003 (link), replying to msg
Quoting Robert Lipe (robertlipe+usa.net):
>
> You might want to set the mime type on the actual file being output so
> that the browser can know what to do with the data ("save as..." or
> "open with...") instead of just splashing it to the user for text.
Unfortunately it's whatever apache on the hosting company sets by default
for gpx file. I don't know how to override that in .htaccess.
--
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of mind-
boggling amounts of excrement when you least expect it." - spaf (1992)
ptomblin+xcski.com on Wed Apr 02 15:10:14 2003 (link), replying to msg
Quoting Robert Lipe (robertlipe+usa.net):
> You might want to set the mime type on the actual file being output so
> that the browser can know what to do with the data ("save as..." or
> "open with...") instead of just splashing it to the user for text.
I figured out how to do that in the .htaccess file. Now it's
application/octet-stream, so it gets saved.
I've also got a logo and fixed the donation page links, so I think it's
ready for prime time.
--
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
"We all agree that your theory is crazy, but is it crazy enough?"
- Niels Bohr (1885-1962)
ptomblin+xcski.com on Wed Apr 02 15:25:46 2003 (link), replying to msg
Quoting Robert Lipe (robertlipe+usa.net): > > I figured out how to do that in the .htaccess file. Now it's > > application/octet-stream, so it gets saved. > > You really want it to be something that triggers a specific application > to be launched that knows how to handle it. Look at the geocaching > stuff for an example of how this can work. Is there a common mime type for GPX files? -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody "Leave the beaten track occasionally, and dive into the woods. You will be certain to find something that you have never seen before." -- Alexander Graham Bell
chris+groundspeak.com on Wed Apr 02 15:35:04 2003 (link), replying to msg
If you just want to send a GPX file down from a web server, you should serve it as text/xml. So, not being familiar with htaccess that well, I would guess something like: AddType text/xml .gpx Chris -----Original Message----- From: Paul Tomblin [mailto:ptomblin+xcski.com] Sent: Wednesday, April 02, 2003 3:24 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Nearly ready Quoting Robert Lipe (robertlipe+usa.net): > > I figured out how to do that in the .htaccess file. Now it's > > application/octet-stream, so it gets saved. > > You really want it to be something that triggers a specific application > to be launched that knows how to handle it. Look at the geocaching > stuff for an example of how this can work. Is there a common mime type for GPX files? -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody "Leave the beaten track occasionally, and dive into the woods. You will be certain to find something that you have never seen before." -- Alexander Graham Bell Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=245454.3115308.4434529.1728375/D=egroupweb/S=1706 030390:HM/A=1457554/R=0/*http:/ipunda.com/clk/beibunmaisuiyuiwabei> <http://us.adserver.yahoo.com/l?M=245454.3115308.4434529.1728375/D=egrou pmail/S=:HM/A=1457554/rand=970646635> To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. ------=_NextPart_000_0001_01C2F92D.73D30910
ptomblin+xcski.com on Wed Apr 02 16:33:28 2003 (link), replying to msg
Quoting Chris Jones (chris+groundspeak.com): > If you just want to send a GPX file down from a web server, you should > serve it as text/xml. No, when I do that, my browser displays as text without the xml tags. I think it's trying to interpret it as XML. -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody "I have traveled the length and breadth of this country and talked with the best people, and I can assure you that data processing is a fad that won't last out the year." --Editor of business books for Prentice Hall, 1957.
chris+groundspeak.com on Wed Apr 02 17:08:39 2003 (link), replying to msg
GPX is XML. So text/xml is a valid mime-type. You can't tell the browser what application to use for a file from the web server-- you can only tell the browser what type of file it is-that's what a mime-type is. By giving a mime-type, you are helping the browser to "guess" what to do with it. Your browser apparently doesn't know what an XML file is, so it treats it like HTML and strips out the markup, leaving the words. My browser on the other hand knows about the xml mime type, and treats the GPX file as XML and shows it to me parsed in color (IE 6). So you have two choices: If you turn the mime-type off completely, the user should be prompted to choose an application if they haven't already associated one. If you associate a mime-type on the server, the browser will guess. If you choose the latter, the correct mime type is XML. I would recommend not providing a mime-type if you just want people to download the file. This will make most browsers prompt the user to either save the file to disk, or to choose and application to open it with. They can usually make that associate permanent, and never be bothered again. Chris -----Original Message----- From: Paul Tomblin [mailto:ptomblin+xcski.com] Sent: Wednesday, April 02, 2003 4:31 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Nearly ready Quoting Chris Jones (chris+groundspeak.com): > If you just want to send a GPX file down from a web server, you should > serve it as text/xml. No, when I do that, my browser displays as text without the xml tags. I think it's trying to interpret it as XML. -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody "I have traveled the length and breadth of this country and talked with the best people, and I can assure you that data processing is a fad that won't last out the year." --Editor of business books for Prentice Hall, 1957. Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=246920.2960106.4328965.1728375/D=egroupweb/S=1706 030390:HM/A=1513704/R=0/*http:/www.gotomypc.com/u/tr/yh/cpm/grp/300_02F/ g22lp?Target=mm/g22lp.tmpl> <http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.1728375/D=egrou pmail/S=:HM/A=1513704/rand=192692354> To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. ------=_NextPart_000_0001_01C2F93A.85F3EC10
chris+groundspeak.com on Thu Apr 03 10:47:15 2003 (link)
Right - that's why I said you have two choices. You can associate it with the only correct mime type that exists today (XML), or make the user choose an application. There is no mime type (yet) for GPX. Short of creating an entirely new mime-type (which matters not until browser makers adopt it) it's the only answer for serving the file raw from a web server. And even if you add a mime type for .gpx, and browser makers adopt it, the user will still have to choose which application handles GPX files, so you're back to the beginning. I would just serve it raw. -----Original Message----- From: Robert Lipe [mailto:robertlipe+usa.net] Sent: Wednesday, April 02, 2003 7:29 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Nearly ready Chris Jones wrote: > I would recommend not providing a mime-type if you just want people to > download the file. This will make most browsers prompt the user to > either save the file to disk, or to choose and application to open it > with. They can usually make that associate permanent, and never be > bothered again. But if you just let it default to application/binary (or whatever the original suggestion was) there's no way for the browser to associate the data with an actual program becuase it doesn't know *what* the data is; that's the whole point of the mime type. RJL Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=245454.3115308.4434529.1728375/D=egroupweb/S=1706 030390:HM/A=1457554/R=0/*http:/ipunda.com/clk/beibunmaisuiyuiwabei> <http://us.adserver.yahoo.com/l?M=245454.3115308.4434529.1728375/D=egrou pmail/S=:HM/A=1457554/rand=963479195> To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. ------=_NextPart_000_0005_01C2F9CE.62DDAFB0
ptomblin+xcski.com on Thu Apr 03 10:55:00 2003 (link), replying to msg
Quoting Chris Jones (chris+groundspeak.com): > Right - that's why I said you have two choices. You can associate it > with the only correct mime type that exists today (XML), or make the The problem with that is that every browser I've ever seen "handles" text/xml by displaying it. That's not what should happen when you download a GPX file - it should either save it, or launch a helper application. > user choose an application. There is no mime type (yet) for GPX. Short > of creating an entirely new mime-type (which matters not until browser > makers adopt it) it's the only answer for serving the file raw from a Browser makers don't have to adopt it. I don't know about IE because I don't use it, but a *good* browser (Mozilla, Safari, Konqueror, Chimera, Opera) lets the user set up their own handler for a particular mime-type. So if I were to make it application/gpx, then people could choose whatever GPX program they have to launch it, or save it. -- Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody Quality Control, n.: The process of testing one out of every 1,000 units coming off a production line to make sure that at least one out of 100 works.
chris+groundspeak.com on Thu Apr 03 11:07:41 2003 (link)
Sorry, I misunderstood. I thought you didn't want users to have to do
anything. It was my original suggestion to let the user choose an
application. Yes, they can do this by registering a mime-type in their
browser (like application/gpx), or when they try to download a .gpx file
for the first time, their browser will prompt them to save it to disk or
choose an application. So its an exactly equivalent amount of work for
the users: they have to associate GPX with an application on their
machine, so these solutions are equivalent.
-----Original Message-----
From: Paul Tomblin [mailto:ptomblin+xcski.com]
Sent: Thursday, April 03, 2003 10:53 AM
To: gpsxml+yahoogroups.com
Subject: Re: [gpsxml] Nearly ready
Quoting Chris Jones (chris+groundspeak.com):
> Right - that's why I said you have two choices. You can associate it
> with the only correct mime type that exists today (XML), or make the
The problem with that is that every browser I've ever seen "handles"
text/xml by displaying it. That's not what should happen when you
download a GPX file - it should either save it, or launch a helper
application.
> user choose an application. There is no mime type (yet) for GPX.
Short
> of creating an entirely new mime-type (which matters not until browser
> makers adopt it) it's the only answer for serving the file raw from a
Browser makers don't have to adopt it. I don't know about IE because I
don't use it, but a *good* browser (Mozilla, Safari, Konqueror, Chimera,
Opera) lets the user set up their own handler for a particular
mime-type.
So if I were to make it application/gpx, then people could choose
whatever
GPX program they have to launch it, or save it.
--
Paul Tomblin <ptomblin+xcski.com>, not speaking for anybody
Quality Control, n.:
The process of testing one out of every 1,000 units coming off
a production line to make sure that at least one out of 100 works.
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/M=245454.3115308.4434529.1728375/D=egroupweb/S=1706
030390:HM/A=1457554/R=0/*http:/ipunda.com/clk/beibunmaisuiyuiwabei>
<http://us.adserver.yahoo.com/l?M=245454.3115308.4434529.1728375/D=egrou
pmail/S=:HM/A=1457554/rand=535809482>
To unsubscribe from this group, send an email to:
gpsxml-unsubscribe+yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/> Terms of Service.
------=_NextPart_000_0011_01C2F9D1.3CCF12C0
xinren_2002+yahoo.com on Thu Apr 10 09:10:30 2003 (link)
Hi
I'd like to be a member of this list. Thank you in advance.
---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
--0-650081665-1049991027=:54174
gpsxml+yahoogroups.com on Fri Apr 11 15:56:25 2003 (link)
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the gpsxml group. File : / Live Webcam Feeds - Click Here. Uploaded by : whitestorish <whitestorish+yahoo.com> Description : Real home Webcam Feeds! Real and Live! You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/%20Live%20Webcam%20Feeds%20-%20Click%20Here. To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, whitestorish <whitestorish+yahoo.com>
gpsxml+yahoogroups.com on Fri Apr 11 15:56:30 2003 (link)
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the gpsxml group. File : / Free Pics in Your Email - Click here Uploaded by : whitestorish <whitestorish+yahoo.com> Description : All the pic you need You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/%20Free%20Pics%20in%20Your%20Email%20-%20Click%20here To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, whitestorish <whitestorish+yahoo.com>
gpsxml+yahoogroups.com on Fri Apr 11 15:56:45 2003 (link)
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the gpsxml group. File : / Net Dating Service - Click here. Uploaded by : whitestorish <whitestorish+yahoo.com> Description : Thousands of profiles to browse through for free You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/%20Net%20Dating%20Service%20-%20Click%20here. To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, whitestorish <whitestorish+yahoo.com>
mvryukalo+yahoo.com on Sat Apr 19 02:07:36 2003 (link)
Hi All, Does anyone dynamicaly generate the GPX file from ColdFusion application? I'm looking for some examples and any links or code are appreciated. Thanks. Maksim.
bogamo+yahoo.com on Tue Jun 10 08:07:47 2003 (link)
Currently I'm just puting out text in xml format, I'm sure there are
problems with escaping names of features that have symbols in them,
but for the most part it works. If anyone knows of a better way to
output XML in java, please let me know. (Performance is somewhat of an
issue).
The website is at http://www.trailregistry.com
You'll need to create a user, then there will be a "Download GPS
data" link at the top of every trail page.
The system will convert the trail data that it has in the database to
a GPX track, and all any waypoints that lay within ~0.5 miles of the
trail.
Also, I noticed that geocaching is using the mime type
application/xml-loc, so I used that too. I'm not sure if that's the
right one though.
Please tell me what you think, and anything I can do better.
Thanks in advance,
-Geoff
egroups+topografix.com on Sun Jun 22 20:39:15 2003 (link), replying to msg
Hello, Tuesday, June 10, 2003, 11:07:32 AM, Geoff wrote: b> Also, I noticed that geocaching is using the mime type b> application/xml-loc, so I used that too. I'm not sure if that's the b> right one though. application/xml-gpx is a better choice. Geocaching also distributes files in a different XML format with the .loc extension, and they use xml-loc for that. Perhaps they didn't change their settings when they started using GPX. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
bogamo+yahoo.com on Mon Jun 23 05:05:43 2003 (link), replying to msg
Thanks. I'll make the change the next time I push up a new version of the
site.
-Geoff
--- Dan Foster <egroups+topografix.com> wrote:
> Hello,
>
> Tuesday, June 10, 2003, 11:07:32 AM, Geoff wrote:
>
> b> Also, I noticed that geocaching is using the mime type
> b> application/xml-loc, so I used that too. I'm not sure if that's the
> b> right one though.
>
> application/xml-gpx is a better choice. Geocaching also distributes
> files in a different XML format with the .loc extension, and they use
> xml-loc for that. Perhaps they didn't change their settings when they
> started using GPX.
>
> --
> Dan Foster
> TopoGrafix - GPS Software, Waypoints, and Maps
> http://www.topografix.com - mailto:egroups+topografix.com
>
>
>
> To unsubscribe from this group, send an email to:
> gpsxml-unsubscribe+yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
egroups+topografix.com on Tue Jul 08 13:20:55 2003 (link), replying to msg
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+topografix.com
kodiak+phonet.com on Tue Jul 08 13:36:22 2003 (link)
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
www.digitaltrails.com
----- Original Message -----
From: Dan Foster
To: gpsxml+yahoogroups.com
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+topografix.com
Yahoo! Groups Sponsor
ADVERTISEMENT
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.
------?extPart_000_0009_01C3456E.CB403E10
sandro_franchi+american-outland.com on Tue Jul 08 19:09:58 2003 (link), replying to msg
We too.
-----Original Message-----
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] 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
www.digitaltrails.com
----- Original Message -----
From: Dan <mailto:egroups+topografix.com> Foster
To: gpsxml+yahoogroups.com
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+topografix.com
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
<http://docs.yahoo.com/info/terms/> .
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/M=244522.3512152.4794593.1261774/D=egroupweb/S=17060303
90:HM/A=1595056/R=0/SIG=124bf4lrb/*http://ashnin.com/clk/muryutaitakenattogy
o?YH=3512152&yhad=1595056> Click Here!
<http://us.adserver.yahoo.com/l?M=244522.3512152.4794593.1261774/D=egroupmai
l/S=:HM/A=1595056/rand=551937858>
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
<http://docs.yahoo.com/info/terms/> .
------?extPart_000_0066_01C345A6.0C384D90
gpsexpl+tiscali.no on Wed Jul 09 05:59:46 2003 (link)
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.com on Wed Jul 09 07:39:31 2003 (link), replying to msg
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+tiscali.no [mailto:gpsexpl+tiscali.no] 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+yahoo.com on Sun Jul 13 13:53:43 2003 (link), replying to msg
--- 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...
egroups+topografix.com on Wed Jul 16 08:36:54 2003 (link), replying to msg
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+topografix.com
egroups+topografix.com on Wed Jul 16 08:46:10 2003 (link), replying to msg
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+topografix.com
sandro_franchi+american-outland.com on Wed Jul 16 09:49:36 2003 (link), replying to msg
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+topografix.com] 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+topografix.com Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303 90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050 4&media=atkins> click here <http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai l/S=:HM/A=1663535/rand=170543025> 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 <http://docs.yahoo.com/info/terms/> . ------?extPart_000_0001_01C34BA1.199B1E80
groups+mrgis.com on Wed Jul 16 20:03:31 2003 (link)
Wanted to let you all know about a new website, MrGIS.com No mass emails, no sales pitches, no fees. This site is for the use of anyone....recreational GPS users, GeoCachers, Professional GIS personnel, First Responders and Homeland Defense personnel and planners. The uses of this site are, but by no means limited to, questions, support, information, research, and whatever else it can be used for EXCEPT selling and/or advertising by sales personnel. The Message Board is the main feature of the site. Use it to post whatever information you are looking for or sharing, find GeoCache's, information on GIS Software, AVL or GPS equipment, success stories, anything you can think of to share. http://www.mrgis.com Best regards, Dave
jeremy+groundspeak.com on Thu Jul 17 09:13:14 2003 (link), replying to msg
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 ------=_NextPart_000_007D_01C34C43.A2ECBED0
sandro_franchi+american-outland.com on Thu Jul 17 09:53:01 2003 (link), replying to msg
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+groundspeak.com] 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 Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303 90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050 4&media=atkins> click here <http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai l/S=:HM/A=1663535/rand=510305458> 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 <http://docs.yahoo.com/info/terms/> . ------?extPart_000_0022_01C34C6A.BFBACA80
sandro_franchi+american-outland.com on Thu Jul 17 10:00:25 2003 (link), replying to msg
Where says "brabd", read "named" :) -----Original Message----- From: Sandro Franchi + American Outland [mailto:sandro_franchi+american-outland.com] 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+groundspeak.com] 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 <http://docs.yahoo.com/info/terms/> . Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303 90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050 4&media=atkins> click here <http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai l/S=:HM/A=1663535/rand=378402618> 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 <http://docs.yahoo.com/info/terms/> . ------?extPart_000_0029_01C34C6B.C8A8E770
kodiak+phonet.com on Thu Jul 17 10:06:29 2003 (link)
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 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 -----
From: Jeremy Irish
To: gpsxml+yahoogroups.com
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
Yahoo! Groups Sponsor
ADVERTISEMENT
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.
------?extPart_000_000E_01C34C63.F369DB20
jeremy+groundspeak.com on Thu Jul 17 10:53:20 2003 (link), replying to msg
--------- 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 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+phonet.com] 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. ------=_NextPart_000_0008_01C34C51.9E5A8420
sandro_franchi+american-outland.com on Thu Jul 17 11:34:52 2003 (link), replying to msg
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+groundspeak.com] 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+american-outland.com]: 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+phonet.com] 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. Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303 90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050 4&media=atkins> click here <http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai l/S=:HM/A=1663535/rand=576646511> 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 <http://docs.yahoo.com/info/terms/> . ------?extPart_000_003D_01C34C78.F973ACC0
jeremy+groundspeak.com on Thu Jul 17 12:08:18 2003 (link), replying to msg
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+american-outland.com] 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. ------=_NextPart_000_0004_01C34C5C.16530E70
sandro_franchi+american-outland.com on Thu Jul 17 18:35:56 2003 (link), replying to msg
"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+groundspeak.com] 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+american-outland.com] 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. Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=17060303 90:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=3050 4&media=atkins> click here <http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmai l/S=:HM/A=1663535/rand=440652866> 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 <http://docs.yahoo.com/info/terms/> . ------?extPart_000_001A_01C34CB3.C71F4C80
davewissenbach+yahoo.com on Fri Jul 18 15:30:58 2003 (link), replying to msg
--- 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
traipse+terra.com.br on Wed Jul 23 10:31:46 2003 (link)
Hi there -
I'm developing a GPS fw and was thinking of exporting waypoints to
HTML format (table) when a friend of mine told me about GPSXML. After
visiting the website and reading some messages, I have a couple of
questions:
1. Is there any documentation about GPSXML in doc or pdf format?
2. Since I'm not used to handheld GPSRs, I know nothing about symbols
("<sym>")... where can I find the "exact names" of most
popular/compatible symbols?
3. Any simple idea on how to link a file (e.g.: a picture, movie,
midi [2nd URL?]) to a waypoint? For instance, I have a waypoint that
refers to a small village that has its own website
("<url>", "<urlname>") and I would like to add a link to a picture
that I took...
Thank you all in advance for any clue.
Traipse
http://www.traipse.com.br
egroups+topografix.com on Wed Jul 23 11:05:22 2003 (link), replying to msg
Hello,
Wednesday, July 23, 2003, 1:31:42 PM, Traipse wrote:
t> Hi there -
t> I'm developing a GPS fw and was thinking of exporting waypoints to
t> HTML format (table) when a friend of mine told me about GPSXML. After
t> visiting the website and reading some messages, I have a couple of
t> questions:
t> 1. Is there any documentation about GPSXML in doc or pdf format?
The only documentation is in HTML, at http://www.topografix.com/gpx_manual.asp
t> 2. Since I'm not used to handheld GPSRs, I know nothing about symbols
t> ("<sym>")... where can I find the "exact names" of most
t> popular/compatible symbols?
Feel free to use the lists of waypoint symbols in EasyGPS.
http://www.easygps.com/download.asp
Select the GPS receiver in File/Preferences/My GPS Receivers, and then
create a new waypoint. The names of all the GPS symbols available are
listed in the Symbol combo box.
I believe Dave Wissenbach has a list of Garmin symbols on his website.
t> 3. Any simple idea on how to link a file (e.g.: a picture, movie,
t> midi [2nd URL?]) to a waypoint? For instance, I have a waypoint that
t> refers to a small village that has its own website
t> ("<url>", "<urlname>") and I would like to add a link to a picture
t> that I took...
<wpt lat="40.167210000" lon="-105.101960000">
<name>PHOTO</name>
<url>http://www.server.com/myphoto.jpg</url>
<urlname>Link to my photo</urlname>
</wpt>
--
Dan Foster
TopoGrafix - GPS Software, Waypoints, and Maps
http://www.topografix.com - mailto:egroups+topografix.com
traipse+terra.com.br on Wed Jul 23 15:13:05 2003 (link), replying to msg
Hi Dan -
Thx a bunch for your reply. I'm gonna download EasyGPS and copy your
symbol names. ;-) BTW, which ones are the most popular? I mean,
which handheld GPSR has the most popular/compatible symbol names?
As for my 3rd question...
t> 3. Any simple idea on how to link a file (e.g.: a picture, movie,
t> midi [2nd URL?]) to a waypoint? For instance, I have a waypoint
that
t> refers to a small village that has its own website
t> ("<url>", "<urlname>") and I would like to add a link to a picture
t> that I took...
Let me try to put it in XML words using your example, adding two
lines (<xxx> & <yyy>) at the end:
<wpt lat="-25.4475" lon="-54.5833">
<name>Itaipu</name>
<url>http://www.itaipu.gov.br/english/main2.htm</url>
<urlname>Official site of the largest power plant in the
world</urlname>
<xxx>My picture of Itaipu lake</xxx>
<yyy>http://www.myserver.com.br/mypicture.jpg</yyy>
</wpt>
In other words, I wonder if there is a simple way that allows
something like that (<xxx> & <yyy>).
Once again, thx for your answer.
Traipse
http://www.traipse.com.br
davewissenbach+yahoo.com on Wed Jul 23 17:51:49 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, "traipse_sp" <traipse+t...> wrote:
> Hi Dan -
>
> Thx a bunch for your reply. I'm gonna download EasyGPS and copy
your
> symbol names. ;-) BTW, which ones are the most popular? I mean,
> which handheld GPSR has the most popular/compatible symbol names?
>
> As for my 3rd question...
>
> t> 3. Any simple idea on how to link a file (e.g.: a picture,
movie,
> t> midi [2nd URL?]) to a waypoint? For instance, I have a
waypoint
> that
> t> refers to a small village that has its own website
> t> ("<url>", "<urlname>") and I would like to add a link to a
picture
> t> that I took...
>
> Let me try to put it in XML words using your example, adding two
> lines (<xxx> & <yyy>) at the end:
>
> <wpt lat="-25.4475" lon="-54.5833">
> <name>Itaipu</name>
> <url>http://www.itaipu.gov.br/english/main2.htm</url>
> <urlname>Official site of the largest power plant in the
> world</urlname>
> <xxx>My picture of Itaipu lake</xxx>
> <yyy>http://www.myserver.com.br/mypicture.jpg</yyy>
> </wpt>
>
Right now, in order to use your own xxx and yyy, you must create
your own namespace and schema. There's a slot for elements in
another namespace in waypoints, routes,
and tracks and the root document that allows you to insert your own
new elements <yournamespace:xxx> and <yournamespace:yyy>.
But I have also been annoyed by the problem you illustrate above,
that we have allowed only one url and one urlname per waypoint.
You can find examples of creating and using another namespace in the
topografix sample data and in my Southwestern Idaho Trail Maps
websites, all linked from the Topografix gpx documentation site.
> In other words, I wonder if there is a simple way that allows
> something like that (<xxx> & <yyy>).
>
> Once again, thx for your answer.
>
> Traipse
> http://www.traipse.com.br
mholger+optera.net on Thu Jul 24 05:20:56 2003 (link), replying to msg
Ok, I'm no XML guru nor am I a GPS guru, but wouldn't it be feasible to
handle URLs the same way waypoints are handled? That is to say, <url
href="http://www.someurl.com/somedoc.html">url name</url>, which could
be used from 0 to 'N' times per <wpt>? Then referencing up to 'N' URLs
per WPT becomes as trivial as accessing multiple WPTs per GPX file. :)
I realise that this is in complete disagreement with the current GPX
specs...but, if there were to ever be any future revisions.... ;)
Cheers!
-Matt.
davewissenbach wrote:
> --- In gpsxml+yahoogroups.com, "traipse_sp" <traipse+t...> wrote:
>>As for my 3rd question...
>>
>>t> 3. Any simple idea on how to link a file (e.g.: a picture,
>
> movie,
>
>>t> midi [2nd URL?]) to a waypoint? For instance, I have a
>
> waypoint
>
>>that
>>t> refers to a small village that has its own website
>>t> ("<url>", "<urlname>") and I would like to add a link to a
>
> picture
>
>>t> that I took...
>>
>>Let me try to put it in XML words using your example, adding two
>>lines (<xxx> & <yyy>) at the end:
>>
>><wpt lat="-25.4475" lon="-54.5833">
>> <name>Itaipu</name>
>> <url>http://www.itaipu.gov.br/english/main2.htm</url>
>> <urlname>Official site of the largest power plant in the
>>world</urlname>
>> <xxx>My picture of Itaipu lake</xxx>
>> <yyy>http://www.myserver.com.br/mypicture.jpg</yyy>
>></wpt>
>>
>
> Right now, in order to use your own xxx and yyy, you must create
> your own namespace and schema. There's a slot for elements in
> another namespace in waypoints, routes,
> and tracks and the root document that allows you to insert your own
> new elements <yournamespace:xxx> and <yournamespace:yyy>.
>
> But I have also been annoyed by the problem you illustrate above,
> that we have allowed only one url and one urlname per waypoint.
>
> You can find examples of creating and using another namespace in the
> topografix sample data and in my Southwestern Idaho Trail Maps
> websites, all linked from the Topografix gpx documentation site.
>
--
Matt Holger -//- mholger+optera.net
UNIX Systems Admin -//- http://www.Optera.NET/
traipse+terra.com.br on Thu Jul 24 10:21:59 2003 (link), replying to msg
Thx Dan. >>> You can find examples of creating and using another namespace in the topografix sample data and in my Southwestern Idaho Trail Maps websites, all linked from the Topografix gpx documentation site. <<< OK. I'm gonna study your examples and try to do something. Traipse http://www.traipse.com.br
traipse+terra.com.br on Thu Jul 24 10:29:38 2003 (link), replying to msg
Matt - >>> Then referencing up to 'N' URLs per WPT becomes as trivial as accessing multiple WPTs per GPX file. <<< It sure is a great idea for the coming releases. Traipse http://www.traipse.com.br
egroups+topografix.com on Thu Jul 24 11:19:33 2003 (link), replying to msg
Hello Matt, Thursday, July 24, 2003, 8:20:46 AM, you wrote: m> Ok, I'm no XML guru nor am I a GPS guru, but wouldn't it be feasible to m> handle URLs the same way waypoints are handled? That is to say, <url m> href="http://www.someurl.com/somedoc.html">url name</url>, which could m> be used from 0 to 'N' times per <wpt>? Then referencing up to 'N' URLs m> per WPT becomes as trivial as accessing multiple WPTs per GPX file. :) m> I realise that this is in complete disagreement with the current GPX m> specs...but, if there were to ever be any future revisions.... ;) I wouldn't have any problem with making this change to the spec. Logically, a wpt (or rte or rtept) can have 0..N URLs associated with it, unlike the other GPX attributes (lat, lon, sym, desc). -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Jul 24 11:19:34 2003 (link), replying to msg
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+topografix.com
sandro_franchi+american-outland.com on Thu Jul 24 18:51:03 2003 (link), replying to msg
A separate namespace sounds perfect to me. Go ahead. Thanks. -----Original Message----- From: Dan Foster [mailto:egroups+topografix.com] 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+topografix.com Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=251812.3170658.4537139.1261774/D=egroupweb/S=17060303 90:HM/A=1652963/R=0/SIG=11tvulr8i/*http://www.netflix.com/Default?mqso=60178 275&partid=3170658> click here <http://us.adserver.yahoo.com/l?M=251812.3170658.4537139.1261774/D=egroupmai l/S=:HM/A=1652963/rand=709705337> 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 <http://docs.yahoo.com/info/terms/> . ------?extPart_000_0001_01C35236.0B507640
davewissenbach+yahoo.com on Sun Jul 27 14:50:16 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello Matt, > > Thursday, July 24, 2003, 8:20:46 AM, you wrote: > > m> Ok, I'm no XML guru nor am I a GPS guru, but wouldn't it be feasible to > m> handle URLs the same way waypoints are handled? That is to say, <url > m> href="http://www.someurl.com/somedoc.html">url name</url>, which could > m> be used from 0 to 'N' times per <wpt>? Then referencing up to 'N' URLs > m> per WPT becomes as trivial as accessing multiple WPTs per GPX file. :) > > m> I realise that this is in complete disagreement with the current GPX > m> specs...but, if there were to ever be any future revisions.... ;) > > I wouldn't have any problem with making this change to the spec. > Logically, a wpt (or rte or rtept) can have 0..N URLs associated with > it, unlike the other GPX attributes (lat, lon, sym, desc). > > -- This change should probably be in the base gpx namespace, in a future revision. But to avoid confusion with the existing version 1.0, I suggest that the name of the new element be something like infourl, where multiple instances are allowed. GPX2.0 applications would write any number of urlinfo tags which would be ignored by GPX1.0 applications, as opposed to GPX2.0 applications writing the new url tag which causes a parsing error in a GPX1.0 document. > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
jeetsukumaran+pd.jaring.my on Fri Aug 01 21:20:49 2003 (link)
Hello. My geodata has some additional information that I wish to save along with the standard fields offered by gpx. From what I can make out, I should declare a namespace to hold my private elements. Sounds kinky ... and I have no idea how to do it! Could someone please help, by, for example, showing me how the following information might be encoded: Waypoint: Name:BRIDGE Lat: 2.20321 Lon: 101.22322 Ele: 212.00 Time: 2003-08-01T13:00Z Desc: Cross it when we come to it Src: Garmin e-Trex I want to add: Keywords: Peat-swamp; conservation; project; river; survey; RSOEasting: EEEEEEE RSONorthing: NNNNNNN Category: Survey I know this much - <wpt lat="2.20321" lon="101.22322"> <ele>212.00</ele> <time>2003-08-01T13:00Z</time> <name>BRIDGE</name> <desc>Cross it when we come to it</desc> <sym>Crossing</sym> <wpt> How do I add the fields above? What file headers do I need to place at the top of the gpx file? What elements do I add to the <wpt> element? Thanks! -- jeet
davewissenbach+yahoo.com on Sat Aug 02 12:07:28 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, "jeetsukumaran" <jeetsukumaran+p...>
wrote:
> Hello.
>
> My geodata has some additional information that I wish to save
along
> with the standard fields offered by gpx. From what I can make out,
I
> should declare a namespace to hold my private elements.
>
> Sounds kinky ... and I have no idea how to do it!
>
> Could someone please help, by, for example, showing me how the
> following information might be encoded:
>
> Waypoint:
> Name:BRIDGE
> Lat: 2.20321
> Lon: 101.22322
> Ele: 212.00
> Time: 2003-08-01T13:00Z
> Desc: Cross it when we come to it
> Src: Garmin e-Trex
>
> I want to add:
> Keywords: Peat-swamp; conservation; project; river; survey;
> RSOEasting: EEEEEEE
> RSONorthing: NNNNNNN
> Category: Survey
>
>
> I know this much -
>
> <wpt lat="2.20321" lon="101.22322">
> <ele>212.00</ele>
> <time>2003-08-01T13:00Z</time>
> <name>BRIDGE</name>
> <desc>Cross it when we come to it</desc>
> <sym>Crossing</sym>
<kinky:Keywords>Peat-swamp; conservation; project; river;
survery;</kinky:Keywords>
<kinky:RSOEasting>EEEEEE</kinky:RSOEasting>
<kinky:RSONorthing>NNNNN</kinky:RSONORTHING>
<kinky:Category>Survery</kinky:Category>
> <wpt>
>
> How do I add the fields above? What file headers do I need to
place
> at the top of the gpx file?
For a header, use this
<gpx
xmlns="http://www.topografix.com/GPX/1/0"
version="1.0" creator="Wissenbach Map3D 2.8"
xmlns:kinky="http://www.sukumarin.com/kinky"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0
http://www.topografix.com/GPX/1/0/gpx.xsd
http://www.sukumarin.com/kinky
http://www.sukumarin.com/kinky/kinky.xsd">
Then at the schema location for the namespace listed, you provide an
XML Schema, which looks
something like this:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://wwww.sukumarin.com/kinky"
xmlns="http://www.sukumarin.com/kinky"
elementFormDefault="qualified">
<annotation><documentation>
This schema describes the extensions to the public gpx
format used in the
Map program by Jeet. Every element in the gpx format allows
the insertion of element content, from another namespace. For
example,
Kinky adds Easting, Northing, and
Category</documentation></annotation>
<xs:element name="RSAEasting" type="xs:string" minOccurs="0" />
<xs:element name="RSANorthing" type="xs:string" minOccurs="0" />
<xs:element name="Category" type="xs:string" minOccurs="0" />
</xs:schema>
In your gpx document, kinky: is shorthand for your namespace
http://www.sukumarin.com/kinky.
I'd suggest that you get a book on XML Schema, such as Wrox Press's
XML Schema, which is where I learned this. (But some of this comes
from trial and error.
What elements do I add to the <wpt>
> element?
>
> Thanks!
>
> -- jeet
jeetsukumaran+pd.jaring.my on Sat Aug 02 13:00:52 2003 (link), replying to msg
Thanks! This helps a lot. XML might as well be Sumerian to me, right now ... so you are right, I do have to read up on it. I plan to use the MS xml parser to parse gpx files. Just out of curiosity, what files do I have to include with my program when I redistribute it? The MS documentation is a little confusing, referring to installer merge files and the like. -- jeet --- In gpsxml+yahoogroups.com, "davewissenbach" <davewissenbach+y...> wrote: > --- In gpsxml+yahoogroups.com, "jeetsukumaran" <jeetsukumaran+p...> > wrote: > > Hello. > > > > My geodata has some additional information that I wish to save > along > > with the standard fields offered by gpx. From what I can make out, > I > > should declare a namespace to hold my private elements. > > > > Sounds kinky ... and I have no idea how to do it! > > > > Could someone please help, by, for example, showing me how the > > following information might be encoded: > > > > Waypoint: > > Name:BRIDGE > > Lat: 2.20321 > > Lon: 101.22322 > > Ele: 212.00 > > Time: 2003-08-01T13:00Z > > Desc: Cross it when we come to it > > Src: Garmin e-Trex > > > > I want to add: > > Keywords: Peat-swamp; conservation; project; river; survey; > > RSOEasting: EEEEEEE > > RSONorthing: NNNNNNN > > Category: Survey > > > > > > I know this much - > > > > <wpt lat="2.20321" lon="101.22322"> > > <ele>212.00</ele> > > <time>2003-08-01T13:00Z</time> > > <name>BRIDGE</name> > > <desc>Cross it when we come to it</desc> > > <sym>Crossing</sym> > <kinky:Keywords>Peat-swamp; conservation; project; river; > survery;</kinky:Keywords> > <kinky:RSOEasting>EEEEEE</kinky:RSOEasting> > <kinky:RSONorthing>NNNNN</kinky:RSONORTHING> > <kinky:Category>Survery</kinky:Category> > > <wpt> > > > > How do I add the fields above? What file headers do I need to > place > > at the top of the gpx file? > > For a header, use this > > <gpx > xmlns="http://www.topografix.com/GPX/1/0" > version="1.0" creator="Wissenbach Map3D 2.8" > xmlns:kinky="http://www.sukumarin.com/kinky" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.topografix.com/GPX/1/0 > http://www.topografix.com/GPX/1/0/gpx.xsd > http://www.sukumarin.com/kinky > http://www.sukumarin.com/kinky/kinky.xsd"> > > Then at the schema location for the namespace listed, you provide an > XML Schema, which looks > something like this: > > <?xml version="1.0" encoding="utf-8"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" > targetNamespace="http://wwww.sukumarin.com/kinky" > xmlns="http://www.sukumarin.com/kinky" > elementFormDefault="qualified"> > > <annotation><documentation> > This schema describes the extensions to the public gpx > format used in the > Map program by Jeet. Every element in the gpx format allows > the insertion of element content, from another namespace. For > example, > Kinky adds Easting, Northing, and > Category</documentation></annotation> > > <xs:element name="RSAEasting" type="xs:string" minOccurs="0" /> > <xs:element name="RSANorthing" type="xs:string" minOccurs="0" /> > <xs:element name="Category" type="xs:string" minOccurs="0" /> > > </xs:schema> > > In your gpx document, kinky: is shorthand for your namespace > http://www.sukumarin.com/kinky. > > I'd suggest that you get a book on XML Schema, such as Wrox Press's > XML Schema, which is where I learned this. (But some of this comes > from trial and error. > > What elements do I add to the <wpt> > > element? > > > > Thanks! > > > > -- jeet
eeronpoika+yahoo.com on Sun Aug 03 10:50:37 2003 (link)
I am new to GPX, but I implemented handling of GPX-format in my
freeware program GeoConv, which converts between different file-
formats, datums, coordinate-formats.
Since most of you know GPX quite well, I send a short description of
the implementation. All corrections, suggestions and other comments
are welcome and appreciated.
I have tested the output against GPX-schema using XML-validator, but
I still keep on testing. I continue with implementing Route-handling.
Address to software: www.iki.fi/eino.uikkanen/geoconvgb/
Wbr,
Eino Uikkanen
www.iki.fi/eino.uikkanen/gb/
Short description (cut of the manual):
GPX, Topografix GPS eXchange format
Because the datum is fixed to WGS84 in this format, the values of the
parameters INDATUM and OUTDATUM have no effect.
GPX-format does not transfer height-coordinate (height above
ellipsoid). Therefore GeoConv interprets in input and output, that
height above ellipsoid equals to the sum of the values of elements
<ele> and <geoidheight>.
If input-file contains both track-points and waypoints, but the order
of appearance does not agree with GPX-standard, GeoConv does not
change the order to agree with standard.
The values to parameters below are fetched from respective GeoConv-
parameters. Values below are default values set by initialization run
GeoConv.ini.
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.topografix.com/GPX/1/0"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 gpx.xsd">
GeoConv reads and writes the fields represented in the sample below:
<gpx version="1.0" creator="GeoConv"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.topografix.com/GPX/1/0"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 gpx.xsd">
<desc>From C:\GPSDATA\PCX5\SOUR\PORKNIEM.GRM</desc>
<trk>
<name>Track 01</name>
<desc>Track 1</desc>
<number>1</number>
<trkseg>
<trkpt lat="+059.975567" lon="+024.401246">
<ele>0</ele>
<time>1997-10-20T12:26:14Z</time>
<geoidheight>0</geoidheight>
<name>BRIDGE</name>
<desc>Bridge to Varo</desc>
</trkpt>
</trkseg>
</trk>
<wpt lat="+060.008006" lon="+024.455481">
<ele>0</ele>
<time>1962-03-27T00:00:00Z</time>
<geoidheight>0</geoidheight>
<name>BRIDGE</name>
<desc>Bridge to Varo</desc>
</wpt>
</gpx>
eeronpoika+yahoo.com on Sun Aug 03 13:13:22 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > 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) Hi, I am responding to an old message, but since it is used as reference through archive, I suppose it is not too late to comment on that. 1) I want to check if your definition of <geoidheight> above is what you actually meant. I wonder if you wanted to say vice versa, "Height of geoid (mean sea level) above WGS84 ellipsoid", not height of ellipsoid above geoid? 2) I would be happy to see height coordinate (height of the point above the reference ellipsoid) in GPX-standard - now it is totally missing. Neither of <ele> nor <geoidheight> can replace it. The third coordinate value in addition to latitude and longitude is height above ellipsoid. The physical heights are actually properties of a point defined by (lat,lon,height above ellipsoid). To be accurate, physical heights are vector-functions of (lat,lon,height above ellipsoid), even though only the scalar part is normally used. Summa summarum: height above reference ellipsoid can�t be substituted by other heights. With Kind Regards, Eino Uikkanen www.iki.fi/eino.uikkanen/gb/
egroups+topografix.com on Mon Aug 04 08:07:19 2003 (link), replying to msg
Hello, Sunday, August 3, 2003, 4:13:17 PM, Eino wrote: e> --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: >> 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) e> Hi, e> I am responding to an old message, but since it is used as reference e> through archive, I suppose it is not too late to comment on that. e> 1) I want to check if your definition of <geoidheight> above is what e> you actually meant. I wonder if you wanted to say vice versa, "Height e> of geoid (mean sea level) above WGS84 ellipsoid", not height of e> ellipsoid above geoid? I copied this definition word for word from the description of the NMEA GGA sentence in my Magellan 315 user's manual. But you are correct, I believe the name we chose is confusing. It probably should be called <ellipsoidheight>, since it's the height of the ellipsoid above the geoid (mean sea level). e> 2) I would be happy to see height coordinate (height of the point e> above the reference ellipsoid) in GPX-standard - now it is totally e> missing. Neither of <ele> nor <geoidheight> can replace it. The third e> coordinate value in addition to latitude and longitude is height e> above ellipsoid. The physical heights are actually properties of a e> point defined by (lat,lon,height above ellipsoid). To be accurate, e> physical heights are vector-functions of (lat,lon,height above e> ellipsoid), even though only the scalar part is normally used. Summa e> summarum: height above reference ellipsoid can?be substituted by e> other heights. Perhaps I'm not understanding you correctly. It seems to me that your new height "h" is just the difference between <ele> and <geoidheight>. h = height above WGS84 ellipsoid ele = height above mean sea level (geoid) geoidheight = height of WGS84 ellipsoid above mean sea level (geoid) so, h = ele - geoidheight -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com