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
eeronpoika+yahoo.com on Mon Aug 04 08:43:41 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > 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�t 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+t... I want to check once more - actually I did also take a direct quotation from NMEA0183-GGA-message description and it was "Height of geoid (mean sea level) above WGS84 ellipsoid". Now our quotations of GGA disagree?! According to my interpretation h = ele + geoidheight (sum). I checked the quatation once more - could you pls do the same, but from NMEA source, not from Magellans ;-). I understood, that you anyway meant it to be the same as in GGA? This "my new h" is not just another height - it is the one and only height used in coordinate calculations, e.g. when we convert 3D- rectangular coordinates (X,Y,Z) to geodetic coordinates (lat,lon,h). Therefore it is very important - actually mandatory in geodetic applications. My dream of a point element would then be e.g. <wpt lat="99.999" lon="99.999" height="9999.99"> <ele>999.999</ele> <geoidheight>9999.99</geoidheight> etc. This is because "my h" is _coordinate_ value as are lat and lon - other heights are _properties_ of the point (lat,lon,h). With Kind Regards, Eino Uikkanen www.iki.fi/eino.uikkanen/gb/
egroups+topografix.com on Mon Aug 04 10:00:04 2003 (link), replying to msg
Hello, Monday, August 4, 2003, 11:43:39 AM, Eino wrote: e> I want to check once more - actually I did also take a direct e> quotation from NMEA0183-GGA-message description and it was "Height of e> geoid (mean sea level) above WGS84 ellipsoid". Now our quotations of e> GGA disagree?! According to my interpretation h = ele + geoidheight e> (sum). I checked the quatation once more - could you pls do the same, e> but from NMEA source, not from Magellans ;-). I understood, that you e> anyway meant it to be the same as in GGA? We intended it to be the same as GGA. I went back to Kjeld's original request to include it. He defined it as you do: <geoidheight> Height of geoid (mean sea level) above WGS84 ellipsoid I checked the description in Magellan's manual. They write: Geoidal separation - difference between the WGS-84 earth ellipsoid and mean sea level (geoid), "-" = mean sea level below ellipsoid. That description matches your definition as well. I must have switched the two terms when writing the documentation. I'll change the documentation tomorrow, unless someone objects, to the following: <geoidheight> Height of geoid (mean sea level) above WGS84 ellipsoid As far as I know, Kjeld's CetusGPS is the only program out there using <geoidheight> now, and based on his original message, I assume he used the correct definition rather than my mistaken one. e> This "my new h" is not just another height - it is the one and only e> height used in coordinate calculations, e.g. when we convert 3D- e> rectangular coordinates (X,Y,Z) to geodetic coordinates (lat,lon,h). e> Therefore it is very important - actually mandatory in geodetic e> applications. My dream of a point element would then be e.g. e> <wpt lat="99.999" lon="99.999" height="9999.99"> e> <ele>999.999</ele> e> <geoidheight>9999.99</geoidheight> e> etc. e> This is because "my h" is _coordinate_ value as are lat and lon - e> other heights are _properties_ of the point (lat,lon,h). I realize that you need the height above the ellipsoid to do precise calculations. In instances where you have both <ele> and <geoidheight>, you can calculate this: h = height above WGS84 ellipsoid ele = height above mean sea level (geoid) geoidheight = Height of geoid (mean sea level) above WGS84 ellipsoid so, h = ele + geoidheight And if you have <ele> but not <geoidheight>, you're out of luck. You won't be able to do your calculations with the correct height data, unless you've got your own table of geoidheight values for the Earth. I did a quick search on the newsgroups for "garmin altitude geoid", and the results are troubling. Nobody has a clear answer to whether the altitude sent with Garmin waypoints is measured relative to the geoid, or to the WGS-84 ellipsoid. I've always assumed it was relative to the geoid (since end users think of altitude relative to mean sea level). I'd run outside and do a test, but it's pouring rain here... -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
eeronpoika+yahoo.com on Mon Aug 04 10:50:49 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > We intended it to be the same as GGA. I went back to Kjeld's > original request to include it. He defined it as you do: > <geoidheight> Height of geoid (mean sea level) above WGS84 > ellipsoid > > I checked the description in Magellan's manual. They write: > Geoidal separation - difference between the WGS-84 earth ellipsoid > and mean sea level (geoid), "-" = mean sea level below ellipsoid. > > That description matches your definition as well. > > I must have switched the two terms when writing the documentation. > I'll change the documentation tomorrow, unless someone objects, to > the following: > <geoidheight> Height of geoid (mean sea level) above WGS84 ellipsoid Fine ? now we and all the definitions do agree and no harm was done :-) > As far as I know, Kjeld's CetusGPS is the only program out there > using <geoidheight> now, and based on his original message, I > assume he used the correct definition rather than my mistaken one. Make it two. My GeoConv also reads and writes <geoidheight> in addition to <ele> and calculates h = <ele> + <geoidheight>. If you want to have a look, you find GeoConv from address www.iki.fi/eino.uikkanen/geoconvgb/ Wbr, Eino www.iki.fi/eino.uikkanen/gb/
robin4jobcurry+yahoo.co.in on Tue Aug 05 04:48:56 2003 (link)
Hello, We are looking for our client a reputed software company for professionals with 2-5 yrs of experience into Java/XML technologies for Pune. The desired incumbent should be very strong in XML and should preferably hail from a product development background. You should have good analytical ability coupled with strong communications skills. Interested candidates kindly send your profile to robina+Jobcurry.com at the earliest possible. Openings are also available for FRESHERS with excellent XML knowledge.(Technical graudates preferred) Awaiting your reply. Thanks & Regards Robin Anthony Jobcurry Systems Pvt. Ltd 020-6634315 SMS using the Yahoo! Messenger;Download latest version. --0-1517220871-1060084131=:46839
yahoo+holomind.de on Tue Aug 05 09:04:41 2003 (link), replying to msg
Hi Robert (and Group), I am searching for a way to convert gps-formats in realtime on a webserver (with php for example). Are there plans (in this group) to port the quite proprietary 'needs to compile' format in C to some web-scripting like php which can run in your webserver. I think, the logik for converting all formats to gpx and back to any format are inside of the gpsbabel c-sources and could be reprogrammed in php, for easy use with a webserver. (kind of converter before download). It sounds like reeinventing the wheel. Has somebody tried to run the gpsbabel(.exe) as a cgi-programm on a linux (e.g. apache-webserver). would be nice to hear about. Otherwise I play with the idea to have a litte php-converter for the files, which define Templates or Rules for read format( 'you name it' ) => save as gpx read format( gpx ) => save as format( 'you name it' ) the funktion for fileopen etc. would be needed only once. in the script you would call. convert_to_gpx( 'format-x' , 'filename-in', 'filename-out' ); convert_from_gpx ( 'format-x' , 'filename' , 'filename-out' ); if you want to convert from format-a to format-b you would do something like. [? php php-stuff.. .. convert_to_gpx( 'format-a' , 'input.txt', 'temp.gpx' ); convert_from_gpx( 'format-b' , 'temp.gpx' , 'out.txt' ); .. some more php stuff... ?] cool or stupid ? ;) greetings, Daniel --- In gpsxml+yahoogroups.com, 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+holomind.de on Tue Aug 05 10:44:30 2003 (link), replying to msg
Hi, perhaps interesting for somebody.... I managed to run the gpsbabel via webserver (kind of cgi) in realtime: http://www.tourismusdirekt.com/service/gps/gpsbabel.php On the page you can see how it works. The gpsbabel-source was compiled on a linux-server (gpsbabel.sourceforge.net) with "./make" in the directory of source-file and the resulting binary copied to /usr/local/bin Then the script is called via "system()" in a php-page. You need rights to execute scripts or even commands via system and the right to read and write in a directory (not every hoster allows this!) This means for websites you can convert files on-the-fly online where the www-user does not need to have the gpsbabel executable. Greetings Daniel --- In gpsxml+yahoogroups.com, "kurwellness" <yahoo+h...> wrote: > Hi Robert (and Group), > > I am searching for a way to convert gps-formats in realtime > on a webserver (with php for example). > Are there plans (in this group) to port the quite proprietary > 'needs to compile' format in C to some web-scripting like > php which can run in your webserver. > > I think, the logik for converting all formats to gpx and back > to any format are inside of the gpsbabel c-sources and could be > reprogrammed in php, for easy use with a webserver. > (kind of converter before download). > It sounds like reeinventing the wheel. > > Has somebody tried to run the gpsbabel(.exe) as a cgi-programm > on a linux (e.g. apache-webserver). would be nice to hear about. > > Otherwise I play with the idea to have a litte php-converter > for the files, which define Templates or Rules for > > read format( 'you name it' ) => save as gpx > read format( gpx ) => save as format( 'you name it' ) > > the funktion for fileopen etc. would be needed only once. > in the script you would call. > > convert_to_gpx( 'format-x' , 'filename-in', 'filename-out' ); > convert_from_gpx ( 'format-x' , 'filename' , 'filename-out' ); > > if you want to convert from format-a to format-b you would do > something like. > > [? php > > php-stuff.. > .. > convert_to_gpx( 'format-a' , 'input.txt', 'temp.gpx' ); > convert_from_gpx( 'format-b' , 'temp.gpx' , 'out.txt' ); > .. > some more php stuff... > > ?] > > cool or stupid ? ;) > > greetings, > Daniel > > --- In gpsxml+yahoogroups.com, 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 Aug 05 12:56:13 2003 (link), replying to msg
kurwellness wrote: > I am searching for a way to convert gps-formats in realtime > on a webserver (with php for example). > Are there plans (in this group) to port the quite proprietary > 'needs to compile' format in C to some web-scripting like "Quite proprietary"? It's totally portable ISO C and runs on dozens of platforms without modifications. > I think, the logik for converting all formats to gpx and back to any > format are inside of the gpsbabel c-sources and could be reprogrammed > in php, for easy use with a webserver. (kind of converter before > download). It sounds like reeinventing the wheel. That would be so backwards. After all the work to reimplement it in another language, you'd functionally have exactly what you started with, but you've now shouldered the maintenance burden. If you want to do this on a webserver, build up the command line from your forms, shell out to the executable running on the server, and capture the output. It's been done by a couple of folks. Here's one such example: http://www.wayhoo.com RJL
shawncarson_231+yahoo.com on Tue Aug 05 14:17:47 2003 (link)
I just wanted to let everyone know about some of the stuff that has happened to me in the last little while. I spent the last 2 years working 60-80 hours a week for an online gaming company and dreading every morning. It just wasn't as satisfying for me as it had been when I began, and the pay didn't quite match up with the hours worked (can anyone say `salary'). Anyway, the point is I found something called Global Online Systems which allowed me to start building a business on the side part- time. After 6 months working part-time I was able to leave my job and now I'm home and loving it. Can't beat taking X-Box breaks whenever I want! If you're interested, you can check them out at www.GraspOn2dreams.com/?refid=xbox80 Or you can call them at 1-888-233-0385 and they'll have someone call you. Hope this helps someone, Shawn Carson
robin4jobcurry+yahoo.co.in on Mon Aug 11 04:57:47 2003 (link)
Hello Everybody, This is Robin here from Jobcurry Systems Pvt. Ltd. Presently, we are looking for one of our reputed clients,a SEI CMM Level 5 company at Pune for Java Professionals with the following skills. Further details of the requirement are as follows. Designation:Team Leader/Developer Experience:3-5yrs in Developing web based applications. Skills: Java1.2/Exp in working with Interstage Server is a must/Strong database knowledge Education:Graduate Location:Pune Interested candidates kindly send us an updated copy of your profile for further processing. Awaiting your reply. Thanks & Regards Robin Anthony Jobcurry Systems Pvt. Ltd. 020-6634315 SMS using the Yahoo! Messenger;Download latest version. --0-825618916-1060603057=:65318
jason.martin+informatik.uni-oldenburg.de on Mon Aug 11 06:03:03 2003 (link)
I am very new to GPX, but noticed that there are no predefined schemas for area features. For GIS systems, this is important to have and It'd be nice to see it incorporated into GPX.
robin4jobcurry+yahoo.co.in on Mon Aug 11 06:26:44 2003 (link)
Hello Friends, This is Robin here from Jobcurry Systems Pvt. Ltd. We are looking for FRESHERS for one of our reputed client for Pune. You should have very good knowledge of Java/XML or used the same for your academic projects. Preference will be given to technical graduate. Interested candidates kindly send your profiles to robina+jobcurry.com Thanks & Regards Robin Anthony Jobcurry Systems Pvt. Ltd. 020-6634315 SMS using the Yahoo! Messenger;Download latest version. --0-249082408-1060608397=:27024
egroups+topografix.com on Mon Aug 11 07:57:51 2003 (link), replying to msg
Hello, Monday, August 11, 2003, 9:03:02 AM, Jason wrote: j> I am very new to GPX, but noticed that there are no predefined j> schemas for area features. For GIS systems, this is important to j> have and It'd be nice to see it incorporated into GPX. This would be a good addition to GPX. I've got several tracklogs that represent a lake shoreline, or the boundary of a wildlife area. I'd like to be able to express these as filled objects in GPX. There are several ways we could add support for filled polygons. 1. Add an optional element to <trk> to indicate that the object represents a closed polygon, rather than a line feature. For example: <trk> <name>Shoreline</name> <filled /> // this is a filled polygon ... 2. Create a new <poly> object, duplicating most of <trk> 3. Add a new namespace for filled objects <trk> <name>Shoreline</name> <gpx_fill:fill> // this is a filled polygon <gpx_fill:color>0x0000ff</gpx_fill> // blue <gpx_fill:pattern>crosshatch</gpx_fill> </gpx_fill:fill> ... I'd like to see something along the lines of #3. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
jeremy+groundspeak.com on Mon Aug 11 10:31:45 2003 (link), replying to msg
GPX is XML for Global Positioning Systems. GML is for what you're looking for. I'm sure you could combine the two schemas to get your intended result. Geography Markup Language (GML) http://opengis.net/gml/01-029/GML2.html -----Original Message----- From: jasonjanine2001 [mailto:jason.martin+informatik.uni-oldenburg.de] Sent: Monday, August 11, 2003 6:03 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Support for Polygon features I am very new to GPX, but noticed that there are no predefined schemas for area features. For GIS systems, this is important to have and It'd be nice to see it incorporated into GPX. ------=_NextPart_000_000A_01C35FF3.C0619C60
egroups+topografix.com on Tue Aug 12 13:55:11 2003 (link), replying to msg
Hello, I'm proposing two new public namespaces for displaying text, lines, and filled shapes on GPS maps. The first schema, gpx_style, deals with fonts, colors, and fill styles. The second schema, gpx_overlay, defines elements for text, polylines, and polygons. All of these items are common features in mapping software like OziExplorer, and are starting to find their way onto standalone GPS receivers as well. I've posted 0.1 versions of each schema in the following locations: gpx_style: http://www.topografix.com/gpx/gpx_style/0/1/gpx_style.xsd gpx_overlay: http://www.topografix.com/gpx/gpx_overlay/0/1/gpx_overlay.xsd I've also posted a demo GPX file that uses the new schemas. http://www.topografix.com/gpx/samples/topografix/demo.gpx A problem came up when working with multiple schemas - we use <xsd:any namespace="##other"> to allow private elements in GPX. When you include a second namespace in your schema (like gpx_overlay pulling in gpx_style), the ##other creates an ambiguity for the parser. The accepted workaround is to place private elements in their own tag. I defined a new <extensions> tag to use in the new schemas. I also rewrote the base GPX schema to use <extensions>. I left the ##other for backwards compatibility, but in the future it would be good to move away from this. I made three other changes in GPX 1.1: 1. I added the <type> element to <rte> and <trk> (as discussed a few months ago) 2. I pulled out <wpt>, <rte>, and <trk> and made them their own elements. This improves the readability of the schema, and also lets you include <wpt> inside your own objects in the future. 3. I added a base <pt> element. I needed this for <polyline> and <polygon>, and figured it was generic enough to be in the base GPX schema. Proposed GPX 1.1 schema: http://www.topografix.com/gpx/1/1/gpx.xsd One change I didn't make was to remove <url> and <urlname> and replace them with a list of urls and photos, as was discussed last month. I think this is also a good change to make, but since it involves removing existing elements, I skipped it for now. Please take a look at these proposed changes, and add your comments to the discussion. I believe these changes address many of the issues that have been brought up since GPX 1.0 was released, and they do it in a way that preserves compatibility with the current spec. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Aug 12 18:09:22 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > I'm proposing two new public namespaces for displaying text, lines, > and filled shapes on GPS maps. The first schema, gpx_style, deals > with fonts, colors, and fill styles. The second schema, gpx_overlay, > defines elements for text, polylines, and polygons. > > All of these items are common features in mapping software like > OziExplorer, and are starting to find their way onto standalone GPS > receivers as well. > > I've posted 0.1 versions of each schema in the following locations: > gpx_style: > http://www.topografix.com/gpx/gpx_style/0/1/gpx_style.xsd > > gpx_overlay: > http://www.topografix.com/gpx/gpx_overlay/0/1/gpx_overlay.xsd > > I've also posted a demo GPX file that uses the new schemas. > http://www.topografix.com/gpx/samples/topografix/demo.gpx > > A problem came up when working with multiple schemas - we use > <xsd:any namespace="##other"> to allow private elements in GPX. When > you include a second namespace in your schema (like gpx_overlay > pulling in gpx_style), the ##other creates an ambiguity for the > parser. The accepted workaround is to place private elements in their > own tag. I defined a new <extensions> tag to use in the new schemas. > I think that this the overlay namespace will solve a problem for me, where I've drawn regions on GPX files using track, but these regions aren't necessarily targeted for the GPS receiver but for SVG export. So I'm all for the changes. (When I get more time I'll review in detail and comment.) > I also rewrote the base GPX schema to use <extensions>. I left the > ##other for backwards compatibility, but in the future it would be > good to move away from this. I made three other changes in GPX 1.1: > > 1. I added the <type> element to <rte> and <trk> (as discussed a few > months ago) > > 2. I pulled out <wpt>, <rte>, and <trk> and made them their own > elements. This improves the readability of the schema, and also lets > you include <wpt> inside your own objects in the future. > > 3. I added a base <pt> element. I needed this for <polyline> and > <polygon>, and figured it was generic enough to be in the base GPX > schema. > > Proposed GPX 1.1 schema: > http://www.topografix.com/gpx/1/1/gpx.xsd > > One change I didn't make was to remove <url> and <urlname> and replace > them with a list of urls and photos, as was discussed last month. > I think this is also a good change to make, but since it involves > removing existing elements, I skipped it for now. > > Please take a look at these proposed changes, and add your comments to > the discussion. I believe these changes address many of the issues > that have been brought up since GPX 1.0 was released, and they do it > in a way that preserves compatibility with the current spec. > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
robin4jobcurry+yahoo.co.in on Tue Aug 12 22:02:13 2003 (link)
Hello Friends, This is Robin here from Jobcurry Systems Pvt. Ltd. Presently, we are looking for our client for Singapore for professionals with expertise in Java technologies. Further details of the requirement are as follows. Details of the 1st requirement are as follows. Experience:3-4 years experience in Oracle DB & Java based application design, development and testing.Experience in telecom related application development would be added advantage.Good verbal and written communication is must. Qualfication:Bachelor of Computer or Electronics & Communication engineering. Details of the 2nd requirement are as follows. Experience:3-4 years experience in Oracle DB, Java & XML based application design, development and testing.Experience in Rational Rose object modeling tool would be added advantage.Experience in telecom related application development would be added advantage.Good verbal and written communication is must. Qualfication:Bachelor of Computer or Electronics & Communication engineering. Interested candidates kindly send your profiles to robina+jobcurry.com to explore this assignment further. Awaiting your replies. Thanks & Regards Robin Anthony Jobcurry Systems Pvt. Ltd. 020-6634315 Win TVs, Bikes, DVD players and more!Click onYahoo! India Promos --0-203227695-1060750922=:26500
egroups+topografix.com on Mon Aug 18 10:58:35 2003 (link), replying to msg
Hello, Tuesday, August 12, 2003, 4:55:39 PM, I wrote: D> I'm proposing two new public namespaces for displaying text, lines, D> and filled shapes on GPS maps. The first schema, gpx_style, deals D> with fonts, colors, and fill styles. The second schema, gpx_overlay, D> defines elements for text, polylines, and polygons. D> All of these items are common features in mapping software like D> OziExplorer, and are starting to find their way onto standalone GPS D> receivers as well. D> I've posted 0.1 versions of each schema in the following locations: D> gpx_style: D> http://www.topografix.com/gpx/gpx_style/0/1/gpx_style.xsd D> gpx_overlay: D> http://www.topografix.com/gpx/gpx_overlay/0/1/gpx_overlay.xsd D> I've also posted a demo GPX file that uses the new schemas. D> http://www.topografix.com/gpx/samples/topografix/demo.gpx D> A problem came up when working with multiple schemas - we use D> <xsd:any namespace="##other"> to allow private elements in GPX. When D> you include a second namespace in your schema (like gpx_overlay D> pulling in gpx_style), the ##other creates an ambiguity for the D> parser. The accepted workaround is to place private elements in their D> own tag. I defined a new <extensions> tag to use in the new schemas. D> I also rewrote the base GPX schema to use <extensions>. I left the D> ##other for backwards compatibility, but in the future it would be D> good to move away from this. I made three other changes in GPX 1.1: D> 1. I added the <type> element to <rte> and <trk> (as discussed a few D> months ago) D> 2. I pulled out <wpt>, <rte>, and <trk> and made them their own D> elements. This improves the readability of the schema, and also lets D> you include <wpt> inside your own objects in the future. D> 3. I added a base <pt> element. I needed this for <polyline> and D> <polygon>, and figured it was generic enough to be in the base GPX D> schema. D> Proposed GPX 1.1 schema: D> http://www.topografix.com/gpx/1/1/gpx.xsd D> One change I didn't make was to remove <url> and <urlname> and replace D> them with a list of urls and photos, as was discussed last month. D> I think this is also a good change to make, but since it involves D> removing existing elements, I skipped it for now. D> Please take a look at these proposed changes, and add your comments to D> the discussion. I believe these changes address many of the issues D> that have been brought up since GPX 1.0 was released, and they do it D> in a way that preserves compatibility with the current spec. I haven't received any feedback on these proposed changes, other than Dave's comments on gpx_overlay. I'd like to leave the discussion open for the remainder of this week, and then adopt GPX 1.1, gpx_style, and gpx_overlay for public use next Monday. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Aug 19 04:48:13 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Tuesday, August 12, 2003, 4:55:39 PM, I wrote: > > D> I'm proposing two new public namespaces for displaying text, lines, > D> and filled shapes on GPS maps. The first schema, gpx_style, deals > D> with fonts, colors, and fill styles. The second schema, gpx_overlay, > D> defines elements for text, polylines, and polygons. > > D> All of these items are common features in mapping software like > D> OziExplorer, and are starting to find their way onto standalone GPS > D> receivers as well. > > D> I've posted 0.1 versions of each schema in the following locations: > D> gpx_style: > D> http://www.topografix.com/gpx/gpx_style/0/1/gpx_style.xsd > > D> gpx_overlay: > D> http://www.topografix.com/gpx/gpx_overlay/0/1/gpx_overlay.xsd > > D> I've also posted a demo GPX file that uses the new schemas. > D> http://www.topografix.com/gpx/samples/topografix/demo.gpx > > D> A problem came up when working with multiple schemas - we use > D> <xsd:any namespace="##other"> to allow private elements in GPX. When > D> you include a second namespace in your schema (like gpx_overlay > D> pulling in gpx_style), the ##other creates an ambiguity for the > D> parser. The accepted workaround is to place private elements in their > D> own tag. I defined a new <extensions> tag to use in the new schemas. > > D> I also rewrote the base GPX schema to use <extensions>. I left the > D> ##other for backwards compatibility, but in the future it would be > D> good to move away from this. I made three other changes in GPX 1.1: > > D> 1. I added the <type> element to <rte> and <trk> (as discussed a few > D> months ago) > > D> 2. I pulled out <wpt>, <rte>, and <trk> and made them their own > D> elements. This improves the readability of the schema, and also lets > D> you include <wpt> inside your own objects in the future. > > D> 3. I added a base <pt> element. I needed this for <polyline> and > D> <polygon>, and figured it was generic enough to be in the base GPX > D> schema. > > D> Proposed GPX 1.1 schema: > D> http://www.topografix.com/gpx/1/1/gpx.xsd > > D> One change I didn't make was to remove <url> and <urlname> and replace > D> them with a list of urls and photos, as was discussed last month. > D> I think this is also a good change to make, but since it involves > D> removing existing elements, I skipped it for now. > > D> Please take a look at these proposed changes, and add your comments to > D> the discussion. I believe these changes address many of the issues > D> that have been brought up since GPX 1.0 was released, and they do it > D> in a way that preserves compatibility with the current spec. > > I haven't received any feedback on these proposed changes, other than > Dave's comments on gpx_overlay. I'd like to leave the discussion open > for the remainder of this week, and then adopt GPX 1.1, gpx_style, > and gpx_overlay for public use next Monday. > Dan, I read these over and it looks like this approach will give a very rich drawing capability for people making their own maps. If you keep going in this direction I'd also suggest that you think about providing a method for including predefined vector ICONS, such as the SVG def/use approach where a path can be predefined and then used at another location. I've experimented with this approach in SVG output from Wissenbach Map. One point that I think that you should clarify is whether the text sizes and line widths should scale as the maps zoom in or out--these sizes are applied after scaling of the map. I won't get around to actually trying these out as I said earlier. I'm busy experimenting with a XML-DOM-based multi-platform program ming using the Trolltech Qt toolkit, instead of Microsoft MFC. (The result will be a GPX application on Embedded Linux/Sharp Zaurus). Dave > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
robin4jobcurry+yahoo.co.in on Mon Sep 15 01:16:25 2003 (link)
Hello All, This is to update you all on excellent openings in JAVA/PERL available with our client. Our client is India's leading IT giant, considered one of the top companies of India. Further details of the requirement are as follows. Designation: Software Engineer Experience:3-5yrs Skills: Java/Perl/Cgi Location: Bangalore Interested candidates kindly get in touch with us to explore this assignment. Send us an updated copy of your profile to robina+jobcurry.com Thanks & Regards Robin Anthony Jobcurry Systems Pvt. Ltd. 020-6634315 Yahoo! India Matrimony: Find your partner online.Post your profile. --0-405220808-1063613777=:64247
groups+mrgis.com on Tue Sep 16 13:40:19 2003 (link)
MrGIS.com is a new site dedicated to GIS and GPS users and professionals. No mass emails, no sales pitches, no fees. This site is for the use of Professional GIS Personnel, Photogrammetrist, First Responders, Surveyors, Homeland Defense Personnel and Planners, and any other applicable field. The uses of the site are, but by no means limited to, questions, support, information, research, etc, EXCEPT targeted selling and/or advertising by vendors and manufacturers (there are seperate forums set up for press releases, job postings and product information by vendors). The MrGIS Message Board is the main feature of the site. Use it to post whatever information you are looking for or want to share. Find information on GIS software, AVL or GPS equipment, success stories, anything you can think of. Some of the benefits of the MrGIS Message Board over traditional Email List Serves are: -Specific forums related to the topics you want to know about (i.e. ArcView, Survey GPS, Wireless Communication for Data, etc.) -Searchable database to look for information specific to your needs. -Optional email notification when someone responds to your post. -User Groups specific to your industry and application (ArcInfo, AutoCAD, ESRI, AVL, Trimble Mapping GPS, etc) -No pop-up ads or ad banners -Regional User Group Forums (i.e. Baghdad ArcInfo Users Group) -Separate forums for job listings, press releases and Vendor/Manufacturer info -Send and receive private messages to your MrGIS Message Board account, not to your personal or work email. -Much, much more! Please feel free to contact me if you have any questions. Recommendations and suggestions are always welcome! http://www.mrgis.com Best regards, MrGIS mrgis+mrgis.com
martinp13+earthlink.net on Tue Sep 16 14:13:50 2003 (link), replying to msg
I would recommend you get the URL working before posting a message with the URL. :) mrgis2003 <groups+mrgis.com> wrote:MrGIS.com is a new site dedicated to GIS and GPS users and professionals. No mass emails, no sales pitches, no fees. This site is for the use of Professional GIS Personnel, Photogrammetrist, First Responders, Surveyors, Homeland Defense Personnel and Planners, and any other applicable field. The uses of the site are, but by no means limited to, questions, support, information, research, etc, EXCEPT targeted selling and/or advertising by vendors and manufacturers (there are seperate forums set up for press releases, job postings and product information by vendors). The MrGIS Message Board is the main feature of the site. Use it to post whatever information you are looking for or want to share. Find information on GIS software, AVL or GPS equipment, success stories, anything you can think of. Some of the benefits of the MrGIS Message Board over traditional Email List Serves are: -Specific forums related to the topics you want to know about (i.e. ArcView, Survey GPS, Wireless Communication for Data, etc.) -Searchable database to look for information specific to your needs. -Optional email notification when someone responds to your post. -User Groups specific to your industry and application (ArcInfo, AutoCAD, ESRI, AVL, Trimble Mapping GPS, etc) -No pop-up ads or ad banners -Regional User Group Forums (i.e. Baghdad ArcInfo Users Group) -Separate forums for job listings, press releases and Vendor/Manufacturer info -Send and receive private messages to your MrGIS Message Board account, not to your personal or work email. -Much, much more! Please feel free to contact me if you have any questions. Recommendations and suggestions are always welcome! http://www.mrgis.com Best regards, MrGIS mrgis+mrgis.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!? Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-2058799465-1063746828=:35319
bogamo+yahoo.com on Fri Sep 19 04:19:09 2003 (link)
Hello All, I don't know why I didn't do this before, but I finally gave TrailRegistry the ability to accept GPX uploads. If any of you have a GPX file saved somewhere with a track log or waypoints in it, please consider donating the trail to TrailRegistry. http://www.trailregistry.com Thank you, -Geoff
troyh+dirtworld.com on Thu Sep 25 10:49:13 2003 (link)
First let me preface this by saying I'm no XML guru. (this will soon become obvious). I'm having a hard time parsing GPX with .net. I'm using the built-in XML reader which works great for other XML documents. But for GPX all I get is the meta data (time, gpx_Id, version & creator) My test code is quite basic: Dim ds As New DataSet ds.ReadXml("c:\test.gpx") DataGrid1.DataSource = ds DataGrid1.DataBind() I realize this isn't a .net support group, but hopefully someone with GPX experience can point me in the right direction. Thanks in advance Troy
eeronpoika+yahoo.com on Thu Sep 25 13:48:29 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, "t_hop99" <troyh+d...> wrote: > First let me preface this by saying I'm no XML guru. (this will soon > become obvious). > > I'm having a hard time parsing GPX with .net. I'm using the built- in > XML reader which works great for other XML documents. But for GPX all > I get is the meta data (time, gpx_Id, version & creator) > > My test code is quite basic: > > Dim ds As New DataSet > ds.ReadXml("c:\test.gpx") > DataGrid1.DataSource = ds > DataGrid1.DataBind() > > I realize this isn't a .net support group, but hopefully someone with > GPX experience can point me in the right direction. > > Thanks in advance > > Troy Maybe this is blind guiding blind, but have you somehow introduced GPX-schema,e.g. from http://www.topografix.com/GPX/1/0/gpx.xsd? Regards, Eino www.iki.fi/eino.uikkanen/gb/
jg.okt2003+hccnet.nl on Wed Oct 08 13:30:41 2003 (link)
Is there a possibility to include/embed GPX entities in a HTML document? I would like to make a HTML page with 'hyperlinks' that, by clicking on them, send a (set of) waypoint(s), route, track to for example EasyGPS or GPSBabel, and/or to a GPS. Theoretically, this seems possible. Is that true, and what is the systax to use? My browser does send the data to EasyGPS when I click on a gpx document, so the mechanism works. I only want to include the GPX data within the same HTML file.
robertlipe+usa.net on Wed Oct 08 13:56:36 2003 (link), replying to msg
> browser does send the data to EasyGPS when I click on a gpx document, > so the mechanism works. I only want to include the GPX data within the > same HTML file. I think it has to be in a different file because you need a new HTTP header that displays the mime type that can trigger the download/save as/helper mechanism. RJL
egroups+topografix.com on Thu Oct 09 05:30:06 2003 (link), replying to msg
Hello jantgerard, Wednesday, October 8, 2003, 4:30:37 PM, you wrote: j> Is there a possibility to include/embed GPX entities in a HTML j> document? I would like to make a HTML page with 'hyperlinks' that, by j> clicking on them, send a (set of) waypoint(s), route, track to for j> example EasyGPS or GPSBabel, and/or to a GPS. Theoretically, this j> seems possible. Is that true, and what is the systax to use? My j> browser does send the data to EasyGPS when I click on a gpx document, j> so the mechanism works. I only want to include the GPX data within the j> same HTML file. You'd probably need to use something on the server side to initiate the download. Perhaps you can use a form with the GPX snippet as a hidden field, and post it back to the server to initiate the download? Another option is to rename the GPX file to .xml, and include a stylesheet to display it as HTML in the browser. Then the user can just save the files as a .gpx file. Finally, you could include GPX snippets as text in a form, and let the user copy the GPX and paste into EasyGPS. My programs use GPX as the text format for copy and paste. If other programs started supporting this, it would be a fast way to move data between GPX-enabled apps. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
stevecharles39439+yahoo.com on Fri Oct 24 17:46:42 2003 (link)
Well, I don't know about you?but I've been having a hard time finding work in the current economical conditions. After being laid off from my previous job, I decided to start doing contract work to pay the bills after not having a lot of luck finding a new job. It wasn't that I couldn't find a job, just that all the jobs I found out there were either entry level, or they wanted a bit more qualifications than I had. So, it was off to hunting for contracts and looking for clients. This has gone alright, but I found that most months I just couldn't make ends meet. So I decided to look into some other areas and see if I could find another option. I knew one thing for sure though, working from home was WAY BETTER than going into the office. After a few weeks of searching the net in my free time I found just what I was looking for. I started working with this company and setting up my own home based business. After only 4 months my business income is surpassing my income from doing contracts and things are looking great! If you're interested in finding out more you can check them out at http://www.GraspOn2dreams.com/?refid=c3 Or you can call them at 1-888-233-0385 and they'll have someone call you. Hope this helps someone, Steven Charles
gps_maps+travelbygps.com on Tue Nov 04 04:51:06 2003 (link)
I'm going through all my GPS map description web pages, revising keyword and description tags. This would be a good time to geocode (?) these pages html (php) pages. What is the convention? - Doug www.travelbygps.com
robertlipe+usa.net on Tue Nov 04 05:58:13 2003 (link), replying to msg
Doug Adomatis wrote: > I'm going through all my GPS map description web pages, revising > keyword and description tags. This would be a good time to geocode > (?) these pages html (php) pages. What is the convention? It isn't GPX, but the closest effort I've seen yet to attempt to classify web pages by location is http://geourl.com/ . RJL
mmooney+accesscomm.ca on Tue Nov 04 08:49:04 2003 (link)
Please remove me from your mailing list as your messages do not seem to require my input. Original Message: ----------------- From: Robert Lipe robertlipe+usa.net Date: Tue, 4 Nov 2003 07:58:08 -0600 To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Lat/Lon Meta tags for web pages? <html><body> <tt> Doug Adomatis wrote:<BR> > I'm going through all my GPS map description web pages, revising <BR> > keyword and description tags.� This would be a good time to geocode<BR> > (?) these pages html (php) pages.� What is the convention?<BR> <BR> It isn't GPX, but the closest effort I've seen yet to attempt to classify<BR> web pages by location is <a href="http://geourl.com/">http://geourl.com/</a> . <BR> <BR> RJL<BR> </tt> <br> <!-- |**|begin egp html banner|**| --> <table border=0 cellspacing=0 cellpadding=2> <tr bgcolor=#FFFFCC> <td align=center><font size="-1" color=#003399><b>Yahoo! Groups Sponsor</b></font></td> </tr> <tr bgcolor=#FFFFFF> <td align=center width=470><table border=0 cellpadding=0 cellspacing=0> <tr> <td align=center><font face=arial size=-2>ADVERTISEMENT</font><br><a href="http://rd.yahoo.com/M=267637.4116732.5333197.1261774/D=egroupweb/S=170 6030390:HM/A=1754452/R=0/SIG=11tpoan5t/*http://www.netflix.com/Default?mqso= 60178324&partid=4116732" alt=""><img src="http://us.a1.yimg.com/us.yimg.com/a/ne/netflix/yhoo0903_lf_300250A.gif" alt="click here" width="300" height="250" border="0"></a></td></tr></table> </td> </tr> <tr><td><img alt="" width=1 height=1 src="http://us.adserver.yahoo.com/l?M=267637.4116732.5333197.1261774/D=egrou pmail/S=:HM/A=1754452/rand=515793020"></td></tr> </table> <!-- |**|end egp html banner|**| --> <br> <tt> To unsubscribe from this group, send an email to:<BR> gpsxml-unsubscribe+yahoogroups.com<BR> <BR> </tt> <br> <br> <tt>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.</tt> </br> </body></html> -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .
ronklogan+hotmail.com on Mon Nov 10 11:32:18 2003 (link), replying to msg
Hi, all - long buildup to answer the original question, AND I pose another question to the group at the end. So I had been decoding my GPX files the hard way by loading them into an XmlDocument object and walking through the DOM. Then I saw these messages and thought I had been silly not to use XmlSerialization! But then I ran into a problem.. First off, I downloaded the gpx.xsd file referenced in the last message, then I ran the XSD.EXE tool on it to generate a CS file for all the classes: xsd /c /n:Topografix gpx.xsd Then I added the gpx.cs file to my project and wrote the following (really short) code in my form to parse a GPX file: private Topografix.gpx ParseGPXFile( string fileName ) { XmlSerializer serializer = new XmlSerializer( typeof(Topografix.gpx) ); using( StreamReader reader = new StreamReader( fileName ) ) { return (Topografix.gpx)serializer.Deserialize( reader ); } } But I was always getting a really weird error on the constructor of the XmlSerializer object when I ran my app - something about a randomly-named dll not being present, with the name changing every time I ran the app. So I asked a friend who's a little more proficient at XmlSerialization, and he told me that XmlSerialization was choking on the code auto-generated from the XSD - it had a two-dimensional array in it and XmlSerialization doesn't seem to like those. So I looked into it and noticed something strange: the xsd tool generated "incorrect" CS classes for the specified XSD! The trk element should contain an array of trkseg elements, which in turn contain an array of trkpt elements. But because the trkseg contains nothing but the trkpt array, the tool was taking some sort of shortcut and specifying the trk element as containing a two-dimensional array of trkpt objects - completely skipping the trkseg elements altogether! And that two-dimensional array messed up the constructor. So I then manually went in and "fixed" the auto-generated gpx.cs file so that the trk element contained a single array of trkseg elements, which contained a single array of trkpt elements and the code works great. But it really irks me that I have to manually adjust my cs file after running the xsd tool. And that got me thinking: the only reason the xsd tool took its [stupid] shortcut was because the trkseg element contains nothing but an array of trkpt elements. If it contained anything else - any other elements whatsoever -- the tool generates the correct cs classes. But what can be added? Then I noticed that the existing XSD is laced with extra "xsd:any" elements that allow extensions to most of the existing elements - except trkseg. So that (finally) bring me to my question: shouldn't the trkseg element be defined the same way most of the other elements are -- so that people can add extensions to them should they choose to? For instance, if you look at the gpx.xsd file, shouldn't the trkseg element be defined as: <xsd:element name="trkseg" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <!-- elements must appear in this order --> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" /> <xsd:element name="trkpt" minOccurs="0" maxOccurs="unbounded"> ...definition for trkpt snipped... </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> Just wondering. I mean, I don't think it would have any impact on anybody who isn't interested in adding custom elements to the trkseg element, or letting .net-heads like me auto-generate their cs files without having to manually tweak them. But I thought I'd ask. -Ron Logan World-Wide Media eXchange http://wwmx.org <http://wwmx.org/> A picture is worth a thousand worlds.. (oh, and I attached the gps.cs file I manually tweaked - assuming the XSD doesn't get changed as suggested) _____ From: eeronpoika [mailto:eeronpoika+yahoo.com] Sent: Thursday, September 25, 2003 1:48 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: GPX and .NET? --- In gpsxml+yahoogroups.com, "t_hop99" <troyh+d...> wrote: > First let me preface this by saying I'm no XML guru. (this will soon > become obvious). > > I'm having a hard time parsing GPX with .net. I'm using the built- in > XML reader which works great for other XML documents. But for GPX all > I get is the meta data (time, gpx_Id, version & creator) > > My test code is quite basic: > > Dim ds As New DataSet > ds.ReadXml("c:\test.gpx") > DataGrid1.DataSource = ds > DataGrid1.DataBind() > > I realize this isn't a .net support group, but hopefully someone with > GPX experience can point me in the right direction. > > Thanks in advance > > Troy Maybe this is blind guiding blind, but have you somehow introduced GPX-schema,e.g. from http://www.topografix.com/GPX/1/0/gpx.xsd? Regards, Eino www.iki.fi/eino.uikkanen/gb/ Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=194081.3897168.5135684.1261774/D=egroupweb/S=17060303 90:HM/A=1706996/R=0/SIG=11p5b9ris/*http:/www.ediets.com/start.cfm?code=30509 &media=atkins> click here <http://us.adserver.yahoo.com/l?M=194081.3897168.5135684.1261774/D=egroupmai l/S=:HM/A=1706996/rand=376066891> 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_001_0018_01C3A77E.42AC1E80
mmooney+accesscomm.ca on Mon Nov 10 17:27:01 2003 (link)
Please remove me from your mailing list. Thanks ATV ----- Original Message ----- From: Ron Logan To: gpsxml+yahoogroups.com Sent: Monday, November 10, 2003 1:32 PM Subject: RE: [gpsxml] Re: GPX and .NET? Hi, all - long buildup to answer the original question, AND I pose another question to the group at the end. So I had been decoding my GPX files the hard way by loading them into an XmlDocument object and walking through the DOM. Then I saw these messages and thought I had been silly not to use XmlSerialization! But then I ran into a problem.. First off, I downloaded the gpx.xsd file referenced in the last message, then I ran the XSD.EXE tool on it to generate a CS file for all the classes: xsd /c /n:Topografix gpx.xsd Then I added the gpx.cs file to my project and wrote the following (really short) code in my form to parse a GPX file: private Topografix.gpx ParseGPXFile( string fileName ) { XmlSerializer serializer = new XmlSerializer( typeof(Topografix.gpx) ); using( StreamReader reader = new StreamReader( fileName ) ) { return (Topografix.gpx)serializer.Deserialize( reader ); } } But I was always getting a really weird error on the constructor of the XmlSerializer object when I ran my app - something about a randomly-named dll not being present, with the name changing every time I ran the app. So I asked a friend who's a little more proficient at XmlSerialization, and he told me that XmlSerialization was choking on the code auto-generated from the XSD - it had a two-dimensional array in it and XmlSerialization doesn't seem to like those. So I looked into it and noticed something strange: the xsd tool generated "incorrect" CS classes for the specified XSD! The trk element should contain an array of trkseg elements, which in turn contain an array of trkpt elements. But because the trkseg contains nothing but the trkpt array, the tool was taking some sort of shortcut and specifying the trk element as containing a two-dimensional array of trkpt objects - completely skipping the trkseg elements altogether! And that two-dimensional array messed up the constructor. So I then manually went in and "fixed" the auto-generated gpx.cs file so that the trk element contained a single array of trkseg elements, which contained a single array of trkpt elements and the code works great. But it really irks me that I have to manually adjust my cs file after running the xsd tool. And that got me thinking: the only reason the xsd tool took its [stupid] shortcut was because the trkseg element contains nothing but an array of trkpt elements. If it contained anything else - any other elements whatsoever -- the tool generates the correct cs classes. But what can be added? Then I noticed that the existing XSD is laced with extra "xsd:any" elements that allow extensions to most of the existing elements - except trkseg. So that (finally) bring me to my question: shouldn't the trkseg element be defined the same way most of the other elements are -- so that people can add extensions to them should they choose to? For instance, if you look at the gpx.xsd file, shouldn't the trkseg element be defined as: <xsd:element name="trkseg" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <!-- elements must appear in this order --> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" /> <xsd:element name="trkpt" minOccurs="0" maxOccurs="unbounded"> ...definition for trkpt snipped... </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> Just wondering. I mean, I don't think it would have any impact on anybody who isn't interested in adding custom elements to the trkseg element, or letting .net-heads like me auto-generate their cs files without having to manually tweak them. But I thought I'd ask. -Ron Logan World-Wide Media eXchange http://wwmx.org A picture is worth a thousand worlds.. (oh, and I attached the gps.cs file I manually tweaked - assuming the XSD doesn't get changed as suggested) ------------------------------------------------------------------------------ From: eeronpoika [mailto:eeronpoika+yahoo.com] Sent: Thursday, September 25, 2003 1:48 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: GPX and .NET? --- In gpsxml+yahoogroups.com, "t_hop99" <troyh+d...> wrote: > First let me preface this by saying I'm no XML guru. (this will soon > become obvious). > > I'm having a hard time parsing GPX with .net. I'm using the built- in > XML reader which works great for other XML documents. But for GPX all > I get is the meta data (time, gpx_Id, version & creator) > > My test code is quite basic: > > Dim ds As New DataSet > ds.ReadXml("c:\test.gpx") > DataGrid1.DataSource = ds > DataGrid1.DataBind() > > I realize this isn't a .net support group, but hopefully someone with > GPX experience can point me in the right direction. > > Thanks in advance > > Troy Maybe this is blind guiding blind, but have you somehow introduced GPX-schema,e.g. from http://www.topografix.com/GPX/1/0/gpx.xsd? Regards, Eino www.iki.fi/eino.uikkanen/gb/ 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. 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_000A_01C3A7C1.37AFCA20
egroups+topografix.com on Tue Nov 11 07:45:40 2003 (link), replying to msg
Hello, Monday, November 10, 2003, 2:32:02 PM, Ron wrote: R> I noticed that the existing XSD is laced with extra "xsd:any" R> elements that allow extensions to most of the existing elements - except R> trkseg. R> So that (finally) bring me to my question: shouldn't the trkseg element be R> defined the same way most of the other elements are -- so that people can R> add extensions to them should they choose to? For instance, if you look at R> the gpx.xsd file, shouldn't the trkseg element be defined as: R> <xsd:element name="trkseg" minOccurs="0" R> maxOccurs="unbounded"> R> <xsd:complexType> R> <xsd:sequence> R> <!-- elements must appear in this order --> R> <xsd:any namespace="##other" minOccurs="0" R> maxOccurs="unbounded" /> R> <xsd:element name="trkpt" minOccurs="0" R> maxOccurs="unbounded"> R> ...definition for trkpt snipped... R> </xsd:element> R> </xsd:sequence> R> </xsd:complexType> R> </xsd:element> R> Just wondering. I mean, I don't think it would have any impact on anybody R> who isn't interested in adding custom elements to the trkseg element, or R> letting .net-heads like me auto-generate their cs files without having to R> manually tweak them. But I thought I'd ask. I believe this was an oversight when we first created GPX 1.0. I've added your change to the GPX 1.1 spec: http://www.topografix.com/GPX/1/1/gpx.xsd -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
gpsxml+yahoogroups.com on Tue Nov 11 19:54:16 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 : /Click here for a great dating service Uploaded by : fusamotece1479 <fusamotece1479+yahoo.com> Description : Browse through singles You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/Click%20here%20for%20a%20great%20dating%20service To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, fusamotece1479 <fusamotece1479+yahoo.com>
ronklogan+hotmail.com on Tue Nov 18 14:17:04 2003 (link), replying to msg
Hi, all. I've got a little problem, and I was wondering if anyone else has run into something like this. I wrote a small utility for downloading tracks from a Garmin GPS unit and saving the data as GPX files (http://wwmx.org). A client has informed me that ExpertGPS doesn't read the files I create - so I downloaded and checked with EasyGPS, and it doesn't read them either. They don't give any error message; they just don't show the files as containing any data. But the GPX files validate just fine with the 1.0 gpx.xsd definition (I've attached a sample to this message). Any ideas? Is my GPX malformed or something? Thanks! Ron Logan http://wwmx.org A picture is worth a thousand worlds.... ------=_NextPart_000_0025_01C3ADDE.9ED99370
ronklogan+hotmail.com on Thu Nov 20 10:31:20 2003 (link), replying to msg
Holy cow -- I'm sorry for the spam but I must apologize to the list for attaching such a HUGE gpx file to my last message. That was just plain thoughtless of me. Sorry. I won't let that happen again. -r ________________________________________ From: Ron Logan [mailto:ronklogan+hotmail.com] Sent: Tuesday, November 18, 2003 2:17 PM To: gpsxml+yahoogroups.com Subject: RE: [gpsxml] Re: GPX and .NET? Hi, all. I've got a little problem.... <SNIP>
amandapaixaom+yahoo.com.br on Sun Nov 23 12:53:25 2003 (link)
Visit this site http://www.geocities.com/zemaplata/index.html
piviwivezo1135+yahoo.com on Wed Nov 26 20:48:37 2003 (link)
Online dating is the fastest growing service online this site helps to review the sites: http://www.reviewonlinedating.com
gpsxml+yahoogroups.com on Wed Nov 26 20:48:40 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 : /Only source for real online dating reviews Uploaded by : piviwivezo1135 <piviwivezo1135+yahoo.com> Description : Review Dating Sites You can access this file at the URL http://groups.yahoo.com/group/gpsxml/files/Only%20source%20for%20real%20online%20dating%20reviews To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, piviwivezo1135 <piviwivezo1135+yahoo.com>
7Ghost+gmx.de on Sat Nov 29 08:07:08 2003 (link)
Hi, i�m relativ new to this hole GPSxml subject. So for a start i just wanted to know which developer tools you use ? Thanks and sorry for my bad english....:-)
davewissenbach+yahoo.com on Sat Nov 29 14:55:09 2003 (link), replying to msg
--- In gpsxml+yahoogroups.com, "sebastian_matyas" <7Ghost+g...> wrote: > Hi, > > i�m relativ new to this hole GPSxml subject. So for a start i just > wanted to know which developer tools you use ? > > Thanks and sorry for my bad english....:-) Wissenbach Map3D was written with Microsoft Visual C++, which is pretty good if you want a program which works on Windows only. I'm working on a new Cross-Platform version of this topographic mapping program using the Qt toolkit from Trolltech, which I highly recommend. This is expecially good because of the built-in support for XML, and easy handling of JPEG and SVG images. Dave
egroups+topografix.com on Mon Dec 01 07:03:22 2003 (link), replying to msg
Hello, Saturday, November 29, 2003, 11:07:05 AM, Sebastian wrote: s> i?m relativ new to this hole GPSxml subject. So for a start i just s> wanted to know which developer tools you use ? I'm also using Microsoft Visual C++. I'd be interested to hear what XML-parsing solution everyone is using. I'm currently using my own state-based parser written in C. It's very small and fast, but it doesn't handle text encodings correctly. I'll probably switch to a solution like MSXML in the future. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
robertlipe+usa.net on Mon Dec 01 16:03:08 2003 (link), replying to msg
Dan Foster wrote: > I'd be interested to hear what XML-parsing solution everyone is > using. I'm currently using my own state-based parser written in C. I used expat in gpsbabel because it's available everywhere. I must be using it in a really stupid way, though as it pushes an insane amount of state handling into the caller. RJL
hank+yerpso.net on Mon Dec 01 16:46:41 2003 (link), replying to msg
> I used expat in gpsbabel because it's available everywhere. I must be > using it in a really stupid way, though as it pushes an insane amount of > state handling into the caller. > I don't think you're using it stupidly ... I've thought the same thing calling it from PHP. It does work though and that's something :) -- Hank Marquardt <hank+yerpso.net> http://web.yerpso.net GPG Id: 2BB5E60C Fingerprint: D807 61BC FD18 370A AC1D 3EDF 2BF9 8A2D 2BB5 E60C
charles+benetech.org on Mon Dec 08 09:39:17 2003 (link), replying to msg
This seems to work for me and note the miss-spelling of attachment is needed Add the follwing HTML headers Content-Type=application/octet-stream Content-Disposition=attatchment; filename=nameOfFile.txt Content-Length=SizeOfAttachment Hope this helps Charles. --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello jantgerard, > > Wednesday, October 8, 2003, 4:30:37 PM, you wrote: > > j> Is there a possibility to include/embed GPX entities in a HTML > j> document? I would like to make a HTML page with 'hyperlinks' that, by > j> clicking on them, send a (set of) waypoint(s), route, track to for > j> example EasyGPS or GPSBabel, and/or to a GPS. Theoretically, this > j> seems possible. Is that true, and what is the systax to use? My > j> browser does send the data to EasyGPS when I click on a gpx document, > j> so the mechanism works. I only want to include the GPX data within the > j> same HTML file. > > You'd probably need to use something on the server side to initiate > the download. Perhaps you can use a form with the GPX snippet as a > hidden field, and post it back to the server to initiate the download? > > Another option is to rename the GPX file to .xml, and include a > stylesheet to display it as HTML in the browser. Then the user can > just save the files as a .gpx file. > > Finally, you could include GPX snippets as text in a form, and let the > user copy the GPX and paste into EasyGPS. My programs use GPX as the > text format for copy and paste. If other programs started supporting > this, it would be a fast way to move data between GPX-enabled apps. > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
jmh+hypercubed.com on Tue Dec 09 21:30:07 2003 (link)
I'm the developer of a tool that can extract coordinate data from Microsoft MapPoint ( http://www.hypercubed.com/projects/coordex/ ). One of the file formats I can import and export is GPX files. I've been asked by a user to include the street address for points that are associated with one. Examining the GPX 1.0 Schema I see that I can simply add a "privately defined wpt elements" to the file (for example <streetaddress>1600 Pennsylvania Avenue NW Washington, DC 20500</streetaddress>. However from what I read here that method is depreciated so I should add a extensions instead (as specified in GPX 1.1 Schema). If I add a an extension the perhaps I should break up the address into components (i.e. <street>, <city>, <zip>). Any suggestions. Is this something that could be added to the overall Schema or does the community feel that this is best left as an extension. Are there any good examples of using the extensions. I've seen the geocaching.com extensions but they don't use the extensions tag but instead specify a supplemental xml schema document. Is that required for extensions?
robertlipe+usa.net on Tue Dec 09 22:16:19 2003 (link), replying to msg
Answering not as an GPX/XML authoritatarian, but rather a plain ole experienced Computer Guy... > 1.1 Schema). If I add a an extension the perhaps I should break up > the address into components (i.e. <street>, <city>, <zip>). It's _always_ easier to put data together than it is to break it apart, so if all other things are equal, let the markup reflect the underlying data. In this case, that tie-breaker would go toward keeping separate tags. Yeah, there's the detail of international addresses, but that's a solvable problem. Hint: "find nearest by zip" is a whole lot easier when you don't have to run around all the records trying to guess which of the numbers in "address" happens to be a zip. RJL
egroups+topografix.com on Wed Dec 10 16:30:17 2003 (link), replying to msg
Hello labtek, Wednesday, December 10, 2003, 12:30:03 AM, you wrote: l> I'm the developer of a tool that can extract coordinate data from l> Microsoft MapPoint ( http://www.hypercubed.com/projects/coordex/ ). l> One of the file formats I can import and export is GPX files. I've l> been asked by a user to include the street address for points that l> are associated with one. Examining the GPX 1.0 Schema I see that I l> can simply add a "privately defined wpt elements" to the file (for l> example <streetaddress>1600 Pennsylvania Avenue NW Washington, DC l> 20500</streetaddress>. However from what I read here that method is l> depreciated so I should add a extensions instead (as specified in GPX l> 1.1 Schema). If I add a an extension the perhaps I should break up l> the address into components (i.e. <street>, <city>, <zip>). l> Any suggestions. Is this something that could be added to the l> overall Schema or does the community feel that this is best left as l> an extension. l> Are there any good examples of using the extensions. I've seen the l> geocaching.com extensions but they don't use the extensions tag but l> instead specify a supplemental xml schema document. Is that required l> for extensions? I'd break the address up into discrete elements, at least to the point of isolating street, city, state/province, zip/postcode, and country. Google finds some proposed address schemas that you might use as a starting point, or you could adopt one of those entirely. I think this is an ideal case for using a namespace extension. So you'd have something like: <wpt lat="..." lon="..."> <desc>White House</desc> <gpx_addr:address> <gpx_addr:street>1600 Pennsylvania Ave</gpx_addr:street> <gpx_addr:city>Washington</gpx_addr:city> <gpx_addr:state>DC</gpx_addr:state> <gpx_addr:country>USA</gpx_addr:country> </gpx_addr:address> </wpt> For examples of namespace extensions, see: <http://www.topografix.com/gpx/gpx_style/0/1/gpx_style.xsd> <http://www.topografix.com/gpx/gpx_overlay/0/1/gpx_overlay.xsd> <http://www.topografix.com/gpx/samples/topografix/demo.gpx> -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
jmh+hypercubed.com on Thu Dec 11 22:09:52 2003 (link), replying to msg
Thanks Dan. I think the extension part is clear now so my only question now is do I need to create an extension xsd for the file to be considered "valid"? --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello labtek, > > Wednesday, December 10, 2003, 12:30:03 AM, you wrote: > > l> I'm the developer of a tool that can extract coordinate data from > l> Microsoft MapPoint ( http://www.hypercubed.com/projects/coordex/ ). > l> One of the file formats I can import and export is GPX files. I've > l> been asked by a user to include the street address for points that > l> are associated with one. Examining the GPX 1.0 Schema I see that I > l> can simply add a "privately defined wpt elements" to the file (for > l> example <streetaddress>1600 Pennsylvania Avenue NW Washington, DC > l> 20500</streetaddress>. However from what I read here that method is > l> depreciated so I should add a extensions instead (as specified in GPX > l> 1.1 Schema). If I add a an extension the perhaps I should break up > l> the address into components (i.e. <street>, <city>, <zip>). > > l> Any suggestions. Is this something that could be added to the > l> overall Schema or does the community feel that this is best left as > l> an extension. > > l> Are there any good examples of using the extensions. I've seen the > l> geocaching.com extensions but they don't use the extensions tag but > l> instead specify a supplemental xml schema document. Is that required > l> for extensions? > > I'd break the address up into discrete elements, at least to the point > of isolating street, city, state/province, zip/postcode, and country. > Google finds some proposed address schemas that you might use as a > starting point, or you could adopt one of those entirely. > > I think this is an ideal case for using a namespace extension. So > you'd have something like: > <wpt lat="..." lon="..."> > <desc>White House</desc> > <gpx_addr:address> > <gpx_addr:street>1600 Pennsylvania Ave</gpx_addr:street> > <gpx_addr:city>Washington</gpx_addr:city> > <gpx_addr:state>DC</gpx_addr:state> > <gpx_addr:country>USA</gpx_addr:country> > </gpx_addr:address> > </wpt> > > For examples of namespace extensions, see: > <http://www.topografix.com/gpx/gpx_style/0/1/gpx_style.xsd> > <http://www.topografix.com/gpx/gpx_overlay/0/1/gpx_overlay.xsd> > <http://www.topografix.com/gpx/samples/topografix/demo.gpx> > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
7Ghost+gmx.de on Tue Dec 16 02:48:23 2003 (link)
Hi, i wanted to know which programming language gives me the best support to handle XML? C# Microsoft.NET C/C++ AutoLISP/VLISP If somenone has experience with XML and autodesk map, which one of those should i use if i had to use XML in the context of Topologies? Or is there some way to include java to map? Thanks for your answers... Sebastian Matyas -- +++ GMX - die erste Adresse f?r Mail, Message, More +++ Neu: Preissenkung f?r MMS und FreeMMS! http://www.gmx.net
ronklogan+hotmail.com on Tue Dec 16 09:12:44 2003 (link)
Hi, Sebastian. First off, Microsoft .NET isn't a language -- the Microsoft .NET Framework is a runtime that's language independent. You can use C#, C++, VisualBasic, Perl, etc. There are others, but those are the ones I have personally used with it. Now, that being said, I am partial to C# and the .NET Framework (although I know there are others out there scoffing right now). The XML support is fantastic, making it pretty darn easy to do absolutely anything you need to do quickly and easily. It's also quite powerful. I've written complex video image-processing algorithms in C# that perform at a comparable rate to C/C++. Obviously not as good, but close enough to satisfy my project requirements, plus give me a safe, powerful, and rapid development environment. I've written a [rather trivial] tool in C# that read GPS tracks from Garmin devices and writes GPX files for both the PC and PocketPC systems, and a whole slew of applications and utilities (most unpublished) that process GPX files. The World-Wide Media eXchange (http://wwmx.org) and all the utilities we provide with it are entirely written in C# to the .NET Framework. The support is just there -- I don't have to worry about reading or writing the XML, I can concentrate on processing the data, images, and maps as I see fit. C/C++ used to be my language of preference, but with all that's been going on in the industry these last several years with security holes and buffer overruns, etc, I've come to the conclusion that no matter how good you think you are, you will eventually shoot yourself in the foot somehow using that language. You just can't maintain the needed level of diligence 100% of the time over the course of your career. I'm probably stepping in someone's religious war, but I believe security holes must be stamped out if the consumer software industry is to move forward -- and C/C++ is a prime culprit in this fiasco. I've seen some of the best computer programmers in the world get dinged because they wrote some perfectly good C/C++ code using acceptable assumptions for the project, and later the code gets reused in a little bit different way by other developers who didn't know about or understand those assumptions, or are operating under different requirements, and -- BANG! -- new buffer overrun security hole in the news. We must move to more type-safe languages and let this one die the death that has been long coming. Let the flames begin! :) VB makes me want to gag. Always has; always will. I haven't used LISP since my college days, so I can't really speak to that. I believe I heard there is a .NET LISP compiler out there, but I've never used it. Java is a fantastic learning language (although I think C# is better), and it's great for little cross-browser web applets, but anyone who has tried to build a full-blown production application package with it has realized that it is severely limited. Think Corel. Anyhow, for small applications and utilities, Java is a nice little language and runtime. I've never used autodesk, so I can't speak to that, but I have used C# to program some ArcView commands and tools. ;) Hope that helps. --Ron Logan http://wwmx.org - Geocoded image database ----- Original Message ----- From: Sebastian Matyas To: gpsxml+yahoogroups.com Sent: Tuesday, December 16, 2003 2:47 AM Subject: [gpsxml] programming language for XML? Hi, i wanted to know which programming language gives me the best support to handle XML? C# Microsoft.NET C/C++ AutoLISP/VLISP If somenone has experience with XML and autodesk map, which one of those should i use if i had to use XML in the context of Topologies? Or is there some way to include java to map? Thanks for your answers... Sebastian Matyas -- +++ GMX - die erste Adresse f�r Mail, Message, More +++ Neu: Preissenkung f�r MMS und FreeMMS! http://www.gmx.net To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com Yahoo! Groups Sponsor ADVERTISEMENT ------------------------------------------------------------------------------ Yahoo! Groups Links a.. To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ b.. To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ------?extPart_000_001F_01C3C3B4.B5471510
egroups+topografix.com on Wed Dec 17 07:00:02 2003 (link), replying to msg
Hello, Friday, December 12, 2003, 12:06:25 AM, labtek wrote: l> Thanks Dan. I think the extension part is clear now so my only l> question now is do I need to create an extension xsd for the file to l> be considered "valid"? Your GPX file won't validate unless you reference a schema (xsd) for each namespace you include in the file. So, yes, you'll have to create an XSD for your extension. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Tue Dec 30 15:38:37 2003 (link), replying to msg
Hello Charlie, Sunday, December 28, 2003, 9:48:18 AM, you wrote: C> I can't get the "Fells Loop" sample file at C> http://www.topografix.com/fells_loop.gpx C> to validate against the SAX2Count.exe program contained in the archive C> at C> http://xml.apache.org/dist/xerces-c/stable/xerces-c2_4_0-windows_nt- C> msvc_60.zip C> It spits out a few hundred errors, starting with this one: C> Error at file C:\...\feels_loop.gpx, line 1, char 65 C> Message: Unknown element 'gpx' C> So I'm pretty much stuck. I can't get my own GPX files to validate, but C> I can't debug the problem, since I can't get the sample file to C> validate either. Anyone have an idea where my problem is? C> Thanks, C> Charlie What are the command line parameters you are using? Try running saxcount -? to see the full list of parameters. I seem to recall that one of the flags (-s maybe) has changed meaning since I wrote the directions for validation. Let me know what you find. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
peterhansen01960+yahoo.com on Wed Dec 31 12:03:31 2003 (link), replying to msg
I wish I has read this before wasting an hour this morning! I figured out that eliminating the "tracks" section from the schema fixed the problem, but didn't spend the time to figure out why. XmlSerialize rules!
jeetsukumaran+pd.jaring.my on Wed Dec 31 17:36:04 2003 (link)
Hello all. On Dan Foster's suggestion, I am reposting the following here, in the hope of getting some answers: As you might infer from the previous e-mails, I have begun to grasp how to use xsl stylesheets to transform the gpx XML. The only problem I am facing now is - since I am dealing with a number of different users who e-mail my their gps data in gpx form, I have some gpx files using the 1.0 namespace, and others with the 1.1 namespace, and I cannot figure out how to feasibly maintain a single set of stylesheets to handle both. OK - one way would be for me to simply have two sets of stylesheets, with one set referencing gpx elements through the "http://www.topografix.com/GPX/1/1" namespace while the other set refers to the "http://www.topografix.com/GPX/1/0" namespace ... but this becomes a management headache, especially when it comes to making modifications in the stylesheets. And, it raises the spectre of having to constantly revise and expand the stylesheet set to take into account future versions of gpx namespaces, while maintaining a set of legacy stylesheets to deal with older gpx files that will be floating around. I Is there any reason that even as the gpx schema continues to evolve, the gpx namespace remains constant through various versions? i.e. so the default namespace for, say, a gpx waypoint element sitting in a gpx file will be the same regardless of whether somebody has used EasyGPS or ExpertGPS (or any other software) to save the file, or whether or not they used and earlier or later version of the software, or whether or not they might be dealing with GPX 1.0, 1.1., or any future schemas? That way, a stylesheet designed today will still be useful year from now, and (perhaps more importantly), stylesheets written for some specific purpose in the future can be used seamless on archived gpx files of today, without modifying either the stylesheet or the gpx files (assuming that the basic core elements of the gpx specificaiton, such as waypoints etc., do not change)? In other words, why not a fixed namespace like xmlns:"http://www.topografix.com/GPX"? I am sure there are very good reasons for the gpx community's design decisions, and I would like to understand them! I just find that accessing elements in different gpx files without knowing beforehand what has been specified as their default namespace (so far, I have dealt with "http://www.topografix.com/GPX/1/0", "http://www.topografix.com/G PX/1/1", and no namespace), makes managing gps archives a little more difficult than it could be if we instead fixed a constant namespace. Attached are two xsl stylesheets. One transforms a gpx file using the "http://www.topografix.com/GPX/1/1" namespace. As might be expected, it fails with those using the "http://www.topografix.com/GPX/1/0" namespace (such as EasyGPS files). The second xslt file ("gpx_any_to_basic_html.xslt") is an attempt at circumventing this issue by brute-force, i.e. liberal and convoluted used of "local-name". While it works with all the gpx file that I have, regardless of namespaces specified (or even if no namespace is given), but I ma not happy with it as it seems to undermine the structured data hierarchy that is fundamental to XML ... it just does not seem like an elegant solution. Am I missing something here? Is there any easy way to deal with multiple default namespaces? For example, is there a way to refer to elements in the default namespace of the xml document being transformed without explicitly defining and referring to that namespace?
AL_PIVONKA+YAHOO.COM on Tue Jan 06 08:48:42 2004 (link)
Working on a cvs -> GPX for National Geographic TOPO software .. This would consist of a xsl transform, yet I have limited background with xslt. Can anyone lend a hand ?
james_sherring+yahoo.com on Tue Jan 06 10:39:55 2004 (link)
Hi Al, Have you seen GPSBabel http://gpsbabel.sourceforge.net? GPSBabel supports transforms both ways for topo, GPX and csv waypoints (as well as many other formats). If it doesn't do something you want for your formats (like routes?), they are fairly responsive to requests or welcome contributions. Also, I think xsl will be useful for GPX -> csv but perhaps not for csv -> GPX. Regards, James -----Original Message----- From: Al [mailto:AL_PIVONKA+YAHOO.COM] Sent: Tuesday, 6 January 2004 5:48 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] National Geographic TOPO mac (CSV export 2 GPX) ? Working on a cvs -> GPX for National Geographic TOPO software .. This would consist of a xsl transform, yet I have limited background with xslt. Can anyone lend a hand ? ------------------------ Yahoo! Groups Sponsor Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ 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! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
AL_PIVONKA+YAHOO.COM on Tue Jan 06 11:00:28 2004 (link), replying to msg
Content-Description: route1.txt Content-Disposition: inline; filename="route1.txt" TOPO! GPS Data Format Deg NAD27 ElevFeet UTC-Time 01-S01,39.61462,-86..79726,786,01/02/2004,19:59:40, 01-W02,39.60080,-86..79722,761,01/02/2004,20:00:00, 01-S03,39.60060,-86..02838,778,01/02/2004,20:03:18, 01-W04,39.57900,-86..91722,767,01/02/2004,20:03:44, 01-S05,39.57895,-86..12321,755,01/02/2004,20:04:27, 01-W06,39.56443,-86..12371,769,01/02/2004,20:04:53, 01-S07,39.56443,-86..16988,761,01/02/2004,20:05:20, 01-E08,39.55725,-86..16988,781,01/02/2004,20:05:45, 01-S08,39.54987,-86..21738,771,01/02/2004,20:06:03, 01-E09,39.53133,-86..22804,725,01/02/2004,20:07:07, 01-E10,39.51755,-86..98105,871,01/02/2004,20:07:39, 01-S11,39.51800,-86..88689,884,01/02/2004,20:07:55, 01-W12,39.50187,-86..84272,879,01/02/2004,20:08:09, 01-N13,39.50187,-86..95322,828,01/02/2004,20:08:38, 01-S14,39.50583,-86..49554,863,01/03/2004,00:38:56, 01-E15,39.45748,-86..09455,646,01/03/2004,00:39:57, 01-W16,39.45963,-86..53903,728,01/03/2004,00:55:10, 01-S17,39.46942,-86..75353,839,01/03/2004,00:55:48, 01-W18,39.46272,-86..75469,869,01/03/2004,00:56:08, 01-S19,39.45895,-86..89669,843,01/03/2004,00:58:00, 01-W20,39.41858,-86..76869,625,01/03/2004,01:36:03, 01-S21,39.42802,-86..13318,767,01/03/2004,01:37:30, 01-W22,39.43052,-86..31718,784,01/03/2004,01:38:07, 01-W23,39.43363,-86..71067,808,01/03/2004,01:44:18, 01-W24,39.42718,-86..43848,787,01/03/2004,01:48:58, 01-W25,39.42342,-86..38415,826,01/03/2004,01:49:43, 01-W26,39.39845,-86..42581,771,01/03/2004,01:50:08, 01-N26,39.40212,-86..84463,880,01/03/2004,01:51:07, 01-W27,39.41540,-86..92846,850,01/03/2004,01:51:27, 01-S28,39.41193,-86..05513,847,01/03/2004,01:56:07, 01-W29,39.37812,-86..97763,833,01/03/2004,01:59:07, 01-N30,39.37855,-86..16296,623,01/03/2004,02:00:00, 01-W31,39.37875,-86..16612,627,01/03/2004,02:00:15, 01-S32,39.37620,-86..88760,699,01/03/2004,02:01:08, 01-S33,39.37827,-86..14426,780,01/03/2004,02:01:49, 01-W34,39.36433,-86..15376,636,01/03/2004,02:02:18, 01-S35,39.36385,-86..23509,625,01/03/2004,02:12:26, 01-W36,39.30935,-86..38075,733,01/03/2004,02:13:00, 01-W37,39.31165,-86..56991,722,01/03/2004,02:13:29, 01-S38,39.31160,-86..61141,691,01/03/2004,02:14:01, 01-E39,39.27083,-86..61591,608,01/03/2004,02:15:57, 01-S40,39.26883,-86..47742,637,01/03/2004,02:21:59, 01-S41,39.26168,-86..43092,642,01/03/2004,02:22:17, 01-W42,39.24385,-86..43042,702,01/03/2004,02:22:50, 01-S43,39.24400,-86..61575,642,01/03/2004,02:26:34, 01-W44,39.23876,-86..58675,652,01/03/2004,02:26:49, 01-S45,39.23871,-87..22123,564,01/03/2004,03:05:50, 01-E46,39.22635,-87..19923,533,01/03/2004,03:10:05, 01-S47,39.22620,-87..17423,531,01/03/2004,03:11:21, 01WEND,39.21535,-87..17473,554,01/03/2004,03:29:45, 02-W01,39.21535,-87..17856,553,01/03/2004,03:35:14, 02-S02,39.21545,-87..37773,632,01/03/2004,03:35:51, 02-S03,39.21550,-87..54489,620,01/03/2004,03:54:25, 02-W04,39.20123,-87..54422,587,01/03/2004,03:59:53, 02-S05,39.20133,-87..78105,538,01/03/2004,04:00:16, 02-W06,39.18671,-87..78355,515,01/03/2004,04:00:32, 02-W07,39.20500,-87..97138,524,01/03/2004,04:01:39, 02-S08,39.20495,-87..15921,547,01/03/2004,04:02:00, 02-S09,39.19693,-87..19754,525,01/03/2004,04:02:18, 02-W10,39.11100,-87..10071,534,01/03/2004,04:03:51, 02-S11,39.11096,-87..28987,522,01/03/2004,04:04:12, 02-W12,39.10386,-87..29137,532,01/04/2004,15:05:25, 02-S13,39.10358,-87..47503,597,01/04/2004,15:05:39, 02-W14,39.10040,-87..47687,598,01/04/2004,15:06:08, 02-W15,39.10148,-87..66320,636,01/04/2004,15:06:47, 02-N16,39.10300,-87..98853,633,01/04/2004,15:12:06, 02-W17,39.10358,-87..99052,633,01/04/2004,15:12:21, 02-N18,39.10920,-87..22252,564,01/04/2004,15:17:08, 02-W19,39.12728,-87..22369,581,01/04/2004,15:17:29, 02-N20,39.13133,-87..40935,558,01/04/2004,15:18:25, 02-W21,39.13540,-87..41118,545,01/04/2004,15:19:11, 02-S22,39.13545,-87..50218,531,01/04/2004,15:19:39, 02-E23,39.11717,-87..59485,532,01/04/2004,15:36:35, 02-S24,39.11340,-87..51085,559,01/04/2004,15:37:57, 02-S25,39.10812,-87..52151,553,01/04/2004,15:38:17, 02-26RB,39.07558,-87..21119,618,01/04/2004,15:40:25, 02-W27,39.08227,-87..22369,629,01/04/2004,15:58:03, 02-W28,39.09003,-87..38418,522,01/04/2004,15:59:14, 02-N29,39.08442,-87..11100,564,01/04/2004,16:01:22, 02-W30,39.09160,-87..11217,587,01/04/2004,16:03:29, 02-S31,39.09155,-87..40816,516,01/04/2004,16:04:01, 02-W32,39.07543,-87..41450,534,01/04/2004,16:05:04, 02-S33,39.07538,-87..43699,529,01/04/2004,16:05:27, 02-W34,39.01008,-87..29400,510,01/04/2004,16:08:02, 02-S35,39.01003,-87..35183,511,01/04/2004,16:09:32, 02-W36,38.99547,-87..34050,531,01/04/2004,16:09:46, 02-S37,38.99537,-87..36500,520,01/04/2004,16:10:01, 02-E38,38.96170,-87..36800,536,01/04/2004,17:11:25, 02-E39,38.96160,-87..17334,535,01/04/2004,17:12:10, 02-S40,38.96545,-87..98184,617,01/04/2004,17:12:25, 02-E41,38.94668,-87..98251,526,01/04/2004,17:12:44, 02-S42,38.94645,-87..93368,528,01/04/2004,17:13:26, 02-W43,38.89653,-87..94118,531,01/04/2004,17:14:18, 02-S44,38.89283,-87..98318,522,01/04/2004,17:14:55, 02-E45,38.88916,-87..98318,535,01/04/2004,17:16:21, 02-E46,38.88183,-87..97118,541,01/04/2004,18:22:45, 02-S47,38.88183,-87..87735,514,01/04/2004,18:24:31, 02-W48,38.81540,-87..87736,509,01/04/2004,18:26:32, 02-S49,38.82083,-87..97619,535,01/04/2004,19:41:47, 02-N50,38.81301,-87..15385,454,01/04/2004,19:42:05, 03-E01,38.82268,-87..15952,517,01/04/2004,19:43:37, 03-N02,38.82996,-87..40451,467,01/04/2004,19:44:18, 03-E03,38.83368,-87..37901,489,01/04/2004,19:44:58, 03-S05,38.83780,-87..60084,460,01/04/2004,19:45:21, 03-S06,38.82483,-87..81967,446,01/04/2004,19:48:49, 03-W07,38.81155,-87..83167,469,01/04/2004,19:51:08, 03-W08,38.80083,-87..02367,468,01/04/2004,19:51:33, 03-S09,38.80080,-87..09850,493,01/04/2004,19:51:49, 03-S10,38.79292,-87..39449,459,01/04/2004,20:28:36, 03-S11,38.79233,-87..39582,456,01/04/2004,20:29:07, 03-S12,38.70363,-87..96632,443,01/04/2004,20:29:48, 03-S13,38.69532,-87..97248,430,01/04/2004,20:30:18, 03-E14,38.69155,-87..04731,419,01/04/2004,20:31:04, 03-END,38.68995,-87..03615,417,01/04/2004,20:31:30, TOPO! GPS Route,R01SW 01-S01,39.61462,-86..79726,786,01/02/2004,19:59:40, 01-W02,39.60080,-86..79722,761,01/02/2004,20:00:00, 01-S03,39.60060,-86..02838,778,01/02/2004,20:03:18, 01-W04,39.57900,-86..91722,767,01/02/2004,20:03:44, 01-S05,39.57895,-86..12321,755,01/02/2004,20:04:27, 01-W06,39.56443,-86..12371,769,01/02/2004,20:04:53, 01-S07,39.56443,-86..16988,761,01/02/2004,20:05:20, 01-E08,39.55725,-86..16988,781,01/02/2004,20:05:45, 01-S08,39.54987,-86..21738,771,01/02/2004,20:06:03, 01-E09,39.53133,-86..22804,725,01/02/2004,20:07:07, 01-E10,39.51755,-86..98105,871,01/02/2004,20:07:39, 01-S11,39.51800,-86..88689,884,01/02/2004,20:07:55, 01-W12,39.50187,-86..84272,879,01/02/2004,20:08:09, 01-N13,39.50187,-86..95322,828,01/02/2004,20:08:38, 01-S14,39.50583,-86..49554,863,01/03/2004,00:38:56, 01-E15,39.45748,-86..09455,646,01/03/2004,00:39:57, 01-W16,39.45963,-86..53903,728,01/03/2004,00:55:10, 01-S17,39.46942,-86..75353,839,01/03/2004,00:55:48, 01-W18,39.46272,-86..75469,869,01/03/2004,00:56:08, 01-S19,39.45895,-86..89669,843,01/03/2004,00:58:00, 01-W20,39.41858,-86..76869,625,01/03/2004,01:36:03, 01-S21,39.42802,-86..13318,767,01/03/2004,01:37:30, 01-W22,39.43052,-86..31718,784,01/03/2004,01:38:07, 01-W23,39.43363,-86..71067,808,01/03/2004,01:44:18, 01-W24,39.42718,-86..43848,787,01/03/2004,01:48:58, 01-W25,39.42342,-86..38415,826,01/03/2004,01:49:43, 01-W26,39.39845,-86..42581,771,01/03/2004,01:50:08, 01-N26,39.40212,-86..84463,880,01/03/2004,01:51:07, 01-W27,39.41540,-86..92846,850,01/03/2004,01:51:27, 01-S28,39.41193,-86..05513,847,01/03/2004,01:56:07, 01-W29,39.37812,-86..97763,833,01/03/2004,01:59:07, 01-N30,39.37855,-86..16296,623,01/03/2004,02:00:00, 01-W31,39.37875,-86..16612,627,01/03/2004,02:00:15, 01-S32,39.37620,-86..88760,699,01/03/2004,02:01:08, 01-S33,39.37827,-86..14426,780,01/03/2004,02:01:49, 01-W34,39.36433,-86..15376,636,01/03/2004,02:02:18, 01-S35,39.36385,-86..23509,625,01/03/2004,02:12:26, 01-W36,39.30935,-86..38075,733,01/03/2004,02:13:00, 01-W37,39.31165,-86..56991,722,01/03/2004,02:13:29, 01-S38,39.31160,-86..61141,691,01/03/2004,02:14:01, 01-E39,39.27083,-86..61591,608,01/03/2004,02:15:57, 01-S40,39.26883,-86..47742,637,01/03/2004,02:21:59, 01-S41,39.26168,-86..43092,642,01/03/2004,02:22:17, 01-W42,39.24385,-86..43042,702,01/03/2004,02:22:50, 01-S43,39.24400,-86..61575,642,01/03/2004,02:26:34, 01-W44,39.23876,-86..58675,652,01/03/2004,02:26:49, 01-S45,39.23871,-87..22123,564,01/03/2004,03:05:50, 01-E46,39.22635,-87..19923,533,01/03/2004,03:10:05, 01-S47,39.22620,-87..17423,531,01/03/2004,03:11:21, 01WEND,39.21535,-87..17473,554,01/03/2004,03:29:45, TOPO! GPS Route,R02SW 02-W01,39.21535,-87..17856,553,01/03/2004,03:35:14, 02-S02,39.21545,-87..37773,632,01/03/2004,03:35:51, 02-S03,39.21550,-87..54489,620,01/03/2004,03:54:25, 02-W04,39.20123,-87..54422,587,01/03/2004,03:59:53, 02-S05,39.20133,-87..78105,538,01/03/2004,04:00:16, 02-W06,39.18671,-87..78355,515,01/03/2004,04:00:32, 02-W07,39.20500,-87..97138,524,01/03/2004,04:01:39, 02-S08,39.20495,-87..15921,547,01/03/2004,04:02:00, 02-S09,39.19693,-87..19754,525,01/03/2004,04:02:18, 02-W10,39.11100,-87..10071,534,01/03/2004,04:03:51, 02-S11,39.11096,-87..28987,522,01/03/2004,04:04:12, 02-W12,39.10386,-87..29137,532,01/04/2004,15:05:25, 02-S13,39.10358,-87..47503,597,01/04/2004,15:05:39, 02-W14,39.10040,-87..47687,598,01/04/2004,15:06:08, 02-W15,39.10148,-87..66320,636,01/04/2004,15:06:47, 02-N16,39.10300,-87..98853,633,01/04/2004,15:12:06, 02-W17,39.10358,-87..99052,633,01/04/2004,15:12:21, 02-N18,39.10920,-87..22252,564,01/04/2004,15:17:08, 02-W19,39.12728,-87..22369,581,01/04/2004,15:17:29, 02-N20,39.13133,-87..40935,558,01/04/2004,15:18:25, 02-W21,39.13540,-87..41118,545,01/04/2004,15:19:11, 02-S22,39.13545,-87..50218,531,01/04/2004,15:19:39, 02-E23,39.11717,-87..59485,532,01/04/2004,15:36:35, 02-S24,39.11340,-87..51085,559,01/04/2004,15:37:57, 02-S25,39.10812,-87..52151,553,01/04/2004,15:38:17, 02-26RB,39.07558,-87..21119,618,01/04/2004,15:40:25, 02-W27,39.08227,-87..22369,629,01/04/2004,15:58:03, 02-W28,39.09003,-87..38418,522,01/04/2004,15:59:14, 02-N29,39.08442,-87..11100,564,01/04/2004,16:01:22, 02-W30,39.09160,-87..11217,587,01/04/2004,16:03:29, 02-S31,39.09155,-87..40816,516,01/04/2004,16:04:01, 02-W32,39.07543,-87..41450,534,01/04/2004,16:05:04, 02-S33,39.07538,-87..43699,529,01/04/2004,16:05:27, 02-W34,39.01008,-87..29400,510,01/04/2004,16:08:02, 02-S35,39.01003,-87..35183,511,01/04/2004,16:09:32, 02-W36,38.99547,-87..34050,531,01/04/2004,16:09:46, 02-S37,38.99537,-87..36500,520,01/04/2004,16:10:01, 02-E38,38.96170,-87..36800,536,01/04/2004,17:11:25, 02-E39,38.96160,-87..17334,535,01/04/2004,17:12:10, 02-S40,38.96545,-87..98184,617,01/04/2004,17:12:25, 02-E41,38.94668,-87..98251,526,01/04/2004,17:12:44, 02-S42,38.94645,-87..93368,528,01/04/2004,17:13:26, 02-W43,38.89653,-87..94118,531,01/04/2004,17:14:18, 02-S44,38.89283,-87..98318,522,01/04/2004,17:14:55, 02-E45,38.88916,-87..98318,535,01/04/2004,17:16:21, 02-E46,38.88183,-87..97118,541,01/04/2004,18:22:45, 02-S47,38.88183,-87..87735,514,01/04/2004,18:24:31, 02-W48,38.81540,-87..87736,509,01/04/2004,18:26:32, 02-S49,38.82083,-87..97619,535,01/04/2004,19:41:47, 02-N50,38.81301,-87..15385,454,01/04/2004,19:42:05, TOPO! GPS Route,R03SW 03-E01,38.82268,-87..15952,517,01/04/2004,19:43:37, 03-N02,38.82996,-87..40451,467,01/04/2004,19:44:18, 03-E03,38.83368,-87..37901,489,01/04/2004,19:44:58, 03-S05,38.83780,-87..60084,460,01/04/2004,19:45:21, 03-S06,38.82483,-87..81967,446,01/04/2004,19:48:49, 03-W07,38.81155,-87..83167,469,01/04/2004,19:51:08, 03-W08,38.80083,-87..02367,468,01/04/2004,19:51:33, 03-S09,38.80080,-87..09850,493,01/04/2004,19:51:49, 03-S10,38.79292,-87..39449,459,01/04/2004,20:28:36, 03-S11,38.79233,-87..39582,456,01/04/2004,20:29:07, 03-S12,38.70363,-87..96632,443,01/04/2004,20:29:48, 03-S13,38.69532,-87..97248,430,01/04/2004,20:30:18, 03-E14,38.69155,-87..04731,419,01/04/2004,20:31:04, 03-END,38.68995,-87..03615,417,01/04/2004,20:31:30, --0-1383947387-1073415605=:22287--
robertlipe+usa.net on Tue Jan 06 11:26:02 2004 (link), replying to msg
al pivonka wrote: > I would really love to have TOPO produce a export in > GPX.. Two people have now pointed you to GPSBabel which reads and writes .tpg and GPX. Are you saying that it doesn't work for you or have you not tried it? (Follow-up to gpsbabel mailing list...) > TOPO! GPS Data Format Deg NAD27 ElevFeet UTC-Time > 01-S01,39.61462,-86..79726,786,01/02/2004,19:59:40, > 01-W02,39.60080,-86..79722,761,01/02/2004,20:00:00, > 01-S03,39.60060,-86..02838,778,01/02/2004,20:03:18, Does it really have two dots there? RJL
egroups+topografix.com on Tue Jan 06 12:08:12 2004 (link), replying to msg
Hello Robert, Tuesday, January 6, 2004, 2:25:58 PM, you wrote: R> al pivonka wrote: >> I would really love to have TOPO produce a export in >> GPX.. R> Two people have now pointed you to GPSBabel which reads and writes .tpg R> and GPX. Are you saying that it doesn't work for you or have you not R> tried it? The latest version of Topo! for Windows (I can't speak for Mac) removed support for the .tpg file format. The native .tpo format is binary, undocumented, and changes between versions of Topo. The new Topo has an import/export "feature" which lets you export waypoints in several very obscure text formats. The obvious solution would be for Topo! to support GPX import/export. Why don't we all take a moment and ask them nicely. I just did (again). <http://maps.nationalgeographic.com/ngmaps/contact.cfm?topocontact=yes> I've started to look into the .tpo format, but it's really ugly. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
AL_PIVONKA+YAHOO.COM on Wed Jan 07 13:01:39 2004 (link), replying to msg
Yes it does have two dots.. No I have not spent much time using GPSBable... I have a created a Java tool to parse the CSV file (specific format) and create a set of gpx file -- Yet, some tools like TerraBrowser are not able to read it... Thinking it must be a format error on my part... --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > al pivonka wrote: > > > I would really love to have TOPO produce a export in > > GPX.. > > Two people have now pointed you to GPSBabel which reads and writes .tpg > and GPX. Are you saying that it doesn't work for you or have you not > tried it? > > (Follow-up to gpsbabel mailing list...) > > > TOPO! GPS Data Format Deg NAD27 ElevFeet UTC-Time > > 01-S01,39.61462,-86..79726,786,01/02/2004,19:59:40, > > 01-W02,39.60080,-86..79722,761,01/02/2004,20:00:00, > > 01-S03,39.60060,-86..02838,778,01/02/2004,20:03:18, > > Does it really have two dots there? > > RJL
AL_PIVONKA+YAHOO.COM on Wed Jan 07 13:05:32 2004 (link), replying to msg
Dan just sent off my request for the support of an Export in GPX format... Thanks for the URL --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello Robert, > > Tuesday, January 6, 2004, 2:25:58 PM, you wrote: > > R> al pivonka wrote: > > >> I would really love to have TOPO produce a export in > >> GPX.. > > R> Two people have now pointed you to GPSBabel which reads and writes .tpg > R> and GPX. Are you saying that it doesn't work for you or have you not > R> tried it? > > The latest version of Topo! for Windows (I can't speak for Mac) > removed support for the .tpg file format. The native .tpo format is > binary, undocumented, and changes between versions of Topo. The new > Topo has an import/export "feature" which lets you export waypoints in > several very obscure text formats. > > The obvious solution would be for Topo! to support GPX import/export. > Why don't we all take a moment and ask them nicely. I just did > (again). > <http://maps.nationalgeographic.com/ngmaps/contact.cfm?topocontact=yes> > > I've started to look into the .tpo format, but it's really ugly. > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
robertlipe+usa.net on Wed Jan 07 13:51:35 2004 (link), replying to msg
Al wrote: > Yet, some tools like TerraBrowser are not able to read it... > Thinking it must be a format error on my part... The line in the sand on XML is "does it validate?". If the file you generate validates but doesn't work in TerraBrowser, it's their problem; if it doesn't, it's your problem. It's nice having a firm line like that. Feed the file you generate to a validator such as http://xml.apache.org/xerces-c/sax2count.html RJL
AL_PIVONKA+YAHOO.COM on Thu Jan 08 06:12:34 2004 (link), replying to msg
I have validated using the java version of xerces parser: java sax.Counter -dv routeAll.gpx routeAll.gpx: 507 ms (919 elems, 459 attrs, 0 spaces, 5040 chars) usage: java sax.Counter (options) uri ... options: -p name Select parser by name. -x number Select number of repetitions. -n | -N Turn on/off namespace processing. -np | -NP Turn on/off namespace prefixes. NOTE: Requires use of -n. -v | -V Turn on/off validation. -s | -S Turn on/off Schema validation support. NOTE: Not supported by all parsers. -f | -F Turn on/off Schema full checking. NOTE: Requires use of -s and not supported by all parsers. -dv | -DV Turn on/off dynamic validation. NOTE: Requires use of -v and not supported by all parsers. -m | -M Turn on/off memory usage report -t | -T Turn on/off "tagginess" report. --rem text Output user defined comment before next parse. -h This help screen. --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > Al wrote: > > > Yet, some tools like TerraBrowser are not able to read it... > > Thinking it must be a format error on my part... > > The line in the sand on XML is "does it validate?". If the file you > generate validates but doesn't work in TerraBrowser, it's their problem; > if it doesn't, it's your problem. It's nice having a firm line like > that. > > Feed the file you generate to a validator such as > http://xml.apache.org/xerces-c/sax2count.html > > RJL
AL_PIVONKA+YAHOO.COM on Thu Jan 08 09:46:04 2004 (link)
--- TOPO <topo+ngs.org> wrote: > From: "TOPO" <topo+ngs.org> > To: <al_pivonka+yahoo.com> > Subject: TOPO! Interactive Maps > Date: Thu, 8 Jan 2004 09:16:48 -0700 > > Thank you for your email and interest in TOPO!. I > will be happy to pass on > your request for us to support the GPX format. > Thanks again! > > Michael Wildschut > TOPO! Technical Support > National Geographic Maps > Evergreen, Colorado > ===== Al Pivonka (H)317.295.1737 Those who say it can't be done, are usually interrupted by those doing it. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
amandapaixaom+yahoo.com.br on Sun Jan 18 09:29:55 2004 (link)
Site about GPS http://www.geocities.com/zemaplata/index.html .
davewissenbach+yahoo.com on Sat Feb 14 08:07:02 2004 (link)
All, In message number 486, Dan Foster posted the proposal for the gpx_style schema and examples. I'm updating Wissenbach Map3D to support mapping and visualizing ski areas. To do this, I need color and line width support--beginner trails in green, advanced trails in blue, expert trails in black, dangerous trails in yellow, etc. In the posted examples demo.gpx, gpx_style is applied directly to a waypoint but not to a track--for track color the private topografix:color is applied. Should I add gpx_style:line properties directly to the track element (which I believe requires a schema change) or should I place this gpx_style:element within an <extensions> tag? I would prefer the placement of the gpx_style:line attributes directly within the track and not within an <extensions> element, although I have currently prototyped with the line attributes applied within the extensions wrapper. Also, what are the units of line width? I am assuming millimeters, because we are using metric units elsewhere in gpx. I also think that the ability to specify a dash pattern could also be useful. Thanks for any clarification--remember that any user of Wissenbach Map3D is a potential user of your programs as well! (Although I'm currently seeing only about 90 downloads a month). Regards, Dave Wissenbach
egroups+topografix.com on Tue Feb 17 11:55:32 2004 (link), replying to msg
Hello, Saturday, February 14, 2004, 11:06:58 AM, Dave wrote: D> In message number 486, Dan Foster posted the proposal for the D> gpx_style schema and examples. D> In the posted examples demo.gpx, gpx_style is applied directly to a D> waypoint but not to a track--for track color the private D> topografix:color is applied. This was an error on my part. I edited an existing GPX file from ExpertGPS to add in the new gpx_style elements. Because there was no way to express color previously, I was using my own topografix:color extension to <trk>. With gpx_style, this becomes obsolete. D> Should I add gpx_style:line properties directly to the track element D> (which I believe requires a schema change) or should I place this D> gpx_style:element within an <extensions> tag? Anything that isn't in namespace "gpx" should go in <extensions>. (gpx_style, gpx_overlay, topografix, wissenbach, groundspeak) D> Also, what are the units of line width? I am assuming millimeters, D> because we are using metric units elsewhere in gpx. Pixels? Meters would make sense if we were actually specifying the width of the trail on the ground. I've never seen a map that shows trail widths to scale - you wouldn't be able to see the tracks on most maps. I've been using the Windows pen width as line width. I doubt there's much of a difference on Mac OSX or Linux. Line width 1 is the smallest visible width. Line width 4 is 4x thicker than #1. D> I also think that the ability to specify a dash pattern could also D> be useful. I think an SVG-style dash pattern would be appropriate. D> Thanks for any clarification--remember that any user of Wissenbach D> Map3D is a potential user of your programs as well! (Although I'm D> currently seeing only about 90 downloads a month). Thanks for pointing out the ambiguities! This is a good time to nail them down, as I'm just starting to implement gpx_style and gpx_overlay in ExpertGPS now. There is at least one other vendor working on styles and map overlays, so we will have plenty of opportunity for interoperability testing. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Tue Feb 17 21:56:58 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > ... > > D> Should I add gpx_style:line properties directly to the track element > D> (which I believe requires a schema change) or should I place this > D> gpx_style:element within an <extensions> tag? > > Anything that isn't in namespace "gpx" should go in <extensions>. > (gpx_style, gpx_overlay, topografix, wissenbach, groundspeak) > OK. I'll keep style within extensions. > D> Also, what are the units of line width? I am assuming millimeters, > D> because we are using metric units elsewhere in gpx. > > Pixels? > > Meters would make sense if we were actually specifying the width > of the trail on the ground. I've never seen a map that shows trail > widths to scale - you wouldn't be able to see the tracks on most maps. > > I've been using the Windows pen width as line width. I doubt there's > much of a difference on Mac OSX or Linux. > Line width 1 is the smallest visible width. > Line width 4 is 4x thicker than #1. > I agree that we don't want to scale line width with the overall scale of the map. What I've done is scale line width to the screen resolution, even on the 3D view. Windows uses 72 or 96 dpi, Macintosh 92, I believe. On Linux the screen resolution is user-settable. The native resolution of most moniters at 0.25 mm dot pitch is more like 100 dpi. And when printing from my HP 7350 the resolution is 300, 600 or 1200 dpi depending on printer driver setting. That's why I proposed mm. But if we chose "points", where a point was about a 72 of an inch that could work too. Then just multiply line widths by 8 or so when printing. For better precision, the screen or printer resolution can be found as follows: int pixelsPerInch = pDC->GetDeviceCaps(LOGPIXELSX); > D> I also think that the ability to specify a dash pattern could also > D> be useful. > > I think an SVG-style dash pattern would be appropriate. > How about this? <trk> ... <extensions> <gpx_style:line> <gpx_style:color>0000ff</gpx_style:color> <gpx_style:width>3.00000</gpx_style:width> <gpx_style:dasharray>6.0 3.0</gpx_style:dasharray> </gpx_style:line> </extensions> </trk> Thanks for the reply. Let me know what you decide on units--we don't need an endless debate--good enough is good enough. I'll switch to using dots interpreted as points, where 1 dot is assumed to equal 72 dpi for now. Then lines will look OK regardless of whether the widths are scaled to precise screen resolution or not. Dave > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
Bernd.Sobotka+Fahrradspass.de on Thu Feb 19 13:21:39 2004 (link)
Hi to all, for my bycicle tours I use a Garmin GPS device and a little Java application wich I have developed. When I read about GPX, I decided to implement it in my application. GPX works fine. After experimenting with version 1.0 for a while, I would like to post a couple of suggestions for improvement: - Garmin GPS devices support so called "route links". Some devices store a route as an alternating sequence of waypoints and route links. But unfortunately it is not possible to add anything else to a route but route waypoints. Therefore I would like to suggest to add a further '<xsd:any namespace="##other" .../>' element to the rte element. - My email address "bernd.sobotka+t-online.de" was not validated correctly. I think the regular expression used for the "emailType" does not allow hyphens (?!). - I created an additional schema for Garmin GPS devices. This schema defines the valid Garmin color and symbol names. I also tried to create a new element to be able to store "proximity waypoints". But this proved to be difficult, since the wpt element is defined locally in the gpx schema. So it cannot be reused. Therefore I would like to propose to define at least the wpt element globally. - Finally I am still wondering why track points possess the complete range of waypoint attributes (name, comment, description, url, source, ...). Especially the value of the src element must always be the same for all track points(?). In my opinion a track point is a tiny little spot in a long sequence of spots. Does anybody have an idea under which circumstances the track-point fields can reasonably be used? Best regards, Bernd Sobotka PS: My program uses the Xerces parser and can be used to validate GPX files. It can be started using Java WebStart: http://www.fahrradspass.de/gMaster/gMaster.jnlp. [Non-text portions of this message have been removed]
egroups+topografix.com on Thu Feb 19 14:05:46 2004 (link), replying to msg
Hello, Thursday, February 19, 2004, 4:21:38 PM, Bernd wrote: B> Hi to all, B> for my bycicle tours I use a Garmin GPS device and a little Java application B> wich I have developed. When I read about GPX, I decided to implement it in B> my application. GPX works fine. After experimenting with version 1.0 for a B> while, I would like to post a couple of suggestions for improvement: B> - I created an additional schema for Garmin GPS devices. This schema defines B> the valid Garmin color and symbol names. Can you post a link to the Garmin schema you created? B> I also tried to create a new B> element to be able to store "proximity waypoints". But this proved to be B> difficult, since the wpt element is defined locally in the gpx schema. So it B> cannot be reused. Therefore I would like to propose to define at least the B> wpt element globally. Take a look at the proposed GPX 1.1 schema: http://www.topografix.com/gpx/1/1/gpx.xsd <wpt> is defined globally in GPX 1.1 B> - Garmin GPS devices support so called "route links". Some devices store a B> route as an alternating sequence of waypoints and route links. But B> unfortunately it is not possible to add anything else to a route but route B> waypoints. Therefore I would like to suggest to add a further '<xsd:any B> namespace="##other" .../>' element to the rte element. Can you provide an example of how you would modify the <rte> element to accomplish this? The schema for supporting alternating rtept and link elements would be a bit more complicated than the line above, right? Can <link> be included in <rtept> instead? B> - My email address "bernd.sobotka+t-online.de" was not validated correctly. B> I think the regular expression used for the "emailType" does not allow B> hyphens (?!). We should fix this in GPX 1.1 B> - Finally I am still wondering why track points possess the complete range B> of waypoint attributes (name, comment, description, url, source, ...). B> Especially the value of the src element must always be the same for all B> track points(?). In my opinion a track point is a tiny little spot in a long B> sequence of spots. Does anybody have an idea under which circumstances the B> track-point fields can reasonably be used? I believe I was the one that suggested adding these elements to <trkpt> in the first place (because my program used to treat routes and tracks identically). I agree that it doesn't make sense to have them there. I think they should be removed from GPX 1.1. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
robertlipe+usa.net on Thu Feb 19 14:43:53 2004 (link), replying to msg
> B> - Finally I am still wondering why track points possess the complete range > B> of waypoint attributes (name, comment, description, url, source, ...). > > I believe I was the one that suggested adding these elements to > <trkpt> in the first place (because my program used to treat routes > and tracks identically). I agree that it doesn't make sense to > have them there. I think they should be removed from GPX 1.1. I can't remember where, but in my travels of GPSBabel, I've seen GPX files that had URL, comment, and description in trackpoints. It was something like a trip log where the person had annotated "and this was the B&B I slept in during my bike ride and their URL is X". That seemed like a perfectly reasonable thing to do. GPSBabel was designed to allow this but bozoed something in the details and I remember having to fix it. I don't see anything in the change logs that tickle more neurons than this... RJL
egroups+topografix.com on Thu Feb 19 15:07:29 2004 (link), replying to msg
Hello, Thursday, February 19, 2004, 5:15:13 PM, Robert wrote: >> B> - Finally I am still wondering why track points possess the complete range >> B> of waypoint attributes (name, comment, description, url, source, ...). >> R> I can't remember where, but in my travels of GPSBabel, I've seen GPX R> files that had URL, comment, and description in trackpoints. It was R> something like a trip log where the person had annotated "and this was R> the B&B I slept in during my bike ride and their URL is X". That seemed R> like a perfectly reasonable thing to do. There are programs that will take a GPX tracklog with timestamps and a set of digital photos with timestamps, and match the timestamps to determine where the photos were taken. The photos can then be viewed on a map. The question is whether the photos should be logically considered part of the trackpoint, or if they are independent of the trackpoint (and tracklog). I tend to think that they should be independent objects (waypoints, or annotations of some sort). There are things that you might want to attach to a specific track, however. I've spent some time trying to figure out the best way to annotate a tracklog to include a message like "milepost 3.6 - watch out, the trail gets really steep here". Some issues: 1. What if there's no trackpoint exactly at milepost 3.6? 2. What if the user simplifies the track, or deletes that trackpoint? I came to the conclusion that trackpoints should only include lat/lon, elevation, time, and GPS info like HDOP and EPE. Annotations should live somewhere else (presumably in <extensions> with their own namespace) -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Mon Feb 23 13:48:53 2004 (link)
Hello, Has any other Windows developer out there implemented copy and paste in their applications? I've been using GPX for copy and paste and for drag and drop in EasyGPS for a while now. It would be great to be able to copy a waypoint in EasyGPS and paste it directly into another GPX-enabled program. -- Dan Foster - egroups+topografix.com TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com
davewissenbach+yahoo.com on Wed Feb 25 11:43:12 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Has any other Windows developer out there implemented copy and paste > in their applications? I've been using GPX for copy and paste and for > drag and drop in EasyGPS for a while now. It would be great to be > able to copy a waypoint in EasyGPS and paste it directly into another > GPX-enabled program. > Dan, I remember in a previous thread you made this excellent suggestion, but I haven't acted on this. So I think that the Topografix programs are the only ones that do this. But I think that we might make it a best practice for GPX-enabled programs to place GPX documents on the clip-board. Do you put just the waypoint on the clipboard, or an entire GPX document? Dave > -- > Dan Foster - egroups+t... > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com
egroups+topografix.com on Wed Feb 25 12:12:18 2004 (link), replying to msg
Hello, Wednesday, February 25, 2004, 2:42:10 PM, Dave wrote: D> I think that we might make it a best practice for GPX-enabled D> programs to place GPX documents on the clip-board. Do you put just D> the waypoint on the clipboard, or an entire GPX document? It depends on what objects are selected in ExpertGPS (or EasyGPS). If you select three waypoints from the list in EasyGPS and click Copy, EasyGPS creates a GPX stream containing only those three waypoints. If you select a bunch of waypoints, routes, and tracks from a map view in ExpertGPS and click Copy, you'll get a GPX stream with the selected objects. Pasting works in a similar way. If you paste a bunch of waypoints into the map view, those waypoints are added to the map. If you paste the same waypoints into a view showing the legs of a route, those waypoints are added to the route. An easier implementation would just be to parse any GPX that is pasted into the document, and add those elements to the existing document. The important part is that anything that ends up on the clipboard must always be a full, validating GPX file. I'm placing data on the clipboard as CF_TEXT (or CF_UNICODETEXT for unicode builds), which allows the user to drop or paste objects from EasyGPS directly into Web pages (if you wanted to upload GPX to a server, for example). -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
jeffpearce1+yahoo.com on Wed Mar 10 07:38:12 2004 (link)
Hi, I'm an Internet Researcher doing a search on GPX Consumer Electronics. Does anyone here know the name of their product development managers (Product Managers). I am on a quest to find out people in their Marketing department. I have the name of the EVP of Marketing but I am also looking for Product Managers, Assistant Product Managers- basically you're lower level Marketing people. If anyone can help me out I will greatly appreciate it! Thank you, Jeff Pearce
ritesh1920+yahoo.com on Fri Mar 26 05:56:23 2004 (link)
hi, i want some hlp on how to interface a gramin (12xl) gps unit.. i want to know where can i get some sample programs or source codes for the same.. also i would like to know how to convert the lat. , long. information given by the gps unit into a tabular form .. thankx. ritesh
davewissenbach+yahoo.com on Fri Mar 26 07:49:45 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "ritesh" <ritesh1920+y...> wrote: > hi, > > i want some hlp on how to interface a gramin (12xl) gps unit.. i > want to know where can i get some sample programs or source codes for > the same.. also i would like to know how to convert the lat. , long. > information given by the gps unit into a tabular form .. > > thankx. > > ritesh Ritesh, Wissenbach Map3D doesn't support the garmin 12xl but this is a matter of a slight differences to the garmin protocol, which you can find documented on Garmin's web site. I've published a complete Software Development Kit for that program at http://myweb.cableone.net/cdwissenbach/map.html As for getting latitude and longitude in tabular format -- why? But if you must, I'd suggest writing an xml stylesheet tranformation to extract data from a gpx file. Dave
ronklogan+hotmail.com on Fri Mar 26 10:11:39 2004 (link), replying to msg
Hi, Ritesh. I haven't tested it with a Garmin 12x1, but you can try the download utility I wrote and have posted on http://wwmx.org/download.aspx. I tried to write it such that it would work with any Garmin device that supports track downloads, but I don't have a drawer full of all the different models, so that's just a theory. If you do decide to give "WWMX TrackDownload" a try (yeah, I know - real original name) and it doesn't work, let me know and I'll try to work out the problems with you. Always helps to have a guinea - er - tester to try things out. ;) It will output a GPX file, but it wouldn't be hard to get the information from that format into a tabular one. Just a simple walk of the XML object model. -Ron _____ From: ritesh [mailto:ritesh1920+yahoo.com] Sent: Friday, March 26, 2004 5:56 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] (unknown) hi, i want some hlp on how to interface a gramin (12xl) gps unit.. i want to know where can i get some sample programs or source codes for the same.. also i would like to know how to convert the lat. , long. information given by the gps unit into a tabular form .. thankx. ritesh Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/SIG=12cprdu38/M=268585.4521611.5694062.1261774/D=egroup web/S=1706030390:HM/EXP=1080395785/A=1950448/R=0/SIG=124kqsk9u/*http:/ashnin com/clk/muryutaitakenattogyo?YH=4521611&yhad=1950448> click here <http://us.adserver.yahoo.com/l?M=268585.4521611.5694062.1261774/D=egroupweb /S=:HM/A=1950448/rand=426363070> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]
Bernd.Sobotka+Fahrradspass.de on Fri Mar 26 12:08:12 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "ritesh" <ritesh1920+y...> wrote: > hi, > > i want some hlp on how to interface a gramin (12xl) gps unit.. i > want to know where can i get some sample programs or source codes for > the same.. also i would like to know how to convert the lat. , long. > information given by the gps unit into a tabular form .. > > thankx. > > ritesh
Bernd.Sobotka+Fahrradspass.de on Fri Mar 26 12:17:07 2004 (link), replying to msg
Hi Ritesh, I have written a program called "gMaster" which should be able to download the GPS data from any Garmin GPS device. (See http://www.fahrradspass.de/gMaster/Download.html) It can export the track data to a CSV files which can then be imported into Excel, for example. Is this what you are looking for? I am not sure if it works with a 12xl since it is only tested with a GPS12 and a Geko 201. Therefore I would be very interested in any error reports. Best regards, Bernd Sobotka PS: Sorry for my last incomplete posting. --- In gpsxml+yahoogroups.com, "ritesh" <ritesh1920+y...> wrote: > hi, > > i want some hlp on how to interface a gramin (12xl) gps unit.. i > want to know where can i get some sample programs or source codes for > the same.. also i would like to know how to convert the lat. , long. > information given by the gps unit into a tabular form .. > > thankx. > > ritesh
robertlipe+usa.net on Fri Mar 26 12:56:09 2004 (link), replying to msg
> > i want some hlp on how to interface a gramin (12xl) gps unit.. i > > want to know where can i get some sample programs or source codes I've had reports from the field that GPSBabel works fine with a 12xl. It runs on all interesting OSes, GPL'ed source is provided, and it handles GPX (and nearly 50 other formats) just fine. RJL
smart_ad0662+yahoo.co.in on Tue Apr 06 05:10:06 2004 (link)
Hello every body. Good news.... Real Work That Pays Now there are many companies providing better jobs to people who are ready to work for them. But the thing required for them is people who are ready to do hard work and earn good amount of money. No qualification is required. U must be knowing Ms-Word and typing. I can say I am proud member of that company and earned very handsome money. Do u wish to join? Do u want to know the details? Then rush your mails to Smart0662+rediffmail.com Smart0662+rediffmail.com Smart0662+rediffmail.com CURRICULUM VITAE AS QUALIFICATION IS NOT SO IMPORTANT BUT TALENT IS VERY IMP. REMEMBER Smart0662+rediffmail.com Smart0662+rediffmail.com Smart0662+rediffmail.com
smart_ad0662+yahoo.co.in on Tue Apr 06 08:18:30 2004 (link)
Hello friends An offer for you...if you are computer Internet... Don't miss this genuine earning opportunity. This company is offering home-based jobs to earn regular income right from your homes. You can work Part time/Full time via Internet from your place or from cyber cafe Working for 2-3 hours daily, you can easily earn Rs. 10,000 - 25,000 per Month. Write to us for more FREE Details Today Mail to: smart0662+rediffmail.com Please mention Subject as ANY ONE of the Send Details or Wanted Details And also Must Inside Subject as JUST You Write only " I need full Information " Please Note: - Send your Inquiry mail only a smart0662+rediffmail.com Don't attach / Send your Resume / C.V (We have only limited Positions! So First come first serve basis) Get FREE Details mail to: smart0662+rediffmail.com
smart_ad0662+yahoo.co.in on Wed Apr 07 04:02:00 2004 (link)
Earn Rs20, 000 Plus/Month By Working Part Time On The Internet!! For more details kindly visit: http://in.geocities.com/smart0662/smartjobsindia.html HOME BASED ONLINE JOB...Earn Rs20, 000 Plus/Month By Working Part Time On The Internet If you would like to work Part time Or Full time from home around your own schedule through Internet. This is not Get Rich Quick or any other Work from Home Scam. The requirement for this job is only a Personal Computer with Internet, an email account & 30- 45 hours per month. The basic skill of computer & Internet usage are required. You will be provided basic training through email and there is NEVER ANY PURCHASE TO YOU WHAT SO EVER in this job for you. There is No Selling or Marketing...The estimated monthly potential earnings will be Rs. 10000 - Rs. 25000 per Month. I am receiving over Rs20000/Month into my bank account since more than an year just by working part time on the internet...then why cant U? For more info email us TODAY mailto:smart0662+rediffmail.com? Subject=INTERESTED_IN_HOME-BASED_ INTERNET_JOB. Be sure to include: 1. First name 2. Last name 3. Email address (if different from above) 4. City/State We'll then send you full info & the Joining Form as soon as possible, and you can make up your own mind. Do not miss this EXCELLENT OFFER...JOIN US TODAY! Plz do forward this mail to your friends and relatives who might be interested in this offer. For more details kindly visit http://in.geocities.com/smart0662/smartjobsindia.html
feedback+gpxchange.com on Mon Apr 12 22:04:57 2004 (link)
My company, offroute.com, is working with several publishers to make more GPX content available. Whether the content is made available for sale or freely, each publisher and author wants to assert their copyrights. I suggest we make this addition to the schema as the element <copyright>.
davewissenbach+yahoo.com on Tue Apr 13 19:29:05 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > My company, offroute.com, is working with several publishers to make > more GPX content available. Whether the content is made available > for sale or freely, each publisher and author wants to assert their > copyrights. I suggest we make this addition to the schema as the > element <copyright>. If you look through the history of this forum you'll find negative comments on a copyright proposal I made early on. The question I have is what are my responsibilities as the author of a GPS mapping program capable of opening such a copyrighted file. Does my responsibility extend to the need to pop up a copyright notice when the file is opened? When I print a map based on the data, do I need to place the copyright notice on the printed map? One way to avoid these questions might be to not extend the gpx format itself but instead place the entire gpx document in a container in encrypted format. Without the key, a license to use the document, then the container can't be opened. Regards, Dave Wissenbach
egroups+topografix.com on Wed Apr 14 06:47:58 2004 (link), replying to msg
Hello, Tuesday, April 13, 2004, 10:27:55 PM, David wrote: D> If you look through the history of this forum you'll find negative D> comments on a copyright proposal I made early on. Here's the past discussion: (Nov 21, 2001) Dave W: 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! Kjeld J: Perhaps we should include the optional element <license> in the <wpt> and <trk> (before the first <trkpt>) in order to be able to add copyright information. Then if your parser sees this element, you know it is copyrighted, and you cannot use/distribute the data unless you get an exact match on the element data with some copyright strings you are allowed to distribute. <license>Copyright by Kjeld Jensen, free distribution allowed</license> No <license> equals copyfree. Dan F: 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). Kjeld J: I agree with you, I won't use it either, but it should be there for those who want it. For instance Internet database owners may be able to prompt the waypoint uploader something like "are you certain that the data labeled [copyright info from the <license> element] may be published at this open source database" [quoting Dan F:] >Maybe I'll end up with an "About this file" command that shows >everything in the GPX header (created by, license, etc). Sounds like a fair solution to me. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Wed Apr 14 07:49:22 2004 (link), replying to msg
Hello, Tuesday, April 13, 2004, 10:27:55 PM, Dave W wrote: D> If you look through the history of this forum you'll find negative D> comments on a copyright proposal I made early on. The question I D> have is what are my responsibilities as the author of a GPS mapping D> program capable of opening such a copyrighted file. We should make the distinction between allowing an author to place a copyright notice on his work, and implementing a digital rights management system. Implementing DRM is probably best left to Microsoft and the music industry. I believe what Offroute is looking for, and what we discussed back in November 2001, is a way to add a simple copyright or license statement to a GPX file. All works created in the US automatically have copyright protection, but adding a simple "Copyright 2004 Dan Foster" at the bottom of a document gives you stronger legal rights should you ever end up in court. It is easy to add a copyright string to a text document or the content of an HTML page, but I haven't come across any standard way of expressing copyright in XML. I checked SVG, XML, and GPSml this morning, and didn't see any rights tags. I used Adobe Illustrator to create a small SVG document, and added a Copyright string in the File Info dialog in Illustrator. The SVG contained several namespaces with copyright information available. Here's how rights are expressed in RDF/Dublin Core: http://dublincore.org/documents/dces/#rights xmlns:dc:="http://purl.org/dc/elements/1.1/" <dc:rights>Copyright (C) 2004 Dan Foster</dc:rights> Element Name: Rights Label: Rights Management Definition: Information about rights held in and over the resource. Comment: Typically, Rights will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions may be made about any rights held in or over the resource. D> Does my D> responsibility extend to the need to pop up a copyright notice when D> the file is opened? When I print a map based on the data, do I need D> to place the copyright notice on the printed map? [I am not a lawyer.] GPX programs can ignore any elements they want to. By definition, all existing GPX programs don't know about a future copyright tag, so they would ignore it or strip it out when saving a file which contained it. If you do chose to take notice of a copyright tag, it would be up to you to determine what actions to take. Several GPX programs have a File Info or About this File dialog which displays the file author, keywords, and other info. Listing the copyright statement there would be a reasonable solution. (That's what I intend to do with EasyGPS and ExpertGPS if we add this). D> D> One way to avoid these questions might be to not extend the gpx D> format itself but instead place the entire gpx document in a D> container in encrypted format. Without the key, a license to use the D> document, then the container can't be opened. I agree that if someone is looking for absolute protection for their GPS data, it would need to be done outside GPX, and probably wouldn't get much interest from this group. (Except some of us would probably decrypt it in an hour or two... :^) -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
ed+topozone.com on Wed Apr 14 09:54:33 2004 (link)
Folks - Perhaps I can chime in a bit as one of those producers of copyrighted derivative works from public-domain government publications <g>. Oversimplifying a bit, none of us may freely reproduce and distribute copyrighted works/documents. Distinct from the copyright itself, copyright holders will typically license their copyrighted works under certain terms. Those terms can be whatever the copyright holder wants - e.g. "every time you copy this document you must shout my name out the window" - but they typically, at a minimum, require the inclusion of a copyright message indicating that the material is under copyright and identifying the holder. As a possibly familiar example, the GNU "copyleft" concept is actually a particular set of license terms for copyrighted works. The GNU General Public License is the license used to grant permission to use copyrighted works under certain (fairly liberal) terms and conditions. "Copyleft" works are not public domain and they are still copyrighted and distributed under license. It is not clear to me from the original message what is meant by "assert their copyrights". It means either that (a) the publishers want a copyright message included or (b) the publishers want to control/regulate copying and distribution, or (c) both. Typically, most folks want both. If you receive a copyrighted document (like a GPX document) you have no idea what you're allowed to do with it (beyond personal use) unless you have a copy of the license agreement, too. Dan's note put it pretty well - distinguishing between a copyright and license management. In the absence of a license agreement, it is impossible to answer questions like "do I need to display the notice?" or "do I need to place the notice on the map?" Simply stashing a copyright message in an XML document might be nice, but once the camel's got his nose under the tent I suspect we'll see requests for including the license agreements, too... - Ed Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 ed+topozone.com (978) 251-4242 -----Original Message----- From: David S. Wissenbach [mailto:davewissenbach+yahoo.com] Sent: Tuesday, April 13, 2004 10:28 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: schema addition --- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > My company, offroute.com, is working with several publishers to make > more GPX content available. Whether the content is made available for > sale or freely, each publisher and author wants to assert their > copyrights. I suggest we make this addition to the schema as the > element <copyright>. If you look through the history of this forum you'll find negative comments on a copyright proposal I made early on. The question I have is what are my responsibilities as the author of a GPS mapping program capable of opening such a copyrighted file. Does my responsibility extend to the need to pop up a copyright notice when the file is opened? When I print a map based on the data, do I need to place the copyright notice on the printed map? One way to avoid these questions might be to not extend the gpx format itself but instead place the entire gpx document in a container in encrypted format. Without the key, a license to use the document, then the container can't be opened. Regards, Dave Wissenbach Yahoo! Groups Links
egroups+topografix.com on Wed Apr 14 11:57:41 2004 (link), replying to msg
Hello, Wednesday, April 14, 2004, 12:52:18 PM, Ed wrote: E> Dan's note put it pretty well - distinguishing between a copyright and E> license management. In the absence of a license agreement, it is E> impossible to answer questions like "do I need to display the notice?" E> or "do I need to place the notice on the map?" Simply stashing a E> copyright message in an XML document might be nice, but once the camel's E> got his nose under the tent I suspect we'll see requests for including E> the license agreements, too... We might as well kill two birds with one stone, then... I spent several hours today reading through various schemes (and schemas) for specifying copyright and license restrictions in digital files. Here's a summary of what I learned. The Dublin Core specification has 15 elements which can be used to list authors, publishers, and rights. It closely mirrors the existing metadata elements we have in GPX (name, author, keywords). It includes a "rights" element, but doesn't define a license element. Creative Commons (http://creativecommons.org) has proposed their own cc:license tag to specify a link to a license for a file. Unfortunately, both Dublin Core and Creative Commons are mostly used for RDF, and Creative Commons doesn't supply an XML schema (xsd file) for their cc namespace. This means we wouldn't be able to properly validate GPX files if we used cc:license. In the end, I created a new <copyright> element with the following parts: required attribute: author - the entity holding the copyright optional element: year - the year of the copyright optional element: license - a link to a license Here's an example: http://www.topografix.com/gpx/samples/topografix/dc.gpx ... <copyright author="Dan Foster"> <year>2004</year> <license>http://creativecommons.org/licenses/by/1.0/</license> </copyright> ... In this case, the license specifies that anyone can reuse or redistribute my GPS data as long as they give me credit. A <copyright> aware program could parse the data above and display "Copyright 2004 Dan Foster" in a File Info dialog, with a button "License Information" which either downloads and displays the license file from the Web, or launches a Web browser to view that URL. The sample file fully validates against the proposed GPX 1.1 schema: http://www.topografix.com/GPX/1/1/gpx.xsd Changes made to the GPX 1.1 schema: - moved all metadata into <metadata> tag to organize it - added <copyright> element I believe this addresses all of the copyright and license concerns mentioned by everyone so far. 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 Wed Apr 14 12:28:51 2004 (link), replying to msg
Dan Foster wrote: > I spent several hours today reading through various schemes (and > schemas) for specifying copyright and license restrictions in digital Lucky you. > I believe this addresses all of the copyright and license concerns > mentioned by everyone so far. What do you all think? When filtering, converting, merging, and generally honking on GPX files, the "metadata" section already caused my head to hurt even before there were legal ramifications involved. I can't say it's at all obvious to me what to do when merging GPX files with different copyrights, licenses, and authors, for example. Those of you that are GPX "endpoints" have control on this sort of thing, but GPSBabel is more of a transit; I don't want to be in the business of figuring out fair/legal use and trying to merge licenses and such. GPSBabel's current approach of vaporizing the metadata section and decomposing it back to a GPX 1.0 isn't totally to my distaste. :-) RJL
egroups+topografix.com on Wed Apr 14 13:00:53 2004 (link), replying to msg
Hello, Wednesday, April 14, 2004, 3:28:32 PM, Robert wrote: R> I can't say it's at all obvious to me what to do when merging GPX files R> with different copyrights, licenses, and authors, for example. Those R> of you that are GPX "endpoints" have control on this sort of thing, but R> GPSBabel is more of a transit; I don't want to be in the business of R> figuring out fair/legal use and trying to merge licenses and such. Does Microsoft's Notepad throw an error message if you try to delete a copyright notice from a text file? It's up to the end user to uphold her end of any licensing agreement to which she has agreed. You aren't responsible for parsing legalese for her or keeping her in compliance. (I'm STILL not a lawyer.) R> GPSBabel's current approach of vaporizing the metadata section and R> decomposing it back to a GPX 1.0 isn't totally to my distaste. :-) Copying directly from Dublin Core's Rights element: "If the Rights element is absent, no assumptions may be made about any rights held in or over the resource." Your solution sounds exactly right in this situation. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
andy.chaffee+cox.net on Wed Apr 14 13:10:07 2004 (link)
I am looking for some development help in creating a new twist on an older application. I am new to the GPS world and need the correct people involved to ensure success. Please email directly if this is of interest. Andy
ed+topozone.com on Wed Apr 14 15:43:29 2004 (link)
I think we can separate the specification and the manipulation of the data. Dan's spec sounds just fine; it's up to the application (as in the Notepad example) to decide what to do - and up to the end user to decide whether or not they like software that does that. I would be a bit cautious about a general policy of discarding copyright information. Your application doesn't need to "figure out fair/legal use", but it should retain any copyright/license attributions that came in from source documents. You can certainly see that merge/delete cycles can make it hard to track what copyright/license should be retained, but a simple policy of "keep them all" isn't bad. I presume that the goal is to motivate people with licensed data to publish it in the GPX format, so it's important to make sure their concerns are actually being addressed to a reasonable and implementable degree. - Ed Ed McNierney President and Chief Mapmaker TopoZone.com -----Original Message----- From: Dan Foster [mailto:egroups+topografix.com] Sent: Wednesday, April 14, 2004 3:59 PM To: gpsxml+yahoogroups.com Subject: Re[2]: [gpsxml] Re: schema addition Hello, Wednesday, April 14, 2004, 3:28:32 PM, Robert wrote: R> I can't say it's at all obvious to me what to do when merging GPX R> files with different copyrights, licenses, and authors, for example. R> Those of you that are GPX "endpoints" have control on this sort of R> thing, but GPSBabel is more of a transit; I don't want to be in the R> business of figuring out fair/legal use and trying to merge licenses and such. Does Microsoft's Notepad throw an error message if you try to delete a copyright notice from a text file? It's up to the end user to uphold her end of any licensing agreement to which she has agreed. You aren't responsible for parsing legalese for her or keeping her in compliance. (I'm STILL not a lawyer.) R> GPSBabel's current approach of vaporizing the metadata section and R> decomposing it back to a GPX 1.0 isn't totally to my distaste. :-) Copying directly from Dublin Core's Rights element: "If the Rights element is absent, no assumptions may be made about any rights held in or over the resource." Your solution sounds exactly right in this situation. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com Yahoo! Groups Links
egroups+topografix.com on Fri Apr 16 10:21:14 2004 (link), replying to msg
Hello, There are two issues I'd like to see addressed in GPX 1.1: 1. email addresses in the <email> tag may be harvested by Web crawlers and start receiving spam. Google is already displaying the full contents of GPX files, exposing email addresses. 2. Someone asked for multiple URLs per waypoint/route/track a while back and we agreed that was a good idea. Proposed solutions: 1. Break <email> up into two required parts: <email id="dan_foster" domain="hotmail.com" /> It should be pretty obvious how to reconstruct an email address from the two parts. 2. Change <url> from "occurs zero or one times" to "occurs zero or more times" While we're at it, <url> and <urlname> should get combined into one element with a required href attribute like this: <link href="http://www.cnn.com">Link to CNN Web site</link> We could add an optional <type> element to let the user specify what kind of media she's linking to: <link href="http://www.kodak.com/my_photo.jpg">Photo of waypoint <type>image/jpg</type> </link> Several GPX-enabled programs are linking photos to tracklogs. At least one mapping program links audio files to route points to give voice prompts at intersections. Your thoughts? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
feedback+gpxchange.com on Fri Apr 16 15:33:56 2004 (link)
The copyright addition implemented in GPX 1.1 looks good to me. I also agree with Ed that copyright information should be retained whenever possible. Those applications that display and perpetuate this information are likely to gain favorable publicity from the authors and publishers who originally expressed concern. Regarding merged data - how would the elements support Ed's "retain it all" option?
feedback+gpxchange.com on Fri Apr 16 15:42:14 2004 (link), replying to msg
The changes suggested below make a bunch of sense to me. I guess my concern is that changes are much more disruptive than additions. Are there any other elements in the current schema where changes are currently being debated? --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > There are two issues I'd like to see addressed in GPX 1.1: > 1. email addresses in the <email> tag may be harvested by Web > crawlers and start receiving spam. Google is already displaying the > full contents of GPX files, exposing email addresses. > > 2. Someone asked for multiple URLs per waypoint/route/track a while > back and we agreed that was a good idea. > > Proposed solutions: > 1. Break <email> up into two required parts: > <email id="dan_foster" domain="hotmail.com" /> > It should be pretty obvious how to reconstruct an email address from > the two parts. > > 2. Change <url> from "occurs zero or one times" to "occurs zero or more times" > While we're at it, <url> and <urlname> should get combined into one > element with a required href attribute like this: > <link href="http://www.cnn.com">Link to CNN Web site</link> > > We could add an optional <type> element to let the user specify what > kind of media she's linking to: > <link href="http://www.kodak.com/my_photo.jpg">Photo of waypoint > <type>image/jpg</type> > </link> > > Several GPX-enabled programs are linking photos to tracklogs. At > least one mapping program links audio files to route points to give > voice prompts at intersections. > > Your thoughts? > > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
davewissenbach+yahoo.com on Sun Apr 18 08:31:58 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > The copyright addition implemented in GPX 1.1 looks good to me. I > also agree with Ed that copyright information should be retained > whenever possible. Those applications that display and perpetuate > this information are likely to gain favorable publicity from the > authors and publishers who originally expressed concern. > > Regarding merged data - how would the elements support Ed's "retain > it all" option? I do support the copyright information and will display this information in my program, but I need to turn your comment on its head and say that those authors and publishers who release content with liberal license terms are likely to gain favorable publicity on my website! I'll probably license my original trail data under the terms that it can be charged for as part of a collection, and that distribution can be charged for, but the data is otherwise free. Ultimately, I think that every travel guide will include GPS data--I think that we've got a pretty good data format for this purpose. Dave
ed+topozone.com on Sun Apr 18 09:19:51 2004 (link)
Dave - That's why I qualified the statement to pertain to those "who originally expressed concern" I'm not lobbying for or against restrictive licensing. I do lobby for respecting the wishes of the data creators - that way they get to set the rules, and the market (customers, publicists, etc.) gets to decide which ones they like! - Ed Ed McNierney President and Chief Mapmaker TopoZone.com -----Original Message----- From: David S. Wissenbach [mailto:davewissenbach+yahoo.com] Sent: Sunday, April 18, 2004 11:32 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: copyright - GPX schema addition --- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > The copyright addition implemented in GPX 1.1 looks good to me. I also > agree with Ed that copyright information should be retained whenever > possible. Those applications that display and perpetuate this > information are likely to gain favorable publicity from the authors > and publishers who originally expressed concern. > > Regarding merged data - how would the elements support Ed's "retain > it all" option? I do support the copyright information and will display this information in my program, but I need to turn your comment on its head and say that those authors and publishers who release content with liberal license terms are likely to gain favorable publicity on my website! I'll probably license my original trail data under the terms that it can be charged for as part of a collection, and that distribution can be charged for, but the data is otherwise free. Ultimately, I think that every travel guide will include GPS data--I think that we've got a pretty good data format for this purpose. Dave Yahoo! Groups Links
egroups+topografix.com on Sun Apr 18 15:48:40 2004 (link), replying to msg
Hello, Friday, April 16, 2004, 6:41:39 PM, Offroute wrote: o> Are there any other elements in the current schema where o> changes are currently being debated? I'd like to see the <author> tag in the "metadata" section expanded to include a URL, and I'd move <email> into <author>, since it's logically connected of the author. For example, if I publish a data file for a national park, I'd like to be able to include a link to the park service Web site (<url> in GPX 1.0) as well as include a link to my Web site as part of the <author> information. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
smart_ad0662+yahoo.co.in on Mon Apr 19 03:08:24 2004 (link)
Dear Sir / Madam, Here is a Wonderful Part Time Home based Job Opportunity to be executed online, exclusively meant for you to earn income every month to change your lifestyle or to meet your daily additional requirements, the way you want. The main features of this job are: Home Based, No Restrictions in Timing, No Boss and No Subordinate problems. ASK ME FOR MORE DETAILS AND SEND E-MAIL ONLY TO THE E-MAIL ID MENTIONED BELOW AND NOT TO MY PERSONAL E-MAIL ID: Smart0662+rediffmail.com Note: 1. Please mention in Subject as "Details requested". 2. Please don't attach "RESUMES" You can type advertisements that will be given to you and perform ad typing jobs during your valuable spare time of at least 1 to 2 hours a day at your convenience shall fetch you decent monthly returns, without any risk. Full training will be provided. Income based on response. The gift of earning money has come to you. Do grab this excellent part time job opportunity and enjoy the benefits, if you are interested. For more details kindly visit http://www.geocities.com/udaya_shre22/smartjobs.html Regards, SRIDEVI.A.R.
kz6g+yahoo.com on Thu Apr 22 15:37:15 2004 (link)
Maps on us [www.mapsonus.com]can save turn by turn lat/lon GPS waypoint data to an html file. It would be great if this could be converted to gpx for importing into GPS applications like EasyGPS, ExpertGPS, etc. I am not a GPX developer, but I know a lot of GPS users would love a way to import a series of waypoints into a GPS application from an on-line trip planning application. Mapblast, mapquest, etc., do not have this functionality. Thoughts anyone? Thanks KZ6G
kz6g+yahoo.com on Thu Apr 22 15:39:01 2004 (link)
Maps on us [www.mapsonus.com]can save turn by turn lat/lon GPS waypoint data to an html file. It would be great if this could be converted to gpx for importing into GPS applications like EasyGPS, ExpertGPS, etc. I am not a GPX developer, but I know a lot of GPS users would love a way to import a series of waypoints into a GPS application from an on-line trip planning application. Mapblast, mapquest, etc., do not have this functionality. Thoughts anyone? Thanks KZ6G
egroups+topografix.com on Fri Apr 23 05:26:21 2004 (link), replying to msg
Hello, Thursday, April 22, 2004, 6:37:07 PM, you wrote: k> Maps on us [www.mapsonus.com]can save turn by turn lat/lon GPS k> waypoint data to an html file. It would be great if this could be k> converted to gpx for importing into GPS applications like EasyGPS, k> ExpertGPS, etc. I think this would make a great standalone GPX application. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
murphy+enterprise.net on Sun Apr 25 04:37:49 2004 (link), replying to msg
Try "GPS Utility" from www.gpsu.co.uk. This will import MapsOnUs files - also MAP24, RAC, Greenflag (European) and many more sources of geo-data. You can then load the data direct to a GPS or export as a GPX file. For details, please see www.gpsu.co.uk/functions.html Alan Murphy (author GPSU). On 23 Apr 2004 19:51:53 -0000, you wrote: > >There are 3 messages in this issue. > >Topics in this digest: > > 1. Maps On Us turn-by-turn to GPS > From: "kz6g" <kz6g+yahoo.com> > 2. Maps On Us turn-by-turn to GPS > From: "kz6g" <kz6g+yahoo.com> > 3. Re: Maps On Us turn-by-turn to GPS > From: Dan Foster <egroups+topografix.com> > > >________________________________________________________________________ >________________________________________________________________________ > >Message: 1 > Date: Thu, 22 Apr 2004 22:37:07 -0000 > From: "kz6g" <kz6g+yahoo.com> >Subject: Maps On Us turn-by-turn to GPS > >Maps on us [www.mapsonus.com]can save turn by turn lat/lon GPS >waypoint data to an html file. It would be great if this could be >converted to gpx for importing into GPS applications like EasyGPS, >ExpertGPS, etc. >I am not a GPX developer, but I know a lot of GPS users would love a >way to import a series of waypoints into a GPS application from an >on-line trip planning application. Mapblast, mapquest, etc., do not >have this functionality. >Thoughts anyone? > >Thanks >KZ6G > > > >________________________________________________________________________ >________________________________________________________________________ > >Message: 2 > Date: Thu, 22 Apr 2004 22:38:11 -0000 > From: "kz6g" <kz6g+yahoo.com> >Subject: Maps On Us turn-by-turn to GPS > >Maps on us [www.mapsonus.com]can save turn by turn lat/lon GPS >waypoint data to an html file. It would be great if this could be >converted to gpx for importing into GPS applications like EasyGPS, >ExpertGPS, etc. >I am not a GPX developer, but I know a lot of GPS users would love a >way to import a series of waypoints into a GPS application from an >on-line trip planning application. Mapblast, mapquest, etc., do not >have this functionality. >Thoughts anyone? > >Thanks >KZ6G > > > >________________________________________________________________________ >________________________________________________________________________ > >Message: 3 > Date: Fri, 23 Apr 2004 08:29:48 -0400 > From: Dan Foster <egroups+topografix.com> >Subject: Re: Maps On Us turn-by-turn to GPS > >Hello, > >Thursday, April 22, 2004, 6:37:07 PM, you wrote: > >k> Maps on us [www.mapsonus.com]can save turn by turn lat/lon GPS >k> waypoint data to an html file. It would be great if this could be >k> converted to gpx for importing into GPS applications like EasyGPS, >k> ExpertGPS, etc. > >I think this would make a great standalone GPX application.
davewissenbach+yahoo.com on Tue Apr 27 05:37:12 2004 (link)
Software Designers, An acquaintance using my website with ExpertGPS noted that the view waypoint on line feature of ExpertGPS didn't work properly under certain circumstances. Debugging further, he noted that I was using relative URL's on my web site. The use of relative URL's is convenient for testing the web site offline, which is why I did that. Obviously, I need to switch to absolute URL's, so that the GPX files are portable. One other option might be to add the equivalent of the html base tag (or just use the html base tag) in the metadata section of the gpx file format. The base tag furnishes the absolute portion of the URL (host and directory) and then an application can compose an absolute URL from the base and the relative URL. This composition too difficult to implement--I've done this as part of my day job in less than a day. What does the group prefer? Canonizing the practice of using relative URL's, or adding a base tag to the GPX standard? Dave Wissenbach
feedback+gpxchange.com on Tue Apr 27 08:41:38 2004 (link), replying to msg
I'm for keeping it as it is - the user should enter the entire absolute URL. --- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > Software Designers, > > An acquaintance using my website with ExpertGPS noted that the view > waypoint on line feature of ExpertGPS didn't work properly under > certain circumstances. Debugging further, he noted that I was using > relative URL's on my web site. > > The use of relative URL's is convenient for testing the web site > offline, which is why I did that. Obviously, I need to switch to > absolute URL's, so that the GPX files are portable. > > One other option might be to add the equivalent of the html base tag > (or just use the html base tag) in the metadata section of the gpx > file format. The base tag furnishes the absolute portion of the URL > (host and directory) and then an application can compose an absolute > URL from the base and the relative URL. This composition too > difficult to implement--I've done this as part of my day job in less > than a day. > > What does the group prefer? Canonizing the practice of using > relative URL's, or adding a base tag to the GPX standard? > > Dave Wissenbach
egroups+topografix.com on Tue Apr 27 10:21:02 2004 (link), replying to msg
Hello, Tuesday, April 27, 2004, 8:33:48 AM, Dave W. wrote: D> he noted that I was using relative URL's on my web site. I'm also guilty of this. I use "style.xsl" for all of my GPX stylesheets, and just assume there's actually a stylesheet in the directory where the file eventually ends up. D> What does the group prefer? Canonizing the practice of using D> relative URL's, or adding a base tag to the GPX standard? I think you meant to write absolute in the first option, correct? D> What does the group prefer? Canonizing the practice of using D> *absolute* URL's, or adding a base tag to the GPX standard? The <base href="www.mysite.com/mydir/mypage.html"> directive is optional in HTML, and when it isn't included, the document viewer is to assume that the base URL is the one it used to access the document. Presumably ExpertGPS was looking in the same folder as the .gpx file for the file you referenced with a relative URL, but the file was still on your server. Is that what happened? (I'm going to assume you've got a GPX file containing a waypoint with a link to a photo from now on...) Using absolute URLs always solves the file location problem, but creates some other problems. It means you can't move the entire file set (gpx file and related photo) to a new directory or server without changing all the links by hand. It means if you download the entire file set to your hard drive, programs will still go out to your Web site to view the photos. There may also be server-side security restrictions to deal with. (Most scripting languages won't let you load a javascript or other file from a different domain, as I recall) Using relative URLs works as long as the entire file set moves together. In Dave's case, [again, I'm assuming] the GPX file moved but the photo didn't. One solution would be to distribute zipped file sets (I believe QuakeMap already supports this), but this doesn't help if you also plan to use and manipulate the GPX file on the server. It seems to me that adding an optional base URL in the metadata section doesn't hurt anything, and may help Dave and others manage their Web sites better. I'm in favor of adding this to GPX 1.1. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
lehto123+yahoo.co.uk on Wed Apr 28 06:07:19 2004 (link)
Hello! As a new subscriber of this group, a question about standardisation status of GPX. Is there any activities relating to e.g OMA (Open Mobile Alliance) or any other forums. Who is responsiple of changes if DTD needs to maintained? cheers Mike --------------------------------- Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now [Non-text portions of this message have been removed]
egroups+topografix.com on Thu Apr 29 05:03:07 2004 (link), replying to msg
Hello, Wednesday, April 28, 2004, 9:07:15 AM, Mike wrote: M> As a new subscriber of this group, a question about standardisation status of GPX. Is there any activities relating to e.g OMA (Open Mobile Alliance) or any other forums. Who is responsiple of M> changes if DTD needs to maintained? The GPX schema is hosted on topografix.com, and I update it as changes are approved. GPX 1.0 has been complete and locked for about a year. We're wrapping up the changes to GPX 1.1 now. Early on, we decided to focus on getting GPX into use, rather than push for its adoption in one of the standards committees. If you'd like to lead an effort to get it certified, I'm sure there would be people on the GPX list willing to help you. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
donreith+rogers.com on Mon May 03 06:55:47 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > The GPX schema is hosted on topografix.com, and I update it as changes > are approved. GPX 1.0 has been complete and locked for about a year. > We're wrapping up the changes to GPX 1.1 now. Given that the latest ExpertGPS build saves to 1.1 is that an indication that 1.1 is wrapped up? I need to get to work to update my MapPoint plug-in as it barfs on 1.1 files... Don http://homepage.mac.com/donreith/gpxExchange/
egroups+topografix.com on Mon May 03 08:18:57 2004 (link), replying to msg
Hello, Monday, May 3, 2004, 9:55:18 AM, Don wrote: D> Given that the latest ExpertGPS build saves to 1.1 is that an D> indication that 1.1 is wrapped up? Changes like Dave W's base URL request could still be added without problems. Because it is an optional element, it wouldn't cause problems with the existing version of ExpertGPS, or files created with it. I still need to write the GPX 1.1 developer's manual (1.0 is at http://www.topografix.com/gpx_manual.asp ). It would be nice to wrap up the discussion on Dave's proposal and any other changes this month. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
lehto123+yahoo.co.uk on Tue May 11 23:07:33 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Wednesday, April 28, 2004, 9:07:15 AM, Mike wrote: > > M> As a new subscriber of this group, a question about standardisation status of GPX. Is there any activities relating to e.g OMA (Open Mobile Alliance) or any other forums. Who is responsiple of > M> changes if DTD needs to maintained? > D> The GPX schema is hosted on topografix.com, and I update it as changes > are approved. GPX 1.0 has been complete and locked for about a year. > We're wrapping up the changes to GPX 1.1 now. > > Early on, we decided to focus on getting GPX into use, rather than > push for its adoption in one of the standards committees. If you'd > like to lead an effort to get it certified, I'm sure there would be D> people on the GPX list willing to help you. In many cases it is more efficient to do just as you said above since standarisation is often slow process and waiting of results can delay development. However it can give some benefits later because "de facto" type of formats which are hosted by one company (even it might be in strong position in market) include more risks from 3rd party Sw vendor point of view. As a conclusion I understand that there is no activities ongoing relating to standardisation of GPX according to knowlege of subscribers of gpsxml-group?
joelfinkle+hotmail.com on Wed May 12 08:32:43 2004 (link)
Has anyone created a simple way to import, say, a spreadsheet's worth of street addresses (tag, number, street, city, state, zip, country) to GPX? It would be very handy for creating customized maps or waypoint files for tours, deliveries, etc. In particular, the Chicago area Chowhound forum (http://www.chowhound.com) has been chatting about creating a map of the hot eating places around the city. A GPS-downloadable version of that would be quite useful. Someone delivering flowers, picking up donated items, etc. could use this kind of feature versus more- expensive GIS systems. Hey, at least I didn't ask for a least-cost route between all the points ;)
robertlipe+usa.net on Wed May 12 09:07:20 2004 (link), replying to msg
jfinkle wrote: > Has anyone created a simple way to import, say, a spreadsheet's worth > of street addresses (tag, number, street, city, state, zip, country) > to GPX? It would be very handy for creating customized maps or > waypoint files for tours, deliveries, etc. GPX isn't the hard part of that equation; the geocoding is. http://members.aol.com/_ht_a/marklent60544/myhomepage/Geocaching/markwellgcfaq.htm#Address The automated tools that can do this tend to not be inexpensive as the data sets are huge. > that would be quite useful. Someone delivering flowers, picking up > donated items, etc. could use this kind of feature versus more- > expensive GIS systems. This is actually the domain of tools like that. Microsoft's Mappoint (~$250 street price) is meant for that kind of thing. I haven't personally used it, so I could be wrong. There are a couple of GPX converters for MapPoint around; see http://www.hypercubed.com/projects/coordex/ for one. > Hey, at least I didn't ask for a least-cost route between all the > points ;) That's actually easier than getting those points. Even the $20 Streets & Trips program from Microsoft will do that. But it doesn't do GPX without conversion. See: http://gpsbabel.sourceforge.net/formats/s_and_t/TripPlanning.html
james_sherring+yahoo.com on Wed May 12 09:07:58 2004 (link)
Hi Joel, If you have access to MS Streets & Trips or MapPoint, you can import a spreadsheet of addresses and have those geocoded. You can then use st2gpx http://gpsbabel.sourceforge.net/st2gpx/st2gpx.html to save the geocoded addresses as GPX. Streets & Trips can also do the least-cost route. If you already have the addresses geocoded then you can use gpsbabel to convert a list to GPX. Cheers, James -----Original Message----- From: jfinkle [mailto:joelfinkle+hotmail.com] Sent: 12 May 2004 17:32 To: gpsxml+yahoogroups.com Subject: [gpsxml] Street Address to GPX? Has anyone created a simple way to import, say, a spreadsheet's worth of street addresses (tag, number, street, city, state, zip, country) to GPX? It would be very handy for creating customized maps or waypoint files for tours, deliveries, etc. In particular, the Chicago area Chowhound forum (http://www.chowhound.com) has been chatting about creating a map of the hot eating places around the city. A GPS-downloadable version of that would be quite useful. Someone delivering flowers, picking up donated items, etc. could use this kind of feature versus more- expensive GIS systems. Hey, at least I didn't ask for a least-cost route between all the points ;) Yahoo! Groups Links http://groups.yahoo.com/group/gpsxml/ gpsxml-unsubscribe+yahoogroups.com http://docs.yahoo.com/info/terms/ __________________________________ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861
egroups+topografix.com on Wed May 12 09:50:15 2004 (link), replying to msg
Hello, Wednesday, May 12, 2004, 11:31:45 AM, Joel wrote: j> Has anyone created a simple way to import, say, a spreadsheet's worth j> of street addresses (tag, number, street, city, state, zip, country) j> to GPX? Here's another geocoding option. This one is a Web service, with a free trial online: http://www.geocode.com/modules.php?name=TestDrive_Eagle -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
joelfinkle+hotmail.com on Thu May 13 13:54:41 2004 (link), replying to msg
Thanks, all. Unfortunately, there's no such thing as a free lunch here. Geocoding the addresses is obviously easy enough to do, because all of the online map services have that data, but nobody gives it away. Garmin's Mapsource doesn't have an API that I can discover, so it looks like there's no easy way at it. Much appreciated, Joel --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Wednesday, May 12, 2004, 11:31:45 AM, Joel wrote: > > j> Has anyone created a simple way to import, say, a spreadsheet's worth > j> of street addresses (tag, number, street, city, state, zip, country) > j> to GPX? > > Here's another geocoding option. This one is a Web service, with a > free trial online: > http://www.geocode.com/modules.php?name=TestDrive_Eagle > > -- > Dan Foster
bhjfzgx1+yahoo.com on Sat May 15 19:13:55 2004 (link)
hey hey, just thought id tell you guys about this free debt consolidation site that reduced my monthly payments by damn near half, no more worries about bills! http://pvglmbuakh.badlink.net I posted this on gpsxml, if you dont want to be a member anymore just email gpsxml-unsubscribe+yahoogroups.com
ophelia_lpm+yahoo.com on Sun May 16 22:14:46 2004 (link)
Do you drive a Lemon instead of a car? Get a free auto warranty quote. never pay for major car repairs again. we will help. check us out http://carwarrant.4all.cc This email was sent because you joined our group. If you do not wish to recieve any emails, unsubscribe. by sending a mail here gpsxml-unsubscribe+yahoogroups.com
ritesh1920+yahoo.com on Sun May 16 22:32:39 2004 (link)
hey can anyone tell me how to convert tab files to shape files. n also how to mark a point on the shape file given the lat/long information.. thank u.. ritesh
patty_v5klr+yahoo.com on Sat May 22 07:49:49 2004 (link)
I was really far into debt. Like Most I was in Financial dispair. I could not seem to get ahead no matter how hard I tried. Untill I found this place. http://behappynow.4ever.cc If you are in debt they can help you out. Check them out today I did. This email was sent because you joined our group. If you do not wish to recieve any emails, unsubscribe. by sending a mail here gpsxml-unsubscribe+yahoogroups.com
ritesh1920+yahoo.com on Mon May 24 10:44:36 2004 (link)
hi there hey am doing a proj in which i need o lat/long info frm a gps unit n then display it on a map.. can any one hlp me in letting me oe do i get tht info n hoe do i get a point on map.. i want to know everything frm the basic lets say li e wots a shape file , a tab file...where can i find the codes or some hlp regrding it.. am doing it in visual basic..any sites where i cn find something... i got a garmin unit .. gramin 12xl unit.. i would really appearcite if i could hlp in this proj.. thankx ritesh...
softwarejobsatjobcurry+yahoo.com on Thu Jun 03 03:15:22 2004 (link)
Hello Friends, This is Robin here from Spider Systems Pvt. Ltd Pune. We are a part of a global IT company called "IGATE INC". IGATE is a SEI CMM Level 5 company and has its HO in Pittsburg US. We are looking for Perl/XML resources our Pune office. Further details of the requirement are as follows. Designation: Developer Skills: Perl/Perl-DBI/XML/Oracle or Sybase Experience:1-3yrs Location:Pune We are ready to look at candidates with only Perl experience for this position. They would be trained on other desired skills. Interested candidates kindly send your profiles to robina+spidersystems.co.in Regds Robin Anthony Resourcing Executive Spider Systems Pvt. Ltd. 020-26634315 --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger [Non-text portions of this message have been removed]
davewissenbach+yahoo.com on Mon Jun 07 05:19:37 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Monday, May 3, 2004, 9:55:18 AM, Don wrote: > > D> Given that the latest ExpertGPS build saves to 1.1 is that an > D> indication that 1.1 is wrapped up? > > Changes like Dave W's base URL request could still be added without > problems. Because it is an optional element, it wouldn't cause > problems with the existing version of ExpertGPS, or files created with > it. > I'm not sure that the base URL is absolutely necessary. I think that for now we're all agreed that we'll use absolute URLs. > I still need to write the GPX 1.1 developer's manual (1.0 is at > http://www.topografix.com/gpx_manual.asp ). It would be nice to wrap > up the discussion on Dave's proposal and any other changes this month. > I think that on of the things that we need to wrap up the format is to prove interoperability and publish example data. I'm converting Wissenbach Map3D to utilize the new format and expect to be done with this by the end of the month. I'd like to converge on a frozen format soon. I think this is expecially important because of the proliferation of GPS devices which has become more mainstream. (Lately, I've noticed a lot of mountain bikers carrying GPS receivers.) The one think that W3C brings in the standardization is a known process (publish working drafts, last call, specification finalized as a recommendation after two applications prove interoperability and a test suite has been published, etc.) Unfortunately, this process carries a lot of weight (I work closely with a representative of my employer who is on several W3C committees and this standards work has become almost his entire full-time job!) So I wouldn't want to go to the W3C, but at the same time, wider adoption of the GPX format by larger software companies might require the price of more formal process. Anyways, I'll contribute test files to the links area, and sample data on my website, once I finish the conversion of Wissenbach Map3D to the 1/1 format later this month. Dave Wissenbach
softwarejobsatjobcurry+yahoo.com on Tue Jun 08 01:44:19 2004 (link)
Hello Friends, We at Spider Systems Pvt Ltd are looking for Perl resources for our Pune office. We require people with the following skills: Experience: 6 months to 1yr Skills: Perl Location:Pune Interested candidates kindly send your profiles to robina+spidersystems.co.in Interviews will be arranged immediately for shortlisted candidates. Regds Robin Anthony Recruitment Consultant Spider Systems Pvt. Ltd. 020-26634315 --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger [Non-text portions of this message have been removed]
egroups+topografix.com on Wed Jun 09 10:52:17 2004 (link), replying to msg
Hello, Monday, June 7, 2004, 8:19:19 AM, Dave W. wrote: D> I think that on of the things that we need to wrap up the format is D> to prove interoperability and publish example data. I've implemented about 95% of what's in the <metadata> tag in ExpertGPS, and I'll post a sample file tomorrow to test against. D> The one think that W3C brings in the standardization is a known D> process (publish working drafts, last call, specification finalized D> as a recommendation after two applications prove interoperability D> and a test suite has been published, etc.) Unfortunately, this D> process carries a lot of weight (I work closely with a D> representative of my employer who is on several W3C committees and D> this standards work has become almost his entire full-time job!) D> So I wouldn't want to go to the W3C, but at the same time, wider D> adoption of the GPX format by larger software companies might D> require the price of more formal process. The annual Associate Member fee at w3c.org is $5700. I nominate Dave as our [unpaid] representative! We've had a few new list members ask "is GPX a standard?" and then disappear without any follow-up. I've heard various rumors that "big companies" are interested in GPX, but I won't repeat them here. If standardization or rigid procedures are a requirement for anyone lurking on the list, it would be good to hear it from you. I agree that we should have a more formal procedure for locking down versions of GPX, and also for proposing and adopting new changes. The "talk until we reach consensus" approach worked well in GPX 1.0, when there was a core group of developers who were all implementing GPX solutions at the same time. Questions got rapid replies. There are several hundred list members now, but questions don't many responses these days. Dave's original question about base URLs was asked in April, and it hasn't been resolved until now. If there's a consensus that we need a more rigid format, let's do it. We can start with GPX 1.1, if you'd like. Thoughts? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
egroups+topografix.com on Thu Jun 10 05:10:39 2004 (link), replying to msg
Hello, Here's some sample output from ExpertGPS. You'll notice I've moved my own private metadata element (topografix:active_point) to the <metadata> extensions as well. http://www.topografix.com/gpx/samples/topografix/metadata.gpx -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
robertlipe+usa.net on Thu Jun 10 07:17:45 2004 (link)
Dan Foster <egroups+topografix.com> wrote: > Here's some sample output from ExpertGPS. You'll notice I've moved my > own private metadata element (topografix:active_point) to the > <metadata> extensions as well. > > http://www.topografix.com/gpx/samples/topografix/metadata.gpx At a glance, the only thing I see that makes me uneasy is the 'email' tag which has now had its content moved from the tag to tag attributes. I don't know if its your plan to have email parse differently inside metadata than everywhere else (please don't) but if so, this is a change that will cause 1.0 readers to no longer see the contents of that tag.
egroups+topografix.com on Thu Jun 10 13:40:08 2004 (link), replying to msg
Hello, Thursday, June 10, 2004, 10:17:38 AM, Robert wrote: >> http://www.topografix.com/gpx/samples/topografix/metadata.gpx R> At a glance, the only thing I see that makes me uneasy is the 'email' tag R> which has now had its content moved from the tag to tag attributes. I don't R> know if its your plan to have email parse differently inside metadata than R> everywhere else (please don't) but if so, this is a change that will cause 1.0 R> readers to no longer see the contents of that tag. I'm not sure what you mean by "everywhere else" (ie, not inside <metadata>) since <email> only appears in the <metadata> section of GPX 1.1. Perhaps the Groundspeak schema has an <email> tag as well? My intention was to break up the email address to keep it from getting harvested by spam crawlers. trails + topografix.com was an email address I only used in GPX files, and it gets a fair amount of spam now. 1.0 readers would have to be updated to see any of the new changes, since they won't know to look inside <metadata>. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
robertlipe+usa.net on Thu Jun 10 13:51:14 2004 (link)
> I'm not sure what you mean by "everywhere else" (ie, not inside > <metadata>) since <email> only appears in the <metadata> section of > GPX 1.1. Perhaps the Groundspeak schema has an <email> tag as well? In 1.0, there was email tag at the top level. http://www.topografix.com/gpx_manual.asp#email > 1.0 readers would have to be updated to see any of the new changes, > since they won't know to look inside <metadata>. So this tag has been dropped, had it's format changed, and moved to metadata, right?
i5technologies+yahoo.co.in on Sat Jun 12 05:19:24 2004 (link)
Hi friends, We have the below immediate opening with our client a CMM LEVEL 5 company at BANGALORE. Applicants with the relevant SKILLSETS, Experience Level and Qualification will only be considered. Please read the requirement and instructions in full before applying. Please mail ur resumes to ? hr+i5technologies.com? with the subject line as (Position applied for ) (Skills) (years of experience) (Your present location). PROJECT MANAGERS/LEADERS - 6 ROLE: You will design, develop, and implement and deploy solutions built around Real Time Service Management suites and products. You will anticipate and resolve complex problems that impact the success of Fortune 50 enterprises and service providers. PASSION: Develop robust solutions that work reliably under a wide range of configurations and user environments. Seeing the solutions that you deploy being used by real people in their every day life. Architecting complex solutions that get deployed across millions of systems worldwide. ( Their software is installed on over 30 million machines and the number is growing every day). Working in small teams on fantastic products with tight delivery schedules. 5. Working on highly visible, mission critical projects with very demanding customers. EDUCATION AND EXPERIENCE : B.E./B.Tech Degree in computer science/business management from an accredited university or college. 2. Minimum 7 years experience in infracture, ERP or CRM products. REQUIRED SKILLS : Extensive experience in ASP, VBscript & JavaScript, development and optimization of SQL queries across databases, and HTML programming. Experience in XML, JSP & Visual Basic, and other scripting languages like Perl, AWK, Shell, Batch programs etc., Experience deploying and customizing complex systems in Windows (and ideally UNIX) environments, including IIS, Apache, and application servers. Excellent skills in troubleshooting/debugging and performance tuning applications. System Administration level understanding of HW/SW configurations, server farms, Networking & DNS. Experience with security and authentication mechanisms. Proven track record dealing with customers (onsite). Exhibit a "can-do" approach and inspire associates to excel, confront negative attitudes and develop a team spirit. Established as an expert in at least one area of speciality. Excellent communication and US English fluency Able to travel extensively worldwide. Kindly provide the following information; Your availability/notice period with current Employer. Years of relevant experience Expected Remuneration/Rate Last Drawn Salary Contact details: Office/Day Phone no. Resi/Evening Phone no. Mobile no: E-mail id?s ( please provide 2 id?s) Available timings Interested candidates can send their updated resume immediately to the mentioned mail id. Bye Prashanth.PS Prashanth.ps ? placement consultant I5technologies Mail id : hr + i5technologies.com Mobile : 98454 05119 Yahoo! India Matrimony: Find your partner online. [Non-text portions of this message have been removed]
gpstothemoon+yahoo.com on Mon Jun 21 16:16:42 2004 (link)
There is a film being made about GPS scavenger hunts. They are also having a real GPS scavenger hunt that will be worth $50k. It's a friend of mine doing it. I told him I would try to get some feedback from us GPS gaming geeks. So if you have thoughts on it, let me know. Anyhow, it should be cool. The website is: http://www.gpsthemovie.com Phil --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! [Non-text portions of this message have been removed]
ed+topozone.com on Mon Jun 21 16:52:17 2004 (link)
Phil - Does your friend live at the corner of Sheridan Street and Route 507 in Tenino, Washington <g>? - Ed Ed McNierney President and Chief Mapmaker TopoZone.com -----Original Message----- From: Phil Harris [mailto:gpstothemoon+yahoo.com] Sent: Monday, June 21, 2004 7:16 PM To: gpstothemoon+yahoo.com Subject: [gpsxml] GPS The Movie There is a film being made about GPS scavenger hunts. They are also having a real GPS scavenger hunt that will be worth $50k. It's a friend of mine doing it. I told him I would try to get some feedback from us GPS gaming geeks. So if you have thoughts on it, let me know. Anyhow, it should be cool. The website is: http://www.gpsthemovie.com Phil --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! [Non-text portions of this message have been removed] ------------------------ Yahoo! Groups Sponsor --------------------~--> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar. Now with Pop-Up Blocker. Get it for free! http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/2U_rlB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links
gpstothemoon+yahoo.com on Mon Jun 21 21:19:08 2004 (link), replying to msg
No. Why? Ed McNierney <ed+topozone.com> wrote:Phil - Does your friend live at the corner of Sheridan Street and Route 507 in Tenino, Washington <g>? - Ed Ed McNierney President and Chief Mapmaker TopoZone.com -----Original Message----- From: Phil Harris [mailto:gpstothemoon+yahoo.com] Sent: Monday, June 21, 2004 7:16 PM To: gpstothemoon+yahoo.com Subject: [gpsxml] GPS The Movie There is a film being made about GPS scavenger hunts. They are also having a real GPS scavenger hunt that will be worth $50k. It's a friend of mine doing it. I told him I would try to get some feedback from us GPS gaming geeks. So if you have thoughts on it, let me know. Anyhow, it should be cool. The website is: http://www.gpsthemovie.com Phil --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! [Non-text portions of this message have been removed] ------------------------ Yahoo! Groups Sponsor --------------------~--> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar. Now with Pop-Up Blocker. Get it for free! http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/2U_rlB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links Yahoo! Groups SponsorADVERTISEMENT --------------------------------- Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ 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. --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! [Non-text portions of this message have been removed]
ed+topozone.com on Tue Jun 22 04:49:15 2004 (link)
Go take a closer look at the website.... - Ed Ed McNierney President and Chief Mapmaker TopoZone.com -----Original Message----- From: Phil Harris [mailto:gpstothemoon+yahoo.com] Sent: Tuesday, June 22, 2004 12:18 AM To: gpsxml+yahoogroups.com Subject: RE: [gpsxml] GPS The Movie No. Why? Ed McNierney <ed+topozone.com> wrote:Phil - Does your friend live at the corner of Sheridan Street and Route 507 in Tenino, Washington <g>? - Ed Ed McNierney President and Chief Mapmaker TopoZone.com -----Original Message----- From: Phil Harris [mailto:gpstothemoon+yahoo.com] Sent: Monday, June 21, 2004 7:16 PM To: gpstothemoon+yahoo.com Subject: [gpsxml] GPS The Movie There is a film being made about GPS scavenger hunts. They are also having a real GPS scavenger hunt that will be worth $50k. It's a friend of mine doing it. I told him I would try to get some feedback from us GPS gaming geeks. So if you have thoughts on it, let me know. Anyhow, it should be cool. The website is: http://www.gpsthemovie.com Phil --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! [Non-text portions of this message have been removed] ------------------------ Yahoo! Groups Sponsor --------------------~--> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar. Now with Pop-Up Blocker. Get it for free! http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/2U_rlB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links Yahoo! Groups SponsorADVERTISEMENT --------------------------------- Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ 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. --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! [Non-text portions of this message have been removed] ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Domains - Claim yours for only $14.70 http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/2U_rlB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links
egroups+topografix.com on Tue Jun 22 05:05:37 2004 (link), replying to msg
Hello, Tuesday, June 22, 2004, 7:48:30 AM, Ed wrote: E> Go take a closer look at the website.... Looks like Ed is our $50,000 winner! Before you book the plane ticket to Washington, I'd ask exactly what they mean by "This movie is a suspense/thriller/horror film." I'd hate to see your remains end up scattered in geocaches across the Pacific Northwest... My advice to the filmmakers: 1. Follow the grand tradition of print and TV journalists by explaining to your audience how the GPS receiver sends its location to the satellites. 2. "This is a Unix system. I *know* this!" - preferably while the main character is looking at an eTrex held upside-down. 3. If you're going to post coordinates on the Web site, at least use GPX. Good luck with the movie! -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
tom+publicvoid.com on Wed Jun 23 20:26:14 2004 (link)
I've just joined this group and looking forward to contributing to the community. First though, I'm wondering if anyone could help me out. I'm trying to develop a .NET Web service using the GPX schema and am running into a few problems with getting .NET to format it properly. This is the result I get: <gpx xmlns="http://www.topografix.com/GPX/1/0"> <GetTestWaypointResult> <lat>40.73092</lat> <lon>-73.99777</lon> <name>WSPFOUNT</name> <desc>Washington Square Park Fountain</desc> </GetTestWaypointResult> </gpx> Does anyone know how to change "GetTestWaypointResult" to "wpt" and to put the lat and lon as attributes within it? Or examples of a web service code for gpx? Thanks. Here's the code I'm using: [WebService] public class gpxtest { [WebMethod] [SoapDocumentMethod (ResponseElementName="gpx", ResponseNamespace="http://www.topografix.com/GPX/1/0")] public wpt GetTestWaypoint() { wpt w = new wpt(40.73092f,- 73.99777f,"WSPFOUNT","Washington Square Park Fountain"); return w; } public class wpt { public float lat; public float lon; public string name; public string desc; public wpt () {} public wpt (float lt, float ln, string n, string d) { lat = lt; lon = ln; name = n; desc = d; } } }
jmanzer+comsearch.com on Mon Jun 28 12:33:56 2004 (link)
Please help me to define the accuracy requirement (detailed-description) for a "1A" and " 2C" coordinate derivation. Which one of these can be achieved using a calibrated GPS receiver (Garman 76S ; is what we commonly use). John Manzer Senior Technical Consultant Comsearch : An Andrew Company 19700 Janelia Farm Blvd. Ashburn, VA 20147 http://www.comsearch.com 703-726-5725 [Non-text portions of this message have been removed]
hjuxgjd8+yahoo.com on Tue Jun 29 22:22:49 2004 (link)
I had really high interest rates on my home loan. I saved thousands of dollars on home payments. And you can too. Interest rates are as low as can be, And Yes Even you can take advantage of this. This is how. Stop in and fill out this thirty-second form, to Begin the money saving process. http://realhomes.sites.cc Get a 100% free custom quote even If you have bad credit. Our specialists will Work with you exclusively to save you the most money possible. This email was sent because you joined our group. If you do not wish to recieve any emails, unsubscribe. by sending a mail here gpsxml-unsubscribe+yahoogroups.com
fb_yahoo+innersource.com on Thu Jul 01 07:45:22 2004 (link)
I've noticed that the more recent version of ExpertGPS (1.3.7) is writing version 1.1 GPX files. Unfortunately the GPX website makes no mention of v1.1 yet, so I'll pose my question here: Could someone explain why the namespace was changed between the 1.0 and 1.1 versions? Were the changes made that significant that it required changing the namespace? The implications of changing the namespace are significant and usually breaks compatibility between the two versions. This is good if the files are truly incompatible, but was that the case here? Otherwise we may be better served by keeping the namespace the same across compatible versions. Thanks, -Falke
egroups+topografix.com on Thu Jul 01 10:27:07 2004 (link), replying to msg
Hello, Thursday, July 1, 2004, 10:43:57 AM, Falke wrote: f> Could someone explain why the namespace was changed between the 1.0 f> and 1.1 versions? Were the changes made that significant that it f> required changing the namespace? f> The implications of changing the namespace are significant and f> usually breaks compatibility between the two versions. This is f> good if the files are truly incompatible, but was that the case here? f> Otherwise we may be better served by keeping the namespace the same f> across compatible versions. Several GPX 1.0 elements were removed from GPX 1.1. Is there any way we could have done this and kept the same namespace and still had both versions validate correctly? I agree with your point that we should make every effort to keep from changing the namespace. For example, we've had several proposals to add new optional elements to GPX, and I believe those should be added to the spec without bumping the namespace number. What difficulties are you running into with the two namespaces? I was able to parse both namespaces in MSXML without needing any explicit version checks. -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
davewissenbach+yahoo.com on Sun Jul 04 21:25:48 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Thursday, July 1, 2004, 10:43:57 AM, Falke wrote: > > f> Could someone explain why the namespace was changed between the 1.0 > f> and 1.1 versions? Were the changes made that significant that it > f> required changing the namespace? > > f> The implications of changing the namespace are significant and > f> usually breaks compatibility between the two versions. This is > f> good if the files are truly incompatible, but was that the case here? > f> Otherwise we may be better served by keeping the namespace the same > f> across compatible versions. > > Several GPX 1.0 elements were removed from GPX 1.1. > Is there any way we could have done this and kept the same namespace > and still had both versions validate correctly? > > I agree with your point that we should make every effort to keep from > changing the namespace. For example, we've had several proposals to > add new optional elements to GPX, and I believe those should be added > to the spec without bumping the namespace number. > > What difficulties are you running into with the two namespaces? I was > able to parse both namespaces in MSXML without needing any explicit > version checks. > I can't speak for Falke, but... Here's one small difficulty. A stylesheet written with the target namespace of GPX1.0 doesn't work with GPX1.1 files. However, the new GPX metadata element, the use of extensions to hold private elements, and the use of the wpt type for trackpoints, routes, and waypoints, constitute an accumulated difference so large that the new namespace should be used. Most applications should be able to handle both 1.0 and 1.1 data--my GPX 1.1 prototype does. (I'm in the final debug stage for conformance to the specification changes and will be releasing code soon.) Dave Wissenbach > -- > Dan Foster > TopoGrafix - GPS Software, Waypoints, and Maps > http://www.topografix.com - mailto:egroups+t...
davewissenbach+yahoo.com on Sat Jul 10 18:23:25 2004 (link)
GPS XML Developers, I've got Wissenbach Map3D now producing valid output for GPX1.1 format, including copyright tags. (Metadata is always displayed when opening a new map.) Added support for multiple links in metadata, waypoint, and track elements, but have not yet added support for links and other metadata in trackpoints. One problem -- gpx_style schema references a point type in the gpx1.1 schematic that is no longer present. (This is a problem with either the GPX1/1 schema or the GPX Style 0/1 schema). The installer, which also includes a sample GPX file, CelebrationPark.gpx, is at http://maps.cableone.net/map3d/SetupWissenbachMap3D.exe I haven't tested for compatibility with other programs (ExpertGPS). The new version reads data in GPX1.0 format or GPX1.1 format but always writes to GPX1.1 format, which means that a program which uses GPX1.0 format will not be able to access the metadata or the embedded links in the track. But the location data and waypoints names and comments will be compatible. Happy trails, Dave P.S. I'll be on vacation, away from the grid, the net, the phone, and everything, and not responsive to followup posts here until July 24th Dave
egroups+topografix.com on Wed Jul 28 11:37:22 2004 (link), replying to msg
Hello, I've made some stylistic changes to the GPX 1.1 schema, and used xsd:annotation to add documentation to the schema document itself. While this makes the schema somewhat harder to read, it allows the automatic generation of documentation from the schema. The schema changes should not have any impact on existing GPX instance documents or the programs which create them (Wissenbach Map, e.g.) The changes involved flattening the schema by using named complex and simple types for all GPX objects, and adding annotation. Please let me know if you have questions or concerns. Please review the schema and documentation and bring up any changes you'd like to see here on the discussion list. I will update the GPX resource pages to point to the 1.1 version of the schema as soon as a week goes by without any further discussion of 1.1 issues. Schema: http://www.topografix.com/gpx/1/1/gpx.xsd Documentation: http://www.topografix.com/gpx/1/1/ -- Dan Foster
davewissenbach+yahoo.com on Thu Jul 29 05:45:08 2004 (link), replying to msg
I think that the change to automatically extracted documentation is really good and the documentation page linked below is very easy to read. I really like the little ? easter eggs which give a detailed description of each element or attribute, so you don't see a lot of extra comments unless you want to. I'll put my GPX11toHTML.xsl stylesheet for extracting metadata and links from GPX online at http://maps.wissenbach.net/gpx/GPX11toHTML.xsl An example GPX file and resulting html from this stylesheet http://maps.wissenbach.net/idaho/BearValleyCreek.gpx http://maps.wissenbach.net/idaho/BearValleyGreek.html (Bear Valley Creek is an easy canoe float at the headwaters of the Middle Fork of the Salmon river) Dave --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > I've made some stylistic changes to the GPX 1.1 schema, and used > xsd:annotation to add documentation to the schema document itself. > While this makes the schema somewhat harder to read, it allows the > automatic generation of documentation from the schema. > > The schema changes should not have any impact on existing GPX instance > documents or the programs which create them (Wissenbach Map, e.g.) > The changes involved flattening the schema by using named complex and > simple types for all GPX objects, and adding annotation. Please let > me know if you have questions or concerns. > > Please review the schema and documentation and bring up any changes > you'd like to see here on the discussion list. I will update the GPX > resource pages to point to the 1.1 version of the schema as soon as a > week goes by without any further discussion of 1.1 issues. > > Schema: http://www.topografix.com/gpx/1/1/gpx.xsd > Documentation: http://www.topografix.com/gpx/1/1/ > > -- > Dan Foster
davewissenbach+yahoo.com on Sat Jul 31 05:06:37 2004 (link), replying to msg
A gentleman from the UK pointed out that the stylesheet in the sample gpx file was incorrect. I've modified the GPX file to use the correct stylesheet in the processing instruction for internet explorer. The root cause is a bug in Wissenbach Map3D which used an old registry setting when writing the stylesheet processing instruction. --- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > I think that the change to automatically extracted documentation is > really good and the documentation page linked below is very easy to > read. I really like the little ? easter eggs which give a detailed > description of each element or attribute, so you don't see a lot of > extra comments unless you want to. > > I'll put my GPX11toHTML.xsl stylesheet for extracting metadata and > links from GPX online at > > http://maps.wissenbach.net/gpx/GPX11toHTML.xsl > > An example GPX file and resulting html from this stylesheet > > http://maps.wissenbach.net/idaho/BearValleyCreek.gpx The file has been updated with a new processing instruction. > http://maps.wissenbach.net/idaho/BearValleyGreek.html Make that BearValleyCreek.html Creek such as a stream, not Greek such as Zorba > > (Bear Valley Creek is an easy canoe float at the headwaters of the > Middle Fork of the Salmon river) > > Dave > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Hello, > > > > I've made some stylistic changes to the GPX 1.1 schema, and used > > xsd:annotation to add documentation to the schema document itself. > > While this makes the schema somewhat harder to read, it allows the > > automatic generation of documentation from the schema. > > > > The schema changes should not have any impact on existing GPX > instance > > documents or the programs which create them (Wissenbach Map, e.g.) > > The changes involved flattening the schema by using named complex > and > > simple types for all GPX objects, and adding annotation. Please > let > > me know if you have questions or concerns. > > > > Please review the schema and documentation and bring up any changes > > you'd like to see here on the discussion list. I will update the > GPX > > resource pages to point to the 1.1 version of the schema as soon > as a > > week goes by without any further discussion of 1.1 issues. > > > > Schema: http://www.topografix.com/gpx/1/1/gpx.xsd > > Documentation: http://www.topografix.com/gpx/1/1/ > > > > -- > > Dan Foster
davewissenbach+yahoo.com on Thu Aug 05 05:45:49 2004 (link), replying to msg
All, As of August 5, the data at BearValleyCreek.gpx was correctly updated to reference the stylesheet in the processing instruction, for client-side transformation in IE6. (I'd uploaded to the server, but to the wrong directory.) Dave --- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > A gentleman from the UK pointed out that the stylesheet in the > sample gpx file was incorrect. I've modified the GPX file to use the > correct stylesheet in the processing instruction for internet > explorer. The root cause is a bug in Wissenbach Map3D which used an > old registry setting when writing the stylesheet processing > instruction. > > --- In gpsxml+yahoogroups.com, "David S. Wissenbach" > <davewissenbach+y...> wrote: > > I think that the change to automatically extracted documentation > is > > really good and the documentation page linked below is very easy > to > > read. I really like the little ? easter eggs which give a detailed > > description of each element or attribute, so you don't see a lot > of > > extra comments unless you want to. > > > > I'll put my GPX11toHTML.xsl stylesheet for extracting metadata and > > links from GPX online at > > > > http://maps.wissenbach.net/gpx/GPX11toHTML.xsl > > > > An example GPX file and resulting html from this stylesheet > > > > http://maps.wissenbach.net/idaho/BearValleyCreek.gpx > > The file has been updated with a new processing instruction. > > > http://maps.wissenbach.net/idaho/BearValleyGreek.html > > Make that BearValleyCreek.html > > Creek such as a stream, not Greek such as Zorba > > > > > (Bear Valley Creek is an easy canoe float at the headwaters of the > > Middle Fork of the Salmon river) > > > > Dave > > > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > > Hello, > > > > > > I've made some stylistic changes to the GPX 1.1 schema, and used > > > xsd:annotation to add documentation to the schema document > itself. > > > While this makes the schema somewhat harder to read, it allows > the > > > automatic generation of documentation from the schema. > > > > > > The schema changes should not have any impact on existing GPX > > instance > > > documents or the programs which create them (Wissenbach Map, > e.g.) > > > The changes involved flattening the schema by using named > complex > > and > > > simple types for all GPX objects, and adding annotation. Please > > let > > > me know if you have questions or concerns. > > > > > > Please review the schema and documentation and bring up any > changes > > > you'd like to see here on the discussion list. I will update > the > > GPX > > > resource pages to point to the 1.1 version of the schema as soon > > as a > > > week goes by without any further discussion of 1.1 issues. > > > > > > Schema: http://www.topografix.com/gpx/1/1/gpx.xsd > > > Documentation: http://www.topografix.com/gpx/1/1/ > > > > > > -- > > > Dan Foster
egroups+topografix.com on Mon Aug 09 09:24:12 2004 (link), replying to msg
Hello, I've updated the GPX Web site to point to the new GPX 1.1 schema and documentation. I updated the text on most of the GPX Web pages, and gave the site its own color scheme and navigation bar. Please take a look - feedback is always appreciated. http://www.topografix.com/gpx.asp -- Dan Foster
jtrubinca+yahoo.ca on Tue Aug 10 04:59:16 2004 (link)
Hello, I am a GIS technician for Natural Resources in Nova Scotia. We are using the GPX format as a standard input on a web site, so contractors can create and submit polygon shapefiles. I noticed the GPX version changed to 1.1 as of yesterday. Is there a synopsis of the changes from version 1.0 and will any of the changes effect our current conversion process. A standard like this was way too long in developing. Thanks John
egroups+topografix.com on Tue Aug 10 07:23:25 2004 (link), replying to msg
Hello, Tuesday, August 10, 2004, 7:59:02 AM, John wrote: j> I noticed the j> GPX version changed to 1.1 as of yesterday. Is there a synopsis of j> the changes from version 1.0 and will any of the changes effect our j> current conversion process. j> A standard like this was way too long in developing. There are no major changes to the base <wpt>, <rte>, and <trk> elements. If your users are submitting metadata (file, author, and copyright info) you will put that information in the new GPX 1.1 <metadata> element. If you are using your own private extensions to GPX, you will put that information in the GPX 1.1 <extensions> element, which appears in each public GPX element. Let us know if your conversion process goes smoothly. -- Dan Foster
jtrubinca+yahoo.ca on Tue Aug 10 08:43:35 2004 (link), replying to msg
Thanks Dan, We use only the base elements and the conversion process worked fine. John Dan Foster <egroups+topografix.com> wrote: Hello, Tuesday, August 10, 2004, 7:59:02 AM, John wrote: j> I noticed the j> GPX version changed to 1.1 as of yesterday. Is there a synopsis of j> the changes from version 1.0 and will any of the changes effect our j> current conversion process. j> A standard like this was way too long in developing. There are no major changes to the base <wpt>, <rte>, and <trk> elements. If your users are submitting metadata (file, author, and copyright info) you will put that information in the new GPX 1.1 <metadata> element. If you are using your own private extensions to GPX, you will put that information in the GPX 1.1 <extensions> element, which appears in each public GPX element. Let us know if your conversion process goes smoothly. -- Dan Foster Yahoo! Groups SponsorADVERTISEMENT --------------------------------- Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ 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. --------------------------------- Post your free ad now! Yahoo! Canada Personals [Non-text portions of this message have been removed]
rich+testingrange.com on Sat Aug 14 11:10:17 2004 (link)
Howdy All, I would like to load data from GPX files into a PostGIS database. I have 18 lines of Perl which generates SQL insert statements of waypoint data. This works just fine for my data. It is naive code that disregards some important aspects of the format, but, it is the 'simplest useful thing,' that has enabled me to do spatial queries against waypoint data. I am now looking to expand this simplest useful thing into the tracklog area. I'm wondering if anyone has already done this, or is also interested in this project. I've stumbled over a couple of non-obvious issues in designing a schema to adequately capture track log information. In any event, in the spirt of offering information, and not just taking, here are notes on how I am importing waypoints into postgis and two simple spatial queries on waypoint data. Also this is an attempt to follow the old usenet rule 'if you want information don't ask a question, rather, post an answer that is false.' I don't know if this _is_ false, but who knows :-) Happy happy to all! Cheers, Rich Gibson Assuming this trivial database table: create table waypoint ( waypoint_id serial NOT NULL, name varchar(32), cmt varchar(255), descr varchar(255), sym varchar(255), location geometry); Here's the perl code to import waypoints: #!/usr/bin/perl use XML::Simple; my $gpx = XMLin($ARGV[0] , NormalizeSpace=>1 ); foreach my $wpt (keys %{$gpx->{wpt}}) { $p = $gpx->{wpt}->{$wpt}; print qq( insert into waypoint (name, cmt, descr, sym, location) values ( '$wpt', '$p->{cmt}', '$p->{desc}', '$p->{sym}', GeometryFromText('POINT($p->{lon} $p->{lat})', 4326) ); ); } A typical invocation piping the output to the PostgreSQL command line, to directly insert into the postgis database named gpswork: ./parse_gpx_way.pl gpx_waypoints.xml | /usr/local/bin/psql -d gpswork This query returns the distance between my house and the toll plaza of the Golden Gate Bridge: select distinct w1.name, w2.name, distance_spheroid( w1.location, w2.location, 'SPHEROID["WGS_1984",6378137,298.257223563]' ) / 1609.344 as my_dist from waypoint w1, waypoint w2 where w1.name = 'HOME' and w2.name = 'TOLPLZ' The distance appears to be: name | name | my_dist ------+--------+----------------- HOME | TOLPLZ | 45.355346582827 And in the same vein, this calculates the distance from my house to all of my waypoints: select distinct w1.name, w2.name, distance_spheroid( w1.location, w2.location, 'SPHEROID["WGS_1984",6378137,298.257223563]' ) / 1609.344 as my_dist from waypoint w1, waypoint w2 where w1.name = 'HOME' order by w2.name Which ends up starting like this (you certainly don't care about all of my waypoints :-) name | name | my_dist ------+--------+------------------- HOME | 100 | 1032.24739646152 HOME | ABSPOT | 80.1128376219472 HOME | AC1 | 793.837536379135 HOME | ADAM | 0.234284473527997
rich+testingrange.com on Sat Aug 14 20:40:08 2004 (link), replying to msg
I know I'm replying to an old message, but check out geocoder.us This is an absolutely free US geocoder built around the Tiger data by my friend Schuyler Erle. There is a web service interface, and instructions to download the code and data and create your own instance of the geocoder. Cheers, Rich --- In gpsxml+yahoogroups.com, "jfinkle" <joelfinkle+h...> wrote: > Thanks, all. > Unfortunately, there's no such thing as a free lunch here. Geocoding > the addresses is obviously easy enough to do, because all of the > online map services have that data, but nobody gives it away. > Garmin's Mapsource doesn't have an API that I can discover, so it > looks like there's no easy way at it. > > Much appreciated, > Joel > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Hello, > > > > Wednesday, May 12, 2004, 11:31:45 AM, Joel wrote: > > > > j> Has anyone created a simple way to import, say, a spreadsheet's > worth > > j> of street addresses (tag, number, street, city, state, zip, > country) > > j> to GPX? > > > > Here's another geocoding option. This one is a Web service, with a > > free trial online: > > http://www.geocode.com/modules.php?name=TestDrive_Eagle > > > > -- > > Dan Foster
robertlipe+usa.net on Mon Aug 16 10:08:45 2004 (link), replying to msg
> stumbled over a couple of non-obvious issues in designing a schema to > adequately capture track log information. If you could explain why the GPX schema for tracks is inadequate, perhaps we could be more helpful. Your perl/sql stuff looks about right for 18 line solutions. Yeah, it leaves some information on the floor, but if it scratches your itch... RJL
rich+testingrange.com on Mon Aug 16 11:07:32 2004 (link), replying to msg
On Mon, 16 Aug 2004, Robert Lipe wrote: > > stumbled over a couple of non-obvious issues in designing a schema to > > adequately capture track log information. > > If you could explain why the GPX schema for tracks is inadequate, perhaps > we could be more helpful. Well I was referring to the database schema part of things. This is probably an implementation issue, but gpsbabel seems to limit trk's to one trksegment, which is a bit off. But I'm looking for anyone whos has alternate solutions to load trks into PostGIS, or is also interested in the problem. Anyone? Cheers, Rich
robertlipe+usa.net on Mon Aug 16 12:19:17 2004 (link), replying to msg
> probably an implementation issue, but gpsbabel seems to limit trk's to one > trksegment, which is a bit off. You should definitely take that up with the GPSBabel guy. RJL
hac_20+yahoo.com on Sun Aug 22 08:56:26 2004 (link)
this is for my thesis.........my lecturer give me one project about GPRS....the overview of this project is user can download maps on his mobile using GPRS and from that his can know the location his is there.gps will blink on this maps his location.The problem is i dont know how to start this project.how maps will be connect to GPS?how map can be download using GPRS?This project using MAPINFO software...and i dont know how to convert MAPINFO to XML Programming..i hope you all can help me...and teach me step by step..please..please..please
steve+fooworks.com on Mon Aug 23 11:55:11 2004 (link)
Hi, I'm joining the group & will now be reading through as much of the list archives as possible. I'm interested decentralizing gpx file searching and reading. -- Steve Mallett http://steve.osdir.com
rich+testingrange.com on Wed Aug 25 00:41:14 2004 (link), replying to msg
Hi Steve, What sorts of things are you interested in doing in terms of decentralized file searching? What sorts of things do you want to search for? Cheers, Rich On Mon, 23 Aug 2004, Steve Mallett wrote: > Hi, > > I'm joining the group & will now be reading through as much of the list > archives as possible. > > I'm interested decentralizing gpx file searching and reading. >
steve+fooworks.com on Wed Aug 25 04:37:43 2004 (link), replying to msg
Rich Gibson wrote: > Hi Steve, > > What sorts of things are you interested in doing in terms of decentralized > file searching? > > What sorts of things do you want to search for? I'd like to see: 1) An easy way to create & publish gpx routes/points, where the creator still has control of the file. 2) An aggregator/portal for finding them. I'm primarily interested in geocaching type gpx files. I'm aware geocaching.com has these, but they're locked up behind a 'premium membership'. I like geocaching.com, this isn't a slight, I'd just like to see this done in a bottom up manner. -- Steve Mallett http://steve.osdir.com
rich+testingrange.com on Wed Aug 25 07:46:48 2004 (link), replying to msg
The general problem of geospatial data discovery is hard...and worth doing. So let's look at it more! On Wed, 25 Aug 2004, Steve Mallett wrote: > Rich Gibson wrote: > > > Hi Steve, > > > > What sorts of things are you interested in doing in terms of decentralized > > file searching? > > > > What sorts of things do you want to search for? > > I'd like to see: > 1) An easy way to create & publish gpx routes/points, where the creator > still has control of the file. > 2) An aggregator/portal for finding them. I'm primarily interested in > geocaching type gpx files. I'm aware geocaching.com has these, but > they're locked up behind a 'premium membership'. I like geocaching.com, > this isn't a slight, I'd just like to see this done in a bottom up manner. > > >
steve+fooworks.com on Wed Aug 25 07:58:41 2004 (link), replying to msg
Rich Gibson wrote: > The general problem of geospatial data discovery is hard...and worth > doing. So let's look at it more! I think this might take place in a peopleaggregator/plink type of space where people just upload their own generated (foaf in this case) gpx files, and can upload anywhere else at whim. S > On Wed, 25 Aug 2004, Steve Mallett wrote: > > >>Rich Gibson wrote: >> >> >>>Hi Steve, >>> >>>What sorts of things are you interested in doing in terms of decentralized >>>file searching? >>> >>>What sorts of things do you want to search for? >> >>I'd like to see: >>1) An easy way to create & publish gpx routes/points, where the creator >>still has control of the file. >>2) An aggregator/portal for finding them. I'm primarily interested in >>geocaching type gpx files. I'm aware geocaching.com has these, but >>they're locked up behind a 'premium membership'. I like geocaching.com, >>this isn't a slight, I'd just like to see this done in a bottom up manner. >> >> >> > > > > > > Yahoo! Groups Links > > > > > > > -- Steve Mallett http://steve.osdir.com
egroups+topografix.com on Wed Aug 25 09:04:46 2004 (link), replying to msg
Hello, Wednesday, August 25, 2004, 7:40:51 AM, Steve wrote: S> I'd like to see: S> 1) An easy way to create & publish gpx routes/points, where the creator S> still has control of the file. S> 2) An aggregator/portal for finding them. We had projects like this in mind when we added these elements to the <metadata> section of the GPX files: <bounds> - so you could quickly determine if a GPX file covers your area of interest <keywords> - so you could search for specific activities I would be very happy to see someone create a search engine or Web service that catalogued GPX files stored on individual Web sites. Given a URL to a GPX file on the Web, it would extract the <metadata> section and store it in a database format. Programs (through a Web service) and end users (through an HTML form) could then query for particular waypoints, geocaches, or trails within a geographic area. I have a Publish to Web feature for GPX files built into EasyGPS and ExpertGPS, and I would extend this to allow files to be submitted to a GPX database as part of the publish process. -- Dan Foster
gps_maps+travelbygps.com on Thu Aug 26 05:07:22 2004 (link)
--- Dan Foster wrote: > I would be very happy to see someone create a search engine or Web > service that catalogued GPX files stored on individual Web sites. Interesting idea. I currently use Atomz as the keyword search utility at Travel by GPS http://www.travelbygps.com/search.php Atomz seems to be adequate however it is searching the content of my web pages and not the gpx files themselves. I'm also integrating Maptech's Mapserver as a geographical search engine, but it has some problems and I have to separately and manually create an icon data file that includes lat, lon, symbol, label... I too would be interested in search engine that cataloged gpx file, especially one that could be integrated into a web site like Travel by GPS. As long as we are making a wish list, I would want some control over results, that is, result ranking as per relevance to various meta- tags. That way premium or sponsored files could have special representation or simply listed first. - Doug
ariestiger+rocketmail.com on Tue Sep 07 09:41:21 2004 (link)
I was working with a tool to make my own parser for the gpx file from Geocaching.com. I ran into a problem where the naming of elements included a ":" and the code I was using would not recognize the element name. This was found by a colleague of mine. Microsoft XML 4.0 Parser SDK XML Developer's Guide / Concepts / document Map / Elements Element Names All elements must have names. Element names are case-sensitive and must start with a letter or underscore. An element name can contain letters, digits, hyphens, underscores, and periods. Note Colons are reserved for use with namespaces. For more information about which Unicode characters are acceptable letters and digits, see Appendix B of the XML specification. This would make the format of the gpx file used by Geocaching invalid. If any of you have worked with this format, how have you gotten around this problem. Tigg
robertlipe+usa.net on Tue Sep 07 10:50:32 2004 (link), replying to msg
ariestiger.rm wrote: > Note Colons are reserved for use with namespaces. [ ... ] > information about which Unicode characters are acceptable letters > and digits, see Appendix B of the XML specification. > > This would make the format of the gpx file used by Geocaching > invalid. If any of you have worked with this format, how have you > gotten around this problem. They aren't invalid; they're in a private groundspeak namespace. We "got around it" by implementing that namespace. There are dozens of tools, including my own GPSBabel, that handle all this just fine. RJL
ariestiger+rocketmail.com on Tue Sep 07 12:18:28 2004 (link)
Here is the format. I have simplified the data to better show the structure of the XML file. As you can see, once you get to the groundspeak portion they have created an element name using a ":". <gpx> <wpt lat="value" lon="value"> <time>value</time> <name>value</name> <desc>value</desc> <url>value</url> <urlname>value</urlname> <sym>value</sym> <type>value</type> <groundspeak:cache id="value" available="True" archived="False" xmlns:groundspeak="value"> <groundspeak:name>value</groundspeak:name> <groundspeak:placed_by>value</groundspeak:placed_by> <groundspeak:owner id="value">value</groundspeak:owner> <groundspeak:type>value</groundspeak:type> <groundspeak:container>value</groundspeak:container> <groundspeak:difficulty>value</groundspeak:difficulty> <groundspeak:terrain>value</groundspeak:terrain> <groundspeak:country> </groundspeak:country> <groundspeak:state>value</groundspeak:state> <groundspeak:short_description html="False">value</groundspeak:short_description> <groundspeak:long_description html="False">value</groundspeak:long_description> <groundspeak:encoded_hints> </groundspeak:encoded_hints> <groundspeak:logs> <groundspeak:log id="value"> <groundspeak:date>value</groundspeak:date> <groundspeak:type>value</groundspeak:type> <groundspeak:finder id="value">value</groundspeak:finder> <groundspeak:text encoded="False">value</groundspeak:text> </groundspeak:log> </groundspeak:logs> <groundspeak:travelbugs /> </groundspeak:cache> </wpt> </gpx>
ariestiger+rocketmail.com on Tue Sep 07 12:26:56 2004 (link), replying to msg
They aren't invalid; they're in a private groundspeak namespace. We "got around it" by implementing that namespace. There are dozens of tools, including my own GPSBabel, that handle all this just fine. So how does one go about implementing a private namespace so one can properly read this file? Is it like using a library that defines the namespace? Is there a particular language that one needs to program in to be able to read it properly? Thanks for the help. BTW I like GPSBabel. Tigg
egroups+topografix.com on Tue Sep 07 13:13:56 2004 (link), replying to msg
Hello, Someone pointed out to me off-list that <course> and <speed> were removed from <trkpt> in GPX 1.1. GPX 1.1 defines <wpt>, <rtept>, and <trkpt> identically. In GPX 1.0, <trkpt> contained these two extra elements. Should we add these elements back into the GPX 1.1 schema? Should we leave them out, and anyone who wants to use them can create a new namespace to handle them? If you are currently using these elements or have an opinion on how we should proceed, please speak out. -- Dan Foster
robertlipe+usa.net on Tue Sep 07 13:54:37 2004 (link), replying to msg
ariestiger.rm wrote: > So how does one go about implementing a private namespace so one can > properly read this file? Is it like using a library that defines > the namespace? Private namespaces allow folks (like Groundspeak) to extend the base spec definitions in a way that won't conflict with others and keeps their peanut butter out of everyone else's chocolate. At the risk of sounding rude, documentation on XML is plentiful in bookstores and the web. One such is: http://www.xml.com/pub/a/1999/01/3namespace.html a few minutes on your favorite search engine should uncover a wealth of information. > Is there a particular language that one needs to > program in to be able to read it properly? You could program it in Fortran, Forth, RPG, assembler, or anything else that aroused you. "It's a mere matter of programming." Source for GPSBabel is available if you want to see one possible approach. RJL
steve_raffaele+shaw.ca on Tue Sep 07 17:09:32 2004 (link), replying to msg
I, for one, would like to see the changes for <course> and <speed> implemented in GPX 1_1 as this was a very nice feature in 1_0 and I would hate to see us go backwards in functionality. Most applications that generate track files have these elements in place and it would be a shame to have to extend the schema to get these elements back. Although it's not extremely difficult to extend the schema (as goundspeek has done) it's just another step that we will have to go through to implement tracks as they have been in the past. I'm suprised that others havn't tried validating their existing .gpx files against the new schema yet. Maybe I'm the only one out there buildin track files in GPX? See Yah --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Someone pointed out to me off-list that <course> and <speed> were > removed from <trkpt> in GPX 1.1. GPX 1.1 defines <wpt>, <rtept>, and > <trkpt> identically. In GPX 1.0, <trkpt> contained these two extra > elements. > > Should we add these elements back into the GPX 1.1 schema? > Should we leave them out, and anyone who wants to use them can create > a new namespace to handle them? > > If you are currently using these elements or have an opinion on how we > should proceed, please speak out. > > -- > Dan Foster
ariestiger+rocketmail.com on Tue Sep 07 17:40:23 2004 (link), replying to msg
Thanks for the help and the direction to the xml site. Found out why I could not call the groundspeak elements and am able to work with it. Thanks for the help.
steve_raffaele+shaw.ca on Thu Sep 09 20:50:37 2004 (link), replying to msg
Here is a quick example of how to extend the GPX_1_0 schema using a Navaid Waypoint Generator File. Note the line starting with xmls:bpt=.... This sets up an extended namespace for the xml (gpx) file so that the custom <bpt:freq>123.3</bpt:freq> can be added. This is the communications frequency of the SANDS RANCH,HAVRE,MT,US airport (not really just an example). This file will work with the GPX_1_0 schema file. You should always add these elements to the end of the list of child elements you are extending. BTW the files generated with Navaid Waypoint Generator won't validate straight out of the box as they have a few elements in the wrong order. This example still has the elements in the wrong order. The file works but it just won't pass a XMLSpy validation. This is only one way to extend an xml schema. There are others! I think this is the simple one. See Yah <?xml version="1.0" ?> - <gpx version="1.0" creator="Navaid Waypoint Generator - http://navaid.com/GPX/" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns="http://www.topografix.com/GPX/1/0" xmlns:bpt="http://gravityinduceddevelopments.com" xsi:schemaLocation="http://www.topografix.com/GPX/1/0"> <author>Paul Tomblin</author> <email>ptomblin+xcski.com</email> <url>http://navaid.com/GPX/</url> <urlname>Navaid Waypoint Generator for GPX</urlname> <wpt lat="48.5374983333333" lon="-109.704923611111"> <ele>792.48</ele> <name>00MT</name> <cmt> <![CDATA[ SANDS RANCH,HAVRE,MT,US]]> </cmt> <src>FAA</src> <type>AIRPORT</type> <bpt:freq>123.3</bpt:freq> </wpt> </gpx> --- In gpsxml+yahoogroups.com, "ariestiger.rm" <ariestiger+r...> wrote: > Thanks for the help and the direction to the xml site. Found out > why I could not call the groundspeak elements and am able to work > with it. Thanks for the help.
davewissenbach+yahoo.com on Fri Sep 10 06:53:47 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "balloon_flyer" <steve_raffaele+s...> wrote: > I, for one, would like to see the changes for <course> and <speed> > implemented in GPX 1_1 as this was a very nice feature in 1_0 and I > would hate to see us go backwards in functionality. Most applications > that generate track files have these elements in place and it would > be a shame to have to extend the schema to get these elements back. > Although it's not extremely difficult to extend the schema (as > goundspeek has done) it's just another step that we will have to go > through to implement tracks as they have been in the past. > > I'm suprised that others havn't tried validating their existing .gpx > files against the new schema yet. Maybe I'm the only one out there > buildin track files in GPX? > An gpx 1.0 file will not validate against the gpx1.1 schema in the very first line, because of the required version="1.1" attribute. I know this because I have validated gpx 1.1 output from Wissenbach Map3D. My approach on compatiblity for Wissenbach Map3D is to read GPX1.0 files but output GPX1.1 files, which most applications should be able to parse and read. For best intoperability we are strict conformists when we write, but don't get pedantic when reading. As far as course and speed, I couldn't care less. But I don't object to these remaining in the format if someone else does care! Dave > See Yah > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Hello, > > > > Someone pointed out to me off-list that <course> and <speed> were > > removed from <trkpt> in GPX 1.1. GPX 1.1 defines <wpt>, <rtept>, > and > > <trkpt> identically. In GPX 1.0, <trkpt> contained these two extra > > elements. > > > > Should we add these elements back into the GPX 1.1 schema? > > Should we leave them out, and anyone who wants to use them can > create > > a new namespace to handle them? > > > > If you are currently using these elements or have an opinion on how > we > > should proceed, please speak out. > > > > -- > > Dan Foster
ptomblin+gmail.com on Sat Sep 11 07:37:48 2004 (link)
I have a site that produces GPX files for aviation related waypoints (http://navaid.com/GPX/). I also produce other types of files for other appiications, such as the CoPilot and GPSPilot applications for Palm OS. Because of that, I have a lot more information available than can be given in the GPX schema, so I was toying with the idea of puting all this extra information in a namespace. My problem is that I know bugger all about XML, and I don't have the time to start reading massive XML references, since I'm trying to work 70 hours a week, maintain my navaid.com site on the side, and learn Python, and have a personal life as well, and if there's any time left over, get some flying in. So I have a few questions: 1. Say I want to create a private name space in my generated file, how do I structure the schema file? 2. Where do I put the schema file so that parsers can find it? 3. Do other programs know to ignore stuff in name spaces that they don't define? 4. I'm currently generating GPX 1.0 - is there any compelling reasons for or against going to the 1.1 schema? Will it break compatibility with any important programs? 5. Does this look like a reasonable way of doing it? Am I interpreting how to do name spaces correctly? <gpx> .... <navaid:tpa>1401</navaid:tpa> <navaid:frequencies> <navaid:frequency type="UNIC" name="UNICOM" frequency="123.7"> <navaid:frequency type="TWR" name="TOWER" frequency="118.3"> </navaid:frequencies> <navaid:runways> <navaid:runway name="7/25" length="2500" width="80" type="ASPH"> </navaid:runways> </gpx> -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
ed+topozone.com on Sat Sep 11 11:46:14 2004 (link)
Paul - I think you'll find folks willing to help, but do you think WE have loads of free time on our hands? We don't have jobs, etc., too? It's considered impolite to jump into a group with "Look, I don't have time to figure this out, so please do it for me". In particular, you need to spend a little while learning the basics of XML (they're not all "massive" references). There's no point in asking people to help you with GPX if you don't take the time to understand the fundamental concepts. It's like asking someone to show you how to play the "Maple Leaf Rag" on the piano because that's all you want to know and you don't really have the time to learn how to play the piano in the first place! - Ed Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 Phone: +1 978 251-4242 Fax: +1 978 251-1396 -----Original Message----- From: Paul Tomblin [mailto:ptomblin+gmail.com] Sent: Saturday, September 11, 2004 10:38 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Help this XML newbie I have a site that produces GPX files for aviation related waypoints (http://navaid.com/GPX/). I also produce other types of files for other appiications, such as the CoPilot and GPSPilot applications for Palm OS. Because of that, I have a lot more information available than can be given in the GPX schema, so I was toying with the idea of puting all this extra information in a namespace. My problem is that I know bugger all about XML, and I don't have the time to start reading massive XML references, since I'm trying to work 70 hours a week, maintain my navaid.com site on the side, and learn Python, and have a personal life as well, and if there's any time left over, get some flying in. So I have a few questions: 1. Say I want to create a private name space in my generated file, how do I structure the schema file? 2. Where do I put the schema file so that parsers can find it? 3. Do other programs know to ignore stuff in name spaces that they don't define? 4. I'm currently generating GPX 1.0 - is there any compelling reasons for or against going to the 1.1 schema? Will it break compatibility with any important programs? 5. Does this look like a reasonable way of doing it? Am I interpreting how to do name spaces correctly? <gpx> .... <navaid:tpa>1401</navaid:tpa> <navaid:frequencies> <navaid:frequency type="UNIC" name="UNICOM" frequency="123.7"> <navaid:frequency type="TWR" name="TOWER" frequency="118.3"> </navaid:frequencies> <navaid:runways> <navaid:runway name="7/25" length="2500" width="80" type="ASPH"> </navaid:runways> </gpx> -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt Yahoo! Groups Links
ptomblin+gmail.com on Sat Sep 11 13:16:26 2004 (link), replying to msg
>It's considered impolite to jump into a group with "Look, I don't have >time to figure this out, so please do it for me". In particular, you I think if you're actually read what I read instead of jumping all over the introduction, I did NOT ask people to "do it for me". I asked some specific questions which should have specific and easily answerable answers. For someone who knows a bit about extending XML schemas, it probably would take less time to answer than you spent flaming me. But never mind, I guess I'll work on improving the CoPilot generator instead. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
ed+topozone.com on Sat Sep 11 13:29:09 2004 (link)
Paul - I read every word you said, and I responded without flaming. I actually contribute virtually nothing to this group (and quite a lot to others), but I try very hard to respect the time of the folks who put in a lot of work themselves, and who also have lots of other pressures on their lives. Before I ask a question (here or anywhere) I think I owe it to others to make a reasonable effort to do my homework. I would visit Google and search for "extending XML schemas", where I would find a number of resources. Then I could come to this group and say "I've looked into this subject and I found X, Y, and Z. I'm trying to do A, and I'm still confused about B, C, and D." - Ed -----Original Message----- From: Paul Tomblin [mailto:ptomblin+gmail.com] Sent: Saturday, September 11, 2004 4:16 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Help this XML newbie >It's considered impolite to jump into a group with "Look, I don't have >time to figure this out, so please do it for me". In particular, you I think if you're actually read what I read instead of jumping all over the introduction, I did NOT ask people to "do it for me". I asked some specific questions which should have specific and easily answerable answers. For someone who knows a bit about extending XML schemas, it probably would take less time to answer than you spent flaming me. But never mind, I guess I'll work on improving the CoPilot generator instead. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt Yahoo! Groups Links
robertlipe+usa.net on Sat Sep 11 16:47:08 2004 (link), replying to msg
> 1. Say I want to create a private name space in my generated file, how > do I structure the schema file? > > 2. Where do I put the schema file so that parsers can find it? Learn by example. Get a sample file from Topografix, Geocaching.com, or anyone else that uses private namespaces. (It'll be evident in the first few lines of the file.) > 3. Do other programs know to ignore stuff in name spaces that they don't define? Yes, in fact that's the whole point. > 4. I'm currently generating GPX 1.0 - is there any compelling reasons > for or against going to the 1.1 schema? Will it break compatibility > with any important programs? I don't know of anything that's 1.1 only at this point. > 5. Does this look like a reasonable way of doing it? Am I > interpreting how to do name spaces correctly? Seems like the right basic idea. Just a couple of days ago, I pointed someone on this very list to a reference on XML namespaces. Check the archives for that post. RJL
Bernd.Sobotka+Fahrradspass.de on Sun Sep 12 03:21:40 2004 (link), replying to msg
> > 4. I'm currently generating GPX 1.0 - is there any compelling reasons > > for or against going to the 1.1 schema? Will it break compatibility > > with any important programs? > > I don't know of anything that's 1.1 only at this point. One GPX 1.1 only element is <copyright>. This is not available in version 1.0. Best regards, Bernd
ptomblin+gmail.com on Sun Sep 12 05:57:26 2004 (link), replying to msg
>From: Robert Lipe <robertlipe+usa.net> > >Just a couple of days ago, I pointed someone on this very list to a >reference on XML namespaces. Check the archives for that post. Yes, I read you post and the reference. What I didn't get out of that is how to make a schema that extends the main schema. Is there a particular way to structure your schema to indicate that it's a namespace within somebody else's, or don't you need to refer back to the other one in any way? Based on the way that reference used both their own schema and an HTML one mixed together, I'm thinking that it's the latter, but I want to be sure. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
ezc4yq41+yahoo.com on Sun Sep 12 14:18:10 2004 (link)
Are you far into debt? I was in the hole over $50,000.00 And now I am getting out of debt FAST! I have money to live. My stress level is lower. Most importantly, my debt is now manageable. For debt relief, copy and past this link into your web-browser. http://moredebt.com/?partid=rcc1 Let the big boys hit for you for a change. Don't let yourself ever be overwhelmed again. Copy and paste this link into your web-browser now http://moredebt.com/?partid=rcc1 Do not miss out, your happiness is more important then overwhelming debt. This email was sent because you joined our group. If you do not wish to receive any emails, unsubscribe. by sending a mail here gpsxml-unsubscribe+yahoogroups.com
davewissenbach+yahoo.com on Sun Sep 12 15:43:33 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > >From: Robert Lipe <robertlipe+u...> > > > >Just a couple of days ago, I pointed someone on this very list to a > >reference on XML namespaces. Check the archives for that post. > > Yes, I read you post and the reference. What I didn't get out of that > is how to make a schema that extends the main schema. Is there a > particular way to structure your schema to indicate that it's a > namespace within somebody else's, or don't you need to refer back to > the other one in any way? > Based on the way that reference used both their own schema and an HTML > one mixed together, I'm thinking that it's the latter, but I want to > be sure. > > > -- <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> <?xml-stylesheet type="text/xsl" href="http://maps.wissenbach.net/gpx/GPX11toHTML.xsl"?><gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="Wissenbach Map3D 2.29" xmlns:wissenbach="http://www.cableone.net/cdwissenbach" xmlns:gpx_style="http://www.topografix.com/GPX/gpx_style/0/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.cableone.net/cdwissenbach http://myweb.cableone.net/cdwissenbach/wissenbach.xsd http://www.topografix.com/GPX/gpx_style/0/1 http://www.topografix.com/GPX/gpx_style/0/1/gpx_style.xsd"> <metadata> This is a snippet from http://maps.wissenbach.net/idaho/BearValleyCreek.gpx Look at lines dealing with gpx_style, and then look up the gps_style schema on the topografix web site. This should be enought to get you started. the xmlns:gpx_style=line sets gpx_style: to be the prefix for the gpx style namepace. Later on you'll see a schemaLocation string pair that relates the namespace to the actual schema file. Dave > "To announce that there must be no criticism of the president, or that we > are to stand by the president, right or wrong, is not only unpatriotic and > servile, but is morally treasonable to the American public." -- Teddy Roosevelt
ptomblin+gmail.com on Sun Sep 12 18:17:17 2004 (link), replying to msg
> xmlns:gpx_style="http://www.topografix.com/GPX/gpx_style/0/1" > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/gpx_style/0/1 > http://www.topografix.com/GPX/gpx_style/0/1/gpx_style.xsd"> > Look at lines dealing with gpx_style, and then look up the gps_style > schema on the topografix web site. This should be enought to get you > started. I can't find gpx_style anywhere on the topografix web site. I tried the urls given in the schemaLocation, and I tried searching their whole site, and I can't find it. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
davewissenbach+yahoo.com on Mon Sep 13 18:28:44 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > > xmlns:gpx_style="http://www.topografix.com/GPX/gpx_style/0/1" > > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > > http://www.topografix.com/GPX/gpx_style/0/1 > > http://www.topografix.com/GPX/gpx_style/0/1/gpx_style.xsd"> > > > Look at lines dealing with gpx_style, and then look up the gps_style > > schema on the topografix web site. This should be enought to get you > > started. > > I can't find gpx_style anywhere on the topografix web site. I tried > the urls given in the schemaLocation, and I tried searching their > whole site, and I can't find it. > Paul, That's strange, because I just clicked on the link in my quoted message above and retrieved and displayed gpx_style.xsd in my web browser. And I assure that I have validated using gpx_style, which means that the Apache xerces parser was able to retrieve style. Dave > -- > "To announce that there must be no criticism of the president, or that we > are to stand by the president, right or wrong, is not only unpatriotic and > servile, but is morally treasonable to the American public." -- Teddy Roosevelt
steve_raffaele+shaw.ca on Tue Sep 14 10:37:44 2004 (link), replying to msg
Paul, I think Davids link to Bear Creek should have taken you to an example of an gpx file that has been extended, just like your trying to do. Unfortunately it takes you to a description of the hike. Try this one... http://maps.wissenbach.net/idaho/PonderosaPark.gpx See Yah Steve --- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > --- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > > >From: Robert Lipe <robertlipe+u...> > > > > > >Just a couple of days ago, I pointed someone on this very list > to a > > >reference on XML namespaces. Check the archives for that post. > > > > Yes, I read you post and the reference. What I didn't get out of > that > > is how to make a schema that extends the main schema. Is there a > > particular way to structure your schema to indicate that it's a > > namespace within somebody else's, or don't you need to refer back > to > > the other one in any way? > > Based on the way that reference used both their own schema and an > HTML > > one mixed together, I'm thinking that it's the latter, but I want > to > > be sure. > > > > > > -- > > <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> > <?xml-stylesheet type="text/xsl" > href="http://maps.wissenbach.net/gpx/GPX11toHTML.xsl"?><gpx > xmlns="http://www.topografix.com/GPX/1/1" > version="1.1" creator="Wissenbach Map3D 2.29" > xmlns:wissenbach="http://www.cableone.net/cdwissenbach" > xmlns:gpx_style="http://www.topografix.com/GPX/gpx_style/0/1" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/1/1/gpx.xsd > http://www.cableone.net/cdwissenbach > http://myweb.cableone.net/cdwissenbach/wissenbach.xsd > http://www.topografix.com/GPX/gpx_style/0/1 > http://www.topografix.com/GPX/gpx_style/0/1/gpx_style.xsd"> > <metadata> > > This is a snippet from > http://maps.wissenbach.net/idaho/BearValleyCreek.gpx > > Look at lines dealing with gpx_style, and then look up the gps_style > schema on the topografix web site. This should be enought to get you > started. > > the xmlns:gpx_style=line sets gpx_style: to be the prefix for the > gpx style namepace. Later on you'll see a schemaLocation string pair > that relates the namespace to the actual schema file. > > Dave > > > "To announce that there must be no criticism of the president, or > that we > > are to stand by the president, right or wrong, is not only > unpatriotic and > > servile, but is morally treasonable to the American public." -- > Teddy Roosevelt
ptomblin+gmail.com on Sat Sep 18 17:48:31 2004 (link)
I have put together a XSD schema file for my extensions to GPX (1.0), and I have an example file that I hope is compliant with it. Is there anybody out there who would volunteer to take a look at the schema and the GPX file and tell me if I'm doing something wrong? The schema file passes the XSD validation at http://apps.gotdotnet.com/xmltools/xsdvalidator/, but when I put the sample file in there as well, it gives me errors about undeclared elements and the like. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
ptomblin+gmail.com on Sat Sep 18 20:00:43 2004 (link)
The schema file is at http://navaid.com/navaid.xsd and the sample file is at http://navaid.com/waypoint.gpx -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
egroups+topografix.com on Mon Sep 20 08:04:05 2004 (link), replying to msg
Hello, Saturday, September 18, 2004, 8:48:28 PM, Paul wrote: P> I have put together a XSD schema file for my extensions to GPX (1.0), P> and I have an example file that I hope is compliant with it. Is there P> anybody out there who would volunteer to take a look at the schema and P> the GPX file and tell me if I'm doing something wrong? P> The schema file is at http://navaid.com/navaid.xsd and the sample file P> is at http://navaid.com/waypoint.gpx If you follow the validation procedure at http://www.topografix.com/gpx_validation.asp with your sample GPX file, you'll see that the first error message returned says that your target namespace is different in the GPX file and in the schema file. I believe the problem is that you are not being consistant in your URI references in the files: http://www.navaid.com vs http://navaid.com A few other comments: You're extending GPX 1.0. You have a better chance of getting others to use your extended data in the future if you go with GPX 1.1. (For example, my GPX 1.0 code is frozen, and I'll only be writing GPX 1.1 from now on) Your extended aviation data schema is probably useful to other programs and companies. Have you thought about involving others in the schema definition? I know that Aeroplanner.com has a similar XML schema - I was involved in its creation in the days before GPX. Overall, it looks good! Let us know if you still have trouble getting your schema to validate properly. -- Dan Foster
ptomblin+gmail.com on Mon Sep 20 10:25:44 2004 (link), replying to msg
On Mon, 20 Sep 2004 13:01:32 -0400, Paul Tomblin <ptomblin+gmail.com> wrote: > I fixed the consistency problem, but SAXCount is still complaining that the > elements navaid:runways and navaid:frequencies are unknown elements. I don't > understand what I'm doing wrong. Ok, I think I've figured it out. SAXCount isn't complaining any more, woo hoo. Thanks for everybody's patience and help. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
ptomblin+gmail.com on Mon Sep 20 10:27:04 2004 (link), replying to msg
From: Dan Foster <egroups+topografix.com> > Saturday, September 18, 2004, 8:48:28 PM, Paul wrote: > > P> I have put together a XSD schema file for my extensions to GPX (1.0), > P> and I have an example file that I hope is compliant with it. Is there > P> anybody out there who would volunteer to take a look at the schema and > P> the GPX file and tell me if I'm doing something wrong? > > P> The schema file is at http://navaid.com/navaid.xsd and the sample file > P> is at http://navaid.com/waypoint.gpx > > If you follow the validation procedure at > http://www.topografix.com/gpx_validation.asp with your sample GPX > file, you'll see that the first error message returned says that your > target namespace is different in the GPX file and in the schema file. > I believe the problem is that you are not being consistant in your > URI references in the files: http://www.navaid.com vs http://navaid.com I fixed the consistency problem, but SAXCount is still complaining that the elements navaid:runways and navaid:frequencies are unknown elements. I don't understand what I'm doing wrong. > You're extending GPX 1.0. You have a better chance of getting others > to use your extended data in the future if you go with GPX 1.1. (For > example, my GPX 1.0 code is frozen, and I'll only be writing GPX 1.1 > from now on) Good point. I was considering going to 1.1, but first I wanted to make sure I knew what I was doing with XML. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
troyh+dirtworld.com on Mon Sep 20 16:45:48 2004 (link)
Howdy, I have a lot of GPX files with either missing chunks of elevation data or that have no elevation data at all. For example, draw a new route in ExpergGPS and it will have no elevation data. Does anyone have a suggestion for how to get this data? I know DEMs have this data, but I don't know how to get this elevation data into my GPX file in bulk. Each file has hundreds, if not thousands of route points so manually doing this isn't much of an option. Thanks in advance. Troy Hopwood
rich+testingrange.com on Mon Sep 20 17:19:58 2004 (link), replying to msg
> Does anyone have a suggestion for how to get this data? I know DEMs > have this data, but I don't know how to get this elevation data into > my GPX file in bulk. Each file has hundreds, if not thousands of route > points so manually doing this isn't much of an option. One way would be to create a perl script using the Geo::GDAL module. Geo::GDAL wraps the GDAL library and allows you access to raster data (ie. DEMs) from Perl. If you have GRASS you can load your DEM's and then write a script to execute r.what commands and capture the result. Assuming you have loaded your data correctly, r.what works like this: r.what input=sf_elevation east_north=549448.3825,4171214.9025 Ie: that will return the value at that coordinate (in UTM). sf_elevation is a DEM layer from the USGS. Good luck with it! Cheers, Rich
davewissenbach+yahoo.com on Mon Sep 20 19:10:34 2004 (link), replying to msg
You can use Wissenbach Map3D for this (If you can find DEMs for your area). Select the trail, and then open the trail information dialog. Check the ground trail to DEM elevation dialog. This will load elevation data from the DEM into the trail. http://myweb.cableone.net/cdwissenbach/maps.html Dave Wissenbach --- In gpsxml+yahoogroups.com, "t_hop99" <troyh+d...> wrote: > Howdy, > > I have a lot of GPX files with either missing chunks of elevation data > or that have no elevation data at all. > > For example, draw a new route in ExpergGPS and it will have no > elevation data. > > Does anyone have a suggestion for how to get this data? I know DEMs > have this data, but I don't know how to get this elevation data into > my GPX file in bulk. Each file has hundreds, if not thousands of route > points so manually doing this isn't much of an option. > > Thanks in advance. > > Troy Hopwood
troyh+dirtworld.com on Tue Sep 21 15:28:16 2004 (link), replying to msg
I tried Wissenback Map3D and had some problems. I opened a GPX file and it drew my route and the terraserver aerial photos. But I couldn't select the trail so the trail menu was always greyed out. If I drew a new route I could then access the trail menu for this. I tried every icon and none seemed to allow me to select the trail. (suggestion add tool tips to the icons). Also, I'm not familiar with the DEM files you're using. I have a DEM file for the region of the trail, but my DEM is called "wenatchee- e.gz" It's zipped, but the file name is the same. Map3D is asking for 047120D4.DEM and possibly others. What are these and any tips for finding them for Washington? Thanks, Troy --- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > You can use Wissenbach Map3D for this (If you can find DEMs for your > area). Select the trail, and then open the trail information dialog. > Check the ground trail to DEM elevation dialog. This will load > elevation data from the DEM into the trail. > > http://myweb.cableone.net/cdwissenbach/maps.html > > Dave Wissenbach > > --- In gpsxml+yahoogroups.com, "t_hop99" <troyh+d...> wrote: > > Howdy, > > > > I have a lot of GPX files with either missing chunks of elevation > data > > or that have no elevation data at all. > > > > For example, draw a new route in ExpergGPS and it will have no > > elevation data. > > > > Does anyone have a suggestion for how to get this data? I know DEMs > > have this data, but I don't know how to get this elevation data > into > > my GPX file in bulk. Each file has hundreds, if not thousands of > route > > points so manually doing this isn't much of an option. > > > > Thanks in advance. > > > > Troy Hopwood
troyh+dirtworld.com on Tue Sep 21 15:31:00 2004 (link), replying to msg
I checked out GRASS and it looks to be a bit over my head. I run Windows so it looks like I would need to run a Unix shell just to run this. Thanks though. Troy --- In gpsxml+yahoogroups.com, Rich Gibson <rich+t...> wrote: > > Does anyone have a suggestion for how to get this data? I know DEMs > > have this data, but I don't know how to get this elevation data into > > my GPX file in bulk. Each file has hundreds, if not thousands of route > > points so manually doing this isn't much of an option. > > One way would be to create a perl script using the Geo::GDAL module. > Geo::GDAL wraps the GDAL library and allows you access to raster data (ie. > DEMs) from Perl. > > If you have GRASS you can load your DEM's and then write a script to > execute r.what commands and capture the result. > > Assuming you have loaded your data correctly, r.what works like this: > r.what input=sf_elevation east_north=549448.3825,4171214.9025 > > Ie: that will return the value at that coordinate (in UTM). sf_elevation > is a DEM layer from the USGS. > > Good luck with it! > > Cheers, > Rich
ptomblin+gmail.com on Tue Sep 21 18:24:57 2004 (link)
I'm trying to convert my data to GPX 1.1. Why is the magvar restricted to 0 - 360 degrees? It's much more traditional to give it as either positive or negative.
egroups+topografix.com on Wed Sep 22 09:26:43 2004 (link), replying to msg
Hello, In GPX 1.1, all major types (gpx, wpt, trk, trkseg, etc) have an <extensions> element which provides a common place to put your own extensions to the GPX schema. I believe we should have added <extensions> to every complex type in GPX 1.1 (and in any private or public namespaces that use it). Consider how you can link a photo to a tracklog in GPX 1.1: <gpx> <trk> <link href="http..."> <text>My Photo</text> <type>image/jpeg</type> </link> ... Now try to give the photo link a lat/lon position showing exactly where along the track it was taken (assume it isn't on a trackpoint). You can't do it in GPX 1.1 without creating your own type that wraps the <link>, and if you do that, no other GPX 1.1 program will be able to recognize the generic <link>. What I'd like to be able to do is this: <gpx> <trk> <link href="http..."> <text>My Photo</text> <type>image/jpeg</type> <extensions> <pt lat="42.123" lon="-71.234"> <time>...</time> </pt> </extensions> </link> ... We left <extensions> out of the following GPX 1.1 complex types: copyrightType linkType emailType personType ptType ptsegType boundsType I'd like to see this corrected, along with two other issues that were recently proposed: - add <course> and <speed> back to <trkpt> - change <magvar> range to (-180, 180] Your thoughts? -- Dan Foster
kodiak+phonet.com on Wed Sep 22 19:47:32 2004 (link)
Okay, I'll admit to not following all the threads here.... so don't beat me too hard.... The X in XML stands for extendable, ie extensions So other then defining <extensions> for validation purposes, what is the point of this tag? Or IS that the point? ----- Original Message ----- From: Dan Foster To: gpsxml+yahoogroups.com Sent: Wednesday, September 22, 2004 10:32 AM Subject: [gpsxml] Should all complexTypes have <extensions>? Hello, In GPX 1.1, all major types (gpx, wpt, trk, trkseg, etc) have an <extensions> element which provides a common place to put your own extensions to the GPX schema. I believe we should have added <extensions> to every complex type in GPX 1.1 (and in any private or public namespaces that use it). Consider how you can link a photo to a tracklog in GPX 1.1: <gpx> <trk> <link href="http..."> <text>My Photo</text> <type>image/jpeg</type> </link> ... Now try to give the photo link a lat/lon position showing exactly where along the track it was taken (assume it isn't on a trackpoint). You can't do it in GPX 1.1 without creating your own type that wraps the <link>, and if you do that, no other GPX 1.1 program will be able to recognize the generic <link>. What I'd like to be able to do is this: <gpx> <trk> <link href="http..."> <text>My Photo</text> <type>image/jpeg</type> <extensions> <pt lat="42.123" lon="-71.234"> <time>...</time> </pt> </extensions> </link> ... We left <extensions> out of the following GPX 1.1 complex types: copyrightType linkType emailType personType ptType ptsegType boundsType I'd like to see this corrected, along with two other issues that were recently proposed: - add <course> and <speed> back to <trkpt> - change <magvar> range to (-180, 180] Your thoughts? -- Dan Foster Yahoo! Groups Sponsor ADVERTISEMENT ------------------------------------------------------------------------------ Yahoo! Groups Links a.. To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ b.. To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed]
egroups+topografix.com on Wed Sep 22 20:21:11 2004 (link), replying to msg
Hello, Thursday, September 23, 2004, 11:46:28 PM, Charles wrote: C> The X in XML stands for extendable, ie extensions C> So other then defining <extensions> for validation purposes, what C> is the point of this tag? Or IS that the point? That IS the point. All GPX files have to validate. So the base GPX schema has to have defined points where you can insert your own namespaces. In GPX 1.0, we had the following: http://www.topografix.com/gpx/1/0/gpx.xsd <!-- you can add your own privately defined wpt elements at the end of the wpt --> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" /> This breaks down when more than two namespaces are used, and they refer to one another internally. As I recall, you can create a document that the parser can interpret in two different ways. Search google for "non-deterministic XML" http://www.google.com/search?hl=en&ie=UTF-8&q=non-deterministic+xml By forcing all extensions to be inside <extensions> the parser now has a deterministic schema to work with. -- Dan Foster
carlm+eurobase-systems.com on Thu Sep 23 02:06:15 2004 (link)
Hi Dan, Having working for the last few year on global XML standards for the Banking and Insurance industries. I would make the following comments 1. First content wise I think GPSXML is good and am seriously considering using/extending it for a marine project I'm currently investigating but ....... 2. From an architectural point for view we've all moved away from complex type defined in elements because is make extending a nightmare. Using <any> really only holds you for simple extensions as you point out. The better way of extending a schema to extend at complex type themselves. When building systems around the resulting XML its then very much easier to match your objects to the complex type in a complimentary fashion. 3. It's industry standard these days to abstract all simple types, as this give protection from changes in the underlying types 4. Many XML based systems use the <xs:annotation> and <xs:documents> to assist integration engines as well as developers 5. I noticed that easyGPS produces .gpsx files - to would be more interoperable if these were .xml files 6. For GPSXML to really be useful would it must incorporation processes not just data. IE <wptRequest> <wptResponse> To be fair every XML standard has been where GPSXML is now. To realise some of the things people have mentioned over the last few month it needs to be brought in line with current thinking, methodologies and standards. It's a great start, keep up the good work and if I can help in anyway please ask. Carl _____ From: Dan Foster [mailto:egroups+topografix.com] Sent: 23 September 2004 04:26 To: gpsxml+yahoogroups.com Subject: Re[2]: [gpsxml] Should all complexTypes have <extensions>? Hello, Thursday, September 23, 2004, 11:46:28 PM, Charles wrote: C> The X in XML stands for extendable, ie extensions C> So other then defining <extensions> for validation purposes, what C> is the point of this tag? Or IS that the point? That IS the point. All GPX files have to validate. So the base GPX schema has to have defined points where you can insert your own namespaces. In GPX 1.0, we had the following: http://www.topografix.com/gpx/1/0/gpx.xsd <http://www.topografix.com/gpx/1/0/gpx.xsd> <!-- you can add your own privately defined wpt elements at the end of the wpt --> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" /> This breaks down when more than two namespaces are used, and they refer to one another internally. As I recall, you can create a document that the parser can interpret in two different ways. Search google for "non-deterministic XML" http://www.google.com/search?hl=en <http://www.google.com/search?hl=en&ie=UTF-8&q=non-deterministic+xml> &ie=UTF-8&q=non-deterministic+xml By forcing all extensions to be inside <extensions> the parser now has a deterministic schema to work with. -- Dan Foster Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=129u7aclm/M=295196.4901138.6071305.3001176/D=gr oups/S=1706030390:HM/EXP=1095996073/A=2128215/R=0/SIG=10se96mf6/*http:/compa nion.yahoo.com> click here <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=groups/S= :HM/A=2128215/rand=725859843> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ <http://groups.yahoo.com/group/gpsxml/> * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments. [Non-text portions of this message have been removed]
egroups+topografix.com on Thu Sep 23 10:38:42 2004 (link), replying to msg
Hello, Thursday, September 23, 2004, 5:03:59 AM, Carl wrote: C> 2. From an architectural point for view we've all moved away from C> complex type defined in elements because is make extending a nightmare. C> Using <any> really only holds you for simple extensions as you point out. C> The better way of extending a schema to extend at complex type themselves. C> When building systems around the resulting XML its then very much easier to C> match your objects to the complex type in a complimentary fashion. C> 3. It's industry standard these days to abstract all simple types, as C> this give protection from changes in the underlying types There are a number of people on this mailing list who deal with XML schemas on a daily basis and are involved in the evolution of XML best practices. I'm not one of them. To those of you who are, please contribute to the discussion and help us keep GPX in sync with the latest thinking in XML. Example instance documents and schemas are always useful to illustrate your point, since they give us a common language to work from. C> 4. Many XML based systems use the <xs:annotation> and <xs:documents> to C> assist integration engines as well as developers GPX 1.1 has <xs:annotation> and <xs:documentation> tags, which were used to generate the automatic documentation http://www.topografix.com/gpx/1/1/gpx.xsd http://www.topografix.com/gpx/1/1/ Should we be doing more? C> 5. I noticed that easyGPS produces .gpsx files - to would be more C> interoperable if these were .xml files I got the feeling that most end users want their GPS data files to be distinguishable from other XML files they might encounter. SVG is another example of an XML-based file type that uses its own extension. C> 6. For GPSXML to really be useful would it must incorporation processes C> not just data. IE <wptRequest> <wptResponse> Can you give an example of how this would be used, and how it could be represented? C> To be fair every XML standard has been where GPSXML is now. To realise some C> of the things people have mentioned over the last few month it needs to be C> brought in line with current thinking, methodologies and standards. I agree %100. For those of you on the GPSXML list who are involved with XML best practices on a daily basis, this is your time to step up and contribute. -- Dan Foster
career_venture+yahoo.com on Fri Sep 24 00:12:25 2004 (link)
Hi Friends!!! A leading global provider of Information Technology services in Bangalore, specializing in the design and deployment of leading-edge information management solutions. With offices in 13 countries across the US, Europe, and Asia, and a workforce of over 4,600 experienced information technology and consulting professionals . Request you to kindly send your resume and refer all your friends who might be interested. Kindly apply only if your skill sets meet all of the given criteria in each stipulated requirement. 1. Requrienment I: Java Developer with STRUTS,UML,EJB,XML Educational Qualification:BE/Btech/MCA Experience:4-5 yrs Skill set:Strong in Java,struts,ejb,xml,uml. Location:Bangalore The Requirement is Immediate and the paypackage is very attractive . Kindly Please send as the resume at the earliest.We will be Online in Yahoo Chat ID: deepa_ci for fast communication. Kindly please send as your updated resume at the earliest. With best regards, R.Deepa Career Impact Mail: reach_deepa+career-impact.com Chennai.
davewissenbach+yahoo.com on Sat Sep 25 06:54:33 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "t_hop99" <troyh+d...> wrote: > I tried Wissenback Map3D and had some problems. > > I opened a GPX file and it drew my route and the terraserver aerial > photos. But I couldn't select the trail so the trail menu was always > greyed out. If I drew a new route I could then access the trail menu > for this. I tried every icon and none seemed to allow me to select > the trail. (suggestion add tool tips to the icons). > > Also, I'm not familiar with the DEM files you're using. I have a DEM > file for the region of the trail, but my DEM is called "wenatchee- > e.gz" It's zipped, but the file name is the same. Map3D is asking > for 047120D4.DEM and possibly others. What are these and any tips > for finding them for Washington? > > Thanks, > > Troy > Troy, Mail the gpx file to me and I'll take a look. The .gz extension means that your DEM file has been compressed with the UNIX utility gzip and is therefore not a DEM file without further processing. There is something like the Terraserver for DEM's, the National Elevation Data set, but I haven't figured out how to use it. Anyways, if you want to continue the discussion let's do this offline. Dave > --- In gpsxml+yahoogroups.com, "David S. Wissenbach" > <davewissenbach+y...> wrote: > > You can use Wissenbach Map3D for this (If you can find DEMs for > your > > area). Select the trail, and then open the trail information > dialog. > > Check the ground trail to DEM elevation dialog. This will load > > elevation data from the DEM into the trail. > > > > http://myweb.cableone.net/cdwissenbach/maps.html > > > > Dave Wissenbach > > > > --- In gpsxml+yahoogroups.com, "t_hop99" <troyh+d...> wrote: > > > Howdy, > > > > > > I have a lot of GPX files with either missing chunks of > elevation > > data > > > or that have no elevation data at all. > > > > > > For example, draw a new route in ExpergGPS and it will have no > > > elevation data. > > > > > > Does anyone have a suggestion for how to get this data? I know > DEMs > > > have this data, but I don't know how to get this elevation data > > into > > > my GPX file in bulk. Each file has hundreds, if not thousands of > > route > > > points so manually doing this isn't much of an option. > > > > > > Thanks in advance. > > > > > > Troy Hopwood
ptomblin+gmail.com on Sat Sep 25 15:49:24 2004 (link)
I've put a sample GPX file with my extended schema at http://navaid.com/waypoint.gpx It validates with SAXCount for me, but Steve Raffaele says it doesn't pass XMLSpy. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
jame_smith009+yahoo.com on Tue Sep 28 22:53:37 2004 (link)
DO YOU STILL WANT A CHEAPER CALLING CARD? WHY CHEAPER ?!!! ITS FREE!!! YES! DEAR!!SIGN UP HERE!!! http://www.geocities.com/cyber_ads/my_view.html EARN FREE AS MANY AS U NEED SAY THANKS TO THE LINK
Bernd.Sobotka+Fahrradspass.de on Fri Oct 01 04:30:44 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Wednesday, August 25, 2004, 7:40:51 AM, Steve wrote: > > S> I'd like to see: > S> 1) An easy way to create & publish gpx routes/points, where the creator > S> still has control of the file. > S> 2) An aggregator/portal for finding them. > > We had projects like this in mind when we added these elements to the > <metadata> section of the GPX files: > <bounds> - so you could quickly determine if a GPX file covers your > area of interest > <keywords> - so you could search for specific activities > > I would be very happy to see someone create a search engine or Web > service that catalogued GPX files stored on individual Web sites. > Given a URL to a GPX file on the Web, it would extract the <metadata> > section and store it in a database format. Programs (through a Web > service) and end users (through an HTML form) could then query for > particular waypoints, geocaches, or trails within a geographic area. > > I have a Publish to Web feature for GPX files built into EasyGPS and > ExpertGPS, and I would extend this to allow files to be submitted to a > GPX database as part of the publish process. > > -- > Dan Foster Dan, Currently I am trying to implement a search engine for GPX files (just a hobby). One minor problem I am trying to solve now is how to analyse the "keywords" element. According to the GPX schema all keywords are to be included in one string. This raises the question how the individual keywords are delimited (by blanks, by commas, ...). In my opinion it would make (my) live easier if the keywords element was further structured in a way that it contained an arbitrary number of "keyword" elements, each containing exactly one keyword. I would be interested in your opinion. Thanks and best regards! Bernd
egroups+topografix.com on Fri Oct 01 06:51:40 2004 (link), replying to msg
Hello, Friday, October 1, 2004, 7:29:45 AM, Bernd wrote: B> Currently I am trying to implement a search engine for GPX files B> (just a hobby). One minor problem I am trying to solve now is how to B> analyse the "keywords" element. According to the GPX schema all B> keywords are to be included in one string. This raises the question B> how the individual keywords are delimited (by blanks, by B> commas, ...). B> In my opinion it would make (my) live easier if the keywords element B> was further structured in a way that it contained an arbitrary B> number of "keyword" elements, each containing exactly one keyword. I've only ever seen comma separated values in the <keywords> tag in GPX files. My personal GPX files typically look like this: <keywords>mountain biking, hiking, Massachusetts</keywords> As far as I can tell, XML schema only supports whitespace separated lists, so your proposal to have <keywords> contain one or more <keyword> tags sounds like a good solution. -- Dan Foster
carlm+eurobase-systems.com on Fri Oct 01 07:28:21 2004 (link)
Hi, The question you have to answer is what functionality, in your example, does <keywords> implement. Unless you have a good reason for the grouping keywords together why not just allow <keywords> to appear many times? Generally it is better not to add extra level of elements. For example <....> <keywords>mountain biking</keywords> <keywords>Hiking</keywords> <keywords>Massachusetts</keywords> </...> Is better than <....> <keywords> <keyword>mountain biking</keyword> <keyword>Hiking</keyword> <keyword>Massachusetts</keyword> </keywords> </...> Hope this helps Carl _____ From: Dan Foster [mailto:egroups+topografix.com] Sent: 01 October 2004 14:57 To: Bernd Sobotka Subject: [gpsxml] Re: <keywords> Hello, Friday, October 1, 2004, 7:29:45 AM, Bernd wrote: B> Currently I am trying to implement a search engine for GPX files B> (just a hobby). One minor problem I am trying to solve now is how to B> analyse the "keywords" element. According to the GPX schema all B> keywords are to be included in one string. This raises the question B> how the individual keywords are delimited (by blanks, by B> commas, ...). B> In my opinion it would make (my) live easier if the keywords element B> was further structured in a way that it contained an arbitrary B> number of "keyword" elements, each containing exactly one keyword. I've only ever seen comma separated values in the <keywords> tag in GPX files. My personal GPX files typically look like this: <keywords>mountain biking, hiking, Massachusetts</keywords> As far as I can tell, XML schema only supports whitespace separated lists, so your proposal to have <keywords> contain one or more <keyword> tags sounds like a good solution. -- Dan Foster Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=129sg1lcp/M=295196.4901138.6071305.3001176/D=gr oups/S=1706030390:HM/EXP=1096725102/A=2128215/R=0/SIG=10se96mf6/*http:/compa nion.yahoo.com> click here <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=groups/S= :HM/A=2128215/rand=883331164> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ <http://groups.yahoo.com/group/gpsxml/> * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments. [Non-text portions of this message have been removed]
MtnBiker+linkline.com on Sat Oct 02 12:12:21 2004 (link)
Are there any programs that show the .gpx in a "human-readable" format and allow editing? By human-readable, I mean like a spreadsheet or database. If I understand xml correcly, there are stylesheets that allow the gpx files to be read in a browser (although I haven't done this or quite figured out how the pieces go together. I do understand basic html and CSS). But I want to be able to edit also. MacGPSPro, although it can write gpx, it doesn't show the data. HikeTech is using a proprietary xml. It seems like Excel or a plist editor
commando666_2000+yahoo.com on Mon Oct 04 09:47:30 2004 (link)
Hi My Name is Anchal, and I am new to GPSXML group. I was just wondering if GPSXML is doing anything related to encoding of real-time position (and other) GPS information, and some other design issues. Till now what I know is that GPX can encode waypoints, routes and tracks. Thanks Anchal
jhempy+insightbb.com on Mon Oct 04 09:51:24 2004 (link)
Hello! I'm new to both XML and the GPX schema, so please excuse my question if the answer is blindingly obvious. I'm writing some programs to generate tracks in geometric shapes (circles, circular spirals, etc.). My tracks work just fine in ExpertGPS, but I noticed that the number of digits to the right of the decimal point in my calculated latitude and longitude values exceeds that from points in my downloaded tracks. Is there a required or recommended precision for latitude and longitudes? I checked the GPX 1.1 schema and for longitude I see: Base XSD Type: decimal -180.0 <= value < 180.0 Longitude of the point. Decimal degrees, WGS84 datum. I googled for the phrases "base xsd type decimal" and "wgs84 datum" but the hits were either unrelated to my question or I just plain couldn't comprehend them. Can someone point me to a reference that will describe (in easy terms that a beginner will understand) the required or recommended precision for latitude and longitude values? Thanks a bunch! Janine ps. I'm using Perl under both Linux and Windows to develop my programs, if that makes a difference to where I should look for reference materials.
mebijohn+earthlink.net on Mon Oct 04 10:19:29 2004 (link), replying to msg
Here is a reference for the xml decimal type. http://www.w3.org/TR/xmlschema-2/#decimal -John Janine Hempy a ?it : > > Hello! > > I'm new to both XML and the GPX schema, so please excuse my question > if the answer is blindingly obvious. > > I'm writing some programs to generate tracks in geometric shapes > (circles, circular spirals, etc.). My tracks work just fine in > ExpertGPS, but I noticed that the number of digits to the right of > the decimal point in my calculated latitude and longitude values > exceeds that from points in my downloaded tracks. Is there a > required or recommended precision for latitude and longitudes? > > I checked the GPX 1.1 schema and for longitude I see: > > Base XSD Type: decimal > -180.0 <= value < 180.0 > Longitude of the point. Decimal degrees, WGS84 datum. > > I googled for the phrases "base xsd type decimal" and "wgs84 datum" > but the hits were either unrelated to my question or I just plain > couldn't comprehend them. > > Can someone point me to a reference that will describe (in easy > terms that a beginner will understand) the required or recommended > precision for latitude and longitude values? > > Thanks a bunch! > Janine > > ps. I'm using Perl under both Linux and Windows to develop my > programs, if that makes a difference to where I should look for > reference materials.
davewissenbach+yahoo.com on Mon Oct 04 19:19:25 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Janine Hempy" <jhempy+i...> wrote: > > Hello! > > I'm new to both XML and the GPX schema, so please excuse my question > if the answer is blindingly obvious. > The answer is fairly obvious. The historical definition of the meter is 1 ten-millionth of the distance between the North Pole and the Equator through Paris, France. This is 90 degrees. So 1 meter is 0.000009 degrees. Going with 6 decimal places would give you accuracy down to about 10 centimeters, or four inches, which is probably good enough. You'll need to use double-precision floating point numbers in your calculations and output to get this kind of accuracy. > I'm writing some programs to generate tracks in geometric shapes > (circles, circular spirals, etc.). My tracks work just fine in > ExpertGPS, but I noticed that the number of digits to the right of > the decimal point in my calculated latitude and longitude values > exceeds that from points in my downloaded tracks. Is there a > required or recommended precision for latitude and longitudes? > Let's not have any more hoaxes out there. The Idaho Air National Guard was fooled by a large Hindu Symbol drawn out on the Alvord Desert by Steen's mountain about 10 or 15 years ago. > I checked the GPX 1.1 schema and for longitude I see: > > Base XSD Type: decimal > -180.0 <= value < 180.0 > Longitude of the point. Decimal degrees, WGS84 datum. > > I googled for the phrases "base xsd type decimal" and "wgs84 datum" > but the hits were either unrelated to my question or I just plain > couldn't comprehend them. > > Can someone point me to a reference that will describe (in easy > terms that a beginner will understand) the required or recommended > precision for latitude and longitude values? > Although the answer is obvious, the question isn't. At one time I was outputting single-precision number is GPX with not too good results. Dave > Thanks a bunch! > Janine > > ps. I'm using Perl under both Linux and Windows to develop my > programs, if that makes a difference to where I should look for > reference materials.
ed+topozone.com on Tue Oct 05 06:52:04 2004 (link), replying to msg
Janine - The recommended precision you should use for any measurement is based on the precision of the tools you used to acquire that measurement. It's a property of the measurement, not a property of the value. As an example, in *very* round numbers, one degree is around 100 km (at 40 degrees latitude, a degree of latitude is 111 km and a degree of longitude is 85 km). If you're using a recreational GPS unit under good conditions, the precision of a coordinate measurement might be +/- 10 m. That's 0.0001 degrees (10 m / 100,000 m), so using 4 or 5 decimal places would be appropriate. Using 7 decimal places suggests a precision of one centimeter, which is misleading for that sort of measurement - but which would be perfectly appropriate for a survey-grade GPS measurement. More is not better. Your measurements should be made (in GPX and otherwise) to reflect the precision of the measurement. Careful users of that measurement (along with others) can then use the data and produce output that appropriately reflects the precision of all the inputs. Your calculated geometric shapes are theoretical constructs and you can use an arbitrary degree of precision for them. However, I'd suggest you think about the inputs - if the center of a circle has a precision of 0.0001 degrees, there's no sense in claiming the circumference has any more precision than that. - Ed Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 (978) 251-4242 ed+topozone.com ----- Original Message ----- From: Janine Hempy <jhempy+insightbb.com> To: gpsxml+yahoogroups.com Sent: Mon, 4 Oct 2004 12:50:56 -0400 Subject: [gpsxml] Newbie question: decimal precision > > > Hello! > > I'm new to both XML and the GPX schema, so please excuse my question > if the answer is blindingly obvious. > > I'm writing some programs to generate tracks in geometric shapes > (circles, circular spirals, etc.). My tracks work just fine in > ExpertGPS, but I noticed that the number of digits to the right of > the decimal point in my calculated latitude and longitude values > exceeds that from points in my downloaded tracks. Is there a > required or recommended precision for latitude and longitudes? > > I checked the GPX 1.1 schema and for longitude I see: > > Base XSD Type: decimal > -180.0 <= value < 180.0 > Longitude of the point. Decimal degrees, WGS84 datum. > > I googled for the phrases "base xsd type decimal" and "wgs84 datum" > but the hits were either unrelated to my question or I just plain > couldn't comprehend them. > > Can someone point me to a reference that will describe (in easy > terms that a beginner will understand) the required or recommended > precision for latitude and longitude values? > > Thanks a bunch! > Janine > > ps. I'm using Perl under both Linux and Windows to develop my > programs, if that makes a difference to where I should look for > reference materials. > > > > > > > > Yahoo! Groups Links > > > > > > > >
egroups+topografix.com on Tue Oct 05 10:24:00 2004 (link), replying to msg
Hello, Tuesday, October 5, 2004, 12:11:58 PM, Janine wrote: J> Not all GPS units return data as mine do, or perhaps they don't work with J> ExpertGPS in the same way. Some of them (in particular, two models made by J> Magellan) return route information for what I'd normally see as tracks. I've never heard of a Magellan GPS that sent the breadcrumb history as a route. These aren't MLR receivers, are they? (Feel free to contact me off list if you want to discuss this further) J> Are tracks and routes interchangeable, then, or are there J> specific purposes when one should be used instead of the other? J> As you may remember from my previous post, I'm creating artificial tracks as J> a programming exercise. These tracks are ideal paths to which actual J> traveled paths will be compared. In this paradigm, should I have created J> routes instead of tracks? Here are some guidelines that might help. There are obvious cases where one would be better than the other, but your task seems to fall somewhere in the middle. If the path shows a log of where the receiver actually was (past history), it is a track. If the path is a series of points at which a navigation decision must be made, it's a route. (MapBlast turn-by-turn driving directions, e.g.) If the path describes a trail or road you're going to be following, but there are no navigational decisions to be made at each point, it's a track. (driving down a windy road, e.g.) If having the GPS give you a directional prompt each time you come to a point would be a good thing, it's a route. (You'd probably be navigating from the compass page on your GPS). If you intend to follow the path by just looking at the lines on the map page of your GPS and following along, it's probably a track.
robertlipe+usa.net on Tue Oct 05 10:56:05 2004 (link), replying to msg
Dan's answer is pretty good. Let me suggest another differentiator in real-world usage. We actually allow for these cases in the real world, but most GPSes and file formats make the additional characteristics that: Tracks typically don't have names associated with the individual points. Routes may or may not. Tracks typically have timestamps associated with each point. Routes typically don't. Tracks typically have a bazillion points (2000-10000). Routes are typically constrained to 20-50 points to describe the path. Now in GPX, we are generally expressive enough to not have to obey these limits; they're just guidelines based on existing data models. Internally, can one inherit from the other -and can both inherit from waypoints- since they're both sequenced waypoints? Yep. GPSBabel, for example, represents waypoints, trackpoints, and routepoints the same internally with just a header stuck on the latter to show collection name and linked list pointers and such. RJL
commando666_2000+yahoo.com on Tue Oct 05 16:38:10 2004 (link)
Hello... Please forgive me if my question is little out of order or scope as I am new to GPS and GPX. Till now i read almost all the messages posted in this group and could figure out that GPX basically can be used if the GPS data is available. Is there any way in which any one is using GPX to encode real time data, i.e. get the data in real time and do the further processing as necessary - like updating the map. Thanks Anchal
ngendwkvtuqj+yahoo.com on Sat Oct 09 11:15:31 2004 (link)
Re-finance now, even with bad-credit! *Best Re-finance Rate for credit challenged. *Best Customer Service *Lowest Interest-Rates in Years *SAVE $100-$400 per month Our easy application only takes a minute. http://diplender.com/?partid=rcc2 I posted this on gpsxml, if you dont want to be a member anymore just email gpsxml-unsubscribe+yahoogroups.com
MtnBiker+linkline.com on Wed Oct 13 17:48:02 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Kevin Read <kevinread+m...> wrote: > On 03/10/2004, at 5:12 AM, gregmtnbike wrote: > > > Are there any programs that show the .gpx in a "human-readable" format > > and allow > > editing? By human-readable, I mean like a spreadsheet or database. If > > I understand xml > > correcly, there are stylesheets that allow the gpx files to be read in > > a browser (although I > > haven't done this or quite figured out how the pieces go together. I > > do understand basic > > html and CSS). But I want to be able to edit also. MacGPSPro, although > > it can write gpx, it > > doesn't show the data. HikeTech is using a proprietary xml. It seems > > like Excel or a plist > > editor > > > > try MacSimpleGPS at www.MacSimpleGPS.com > looks like just what you are after > > Kevin Looks like it yes. But editing of tracks with time included is not yet supported and no new versions in over six months. But it's close, but not there.
commando666_2000+yahoo.com on Wed Oct 13 22:09:11 2004 (link)
Hi... I was gong through teh GPX schema 1.1 i didn't quite understand the difference between comments and description... can anyone explain that... Thanks Anchal
rich+testingrange.com on Thu Oct 14 08:33:38 2004 (link), replying to msg
Terrabrowser, http://www.chimoosoft.com/terrabrowser.html, can edit GPX waypoints, but (not yet?) track logs. I wrote a little CGI to analyze GPX files and add speed and distance information: http://www.chimoosoft.com/terrabrowser.html Let us know what you find out! On Thu, 14 Oct 2004, gregmtnbike wrote: > > > --- In gpsxml+yahoogroups.com, Kevin Read <kevinread+m...> wrote: > > On 03/10/2004, at 5:12 AM, gregmtnbike wrote: > > > > > Are there any programs that show the .gpx in a "human-readable" format > > > and allow > > > editing? By human-readable, I mean like a spreadsheet or database. If > > > I understand xml > > > correcly, there are stylesheets that allow the gpx files to be read in > > > a browser (although I > > > haven't done this or quite figured out how the pieces go together. I > > > do understand basic > > > html and CSS). But I want to be able to edit also. MacGPSPro, although > > > it can write gpx, it > > > doesn't show the data. HikeTech is using a proprietary xml. It seems > > > like Excel or a plist > > > editor > > > > > > > try MacSimpleGPS at www.MacSimpleGPS.com > > looks like just what you are after > > > > Kevin > > Looks like it yes. But editing of tracks with time included is not yet supported and no new > versions in over six months. But it's close, but not there. > > > > > > > > > Yahoo! Groups Links > > > > > > >
MtnBiker+linkline.com on Thu Oct 14 10:16:19 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Rich Gibson <rich+t...> wrote: > Terrabrowser, http://www.chimoosoft.com/terrabrowser.html, can edit GPX > waypoints, but (not yet?) track logs. > > I wrote a little CGI to analyze GPX files and add speed and distance > information: > http://www.chimoosoft.com/terrabrowser.html > > Let us know what you find out! > > On Thu, 14 Oct 2004, gregmtnbike wrote: > Your CGI might be handy after I get the gpx editing and the right segments connected. Is there a connection between your CGi and TerraBrowser? I could get a waypoint to display, but not a route, but maybe it's because it's beta. > > > > > > --- In gpsxml+yahoogroups.com, Kevin Read <kevinread+m...> wrote: > > > On 03/10/2004, at 5:12 AM, gregmtnbike wrote: > > > > > > > Are there any programs that show the .gpx in a "human-readable" format > > > > and allow > > > > editing? By human-readable, I mean like a spreadsheet or database. If > > > > I understand xml > > > > correcly, there are stylesheets that allow the gpx files to be read in > > > > a browser (although I > > > > haven't done this or quite figured out how the pieces go together. I > > > > do understand basic > > > > html and CSS). But I want to be able to edit also. MacGPSPro, although > > > > it can write gpx, it > > > > doesn't show the data. HikeTech is using a proprietary xml. It seems > > > > like Excel or a plist > > > > editor > > > > > > > > > > try MacSimpleGPS at www.MacSimpleGPS.com > > > looks like just what you are after > > > > > > Kevin > > > > Looks like it yes. But editing of tracks with time included is not yet supported and no new > > versions in over six months. But it's close, but not there.
rich+testingrange.com on Thu Oct 14 10:45:44 2004 (link), replying to msg
On Thu, 14 Oct 2004, gregmtnbike wrote: > Your CGI might be handy after I get the gpx editing and the right segments connected. Is > there a connection between your CGi and TerraBrowser? I could get a waypoint to display, > but not a route, but maybe it's because it's beta. I have no connection with Terrabrowser...my cgi is just me noodling with GPX, trying to add things that scratch my itches. I'm with you in wanting a table like editing interface. I'd like to use GPX format more fully, but we need editing tools, and processing and statistics, etc for this to work the way I want. Fortunately, I can write code :-) I don't think Terrabrowser can do routes. The original version didn't do track logs, so it is getting better over time... You can mostly translate routes to tracks without losing too much information, as a sort of work around. If you have thoughts on tools that are amenable to simple CGI manipulation then please let me know! Tools that take a GPX file, do something, and return the result are 'easy' for me to write now that I have sort of a framework for dealing with GPX files. Also, gpsbabel is a great tool! The command line works under Windows, Linux, and OSX (the GUI's are basically useless). Cheers, Rich
Bernd.Sobotka+Fahrradspass.de on Thu Oct 14 12:25:10 2004 (link), replying to msg
Hi Anchal, comments are supposed to be transferred to the GPS device. Therefore the cmt element is only available for waypoints, routes, and tracks. Descriptions are supposed to contain a more lengthy textual description of the afore-mentioned elements or of the whole gpx file. Comments are typically shorter than descriptions and one should be careful in using special characters which might lead to unexpected results on the GPS device. Best regards, Bernd --- In gpsxml+yahoogroups.com, "Anchal Jain" <commando666_2000+y...> wrote: > > Hi... > > I was gong through teh GPX schema 1.1 > > i didn't quite understand the difference between comments and > description... > > can anyone explain that... > > Thanks > Anchal
Jochen.Schmidt+t-online.de on Fri Oct 15 00:03:45 2004 (link)
Hi all, I am a new member of this group so please apologize, if this topic has been discussed several times before. What I want to ask, is: Is there any common schema or naming convention for the symbol names used in the gpx-tag <sym> or does it follow any specification like the garmin spec for example found at http://www.garmin.com/support/pdf/iop_chng.pdf (page 36 ff.) Thanks in advancefor your answers Best regards Jochen Schmidt
robertlipe+usa.net on Fri Oct 15 05:38:59 2004 (link), replying to msg
jms_stgt wrote: > I am a new member of this group so please apologize, if this topic > has been discussed several times before. What I want to ask, is: Is I floated this once before, but it's been a while. > there any common schema or naming convention for the symbol names > used in the gpx-tag <sym> or does it follow any specification like > the garmin spec for example found at > http://www.garmin.com/support/pdf/iop_chng.pdf (page 36 ff.) The answer was that since it's a program and receiver independent spec that the contents of that tag are free form. Thus GPX readers have to be liberal in what they accept; "house", "home", and "residence" may all resolve to the same icon, for example. Yeah, it's a drag. RJL
robertlipe+usa.net on Fri Oct 15 08:42:01 2004 (link), replying to msg
Troy Hopwood - DirtWorld.com wrote: > On that note, has anyone compiled a list of known symbol names? i.e. house, > home, residence all being the same thing? Not to be a smart aleck, but based on my experience with 50-odd formats in GPSBabel, it seems like an English Dictionary would be a good starting place until you can get to the other languages. :-) Seriously, I've found no satisfactory cross-reference. Every time I've tried to make one, a version number will bump and double the matrix. If you're preparing content meant for a wide audience, I suggest you be very cautious in what you use and, if at all possible, do mimic the set of someone bigger than you. It's all very icky. RJL
phfgvoueb+yahoo.com on Mon Oct 18 07:20:07 2004 (link)
If you are in debt, consolidate now. There is no amount of debt that is too much or too little. If you are behind on bills we can help. Sleep well and debt free http://grealus.com/adehu please copy and paste the above link into your web-browser. 89% of society is in debt at this current time. If you are in debt we can help you. Let our knowledgeable staff assist you in your time of need. copy and paste the following link into your web browser now http://grealus.com/adghu You must act now. Do not live with any more debt We will clear all of your debt through consolidation. This is your one chance check us out now. http://grealus.com/adfhu Copy and paste the above link into your web browser. Save money consolidate now, this is important. http://grealus.com/adghu This email was sent because you joined our group. If you do not wish to recieve any emails, unsubscribe. by sending a mail here gpsxml-unsubscribe+yahoogroups.com
scabpagiey+yahoo.com on Sun Oct 24 01:44:46 2004 (link)
Re-finance now, even with bad-credit! *Free No Obligation *Best Re-finance Rate for credit challenged. *Best Customer Service *Lowest Interest-Rates in Years *SAVE $100-$400 per month Our easy application only takes a minute. http://grealus.com/azwh1 I posted this on gpsxml, if you dont want to be a member anymore just email gpsxml-unsubscribe+yahoogroups.com
xqwgdxmec+yahoo.com on Tue Oct 26 06:33:43 2004 (link)
This is a one time opportunity. You cannot miss out on interest rates as low as this. All it takes is 30 seconds to start the money saving process. http://grealus.com/atrhu Please copy and paste the above link into your web browser. Do not miss out interest rates have never been lower. http://grealus.com/acwhu This email was sent because you joined our group. If you do not wish to recieve any emails, unsubscribe. by sending a mail here gpsxml-unsubscribe+yahoogroups.com
shelly22_jones+yahoo.com on Wed Oct 27 04:26:58 2004 (link)
WOW! WHAT AN EXCELLANT SITE!WHY DID NOT TELL ME EARLIER DEAR DEAR FRIENDS GET UR FRIENDS on free CALLING CARDS I HAVE RECEIVED THIS LINK FROM A FRIEND OF FREE CALLING CARDS I WAS DOUBTFULL BUT WHEN I GOT THE FIRST CARD I BELEIVED IT NOW I STARTED EARNING FREE WHY NOT YOU ALSO ENJOY THE SAME ITS FREE!!! ITS SIMPLE !!! JUST SIGN IN AND LOG IN AND START EARNING FREE N FREE !!!!FREEEEEEE!!! LINK : http://www.geocities.com/flora_offers/gains.html Dear Moderator This is an informative msg only ,not a spam,you can check and if you are satisfied then only circulate
jame_smith009+yahoo.com on Sat Oct 30 02:12:58 2004 (link)
GET FREE CALLING CARDS AND MAKE LOCAL AND INTERNATIONAL CALLS FREEEE!! FOR DETAILS : SIGN-UP HERE AND CALL ANYWHERE IN THE WORLD FREE http://tinyurl.com/5u6wj I wish to circulate after your check only.
hqukofricu+yahoo.com on Tue Nov 02 11:41:24 2004 (link)
hey all I recently re-financed my mortgage for free even though I have BAD credit. They even gave me a great rate! Take a look at this service... http://grealus.com/azwh1 I posted this on gpsxml, if you dont want to be a member anymore just email gpsxml-unsubscribe+yahoogroups.com
shelly22_jones+yahoo.com on Sun Nov 07 23:50:08 2004 (link)
Hey friends we do not know till now but one of my friends send a link to me it's amazing and its very simple. spend few minutes to earn 100% sure free minutes HERE IS THE LINK :: http://tinyurl.com/6fyoc 100% FREE. SIGNUP!!! Only Name,email and valid address required to sign up!! Hurry!!!! NOTE : don't forgot to send this link to our fellow FRIENDS bye bye http://www.globalfreecalling.com/reg1.asp?refcode=pears __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com [Non-text portions of this message have been removed]
jame_smith009+yahoo.com on Tue Nov 09 02:28:10 2004 (link)
FEEL FREE TO VISIT AND GET FREE CALLINGCARDS AS BONUS. MAKE LOCAL AND INTERNATIONAL CALLS FREE.. SIGN-UP HERE http://tinyurl.com/4cztb I wish to circulate after your check only.
chris.lawless+worktech.com on Tue Nov 09 09:21:33 2004 (link)
Hello! I'm quite new to GPX ad XML and was wondering if I could get some guidance. I am writing a Delphi application that I want to track GPS co-ordinates then write them out to a GPX file. I have looked through the GPX specifications and they are quite intimidating, is there any simplified version I could maybe use if I just want to track the date/time, latitude, longitude, altitude and speed? I am currently storing the captured GPS data in a grid that can automatically write out to XML. This mechanism adds record descriptors in a form shown below. Is this sufficient, with the data appropriately modified, to be a GPX file? <ListDescr> <RecordDescr> <FieldDescr[0]>Cell 0,0</FieldDescr[0]> <FieldDescr[1]>Cell 1,0</FieldDescr[1]> <FieldDescr[2]>Cell 2,0</FieldDescr[2]> </RecordDescr> <RecordDescr> <FieldDescr[0]>Cell 0,1</FieldDescr[0]> <FieldDescr[1]>Cell 1,1</FieldDescr[1]> <FieldDescr[2]>Cell 2,1</FieldDescr[2]> </RecordDescr> </ListDescr> Can anyone send me a simple example of a GPX file containing just waypoints or tracking data? Thanks in advance for any help, Chris.
robertlipe+usa.net on Tue Nov 09 10:14:19 2004 (link), replying to msg
Chris Lawless wrote: > I have looked through the GPX specifications and they are quite > intimidating, They're really not too bad if you speak the basic parlance of navigation and a dash of XML. > is there any simplified version I could maybe use if I just want to > track the date/time, latitude, longitude, altitude and speed? Most of the tags are optional. You can look at the output of many programs, model your code after that, be sure it validates and go from there. (robertl) rjloud:/home/robertl/src/gpsbabel/reference/track $ gpsbabel -i nmea -f nmea -o gpx -F - <?xml version="1.0"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <time>2004-11-09T17:41:02Z</time> <trk> <trkseg> <trkpt lat="42.530485" lon="-88.121722"> <ele>209.800000</ele> <time>2004-08-07T03:29:08Z</time> </trkpt> [ repeats similarly ] <trkpt lat="42.530515" lon="-88.121760"> <ele>221.900000</ele> <time>2004-08-07T03:31:40Z</time> </trkpt> <trkpt lat="42.530517" lon="-88.121758"> <ele>221.400000</ele> <time>2004-08-07T03:31:41Z</time> </trkpt> </trkseg> </trk> </gpx> > Can anyone send me a simple example of a GPX file containing just > waypoints or tracking data? Some are on the web site at http://www.topografix.com/gpx_sample_files.asp but I think the samples have kind of gotten obscured by the viewer thingy demonstrating what CAN be done...
chris.lawless+worktech.com on Tue Nov 09 10:22:44 2004 (link)
It seems a trackpoint is structured like this, from a sample I was kindly sent. Are all of the elements required or are some optional? Also is there any detail available on the formatting required, the date for example seems to be in a curious form, also are the speed and ele (elevation?) in specific units?Chris. 0 183.7 79.3 3d 9 0.8
jame_smith009+yahoo.com on Tue Nov 09 21:05:08 2004 (link)
Hai Friends,this is MONIKA, Believe me...it will change our lifes,it's totally FREE......... Stop buying prepaid cards. Earn your prepaid cards with FREE... REALLY FREE.... HERE IE THE LINK::http://tinyurl.com/3mpl3 No Hastles !!! No risks !!!just sign up and 2 minutes time
egroups+topografix.com on Wed Nov 10 07:15:12 2004 (link), replying to msg
Hello, Wednesday, November 10, 2004, 9:53:25 AM, Janine wrote: J> The schema really helped me out when I got started with the GPX business. J> The big brains on the list are really happy to help, but they respond extra J> fast to questions that contain a quote from the schema. Or so my experience J> has indicated. Yes. You'll get much more help if you show that you've read the relevant parts of the schema. I was surprised about the question regarding elevation units - we've been pretty good about specifying units throughout the spec. The automatic documentation for GPX 1.1 hides it a bit. Click on the little question mark after any tag in the schema documentation. In this case, you'll see "elevation of the trackpoint (in meters)". In general, all GPX objects use the metric system. -- Dan Foster
chris.lawless+worktech.com on Wed Nov 10 09:30:56 2004 (link)
I've been there and well, I've read some of it. I think my main conclusion was that I don't know enough about XML, Schemas and this way of documenting things! Maybe it'll be clearer if I try to outline what I want to achieve. My aim is to build a GPX file that can be uploaded to a graphical tracking web site, www.motionbased.com <http://www.motionbased.com/> or www.gpsvisualizer.com <http://www.gpsvisualizer.com/> to display my track/route. I was sent a sample GPX file which uploads ok to the second site but is refused by the first. Based on this I wrote my software to mimic this file and it does indeed work with the second web site. I then found a GPX file that seems to work with the first site but it will not work with the second. Now I'm starting to get confused, clearly one of the aims of GPX is to be universal and portable so there is some incompatibility here. I think that it's partly differences between the GPX files but, maybe, just as dependent on the content. The services may be looking for some or all of tracks, routes, waypoints. I have no doubts that the schema documentation is very good, very accurate and very detailed, unfortunately I just don't understand it! I'll keep on trying but I feel that sometimes and overview and example of "A route looks like this" or "Here is a simple track file explained" would go an awful long way. Just my 2 cents :-) Chris. _____ From: Janine Hempy [mailto:jhempy+insightbb.com] Sent: Wednesday, November 10, 2004 9:53 AM To: gpsxml+yahoogroups.com Subject: RE: [gpsxml] Track Point Structure Chris, Did anyone direct you to this page yet? http://www.topografix.com/gpx.asp It's got a link to the GPX schema, which (I believe) answers your questions about required vs. optional fields. I'm not sure about units either, so I'm interested in hearing answers to your questions. The schema really helped me out when I got started with the GPX business. The big brains on the list are really happy to help, but they respond extra fast to questions that contain a quote from the schema. Or so my experience has indicated. Happy coding, Janine (a small brain aspiring to be a medium brain) _____ From: Chris Lawless [mailto:chris.lawless+worktech.com] Sent: Tuesday, November 09, 2004 1:27 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Track Point Structure It seems a trackpoint is structured like this, from a sample I was kindly sent. Are all of the elements required or are some optional? Also is there any detail available on the formatting required, the date for example seems to be in a curious form, also are the speed and ele (elevation?) in specific units? <trkpt lat="36.7936383" lon="-121.7836750"> <ele>0</ele> <time>2003-01-31T18:09:44.220Z</time> <course>183.7</course> <speed>79.3</speed> <fix>3d</fix> <sat>9</sat> <hdop>0.8</hdop> </trkpt> Chris. Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=129kiqe7m/M=295196.4901138.6071305.3001176/ D=gr oups/S=1706030390:HM/EXP=1100110964/A=2128215/R=0/SIG=10se96mf6/*http:// comp anion.yahoo.com> click here <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=group s/S= :HM/A=2128215/rand=621385629> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT click here <http://us.ard.yahoo.com/SIG=129rdvt73/M=295196.4901138.6071305.3001176/ D=groups/S=1706030390:HM/EXP=1100184689/A=2128215/R=0/SIG=10se96mf6/*htt p:/companion.yahoo.com> <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=group s/S=:HM/A=2128215/rand=855142740> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]
chris.lawless+worktech.com on Wed Nov 10 09:48:58 2004 (link)
For example, one sample GPX file I have includes track points like this: <trkpt lat="36.9692217" lon="-122.0375267"><ele>22.00</ele><time>2003-01-31T17:42:14.160Z</time> <course>27.0</course><speed>1.1</speed><fix>3d</fix><sat>7</sat><hdop>1. 2</hdop></trkpt>
davewissenbach+yahoo.com on Wed Nov 10 18:04:30 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Chris Lawless" <chris.lawless+w...> wrote: > For example, one sample GPX file I have includes track points like this: > > > > <trkpt lat="36.9692217" > lon="-122.0375267"><ele>22.00</ele><time>2003-01- 31T17:42:14.160Z</time> > <course>27.0</course><speed>1.1</speed><fix>3d</fix><sat>7</sat><hdop >1. > 2</hdop></trkpt> > > > > From what I can tell from the schema here is no speed or course > attributes, have these been created as additional elements? > > > > Chris. > > Well, in gpx 1.0 there was a slot for additional elements in another namespace, after all of the normal output. But what you apparently have is an invalid gpx file. Most applications will read invalid gpx files to avoid creating problems for others, but to be a responsible content generator, you should strictly follow the 1.1 schema and test your output to make sure that this validates against the schema. > > _____ > > From: Janine Hempy [mailto:jhempy+i...] > Sent: Wednesday, November 10, 2004 9:53 AM > To: gpsxml+yahoogroups.com > Subject: RE: [gpsxml] Track Point Structure > > > > Chris, > > Did anyone direct you to this page yet? > http://www.topografix.com/gpx.asp > It's got a link to the GPX schema, which (I believe) answers your > questions > about required vs. optional fields. I'm not sure about units either, so > I'm > interested in hearing answers to your questions. > > The schema really helped me out when I got started with the GPX > business. > The big brains on the list are really happy to help, but they respond > extra > fast to questions that contain a quote from the schema. Or so my > experience > has indicated. > > Happy coding, > Janine > (a small brain aspiring to be a medium brain) > > > > _____ > > From: Chris Lawless [mailto:chris.lawless+w...] > Sent: Tuesday, November 09, 2004 1:27 PM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Track Point Structure > > > It seems a trackpoint is structured like this, from a sample I was > kindly > sent. Are all of the elements required or are some optional? > > Also is there any detail available on the formatting required, the date > for > example seems to be in a curious form, also are the speed and ele > (elevation?) in specific units? > > > <trkpt lat="36.7936383" lon="-121.7836750"> > <ele>0</ele> > <time>2003-01-31T18:09:44.220Z</time> > <course>183.7</course> > <speed>79.3</speed> > <fix>3d</fix> > <sat>9</sat> > <hdop>0.8</hdop> > </trkpt> > > Chris. > > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > <http://us.ard.yahoo.com/SIG=129kiqe7m/M=295196.4901138.6071305.30011 76/ > D=gr > oups/S=1706030390:HM/EXP=1100110964/A=2128215/R=0/SIG=10se96mf6/*http :// > comp > anion.yahoo.com> click here > > <http://us.adserver.yahoo.com/l? M=295196.4901138.6071305.3001176/D=group > s/S= > :HM/A=2128215/rand=621385629> > > > _____ > > Yahoo! Groups Links > > > * To visit your group on the web, go to: > http://groups.yahoo.com/group/gpsxml/ > > > * To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service > <http://docs.yahoo.com/info/terms/> . > > > > > [Non-text portions of this message have been removed] > > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > click here > <http://us.ard.yahoo.com/SIG=129rdvt73/M=295196.4901138.6071305.30011 76/ > D=groups/S=1706030390:HM/EXP=1100184689/A=2128215/R=0/SIG=10se96mf6/* htt > p:/companion.yahoo.com> > > > <http://us.adserver.yahoo.com/l? M=295196.4901138.6071305.3001176/D=group > s/S=:HM/A=2128215/rand=855142740> > > > > _____ > > Yahoo! Groups Links > > * To visit your group on the web, go to: > http://groups.yahoo.com/group/gpsxml/ > > * To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/> . > > > > [Non-text portions of this message have been removed]
chris.lawless+worktech.com on Wed Nov 10 20:11:35 2004 (link)
Great, thanks, I will endeavour to do so. I have some pointers on why my file was being rejected at www.motionbased.com, they validate the data nd do not allow duplicate points. As I am logging data as fast as I can get it I was getting duplicates within my data. So my question is two-fold, firstly does the GPX format specifically prohibit duplicates in any way and am I correct that the GPX format only logs the time down to the second? (The timing issue is the reason I get duplicates, I was initially trying to log the times to the milli-second which avoided duplicates but this seems to be incorrect according to the documentation. Chris. -----Original Message----- From: David S. Wissenbach [mailto:davewissenbach+yahoo.com] Sent: Wed 11/10/2004 9:04 PM To: gpsxml+yahoogroups.com Cc: Subject: [gpsxml] Re: Track Point Structure --- In gpsxml+yahoogroups.com, "Chris Lawless" <chris.lawless+w...> wrote: > For example, one sample GPX file I have includes track points like this: > > > > <trkpt lat="36.9692217" > lon="-122.0375267"><ele>22.00</ele><time>2003-01- 31T17:42:14.160Z</time> > <course>27.0</course><speed>1.1</speed><fix>3d</fix><sat>7</sat><hdop >1. > 2</hdop></trkpt> > > > > From what I can tell from the schema here is no speed or course > attributes, have these been created as additional elements? > > > > Chris. > > Well, in gpx 1.0 there was a slot for additional elements in another namespace, after all of the normal output. But what you apparently have is an invalid gpx file. Most applications will read invalid gpx files to avoid creating problems for others, but to be a responsible content generator, you should strictly follow the 1.1 schema and test your output to make sure that this validates against the schema. > > _____ > > From: Janine Hempy [mailto:jhempy+i...] > Sent: Wednesday, November 10, 2004 9:53 AM > To: gpsxml+yahoogroups.com > Subject: RE: [gpsxml] Track Point Structure > > > > Chris, > > Did anyone direct you to this page yet? > http://www.topografix.com/gpx.asp > It's got a link to the GPX schema, which (I believe) answers your > questions > about required vs. optional fields. I'm not sure about units either, so > I'm > interested in hearing answers to your questions. > > The schema really helped me out when I got started with the GPX > business. > The big brains on the list are really happy to help, but they respond > extra > fast to questions that contain a quote from the schema. Or so my > experience > has indicated. > > Happy coding, > Janine > (a small brain aspiring to be a medium brain) > > > > _____ > > From: Chris Lawless [mailto:chris.lawless+w...] > Sent: Tuesday, November 09, 2004 1:27 PM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Track Point Structure > > > It seems a trackpoint is structured like this, from a sample I was > kindly > sent. Are all of the elements required or are some optional? > > Also is there any detail available on the formatting required, the date > for > example seems to be in a curious form, also are the speed and ele > (elevation?) in specific units? > > > <trkpt lat="36.7936383" lon="-121.7836750"> > <ele>0</ele> > <time>2003-01-31T18:09:44.220Z</time> > <course>183.7</course> > <speed>79.3</speed> > <fix>3d</fix> > <sat>9</sat> > <hdop>0.8</hdop> > </trkpt> > > Chris. > > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > <http://us.ard.yahoo.com/SIG=129kiqe7m/M=295196.4901138.6071305.30011 76/ > D=gr > oups/S=1706030390:HM/EXP=1100110964/A=2128215/R=0/SIG=10se96mf6/*http :// > comp > anion.yahoo.com> click here > > <http://us.adserver.yahoo.com/l? M=295196.4901138.6071305.3001176/D=group > s/S= > :HM/A=2128215/rand=621385629> > > > _____ > > Yahoo! Groups Links > > > * To visit your group on the web, go to: > http://groups.yahoo.com/group/gpsxml/ > > > * To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service > <http://docs.yahoo.com/info/terms/> . > > > > > [Non-text portions of this message have been removed] > > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > click here > <http://us.ard.yahoo.com/SIG=129rdvt73/M=295196.4901138.6071305.30011 76/ > D=groups/S=1706030390:HM/EXP=1100184689/A=2128215/R=0/SIG=10se96mf6/* htt > p:/companion.yahoo.com> > > > <http://us.adserver.yahoo.com/l? M=295196.4901138.6071305.3001176/D=group > s/S=:HM/A=2128215/rand=855142740> > > > > _____ > > Yahoo! Groups Links > > * To visit your group on the web, go to: > http://groups.yahoo.com/group/gpsxml/ > > * To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/> . > > > > [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT click here <http://us.ard.yahoo.com/SIG=129ff7gh3/M=298184.5584357.6650215.3001176/D=groups/S=1706030390:HM/EXP=1100225077/A=2426685/R=0/SIG=11eslo8dq/*http://www.netflix.com/Default?mqso=60185401> <http://us.adserver.yahoo.com/l?M=298184.5584357.6650215.3001176/D=groups/S=:HM/A=2426685/rand=926281229> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]
egroups+topografix.com on Thu Nov 11 04:42:11 2004 (link), replying to msg
Hello Chris, Wednesday, November 10, 2004, 11:15:48 PM, you wrote: C> I have some pointers on why my file was being rejected at >www.motionbased.com, they validate the data nd do not allow duplicate >points. As I am logging data as fast as I can get it I was getting C> >duplicates within my data. C> So my question is two-fold, firstly does >the GPX format specifically prohibit duplicates in any way and am I >correct that the GPX format only logs the time down to the second? >(The timing issue is C> the reason I get duplicates, I was initially >trying to log the times to the milli-second which avoided duplicates >but this seems to be incorrect according to the documentation. The GPX schema says nothing regarding duplicate points. Therefore, they are allowed. If the GPX file passes the validation test (http://www.topografix.com/gpx_validation.asp) then it is a valid GPX file. MotionBased may impose their own limitations on GPX files they accept, but they shouldn't be telling you you have an invalid GPX file if it validates. If they can detect that a point is a duplicate, couldn't they just drop it from the input stream and accept the modified file? You asked about <speed> and <course>. These were present in GPX 1.0, and dropped (inadvertently, by me) in GPX 1.1. Nobody replied to my earlier message about what we should do about them going forward. As Dave W. points out, you can't include them in a valid GPX 1.1 file. -- Dan Foster
chris.lawless+worktech.com on Thu Nov 11 07:07:28 2004 (link)
Thanks for the clarification. To be fair they didn't say it was an invalid GPX file, they said it was not accepted by their system because they do not permit duplicate points. It does seem a little odd though, I'd think they would either allow them or discard the duplicates as the file is loaded, I'll suggest that. I'm very new to this but storing speed and course seems to have value to save calculating them later. My working uploads at motionbased display speed so I assume they must calculate ot from the change in location and time. This seems a lot of work to go to when we could have logged it earlier. For my personal objectives I would like to log speed as it suits my requirements very well. One of my aims is to track a vehicle and later analyse it, the speed is a factor that is of particular interest and as such I'd like to log it in the GPX file if possible. Chris. -----Original Message----- From: Dan Foster [mailto:egroups+topografix.com] Sent: Thu 11/11/2004 7:33 AM To: Chris Lawless Cc: Subject: Re[2]: [gpsxml] Re: Track Point Structure Hello Chris, Wednesday, November 10, 2004, 11:15:48 PM, you wrote: C> I have some pointers on why my file was being rejected at >www.motionbased.com, they validate the data nd do not allow duplicate >points. As I am logging data as fast as I can get it I was getting C> >duplicates within my data. C> So my question is two-fold, firstly does >the GPX format specifically prohibit duplicates in any way and am I >correct that the GPX format only logs the time down to the second? >(The timing issue is C> the reason I get duplicates, I was initially >trying to log the times to the milli-second which avoided duplicates >but this seems to be incorrect according to the documentation. The GPX schema says nothing regarding duplicate points. Therefore, they are allowed. If the GPX file passes the validation test (http://www.topografix.com/gpx_validation.asp) then it is a valid GPX file. MotionBased may impose their own limitations on GPX files they accept, but they shouldn't be telling you you have an invalid GPX file if it validates. If they can detect that a point is a duplicate, couldn't they just drop it from the input stream and accept the modified file? You asked about <speed> and <course>. These were present in GPX 1.0, and dropped (inadvertently, by me) in GPX 1.1. Nobody replied to my earlier message about what we should do about them going forward. As Dave W. points out, you can't include them in a valid GPX 1.1 file. -- Dan Foster Yahoo! Groups Sponsor ADVERTISEMENT click here <http://us.ard.yahoo.com/SIG=129hedc0j/M=298184.5584357.6650215.3001176/D=groups/S=1706030390:HM/EXP=1100263332/A=2426683/R=0/SIG=11eeoolb0/*http://www.netflix.com/Default?mqso=60185400> <http://us.adserver.yahoo.com/l?M=298184.5584357.6650215.3001176/D=groups/S=:HM/A=2426683/rand=271057970> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]
ptomblin+gmail.com on Thu Nov 11 07:35:57 2004 (link)
I have an extended schema with elements such as <navaid:frequency type="DRCO" frequency="123.55" name="REGINA RDO (WOLLASTON LAKE)"/> What do I do if the text in the "name" part needs to have double quotes in them? I've tried escaping them with backslashes the way I'd do in C or perl. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
robertlipe+usa.net on Thu Nov 11 07:57:18 2004 (link), replying to msg
Paul Tomblin wrote: > > I have an extended schema with elements such as > <navaid:frequency type="DRCO" frequency="123.55" name="REGINA RDO > (WOLLASTON LAKE)"/> > > What do I do if the text in the "name" part needs to have double > quotes in them? I've tried escaping them with backslashes the way I'd > do in C or perl. I think this is one of the reasons this style seems out of favor compared to having each subthingy (type, freq, name) in its own tag. <navaid:frequency> <navaid:freq_name>Waldo "the Crusher" Zielmanski</navaid:freq_name> </navaid:frequency> But overriding that, Quotes should be entity encoded when they appear in the data stream by transforming then to " shouldn't they? You might be able to solve this with CDATAs. (Disclaimer, untested idea follows, but it may give you enough to google upon.) Something like: name=<![CDATA[Waldo "the Crusher" Zielmanski]]> That's pretty ugly. (And more likely to blow away underachieving XML parsers.) RJL
molund+gmail.com on Thu Nov 11 09:15:52 2004 (link), replying to msg
If you are logging speed from the GPS, you may find all sorts of wild fluctuations. Calculating speed yourself will allow you to smooth and correct any weirdness in the data. For instance, if you calculate speed as total meters travelled in the past 30 seconds, you will get a much more reliable figure than if you calculate over 1 second, or from one trackpoint to the next. There are trigonometry formulas for calculating the distance between 2 latitude/longitude points. I have yet to find a formula online that is complex enough to be as accurate as my GPS over a known distance. On Thu, 11 Nov 2004 10:11:43 -0500, Chris Lawless <chris.lawless+worktech.com> wrote: > For my personal objectives I would like to log speed as it suits my > requirements very well. One of my aims is to track a vehicle and later > analyse it, the speed is a factor that is of particular interest and as such > I'd like to log it in the GPX file if possible. >
dananderson2+yahoo.com on Thu Nov 11 09:51:21 2004 (link)
I see there was a comment about styles to support line types, colors, and widths earlier this year. I'm curious where current thinking is. Is there a reason "style" (or also line type, color, width, etc.) wasn't added as an optional attribute under tracks (trkType) plus a means of defining "style"?
egroups+topografix.com on Thu Nov 11 10:34:12 2004 (link), replying to msg
Hello, Thursday, November 11, 2004, 12:51:13 PM, Dan A. wrote: d> I see there was a comment about styles to support line types, colors, d> and widths earlier this year. I'm curious where current thinking is. d> Is there a reason "style" (or also line type, color, width, d> etc.) wasn't added as an optional attribute under tracks d> (trkType) plus a means of defining "style"? I didn't get much of a response to my original proposal for a public style and overlay definition, so I've been concentrating on fleshing out my proposal and getting a working implementation into ExpertGPS before bringing it up on the discussion forum again. I think there's general agreement (if silence can be interpreted to be agreement) that line styles ought to be broken out into their own namespace to avoid cluttering up the base GPX definition. In my implementation, I've decided that the GPX <type> element is what controls the style of objects in ExpertGPS. That is, you can define once how <type>Hiking Trail</type> should be displayed, and all trails with that type get that graphic style. My schema proposal is still a work in progress. You can see its current incarnation (which will likely change a bit) at: http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd -- Dan Foster
davewissenbach+yahoo.com on Thu Nov 11 18:34:31 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Thursday, November 11, 2004, 12:51:13 PM, Dan A. wrote: > > d> I see there was a comment about styles to support line types, colors, > d> and widths earlier this year. I'm curious where current thinking is. > > d> Is there a reason "style" (or also line type, color, width, > d> etc.) wasn't added as an optional attribute under tracks > d> (trkType) plus a means of defining "style"? > > I didn't get much of a response to my original proposal for a public > style and overlay definition, so I've been concentrating on fleshing > out my proposal and getting a working implementation into ExpertGPS > before bringing it up on the discussion forum again. > That might be a good strategy. Benevolent dictatorship might be the best way to reach agreement. To see what happens in a pure democracy follow the W3C working group's SVG1.2 discussion. Yikes! Let's not be like those guys. > I think there's general agreement (if silence can be interpreted to be > agreement) that line styles ought to be broken out into their own > namespace to avoid cluttering up the base GPX definition. > > In my implementation, I've decided that the GPX <type> element is what > controls the style of objects in ExpertGPS. That is, you can define > once how <type>Hiking Trail</type> should be displayed, and all > trails with that type get that graphic style. > That's what I currently do in Wissenbach Map3D when outputing SVG - use the type element to select the style, but I wrote that code before you wrote the gpx_style schema, which I think we agree follows the CSS properties fairly closely. Eventually, I want SVG to use CSS type properties, such as those declared in gpx_style. > My schema proposal is still a work in progress. You can see its > current incarnation (which will likely change a bit) at: > http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd > I currently use gpx_style in the track definition in the manner described in my message 543, where I asked for and obtained clarification on how the units of the gpx_style element. For an example of the usage of gpx_style in this manner, see http://www.gpstrailmaps.com/idaho/BogusBasin/BogusBasinSkiResort.gpx I would prefer to keep this usage or something very similar, especially after having asked for and receiving clarification here. One problem with what I've done is that that schema doesn't actually bind an element gpx_style:line as lineType, as far as I can tell. Perhaps we need to work on interoperability a bit. By the way, the 3D view on my current map3d web page is displaying a gpx file created by ExpertGPS. And recently I was sent a gpx file created by a person using Cetus and with a Radio Shack receiver. > -- > Dan Foster
robertlipe+usa.net on Thu Nov 11 19:05:34 2004 (link), replying to msg
David S. Wissenbach wrote: > By the way, the 3D view on my current map3d web page is displaying > a gpx file created by ExpertGPS. And recently I was sent a gpx file > created by a person using Cetus and with a Radio Shack receiver. I've actually been really pleased at the wild and crazy stuff I see users doing with GPX so far. Web portals, trading huts, and like are making good use of GPX. It's opened the doors for letting folks trade their data. There's even a tease that Garmin's nRoute - related to Mapsource, but different - has added GPX, albeit read-only in their most recent beta. RJL
steve_raffaele+shaw.ca on Thu Nov 11 21:42:37 2004 (link), replying to msg
Well, I guess others are now looking for course and speed in their track log elements. I for one would like to, once again, request that these elements be placed back in the schema. I will continue to avoid generating gpx_1_1 files until this happens. 1_0 works great for me and I don't see any reason to give up a very usefull format for something that is less than what I'm used to. I could easily extend the 1_1 schema but why go through the effort when I have a working option. I'm starting a "Bring Back Course and Speed for Tracks" initative. Vote here and get Dan to bring it back! Maybe 1_2? On another note.. I'd like to know if anyone is having problems using a GPX file with VB.net. In the "metadata" element there is a "link" element at the root level of "metadata" and a "link" element at the "author" level within the "metadata" element. This is perfectly legal as per the published .gpx schema. The problem that I have is using a gpx file where both of these elements are populated with a vb.net "ReadXml" command. First a little background on what the "ReadXml" command does. The command takes an xml file, reads the elements and builds a relational table structure (dataset) very similar to a database. This structure comes complete with tables, nested tables, columns and even relationships that can be used later in the code. This command works great and saves the developer a lot of time and effort in building all of these tables and relationships. You simply use the following code and pass the file path (pFileName)? Public Function GetNavComData(ByVal pFileName As String) As DataSet Dim dsData As New DataSet Try dsData.ReadXml(pFileName) Return (dsData) Catch ex As Exception MsgBox("Error: " & ex.Message) End Try End Function The dataset now contains all the tables and columns that make up the xml file. WORKS GREAT ?unless there are two elements with the same name (link) in a parent table (metadata) and child table (author). I've looked into ways around this problem and come up empty handed. What I'm thinking of doing is editing the file on file load to remove one of the "link" elements. KLUDGE I've also noticed that the gpx schema fails a VB.net "ReadSchema" command for the same reason. Anyone know if the gpx_1_1 schema is breaking some kind of XML rule when this kind of nesting occurs? Is there a VB.net setting or parameter I'm missing when it comes to reading the xml file? Thanks Steve --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello Chris, > > Wednesday, November 10, 2004, 11:15:48 PM, you wrote: > > C> I have some pointers on why my file was being rejected at > >www.motionbased.com, they validate the data nd do not allow duplicate > >points. As I am logging data as fast as I can get it I was getting C> > >duplicates within my data. C> So my question is two-fold, firstly does > >the GPX format specifically prohibit duplicates in any way and am I > >correct that the GPX format only logs the time down to the second? > >(The timing issue is C> the reason I get duplicates, I was initially > >trying to log the times to the milli-second which avoided duplicates > >but this seems to be incorrect according to the documentation. > > The GPX schema says nothing regarding duplicate points. Therefore, > they are allowed. If the GPX file passes the validation test > (http://www.topografix.com/gpx_validation.asp) then it is a valid GPX > file. MotionBased may impose their own limitations on GPX files they > accept, but they shouldn't be telling you you have an invalid GPX file > if it validates. If they can detect that a point is a duplicate, > couldn't they just drop it from the input stream and accept the > modified file? > > You asked about <speed> and <course>. These were present in GPX 1.0, > and dropped (inadvertently, by me) in GPX 1.1. Nobody replied to my > earlier message about what we should do about them going forward. > As Dave W. points out, you can't include them in a valid GPX 1.1 file. > > -- > Dan Foster
chris.lawless+worktech.com on Fri Nov 12 03:29:57 2004 (link)
I'm kind of new to this and new here but course and speed seem like a plus to me. I'd also loike to ask if I am correct that time is only logged to the nearest second and if there is a particular reason why this is so, rather than using milliseconds. Chris. -----Original Message----- From: balloon_flyer [mailto:steve_raffaele+shaw.ca] Sent: Fri 11/12/2004 12:42 AM To: gpsxml+yahoogroups.com Cc: Subject: [gpsxml] Re: Track Point Structure Well, I guess others are now looking for course and speed in their track log elements. I for one would like to, once again, request that these elements be placed back in the schema. I will continue to avoid generating gpx_1_1 files until this happens. 1_0 works great for me and I don't see any reason to give up a very usefull format for something that is less than what I'm used to. I could easily extend the 1_1 schema but why go through the effort when I have a working option. I'm starting a "Bring Back Course and Speed for Tracks" initative. Vote here and get Dan to bring it back! Maybe 1_2? On another note.. I'd like to know if anyone is having problems using a GPX file with VB.net. In the "metadata" element there is a "link" element at the root level of "metadata" and a "link" element at the "author" level within the "metadata" element. This is perfectly legal as per the published .gpx schema. The problem that I have is using a gpx file where both of these elements are populated with a vb.net "ReadXml" command. First a little background on what the "ReadXml" command does. The command takes an xml file, reads the elements and builds a relational table structure (dataset) very similar to a database. This structure comes complete with tables, nested tables, columns and even relationships that can be used later in the code. This command works great and saves the developer a lot of time and effort in building all of these tables and relationships. You simply use the following code and pass the file path (pFileName)�?� Public Function GetNavComData(ByVal pFileName As String) As DataSet Dim dsData As New DataSet Try dsData.ReadXml(pFileName) Return (dsData) Catch ex As Exception MsgBox("Error: " & ex.Message) End Try End Function The dataset now contains all the tables and columns that make up the xml file. WORKS GREAT �?�unless there are two elements with the same name (link) in a parent table (metadata) and child table (author). I've looked into ways around this problem and come up empty handed. What I'm thinking of doing is editing the file on file load to remove one of the "link" elements. KLUDGE I've also noticed that the gpx schema fails a VB.net "ReadSchema" command for the same reason. Anyone know if the gpx_1_1 schema is breaking some kind of XML rule when this kind of nesting occurs? Is there a VB.net setting or parameter I'm missing when it comes to reading the xml file? Thanks Steve --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello Chris, > > Wednesday, November 10, 2004, 11:15:48 PM, you wrote: > > C> I have some pointers on why my file was being rejected at > >www.motionbased.com, they validate the data nd do not allow duplicate > >points. As I am logging data as fast as I can get it I was getting C> > >duplicates within my data. C> So my question is two-fold, firstly does > >the GPX format specifically prohibit duplicates in any way and am I > >correct that the GPX format only logs the time down to the second? > >(The timing issue is C> the reason I get duplicates, I was initially > >trying to log the times to the milli-second which avoided duplicates > >but this seems to be incorrect according to the documentation. > > The GPX schema says nothing regarding duplicate points. Therefore, > they are allowed. If the GPX file passes the validation test > (http://www.topografix.com/gpx_validation.asp) then it is a valid GPX > file. MotionBased may impose their own limitations on GPX files they > accept, but they shouldn't be telling you you have an invalid GPX file > if it validates. If they can detect that a point is a duplicate, > couldn't they just drop it from the input stream and accept the > modified file? > > You asked about <speed> and <course>. These were present in GPX 1.0, > and dropped (inadvertently, by me) in GPX 1.1. Nobody replied to my > earlier message about what we should do about them going forward. > As Dave W. points out, you can't include them in a valid GPX 1.1 file. > > -- > Dan Foster Yahoo! Groups Sponsor ADVERTISEMENT click here <http://us.ard.yahoo.com/SIG=129tv6bvv/M=298184.5584357.6650215.3001176/D=groups/S=1706030390:HM/EXP=1100324557/A=2426685/R=0/SIG=11eslo8dq/*http://www.netflix.com/Default?mqso=60185401> <http://us.adserver.yahoo.com/l?M=298184.5584357.6650215.3001176/D=groups/S=:HM/A=2426685/rand=391303720> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]
chris.lawless+worktech.com on Fri Nov 12 03:33:20 2004 (link)
I agree but my approach to software development has always been to provide as many options as possible then let the recipient decide jpw to use them. Having a <speed> parameter obviously does not preclude someone calculating it themselves but it does provide it should it be needed or should they wish to use it. There's no obligation to use a tag just because it is permitted, but if it is not available the choices is gone. Chris. -----Original Message----- From: Michael Olund [mailto:molund+gmail.com] Sent: Thu 11/11/2004 12:15 PM To: gpsxml+yahoogroups.com Cc: Subject: Re: Re[2]: [gpsxml] Re: Track Point Structure If you are logging speed from the GPS, you may find all sorts of wild fluctuations. Calculating speed yourself will allow you to smooth and correct any weirdness in the data. For instance, if you calculate speed as total meters travelled in the past 30 seconds, you will get a much more reliable figure than if you calculate over 1 second, or from one trackpoint to the next. There are trigonometry formulas for calculating the distance between 2 latitude/longitude points. I have yet to find a formula online that is complex enough to be as accurate as my GPS over a known distance. On Thu, 11 Nov 2004 10:11:43 -0500, Chris Lawless <chris.lawless+worktech.com> wrote: > For my personal objectives I would like to log speed as it suits my > requirements very well. One of my aims is to track a vehicle and later > analyse it, the speed is a factor that is of particular interest and as such > I'd like to log it in the GPX file if possible. > Yahoo! Groups Sponsor <http://us.ard.yahoo.com/SIG=1291fjcmb/M=281955.5530326.6602771.3001176/D=groups/S=1706030390:HM/EXP=1100279754/A=2343726/R=0/SIG=12iq8e7g4/*http://clk.atdmt.com/VON/go/yhxxxvon01900091von/direct/01/&time=1100193354418574> <http://us.ard.yahoo.com/SIG=1291fjcmb/M=281955.5530326.6602771.3001176/D=groups/S=1706030390:HM/EXP=1100279754/A=2343726/R=1/SIG=12iq8e7g4/*http://clk.atdmt.com/VON/go/yhxxxvon01900091von/direct/01/&time=1100193354418574> Get unlimited calls to U.S./Canada <http://view.atdmt.com/VON/view/yhxxxvon01900091von/direct/01/&time=1100193354418574> <http://us.adserver.yahoo.com/l?M=281955.5530326.6602771.3001176/D=groups/S=:HM/A=2343726/rand=416438019> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]
egroups+topografix.com on Fri Nov 12 09:06:19 2004 (link), replying to msg
Hello, Friday, November 12, 2004, 12:42:33 AM, balloon_flyer wrote: b> I'm starting a "Bring Back Course and Speed for Tracks" initative. b> Vote here and get Dan to bring it back! Maybe 1_2? There are actually a number of different measurements that users might want to store. We should probably allow all or most of them. course - the direction from startpoint to endpoint heading - the direction your boat is actually pointing bearing - the direction from your current position to the endpoint track - the direction you're actually going (different from heading if there's a cross-current, for example) speed - how fast your wheels, screws, propellers are turning speed over ground - how fast you're actually moving (factoring in currents) Some of these can be calculated after the fact using distance/speed/time calculations. Others are direct measurements from the compass and tachometer on your craft. I haven't read any arguments against having course and speed be expressable in GPX. I'd like to see it possible to express them. I'm not convinced they belong in the main GPX schema, though. (In line with my current thinking that very very little belongs in the main schema) I'd like to see a major gutting of wptType in GPX 1.2, and I'd like to see a separate trkptType created for tracks. Currently wptType is used for waypoints (good), routes (good - they are composed of waypoints), and tracks (bad, IMO). In GPX 1.0, trackpoints were identical to waypoints, but they had two additional elements (course and speed). I failed to remember that in GPX 1.1 and mistakenly combined the two types, thinking they were identical. I'd like to see us take a broad look at what's currently missing from GPX that should be added, and what's currently in GPX 1.1 that should be changed or moved. I think some general categories of data will emerge, and we can consider grouping similar items together in separate schemas, much as we're doing for line-drawing and stylistic stuff. At the same time, I'd like to revive the discussion about how changes to the schemas should be proposed, discussed, and adopted, so that developers can have a timeline for adopting new GPX schemas into their product schedules. Some suggested additions I've heard so far: nautical direct measurements at each trackpoint: engine speed, heading, depth, temperature calculated values at each trackpoint: distance, bearing, speed over ground, grade, etc. measured athlete data at each trackpoint: heartrate calculated athlete data: calories burned, etc. public schema for aviation: Paul Tomblin's schema, AeroPlanner.com schema change <magvar> range to (-180, 180] Add <extensions> to the following GPX 1.1 complex types: copyrightType linkType emailType personType ptType ptsegType boundsType (see my email on 22 Sept, 2004) Proximity waypoints Real-time tracking info Maybe all of these things can get lumped into their own schemas and can be made to work with the existing GPX 1.1 schema. More likely, we'll find some minor changes to the main 1.1 schema need to be made. It would be very helpful to get as many proposed additions out in the open now, so we can try to propose a solution that handles all of them. -- Dan Foster
robertlipe+usa.net on Fri Nov 12 09:31:23 2004 (link), replying to msg
Dan Foster wrote: > It would be very helpful to get as many proposed additions out in the > open now, so we can try to propose a solution that handles all of > them. I don't have a specific proposal (and am unlikely to lead one) but let me toss out that there are at least four geocaching gpx/xml mutants in the wild or in development. Without someone to drive a standardization, it's unlikely to happen, but I wanted to toss that out here. So far, they've all been seemingly happy to do their own private namespace thing. RJL
ed+topozone.com on Fri Nov 12 09:35:06 2004 (link)
Troy - Here's one, and just in time for that Christmas wish-list! http://www.timex.com/bin/detail.tmx?item=048148595514 - Ed Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 ed+topozone.com (978) 251-4242 -----Original Message----- From: Troy Hopwood - DirtWorld.com [mailto:troyh+dirtworld.com] Sent: Friday, November 12, 2004 12:25 PM To: gpsxml+yahoogroups.com Subject: RE: [gpsxml] Course, speed, and all the other GPX changes Forgive my ignorance, but why on earth would you want to add things like heart rate, engine speed, depth, etc.? GPX is about global positioning and no GPS device I know of tells me my heart rate. If developers want to combine non-GPS data with their GPS data they are welcome to do so by extending the GPX format to fit their unique needs. Rather than trying to come up with a spec that will work for everyone in every scenario, GPX should be a solid base that works for GPS and mapping needs. Then the focus should be getting corporate support. Getting Garmin, Delorme, and or Topo to support GPX will go a long ways toward legitimizing this format. Troy Hopwood _____ From: Dan Foster [mailto:egroups+topografix.com] Sent: Friday, November 12, 2004 9:06 AM To: balloon_flyer Subject: [gpsxml] Course, speed, and all the other GPX changes Hello, Friday, November 12, 2004, 12:42:33 AM, balloon_flyer wrote: b> I'm starting a "Bring Back Course and Speed for Tracks" initative. b> Vote here and get Dan to bring it back! Maybe 1_2? There are actually a number of different measurements that users might want to store. We should probably allow all or most of them. course - the direction from startpoint to endpoint heading - the direction your boat is actually pointing bearing - the direction from your current position to the endpoint track - the direction you're actually going (different from heading if there's a cross-current, for example) speed - how fast your wheels, screws, propellers are turning speed over ground - how fast you're actually moving (factoring in currents) Some of these can be calculated after the fact using distance/speed/time calculations. Others are direct measurements from the compass and tachometer on your craft. I haven't read any arguments against having course and speed be expressable in GPX. I'd like to see it possible to express them. I'm not convinced they belong in the main GPX schema, though. (In line with my current thinking that very very little belongs in the main schema) I'd like to see a major gutting of wptType in GPX 1.2, and I'd like to see a separate trkptType created for tracks. Currently wptType is used for waypoints (good), routes (good - they are composed of waypoints), and tracks (bad, IMO). In GPX 1.0, trackpoints were identical to waypoints, but they had two additional elements (course and speed). I failed to remember that in GPX 1.1 and mistakenly combined the two types, thinking they were identical. I'd like to see us take a broad look at what's currently missing from GPX that should be added, and what's currently in GPX 1.1 that should be changed or moved. I think some general categories of data will emerge, and we can consider grouping similar items together in separate schemas, much as we're doing for line-drawing and stylistic stuff. At the same time, I'd like to revive the discussion about how changes to the schemas should be proposed, discussed, and adopted, so that developers can have a timeline for adopting new GPX schemas into their product schedules. Some suggested additions I've heard so far: nautical direct measurements at each trackpoint: engine speed, heading, depth, temperature calculated values at each trackpoint: distance, bearing, speed over ground, grade, etc. measured athlete data at each trackpoint: heartrate calculated athlete data: calories burned, etc. public schema for aviation: Paul Tomblin's schema, AeroPlanner.com schema change <magvar> range to (-180, 180] Add <extensions> to the following GPX 1.1 complex types: copyrightType linkType emailType personType ptType ptsegType boundsType (see my email on 22 Sept, 2004) Proximity waypoints Real-time tracking info Maybe all of these things can get lumped into their own schemas and can be made to work with the existing GPX 1.1 schema. More likely, we'll find some minor changes to the main 1.1 schema need to be made. It would be very helpful to get as many proposed additions out in the open now, so we can try to propose a solution that handles all of them. -- Dan Foster Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=129uf7a3c/M=298184.5584357.6650215.3001176/D=gr oups/S=1706030390:HM/EXP=1100365581/A=2426685/R=0/SIG=11eslo8dq/*http:/www.n etflix.com/Default?mqso=60185401> click here <http://us.adserver.yahoo.com/l?M=298184.5584357.6650215.3001176/D=groups/S= :HM/A=2426685/rand=291646108> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed] Yahoo! Groups Links
rich+testingrange.com on Fri Nov 12 10:26:17 2004 (link), replying to msg
On Fri, 12 Nov 2004, Dan Foster wrote: > I'd like to see a major gutting of wptType in GPX 1.2, and I'd like to > see a separate trkptType created for tracks. Currently wptType is > used for waypoints (good), routes (good - they are composed of > waypoints), and tracks (bad, IMO). In GPX 1.0, trackpoints were > identical to waypoints, but they had two additional elements (course > and speed). I failed to remember that in GPX 1.1 and mistakenly > combined the two types, thinking they were identical. Personally I don't think there is anything different about a wptType and a trkptType - anything that you might want to know about a waypoint you may want to know about a track point, and anything you might want to know about a track point (including course, speed, bearing, etc), could reasonably apply to a number of uses of waypoints. I accept the argument that many uses of waypoints don't require speed, and even that for many uses of a waypoint a 'speed' is absurd, but it doesn't hurt a user of waypoint data that another user of waypoints might use speed, or course... And it seems that simplifying the model by providing one type of 'point' makes sense. Cheers, Rich
egroups+topografix.com on Fri Nov 12 10:52:19 2004 (link), replying to msg
Hello, Friday, November 12, 2004, 12:25:00 PM, Troy wrote: T> Forgive my ignorance, but why on earth would you want to add things like T> heart rate, engine speed, depth, etc.? I'll fight tooth and nail along side you to make sure heart rate never gets added to the main GPX schema. But if you look at what's happening in the endurance training market right now, you'll realize that heart rate data combined with position, speed, and elevation data (from GPS) is going to be the next big thing in personal training. T> GPX is about global positioning and no GPS device I know of tells me my T> heart rate. If developers want to combine non-GPS data with their GPS data T> they are welcome to do so by extending the GPX format to fit their unique T> needs. If we can provide an opportunity for various equipment manufacturers (Ed gave you a link to Timex' offering) and Web training sites (try http://www.trainingpeaks.com or http://www.motionbased.com ) to come together and create a vendor-neutral schema for heart rate data - why shouldn't we? As a programmer, I'd rather deal with one public schema for heart rate than have to deal with each vendor's private extensions. Of course, if heart rate doesn't concern you or your application, you can ignore it and any schema that emerges. I'm ignoring it for now, but I suspect my customers will be clamoring for it within a year. T> Rather than trying to come up with a spec that will work for everyone in T> every scenario, GPX should be a solid base that works for GPS and mapping T> needs. We're pretty much there, right? Where should we go from here? Rather than shut the mailing list down and let people extend the schema on their own, why not let smaller groups find each other and work on creating sub-schemas to handle stuff that's related to, but not directly associated with, the traditional GPS position/speed/elevation/time. T> Then the focus should be getting corporate support. Getting Garmin, Delorme, T> and or Topo to support GPX will go a long ways toward legitimizing this T> format. The most convincing way I know to do this is to present them with a set of schemas that handle 100% of the things they want to express. Topo! has colored tracks. Can GPX do this? (that's the purpose of my gpx_style sub-schema) Garmin just introduced temperature logging for trackpoints. Can GPX do this? Honestly, I thought GPX 1.1 would be the final revision of the main GPX schema, and at this point there would be nothing to do but work on related public schemas. I've been focusing on the map drawing features that Topo!, OziExplorer, and other mapping programs would insist on before adopting GPX. In doing so, I've come across a few things that lead me to believe a GPX 1.2 revision will be needed. I realize how disruptive it is to switch to a new version, so if we really do need to make some changes in the future, I'd rather get them all worked out and lump them all together instead of dealing with them one at a time as people discover them. -- Dan Foster
Bernd.Sobotka+Fahrradspass.de on Sat Nov 13 06:34:35 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Wednesday, August 25, 2004, 7:40:51 AM, Steve wrote: > > S> I'd like to see: > S> 1) An easy way to create & publish gpx routes/points, where the creator > S> still has control of the file. > S> 2) An aggregator/portal for finding them. > > We had projects like this in mind when we added these elements to the > <metadata> section of the GPX files: > <bounds> - so you could quickly determine if a GPX file covers your > area of interest > <keywords> - so you could search for specific activities > > I would be very happy to see someone create a search engine or Web > service that catalogued GPX files stored on individual Web sites. > Given a URL to a GPX file on the Web, it would extract the <metadata> > section and store it in a database format. Programs (through a Web > service) and end users (through an HTML form) could then query for > particular waypoints, geocaches, or trails within a geographic area. > > I have a Publish to Web feature for GPX files built into EasyGPS and > ExpertGPS, and I would extend this to allow files to be submitted to a > GPX database as part of the publish process. > > -- > Dan Foster Hello, Recently I finished the implementation of my search engine for gpx files. It stores the url together with the metadata elements in a database and offers the basic search funtionality. You find it here: http://www.fahrradspass.de/index.htm I am going to extend it from time to time. Therefore I would be interested in any comments from the gpx community. Also I am always looking for new file to store. Best regards, Bernd
molund+gmail.com on Sat Nov 13 08:37:57 2004 (link), replying to msg
Is there an English URL? On Sat, 13 Nov 2004 14:33:51 -0000, Bernd Sobotka <bernd.sobotka+fahrradspass.de> wrote: > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Hello, > > > > Wednesday, August 25, 2004, 7:40:51 AM, Steve wrote: > > > > S> I'd like to see: > > S> 1) An easy way to create & publish gpx routes/points, where the > creator > > S> still has control of the file. > > S> 2) An aggregator/portal for finding them. > > > > We had projects like this in mind when we added these elements to > the > > <metadata> section of the GPX files: > > <bounds> - so you could quickly determine if a GPX file covers your > > area of interest > > <keywords> - so you could search for specific activities > > > > I would be very happy to see someone create a search engine or Web > > service that catalogued GPX files stored on individual Web sites. > > Given a URL to a GPX file on the Web, it would extract the > <metadata> > > section and store it in a database format. Programs (through a Web > > service) and end users (through an HTML form) could then query for > > particular waypoints, geocaches, or trails within a geographic > area. > > > > I have a Publish to Web feature for GPX files built into EasyGPS > and > > ExpertGPS, and I would extend this to allow files to be submitted > to a > > GPX database as part of the publish process. > > > > -- > > Dan Foster > > Hello, > > Recently I finished the implementation of my search engine for gpx > files. It stores the url together with the metadata elements in a > database and offers the basic search funtionality. You find it here: > http://www.fahrradspass.de/index.htm > > I am going to extend it from time to time. Therefore I would be > interested in any comments from the gpx community. Also I am always > looking for new file to store. > > Best regards, > Bernd > > > > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > > ________________________________ > Yahoo! Groups Links > > To visit your group on the web, go to: > http://groups.yahoo.com/group/gpsxml/ > > 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.
Bernd.Sobotka+Fahrradspass.de on Sat Nov 13 09:28:30 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Michael Olund <molund+g...> wrote: > Is there an English URL? > > Good point! I just translated the page into English. So most people should now be able to read it. Best regards Bernd
dananderson2+yahoo.com on Sun Nov 14 20:29:57 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Thursday, November 11, 2004, 12:51:13 PM, Dan A. wrote: > > d> I see there was a comment about styles to support line types, colors, > d> and widths earlier this year. I'm curious where current thinking is. > > d> Is there a reason "style" (or also line type, color, width, > d> etc.) wasn't added as an optional attribute under tracks > d> (trkType) plus a means of defining "style"? > > I didn't get much of a response to my original proposal for a public > style and overlay definition, so I've been concentrating on fleshing > out my proposal and getting a working implementation into ExpertGPS > before bringing it up on the discussion forum again. > > I think there's general agreement (if silence can be interpreted to be > agreement) that line styles ought to be broken out into their own > namespace to avoid cluttering up the base GPX definition. > > In my implementation, I've decided that the GPX <type> element is what > controls the style of objects in ExpertGPS. That is, you can define > once how <type>Hiking Trail</type> should be displayed, and all > trails with that type get that graphic style. > > My schema proposal is still a work in progress. You can see its > current incarnation (which will likely change a bit) at: > http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd > > -- > Dan Foster Thanks for your response. Sorry I'm so slow to respond. I've just started looking at the schema and I'm not up to speed yet. A couple of items: What is the units of "width"? I see Dave W. has used "0.500000". I'm not clear on the "dasharrayType". My first thought was that it specified the length of a "dash" then the length of "whitespace", etc. for the length of a repeating pattern. I'm trying to get a "maps on CD" product done. I would really like to supply a GPX file with "line types" that could be read by the mapping programs as they add support for GPX. I'm glad to see that you've specified as much as you have and I'd like to encourage completing it. Just as a "for instance" I currently have the following types: Name Line Type Color Size Road Major Solid Black 7 Road Main Solid Black 5 Road Minor/Secondary Solid Black 4 Road Local Dash Black 3 Road Paved Solid Black 4 Road Gravel/Dirt Solid Black 3 Road High Clearance Dash Gray 3 Road 4WD Dash Gray 3 Road Old Dot Black 3 Road Service/Utility Dash Black 3 Parking Lot Outline Dot Black 3 Misc., Other Road Dot Black 3 Trail Multipurpose Solid Green 4 Trail Double Track Solid Purple 3 Trail Primary/Single Dash Purple 3 Trail Secondary Solid Red 3 Trail Primitive Dash Red 2 Cross Country Route Dot Red 3 Misc., Other Trail Dot Black 3 Boundary Dot Navy 3 Regards, Dan A.
egroups+topografix.com on Mon Nov 15 07:49:15 2004 (link), replying to msg
Hello, Friday, November 12, 2004, 12:25:00 PM, Troy wrote: T> The focus should be getting corporate support. Getting Garmin, Delorme, T> and or Topo to support GPX will go a long ways toward legitimizing this T> format. Garmin has added support for GPX 1.1 in the latest MapSource beta. http://www.garmin.com/support/download_details.jsp?id=625 The only issue I've discovered so far is that they aren't including the schemaLocation in the <gpx> tag, so their GPX files don't pass the validator. Hopefully it will be corrected soon. -- Dan Foster
egroups+topografix.com on Mon Nov 15 08:10:29 2004 (link), replying to msg
Hello, Friday, November 12, 2004, 1:25:43 PM, Rich wrote: R> Personally I don't think there is anything different about a wptType and a R> trkptType - anything that you might want to know about a waypoint you may R> want to know about a track point, and anything you might want to know R> about a track point (including course, speed, bearing, etc), could R> reasonably apply to a number of uses of waypoints. R> I accept the argument that many uses of waypoints don't require speed, and R> even that for many uses of a waypoint a 'speed' is absurd, but it doesn't R> hurt a user of waypoint data that another user of waypoints might use R> speed, or course... I haven't been able to think of a reason why someone might want to associate speed or course with a waypoint. Can anyone give an example? Is anyone putting speed or course in their output now? R> And it seems that simplifying the model by providing one type of 'point' R> makes sense. True, but we seem to have created the generic model point from the intersection of waypoint and trackpoint attributes, rather than the union. From an object-oriented viewpoint, it makes more sense to me to create a base point type, and add stuff onto that, rather than having a "kitchen-sink" point type that contains all the stuff that any subtype could possibly have associated with it. You'll notice I started using a <pt> type in the gpx_overlay schema which is as bare-bones as it can be. Maybe we should have started with that as a base for our other point types. This would be a good time for one of you XML design pattern gurus to step in... I'd be curious to know how much actual overlap there is in GPX programs that are out there now between optional elements for waypoints and trackpoints. Are people giving trackpoints name, comment, and description? Are waypoints getting hdop, speed, and course? I'm no longer treating routes and tracks as interchangable in the next version of ExpertGPS. Trackpoints will only contain lat/lon, elevation, and timestamp. My waypoints do not contain any speed or accuracy information. -- Dan Foster
egroups+topografix.com on Mon Nov 15 09:11:00 2004 (link), replying to msg
Hello, Saturday, November 13, 2004, 9:33:51 AM, Bernd wrote: B> Recently I finished the implementation of my search engine for gpx B> files. It stores the url together with the metadata elements in a B> database and offers the basic search funtionality. You find it here: B> http://www.fahrradspass.de/index.htm B> I am going to extend it from time to time. Therefore I would be B> interested in any comments from the gpx community. Also I am always B> looking for new file to store. That's very cool! Is there a form we can use to add our own GPX files to the database? -- Dan Foster TopoGrafix - GPS Software, Waypoints, and Maps http://www.topografix.com - mailto:egroups+topografix.com
rich+testingrange.com on Mon Nov 15 09:43:04 2004 (link), replying to msg
> R> I accept the argument that many uses of waypoints don't require speed, and > R> even that for many uses of a waypoint a 'speed' is absurd, but it doesn't > R> hurt a user of waypoint data that another user of waypoints might use > R> speed, or course... > > I haven't been able to think of a reason why someone might want to > associate speed or course with a waypoint. Can anyone give an > example? Is anyone putting speed or course in their output now? Sure...I have a case :-) Schuyler and I wrote a (trivial) program to allow us to do easy geoannotation. We have gpsd running, and we can annotate a point with either a single keystroke, or by entering a line of text followed by an enter. This lets us do fun stuff easily like making note of interesting features, and creating spatially enabled narratives, and creating custom route maps (say for special events, races, rallies, etc) And in this context, if I am going north or south (or any of those other 358 directions) can be totally relevant. So, say I am creating a route map, then being able to type "You will see a large sign on the right" is a lot more relevant if I can tell which way I was going at the time. Or coding automatic images...say I have a camera pointing out the front of the car, then I can encode the picture information in a GPX waypoint. If I then have my course my life is easier. I also geocode audio files created from a small voice recorder. This is effectively the same geoannotation issue...but even worse since I can be more verbose on the recorder :-) > R> And it seems that simplifying the model by providing one type of 'point' > R> makes sense. > > True, but we seem to have created the generic model point from the > intersection of waypoint and trackpoint attributes, rather than the > union. I won't argue about object-oriented viewpoints, since ultimately that is an ontological argument and while I agree that there are some 'right' and 'wrong' answers, mostly it is shades of grey. I will say that I like the idea of a 'point' being the union of waypoint and trackpoint attributes, since I personally just don't see a distinction between the two. Or rather, the distinction I see is at the next level of containment. The difference between a waypoint and a trackpoint is that a trackpoint is contained within a track segment. Though...when thinking about ways to group waypoints I wish for a 'trip' type that contains waypoints within a trip oriented context... Cheers, Rich
egroups+topografix.com on Mon Nov 15 10:45:03 2004 (link), replying to msg
Hello, Sunday, November 14, 2004, 11:29:45 PM, Dan A. wrote: d> What is the units of "width"? I see Dave W. has used "0.500000". That's the big question. This is a problem we need to solve so we can properly describe a number of things, like the width of a line or the height of a row of text. There are two approaches to a solution. One is to interpret width to be the actual physical dimension of the object on the Earth. So your Gravel Road might be 3 meters wide. <width>3.0</width> Some programs work this way internally, scaling the width of the line they draw on the map so it always overs 3 meters of ground at any scale. SVG is implemented this way now. Of course, if you zoom out to a country-level map, that gravel road is going to be too thin to actually see. The "physical dimensions" approach breaks down a bit when trying to apply it to completely non-physical things like font-height. Which programs act this way internally? SVG 1.0, 1.1 Many vector-based mapping programs future versions of ExpertGPS The second approach is to define a line width in terms of millimeters on the display device (or pixels, or some other unit that isn't related to a physical measurement of the object being modeled). So your Gravel Road might be 4.2 mm wide. <width>4.2</width> In keeping with our adherance to the metric system, millimeters seems a better choice for a base unit than inches, picas, points, em, en, or the other measurements used in graphics systems. Which programs act this way internally? SVG 1.2 may have a choice? Most raster-based mapping programs USGS printed map standards define line-widths in millimeters d> I'm not clear on the "dasharrayType". My first thought was that it d> specified the length of a "dash" then the length of "whitespace", etc. d> for the length of a repeating pattern. Yes, that's exactly it. It's modeled after SVG's stroke-dasharray. In general, if SVG does something similar to what we need, we copy it (or a subset of it). What are the units? The same as above - once we determine what those are... Actually, there needs to be a clarification of whether the dasharray numbers are measurements or multipliers. For example, if the line width is 3, and the dash array is "10 20", and the units are millimeters, is the dash 3mm wide and 10mm long, or is it 3mm wide and 30mm long? I can't tell which way SVG does this by reading the spec. GDI+ uses multipliers, I believe. -- Dan Foster
dananderson2+yahoo.com on Mon Nov 15 11:23:50 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Sunday, November 14, 2004, 11:29:45 PM, Dan A. wrote: > > d> What is the units of "width"? I see Dave W. has used "0.500000". > > That's the big question. This is a problem we need to solve so we can > properly describe a number of things, like the width of a line or the > height of a row of text. There are two approaches to a solution. > > One is to interpret width to be the actual physical dimension of the > object on the Earth. So your Gravel Road might be 3 meters wide. > <width>3.0</width> Some programs work this way internally, scaling > the width of the line they draw on the map so it always overs 3 meters > of ground at any scale. SVG is implemented this way now. > Of course, if you zoom out to a country-level map, that gravel road is > going to be too thin to actually see. Yes, for certain items on maps it's the indication of the presence of them that's important and not their actual size. Other items (a lake outline for instance) that you may actually want to show the actual size. Perhaps there should be two types of measurements. One type would give the actual real world size and be displayed as such. The other would be a relative display size (or non-physical display size) and be left to the program's author to decide how many pixels, etc. would be used. This would probably apply to the non-physical items too. > The "physical dimensions" approach breaks down a bit when trying to > apply it to completely non-physical things like font-height. > > Which programs act this way internally? > SVG 1.0, 1.1 > Many vector-based mapping programs > future versions of ExpertGPS > > > The second approach is to define a line width in terms of millimeters > on the display device (or pixels, or some other unit that isn't > related to a physical measurement of the object being modeled). So > your Gravel Road might be 4.2 mm wide. <width>4.2</width> In keeping > with our adherance to the metric system, millimeters seems a better > choice for a base unit than inches, picas, points, em, en, or the > other measurements used in graphics systems. Possibly support both methods as mentioned above..... > Which programs act this way internally? > SVG 1.2 may have a choice? > Most raster-based mapping programs > USGS printed map standards define line-widths in millimeters > > > d> I'm not clear on the "dasharrayType". My first thought was that it > d> specified the length of a "dash" then the length of "whitespace", etc. > d> for the length of a repeating pattern. > > Yes, that's exactly it. It's modeled after SVG's stroke-dasharray. > In general, if SVG does something similar to what we need, we copy it > (or a subset of it). What are the units? The same as above - once we > determine what those are... Actually, there needs to be a > clarification of whether the dasharray numbers are measurements or > multipliers. For example, if the line width is 3, and the dash array > is "10 20", and the units are millimeters, is the dash 3mm wide and > 10mm long, or is it 3mm wide and 30mm long? I can't tell which way > SVG does this by reading the spec. GDI+ uses multipliers, I believe. > > -- > Dan Foster The bottom line for me is that when you zoom in/out the dash - dot - dash doesn't turn into a solid line or spread so far apart that you can't see the "line" anymore in the small window. I've seen early versions of cadd programs that did that. Dan Anderson
gps_maps+travelbygps.com on Mon Nov 15 11:51:42 2004 (link), replying to msg
--- Dan Foster wrote: > Garmin has added support for GPX 1.1 in the latest MapSource beta. > http://www.garmin.com/support/download_details.jsp?id=625 > This is GREAT NEWS for those of us who committed early-on to publishing GPS data in (.gpx) format! Congradulaions Dan! - Doug www.travelbygps.com
gps_maps+travelbygps.com on Mon Nov 15 12:06:54 2004 (link), replying to msg
Bernd wrote: > > Recently I finished the implementation of my search engine > for gpx files. > http://www.fahrradspass.de/index.htm Dan Foster wrote: > That's very cool! Is there a form we can use to add > our own GPX files to the database? There are over 200 gpx files at Travel by GPS, which contain thousands of waypoints. What do I need to do to these file to insure that Bernd's search engine will index them correctly? And what is the proper format for adding author, keyword, and desciptive tags to the gpx file? - Doug www.travelbygps.com
molund+gmail.com on Tue Nov 16 09:54:48 2004 (link)
Is there a file format that is designed to map several trails in the same area? I am mapping a 250 acre wooded area near my home. There are at least 25 separate trails in the area. What would be the best way to encapsulate all the trails in a single file? Mike
dananderson2+yahoo.com on Tue Nov 16 10:38:41 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Troy Hopwood - DirtWorld.com" <troyh+d...> wrote: > Shouldn't display size of lines and text be left up to the author of the > software used to display a GPX file? If the GPX file identifies the type of > element it is ie. River, singletrack, street, etc. and if so desired, it's > actual physical size then the viewing program can determine how to draw it. > This way singletrack is always represented by the exact same style line in > ExpertGPS for example. > > Troy Hopwood IMHO, no. I've downloaded maps from Nat'l. Geographics's MapXchange where the author used very wide lines that covered up the topo detail so I had to go through and make them smaller (and early program versions without "styles" meant changing a bunch one by one). Someone else might make them too thin for my old eyes. In this case the data supplier made the choice which I could change in the program. If the program makes the choice, my only choice is to change programs. The program should not force certain line widths on the user (except for the program that only draws one size). In other words, I'm going to pick a mapping program that lets me set the line width to say 1 through 10. I'm not going to pick a mapping program that forces me to define a line as "river", "singletrack", "street", etc. and sets the width accordingly. The program may very well not have the type of object that I'm trying to draw in its definition and I might have to set a trail to "street" to get the size of line that I want. I currently have 4 line widths for various types of roads and 3 widths for various types of trails. If they want, someone using my data can change the widths of all the roads to some other value in the "styles" setup. Or they can change the style that a particular object belongs to. At least they can if the program supports "styles". Dan A.
ed+topozone.com on Tue Nov 16 10:59:47 2004 (link)
Troy & Dan - A potential difficulty lies in having a general-purpose map viewer application know about every "type" of line. "Singletrack" is obvious to you, but it ONLY has meaning in one specific domain. "Isotherm", "transect", "fall line", etc..., not to mention the fact that "river" means something that could be a foot across (in the real world) or a mile wide. So do we come up with multiple "river" subtypes? Part of the problem is that Dan's partially trying to insulate himself from bad design. I noticed Dan had no complaints about the linestyles on the topo basemap, which he can't change. That's (mainly) because they're well-designed maps, and the MapXchange file is a badly-designed map. But in general, cartographic practice is to designate objects rather finely with attributes, and allow the user to then classify either finely or coarsely based on those attributes. You might have 5 different subtypes of singletrack, for example, which would commonly be rendered as one style but might be divided for a more detailed look. We're drifting back, however, to the distinction between object attributes and rendering styles. These emails are about attributes, with applied styles, rather than rendering styles specified in the GPX file. I think it's important not to lose that distinction. "I currently have 4 line widths for various types of roads and 3 widths for various types of trails. If they want, someone using my data can change the widths of all the roads to some other value in the "styles" setup"... Yes, but would everything else of the same width change, too? That's the difference between classifying objects and overriding rendering styles. - Ed Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 ed+topozone.com (978) 251-4242 -----Original Message----- From: Troy Hopwood - DirtWorld.com [mailto:troyh+dirtworld.com] Sent: Tuesday, November 16, 2004 1:47 PM To: gpsxml+yahoogroups.com Subject: RE: [gpsxml] Re: Font sizes and line widths - units? It sounds like we're on the same page, different book. I agree that a program that sets a line width with no customization is very limited. What I'm saying is that the GPX shouldn't set the line width either. But identify the type. Then a well written program would have a style sheet so you could say all rivers are 12pixels wide and aqua marine and all singletrack is 10pixels wide red and dashed, etc. This way you have total control over the sizes. If the GPX file defines all the sizes then you're back in the situation you described with the National Geographic MapXchange. Troy _____ From: dananderson2 [mailto:dananderson2+yahoo.com] Sent: Tuesday, November 16, 2004 10:38 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: Font sizes and line widths - units? --- In gpsxml+yahoogroups.com, "Troy Hopwood - DirtWorld.com" <troyh+d...> wrote: > Shouldn't display size of lines and text be left up to the author of the > software used to display a GPX file? If the GPX file identifies the type of > element it is ie. River, singletrack, street, etc. and if so desired, it's > actual physical size then the viewing program can determine how to draw it. > This way singletrack is always represented by the exact same style line in > ExpertGPS for example. > > Troy Hopwood IMHO, no. I've downloaded maps from Nat'l. Geographics's MapXchange where the author used very wide lines that covered up the topo detail o I had to go through and make them smaller (and early program versions without "styles" meant changing a bunch one by one). Someone else might make them too thin for my old eyes. In this case the data supplier made the choice which I could change in the program. If the program makes the choice, my only choice is to change programs. The program should not force certain line widths on the user (except for the program that only draws one size). In other words, I'm going to pick a mapping program that lets me set the line width to say 1 through 10. I'm not going to pick a mapping program that forces me to define a line as "river", "singletrack", "street", etc. and sets the width accordingly. The program may very well not have the type of object that I'm trying to draw in its definition and I might have to set a trail to "street" to get the size of line that I want. I currently have 4 line widths for various types of roads and 3 widths for various types of trails. If they want, someone using my data can change the widths of all the roads to some other value in the "styles" setup. Or they can change the style that a particular object belongs to. At least they can if the program supports "styles". Dan A. Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=129mf7ff8/M=298184.5584357.6650215.3001176/D=gr oups/S=1706030390:HM/EXP=1100716722/A=2426683/R=0/SIG=11eeoolb0/*http:/www.n etflix.com/Default?mqso=60185400> click here <http://us.adserver.yahoo.com/l?M=298184.5584357.6650215.3001176/D=groups/S= :HM/A=2426683/rand=201335334> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed] Yahoo! Groups Links
dananderson2+yahoo.com on Tue Nov 16 11:44:06 2004 (link), replying to msg
Or maybe not even a different book. We're talking about extentions to the GPX spec. so that it supports "styles". A line type element (trk) is assigned a "lineType" and "lineType" is defined in Dan Foster's proposed extension of the GPX spec. "lineType" could be "River" and have a color of blue, be a solid line, and have a width "w", etc. In other words, the programs style sheet is stored in the GPX file with the rest of the data. Dan A. --- In gpsxml+yahoogroups.com, "Troy Hopwood - DirtWorld.com" <troyh+d...> wrote: > It sounds like we're on the same page, different book. > > I agree that a program that sets a line width with no customization is very > limited. What I'm saying is that the GPX shouldn't set the line width > either. But identify the type. Then a well written program would have a > style sheet so you could say all rivers are 12pixels wide and aqua marine > and all singletrack is 10pixels wide red and dashed, etc. This way you have > total control over the sizes. If the GPX file defines all the sizes then > you're back in the situation you described with the National Geographic > MapXchange. > > Troy > > _____ > > From: dananderson2 [mailto:dananderson2+y...] > Sent: Tuesday, November 16, 2004 10:38 AM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Re: Font sizes and line widths - units? > > > --- In gpsxml+yahoogroups.com, "Troy Hopwood - DirtWorld.com" > <troyh+d...> wrote: > > Shouldn't display size of lines and text be left up to the author > of the > > software used to display a GPX file? If the GPX file identifies the > type of > > element it is ie. River, singletrack, street, etc. and if so > desired, it's > > actual physical size then the viewing program can determine how to > draw it. > > This way singletrack is always represented by the exact same style > line in > > ExpertGPS for example. > > > > Troy Hopwood > > IMHO, no. I've downloaded maps from Nat'l. Geographics's MapXchange > where the author used very wide lines that covered up the topo detail > so I had to go through and make them smaller (and early program > versions without "styles" meant changing a bunch one by one). > Someone else might make them too thin for my old eyes. In this case > the data supplier made the choice which I could change in the > program. If the program makes the choice, my only choice is to change > programs. The program should not force certain line widths on the > user (except for the program that only draws one size). > > In other words, I'm going to pick a mapping program that lets me > set the line width to say 1 through 10. I'm not going to pick a > mapping program that forces me to define a line as "river", > "singletrack", "street", etc. and sets the width accordingly. The > program may very well not have the type of object that I'm trying to > draw in its definition and I might have to set a trail to "street" to > get the size of line that I want. > > I currently have 4 line widths for various types of roads and 3 widths > for various types of trails. If they want, someone using my data can > change the widths of all the roads to some other value in the "styles" > setup. Or they can change the style that a particular object > belongs to. At least they can if the program supports "styles". > > Dan A. > > > > > > > > Yahoo! Groups Sponsor > > > ADVERTISEMENT > > <http://us.ard.yahoo.com/SIG=129mf7ff8/M=298184.55 84357.6650215.3001176/D=gr > oups/S=1706030390:HM/EXP=1100716722/A=2426683/R=0/ SIG=11eeoolb0/*http:/www.n > etflix.com/Default?mqso=60185400> click here > > > <http://us.adserver.yahoo.com/l?M=298184.5584357.6 650215.3001176/D=groups/S= > :HM/A=2426683/rand=201335334> > > _____ > > Yahoo! Groups Links > * To visit your group on the web, go to: > http://groups.yahoo.com/group/gpsxml/ > > * To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service > <http://docs.yahoo.com/info/terms/> . > > > [Non-text portions of this message have been removed]
egroups+topografix.com on Tue Nov 16 14:06:35 2004 (link), replying to msg
Hello, Tuesday, November 16, 2004, 1:47:26 PM, Troy wrote: T> I agree that a program that sets a line width with no customization is very T> limited. What I'm saying is that the GPX shouldn't set the line width T> either. But identify the type. Then a well written program would have a T> style sheet so you could say all rivers are 12pixels wide and aqua marine T> and all singletrack is 10pixels wide red and dashed, etc. This way you have T> total control over the sizes. If the GPX file defines all the sizes then T> you're back in the situation you described with the National Geographic T> MapXchange. I'm taking both approaches in future output from ExpertGPS. ExpertGPS will use a style-sheet approach just as Troy described. You can define a "river" style once and all tracks that use it will be drawn using those parameters. If you change how it is drawn, all rivers will be updated. I use the <type> field in <trk> to specify the style type. (And I'm going to encourage users to give their types real-world names like Hiking Trail rather than Dashed Black Line.) When I output to GPX, I will write out the <type> but I will also fully (or as much as the schema allows) describe the attributes that make up the type. So I'll include line-width, color, opacity, fill-color, etc. That way a service like GPSVisualizer could draw a pretty good approximation of the track as it appears in ExpertGPS, even if they don't have the same style library that I do. On input, the program will make note of the <type> of the incoming track and check for a match in its style-sheet library. But it will also parse the other attributes of gpx_style, and create a style based on what's in the file. (call this the file style sheet). The user has an option to switch between the program style sheet (their style choices) and the file style sheet (the file author's style choices). Here's an example of a tracklog defining the edge of a pond. The pond outline is USGS dark blue. The fill is USGS light blue. (ie, it looks like a pond on a USGS topo map) You'll notice <pattern>Stream</pattern> as part of the line type. In addition to the basic solid/dash/dot/dash-dot line styles, I'm going to have pre-defined line styles that match USGS and other major map providers in terms of color, line weight, and dash intervals. Sample: <trk> <name>LONG POND</name> <desc>Long Pond</desc> <number>1</number> <type>pond</type> <extensions> <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>0097a4</color> <opacity>1</opacity> <pattern>Stream</pattern> </line> <fill xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>0097a4</color> <opacity>0.498039</opacity> <pattern>None</pattern> </fill> </extensions> <trkseg> <trkpt lat="42.4426869533941" lon="-71.58673643"/> <trkpt lat="42.4432773059327" lon="-71.58703643"/> ... -- Dan Foster
egroups+topografix.com on Tue Nov 16 14:14:30 2004 (link), replying to msg
Hello Michael, Tuesday, November 16, 2004, 12:54:44 PM, you wrote: M> Is there a file format that is designed to map several trails in the M> same area? I am mapping a 250 acre wooded area near my home. There M> are at least 25 separate trails in the area. What would be the best M> way to encapsulate all the trails in a single file? A single GPX file can contain any number of waypoints, routes, and tracks. You should be able to add each trail you map with your GPS to a master file in your mapping software. http://www.topografix.com/gpx_resources.asp has a number of mapping programs that use GPX. -- Dan Foster
egroups+topografix.com on Tue Nov 16 15:44:30 2004 (link), replying to msg
Hello, Monday, November 15, 2004, 2:23:40 PM, Dan A. wrote: d> Perhaps there should be two types of measurements. One type d> would give the actual real world size and be displayed as such. The d> other would be a relative display size (or non-physical display size) d> and be left to the program's author to decide how many pixels, etc. d> would be used. The problem with having two types of measurements is that all programs would have to be able to understand and convert from both types to whatever native format the program used. That's twice as much work for everyone. My program is set up to use real-world measurements, but I'm going to argue for using millimeters on the output device as the standard. The majority of mapping programs I've used (Ozi, Topo!, Terrain Navigator, etc) are set up so that a width of "2" in the UI results in a line 2 pixels wide, regardless of resolution or scale. For these programs, converting to and from the GPX millimeters standard just involves doing a multiplication against some scale factor that takes into account the screen or printer resolution. To verify that those programs are doing the conversion correctly, it would be easy to feed in a GPX route with a line width of 100. The resulting line should be 100mm (10 centimeters) on the screen and on the printed page. For programs like ExpertGPS that will scale line widths up and down depending on the scale of the underlying map, we need to pick some common scale factor at which the output would match that of a program from the category above. Since USGS 1:24000 quads are the most easily obtainable maps on the Internet, and that scale is roughly in the middle of what GPS users around the world are using (some use 1:10K, others 1:50K for ground navigation), I propose that this be our common scale. The UTM grid overlay on most quad maps provides an easy way to calibrate programs from the second category. Draw a route down one of the UTM lines. Now make the line width so thick that it touches the two parallel lines on either side. The line covers 2000 meters of the real-world. At a scale of 1:24000, 2000 meters = 83.333 millimeters. The GPX line width for the line that spans two UTM gridlines is 83.3 The only problem I can see with using millimeters as the standard of measurement for these objects is that the usable range is really from 0.1 to about 10.0 Above that value, the lines are too fat on the screen. (in the first example, 100.0 is 10cm wide - that's a lot of toner or ink on the printer!) The obvious solution is to define the unit of measure to be 10ths of millimeters, which gives a very nice usable range of 1.0 - 100.0 Personally, I like using millimeters for two reasons. Nobody uses tenths of anything as a standard measurement. Plus, this makes it immediately obvious to someone who maps their UI slider value directly to the GPX file that they've done something wrong. As an added bonus, USGS already defines their standard line types in millimeters. Those of you wanting to make your "Trail-Class 5, 4-wheel-drive vehicles" tracks match those on a USGS map only need to specify: line width=0.175mm, dash=1.25mm, space=0.5mm (Digital Cartographic Standard for Geologic Map Symbolization, chapter 28) Please share your thoughts on this proposal. -- Dan Foster
ivar+owt.com on Tue Nov 16 18:00:18 2004 (link), replying to msg
As to the discussion of line widths and types. I believe the spirit of Standard Generalized Markup Language (SGML), the parent of GPSXML, is to specify WHAT, not HOW. Ivar (normally a lurker, as I don't code in GPSXML...yet)
davewissenbach+yahoo.com on Tue Nov 16 20:00:59 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Monday, November 15, 2004, 2:23:40 PM, Dan A. wrote: > > d> Perhaps there should be two types of measurements. One type > d> would give the actual real world size and be displayed as such. The > d> other would be a relative display size (or non-physical display size) > d> and be left to the program's author to decide how many pixels, etc. > d> would be used. > > The problem with having two types of measurements is that all programs > would have to be able to understand and convert from both types to > whatever native format the program used. That's twice as much work > for everyone. > > My program is set up to use real-world measurements, but I'm going to > argue for using millimeters on the output device as the standard. The > majority of mapping programs I've used (Ozi, Topo!, Terrain Navigator, > etc) are set up so that a width of "2" in the UI results in a line 2 > pixels wide, regardless of resolution or scale. For these programs, > converting to and from the GPX millimeters standard just involves > doing a multiplication against some scale factor that takes into > account the screen or printer resolution. > > To verify that those programs are doing the conversion correctly, it > would be easy to feed in a GPX route with a line width of 100. The > resulting line should be 100mm (10 centimeters) on the screen and on > the printed page. > > > For programs like ExpertGPS that will scale line widths up and down > depending on the scale of the underlying map, we need to pick some > common scale factor at which the output would match that of a program > from the category above. Since USGS 1:24000 quads are the most easily > obtainable maps on the Internet, and that scale is roughly in the > middle of what GPS users around the world are using (some use 1:10K, > others 1:50K for ground navigation), I propose that this be our common > scale. > > The UTM grid overlay on most quad maps provides an easy way to > calibrate programs from the second category. Draw a route down one of > the UTM lines. Now make the line width so thick that it touches the > two parallel lines on either side. The line covers 2000 meters of the > real-world. At a scale of 1:24000, 2000 meters = 83.333 millimeters. > The GPX line width for the line that spans two UTM gridlines is 83.3 > > > The only problem I can see with using millimeters as the standard of > measurement for these objects is that the usable range is really from > 0.1 to about 10.0 Above that value, the lines are too fat on the > screen. (in the first example, 100.0 is 10cm wide - that's a lot of > toner or ink on the printer!) The obvious solution is to define the > unit of measure to be 10ths of millimeters, which gives a very nice > usable range of 1.0 - 100.0 > > Personally, I like using millimeters for two reasons. Nobody uses > tenths of anything as a standard measurement. Plus, this makes it > immediately obvious to someone who maps their UI slider value directly > to the GPX file that they've done something wrong. > > As an added bonus, USGS already defines their standard line types in > millimeters. Those of you wanting to make your "Trail-Class 5, > 4-wheel-drive vehicles" tracks match those on a USGS map only need to > specify: line width=0.175mm, dash=1.25mm, space=0.5mm > (Digital Cartographic Standard for Geologic Map Symbolization, chapter > 28) > > > Please share your thoughts on this proposal. > I prefer millimeters to points or dots of device resolution, but I am currently using points in Wissenbach Map3D. Dave > -- > Dan Foster
davewissenbach+yahoo.com on Tue Nov 16 20:06:28 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello Michael, > > Tuesday, November 16, 2004, 12:54:44 PM, you wrote: > > > M> Is there a file format that is designed to map several trails in the > M> same area? I am mapping a 250 acre wooded area near my home. There > M> are at least 25 separate trails in the area. What would be the best > M> way to encapsulate all the trails in a single file? > > A single GPX file can contain any number of waypoints, routes, and > tracks. You should be able to add each trail you map with your GPS to > a master file in your mapping software. > > http://www.topografix.com/gpx_resources.asp has a number of mapping > programs that use GPX. > If you have read the entire group up to this point, you know that ExpertGPS provides cut-and-paste capability which would help you do this. I've been lazy and not added cut and paste -- hey, what do you expect for free? but you can edit any gpx files in a text editor such as word pad, and copy tracks out of one file into another. Another way is to open a gpx file, and read the new trail into the open file. I've got one map that has about a hundred miles of trails, at 100 track points per mile, that works fine in gpx format. Dave Wissenbach > -- > Dan Foster
dananderson2+yahoo.com on Tue Nov 16 22:49:34 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Hello, > > > > Monday, November 15, 2004, 2:23:40 PM, Dan A. wrote: > > > > d> Perhaps there should be two types of measurements. One type > > d> would give the actual real world size and be displayed as > such. The > > d> other would be a relative display size (or non-physical display > size) > > d> and be left to the program's author to decide how many pixels, > etc. > > d> would be used. > > > > The problem with having two types of measurements is that all > programs > > would have to be able to understand and convert from both types to > > whatever native format the program used. That's twice as much work > > for everyone. > > > > My program is set up to use real-world measurements, but I'm going > to > > argue for using millimeters on the output device as the standard. > The > > majority of mapping programs I've used (Ozi, Topo!, Terrain > Navigator, > > etc) are set up so that a width of "2" in the UI results in a line > 2 > > pixels wide, regardless of resolution or scale. For these > programs, > > converting to and from the GPX millimeters standard just involves > > doing a multiplication against some scale factor that takes into > > account the screen or printer resolution. > > > > To verify that those programs are doing the conversion correctly, > it > > would be easy to feed in a GPX route with a line width of 100. The > > resulting line should be 100mm (10 centimeters) on the screen and > on > > the printed page. > > > > > > For programs like ExpertGPS that will scale line widths up and down > > depending on the scale of the underlying map, we need to pick some > > common scale factor at which the output would match that of a > program > > from the category above. Since USGS 1:24000 quads are the most > easily > > obtainable maps on the Internet, and that scale is roughly in the > > middle of what GPS users around the world are using (some use > 1:10K, > > others 1:50K for ground navigation), I propose that this be our > common > > scale. > > > > The UTM grid overlay on most quad maps provides an easy way to > > calibrate programs from the second category. Draw a route down > one of > > the UTM lines. Now make the line width so thick that it touches > the > > two parallel lines on either side. The line covers 2000 meters of > the > > real-world. At a scale of 1:24000, 2000 meters = 83.333 > millimeters. > > The GPX line width for the line that spans two UTM gridlines is > 83.3 > > > > > > The only problem I can see with using millimeters as the standard > of > > measurement for these objects is that the usable range is really > from > > 0.1 to about 10.0 Above that value, the lines are too fat on the > > screen. (in the first example, 100.0 is 10cm wide - that's a lot > of > > toner or ink on the printer!) The obvious solution is to define > the > > unit of measure to be 10ths of millimeters, which gives a very nice > > usable range of 1.0 - 100.0 > > > > Personally, I like using millimeters for two reasons. Nobody uses > > tenths of anything as a standard measurement. Plus, this makes it > > immediately obvious to someone who maps their UI slider value > directly > > to the GPX file that they've done something wrong. > > > > As an added bonus, USGS already defines their standard line types > in > > millimeters. Those of you wanting to make your "Trail-Class 5, > > 4-wheel-drive vehicles" tracks match those on a USGS map only need > to > > specify: line width=0.175mm, dash=1.25mm, space=0.5mm > > (Digital Cartographic Standard for Geologic Map Symbolization, > chapter > > 28) > > > > > > Please share your thoughts on this proposal. > > > > I prefer millimeters to points or dots of device resolution, but I > am currently using points in Wissenbach Map3D. > > Dave It's device independent and workable so I like it too. Dan A.
azbithead+gmail.com on Wed Nov 17 16:58:12 2004 (link)
Hello All, By way of introduction to the members of the forum, my name is Steve Hales and I am a software engineer at Garmin. I have been involved in the development of the GPX open/save functionality in our MapSource application. I look forward to being involved in the discussions in this forum. Dan Foster and I have been having a discussion via email regarding the schemaLocation attribute in GPX instance documents. The issue is whether or not a valid GPX document must include a schemaLocation with a value set to http://www.topografix.com/GPX/1/0/gpx.xsd or http://www.topografix.com/GPX/1/1/gpx.xsd. Dan has asserted that it must. I contend that it does not hurt to have it but it is not strictly needed. Regular forum readers may have seen Dan's post expressing concern that GPX documents produced by MapSource do not validate according to the test given at http://www.topografix.com/gpx_validation.asp. The reason they will not validate under that test is that they do not include the schemaLocation as described above and the SaxCount program relies on the presence of the schemaLocation attribute. However, these files will validate using the tool at http://tools.decisionsoft.com/schemaValidate.html. At this point, I want to say that whether or not validation is a good thing is not part of the issue I'm getting at here. At Garmin, we believe it is a very good thing and MapSource does validation when it reads GPX documents. In fact, we chose not to give MapSource the ability to read .loc files because there is no schema available to validate them. I also want to point out that the XML Schema specification at http://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation states that the schemaLocation attribute "*can* be used in a document to provide hints as to the physical location of schema documents which may be used for assessment" (emphasis mine). Finally, Dan's assertion that a valid GPX document must contain a schemaLocation as stated above is a restriction being placed on GPX documents external to the restrictions expressed in the GPX schema. In my opinion, having additional requirements outside of the schema is undesirable because they can easily lead to ambiguity and may be difficult to implement. They are also not amenable to automated processing which is one of the great features of XML schemas. I welcome your comments. - Steve
davewissenbach+yahoo.com on Wed Nov 17 18:25:22 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Steve Hales <azbithead+g...> wrote: > Hello All, > > By way of introduction to the members of the forum, my name is Steve > Hales and I am a software engineer at Garmin. I have been involved in > the development of the GPX open/save functionality in our MapSource > application. I look forward to being involved in the discussions in > this forum. > > Dan Foster and I have been having a discussion via email regarding the > schemaLocation attribute in GPX instance documents. The issue is > whether or not a valid GPX document must include a schemaLocation with > a value set to http://www.topografix.com/GPX/1/0/gpx.xsd or > http://www.topografix.com/GPX/1/1/gpx.xsd. Dan has asserted that it > must. I contend that it does not hurt to have it but it is not > strictly needed. Regular forum readers may have seen Dan's post > expressing concern that GPX documents produced by MapSource do not > validate according to the test given at > http://www.topografix.com/gpx_validation.asp. The reason they will not > validate under that test is that they do not include the > schemaLocation as described above and the SaxCount program relies on > the presence of the schemaLocation attribute. However, these files > will validate using the tool at > http://tools.decisionsoft.com/schemaValidate.html. > > At this point, I want to say that whether or not validation is a good > thing is not part of the issue I'm getting at here. At Garmin, we > believe it is a very good thing and MapSource does validation when it > reads GPX documents. In fact, we chose not to give MapSource the > ability to read .loc files because there is no schema available to > validate them. > > I also want to point out that the XML Schema specification at > http://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation states that the > schemaLocation attribute "*can* be used in a document to provide hints > as to the physical location of schema documents which may be used for > assessment" (emphasis mine). > > Finally, Dan's assertion that a valid GPX document must contain a > schemaLocation as stated above is a restriction being placed on GPX > documents external to the restrictions expressed in the GPX schema. In > my opinion, having additional requirements outside of the schema is > undesirable because they can easily lead to ambiguity and may be > difficult to implement. They are also not amenable to automated > processing which is one of the great features of XML schemas. > > I welcome your comments. > > - Steve Welcome to the group, and thanks to Garmin for providing gpx 1.1 support in your software. I've always been impressed by Garmin's ongoing support for their GPS units and continuing product improvement. I hope that members of the group give you due deference! We validate using xerces/ SaxCount simply because that's an available free tool -- I think that we were on the bleeding edge of the usage of XML Schema. Thanks for providing an alternative method of validation. If you are concerned about automated processing, I think that you would want the schema location specified! Otherwise, how would the validation tool know which schema to use? There's nothing in the namespace declaration which tells you where to locate the schema, so you'll have to resort to using a well-known schema location. I don't think that validation is a good idea for a reader, anyways -- because minor glitches and programming errors that would otherwise slide right through your parser will cause the document to be rejected. Instead, be strict on your output, but not on input. Perhaps when you support the GPX program you do so with the caveat that support by Garmin for GPX files is guaranteed only for VALID gpx files. (Just pop up a warning box for files that don't validate, which includes the generating application. Hopefully mine won't be among these.) We all know where to find the schema, so leaving the schema out is a big deal one way or another--it just becomes a bit inconvenient when validating not to have the schema location. The best argument for not providing schema location is to prevent a hit on the topografix web site every time a gpx file is opened with a validating parser. But that can be prevented simply by having the parser cache the schema, or allowing an alternative schema location to be specified (provided that the data at the alternative location matches the master at topografix. Regards, Dave Wissenbach
Bernd.Sobotka+Fahrradspass.de on Thu Nov 18 08:44:14 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+t...> wrote: > > Bernd wrote: > > > > Recently I finished the implementation of my search engine > > for gpx files. > > http://www.fahrradspass.de/index.htm > > Dan Foster wrote: > > That's very cool! Is there a form we can use to add > > our own GPX files to the database? > > There are over 200 gpx files at Travel by GPS, which contain > thousands of waypoints. What do I need to do to these file to insure > that Bernd's search engine will index them correctly? And what is > the proper format for adding author, keyword, and desciptive tags to > the gpx file? > - Doug > www.travelbygps.com Hi, There is a new function now which allows every user to enter a new GPX file reference to the database. I recommend to separate keywords by commas or by semicolons. This will guarantee that the application stores them correctly. There is no particular format for authors or desc elements. The application stores all descriptions "as they are". The only restrictions are the maximum lengths of the database fields. This might lead to very long descriptions being truncated. If you should run into any problems, please let me know. Best regards, Bernd
robertlipe+usa.net on Thu Nov 18 10:16:16 2004 (link), replying to msg
> I have been involved in the development of the GPX open/save Welcome, Steve. That's a useful feature in your product and I look forward to checking that out. > schemaLocation as described above and the SaxCount program relies on > the presence of the schemaLocation attribute. However, these files > will validate using the tool at > http://tools.decisionsoft.com/schemaValidate.html. That's really strange. It's bad form to answer a question with a question, but here goes. SAXCount is part of Xerces. This site claims to use Xerces. Why there is a discrepancy on what they consider "good"? RJL
azbithead+gmail.com on Thu Nov 18 10:41:00 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > > If you are concerned about automated processing, I think that you > would want the schema location specified! Otherwise, how would the > validation tool know which schema to use? There's nothing in the > namespace declaration which tells you where to locate the schema, so > you'll have to resort to using a well-known schema location. Using a well-known location is not necessarily a bad thing. We, in particular, were concerned that our users might be running on a computer that does not have access to the Internet. As such, we had to make provision for the schema to always be available locally. We did that by embedding a copy of the schema into our executable as a custom resource. > I don't think that validation is a good idea for a reader, anyways -- > because minor glitches and programming errors that would otherwise > slide right through your parser will cause the document to be > rejected. Instead, be strict on your output, but not on input. > Perhaps when you support the GPX program you do so with the caveat > that support by Garmin for GPX files is guaranteed only for VALID > gpx files. (Just pop up a warning box for files that don't validate, > which includes the generating application. Hopefully mine won't be > among these.) Our intention is that MapSource will only work with valid GPX files. But, as I mentioned in my original post, this is not the topic of this thread. I'd be glad to discuss the merits of validation in another thread. > The best argument for not providing schema location is to prevent a > hit on the topografix web site every time a gpx file is opened with > a validating parser. But that can be prevented simply by having the > parser cache the schema, or allowing an alternative schema location > to be specified (provided that the data at the alternative location > matches the master at topografix. My point in starting this thread was not to debate whether including the schemaLocation is a good thing. In fact, I think it probably is a good thing. The question I am raising is whether a GPX document should be considered invalid if it does not include a schemaLocation. The XML Schema standard does not consider a schema-based XML document to be invalid if it does not include a schemaLocation. Dan, however, expressed his opinion to me that a GPX document should be considered invalid if it has no schemaLocation. That seems overly restrictive (and unnecessary) to me. - Steve
azbithead+gmail.com on Thu Nov 18 10:52:17 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > That's really strange. It's bad form to answer a question with a > question, but here goes. SAXCount is part of Xerces. This site claims > to use Xerces. Why there is a discrepancy on what they consider "good"? Just a couple of comments here: Saying that SaxCount is *part* of Xerces is a little misleading. SaxCount is actually just an example program provided with the Xerces source code distribution. It's just one of several samples provided to help illustrate how to use the Xerces API in a program. I don't think there is any discrepancy here. If you dive into the Xerces documentation you will find that they provide the means to get a schema document from multiple sources, one of which is through the schemaLocation attribute in an instance document. This is how SaxCount was written. The developers of the web site chose to use another method within Xerces for getting the schema document. - Steve
azbithead+gmail.com on Thu Nov 18 11:35:08 2004 (link), replying to msg
The following was sent directly to me via the forum but I thought others in the forum might have the same question so I am posting the question and my response to the forum: >Hello Steve, > >I learnt from a posting in the gpx developers forum, that you worked >on the "open/save as GPX" functionality of the new MapSource >software. As I was workling on a small private project transfering >TOP50 overlays (a topographic map software commonly used in Germany) >to my Garmin device, I wanted to ask, if you have any reference, that >you are allowed to publish, how you code the <sym>-Tag of the wptType >record to the Garmin-symbols. If its easy for you, your answer would >be helpful, but if its too much effort, I would understand The short answer is that I don't have any documentation that provides the information you seek. However, if you have the MapSource 6.5 beta it is possible to do some reverse engineering to get the info. Here's how: 1. Launch MapSource 6.5 beta. 2. For each symbol you are interested in, create a waypoint having that symbol. 3. Save your document as a GPX file. 4. Open the GPX file in your favorite text editor. 5. Examine the string values in the <sym> elements. If you create a GPX file using those same strings and open it in MapSource you will get the corresponding symbols. Hope that helps. - Steve
dananderson2+yahoo.com on Thu Nov 18 12:49:28 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Sunday, November 14, 2004, 11:29:45 PM, Dan A. wrote: > d> I'm not clear on the "dasharrayType". My first thought was that it > d> specified the length of a "dash" then the length of "whitespace", etc. > d> for the length of a repeating pattern. > > Yes, that's exactly it. It's modeled after SVG's stroke-dasharray. > In general, if SVG does something similar to what we need, we copy it > (or a subset of it). What are the units? The same as above - once we > determine what those are... Actually, there needs to be a > clarification of whether the dasharray numbers are measurements or > multipliers. For example, if the line width is 3, and the dash array > is "10 20", and the units are millimeters, is the dash 3mm wide and > 10mm long, or is it 3mm wide and 30mm long? I can't tell which way > SVG does this by reading the spec. GDI+ uses multipliers, I believe. > > -- > Dan Foster Looking at the GDI spec. the lengths are relative to the line width with "1" equal to the line width. So yes, it is a multiplier. Looking at the SVG spec there are a number of ways of specifying the units including a percentage. For the example above, I would say the line is 3 user units wide and the dash is 10 user units long given no other information (ie. not multiplied by the line width). I also looked at an example in an SVG tutorial where the dash length was a measurement not a multiplier. Dan A.
davewissenbach+yahoo.com on Thu Nov 18 17:42:06 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "azbithead" <azbithead+g...> wrote: > > --- In gpsxml+yahoogroups.com, "David S. Wissenbach" > <davewissenbach+y...> wrote: > > > > If you are concerned about automated processing, I think that you > > would want the schema location specified! Otherwise, how would the > > validation tool know which schema to use? There's nothing in the > > namespace declaration which tells you where to locate the schema, > so > > you'll have to resort to using a well-known schema location. > > Using a well-known location is not necessarily a bad thing. We, in > particular, were concerned that our users might be running on a > computer that does not have access to the Internet. As such, we had to > make provision for the schema to always be available locally. We did > that by embedding a copy of the schema into our executable as a custom > resource. > > > I don't think that validation is a good idea for a reader, anyways > -- > > because minor glitches and programming errors that would otherwise > > slide right through your parser will cause the document to be > > rejected. Instead, be strict on your output, but not on input. > > Perhaps when you support the GPX program you do so with the caveat > > that support by Garmin for GPX files is guaranteed only for VALID > > gpx files. (Just pop up a warning box for files that don't > validate, > > which includes the generating application. Hopefully mine won't be > > among these.) > > Our intention is that MapSource will only work with valid GPX files. > But, as I mentioned in my original post, this is not the topic of this > thread. I'd be glad to discuss the merits of validation in another > thread. > > > The best argument for not providing schema location is to prevent a > > hit on the topografix web site every time a gpx file is opened with > > a validating parser. But that can be prevented simply by having the > > parser cache the schema, or allowing an alternative schema location > > to be specified (provided that the data at the alternative location > > matches the master at topografix. > > My point in starting this thread was not to debate whether including > the schemaLocation is a good thing. In fact, I think it probably is a > good thing. The question I am raising is whether a GPX document should > be considered invalid if it does not include a schemaLocation. The XML > Schema standard does not consider a schema-based XML document to be > invalid if it does not include a schemaLocation. Dan, however, > expressed his opinion to me that a GPX document should be considered > invalid if it has no schemaLocation. That seems overly restrictive > (and unnecessary) to me. > > - Steve I proposed the usage of SaxCount as a validation method simply because this was cheap and easy. And including the schema location in the gpx file makes validation relatively painless. I also agree that including the schema location for the gpx namespace SHOULD be provided but vendor-specific extensions to the gpx file MUST have the schema location specified, because the vendor- -specific schema location is not well known and to allow validation. If the other contributers to gpx can agree that the schema location for the gpx namespace SHOULD be provided, and use the W3C's definition of that word, then we can close this discussion (or is it a debate?) and move on. By the way, I tested the MapSource Beta 6.5 against a sampling of the data on my website at http://www.gpstrailmaps.com/ and was able to interchange data. I'll be going through the website to ensure that all of my files are valid (I've been a bit lax about producing valid output, and wasn't able to open one of the files in MapSource until opening and resaving in another program.) Dave
aefitzhugh+yahoo.com on Fri Nov 19 08:46:47 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > If you are concerned about automated processing, I think that you > would want the schema location specified! Otherwise, how would the > validation tool know which schema to use? There's nothing in the > namespace declaration which tells you where to locate the schema, so > you'll have to resort to using a well-known schema location. A minor point: the official position in XML land is that the URI that specifies a schema is *not* to be treated as an actual location from which the schema doc can be retrieved. The URI is really a namespace specifier, or version specifier if you will. The meaning of an element is ambiguous without it. And that leads to why it is very important to specify the schema in documents: versioning. There will inevitably be new versions in the future, and specifying the schemas now will be important for future interoperability of the data. -- Andy
azbithead+gmail.com on Fri Nov 19 09:39:00 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > > I proposed the usage of SaxCount as a validation method simply > because this was cheap and easy. And including the schema location > in the gpx file makes validation relatively painless. > If others in the forum would find it to be useful, I would be willing to develop a command line program based on the SaxCount code that might be more useful to those wishing to validate XML schema instances. The program could validate an instance either by using the instance's embedded schemaLocation (if it has one) or by using schema location info provided on the command line. It also could provide an exit status such that it could be used in scripts. Since it would be based on SaxCount, I would be willing to make the source code freely available. What do you think? - Steve
egroups+topografix.com on Fri Nov 19 11:19:10 2004 (link), replying to msg
Hello, I've tried to stay out of this discussion as long as possible, but the weekend is drawing nearer and many of us will be logging off for a few days. Steve wants to know: 1 - whether there is a CURRENT requirement to include schemaLocation in all GPX files. Please note that this is not a question about whether you agree with a requirement - it's a question of whether a rule exists or not. 2 - whether schemaLocation should be required in the FUTURE for all GPX files. Most of the debate so far has been on question 2. It's a very important discussion to have, but I think we'd be best off knowing the answer to question 1 first. Some facts regarding question 1: - GPX files that do not contain the schemaLocation attribute do not validate using the validation method described at http://www.topografix.com/gpx_validation.asp, because the validator has not been given the location of the schemas it is supposed to validate against. Quoting from the Web page above: "Why Validate? Your application needs to produce valid GPX output before it can be used with other programs and web services that support GPX. When a developer encounters a GPX file she can't parse, the first question should always be "Is this a valid GPX file?" The GPX validation test provides a consistant answer to this question. If your file validates successfully, SAXCount will display a count of the elements in your file, like the following: my_gpx_file.gpx: 1012 ms (4025 elems, 1916 attrs, 8048 spaces, 36109 chars) Any other output from SAXCount.exe indicates that your GPX file is incorrect. It is your responsibility to ensure that any GPX files you create validate successfully against the GPX schema." - If there is a current requirement that GPX files must validate using the SAXCount method, then the answer to question 1 is YES. We all need to agree to the truth of the last statement before proceeding. Speak up if you don't see how question 1 boils down to this. [Dan's opinion: I believe there's ample evidence in the email archives that there is an existing CURRENT requirement, dating back to 2002, that GPX files must validate using the SAXCount method. I'm going to quote from a number of old emails below to support this. I'd appreciate it if some of the GPX old-timers on the list would think back to 2002 and chime in with their thoughts on how things evolved. Please keep in mind that we're discussing a very narrow issue here: whether or not we decided in 2002 that all GPX files had to pass the SAXCount test. If you weren't participating in the GPX forum in 2002, you shouldn't be participating in this very narrow discussion, other than to point out specific emails from the archives. (I apologize for the offensive nature of this last paragraph. I don't want anyone to feel their contribution to this forum is unwanted or less important than anyone else's.) Excerpts from the email archives: David Wissenbach 1 Jan 2002: 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. Dan Foster 16 Jan 2002: 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. Kjeld Jensen 20 Jan 2002: It is amazing how a few hours with a new technology can change one's point of view :-) I have played with the XML schema for the past two days now, here are my conclusions: I followed Dan's description and implemented the version 0.4 into my existing "old" gpx format. I had to make a few modifications to the old format but notihing serious. I discovered that I had to make a copy of the schema and put it on my personal homepage. Most developers will probably want to do this, so we have to support it I guess. I then validated against the zerces parser which turned out fine. Import into the new beta of ExpertGPS also works fine for both waypoints and tracks. After having tried this I agree to Dan's 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. Dan Foster 1 Mar 2002: (in reply to Brian Lalor) 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 22 Sep 2002: (in reply to Robert Lipe) 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 Robert Lipe 1 Apr 2003 (in reply to Paul Tomblin): > 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. Thanks for reading all of this. If you are going to reply to this "current requirement" thread, please keep your comments limited to interpretations of past discussions on this forum. If you have comments regarding question 2 (should schemaLocation be required in the future) please choose a different subject line for your message. -- Dan Foster
robertlipe+usa.net on Fri Nov 19 11:49:42 2004 (link), replying to msg
Dan Foster wrote: > Steve wants to know: > 1 - whether there is a CURRENT requirement to include schemaLocation in > all GPX files. Please note that this is not a question about whether > you agree with a requirement - it's a question of whether a rule Based on my experience in past (and more formal) specifications, I'd say there is, but it's an implicit one. (/me resists urge to veer into point 2.) We didn't defer to XML standards to determine "correctness"; we said, Any other output from SAXCount.exe indicates that your GPX file is incorrect. It is your responsibility to ensure that any GPX files you create validate successfully against the GPX schema. Now in doing this, we left all kinds of wiggle room including the option for "the latest version of Xerces" to change the rules under us, but I suppose if we reduce this to return Boolean we have to return FALSE on Steve's files; leaving out schemaLocation will result in other output from SAXCount.exe thus indicating the GPX file is incorrect. A determined developer could therefore trump that by submitting a change to Xerces to accept this form. The day it was released as "the latest version" he or she could get a giant "neener neener neener". So, yeah, I think we did end up speccing it that way if only by accident. RJL
davewissenbach+yahoo.com on Fri Nov 19 18:24:31 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > I've tried to stay out of this discussion as long as possible, but the > weekend is drawing nearer and many of us will be logging off for a few > days. > > Steve wants to know: > 1 - whether there is a CURRENT requirement to include schemaLocation in > all GPX files. Please note that this is not a question about whether > you agree with a requirement - it's a question of whether a rule > exists or not. > 2 - whether schemaLocation should be required in the FUTURE for all GPX > files. > > Most of the debate so far has been on question 2. It's a very > important discussion to have, but I think we'd be best off knowing the > answer to question 1 first. > > Some facts regarding question 1: > - GPX files that do not contain the schemaLocation attribute do not > validate using the validation method described at > http://www.topografix.com/gpx_validation.asp, because the validator > has not been given the location of the schemas it is supposed to > validate against. > > Quoting from the Web page above: > "Why Validate? > Your application needs to produce valid GPX output before it can be > used with other programs and web services that support GPX. When a > developer encounters a GPX file she can't parse, the first question > should always be "Is this a valid GPX file?" The GPX validation test > provides a consistant answer to this question. > > If your file validates successfully, SAXCount will display a count of > the elements in your file, like the following: > my_gpx_file.gpx: 1012 ms (4025 elems, 1916 attrs, 8048 spaces, 36109 chars) > > Any other output from SAXCount.exe indicates that your GPX file is > incorrect. It is your responsibility to ensure that any GPX files you > create validate successfully against the GPX schema." > > > - If there is a current requirement that GPX files must validate using > the SAXCount method, then the answer to question 1 is YES. > > We all need to agree to the truth of the last statement before > proceeding. Speak up if you don't see how question 1 boils down to > this. > Yes, there is a current requirement to validate using SaxCount.exe. (I have also unfortunately discovered that intermediate versions of WM3D developed did not meet that requirement. So this might be a case of do as I say and not as I do. But I have corrected all date published on www.gpstrailmaps.com and resolve to do better in the future, because interoperability is the very foundation of the gpx xml effort! > > Thanks for reading all of this. If you are going to reply to this > "current requirement" thread, please keep your comments limited to > interpretations of past discussions on this forum. If you have > comments regarding question 2 (should schemaLocation be required in > the future) please choose a different subject line for your message. > > -- > Dan Foster
jame_smith009+yahoo.com on Sat Nov 20 01:37:29 2004 (link)
I am trying this from past 3 months and getting free calling cards why not u.... http://urbonus.notlong.com U can get more by refering your beloved ones.
egroups+topografix.com on Tue Nov 23 08:35:29 2004 (link)
Hello, I'd like to start a discussion about the best way to represent in GPX objects that aren't meant to be sent to the GPS. A GPX file might contain a tracklog and waypoints containing a hike, but it also might include some text labels to display on the base map, and a filled polygon noting the location of a pond that doesn't appear on the printed map. The polygon-pond may have started out as a tracklog - perhaps I walked the perimeter of the frozen pond with a GPS to record its bounds. Many mapping programs allow the user to add text notes and photographs to the map. They also allow the user to draw lines and filled shapes to represent things like roads, fields, and food plots. Point objects like text notes could be mapped to <wpt> in GPX. Lines and filled shapes could be mapped to <rte> or <trk>. Should they? Or should they have their own base types? When I first started thinking about this I believed that these objects should be represented by their own base types in GPX. If you look at the early version of the gpx_overlay schema I have been working on, you'll see <polygon> and <polyline> elements. http://www.topografix.com/gpx/gpx_overlay/0/1/gpx_overlay.xsd <polyline> might indicate a gas pipeline cutting across a mapped area. <polygon> might be used to describe the boundary line of a public park or a farm field. As I started working on an implementation, I realized that <polyline> and <rte/trk> were pretty much identical, except that: <polyline> was intended to not be sent to the GPS <polyline> wouldn't be recognized by any existing GPX programs It seems to me a better solution to reuse <rte> and <trk> for these objects, and simply insert a tag indicating that these objects are not meant to be sent to the GPS. This would permit the greatest amount of data interchange between programs. It also mirrors the way most mapping programs currently work, with the exception of text notes. In the mapping programs I looked at (Ozi, Topo!), lines and filled shapes are only available as routes or tracks. Text notes are the exception. Most programs keep text notes and waypoints separate. (Ozi calls them Map Comments, for example). I don't see any major difference between a styled <wpt> and a text note and would recommend storing text notes in the super <wpt> element that currently handles waypoints, routepoints, and trackpoints. Programs that kept the two separate could always check for the presence of <do_not_send_this_element_to_the_gps /> when importing <wpt> elements and interpret those objects as text notes. An example: <wpt lat="42" lon="-150"> <desc>Map of our hunting club</desc> <do_not_send_this_element_to_the_gps /> <!-- this is a text note --> <extensions> [lots of style stuff goes here: Arial, 24pt, red, bold-italic...] </extensions> </wpt> <do_not_send_this_element_to_the_gps> could have a shorter name in the actual implementation... Any thoughts? -- Dan Foster - egroups+topografix.com
molund+gmail.com on Tue Nov 23 09:39:00 2004 (link), replying to msg
While I agree that base maps are important, is that really what GPX is for? GPX is "a light-weight XML data format for the interchange of GPS data ". It is not "a general purpose XML format for creating maps". Keep it simple so new developers can pick it up easily. On Tue, 23 Nov 2004 11:35:29 -0500, Dan Foster <egroups+topografix.com> wrote: > Hello, > > I'd like to start a discussion about the best way to represent in GPX > objects that aren't meant to be sent to the GPS. A GPX file might > contain a tracklog and waypoints containing a hike, but it also might > include some text labels to display on the base map, and a filled polygon > noting the location of a pond that doesn't appear on the printed map. > The polygon-pond may have started out as a tracklog - perhaps I > walked the perimeter of the frozen pond with a GPS to record its > bounds. > > Many mapping programs allow the user to add text notes and photographs > to the map. They also allow the user to draw lines and filled shapes > to represent things like roads, fields, and food plots. Point objects > like text notes could be mapped to <wpt> in GPX. Lines and filled > shapes could be mapped to <rte> or <trk>. Should they? Or should > they have their own base types? > > When I first started thinking about this I believed that these objects > should be represented by their own base types in GPX. If you look at > the early version of the gpx_overlay schema I have been working on, > you'll see <polygon> and <polyline> elements. > http://www.topografix.com/gpx/gpx_overlay/0/1/gpx_overlay.xsd > > <polyline> might indicate a gas pipeline cutting across a mapped area. > <polygon> might be used to describe the boundary line of a public > park or a farm field. > > As I started working on an implementation, I realized that <polyline> > and <rte/trk> were pretty much identical, except that: > <polyline> was intended to not be sent to the GPS > <polyline> wouldn't be recognized by any existing GPX programs > > It seems to me a better solution to reuse <rte> and <trk> for these > objects, and simply insert a tag indicating that these objects are > not meant to be sent to the GPS. This would permit the greatest > amount of data interchange between programs. It also mirrors the way > most mapping programs currently work, with the exception of text > notes. In the mapping programs I looked at (Ozi, Topo!), lines and > filled shapes are only available as routes or tracks. > > Text notes are the exception. Most programs keep text notes and > waypoints separate. (Ozi calls them Map Comments, for example). > I don't see any major difference between a styled <wpt> and a text > note and would recommend storing text notes in the super <wpt> element > that currently handles waypoints, routepoints, and trackpoints. > Programs that kept the two separate could always check for the > presence of <do_not_send_this_element_to_the_gps /> when importing > <wpt> elements and interpret those objects as text notes. > > An example: > <wpt lat="42" lon="-150"> > <desc>Map of our hunting club</desc> > <do_not_send_this_element_to_the_gps /> <!-- this is a text note --> > <extensions> > [lots of style stuff goes here: Arial, 24pt, red, bold-italic...] > </extensions> > </wpt> > > <do_not_send_this_element_to_the_gps> could have a shorter name in the > actual implementation... > > Any thoughts? > > -- > Dan Foster - egroups+topografix.com > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > > ________________________________ > Yahoo! Groups Links > > To visit your group on the web, go to: > http://groups.yahoo.com/group/gpsxml/ > > 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.
egroups+topografix.com on Tue Nov 23 10:55:20 2004 (link), replying to msg
Hello, Tuesday, November 23, 2004, 12:37:05 PM, Michael wrote: M> While I agree that base maps are important, is that really what GPX is M> for? GPX is "a light-weight XML data format for the interchange of M> GPS data ". It is not "a general purpose XML format for creating M> maps". Keep it simple so new developers can pick it up easily. "GPS data" stops being just GPS data as soon as it leaves the GPS receiver. It becomes Jeremy Irish's geocaches, or Paul Tomblin's aviation database, or Doug Adomatis' travel maps, or Backpacker Magazine's GPS trail guides. When you look at the actual data that is being exchanged, it's clear that the descriptions, photos, and other metadata is equally as important as the lat/lon/ele/time data from the GPS receiver. I think we're all in agreement that GPX should not become an "everything and the kitchen sink" format. I personally feel that the fact that there's no standard way to say "this tracklog should be a green line" in GPX is a problem. Most of the other GPS data formats (Ozi's .trk, Topo!'s .tpo, MapTech's .txf) can express this, and I think that's a good measure of where to draw the line regarding what goes into GPX. Same goes for text on a map. I'm trying to solve the "green line" issue in a generic way that can be quickly understood and implemented by anyone. Take a look at http://www.topografix.com/gpx/gpx_style/0/2/gpx_style.xsd <line>, <fill>, and <text> ought to make some sense. Text on a map seems generic enough to me that others might want to work on a common specification. If there really is no other interest in this, then I would be happy to go off and implement it as part of my private schema. -- Dan Foster
egroups+topografix.com on Tue Nov 23 13:24:33 2004 (link), replying to msg
Hello, Tuesday, November 23, 2004, 3:21:01 PM, Troy wrote: T> But, for the sake of discussion: What would a text label accomplish? Why not T> just use the description field? Would a text label have a latitude and T> longitude to determine where it appears on the map? http://www.topografix.com/gpx/samples/topografix/waypoint_labels.png Here are two waypoints. "Campground" has a default text label (text to the right of the map icon). "Hot Springs" was too close to the other waypoint, and so the label has been positioned away from the icon. Just to make things interesting I gave it a larger font size, made it bold-italic, and used a serif font. Here's the validated GPX output: http://www.topografix.com/gpx/samples/topografix/labels.gpx Schemas used: GPX 1.1 gpx_style 0.2 (proposed - handles fonts, colors, lines, and fills) gpx_overlay 0.2 (proposed - handles text labels) T> I'm working on an app to display maps based on GPX data. I've found the T> description field to be plenty for my needs. For the moment I'm just using the <desc> field for the text of the label, just like Troy is. If you've loaded a GPX file authored by Dave W or Doug A, though, you'll get a pretty big text label! Those guys include some pretty detailed descriptions in their files (and that's a great thing). Having a way to specify the label text explicitly would probably be helpful. T> One key thing to remember when comparing GPX with TOPO and other proprietary T> formats is those formats are not designed for exchanging GPS data, but T> rather for rendering their own proprietary maps. If you look at the Topo! MapXchange site, which is a site for Topo! users to exchange data files, you'll see that 99% of the files being exchanged are .tpo, which includes colored tracklogs and text notes and photos. The .tpg waypoint exchange format isn't being used, possibly because it just isn't descriptive enough for what people want to share. (It also only handles waypoints) If I was at National Geographic working on Topo!, and I was getting bombarded with requests to support a documented format for exchanging trail maps, I'd look at GPX and pass it over because it doesn't express any of the line and text attributes that make Topo! maps look good. It was my hope that if we collaborated on a few public sub-schemas that addressed some of the common needs of programs that rely on GPS data, we'd end up with a much richer sharing of data between programs. -- Dan Foster
robertlipe+usa.net on Tue Nov 23 14:07:10 2004 (link), replying to msg
Dan Foster wrote: > label, just like Troy is. If you've loaded a GPX file authored by > Dave W or Doug A, though, you'll get a pretty big text label! Those > guys include some pretty detailed descriptions in their files (and > that's a great thing). Having a way to specify the label text > explicitly would probably be helpful. But isn't this the double-edged sword that GPX has lived under all this time? Using <desc> as a label (and what renders nicely on your workstation with a 24 inch monitor doesn't work well so well on your cell fone) has pretty much the same problems as using <name> as a waypoint name - what works well for Cetus with giant names works poorly for a Banana. How do you allow unbounded expression in the bounded space of something you don't control? I'm not trying to be paradoxical; I'm just holding up the mirror of time to point out that we've been here before. Before - whether that was with icon descriptions or waypoint names - we've allowed the producer to be as expressive as they can be (as it sounds like DaveW or DougA are) and put the onus on the consumer to trim things to fit. Let's think about other prior art in the industry on this. [XH]TML's img/alt and table/summary tags come to mind as something that allows the producer to provide a 'dumbed down' version of the data that the consumer can choose to use in environments where that's a problem. Should we consider something analagous, but providing guidelines for that alternate tag? That seems more natural than the <do_not_send_this_element_to_the_gps /> tag as the data is an alternate representation of <desc>. > users to exchange data files, you'll see that 99% of the files being > exchanged are .tpo, which includes colored tracklogs and text notes It's also the default of the new versions. RJL P.S. My reading material for this holiday weekend is "Real World XML" so I reserve the right to backpedal next week. :-)
egroups+topografix.com on Tue Nov 23 14:31:21 2004 (link), replying to msg
Hello, Tuesday, November 23, 2004, 5:06:38 PM, Robert wrote: R> Dan Foster wrote: >> Having a way to specify the label text explicitly would probably be helpful. Robert wrote: R> Using <desc> as a label (and what renders nicely on your workstation R> with a 24 inch monitor doesn't work well so well on your cell fone) has R> pretty much the same problems as using <name> as a waypoint name I think we're arguing the same point. As far as I can tell, you're making the statement that guessing which field to display as a map label can get you into trouble. I agree. <desc> is "A text description of the element. Holds additional information about the element intended for the user, not the GPS." (GPX 1.1 schema) It doesn't say anything about <desc> being a label. If the GPX waypoint had some <label> tag included in it, then we can assume that the user really wants us to display that exact text on the map as a label. If it doesn't, we're back to guessing what field we should use instead. Having a way to specify the label text explicitly would probably be helpful. Something like: <text xmlns="http://www.topografix.com/GPX/gpx_overlay/0/2" lat="42" lon="71"> <label>Hot Springs</label> </text> R> Should we consider something analagous, but providing guidelines for R> that alternate tag? R> That seems more natural than the <do_not_send_this_element_to_the_gps /> R> tag as the data is an alternate representation of <desc>. So you'd be happier with text on a map looking something like this? <text xmlns="http://www.topografix.com/GPX/gpx_overlay/0/2" lat="42" lon="71"> <label>Hot Springs</label> </text> -- Dan Foster
robertlipe+usa.net on Tue Nov 23 14:58:40 2004 (link), replying to msg
> I think we're arguing the same point. As far as I can tell, you're > making the statement that guessing which field to display as a map > label can get you into trouble. I agree. <desc> is "A text I think we're on _almost_ the same point. Between name, desc, and text, we already have a couple of choices (and the code in GPSBabel that figures out the "best" to use looks like hell) of names for things. We do have prior art for yet _another_ alternative representation, but where does it end? Should it end? We already have "really short" "pretty short" and "go nuts" covered. :-) > R> That seems more natural than the <do_not_send_this_element_to_the_gps /> > R> tag as the data is an alternate representation of <desc>. > > So you'd be happier with text on a map looking something like this? > <text xmlns="http://www.topografix.com/GPX/gpx_overlay/0/2" lat="42" lon="71"> > <label>Hot Springs</label> > </text> I'm sure you weren't seriously proposing the original tag name, but yes, that seems less icky to me. Like others, though, I wonder if growing GPX to become an ESRI shapefile replacement is practical. RJL
feedback+gpxchange.com on Tue Nov 23 19:29:09 2004 (link)
I'm in agreement with Dan. GPX should include the style and annotation functions found in popular consumer GPS enabled software applications. Tens of thousands of users regularly make use of programs such as ExpertGPS, NG TOPO!, etc. They do so to make their GPS data visually understandable and embellished to the degree that it can be used to produce stand-alone maps or maps that are to be used in concert with the basic GPS data contained within. Users and publishers, are anxious to have a common format whereby this "information" can be shared and distributed for use by interested persons using the software application of their choice. Many of my friends have rich "GPS-centric" files that I would love to use, but my preferred application won't open their proprietary data format or I am forced to import a common stripped down format. That sucks. We're not talking about GIS here. We're talking about a way of conveying the GPS data that makes it more useful for the common Joe (or Betty.) Wouldn't it be nice to have your color receiver show your tracks on screen in different colors or with different line styles? Or, why not have the ability to upload polygons that depict hunting boundaries or property lines? Or how about text annotation in a general area that describes a specific danger, etc. Surely these things can be geographically described and their basic location data is often captured with a simple handheld GPS. Eventually we'll be able to have this kind of relevant data displayed on mapping receivers, but at least for now we can print maps or share files that are richened with this information. I've got to tell you, opening a file and seeing a track that represents a 4WD road means a lot more to me than seeing a breadcrumb line. Private schemas are not the answer for the basic kind of elements we're talking about here. Breaking this basic information out into private schemas will only slow the availability of the data and keep what could be great shared information locked up in proprietary formats. Certainly there are countless elements which are so specialized that they belong in private schemas, but what I've heard Dan describe as his plans for annotating within ExpertGPS should be adopted within GPX itself. Any developer who choses to ignore certain elements can do so at his choosing. Parse any subset of data you choose. Let's not short change to promise of GPX without carefully considering the opportunities that a richer schema offers.
davewissenbach+yahoo.com on Tue Nov 23 20:09:37 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > > I'm in agreement with Dan. GPX should include the style and > annotation functions found in popular consumer GPS enabled software > applications. Tens of thousands of users regularly make use of > programs such as ExpertGPS, NG TOPO!, etc. They do so to make their > GPS data visually understandable and embellished to the degree that > it can be used to produce stand-alone maps or maps that are to be > used in concert with the basic GPS data contained within. > > Users and publishers, are anxious to have a common format whereby > this "information" can be shared and distributed for use by > interested persons using the software application of their choice. > Many of my friends have rich "GPS-centric" files that I would love > to use, but my preferred application won't open their proprietary > data format or I am forced to import a common stripped down format. > That sucks. > > We're not talking about GIS here. We're talking about a way of > conveying the GPS data that makes it more useful for the common Joe > (or Betty.) > > Wouldn't it be nice to have your color receiver show your tracks on > screen in different colors or with different line styles? Or, why > not have the ability to upload polygons that depict hunting > boundaries or property lines? Or how about text annotation in a > general area that describes a specific danger, etc. Surely these > things can be geographically described and their basic location data > is often captured with a simple handheld GPS. Eventually we'll be > able to have this kind of relevant data displayed on mapping > receivers, but at least for now we can print maps or share files > that are richened with this information. I've got to tell you, > opening a file and seeing a track that represents a 4WD road means a > lot more to me than seeing a breadcrumb line. > > Private schemas are not the answer for the basic kind of elements > we're talking about here. Breaking this basic information out into > private schemas will only slow the availability of the data and keep > what could be great shared information locked up in proprietary > formats. Certainly there are countless elements which are so > specialized that they belong in private schemas, but what I've heard > Dan describe as his plans for annotating within ExpertGPS should be > adopted within GPX itself. Any developer who choses to ignore > certain elements can do so at his choosing. Parse any subset of data > you choose. > > Let's not short change to promise of GPX without carefully > considering the opportunities that a richer schema offers. Well, at one point I thought that GML was the way to go, and downloaded all 500 or so odd-pages of the documentation. What a thud! We do need better presentation. Experiment with GPS Visualizer to produce SVG and see what you can do with the resulting interactive output. You can move labels so that the labels are not on top of each other, and move tracks to sensible positions. Now consider adding a trail to a network of 25 or 30 trails and regenerating the SVG or using a conversion tool to output to the various mapping programs. All of this work needs to be done over again, because the source gpx file did not include the presentation aspects. I would suggest that for now we develop the best practices for presentation as extensions in separate public extension namespaces so that we continue to provide the basic functions of GPS Exchange while GPX1.2 ages a bit and gains marketplace acceptance. If the gpx standard becomes too volatile it ceases to be useful to commercial developers because of the excessive costs of software development and maintenance. Using separate namespaces for presentation will protect the base standard against this volatility. Of cource there should be a gpx 2.0 eventually, but the time frame for this should be in a couple of years, not right now, IMHO. Regards, Dave Wissenbach
egroups+topografix.com on Wed Nov 24 06:33:50 2004 (link), replying to msg
Hello, Tuesday, November 23, 2004, 11:07:49 PM, David S. Wissenbach wrote: D> I would suggest that for now we develop the best practices for D> presentation as extensions in separate public extension namespaces D> so that we continue to provide the basic functions of GPS Exchange D> while GPX1.2 ages a bit and gains marketplace acceptance. I think you mean GPX 1.1 here. D> If the gpx standard becomes too volatile it ceases to be useful to D> commercial developers because of the excessive costs of software D> development and maintenance. Using separate namespaces for D> presentation will protect the base standard against this volatility. D> Of cource there should be a gpx 2.0 eventually, but the time frame D> for this should be in a couple of years, not right now, IMHO. I agree entirely with what you've written. I just want to clarify that the gpx_style and gpx_overlay namespaces work today with the GPX 1.1 base schema and require no changes to the gpx schema or to any existing applications. The sample file I posted validates, and opens successfully in ExpertGPS, MapSource, and Wissenbach Map. http://www.topografix.com/gpx/samples/topografix/labels.gpx -- Dan Foster
azbithead+gmail.com on Wed Nov 24 15:15:36 2004 (link), replying to msg
Here's my $0.02: I completely agree with every comment Jeremy Irish has made on this topic. Go see his posts. Additionally, here's a hypothetical scenario: You buy a new GPS (hopefully a Garmin one) and hook it up to your PC to get some data in or out of it and, lo and behold, it talks GPX! The probability of that scenario actually happening increases inversely with the weight of the GPX schema. A heavier schema, i.e., one that has more and more optional fields, requires more processing power to parse even if the optional fields are not included in a particular instance. Processing power is a precious commodity in battery-powered, memory-limited devices. It is my opinion that GPX already has too much stuff in it. I'd like to see GPX 2.0 made lighter and new add-on schemas developed for related uses. - Steve
egroups+topografix.com on Wed Nov 24 17:31:20 2004 (link)
Hello, I apologize for starting yet another thread. But continuing this discussion under the subject "GPX 2.0" doesn't make much sense. I'm seeing a number of comments like these: (I'm paraphrasing) "GPX is too complicated" "GIS doesn't belong in GPX" "consider a Garmin GPS that talks GPX" Does the term "GPX" in these phrases actually mean the same thing to all of us? I get the feeling it doesn't. I'm having a hard time following some of the arguments presented because of this. I know what the "GPX schema" is: there are two of them http://www.topografix.com/gpx/1/0/gpx.xsd http://www.topografix.com/gpx/1/1/gpx.xsd I know what a "GPX file" is: it's an XML file that: 1. begins with a root element <gpx> 2. contains data from the GPX schema and any number of other schemas and 3. validates with SAXCount.exe A GPX file can contain GPS data, geocache logs, Cajun recipes, mapping information, and/or the Gettysburg Address, as long as it validates against the schemas it includes. "GPX is too complicated". I can only take this to mean that the GPX schema is too complicated. There's certainly nothing we can do to manage how complicated GPX files can be, since they can reference an infinite number of schemas. I hear this phrase repeated a lot, but I never hear suggestions as to what should be trimmed from the GPX schema to make it less complicated. "GIS doesn't belong in GPX" Again, this has to refer to the GPX schema. There aren't any rules as to what can go in a GPX file. geocaches, travel bugs, a complete reimplementation of GML are all fair game. Nobody is suggesting that GIS go into the GPX schema. It doesn't belong there. It belongs in an external schema. We all agree on this. "consider a Garmin GPS that talks GPX" I think Steve is referring to the GPX schema here, but I can't be sure. Certainly the GPX schema alone isn't sufficient to describe all of the attributes currently in the Garmin interface protocol. He makes the case for a lighter GPX schema so it can be processed by a battery-powered device. I hope he recognizes that a lighter GPX schema doesn't ensure smaller GPX files. Jeremy's geocaching GPX files (which are about 1% GPX 1.0 schema and 99% groundspeak schema) bring my ancient laptop to a grinding halt on occasion. As we continue the discussion, please keep in mind that "gpx schema" and "gpx file" are not synonymous terms, and that "GPX" alone only adds to the confusion. Happy Thanksgiving, everyone. -- Dan Foster - egroups+topografix.com
davewissenbach+yahoo.com on Thu Nov 25 05:39:10 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > I apologize for starting yet another thread. But continuing this > discussion under the subject "GPX 2.0" doesn't make much sense. > > I'm seeing a number of comments like these: (I'm paraphrasing) > "GPX is too complicated" > "GIS doesn't belong in GPX" > "consider a Garmin GPS that talks GPX" > Translations: The base gpx namespace is too complicated. GIS doesn't belong in the base gpx namespace. Consider a Garmin GPS which uses the base gpx namespace as its application layer protocol data format. > Does the term "GPX" in these phrases actually mean the same thing to > all of us? I get the feeling it doesn't. I'm having a hard time > following some of the arguments presented because of this. > > I know what the "GPX schema" is: > there are two of them > http://www.topografix.com/gpx/1/0/gpx.xsd > http://www.topografix.com/gpx/1/1/gpx.xsd > > I know what a "GPX file" is: > it's an XML file that: > 1. begins with a root element <gpx> > 2. contains data from the GPX schema and any number of other schemas > and > 3. validates with SAXCount.exe > A GPX file can contain GPS data, geocache logs, Cajun > recipes, mapping information, and/or the Gettysburg Address, as long > as it validates against the schemas it includes. > > > > "GPX is too complicated". I can only take this to mean that the GPX > schema is too complicated. There's certainly nothing we can do to > manage how complicated GPX files can be, since they can reference an > infinite number of schemas. > I hear this phrase repeated a lot, but I never hear suggestions as to > what should be trimmed from the GPX schema to make it less > complicated. > This might be a complain that the metadata belongs in an extensions namespace rather than in the base namepace. Other than that, I couldn't suggest why someone would say this. > > "GIS doesn't belong in GPX" > Again, this has to refer to the GPX schema. There aren't any rules as > to what can go in a GPX file. geocaches, travel bugs, a complete > reimplementation of GML are all fair game. > Nobody is suggesting that GIS go into the GPX schema. It doesn't > belong there. It belongs in an external schema. We all agree on > this. > Let's translate this as "Presentational hints which improve interoperability and data change for applications do not belong in the base GPS Exchange schema.". > > "consider a Garmin GPS that talks GPX" > I think Steve is referring to the GPX schema here, but I can't be > sure. Certainly the GPX schema alone isn't sufficient to describe all > of the attributes currently in the Garmin interface protocol. He > makes the case for a lighter GPX schema so it can be processed by a > battery-powered device. I hope he recognizes that a lighter GPX > schema doesn't ensure smaller GPX files. Jeremy's geocaching GPX > files (which are about 1% GPX 1.0 schema and 99% groundspeak schema) > bring my ancient laptop to a grinding halt on occasion. > > > As we continue the discussion, please keep in mind that "gpx schema" > and "gpx file" are not synonymous terms, and that "GPX" alone only > adds to the confusion. > I agree that this will clarify the discussion greatly. > > Happy Thanksgiving, everyone. > > -- > Dan Foster - egroups+t...
davewissenbach+yahoo.com on Thu Nov 25 06:30:53 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Jeremy Irish" <jeremy+g...> wrote: > "We're not talking about GIS here. We're talking about a way of conveying > the GPS data that makes it more useful for the common Joe (or Betty.)" > > > > We are talking about GIS here. GPX was designed for GPS data alone. If you > want to call it GIS lite, that's fine. But it is still GIS. Drawing pretty > lines and maps is GIS. > > > > "Wouldn't it be nice to have your color receiver show your tracks on screen > in different colors or with different line styles?" > > > > Oh my yes. I'm all tingly. Put it in a separate schema. > > This seems insulting without being constructive. A motorcycle rider on a mixed-use trail system which he has downloaded to his gps receiver might use the color coding to stay off the pedestrian-only trails. An most gps receivers these days do support color. So I'd say that if the intent of the base GPX Exchange format is to exchange data both to and from GPS receivers color does belong in the base standard. When you say put it in separate schema, do you mean to close the discussion. Perhaps presentational data specific to a model of gps receiver needs to go in an extension schema. The best way for you to defend a simple base schema might be to constructively suggest alternatives to the ideas discussed here. > > "Let's not short change to promise of GPX without carefully considering the > opportunities that a richer schema offers." > > > > Create a separate schema and market the heck out of it. But don't put it in > GPX 2.0. > I'd like to market the heck out of it under the gpx umbrella, which appears to have some value. So perhaps gpx2.0 is really gpx1.1 with a rich set of extension schemas. That's the dilemna. Your interests and my interests seldom converge. What we have now in the lightweight mapping application space are little fiefdoms where National Geographic, DeLorme, and formely Garmin all carve out a set of users and try to distribute data in their format. Having solved one problem (exhcnage of gps data) I'm ready to move on to the next. I accept your reservations about one heavyweight schema, and its good that we have this discussion. Perhaps we can agree on this principle. The base gpx schema should be as simple as possible. Still, I'd like be able to discuss this second problem, the application space for lightweight desktop mapping and trail data exchange here as well. This is not GIS. GIS implies a data base driving a mapping application. Probably a GIS system would generate a gpx/gpx_style/gpx_app file (we won't call this GPX2.0 so as not to affend anyone) that a browser or application would use. > > > The idea seems to be attempting to force a square peg in a round hole. > > > One thing I don't understand is the assumption that track data is in some > way a good way to distribute points of interest or map making. GPS track > data is the data logging function of GPS units. You walk and bread crumbs > show where you've been. Routes, on the other hand, indicate a path of > travel, but not really a "drawn" path of travel. Of course map data comes > from somewhere and track data is a good way to, say, hike a trail for > drawing an eventual path on a map. But you should convert that data to a > shapefile or other mapping resource format. > > I'm much more interested in the reverse process. For instance, I obtained a gpx file from a friend which logged his mountain bike trip on an obscure trail. I did print a map, but I also used the gpx file to follow that path. Just 3 days ago I was taken on a very convoluted route through a maze of logging roads in dense forest which will eventually become a trail for everyone to use. This trail is used to create a map, but has the dual use of being downloaded back into the gps receiver so that I and others can find our way back again. So track data is a very good way to distribute an intended path to follow. The GPS then points the way. I don't need to dig out the map at every turn, I just follow the arrow on the GPS. > > That's GIS. Perhaps GML is too bloated for the average person, so you should > come up with another namespace that simplifies this mapping functionality > you desire. Personally I'd rather try and find ways to simplify the GPX > schema instead of continuing to create bloat. XML is bloated as it is. For > example, instead of creating route points we should just reference existing > waypoints, mirroring the functionality of Garmin units. Route points and > waypoints seem redundant. > The garmin approach where routes don't define their own constituent routepoints seems to be a leftover from the days when we used to count transistors. > > > But whatever you do, Geocaching.com doesn't *have* to adopt 2.0. We're still > running 1.0 and it works fine since we add our own details in our own > namespace. And market the heck out of it. > That's why we have these discussions. No one should have to use gpx and its extension schemas, but if everyone wants to we have a basis for data exchange that is currently lacking. > > > And before you say that I don't care because I won't use 2.0, I do care > because it seems that the attempt is to lose scope on the original intent of > GPX. > > Things never work out exactly the way you thought they would. So let's try not to put too much on original intent. Please don't ignore the application space (what you call GIS). And in exchange those of us who live in that space will try to keep the exchange space pure and simple (and therefore useful.) > > Jeremy > > > > [Non-text portions of this message have been removed]
davewissenbach+yahoo.com on Thu Nov 25 09:49:10 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Tuesday, November 23, 2004, 11:07:49 PM, David S. Wissenbach wrote: > > D> I would suggest that for now we develop the best practices for > D> presentation as extensions in separate public extension namespaces > D> so that we continue to provide the basic functions of GPS Exchange > D> while GPX1.2 ages a bit and gains marketplace acceptance. > > I think you mean GPX 1.1 here. > I'm so confused. SVG1.2 is in its last call stages at the W3C. I did mean gpx 1.2 > D> If the gpx standard becomes too volatile it ceases to be useful to > D> commercial developers because of the excessive costs of software > D> development and maintenance. Using separate namespaces for > D> presentation will protect the base standard against this volatility. > > D> Of cource there should be a gpx 2.0 eventually, but the time frame > D> for this should be in a couple of years, not right now, IMHO. > > I agree entirely with what you've written. I'm not so sure I was correct, given the comments of the other stakeholders elsewhere! I just want to clarify > that the gpx_style and gpx_overlay namespaces work today with the GPX > 1.1 base schema and require no changes to the gpx schema or to any > existing applications. The sample file I posted validates, and opens > successfully in ExpertGPS, MapSource, and Wissenbach Map. > http://www.topografix.com/gpx/samples/topografix/labels.gpx Perhaps what we need are profiles for gpx which interact with these namespaces. There can a baseline exchange profile which uses gpx1.1 only, or its unadorned successor, gpx1.2. There already seems to be a default geocaching profile. There can be a logging profile for the runners, bikers and athletes which uses elements of the gpx_style. There can be a guide and storytelling profile for travel companies. And there can be a desktop mapping profile. I've already been contacted by a resource manager interested in mapping his 1200 acres whatever, and by a mountain bike club working with government agencies to develop a new trail system. Not everybody needs or wants to use a fullblown GIS system, at least at first. That's what SVG is doing. There is SVG tiny, SVG basic, SVG mobile, and an inactive SVG print profile. Each of these profiles can be developed by a separate working group of interested stakeholders. Thanks for the example which ties gpx_overlay and gpx_style together. I am working on two sample ski 3D area map where I will be designating ski runs and terrain areas. I want to use floating colored text to denote terrain areas by ability, rather than cluttering up the terrain with dasheded lines. I've learned more about Jackson Hole Ski Resort in 15 minutes of flying over in 3D than I know from 18 days of ski vacations there spread out over years! In this case the source map can be published as a 3D model, as an SVG map, or as a set of trails to a GPS receiver. Perhaps we can tag our posts under the appropriate profile or move this to a different yahoo group entirely. I'd like to stay in a big tent for now, though. Dave > > -- > Dan Foster
ptomblin+gmail.com on Thu Nov 25 10:14:30 2004 (link), replying to msg
I was a GIS programmer for 6 years. Back then it was a truism that you didn't mix up geography with presentation. The idea was that you had your geographic data, which told you what type of data it was representing, and you had your application (and the user customizations of that application), which decided how to present it. Your geographic data would have lines classified as "road" or "stream" or "property line", and it was your application that decided if roads were red and streams blue and property lines were invisible. Similarly, you might have a point feature with attributes like "address" and "tax assessment" and "school district" and it was up to the application whether it wanted to label it with the address or the school district or whatever. My point? That GPX should hold geographic data, not presentation data. It should be up to the application how to display the data based on the attributes. You don't want to put "display this line in red" because somebody else might want to display roads differently, or not display them at all. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
molund+gmail.com on Thu Nov 25 10:15:44 2004 (link), replying to msg
xhtml is probably one of the most widely accepted xml schemas. It is also freakin huge by schema standards. My point is that people don't learn html by looking at a schema. And nobody uses ALL the html tags. You learn html by going out and buying a book. Furthermore, I can still create an html page that only uses the <html>, <body>, <p>, and <h1> tags. It might not be nice to look at, but it is still valid. There may be no gpx book at this time (?), but it wouldn't be a huge stretch to create some simple examples (e.g. this is how you represent a simple track) . On Thu, 25 Nov 2004 17:49:06 -0000, David S. Wissenbach <davewissenbach+yahoo.com> wrote: > > That's what SVG is doing. There is SVG tiny, SVG basic, SVG mobile, > and an inactive SVG print profile. Each of these profiles can be > developed by a separate working group of interested stakeholders.
dananderson2+yahoo.com on Thu Nov 25 12:11:45 2004 (link)
I'm working on a product that consists of maps (term used loosely) and data for GPS receivers. At this time I'm not supplying the program so I'm trying to use existing programs. This will be a big problem for the user because of all the different file formats and feature sets of those programs. GPX was created, of course, to solve this problem. I'll supply GPX files but they will currently only supply a small subset of the information available. I also want to be able to display short pieces of text on the map and longer pieces of text in a separate window with a possible linkage from an icon on the map. You can do this currently with NG Topo! and OziExplorer. I also want to put small icons (images) on the map and also supply larger images that would open in a separate window. You can also do this with NG Topo! and OziExplorer. OziExplorer has its own file format for this map oriented data as does NG Topo! and all the other programs have their own file formats to the extent they support these features. So exchanging data is not easy between users. I haven't expected map-oriented data to be put into the GPX schema. But a common standard needs to be created. Perhaps GML would be suitable but could make things more complicated than need be. If GPX is currently bloated then surely GML is bloated for limited GIS. Also note that there are mapping GPS receivers out there that need map data. In other words, data for GPS receivers encompasses much more than just waypoints, routes, and tracks. Also I wouldn't be surprised to see more user control of how tracks are displayed in the GPS receiver in the future.
egroups+topografix.com on Fri Nov 26 04:20:43 2004 (link), replying to msg
Hello, Thursday, November 25, 2004, 1:13:45 PM, Paul wrote: P> My point? That GPX should hold geographic data, not presentation P> data. Did you mean GPX files should not hold presentation data, or that the base GPX schema should not hold presentation schema? -- Dan Foster
ptomblin+gmail.com on Fri Nov 26 07:41:25 2004 (link), replying to msg
On Fri, 26 Nov 2004 07:20:39 -0500, Dan Foster <egroups+topografix.com> wrote: > Thursday, November 25, 2004, 1:13:45 PM, Paul wrote: > > P> My point? That GPX should hold geographic data, not presentation > P> data. > > Did you mean GPX files should not hold presentation data, or that the > base GPX schema should not hold presentation schema? Personally, I don't think presentation data should be in the GPX file at all - like I said before, the presentation should be up to the application and the end user, not the provider of the data file. So if people insist on putting presentation data where it doesn't belong, it should not be in the base schema. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
dananderson2+yahoo.com on Fri Nov 26 09:26:33 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > I'd like to start a discussion about the best way to represent in GPX > objects that aren't meant to be sent to the GPS. A GPX file might > contain a tracklog and waypoints containing a hike, but it also might > include some text labels to display on the base map, and a filled polygon > noting the location of a pond that doesn't appear on the printed map. > The polygon-pond may have started out as a tracklog - perhaps I > walked the perimeter of the frozen pond with a GPS to record its > bounds. > > Many mapping programs allow the user to add text notes and photographs > to the map. They also allow the user to draw lines and filled shapes > to represent things like roads, fields, and food plots. Point objects > like text notes could be mapped to <wpt> in GPX. Lines and filled > shapes could be mapped to <rte> or <trk>. Should they? Or should > they have their own base types? IMHO they should have their own types and probably not be part of the GPX schema (GPX schema used only for data to be sent/received from the GPS receiver). [snip] Dan A.
dananderson2+yahoo.com on Fri Nov 26 09:46:53 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Tuesday, November 23, 2004, 12:37:05 PM, Michael wrote: > > M> While I agree that base maps are important, is that really what GPX is > M> for? GPX is "a light-weight XML data format for the interchange of > M> GPS data ". It is not "a general purpose XML format for creating > M> maps". Keep it simple so new developers can pick it up easily. > > "GPS data" stops being just GPS data as soon as it leaves the GPS > receiver. It becomes Jeremy Irish's geocaches, or Paul Tomblin's > aviation database, or Doug Adomatis' travel maps, or Backpacker > Magazine's GPS trail guides. When you look at the actual data that is > being exchanged, it's clear that the descriptions, photos, and other > metadata is equally as important as the lat/lon/ele/time data from the > GPS receiver. Yes, but some of the data received from the GPS receiver doesn't necessarily stop being "GPS data". It may get sent back to the GPS receiver. Other data may become "map data" never to be sent to a GPS receiver. > I think we're all in agreement that GPX should not become an > "everything and the kitchen sink" format. I personally feel that the > fact that there's no standard way to say "this tracklog should be > a green line" in GPX is a problem. Most of the other GPS data formats > (Ozi's .trk, Topo!'s .tpo, MapTech's .txf) can express this, and I > think that's a good measure of where to draw the line regarding what > goes into GPX. Same goes for text on a map. I think GPX should support any attributes that GPS data may have. > I'm trying to solve the "green line" issue in a generic way that can > be quickly understood and implemented by anyone. Take a look at > http://www.topografix.com/gpx/gpx_style/0/2/gpx_style.xsd > <line>, <fill>, and <text> ought to make some sense. > > Text on a map seems generic enough to me that others might want to > work on a common specification. If there really is no other interest > in this, then I would be happy to go off and implement it as part of > my private schema. > > -- > Dan Foster I would like to see a public "map annotation" schema that would allow the user to open one file for ease of use. If the GPX schema is only going to be for data destined or originated from a GPS receiver then a "map annotation" schema needs to be able to reference the GPX file and possibly also a data presentation file (styles/object types/attributes). Dan A.
dananderson2+yahoo.com on Fri Nov 26 10:23:28 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Troy Hopwood - DirtWorld.com" <troyh+d...> wrote: > I agree with Michael. Keep GPX simple as a means of exchanging gps data. > > But, for the sake of discussion: What would a text label accomplish? Why not > just use the description field? Would a text label have a latitude and > longitude to determine where it appears on the map? > > I'm working on an app to display maps based on GPX data. I've found the > description field to be plenty for my needs. > > One key thing to remember when comparing GPX with TOPO and other proprietary > formats is those formats are not designed for exchanging GPS data, but > rather for rendering their own proprietary maps. If you export a file from > TOPO! All you get is GPS data. This is where I feel GPX belongs. > > Troy I assume you're putting the text label in the description field of a waypoint. The description field of a waypoint is for information about the waypoint not text labels. Seems to me you're using GPX in a way you don't want to see it used. Labels belong in a map annotation schema. (By labels I don't mean text associated with waypoints, ie. names, comments, or description). Yes a "text label" would have coordinates for placing it on a map or a "text note" would have the coordinates for placing a symbol on the map that would link to the note. Dan A.
davewissenbach+yahoo.com on Fri Nov 26 10:57:24 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Michael Olund <molund+g...> wrote: > xhtml is probably one of the most widely accepted xml schemas. It is > also freakin huge by schema standards. My point is that people don't > learn html by looking at a schema. And nobody uses ALL the html tags. > You learn html by going out and buying a book. Furthermore, I can > still create an html page that only uses the <html>, <body>, <p>, and > <h1> tags. It might not be nice to look at, but it is still valid. > > There may be no gpx book at this time (?), but it wouldn't be a huge > stretch to create some simple examples (e.g. this is how you represent > a simple track) . > > > Well, I did that for GPX1.0. Just look in the files section of this group for TableRockBasic.gpx I guess we may need some gpx1.1 samples to remove the intimidation factor!
dananderson2+yahoo.com on Fri Nov 26 13:18:33 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > On Fri, 26 Nov 2004 07:20:39 -0500, Dan Foster <egroups+t...> wrote: > > Thursday, November 25, 2004, 1:13:45 PM, Paul wrote: > > > > P> My point? That GPX should hold geographic data, not presentation > > P> data. > > > > Did you mean GPX files should not hold presentation data, or that the > > base GPX schema should not hold presentation schema? > > Personally, I don't think presentation data should be in the GPX file > at all - like I said before, the presentation should be up to the > application and the end user, not the provider of the data file. So > if people insist on putting presentation data where it doesn't belong, > it should not be in the base schema. > Changed subject from "Re: Confusion over the term "GPX"?" I'd like to get a better idea of how you envision programs working. Lets say I supply a file, "SomeFile", containing 1,000 line/track segments with specified data types. There are 30 data types: DType1 through DType30. You open the file with "ProgramA" that supports line sizes, line types (dot, dash, solid, etc), and line colors. How is the program going to display each of the data types? ... Does the program ask the user for the size, type, and color for each of the data types above? Does this happen every time the file is opened or is this information then saved in a file for the next time "SomeFile" is opened? If programs are to have predefined data types is it good to have different programs give the same data type different attributes? So ProgramA might set DType1 to blue, dashed, and 2mm width, ProgramB might set DType1 to yellow, solid, and 5mm width, and ProgramC might set DType1 to green, dot, and 3mm width. Should word processing programs do the same thing? So I can make up a document with data types "heading", "subheading", "bodytext", etc. with ProgramWA. ProgramWA sets "heading" to size 16 and bold, "subheading to size 14 and regular, "bodytext" to size 10 and regular. I send the document to someone else (how about a printer?) who opens it with ProgramWB that sets "heading" to size 12 and bold, "subheading" to size 10 and italics, "bodytext" to size 9 and regular. Is this how the system is supposed to work? I think this subject needs some discussion. Dan A.
ptomblin+gmail.com on Fri Nov 26 14:01:52 2004 (link), replying to msg
On Fri, 26 Nov 2004 21:17:31 -0000, dananderson2 <dananderson2+yahoo.com> wrote: > --- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > > Personally, I don't think presentation data should be in the GPX file > > at all - like I said before, the presentation should be up to the > > application and the end user, not the provider of the data file. So > > if people insist on putting presentation data where it doesn't belong, > > it should not be in the base schema. > > > I'd like to get a better idea of how you envision programs working. > > Lets say I supply a file, "SomeFile", containing 1,000 line/track > segments with specified data types. There are 30 data types: DType1 > through DType30. Let's make it a more real world example. Lets say you have tracks with types "Major road", "minor road", "seasonal stream", "navigable river", "unnavigable stream", and "dry gulley". If your program is making a road map, it might decide to make the "major roads" red and thick and labelled with the "route number" attribute, the "minor roads" thin and brown also labelled from the attiributes, and not even show the water features except maybe the "navigable rivers". A program that was making hydrographic or topographic maps would display the water features differently. A program that was making orienteering maps would show everything, but not label them. > You open the file with "ProgramA" that supports line sizes, line types > (dot, dash, solid, etc), and line colors. How is the program going to > display each of the data types? ... It would depend on the program and the user. > Does the program ask the user for the size, type, and color for each > of the data types above? Does this happen every time the file is > opened or is this information then saved in a file for the next time > "SomeFile" is opened? Why should that be the concern of the supplier of geographic data. You supply the "ground truth", you don't tell them how to display it. > So ProgramA might set DType1 to blue, dashed, and 2mm width, ProgramB > might set DType1 to yellow, solid, and 5mm width, and ProgramC might > set DType1 to green, dot, and 3mm width. Yes, exactly. > Should word processing programs do the same thing? So I can make up a > document with data types "heading", "subheading", "bodytext", etc. > with ProgramWA. ProgramWA sets "heading" to size 16 and bold, > "subheading to size 14 and regular, "bodytext" to size 10 and regular. That's the way html used to work before the idiots at Netscape and Microsoft blurred the line between data and presentation and added ad-hoc presentation level tags like "<i>" and "<blink>". The HTML said that this text is header level 1 (H1), this text is header level 2, and this text is in a paragraph, and this text was in a ordered list. It was up to the individual and his web browser to decide whether H1 should be bolded and 20 point type or bright red and flashing or read out by a screen reader or put on a braille writer. > I send the document to someone else (how about a printer?) who opens > it with ProgramWB that sets "heading" to size 12 and bold, > "subheading" to size 10 and italics, "bodytext" to size 9 and regular. > Is this how the system is supposed to work? Word processors are concerned with presentation far more than with data. That's why they call it "What You See Is What You Get". -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
ed+topozone.com on Fri Nov 26 15:33:00 2004 (link)
Folks - I'm concerned that this conversation is generating more heat than light. I've been reluctant to chip in, but there are too many assertions being made that aren't necessarily so. The <I> tag existed in HTML before there were ANY idiots at Netscape (or any Netscape), but the GPX-related comments are more important. I think it would be good to provide some references along with the points made in this discussion. For example, I get detailed street map data from Tele Atlas/GDT, a very large data provider. As a geographic data supplier, they certainly do care about presentation, and provide both technical documentation and popular GIS software symbology files to go along with their data. They don't require anyone to use that symbology, but users would be pretty unhappy if they were provided with huge amounts of data and no hints at all on how to properly render it. Random color schemes don't cut it. Likewise, the USGS produces hundreds of pages of documentation on how geographic data is symbolized on topographic maps. This is helpful; they are another geographic data supplier that cares a LOT about symbology. If you use geographic data from the USGS you can render it any way you like, but it's nice to have a suggestion from the data producer, and it's nice to be able to replicate the appearance of a very popular format, even if you're using a subset of that data. To bring this into the GPS-specific world, there are data sets produced in the field with GPS that classify data quite finely; it's common to get a GPS waypoint file with a classification field holding a dozen or two different type classes. If I've got GPS point data representing 30 different wetland types, I might very well want to attach a standard set of symbology to go with it. Users want standard symbology. They also want to be able to override it. But I think the key point is that in the cases we're talking about the creator of the data may have a much better idea of how to symbolize it than the end user does. So why can't the creator provide that knowledge via GPX? As we've seen from the various data interchange formats created by National Geographic, etc., providers WILL offer this info. So I think the question is better thought of as "What are the advantages and disadvantages of including this presentation information in the GPX schema as opposed to in a different, complementary schema?" I have not heard much input on that distinction, and I think it would be very helpful. It would be especially helpful to focus on advantages and disadvantages specifically, rather than on whether GPX is "GIS" (whatever that means to you) or what our personal opinions are about whether something should be in GPX or not. Thanks! - Ed Ed McNierney President and Chief Mapmaker TopoZone.com / Maps a la carte, Inc. 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 Phone: +1 978 251-4242 Fax: +1 978 251-1396
davewissenbach+yahoo.com on Fri Nov 26 18:27:01 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Jeremy Irish" <jeremy+g...> wrote: > It seems to me that the undercurrent over the proposed additions to the GPX > base schema is because GPX has become more widely adopted within software > applications (in no small part to the use of GPX on geocaching.com). Because I'll give you credit for this, and in fact all ready have. I'm amazed at how many avid geocacher's there are, and how they realize how hard you've worked to support their hobby! > many applications are now adopting GPX it is far easier to push through > changes to the GPX schema than by creating a new schema that does "map > styling" - a term I discovered while investigating GML. Map styling is that > fuzzy area between GIS and map making that determines how map data is > presented... which seems to be the case here. Although it is the easy > solution to implement it in the base GPX schema it doesn't seem to be the > right one. > > I would make the recommendation to fork any map styling concepts into its > own XML namespace and develop the idea further - either creating a GML > "lite" version or create a totally new version like how this guy did maps: > > http://www.stirbitch.com/steve/smml/ > > Though use lat/lon instead of x/y values, of course. The idea here is that > the MSML or whatever you call it can live in harmony with GPX inside of a > *.gpx file and its own namespace. > > I have discovered that GML wasn't so much defined as a "map styling" > language as a spatial language - and not a well adopted either (much to do > with companies being satisfied with their own proprietary formats). They > recommend SVG but for your purposes (and franky, mine) we would be more > inclined to go with our own "map styling" namespace. > > Thoughts? You'll find a few examples of SVG output from original GPX data at gpstrailmaps.com. I have used both a global styling approach, where the data in the type field provides a hint as to what to draw. For instance, a track with type Expert Ski Run is drawn narrow and yellow, and a track with type Beginner Ski Run is drawn wide and green. This is roughtly the equivalent of the approach taken in the VML description above, I think. That is, the equivalent of a style sheet tranformation (but done with a mapping program because the style sheet transformation can't be used to convert Lat,Lon to UTM.) But I also provided, and have since taken out of WM3D, a style field which would directly alter the SVG style for a specific track. The result was that I was able to produce, in SVG, output which was much better looking, and more visually compelling, than the display in the program. That led me to the belief that presentation was just as important as the raw data in a document format. I think that both of these methods have their uses -- a) carrying meaning in the data file (This is raw data and presents an observation -- while I was carrying my gps receiver I noticed I was skiing through the trees, hence I call this an Expert Ski Run). Then we style all such trails. b) Add hoc styling, where I decide that I was on a pretty tough beginner ski run, so instead of coloring this blue for advanced or green for beginner I use aquamarine. a) arguably belongs in the gpx namespace. (I have a recurring proposal to add mode of travel and type of trail -- in GPX1.1 we now have type.) b) definitely belongs in an extension or styling namespace. I think that Dan is exactly on the right track (and way ahead of us) with the use of gpx_overlay and gpx_style namespaces. I also do believe that we agreed, about 200 messages ago, to use a separate namespace for style information. At about that time I read the gml thud and decided to stay away. By the way, there is more reading and research material on map styling available in the proceedings of the SVG Open conference for 2004. See http://www.svgopen.org/2004/proceedings_en.html I've not read any of this material. I think that we are filling a strong need here, to produce a cross- media publishing format for lightweight mapping data. (I publish to a GPS receiver, to a desktop 2D display, to SVG, to HTML through stylesheet extraction, and to a 3D virtual reality display) Eventually I will also publish trails on print and probably to the next VRML.) All can use the same lightweight document format, gpx + gpx_style + gpx_overlay as a source format. We did have discussion early on as to whether gpx was just an exchange or document format and decided to provide the extensions in any other namespace in order to resolve the dilemna. But I always have a little trouble keeping this concept straight, in part because my attention to this group is so sporadic. Dave Wissenbach
jasonic+nomadics.org on Fri Nov 26 18:55:28 2004 (link)
Hello, I'm just jumping in mid-thread here. Emerging from being unfortunately-too-busy-with-other-stuff-deep-lurk mode, so please excuse any redundancy in my comments. > I have discovered that GML wasn't so much defined as a "map styling" > language as a spatial language - and not a well adopted either (much to do > with companies being satisfied with their own proprietary formats). They > recommend SVG but for your purposes (and frankly, mine) we would be more > inclined to go with our own "map styling" namespace. > > Thoughts? Yes..hmmm I feel this is a very important topic.. Perhaps MacEachren's map usage [cube] space is a good way to get a handle on this. As he once wrote: "My position is that there is no single correct scientific, or non-scientific, approach to how maps work". source quote = http://www.geomatics.kth.se/PhD/licavhandling.pdf The usage model I have in mind is the conceptual tool one which assigns axes in three-space to plot various crucial map use attributes. The way I remember it, is:: ACCESS >> public vs. private DATA >> high vs. low PRESENTATION / BROWSABILITY >> static vs. dynamic Actually there is an online source image of the original at http://kartoweb.itc.nl/webcartography/webbook/ch03/ch03.htm which plots it like as: AUDIENCE >> public vs. private INTERACTION >> high vs. low DATA RELATIONS >> unknown vs. known The point is those six limit/directions define the six points of a cube. Map Use is then plotted within that space. Very nice technique one can apply widely and extend by swapping alternative axis attributes - namespaces if you will Map styling in my mind needs to embrace changing but contiguous map use space. Like the way film language informs editing techniques. Thus the map of a journey is actually an ordered sequence of map usage [name]spaces. Between source and destination we encounter different map spaces. The connectedness of those gives us the map of our full journey. An example: Let's start say with the highly personal space of your own home, then exit there via a small local map to a public transport hub [station, airport etc], then enter a specific orientation map guiding you to the correct gate, platform, train/plain etc. On the train/plain we have a seat number. We stay mainly put for N-hours with short detours to bathroom, buffet car etc. However we are also traversing a highly geographic map a the same time moving at Z-miles per hour perhaps with a fascinating and view though or above the earth. On debarking we return to a similar bureaucratically dominated space [passport/baggage control etc]. Then we might enter another public transport system like subway system where stations are mapped by equalized logistical or topological order in preference over spatial scaling reality. Take the blue line four steps and change to red line going uptown for 3 more stops. Now exit via very specific localized map, end of platform, up steps to east side of the street, round the corner, cross the piazza by the bronze horseman. next to the XYZ Conference hall is a cafe called "GPXSML Cafe". Find a table on the terrace. I'll meet you there at 4:15pm. etc The maps we need in life change styling demands continuously, with our personal needs at times demanding intense filtering/removal of data or topological reorganization with appropriate stylistic presentation. Less-is-more cartographic. But at other times the exact opposite is required: extra data, more-is-less overview map styles apply. At present there are almost no mapping systems or interfaces which do this. However film-language [Video/TV/Film/Motion Graphics] do this all the time and we accept the continuity implied, and/or changes of scene/time/pov quite easily. Map-language needs to do this also, especially as it embraces animation, temporal-spatial indexing, interactive dynamics, multi-user, multi-nodal contexts. TV weather maps are one of the few to tackle this somewhat. But still disconnected from the rest. So I argue yes please let's have for 'map-styling', but only usefully really if we also introduces a 'map-usage' markup. - Jason Jason Cunliffe [Nomadics]
dananderson2+yahoo.com on Fri Nov 26 22:24:21 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > On Fri, 26 Nov 2004 21:17:31 -0000, dananderson2 <dananderson2+y...> wrote: > > --- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > > > Personally, I don't think presentation data should be in the GPX file > > > at all - like I said before, the presentation should be up to the > > > application and the end user, not the provider of the data file. So > > > if people insist on putting presentation data where it doesn't belong, > > > it should not be in the base schema. > > > > > I'd like to get a better idea of how you envision programs working. > > > > Lets say I supply a file, "SomeFile", containing 1,000 line/track > > segments with specified data types. There are 30 data types: DType1 > > through DType30. > > Let's make it a more real world example. Lets say you have tracks > with types "Major road", "minor road", "seasonal stream", "navigable > river", "unnavigable stream", and "dry gulley". > > If your program is making a road map, it might decide to make the > "major roads" red and thick and labelled with the "route number" > attribute, the "minor roads" thin and brown also labelled from the > attiributes, and not even show the water features except maybe the > "navigable rivers". A program that was making hydrographic or > topographic maps would display the water features differently. A > program that was making orienteering maps would show everything, but > not label them. > > > You open the file with "ProgramA" that supports line sizes, line types > > (dot, dash, solid, etc), and line colors. How is the program going to > > display each of the data types? ... > > It would depend on the program and the user. > > > Does the program ask the user for the size, type, and color for each > > of the data types above? Does this happen every time the file is > > opened or is this information then saved in a file for the next time > > "SomeFile" is opened? > > Why should that be the concern of the supplier of geographic data. > You supply the "ground truth", you don't tell them how to display it. > > > > So ProgramA might set DType1 to blue, dashed, and 2mm width, ProgramB > > might set DType1 to yellow, solid, and 5mm width, and ProgramC might > > set DType1 to green, dot, and 3mm width. > > Yes, exactly. > > > Should word processing programs do the same thing? So I can make up a > > document with data types "heading", "subheading", "bodytext", etc. > > with ProgramWA. ProgramWA sets "heading" to size 16 and bold, > > "subheading to size 14 and regular, "bodytext" to size 10 and regular. > > That's the way html used to work before the idiots at Netscape and > Microsoft blurred the line between data and presentation and added > ad-hoc presentation level tags like "<i>" and "<blink>". The HTML > said that this text is header level 1 (H1), this text is header level > 2, and this text is in a paragraph, and this text was in a ordered > list. It was up to the individual and his web browser to decide > whether H1 should be bolded and 20 point type or bright red and > flashing or read out by a screen reader or put on a braille writer. > > > I send the document to someone else (how about a printer?) who opens > > it with ProgramWB that sets "heading" to size 12 and bold, > > "subheading" to size 10 and italics, "bodytext" to size 9 and regular. > > Is this how the system is supposed to work? > > Word processors are concerned with presentation far more than with > data. That's why they call it "What You See Is What You Get". Thanks for your response. As someone who likes to have a screen (window) background that is not bright white, I don't like web sites that force a white background on me when it isn't necessary. So up to a point, I agree with you. However I also see the need for a document to be presented as the creator intended, so I don't agree in total. Dan A.
gps_maps+travelbygps.com on Sat Nov 27 06:09:26 2004 (link)
(Pardon this long post. I'm always a bit reflective during the holidays.) About 5 years ago, when I first started looking into formats for publishing GPS data, I was hoping to find way to exploit Proximity Alarms. I still remember the first time I got a tickle out of my 12XL beeping and displaying "Arriving at [waypoint name]" I tried to be creative with my waypoint names, making the arrival messages more meaningful, but I kept bumping up against the 6 character imitation (and on another subject, I also realized the Waypoint Name field needed to be a concise alphanumeric code that associated the point with other related points). Oh, how I wanted detailed proximity alarm messages. Not only text messages, I envisioned proximity alarms as sound bytes and pictures. Imagine coming to a trail junction and having your handheld device prompt you with "Take the trail to the north and see the cliffs. Take the trail to the south and see the lake" while showing you scenic pictures of the cliffs and lake to help you make your decision. Imagine a walking tour in the historic district with a handheld device which narrated the tour showing pictures of hidden architectural details. Or perhaps a little more far fetched, imagine hearing a baby cry and being prompted to print out a coupon for pampers as you walk down isle 5 (of the open air market of course :) My idea was to provide media content for the companies that were developing the "location aware" hardware and software. At the time it seemed that PDAs were an ideal platform, but multi-media and GPS modules where pushing the limits of the palm-sized technology. Pushing the envelope were several companies struggling for marketshare, including a few which now litter roadside of the information highway, like GeoDiscovery.com and sherpa.com. At the turn of the century, Garmin, Magellan, and Lowrance were successfully marketing handheld GPS units to millions of recreational users in the post-SA era. By default, these dedicated GPS units would be the vehicles to propel my idea into realization. All that I needed was a common file format so that I didn't have to publish multiple versions of the same content. Enter Dan Foster's "power tools for your GPS' and the rest of recent history. While my maps and guides are enjoyed by many patrons, they are not what I had originally envisioned. Perhaps PDA technology is now ripe for this endeavor. I am specifically encouraged by wares for the PocketPC. So, to this group, I ask: To what extent does GPX now support Proximity Alarms, and what plans for the future of GPX include the activation (for lack of a better word) of media files based on current position? - Doug www.travelbygps.com
shelly22_jones+yahoo.com on Tue Nov 30 00:25:53 2004 (link)
Iam enjoying this for the past 3 months Why not you toooooo......... http://www.globalfreecalling.com/reg1.asp?refcode=pears dont forgot to send this link to your friends bye bye avail this oppurtunity and circulate to our friends who are spending lots of money in terms of calling cards . --------------------------------- Do you Yahoo!? The all-new My Yahoo! ? What will yours do? [Non-text portions of this message have been removed]
shelly22_jones+yahoo.com on Tue Nov 30 00:25:54 2004 (link)
Iam enjoying this for the past 3 months Why not you toooooo......... http://www.globalfreecalling.com/reg1.asp?refcode=pears dont forgot to send this link to your friends bye bye avail this oppurtunity and circulate to our friends who are spending lots of money in terms of calling cards . --------------------------------- Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. [Non-text portions of this message have been removed]
egroups+topografix.com on Thu Dec 02 06:51:11 2004 (link), replying to msg
Hello, Saturday, November 27, 2004, 9:09:16 AM, Doug wrote: D> About 5 years ago, when I first started looking into formats for D> publishing GPS data, I was hoping to find way to exploit Proximity D> Alarms. D> Not only text messages, I envisioned proximity alarms as sound D> bytes and pictures. Imagine coming to a trail junction and having D> your handheld device prompt you with "Take the trail to the north and D> see the cliffs. Take the trail to the south and see the lake" while D> showing you scenic pictures of the cliffs and lake to help you make D> your decision. Imagine a walking tour in the historic district with D> a handheld device which narrated the tour showing pictures of hidden D> architectural details. I share your interest in this idea. Others do, as well. I've been approached by several people wanting a "GPS tour guide" authoring tool and handheld software. D> So, to this group, I ask: D> To what extent does GPX now support Proximity Alarms, and what plans D> for the future of GPX include the activation (for lack of a better D> word) of media files based on current position? The GPS base schema says nothing about proximity alarms. The GPX file format allows extension schemas which could implement proximity alarms. As with everything else in GPX, nothing happens without someone advocating and "sponsoring" it. You may have just nominated yourself. In which case, I second the motion... :) OziExplorer and other moving-map programs implement three types of alarms: 1. Proximity alarms: triggered if you are less than a certain distance from a waypoint. 2. Area alarms: triggered if you enter a closed polygonal area ("you are now entering restricted military airspace", e.g.) 3. Anchor drift alarms: set at your current position; triggered if your current position is greater than a certain distance from the initial location. (e.g., your anchor line snapped overnight and you are drifting toward a reef) Other possible alarms might include: 4. Shallow-water: triggered if your supertanker's depth finder reports a depth less than 10 fathoms, e.g. 5. Speed-based: "you're going 50 in a 20MPH zone" 6. Elevation-based: "terrain ahead - pull up!" It seems to me that a generic "alarm" has a type (one of the numbers above) and an optional "action to take". What follows is "pseudo-GPX" - I'm leaving out the namespace declarations for external schemas (prox-alarm and action) and writing the rest from memory... Simple proximity alarm for GPS: since the GPS receiver can only do one thing (beep) when a proximity alarm occurs, there's no reason to specify an action. <wpt> <extensions> <prox-alarm radius="500.0"/> // 500 meters <extensions> </wpt> A fancier GPS tour guide could add all sorts of multimedia stuff <wpt> <extensions> <prox-alarm radius="500.0"> // 500 meters <action type="play_audio"> <link href="history_of_Washington_monument.mp3"/> </action> <action type="show_image"> <link href="Washington_monument_photo.jpg"/> </action> <action type="visit_url"> <link href="http://www.washington-info.com/about_the_monument.htm"/> </action> <extensions> </wpt> In summary: - what you want to do can (and should) be done by creating an extension schema. - an "alarm" schema can be generic enough to express the simple GPS receiver proximity alarm, and can be flexible enough to implement a "GPS tour guide" - the <link> element in the GPX base schema would be a good way to reference file-based multimedia elements. If you're willing to propose a schema for this, I'll certainly participate in the discussion and will likely implement it in my software in the future. -- Dan Foster
dananderson2+yahoo.com on Thu Dec 02 08:05:38 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: [snip] > In summary: > - what you want to do can (and should) be done by creating an > extension schema. > - an "alarm" schema can be generic enough to express the simple GPS > receiver proximity alarm, and can be flexible enough to implement a > "GPS tour guide" > - the <link> element in the GPX base schema would be a good way to > reference file-based multimedia elements. > > If you're willing to propose a schema for this, I'll certainly > participate in the discussion and will likely implement it in my > software in the future. > > -- > Dan Foster Perhaps a name more like "proximity actions" which includes both critical actions (alarms) and non-critical actions would be more appropriate? Note that some current mapping receivers can also display a text message ("next road") when using data stored in the mapping section of the receiver albeit by an unpublished, proprietary protocol (note that Garmin is selling third party map data even though someone violated their license agreement to make it). Dan A.
egroups+topografix.com on Thu Dec 02 08:55:26 2004 (link), replying to msg
Hello, Friday, November 26, 2004, 8:29:24 PM, Jeremy wrote: J> I would make the recommendation to fork any map styling concepts into its J> own XML namespace and develop the idea further J> The idea here is that J> the MSML or whatever you call it can live in harmony with GPX inside of a J> *.gpx file and its own namespace. J> I have discovered that GML wasn't so much defined as a "map styling" J> language as a spatial language - and not a well adopted either (much to do J> with companies being satisfied with their own proprietary formats). They J> recommend SVG but for your purposes (and franky, mine) we would be more J> inclined to go with our own "map styling" namespace. J> Thoughts? I agree completely. I think we're reaching consensus on some of the broader issues: 1. Very little belongs in the base GPX schema 2. "map styling" can be included in a GPX file, but it needs to have its own schema. 3. "map styling" is a hint from the data file provider on how the data should be presented. The rendering agent may choose to follow this hint, use the User's styling guidelines instead, or ignore it completely. 4. Having a "suggested styling hint" leads to richer data use than having no styling information at all. 5. "...the creator of the data may have a much better idea of how to symbolize it than the end user does." - Ed McNierney 6. GPX schemas and this discussion group should focus on how data is exchanged, rather than on the implementation details of how a rendering agent might display it. ("what, not how") -- Dan Foster
egroups+topografix.com on Thu Dec 02 08:55:26 2004 (link), replying to msg
Hello, Friday, November 26, 2004, 4:17:31 PM, Dan Anderson wrote: d> I'd like to get a better idea of how you envision programs working. d> If programs are to have predefined data types is it good to have d> different programs give the same data type different attributes? d> So ProgramA might set DType1 to blue, dashed, and 2mm width, ProgramB d> might set DType1 to yellow, solid, and 5mm width, and ProgramC might d> set DType1 to green, dot, and 3mm width. d> I think this subject needs some discussion. A few dozen posts back someone asked that we stick to the "what", not the "how". I'll slip into "how" mode for a moment... Cascading style sheets are a good analogy. If you send me a GPX file with "your style" and I open it in my program that defines "my style", and there are style conflicts, there are two possible outcomes: 1. "my style" gets preference over "your style". 2. "your style" gets preference over "my style". There are pros and cons to both outcomes. In the end it comes down to whether I feel I've got better taste in styling maps than you do. If the file is coming from Joe Shmoe, I'd choose #1. If it's coming from the USGS, I'd probably choose #2. As they say in Latin America, "De gustibus non disputandum est" (apologies to Dan Qualye) In my application, I'm defaulting to choice #1, but letting the GPX file and/or the user override that on a file-by-file basis to show the file styling as the creator intended. All of this is an implementation detail. GPX files and schemas should allow the data creator describe her data in a standard way. The end user can make her own decisions about whether or not to accept the data creator's styling suggestions. -- Dan Foster
gps_maps+travelbygps.com on Fri Dec 03 12:46:07 2004 (link), replying to msg
--- In Dan Foster wrote: > The GPX file > format allows extension schemas which could implement proximity > alarms. As with everything else in GPX, nothing happens without > someone advocating and "sponsoring" it. You may have just nominated > yourself. In which case, I second the motion... :) Dan, Thanks for the detailed reply and thoughtful consideration. I don't understand what you mean by "sponsoring" but consider me an advocate. I wouldn't know where to start developing an extension schema, but as a publisher, I will enthusastically offer ideas, beta test, adopt and promote programs that facilitate GPS-guided tours. - Doug www.travelbygps.com Travel by GPS Maps Waypoints and Tracks to Adventure
richard+memory-map.com on Sun Dec 05 14:58:18 2004 (link)
Hi, I have created the following simple GPX file, but it is failing the validator. The output from SAX2count is below. I wonder if someone can help me understand what the error means? <?xml version="1.0" encoding="ISO-8859-1"?> <gpx version="1.0" creator="Memory-Map 4.3.1.491 http://www.memory-map.com" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <wpt lat="42.2469500000" lon="-71.4618070000"> <name><![CDATA[AQUADUCT]]></name> <type><![CDATA[Dam]]></type> <desc><![CDATA[Aquaduct]]></desc> </wpt> </gpx> $ C:/tmp/xml_test/XERCES~1/bin/SAX2Count.exe test.gpx Error at file \\hp\shareddocs/test.gpx, line 11, char 7 Message: Element 'desc' is not valid for content model: '((ele,time,magvar,geo idheight,name,cmt,desc,src,url,urlname,sym,type,fix,sat,hdop,vdop,pdop ,ageofdgps data,dgpsid),)'
egroups+topografix.com on Sun Dec 05 17:40:34 2004 (link), replying to msg
Hello, Sunday, December 5, 2004, 5:58:16 PM, Richard wrote: r> I have created the following simple GPX file, but it is failing the r> validator. r> r> <type><![CDATA[Dam]]></type> r> <desc><![CDATA[Aquaduct]]></desc> r> $ C:/tmp/xml_test/XERCES~1/bin/SAX2Count.exe test.gpx r> Error at file \\hp\shareddocs/test.gpx, line 11, char 7 r> Message: Element 'desc' is not valid for content r> model: '((ele,time,magvar,geo r> idheight,name,cmt,desc,src,url,urlname,sym,type,fix,sat,hdop,vdop,pdop r> ,ageofdgps r> data,dgpsid),)' The error message tells you that your <desc> element is the problem. The <type> element that preceded it did not generate an error. The validator gave you a list of valid content for <wpt> - the key is that elements in this list must be listed *in order*. After seeing <type> in your input stream, the validator is now expecting one of the following: fix,sat,hdop,vdop,pdop,ageofdgps,data,dgpsid You need to output your elements in the exact order they appear in the schema. In your case, swap <desc> must come before <type>: <name><![CDATA[AQUADUCT]]></name> <desc><![CDATA[Aquaduct]]></desc> <type><![CDATA[Dam]]></type> The CDATA wrappers aren't needed for the example data you gave. Welcome to the group. Memory Map is an outstanding program! -- Dan Foster
egroups+topografix.com on Mon Dec 06 04:12:33 2004 (link), replying to msg
Hello, Friday, December 3, 2004, 3:45:24 PM, Doug wrote: D> I wouldn't know where to start developing an extension D> schema, but as a publisher, I will enthusastically offer ideas, beta D> test, adopt and promote programs that facilitate GPS-guided tours. Fair enough. If you can come up with a detailed description of what you'd like to be able to express in your GPX files, I will help by converting it to an external schema. -- Dan Foster
rich+testingrange.com on Mon Dec 06 07:04:38 2004 (link), replying to msg
> D> I wouldn't know where to start developing an extension > D> schema, but as a publisher, I will enthusastically offer ideas, beta > D> test, adopt and promote programs that facilitate GPS-guided tours. > > Fair enough. If you can come up with a detailed description of what > you'd like to be able to express in your GPX files, I will help by > converting it to an external schema. I feel that we are all publishers, and so we want tools to help us all manage our collection and creation, management, and presentation of geospatial data. I want tools to help as I attempt to create geospatially enabled narratives. Cheers, Rich
richard+memory-map.com on Mon Dec 06 07:36:37 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > ... the key is that elements in this list must be listed *in order*. Ahhhhh.... thank you! GPX has been on my wish list for a long time. The amount of published data out there is of benefit to us all, and I hope Memory-Map's support will help it reach critical mass.
egroups+topografix.com on Mon Dec 06 09:13:49 2004 (link)
Hello, There seems to be general consensus that an external schema for adding map presentation hints to GPX files is a good idea. My original proposal for style and overlay schemas got a pretty chilly reception. Here's the link to my proposed external schema for style information (fonts, text sizes, line widths, fill colors, etc): http://www.topografix.com/gpx/gpx_style/0/2/gpx_style.xsd I'd appreciate specific feedback on how to improve this schema. My goal is to get reach some agreement regarding this schema and gpx_overlay in the next four weeks. gpx_style is fairly straightforward and gpx_overlay is likely to spawn more discussion, so I'd like to get gpx_style squared away first. The only two elements which have units are line/width and text/size. The units for both are millimeters. Your comments, please. -- Dan Foster
dananderson2+yahoo.com on Mon Dec 06 11:51:21 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > There seems to be general consensus that an external schema for adding > map presentation hints to GPX files is a good idea. My original > proposal for style and overlay schemas got a pretty chilly reception. > Here's the link to my proposed external schema for style information > (fonts, text sizes, line widths, fill colors, etc): > http://www.topografix.com/gpx/gpx_style/0/2/gpx_style.xsd > > I'd appreciate specific feedback on how to improve this schema. My > goal is to get reach some agreement regarding this schema and > gpx_overlay in the next four weeks. gpx_style is fairly > straightforward and gpx_overlay is likely to spawn more discussion, so > I'd like to get gpx_style squared away first. > > The only two elements which have units are line/width and text/size. > The units for both are millimeters. > > Your comments, please. > > -- > Dan Foster Perhaps "dasharray" (pattern) should also be in millimeters. Would you explain your intentions for "gpxptType" under "textType" a bit? Thanks, Dan A.
egroups+topografix.com on Mon Dec 06 12:01:45 2004 (link), replying to msg
Hello, Monday, December 6, 2004, 2:50:05 PM, Dan A. wrote: d> Perhaps "dasharray" (pattern) should also be in millimeters. Good point. Yes, the units for dasharray are millimeters. Other graphics formats define dasharray as a multiplier against line width. So a line 3mm wide with a dash array of "10 20" would produce a stroke 3mm wide by 30mm long, and a space 60mm long. I'd prefer that they were treated as millimeters, so the example above would produce a stroke 3mm wide by 10mm long, and a space 20mm long. d> Would you explain your intentions for "gpxptType" under "textType" a bit? Oops. My intention is to delete that element. I've waffled back and forth about the best way to define a text label's position, but I'd like to keep all geometry out of gpx_style. gpx_overlay would be used to specify the location of the text label, and gpx_style would just describe how it is to be rendered (color, size, etc) Thanks for keeping me honest! -- Dan Foster
davewissenbach+yahoo.com on Mon Dec 06 19:32:12 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > There seems to be general consensus that an external schema for adding > map presentation hints to GPX files is a good idea. My original > proposal for style and overlay schemas got a pretty chilly reception. > Here's the link to my proposed external schema for style information > (fonts, text sizes, line widths, fill colors, etc): > http://www.topografix.com/gpx/gpx_style/0/2/gpx_style.xsd > > I'd appreciate specific feedback on how to improve this schema. My > goal is to get reach some agreement regarding this schema and > gpx_overlay in the next four weeks. gpx_style is fairly > straightforward and gpx_overlay is likely to spawn more discussion, so > I'd like to get gpx_style squared away first. > > The only two elements which have units are line/width and text/size. > The units for both are millimeters. > > Your comments, please. > The element text should not have a child with the same name text, just for aesthetic reasons. Perhaps you could use <label><text> Text should have a background color, and background opacity, in addition to the foreground color and opacity. The dasharray, now in millimeters, needs finer resolution. For a fine line, a minimum dash length of 1mm is too constraining. I think that this can be accomplished simply by adding a . to the list of allowed characters. Text size should always be interpreted as screen coordinates, and not device coordinates. We may need level-of-detail, even for these relatively simple maps, so that text doesn't crowd together too much at low zoom levels. Some of my trail maps have gotten pretty messy looking, but I prefer not to use the Scalable Vector Graphics approach that shrinks text to absurdly small sizes when mapping a large geographic area into a small display area. Regards, Dave Wissenbach > -- > Dan Foster
susan_rose21+yahoo.com on Tue Dec 07 04:35:31 2004 (link)
The real thing is here Get into the right place right now! Set your idea in motion with a Free Inventors Kit! http://tinyurl.com/6fyoc You can personally use this you can give it to anybody F_R_E_E signin. login and earn on...on...on.......with http://www.globalfreecalling.com/reg1.asp?refcode=pears
egroups+topografix.com on Tue Dec 07 09:38:25 2004 (link), replying to msg
Hello, Monday, December 6, 2004, 10:32:02 PM, Dave W. wrote: D> The element text should not have a child with the same name text, D> just for aesthetic reasons. Perhaps you could use <label><text> That's another element I meant to remove. The text style element should just contain the styling information and not the text itself. Some other object would contain both the text label and the text style. Similarly, the line style element doesn't contain the line description. A tracklog has a list of trackpoints defining the line, and a line style describing how the line should be drawn. D> Text should have a background color, and background opacity, in D> addition to the foreground color and opacity. Are you trying to describe something like a highway sign, which has white text on a green (rectangular) background? Or are you trying to describe outlined text (each letter has a color for the edge and a fill color for the inside of the glyph)? If you want to allow outlined text, then the background color really is an attribute of the text and should be in gpx_style:text. If you want to draw something like a highway sign text label for a waypoint, then what you really have is a label with a green fill and white text. It might look something like: (pseudo-GPX) <wpt...> <extensions> <gpx_overlay:label> <gpx_style:text>...white text...</gpx_style:text> <gpx_style:line>...1mm gold line...</gpx_style:line> // gold edge <gpx_style:fill>...green fill...</gpx_style:fill> // green background </gpx_overlay:label> </extensions> </wpt> Without jumping too far into gpx_overlay: label with text style: text overlay with no background box or color label with text style and fill style: text drawn over a background box D> The dasharray, now in millimeters, needs finer resolution. For a D> fine line, a minimum dash length of 1mm is too constraining. I think D> that this can be accomplished simply by adding a . to the list of D> allowed characters. Someone with actual knowledge of regular expressions would have to write that one for me. How do you prevent these invalid floating point numbers? 1..2 . 00.2 etc... My preference would be to give up on <xsd:pattern> and trying to match SVG exactly. (As far as I can tell, SVG's stroke-pattern is defined as "string") I'd be happy with something like: <dasharray>`// contains one or more <dash> <dash mark="0.2" space="3.44"> <dash mark="1.2" space="0.25"> </dasharray> Thoughts? Regular-expression volunteers? D> Text size should always be interpreted as screen coordinates, and D> not device coordinates. I understand how there is a difference between screen and device when the unit is pixels. How is there a difference when the unit is millimeters? If I'm sending a GPX file to a Web service for custom printing, there's no screen involved. D> We may need level-of-detail, even for these relatively simple maps, D> so that text doesn't crowd together too much at low zoom levels. D> Some of my trail maps have gotten pretty messy looking, but I prefer D> not to use the Scalable Vector Graphics approach that shrinks text D> to absurdly small sizes when mapping a large geographic area into a D> small display area. I'm glad you brought up level-of-detail. I'm implementing this as well, but thought it was too app-specific to include in a public GPX extension schema. Perhaps we can come up with a generic way to describe this. -- Dan Foster
davewissenbach+yahoo.com on Tue Dec 07 17:56:16 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Monday, December 6, 2004, 10:32:02 PM, Dave W. wrote: > > D> The element text should not have a child with the same name text, > D> just for aesthetic reasons. Perhaps you could use <label><text> > > That's another element I meant to remove. The text style element > should just contain the styling information and not the text itself. > Some other object would contain both the text label and the text > style. > That makes sense to me. > Similarly, the line style element doesn't contain the line > description. A tracklog has a list of trackpoints defining the line, > and a line style describing how the line should be drawn. > > D> Text should have a background color, and background opacity, in > D> addition to the foreground color and opacity. > > Are you trying to describe something like a highway sign, which has > white text on a green (rectangular) background? Or are you trying to > describe outlined text (each letter has a color for the edge and a > fill color for the inside of the glyph)? > > If you want to allow outlined text, then the background color really > is an attribute of the text and should be in gpx_style:text. > > If you want to draw something like a highway sign text label for a > waypoint, then what you really have is a label with a green fill and > white text. It might look something like: (pseudo-GPX) > <wpt...> > <extensions> > <gpx_overlay:label> > <gpx_style:text>...white text...</gpx_style:text> > <gpx_style:line>...1mm gold line...</gpx_style:line> // gold edge > <gpx_style:fill>...green fill...</gpx_style:fill> // green background > </gpx_overlay:label> > </extensions> > </wpt> > The above describes what I was thinking and will work just fine. > Without jumping too far into gpx_overlay: > label with text style: text overlay with no background box or color > label with text style and fill style: text drawn over a background box > > D> The dasharray, now in millimeters, needs finer resolution. For a > D> fine line, a minimum dash length of 1mm is too constraining. I think > D> that this can be accomplished simply by adding a . to the list of > D> allowed characters. > > Someone with actual knowledge of regular expressions would have to > write that one for me. How do you prevent these invalid floating point > numbers? > 1..2 > . > 00.2 > etc... > > My preference would be to give up on <xsd:pattern> and trying to match > SVG exactly. (As far as I can tell, SVG's stroke-pattern is defined > as "string") > > I'd be happy with something like: > <dasharray>`// contains one or more <dash> > <dash mark="0.2" space="3.44"> > <dash mark="1.2" space="0.25"> > </dasharray> > The above is verbose, but unambiguous and easy to parse. Fits the XML model perfectly. > D> Text size should always be interpreted as screen coordinates, and > D> not device coordinates. > > I understand how there is a difference between screen and device when > the unit is pixels. How is there a difference when the unit is > millimeters? > > If I'm sending a GPX file to a Web service for custom printing, > there's no screen involved. > Let me clarify what I meant. In display space, whether screen or printer, 12 point text should always be 1/6 of an inch high, regardsless of zoom level. > D> We may need level-of-detail, even for these relatively simple maps, > D> so that text doesn't crowd together too much at low zoom levels. > D> Some of my trail maps have gotten pretty messy looking, but I prefer > D> not to use the Scalable Vector Graphics approach that shrinks text > D> to absurdly small sizes when mapping a large geographic area into a > D> small display area. > > I'm glad you brought up level-of-detail. I'm implementing this as > well, but thought it was too app-specific to include in a public GPX > extension schema. Perhaps we can come up with a generic way to > describe this. > I've seen references to level of detail in conversations related to SVG and mapping. I'm not sure that I'll ever implement level of detail in WM3D, but this seems to be a good application feature. If gpx_style and gpx_overlay are a method of making application data interchangeable, I think that level of detail is appropriate. I've seen gpx implemented in cell phone applications now, and on a small screen I suspect that LOD is very important. My first instinct would be to implement LOD as a map scale value above which the element to which LOD is applied disappears. <gpx_style:lod max_scale="24000.0"/> > -- > Dan Foster
egroups+topografix.com on Mon Dec 13 14:33:26 2004 (link), replying to msg
Hello, I've updated the gpx_style schema with all the suggestions that were offered. (I thought Dave W's level of detail was better placed in gpx_overlay - so I put it there). I added documentation for all of the elements. Assuming no changes to gpx_style come up in the gpx_overlay discussion, I will propose that we finalize this schema and give it a 1.0 version number. Schema: http://www.topografix.com/gpx/gpx_style/0/2/gpx_style.xsd Documentation: http://www.topografix.com/gpx/gpx_style/0/2/ -- Dan Foster
egroups+topografix.com on Wed Dec 15 14:02:17 2004 (link)
Hello, I've updated the gpx_overlay 0.2 schema and created documentation for it. I've also created a sample GPX file demonstrating a possible use of gpx_style and gpx_overlay in a GPX file. Schema: http://www.topografix.com/gpx/gpx_overlay/0/2/gpx_overlay.xsd Documentation: http://www.topografix.com/gpx/gpx_overlay/0/2/ (note that most of the elements in gpx_overlay are drawn in from the main GPX schema and gpx_style. You'll need to refer to those documentation links as you go. The documentation generator I use doesn't handle cross-schema links.) Sample file: http://www.topografix.com/gpx/samples/topografix/overlay.gpx "Example file showing a route defining the bounds of a farm field. gpx_overlay is used to place a label with the field's area in the center of the field. gpx_style is used to display a dotted boundary around a hatched fill pattern" A quick walkthrough: gpx_overlay contains two elements: lod (level of display) and text. lod defines a maximum scale at which the parent object is to be displayed on a map. It is used to keep the screen from getting too cluttered. The following waypoint displays on a 1:24000 scale topo map, but is hidden when viewing a 1:100000 scale overview map. <wpt> ... <lod max_scale="24000"/> ... </wpt> <text> defines a text overlay. This could be a waypoint label, a text note on a map, or maybe part of a map legend. <text> contains: lat/lon attributes defining the location of the overlay. <text> - a text string (the actual text to display) <gpx_style:text> - optional styling info <align> and <vertical-align> - aligns the overlay relative to the parent. (a waypoint label might be center aligned below the waypoint symbol on the map) <derived_from> - a hint to the receiving application on where the display text actually came from. This can indicate a data field in the parent GPX object: <text>The White House</text> <derived_from>desc</derived_from> this means that the label text is really just a copy of what's in the waypoint's Description field. If that changes, the text label should change too. <text>120 acres</text> <derived_from>area</derived_from> this means that the label text was calculated based on the area of the parent route. If the route changes, the area should be recalculated and used as the label text. <text>The White House</text> <derived_from>wissenbach:foo</derived_from> My program has no idea what wissenbach:foo is, so I'll just display the text and not worry about it. A receiving program can match <derived_from> against a list of values it recognizes, and implement "smart labels" that update as their parents change. Comments? -- Dan Foster - egroups+topografix.com
dananderson2+yahoo.com on Wed Dec 15 17:29:47 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > I've updated the gpx_overlay 0.2 schema and created documentation for > it. I've also created a sample GPX file demonstrating a possible use > of gpx_style and gpx_overlay in a GPX file. > > Schema: > http://www.topografix.com/gpx/gpx_overlay/0/2/gpx_overlay.xsd > > Documentation: > http://www.topografix.com/gpx/gpx_overlay/0/2/ > (note that most of the elements in gpx_overlay are drawn in from the > main GPX schema and gpx_style. You'll need to refer to those > documentation links as you go. The documentation generator I use > doesn't handle cross-schema links.) > > Sample file: > http://www.topografix.com/gpx/samples/topografix/overlay.gpx > "Example file showing a route defining the bounds of a farm field. > gpx_overlay is used to place a label with the field's area in the > center of the field. gpx_style is used to display a dotted boundary > around a hatched fill pattern" > > > A quick walkthrough: > gpx_overlay contains two elements: lod (level of display) and text. > lod defines a maximum scale at which the parent object is to be > displayed on a map. It is used to keep the screen from getting too > cluttered. > The following waypoint displays on a 1:24000 scale topo map, but is > hidden when viewing a 1:100000 scale overview map. > <wpt> > ... > <lod max_scale="24000"/> > ... > </wpt> > > > <text> defines a text overlay. This could be a waypoint label, a text > note on a map, or maybe part of a map legend. > <text> contains: > lat/lon attributes defining the location of the overlay. > <text> - a text string (the actual text to display) > <gpx_style:text> - optional styling info > <align> and <vertical-align> - aligns the overlay relative to the > parent. (a waypoint label might be center aligned below the waypoint > symbol on the map) > <derived_from> - a hint to the receiving application on where the > display text actually came from. This can indicate a data field in > the parent GPX object: > > <text>The White House</text> > <derived_from>desc</derived_from> > this means that the label text is really just a copy of what's in the > waypoint's Description field. If that changes, the text label should > change too. > > <text>120 acres</text> > <derived_from>area</derived_from> > this means that the label text was calculated based on the area of > the parent route. If the route changes, the area should be > recalculated and used as the label text. > > <text>The White House</text> > <derived_from>wissenbach:foo</derived_from> > My program has no idea what wissenbach:foo is, so I'll just display > the text and not worry about it. > > A receiving program can match <derived_from> against a list of values > it recognizes, and implement "smart labels" that update as their > parents change. > > > Comments? > -- > Dan Foster I'm a bit frazzled from the last 2.5 days but here's some initial thoughts and some items I've mentioned before: On alignment: I think I would take "alignment" to be relative to the parent object if that makes sense or relative to some other object that makes sense. Hopefully there aren't multiple objects that make sense or there might be some interesting resultsresults - just thinking ultimately needs more explanation/clarification. I think of the waypoint symbol and the waypoint name as part of the same (parent) object (waypoint). In this case the symbol is displayed (probably centered at the given coordinates) and whatever associated text displayed nearby. So it makes sense to display the text relative to the symbol. "AllTopo" does this by specifying which direction from the symbol and the distance using "N, E, S, W, NE, SE, SW, NW, Center" etc. "Align" and "vertical-align" will do this well. "AllTopo" can also apply a rotation to the text. Other possible attributes of text: rotation and distance from the object it is relative to. I'd like to see two types of "text". One is as currently described in overlay that is displayed on the map at the coordinates given. I tend to think of this type as "label". I see using this for mileages next to trails, the names of trails, parks, etc. The other type of text is not intended to be shown on the map but is to be displayed in some sort of separate window. I think of this type as "notes" because the quantity of text is on the larger side and would obscure too much of the map if placed on it. The latest versions of Nat'l. Geographic's TOPO! is a good example. Similar to the two types of text, I would like to see the same for images. One would be a "map graphic" type that is overlaid on the map at the coordinates given for things like arrows, parking symbols, etc. The other type of image, "a picture", would probably be larger and intended to be displayed separate from the map (in another window). Both "notes" and "pictures" may have optional items such as a "map graphic" that displays on the map and links back to the "note" or "picture". This could also be a "label", "waypoint", "track", etc. Double clicking (or however the app. wants to do it) on the item on the map would bring up the note or picture. An afterthought - a line type to display a linear object on the map similar to tracks but not intended to be sent to a GPS receiver. I could see trails done as "tracks" which would also be intended to be sent to a receiver but a parking lot outline done with this line type. As it stands now, I'm drawing with "tracks" and the user has to select which "tracks" to download to the receiver. Not necessarily a problem but it would be nice to have "lines" not likely to be sent in a separate category. Dan A.
davewissenbach+yahoo.com on Wed Dec 15 19:44:59 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "dananderson2" <dananderson2+y...> wrote: > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Hello, > > > > I've updated the gpx_overlay 0.2 schema and created documentation for > > it. I've also created a sample GPX file demonstrating a possible use > > of gpx_style and gpx_overlay in a GPX file. > > > > Schema: > > http://www.topografix.com/gpx/gpx_overlay/0/2/gpx_overlay.xsd > > > > Documentation: > > http://www.topografix.com/gpx/gpx_overlay/0/2/ > > (note that most of the elements in gpx_overlay are drawn in from the > > main GPX schema and gpx_style. You'll need to refer to those > > documentation links as you go. The documentation generator I use > > doesn't handle cross-schema links.) > > > > Sample file: > > http://www.topografix.com/gpx/samples/topografix/overlay.gpx > > "Example file showing a route defining the bounds of a farm field. > > gpx_overlay is used to place a label with the field's area in the > > center of the field. gpx_style is used to display a dotted boundary > > around a hatched fill pattern" > > > > > > A quick walkthrough: > > gpx_overlay contains two elements: lod (level of display) and text. > > lod defines a maximum scale at which the parent object is to be > > displayed on a map. It is used to keep the screen from getting too > > cluttered. > > The following waypoint displays on a 1:24000 scale topo map, but is > > hidden when viewing a 1:100000 scale overview map. > > <wpt> > > ... > > <lod max_scale="24000"/> > > ... > > </wpt> > > > > > > <text> defines a text overlay. This could be a waypoint label, a text > > note on a map, or maybe part of a map legend. > > <text> contains: > > lat/lon attributes defining the location of the overlay. > > <text> - a text string (the actual text to display) > > <gpx_style:text> - optional styling info > > <align> and <vertical-align> - aligns the overlay relative to the > > parent. (a waypoint label might be center aligned below the waypoint > > symbol on the map) > > <derived_from> - a hint to the receiving application on where the > > display text actually came from. This can indicate a data field in > > the parent GPX object: > > > > <text>The White House</text> > > <derived_from>desc</derived_from> > > this means that the label text is really just a copy of what's in the > > waypoint's Description field. If that changes, the text label should > > change too. > > > > <text>120 acres</text> > > <derived_from>area</derived_from> > > this means that the label text was calculated based on the area of > > the parent route. If the route changes, the area should be > > recalculated and used as the label text. > > > > <text>The White House</text> > > <derived_from>wissenbach:foo</derived_from> > > My program has no idea what wissenbach:foo is, so I'll just display > > the text and not worry about it. > > > > A receiving program can match <derived_from> against a list of values > > it recognizes, and implement "smart labels" that update as their > > parents change. > > > > > > Comments? > > -- > > Dan Foster > > I'm a bit frazzled from the last 2.5 days but here's some initial > thoughts and some items I've mentioned before: > > On alignment: > I think I would take "alignment" to be relative to the parent object > if that makes sense or relative to some other object that makes sense. > Hopefully there aren't multiple objects that make sense or there > might be some interesting resultsresults - just thinking ultimately > needs more explanation/clarification. > > I think of the waypoint symbol and the waypoint name as part of the > same (parent) object (waypoint). In this case the symbol is displayed > (probably centered at the given coordinates) and whatever associated > text displayed nearby. So it makes sense to display the text relative > to the symbol. "AllTopo" does this by specifying which direction from > the symbol and the distance using "N, E, S, W, NE, SE, SW, NW, Center" > etc. "Align" and "vertical-align" will do this well. "AllTopo" can > also apply a rotation to the text. > > Other possible attributes of text: rotation and distance from the > object it is relative to. > > I'd like to see two types of "text". One is as currently described in > overlay that is displayed on the map at the coordinates given. I tend > to think of this type as "label". I see using this for mileages next > to trails, the names of trails, parks, etc. > > The other type of text is not intended to be shown on the map but is > to be displayed in some sort of separate window. I think of this type > as "notes" because the quantity of text is on the larger side and > would obscure too much of the map if placed on it. The latest > versions of Nat'l. Geographic's TOPO! is a good example. > How is this different from the description field currently included in the various elements? > Similar to the two types of text, I would like to see the same for > images. One would be a "map graphic" type that is overlaid on the map > at the coordinates given for things like arrows, parking symbols, etc. > For ease of implementation and data transfer, the format of this graphic should be jpeg or png. width and height. > The other type of image, "a picture", would probably be larger and > intended to be displayed separate from the map (in another window). > Currently we do that with links attached to waypoints. Possibly this is implemented as links attached to overlay objects. > Both "notes" and "pictures" may have optional items such as a "map > graphic" that displays on the map and links back to the "note" or > "picture". This could also be a "label", "waypoint", "track", etc. > Double clicking (or however the app. wants to do it) on the item on > the map would bring up the note or picture. > I display embedded photos icons on some of my tracks now but don't have such a direct method of opening. I think that we already have that mechanism with links -- we just need to clarify the details. > An afterthought - a line type to display a linear object on the map > similar to tracks but not intended to be sent to a GPS receiver. I > could see trails done as "tracks" which would also be intended to be > sent to a receiver but a parking lot outline done with this line type. > As it stands now, I'm drawing with "tracks" and the user has to > select which "tracks" to download to the receiver. Not necessarily a > problem but it would be nice to have "lines" not likely to be sent in > a separate category. > I expected to see a polyLine element in the gpx_overlay schema and would like to see this edition. I found the CIA World Data Base of rivers, continental outlines, and political boundaries online at http://www.evl.uic.edu/pape/data/WDB/ and am just considering how I might simplify the data to create a vector overlay for when WM3D opens up with the Mercator projection at a worldwide scale or for users outside the USA. A gpx file consisting just of gpx_overlay polyLine elements could be a simple container for this map and could be a good way to share the digestable version of this 130 MB data base. Perhaps we should assign priorities to each of the features -- I am perfectly willing to implement some in WM3D but of course have limited time! > Dan A.
davewissenbach+yahoo.com on Wed Dec 15 19:56:03 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > I've updated the gpx_overlay 0.2 schema and created documentation for > it. I've also created a sample GPX file demonstrating a possible use > of gpx_style and gpx_overlay in a GPX file. > > Schema: > http://www.topografix.com/gpx/gpx_overlay/0/2/gpx_overlay.xsd > > Documentation: > http://www.topografix.com/gpx/gpx_overlay/0/2/ > (note that most of the elements in gpx_overlay are drawn in from the > main GPX schema and gpx_style. You'll need to refer to those > documentation links as you go. The documentation generator I use > doesn't handle cross-schema links.) > I'd like to have some signal as to when I can publish sample data on my website using these schemas -- I jumped the gun and published BogusBasinSkiResort using the old schema which no longer validates. Can the next versions be gpx_overlay/0/3 and gpx_style/0/3 ? I can prevent this by making these private, but this precludes interchange testing. > Sample file: > http://www.topografix.com/gpx/samples/topografix/overlay.gpx > "Example file showing a route defining the bounds of a farm field. > gpx_overlay is used to place a label with the field's area in the > center of the field. gpx_style is used to display a dotted boundary > around a hatched fill pattern" > The outline of the field shouldn't be a route, per Dan Anderson's suggestion below, but instead a polyline. The route would instead be a set of points to be taken as instructions for the ditch digger or fence builder. (Been there, done both!) Collectively the gpx_overlays a simple vector basemap embedded in the gpx file. The gpx_overlay:polygon may have started out as a route, but is converted to a polygon by the mapmaker who doesn't intend that you follow the route. > > A quick walkthrough: > gpx_overlay contains two elements: lod (level of display) and text. > lod defines a maximum scale at which the parent object is to be > displayed on a map. It is used to keep the screen from getting too > cluttered. > The following waypoint displays on a 1:24000 scale topo map, but is > hidden when viewing a 1:100000 scale overview map. > <wpt> > ... > <lod max_scale="24000"/> > ... > </wpt> > > > <text> defines a text overlay. This could be a waypoint label, a text > note on a map, or maybe part of a map legend. > <text> contains: > lat/lon attributes defining the location of the overlay. > <text> - a text string (the actual text to display) > <gpx_style:text> - optional styling info > <align> and <vertical-align> - aligns the overlay relative to the > parent. (a waypoint label might be center aligned below the waypoint > symbol on the map) > <derived_from> - a hint to the receiving application on where the > display text actually came from. This can indicate a data field in > the parent GPX object: > > <text>The White House</text> > <derived_from>desc</derived_from> > this means that the label text is really just a copy of what's in the > waypoint's Description field. If that changes, the text label should > change too. > > <text>120 acres</text> > <derived_from>area</derived_from> > this means that the label text was calculated based on the area of > the parent route. If the route changes, the area should be > recalculated and used as the label text. > > <text>The White House</text> > <derived_from>wissenbach:foo</derived_from> > My program has no idea what wissenbach:foo is, so I'll just display > the text and not worry about it. > > A receiving program can match <derived_from> against a list of values > it recognizes, and implement "smart labels" that update as their > parents change. > > > Comments? > -- Thanks. > Dan Foster - egroups+t...
egroups+topografix.com on Thu Dec 16 07:31:16 2004 (link), replying to msg
Hello, Wednesday, December 15, 2004, 10:55:17 PM, David W. wrote: D> I'd like to have some signal as to when I can publish sample data on D> my website using these schemas -- I jumped the gun and published D> BogusBasinSkiResort using the old schema which no longer validates. I apologize for that - I knew you were using the 0/1 version of gpx_style (ExpertGPS 1.3.7 does too) but I thought I could make changes to 0/2 with impunity. I've been keeping my test files quarantined until we get to 1/0. That's one reason I'd like to get the discussion wrapped up this month - I'd like to be able to release my beta software which will write to these schemas. D> Can the next versions be gpx_overlay/0/3 and gpx_style/0/3 ? My sincere hope is that the next version is 1/0 (a fixed, public release) for both. -- Dan Foster
egroups+topografix.com on Thu Dec 16 09:47:40 2004 (link), replying to msg
Hello, Wednesday, December 15, 2004, 10:43:36 PM, David W. wrote: D> I expected to see a polyLine element in the gpx_overlay schema This seems to be the biggest issue, so perhaps we should tackle it first. How should data that isn't meant for the GPS be represented? How should filled tracks or routes be represented? (And are there really such things?) Are <rte> and <trk> the appropriate objects to use, or do we need <polyline> and perhaps <polygon>? I saw enough similarity between tracks and polylines to treat them the same in my software, and to output them as <trk> in my GPX files. Polylines can have almost all of the metadata that tracks have. Contour lines have elevation. Street centerlines have names. I proposed a "do not send to GPS" tag that didn't go over too well. The alternative is putting this stuff in a new base tag like <polyline>. Is that the group consensus? Do we need a <polygon> tag as well for closed objects, or is a <polyline> that happens to start and end at the same point sufficient? What about filled routes? Can they exist? I just went out and walked a property boundary last weekend. The GPS guided me from one boundary monument to the next. That's a <rte>. On my map, it made sense to give the property a fill pattern. On other days, the same property line is just supporting information, basemap data that shouldn't be confused with the routes I'm drawing across the property. On those days, the same property line should probably be a <polyline>. There's a blurry line between <rte>, <trk>, and <polyline>. Anyone care to offer some definitions? <rte> is the easiest one to define - a directed path that you plan to take with your GPS guiding you. <trk> has been described as "GPS breadcrumbs showing where you were" <polyline> would then be "everything else". The problem I see is that most of what goes into one of Dave W's area trail maps is now best classified as <polyline>. I've started mapping out some of the local areas, tracing trails off of maps, gathering my own GPS data, and bringing in data layers from the state GIS. Should this all be <polyline>? If so, that means that fewer programs will recognize and display it. Comments? -- Dan Foster
dananderson2+yahoo.com on Thu Dec 16 10:30:10 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > > --- In gpsxml+yahoogroups.com, "dananderson2" <dananderson2+y...> > wrote: > > > > The other type of text is not intended to be shown on the map but > is > > to be displayed in some sort of separate window. I think of this > type > > as "notes" because the quantity of text is on the larger side and > > would obscure too much of the map if placed on it. The latest > > versions of Nat'l. Geographic's TOPO! is a good example. > > > > How is this different from the description field currently included > in the various elements? The way I see it is the description field is part of the objects waypoint, track, or route (also metadata). "Notes" is independent of GPS related data and may not even have coordinates associated with them. Dan A.
dananderson2+yahoo.com on Thu Dec 16 10:40:09 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > > I'd like to have some signal as to when I can publish sample data on > my website using these schemas -- I jumped the gun and published > BogusBasinSkiResort using the old schema which no longer validates. > > Can the next versions be gpx_overlay/0/3 and gpx_style/0/3 ? > > I can prevent this by making these private, but this precludes > interchange testing. Is there any problem with just putting the files on another web page with text that spells out that they are under development using schema "x" which is also under development? Then move them to your main download page when everything is finalized and working. Dan A.
dananderson2+yahoo.com on Thu Dec 16 11:49:48 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Wednesday, December 15, 2004, 10:43:36 PM, David W. wrote: > > D> I expected to see a polyLine element in the gpx_overlay schema > > This seems to be the biggest issue, so perhaps we should tackle it > first. How should data that isn't meant for the GPS be represented? > How should filled tracks or routes be represented? (And are there > really such things?) Are <rte> and <trk> the appropriate objects to > use, or do we need <polyline> and perhaps <polygon>? > > I saw enough similarity between tracks and polylines to treat them the > same in my software, and to output them as <trk> in my GPX files. > Polylines can have almost all of the metadata that tracks have. > Contour lines have elevation. Street centerlines have names. > > I proposed a "do not send to GPS" tag that didn't go over too well. My current view is that the "do not send to GPS" tag is essentially implemented as a separate dataset defined by gpx_overlay. > The alternative is putting this stuff in a new base tag like > <polyline>. Is that the group consensus? Do we need a <polygon> tag > as well for closed objects, or is a <polyline> that happens to start > and end at the same point sufficient? As things stand now I think <polyline> belongs in gpx_overlay. Adding "Polygon" now could save a revision in the near future but I'm not sure if anyone would implement/use it soon. > What about filled routes? Can they exist? I just went out and walked > a property boundary last weekend. The GPS guided me from one boundary > monument to the next. That's a <rte>. On my map, it made sense to > give the property a fill pattern. On the map perhaps the logical way to handle it would be to convert the closed route (or track) to a polygon? > On other days, the same property line is just supporting information, > basemap data that shouldn't be confused with the routes I'm drawing > across the property. On those days, the same property line should > probably be a <polyline>. Yes, or polygon. > There's a blurry line between <rte>, <trk>, and <polyline>. Anyone > care to offer some definitions? > > <rte> is the easiest one to define - a directed path that you plan to > take with your GPS guiding you. > > <trk> has been described as "GPS breadcrumbs showing where you were" > > <polyline> would then be "everything else". > > The problem I see is that most of what goes into one of Dave W's area > trail maps is now best classified as <polyline>. I've started mapping > out some of the local areas, tracing trails off of maps, gathering > my own GPS data, and bringing in data layers from the state GIS. > Should this all be <polyline>? If so, that means that fewer programs > will recognize and display it. > > > Comments? > -- > Dan Foster First pass at sort of a definition..... A track and route are special cases of "polyline". They are data that came from or is to be sent to a GPS receiver. The distinction between a track and a route is somewhat blurred already as technology becomes cheaper and more powerful. In the future there could be no difference. An application could be structured with one database for "track" and one for "polylines". Commands could be provided to convert one to the other as the user wishes. A polyline is a series of connected points in 2 dimensions or an optional third dimension (elevation) that is intended to be displayed on the "map". The number of points possible in any series should be large. A track is a series of connected points in 2 dimensions or an optional third dimension (elevation) that is intended to be sent to the receiver or came from a receiver. A track can also have additional data as spelled out in the gpx schema. A route is a series of connected points in 2 dimensions (I'm not aware of any program or device that uses a third dimension so far) that is intended to be sent to the receiver or came from a receiver. The points used in a route have additional information so that better navigation messages may be displayed (ie. the points that make up a route are usually waypoints with names, comments, etc.). The number of points in a route is usually less than a track because of memory limitations and/or less capable data structures. All that's really needed to end the distinction between a route and a track in current GPS receivers is more memory so that track points could have names too. I think gpx_overlay should contain objects that are not intended to be sent to a receiver and didn't immediately come from a receiver. Some types of objects may be transferred from one class to the other (tracks in particular). For the time being I will ignore data for mapping receivers since there aren't many receivers with a public protocol. A "Do not send to receiver" flag that Dan Foster proposed would have been a better structure. Someday what we see on the computer screen will be sent to the receiver (not just under control of the receiver manufacturer). Dan A.
davewissenbach+yahoo.com on Thu Dec 16 19:19:30 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Wednesday, December 15, 2004, 10:43:36 PM, David W. wrote: > > D> I expected to see a polyLine element in the gpx_overlay schema > > This seems to be the biggest issue, so perhaps we should tackle it > first. How should data that isn't meant for the GPS be represented? > How should filled tracks or routes be represented? (And are there > really such things?) Are <rte> and <trk> the appropriate objects to > use, or do we need <polyline> and perhaps <polygon>? > > I saw enough similarity between tracks and polylines to treat them the > same in my software, and to output them as <trk> in my GPX files. > Polylines can have almost all of the metadata that tracks have. > Contour lines have elevation. Street centerlines have names. > > I proposed a "do not send to GPS" tag that didn't go over too well. > The alternative is putting this stuff in a new base tag like > <polyline>. Is that the group consensus? Do we need a <polygon> tag > as well for closed objects, or is a <polyline> that happens to start > and end at the same point sufficient? > I think that polyline with gpx_style applied is good enough. Treat a polyline as a path that can be either edged or filled. (But don't call this a path because path carries that implication of composition from primitives such as Bezier curves and Arcs.) > What about filled routes? Can they exist? I just went out and walked > a property boundary last weekend. The GPS guided me from one boundary > monument to the next. That's a <rte>. On my map, it made sense to > give the property a fill pattern. > And I've done the same thing with a trail of type Avalanche Area on an experimental map created for conversion to SVG. See http://www.gpstrailmaps.com/idaho/BogusBasin/BogusBasinSVG.html for an example. (You'll need to have the SVG viewer from Adobe to see this.) I don't really want the contour line around Shafer Butte or the Avalanche area on More's mountain to show up on a GPS receiver as tracks but that's what would happen if this map were opened by Garmin MapSource. (I hope that no one follows the "Avalanche Area" route, because that really -is- a dangerous back-country avalanche area!) > On other days, the same property line is just supporting information, > basemap data that shouldn't be confused with the routes I'm drawing > across the property. On those days, the same property line should > probably be a <polyline>. > > > There's a blurry line between <rte>, <trk>, and <polyline>. Anyone > care to offer some definitions? > > <rte> is the easiest one to define - a directed path that you plan to > take with your GPS guiding you. > > <trk> has been described as "GPS breadcrumbs showing where you were" > > <polyline> would then be "everything else". > > The problem I see is that most of what goes into one of Dave W's area > trail maps is now best classified as <polyline>. I've started mapping > out some of the local areas, tracing trails off of maps, gathering > my own GPS data, and bringing in data layers from the state GIS. > Should this all be <polyline>? If so, that means that fewer programs > will recognize and display it. > > > Comments? > -- > Dan Foster I know that polyline will be a bit more difficult to program but keeping this data in gpx_overlay will help separate those who just want simple gps data exchange and those who want richer graphical content. Fences make good neighbors. People who just want to follow a published trail using G7ToWin or EasyGPS or MapSource without buying or downloading yet another program can do so, but there's something more for people who upgrade. Also, existing programs using GPX1.1 would not be able to interpret a new element indicating data not for transfer to a GPS, but such programs would naturally ignore data in a schema which they don't understand or intentionally ignore. Regards, Dave Wissenbach
susan_rose21+yahoo.com on Fri Dec 17 01:01:33 2004 (link)
"WOW!! WHAT A SITE!!! GOOD COLLECTIONS!!! GOOD FREE STUFF HI FRIENDS LET US CELEBRATE CHRISTMAS N YEAR IN A NOVEL WAY THE LINK WHICH IAM GIVING YOU IS DAMN GOOD ITS QUITE FUNNY AND EARNER ALSO IT SHOWE ME WAY TO SAVE ,ITS TRUE EXPERIENCE IT ON YOUR OWN THNAKS AND BYE....BYE... http://tinyurl.com/6gwx8 http://www.globalfreecalling.com/reg1.asp?refcode=pears --------------------------------- Do you Yahoo!? Send holiday email and support a worthy cause. Do good. [Non-text portions of this message have been removed]
davewissenbach+yahoo.com on Sat Dec 18 15:24:09 2004 (link)
The W3C is working on a proposal to allow SVG drawing of generic XML content that might be relevant here, maybe in the long term. This is a very popular add-on to SVG that was discussed as part of the SVG1.2 standard but spun off. http://www.w3.org/TR/2004/WD-sXBL-20041122/ I'm not sure whether this is entirely applicable, because some of the objects that we want to draw and style will be polylines with coordinates in geographic space but line widths in display space -- and text boxes pinned to the map at the location defined by vertical- align and horizontal align, but again rendered in display space. But still, we should look at what's already out there before diving in too deeply. If we do this right I think that we could be inventing something really, really useful here!
davewissenbach+yahoo.com on Sat Dec 18 16:23:40 2004 (link)
All, One of the really neat features of GPS Visualizer is the ability to grab and move labels apart from each other in an SVG file. I'd also like to use this concept in our styled and overlayed GPS Exchange format. The vertical align and align elements specify the origin of the label, but additional control of the label placement could be made by allowing an additional offset (in millimeters). The label origin, determined by vertical-align and align, is then located at a displacement (in millimeters) from the geographical feature to which the label occurs. In the current definition of gpx_overlay this displacement is implied to be zero. <gpx_overlay:text lat="43.123" lon="-116.456" dx="6mm" dy="-10mm"> might pin the name of a track to a location on the track, but offset the label just a bit so that the track doesn't cross over or under the label. Using an offset of millimeters in display space instead of an absolute location in geographic space prevents the label from visually drifting away from a track or waypoint as the user zooms in on the track or waypoint. dx and dy would have a default value of 0. dx would be right- positive, with dy up-positive. Dave
davewissenbach+yahoo.com on Wed Dec 22 19:55:05 2004 (link)
Question regarding the interpretation of vertical align tags. The example below moves a ski run symbol's label above and to the left of the waypoint symbol. Am I interpreting the align and vertical-align tags correctly, as a label origin relative to the edge of the waypoint? Also, do align and vertical-align go in the gpx_overlay:text tag or in the gpx_style:text tag? Below is how wm3d outputs this now (indented for readability) <wpt lat="43.777081" lon="-116.110375"> <ele>1950.686401</ele><name>BTRCUp</name> <cmt>Buttercup Trail</cmt> <sym>Skiing Area</sym> <extensions> <map3d:layer>trailmap</map3d:layer> <gpx_overlay:text lat="43.777081" lon="-116.110375"> <gpx_overlay:text>Buttercup</gpx_overlay:text> <gpx_style:align>right</gpx_style:align> <gpx_style:vertical-align>bottom</gpx_style:vertical-align> <gpx_style:text> <gpx_style:color>00ff00</gpx_style:color> </gpx_style:text></gpx_overlay:text> </extensions> </wpt>
egroups+topografix.com on Thu Dec 23 04:13:06 2004 (link), replying to msg
Hello, Wednesday, December 22, 2004, 10:55:02 PM, David W. wrote: D> Question regarding the interpretation of vertical align tags. D> The example below moves a ski run symbol's label above and to the D> left of the waypoint symbol. Am I interpreting the align and D> vertical-align tags correctly, as a label origin relative to the D> edge of the waypoint? <gpx_overlay:text lat="43.777081" lon="-116.110375"> <gpx_overlay:text>Buttercup</gpx_overlay:text> <gpx_style:align>right</gpx_style:align> <gpx_style:vertical-align>bottom</gpx_style:vertical-align> <gpx_style:text> <gpx_style:color>00ff00</gpx_style:color> </gpx_style:text></gpx_overlay:text> You understand the meaning correctly but you seem to have reversed it in your GPX sample. In gpx_overlay, "align" means "the horizontal alignment of the text overlay relative to the parent object." In this case, the parent object is the waypoint. The waypoint symbol is drawn on the map at the exact location of the waypoint. You said you wanted a label above and to the left of the waypoint. <gpx_style:align>left</gpx_style:align> <gpx_style:vertical-align>top</gpx_style:vertical-align> The label is "left", relative to the waypoint, and "top" relative to the waypoint. D> Also, do align and vertical-align go in the gpx_overlay:text tag or D> in the gpx_style:text tag? Both! In gpx_overlay, align and vertical-align specify the alignment of the entire text label relative to the parent object. In gpx_style, align and vertical-align specify the alignment of the text *within* the text label. Compare with the left/center/right text-justification buttons in Wordpad, e.g. (Note that there's no real use for vertical-align in this case - the label box should be sized to fit the text exactly. But gpx_style might be embedded in some other object that can use it.) Here's your same GPX example with a label above and to the left of the waypoint symbol. The text block is centered, so it looks like this: (X is the waypoint symbol) ********************* * WHITE HOUSE * * GEORGE LIVES HERE * ********************* X <wpt lat="43.777081" lon="-116.110375"> <desc>WHITE HOUSE GEORGE LIVES HERE</desc> <sym>X</sym> <extensions> <gpx_overlay:text lat="43.777081" lon="-116.110375"> <text>WHITE HOUSE GEORGE LIVES HERE</text> <derived_from>desc</derived_from> <align>left</align> <vertical-align>top</vertical-align> <gpx_style:text> <color>00ff00</color> <align>center</align> </gpx_style:text> </gpx_overlay:text> </extensions> </wpt> -- Dan Foster
egroups+topografix.com on Thu Dec 23 05:39:47 2004 (link)
Hello, There seem to be two types of text label positions: 1. Default positions (label is just offset some small number of millimeters from the waypoint symbol). 2. User-specified positions (the user dragged the label to a new position to avoid crowding). There are two ways to specify that new position: 2A. geographic coordinates (lat/lon) 2B. as an offset in millimeters from the waypoint These two ways produce different outcomes when you zoom in and out. 2A causes the label to stay fixed to geographic location on the map. 2B causes the label to stay a fixed distance from the waypoint regardless of zoom. The 0/2 overlay schema I proposed doesn't address these three cases well. It requires a lat/lon pair for every label, even though this is only useful for 2A. It doesn't provide the offset values needed for 2B. I think that all three cases can be handled with two optional, mutually-exclusive elements. Pick one of: <offset dx="1.0" dy="1.0"/> <point lat="42.1" lon="-71.2"/> [nothing] Additionally, <align> and <vertical-align> are not needed because they can be determined from the two elements above. The offset given above puts the label above and to the right of the waypoint. That implies that the text box should be displayed so that it is entirely above and to the right. So the "anchor corner" of the label is the lower left corner. This corner should be anchored 1mm above and 1mm to the left of the waypoint. I'd like to see the three cases handled this way: 1. Default position // text label centered 5mm below waypoint symbol <gpx_overlay:text> <offset dx="0" dy="-5"/> ... If your program displays all waypoint labels in the same, default fashion (ExpertGPS 1.3.7, e.g.), you don't need to include any offset info at all. <gpx_overlay:text> ... 2A. User-specified offset label // text label 25mm below and 14mm right of waypoint symbol <gpx_overlay:text> <offset dx="14" dy="-25"/> ... // Note that this format is identical to #1 above. Suggested program implementation for determining if something is a user-located label: if the incoming offset is greater than your program's default label offset, treat it as #2A, else treat it as #1 and replace the file's default offset with your program's default offset. 2B. User-specified geographic-location label // text label at 42.123,-71.234 <gpx_overlay:text> <point lat="42.123" lon="-71.234"/> ... Is this a better solution? Did I describe "anchor corners" well enough? -- Dan Foster
davewissenbach+yahoo.com on Thu Dec 23 07:45:29 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > There seem to be two types of text label positions: > 1. Default positions (label is just offset some small number of > millimeters from the waypoint symbol). > 2. User-specified positions (the user dragged the label to a new > position to avoid crowding). There are two ways to specify that new > position: > 2A. geographic coordinates (lat/lon) > 2B. as an offset in millimeters from the waypoint > These two ways produce different outcomes when you zoom in and out. > 2A causes the label to stay fixed to geographic location on the map. > 2B causes the label to stay a fixed distance from the waypoint > regardless of zoom. > > The 0/2 overlay schema I proposed doesn't address these three cases > well. It requires a lat/lon pair for every label, even though this is > only useful for 2A. It doesn't provide the offset values needed for > 2B. > > I think that all three cases can be handled with two optional, > mutually-exclusive elements. Pick one of: > <offset dx="1.0" dy="1.0"/> > <point lat="42.1" lon="-71.2"/> > [nothing] > > Additionally, <align> and <vertical-align> are not needed because they > can be determined from the two elements above. The offset given > above puts the label above and to the right of the waypoint. That > implies that the text box should be displayed so that it is entirely > above and to the right. So the "anchor corner" of the label is the > lower left corner. This corner should be anchored 1mm above and 1mm > to the left of the waypoint. > > > I'd like to see the three cases handled this way: > 1. Default position > // text label centered 5mm below waypoint symbol > <gpx_overlay:text> > <offset dx="0" dy="-5"/> > ... > In this case the anchor corner is not really a corner. I would use the terminology from HPGL and say that the label origin is the top center of the label in this case. (I see also that we have defined the positive y axis as up and to the right.) Can we adopt the convention that an explicit offset of zero defines the label origin as the center. If not vertical align and horizontal align still have a use as a method of defining the label origin. Is the offset a vector in display space originating at the center of the waypoint to the anchor corner/label origin, or is the origin of the offset vector the bottom center of the waypoint. I think that this distinction is important if gpx_overlay doesn't also provide a way for the authoring application to furnish a symbol to the reading application, because the authoring application symbol set might be different from the reading application symbols. > If your program displays all waypoint labels in the same, default > fashion (ExpertGPS 1.3.7, e.g.), you don't need to include any offset > info at all. > <gpx_overlay:text> > ... > > 2A. User-specified offset label > // text label 25mm below and 14mm right of waypoint symbol > <gpx_overlay:text> > <offset dx="14" dy="-25"/> > ... > // Note that this format is identical to #1 above. Suggested program > implementation for determining if something is a user-located label: > if the incoming offset is greater than your program's > default label offset, treat it as #2A, else treat it as #1 and replace > the file's default offset with your program's default offset. > > 2B. User-specified geographic-location label > // text label at 42.123,-71.234 > <gpx_overlay:text> > <point lat="42.123" lon="-71.234"/> > ... > > > Is this a better solution? Did I describe "anchor corners" well > enough? > -- > Dan Foster I like the overall approach much better, even after having invested the time to implement a simple gui to select the label origin. We may also need a mechanism to convey symbols (perhaps as small JPEG/PNG images with dimensions and origin. If the dimensions of the symbols are known, then the authoring application can originate the label displacement at the center of the symbol. Otherwise I think that the displacement needs to be from the edge. P.S. Dan, If you are under time pressure to produce your software beta, you could unilaterally publish a working draft under a topografix namespace. This would give a short term interoperability problem, but I really believe that we are addressing a more general problem of a map presentation language not yet solved by SVG, which is a fairly rigid presentation language without layout aspects. (For instance, SVG labels shrink and grow in size as the zoom goes in or out.) I also note that someone has developed a gpx plugin for Mozilla, which opens the concept of a geographic browser. Regards, Dave
egroups+topografix.com on Thu Dec 23 11:43:13 2004 (link), replying to msg
Hello, Thursday, December 23, 2004, 10:44:15 AM, David W. wrote: >> <offset dx="0" dy="-5"/> D> In this case the anchor corner is not really a corner. I would use D> the terminology from HPGL and say that the label origin is the top D> center of the label in this case. Agreed. <offset> and <point> specify the distance to the label origin. Corner is out. D> (I see also that we have defined the positive y axis as up and to the right.) Yes. The standard cartesian coordinate system seems easier to defend as a generic solution. D> Can we adopt the convention that an explicit offset of zero defines D> the label origin as the center. Yes. D> Is the offset a vector in display space originating at the center of D> the waypoint to the anchor corner/label origin, or is the origin of D> the offset vector the bottom center of the waypoint. I think it would be cleaner to define it as a vector from the center of the waypoint, but without specifying the symbol size (as you pointed out) this isn't going to produce good results between programs. My vote is for practicality here - make it the distance from the edge of the waypoint symbol to the label origin. That's the critical space to define to get a good-looking margin between the symbol and the text. Dan A. asked for a rotation element for gpx_overlay:text. That brings up an order-of-operations question regarding rotation and offset. Which should happen first, the rotation, or the offset (translation)? It would be nice if the order of operations matched the order the elements appeared in the GPX file. For a rotated default waypoint label (#1), it seems to me you rotate first (around the waypoint, and then offset in this rotated coordinate system. For a rotated user-positioned waypoint label (#2A), it seems to me you move to the user position first, and then rotate. Making things uglier, rotation has to follow <point> if they are to be allowed together. (that is, the center of rotation is the label point.) Does it even make sense to have rotation around a user-specified location? Probably not for waypoints, but probably for tracks or routes. ("place the label on this straight part of the track, and rotate it so it lines up with the direction of travel", e.g.) Perhaps <offset> needs to be broken up to properly address the two ways it is being used: <translate dx="25" dy="37"> // move to a user-specified location <margin>3</margin> // 3mm space between symbol and text The order that comes to mind is: <gpx_overlay:text> <point...> // choose point or translate or neither <translate...> // not both! <rotate...> <margin...> ... </gpx_overlay:text> D> I like the overall approach much better, even after having invested D> the time to implement a simple gui to select the label origin. If it is any consolation, I ripped out all my <polyline> code and now have to put it back... D> We may also need a mechanism to convey symbols (perhaps as small D> JPEG/PNG images with dimensions and origin. If the dimensions of the D> symbols are known, then the authoring application can originate the D> label displacement at the center of the symbol. Otherwise I think D> that the displacement needs to be from the edge. How would you convey these symbols? Embedded bitmaps in the XML file? Links to a common Web source? Links to local files? Symbol fonts? I'd rather see a joint effort to develop a common symbol set that all programs can use. I don't think we're ever going to get 100% compatibility between programs, and symbols are one area where it will probably break down. D> If you are under time pressure to produce your software beta, you D> could unilaterally publish a working draft under a topografix D> namespace. How about we freeze gpx_overlay 0/2 in another week or two and just work on implementation and compatibility for a while? That should help show any missing features or areas that need refining, and we can try for a 1/0 version a few months later. For schemas going forward, I'd like to see us work in four stages: 1. proposal/discussion - all changes allowed. code at your own peril. 2. first draft - documentation added. sample files posted but not allowed in the open. feel free to code an implementation, but changes may break your instance documents and you may have to rewrite parts of your code. 3. additions only - no changes can be made that would break existing instance documents. (ie, the only thing that can be added are optional elements) No removal or renaming of existing objects. You can safely release code at this point - nothing can change in the schema that would break your implementation. 4. release. schema is frozen. no changes, period. I think we're pretty close to #3 for gpx_style, and still firmly in #2 for gpx_overlay 0/2. Happy holidays, everyone! -- Dan Foster
davewissenbach+yahoo.com on Thu Dec 23 20:52:15 2004 (link)
I have posted a hand-modified SVG file on my web site to show how an orientation for a label might be combined with a label origin which is applied after the rotation for orientation. Note that for various waypoints text appears to the left, or to the right, or above, relative to the direction of the text. http://www.gpstrailmaps.com/idaho/HullsGulch/LabelOrientation.svg One of the labels, the Loop Trail upper Trailhead, is pinned to a geographic location to avoid the converging trails near this point. Dave
davewissenbach+yahoo.com on Fri Dec 24 00:14:49 2004 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Thursday, December 23, 2004, 10:44:15 AM, David W. wrote: > > >> <offset dx="0" dy="-5"/> > D> In this case the anchor corner is not really a corner. I would use > D> the terminology from HPGL and say that the label origin is the top > D> center of the label in this case. > > Agreed. <offset> and <point> specify the distance to the label > origin. Corner is out. > > D> (I see also that we have defined the positive y axis as up and to the right.) > > Yes. The standard cartesian coordinate system seems easier to defend > as a generic solution. > > D> Can we adopt the convention that an explicit offset of zero defines > D> the label origin as the center. > > Yes. > > D> Is the offset a vector in display space originating at the center of > D> the waypoint to the anchor corner/label origin, or is the origin of > D> the offset vector the bottom center of the waypoint. > > I think it would be cleaner to define it as a vector from the center > of the waypoint, but without specifying the symbol size (as you > pointed out) this isn't going to produce good results between > programs. My vote is for practicality here - make it the distance > from the edge of the waypoint symbol to the label origin. That's the > critical space to define to get a good-looking margin between the > symbol and the text. > I would modify this definition slightly to define this the offset as the distance from the bounding box of the waypoint symbol to the label origin. (because we are going to play with rotation below, and the bounding box can rotate) > > > Dan A. asked for a rotation element for gpx_overlay:text. That brings > up an order-of-operations question regarding rotation and offset. > Which should happen first, the rotation, or the offset (translation)? > It would be nice if the order of operations matched the order the > elements appeared in the GPX file. > > For a rotated default waypoint label (#1), it seems to me you rotate > first (around the waypoint, and then offset in this rotated coordinate > system. > Good points, and foot for thought. I've chewed on this for a while--- I would use a separate attribute/element here called the orientation of the label. Then a waypoint label at an orientation of 45 degrees with offset x=2.0,y=0 (from the edge of a rotated bounding box) appears above and to the right of the (unrotated) waypoint, but a waypoint label at the same orientation of 45 degrees with negative offset -2.0,0 appears below and to the left of the waypoint. Both appear upright when the viewer tilts their head to the left! > For a rotated user-positioned waypoint label (#2A), it seems to me you > move to the user position first, and then rotate. > I would use the rotation element here, which must follow offset if present. > Making things uglier, rotation has to follow <point> if they are to be > allowed together. (that is, the center of rotation is the label point.) > I agree that the center of rotation should be the label origin, if rotation follows point. I think that <orientation> <point> <rotation> in that order make sense. I'm hand-coding some examples of the above by hacking my SVG maps, which I'll provide after a more hours of seat time.) (I'm on vacation today.) > Does it even make sense to have rotation around a user-specified > location? Probably not for waypoints, but probably for tracks or > routes. ("place the label on this straight part of the track, and > rotate it so it lines up with the direction of travel", e.g.) > I'd also like to use floating labels that line up with ridge lines or valley bottoms, such as Blue Bunch Mountain or Hulls Gulch for places I've recently visited. These could be waypoints but might just be floating gpx_overlay:text elements. In that case both a geographic origin and offset make sense, because the offset defines the label origin -- either to the left or right of the tying coordinate. > Perhaps <offset> needs to be broken up to properly address the two > ways it is being used: > <translate dx="25" dy="37"> // move to a user-specified location > <margin>3</margin> // 3mm space between symbol and text > I think agree that margin is a good concept to introduce here. > The order that comes to mind is: > <gpx_overlay:text> > <point...> // choose point or translate or neither > <translate...> // not both! > <rotate...> > <margin...> > ... > </gpx_overlay:text> > > > > D> I like the overall approach much better, even after having invested > D> the time to implement a simple gui to select the label origin. > > If it is any consolation, I ripped out all my <polyline> code and now > have to put it back... > A topic for further discussion is whether tracks and routes are special cases of polylines -- does all of the rich embedded content that we have defined for tracks and routes also belong in polylines? Dan A's comments previously seemed to want this. Before I read those comments, I thought that a polyline was a simple line -- but perhaps there's a potential story behind every road and place on the map. > D> We may also need a mechanism to convey symbols (perhaps as small > D> JPEG/PNG images with dimensions and origin. If the dimensions of the > D> symbols are known, then the authoring application can originate the > D> label displacement at the center of the symbol. Otherwise I think > D> that the displacement needs to be from the edge. > > How would you convey these symbols? Embedded bitmaps in the XML file? > Links to a common Web source? Links to local files? Symbol fonts? > > I'd rather see a joint effort to develop a common symbol set that all > programs can use. I don't think we're ever going to get 100% > compatibility between programs, and symbols are one area where it will > probably break down. > > D> If you are under time pressure to produce your software beta, you > D> could unilaterally publish a working draft under a topografix > D> namespace. > > How about we freeze gpx_overlay 0/2 in another week or two and just > work on implementation and compatibility for a while? That should > help show any missing features or areas that need refining, and we can > try for a 1/0 version a few months later. > > For schemas going forward, I'd like to see us work in four stages: > 1. proposal/discussion - all changes allowed. code at your own peril. > 2. first draft - documentation added. sample files posted but not > allowed in the open. feel free to code an implementation, but changes > may break your instance documents and you may have to rewrite parts of > your code. > 3. additions only - no changes can be made that would break existing > instance documents. (ie, the only thing that can be added are > optional elements) No removal or renaming of existing objects. You > can safely release code at this point - nothing can change in the > schema that would break your implementation. > 4. release. schema is frozen. no changes, period. > > I think we're pretty close to #3 for gpx_style, and still firmly in #2 > for gpx_overlay 0/2. > > > Happy holidays, everyone! > -- > Dan Foster And to you. Hopefully I'll be out there logging a few more trails -- last Saturday my 6 year old actually skiied for an hour before she had to sit in the sled, which made things much easier for me. Dave
ptomblin+gmail.com on Mon Jan 03 15:27:53 2005 (link)
So, when is the schema going to be updated to allow negative values for magnetic variation? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
egroups+topografix.com on Thu Jan 06 05:57:32 2005 (link), replying to msg
Hello, Monday, January 3, 2005, 6:27:52 PM, Paul wrote: P> So, when is the schema going to be updated to allow negative values P> for magnetic variation? GPX 1.1 is frozen, so the change can't go there. GPX 1.2 hasn't even been discussed, so it's unlikely that anything would change in the next 6 months. The only other option is to decide that <magvar> doesn't belong in the main schema and create a new sub-schema for it. All that's needed is someone to drive the effort. -- Dan Foster
commando666_2000+yahoo.com on Thu Jan 06 15:08:04 2005 (link)
Hi I was parsing the NMEA data but i don't know which NMEA sentence carry the information about the TRACKS. Also what sentence to look for the Date and time for the tracks. Thanks Anchal
commando666_2000+yahoo.com on Thu Jan 06 15:10:02 2005 (link)
One more question - what does the elevation means in the track points and how to get it from the NMEA sentence. Anchal
robertlipe+usa.net on Thu Jan 06 15:10:32 2005 (link)
> I was parsing the NMEA data but i don't know which NMEA sentence > carry the information about the TRACKS. Also what sentence to look > for the Date and time for the tracks. Is this question really about GPX or is it about NMEA?
ptomblin+gmail.com on Thu Jan 06 15:33:21 2005 (link), replying to msg
On Thu, 6 Jan 2005 08:42:51 -0500, Dan Foster <egroups+topografix.com> wrote: > Hello, > > Monday, January 3, 2005, 6:27:52 PM, Paul wrote: > > P> So, when is the schema going to be updated to allow negative values > P> for magnetic variation? > > GPX 1.1 is frozen, so the change can't go there. > GPX 1.2 hasn't even been discussed, so it's unlikely that anything > would change in the next 6 months. > The only other option is to decide that <magvar> doesn't belong in the > main schema and create a new sub-schema for it. All that's needed is > someone to drive the effort. I don't get this. You've got a definite bug in your schema, and rather than fix it, you're just suggesting that it be removed? I had somebody asking me to put the information into my GPX files, so I assumed that some application used it, possibly EasyGPS. But if not, maybe he was writing his own application. In that case, I'll just stick a "declination" into my extended schema instead. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
commando666_2000+yahoo.com on Thu Jan 06 17:02:42 2005 (link), replying to msg
it is About NMEA.... Anchal Robert Lipe <robertlipe+usa.net> wrote: > I was parsing the NMEA data but i don't know which NMEA sentence > carry the information about the TRACKS. Also what sentence to look > for the Date and time for the tracks. Is this question really about GPX or is it about NMEA? --------------------------------- Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ 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. --------------------------------- Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. Learn more. [Non-text portions of this message have been removed]
dananderson2+yahoo.com on Fri Jan 07 13:42:23 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > On Thu, 6 Jan 2005 08:42:51 -0500, Dan Foster <egroups+t...> wrote: > > Hello, > > > > Monday, January 3, 2005, 6:27:52 PM, Paul wrote: > > > > P> So, when is the schema going to be updated to allow negative values > > P> for magnetic variation? > > > > GPX 1.1 is frozen, so the change can't go there. > > GPX 1.2 hasn't even been discussed, so it's unlikely that anything > > would change in the next 6 months. > > The only other option is to decide that <magvar> doesn't belong in the > > main schema and create a new sub-schema for it. All that's needed is > > someone to drive the effort. > > I don't get this. You've got a definite bug in your schema, and > rather than fix it, you're just suggesting that it be removed? > > I had somebody asking me to put the information into my GPX files, so > I assumed that some application used it, possibly EasyGPS. But if > not, maybe he was writing his own application. In that case, I'll > just stick a "declination" into my extended schema instead. > -- If I had to create a GPX file with the magnetic variation now, I would probably store negative values as 360 + (neg value). So a "magvar" of -11 deg would be stored as 349 deg. If "magvar" was greater than 180 deg., I would subtract 360 deg. to get the negative magvar value. Dan A.
gpsmap196+yahoo.com on Thu Jan 13 03:40:01 2005 (link)
Hi, I've a question / remark about GPX format. I use my own application to write a GPX file, and I want to map the Garmin Symbol Scheme to the GPX one. If you retreive data from a Garmin unit, the symbol will like a number; 'Const sym_wpt_dot = 18 ' waypoint dot */ This comes directly from the Garmin Protocol spec's (it's a whole list with symbol names. Nou I want to map these symbol numbers to valid GPX symbol names. Can anyone help me with this?
gpsmap196+yahoo.com on Thu Jan 13 03:47:01 2005 (link)
Another question about the GPX format. If you retreive a waypoint from a Garmnin unit, which is in its Aviation Database, It will get some extra info about what kind waipoint it is in the DB (VOR/NDB/Airport etc), a class and country code will be send. This is done for the reason that if you upload the waypoint again (as part of a downloaded route for example) it will check the waypoints excistance in the aviation DB, if its there, it will check the class & country. If these values are not supplied, it will create a user waypoint. And this is where it gets confusing. You will have a user waypoint in the list, that is also in the aviation databse (so in fact, it's not needed in the users waypoints list). See the following developer notes (from waymex IT ) " Some GPS units contain an internal database of waypoint information; for example, most aviation products have an internal database of aviation waypoints, and the StreetPilot has an internal database of land waypoints. When routes are being transferred from the Host to one of these units, the GPS will attempt to match the incoming route waypoints with waypoints in its internal database. The GPS inspects the `Class' member of the incoming route waypoint and if it indicates a non-user waypoint, the GPS searches its internal database using either the `Identifier' and `Country' members or the `Sub Class' member. If a match is found, the waypoint from the internal database is used for the route; otherwise, a new user waypoint is created and used." Is there a way to implement this into the GPX file format, so that the waypoint also holds a Class, sub class and country code??
ptomblin+gmail.com on Thu Jan 13 04:28:27 2005 (link), replying to msg
On Thu, 13 Jan 2005 11:46:55 -0000, gpsmap196 <gpsmap196+yahoo.com> wrote: > Is there a way to implement this into the GPX file format, so that > the waypoint also holds a Class, sub class and country code?? I developed my own GPX extension schema for aviation waypoints (see http://navaid.com/GPX/), but I didn't know about this. In order for a GPX extension schema to be useful in a case like this, the program that takes the GPX data and puts it into your Garmin would have to know about the extension schema as well. Is the program you are using to do this from Garmin or from a third party? Either way, I would be interested in cooperating with them to put together an extension schema that we could all use. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
robertlipe+usa.net on Thu Jan 13 07:06:13 2005 (link), replying to msg
gpsmap196 wrote: > I've a question / remark about GPX format. I raised this very issue about GPX in the early days. The resolution wasn't very satisfying to me, but we weren't able to come up with anything better. > I use my own application to write a GPX file, and I want to map the > Garmin Symbol Scheme to the GPX one. > > If you retreive data from a Garmin unit, the symbol will like a > number; > > 'Const sym_wpt_dot = 18 ' waypoint dot */ > > This comes directly from the Garmin Protocol spec's (it's a whole > list with symbol names. The real problem is you want GPX files to be portable across readers. Such interoperability is one of the very points of GPX, right? So in the general case, you don't want your symbol names to have too much knowledge of their reader. Garmin may call it "Residence" while Magellan may call it "House" yet to the casual observer, they sure do look the same. Garmin has a "City (Small)" while Magellan calls an icon "Small City". Users don't want to be tormented by these kinds of differences. So if you call it "dot" and Dan calls it "default" and Dave doesn't provide <sym> at all (after all, it's optional) and I call it "18", have we really advanced the state of the industry toward GPS data file interoperability? ...and that's with the concept of a default symbol. I'll let you extrapolate this situation to specialized symbols like "Contact, Big Ears" (I'm not making this up) to see how ugly it can get. If you're not really caring about interoperability with multiple readers and you KNOW there is one reader of this and it accepts the Garmin protocol names, things get a little easier but only for a little while. There are mutations of even the Garmin icon mapping - Dot is "18" for most of the Garmin receivers, but "0" in the units that support D103 protocol and symbols above 256 are truncated on D101s and experience has shown that the available icons in any receiver may be renumbered or added to between even minor firmware revs. It's all very icky, isn't it? > Nou I want to map these symbol numbers to valid GPX symbol names. Can > anyone help me with this? The problem you face is that that "valid GPX symbol names" actually is a superset of Garmin-specific names. Garmin's "Hunting Area" is no more or less of a valid GPX symbol name than Magellan's "hunting/fishing" or (gasp) the strings "171" or "s". GPSBabel's tries to map all this, but following the ongoing thrash and flail of Garmin's protocol and Mapsource definitions in particular makes it an endless game of chase. If you have a GPSBabel source tree handy, it's in 'garmin_tables.c' and if you don't have that handy you can use the web viewer and see the mappings I use at: http://cvs.sourceforge.net/viewcvs.py/gpsbabel/gpsbabel/garmin_tables.c?only_with_tag=MAIN&view=markup
egroups+topografix.com on Thu Jan 13 10:49:09 2005 (link), replying to msg
Hello, Thursday, January 13, 2005, 7:28:25 AM, Paul wrote: P> On Thu, 13 Jan 2005 11:46:55 -0000, gpsmap196 <gpsmap196+yahoo.com> wrote: >> Is there a way to implement this into the GPX file format, so that >> the waypoint also holds a Class, sub class and country code?? P> In order for a P> GPX extension schema to be useful in a case like this, the program P> that takes the GPX data and puts it into your Garmin would have to P> know about the extension schema as well. Is the program you are using P> to do this from Garmin or from a third party? Either way, I would be P> interested in cooperating with them to put together an extension P> schema that we could all use. I will implement this in EasyGPS and ExpertGPS if we develop a common schema. -- Dan Foster
gpsmap196+yahoo.com on Fri Jan 14 04:35:18 2005 (link), replying to msg
Ok, I understand, The Same as you, when I retreive stuff from my GPS, I use the Garmin specs in my own App. But If I export it to GPX.. there's the problem. I read it in EasyGPS, or other tools. Because they all use different symbol mapping, it's a headache... So I was just wondering if there was something like a basic symbol mapping.. Wouldn't it be possible to make a GPX symbol name table? so everyone can map to this using their own applications? Thanks for you response. Martin --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > gpsmap196 wrote: > > > I've a question / remark about GPX format. > > I raised this very issue about GPX in the early days. The resolution > wasn't very satisfying to me, but we weren't able to come up with > anything better. > > > I use my own application to write a GPX file, and I want to map the > > Garmin Symbol Scheme to the GPX one. > > > > If you retreive data from a Garmin unit, the symbol will like a > > number; > > > > 'Const sym_wpt_dot = 18 ' waypoint dot */ > > > > This comes directly from the Garmin Protocol spec's (it's a whole > > list with symbol names. > > The real problem is you want GPX files to be portable across readers. > Such interoperability is one of the very points of GPX, right? So > in the general case, you don't want your symbol names to have too > much knowledge of their reader. Garmin may call it "Residence" while > Magellan may call it "House" yet to the casual observer, they sure do > look the same. Garmin has a "City (Small)" while Magellan calls an > icon "Small City". Users don't want to be tormented by these kinds of > differences. > > So if you call it "dot" and Dan calls it "default" and Dave doesn't > provide <sym> at all (after all, it's optional) and I call it "18", > have we really advanced the state of the industry toward GPS data file > interoperability? > > ...and that's with the concept of a default symbol. I'll let you > extrapolate this situation to specialized symbols like "Contact, Big > Ears" (I'm not making this up) to see how ugly it can get. > > If you're not really caring about interoperability with multiple readers > and you KNOW there is one reader of this and it accepts the Garmin > protocol names, things get a little easier but only for a little while. > There are mutations of even the Garmin icon mapping - Dot is "18" for > most of the Garmin receivers, but "0" in the units that support D103 > protocol and symbols above 256 are truncated on D101s and experience > has shown that the available icons in any receiver may be renumbered or > added to between even minor firmware revs. > > It's all very icky, isn't it? > > > Nou I want to map these symbol numbers to valid GPX symbol names. Can > > anyone help me with this? > > The problem you face is that that "valid GPX symbol names" actually is a > superset of Garmin-specific names. Garmin's "Hunting Area" is no more > or less of a valid GPX symbol name than Magellan's "hunting/fishing" or > (gasp) the strings "171" or "s". > > GPSBabel's tries to map all this, but following the ongoing thrash and > flail of Garmin's protocol and Mapsource definitions in particular makes > it an endless game of chase. If you have a GPSBabel source tree handy, > it's in 'garmin_tables.c' and if you don't have that handy you can use > the web viewer and see the mappings I use at: > > http://cvs.sourceforge.net/viewcvs.py/gpsbabel/gpsbabel/garmin_tables. c?only_with_tag=MAIN&view=markup
gpsmap196+yahoo.com on Fri Jan 14 04:56:26 2005 (link), replying to msg
Hi, Well the way I do it, is when I retrieve a waypoint (that belongs to a route) from my Garmin, I also read the Class/Subclass and country name. I store these values in my app, and if I wan't to upload the route to the GPS again, I will upload the waypoints with their Class/subclass and country name, so the GPS will sort it out. It would be nice to implement these extensions in the waypoint set of the GPX file. When loading the GPX file everyone is able to deal with this data the way he or she want's it. I am not a prof. developer, but I would see somting like this in the Waypoint Type: <class> :decimal </class> - or - I beleive there is already a <type>?? <Country> :strng </country> When retreiving the class from a Garmin unit, it's in a INT format (see below, although Garmin calls it the waypoint_type) The Country code will be the first 2 letters of the ICAO country code (ie EH for Netherlands EG Forr the UK ED for Germany etc) user_wpt = 0x00, /* user waypoint */ avtn_apt_wpt = 0x40, /* aviation airport waypoint */ avtn_int_wpt = 0x41, /* aviation intersection waypoint */ avtn_ndb_wpt = 0x42, /* aviation NDB waypoint */ avtn_vor_wpt = 0x43, /* aviation VOR waypoint */ avtn_arwy_wpt = 0x44, /* aviation airport runway waypoint */ avtn_aint_wpt = 0x45, /* aviation airport intersection */ avtn_andb_wpt = 0x46, /* aviation airport ndb waypoint */ map_pnt_wpt = 0x80, /* map point waypoint */ map_area_wpt = 0x81, /* map area waypoint */ map_int_wpt = 0x82, /* map intersection waypoint */ map_adrs_wpt = 0x83, /* map address waypoint */ map_line_wpt = 0x84, /* map line waypoint */ --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Thursday, January 13, 2005, 7:28:25 AM, Paul wrote: > > P> On Thu, 13 Jan 2005 11:46:55 -0000, gpsmap196 <gpsmap196+y...> wrote: > > >> Is there a way to implement this into the GPX file format, so that > >> the waypoint also holds a Class, sub class and country code?? > > P> In order for a > P> GPX extension schema to be useful in a case like this, the program > P> that takes the GPX data and puts it into your Garmin would have to > P> know about the extension schema as well. Is the program you are using > P> to do this from Garmin or from a third party? Either way, I would be > P> interested in cooperating with them to put together an extension > P> schema that we could all use. > > I will implement this in EasyGPS and ExpertGPS if we develop a common > schema. > > -- > Dan Foster
robertlipe+usa.net on Fri Jan 14 06:24:14 2005 (link), replying to msg
gpsmap196 wrote: > I read it in EasyGPS, or other tools. Because they all use different > symbol mapping, it's a headache... I keep the protocol mantra "be conservative in what you send and liberal in what you accept" in the back of my mind. When I find "aliases" for icons, I try add them to the parsers, but it's a manual process that's high maintenance to work out that "bank" and "atm" are probably the same thing and allow either on read but only the 'preferred' one on write. > So I was just wondering if there > was something like a basic symbol mapping.. There hasn't been one specified to my knowledge. > Wouldn't it be possible to make a GPX symbol name table? so everyone > can map to this using their own applications? The real problem is one of limiting expressiveness. While it would be very handy to have a set of "core" symbols that are recommended and well understood, it seems that every program or receiver has a different idea of what that core set might be. So we might decide that "bank" is a preferred spelling to "atm" (even though they aren't _really_ the same thing) but what do we do when we drag the data to a consumer that has neither? What do you do when the thing you're coming from has symbol types that are sufficiently obscure that you can be pretty sure they aren't representable in anything else? How close is 'close enough'? Certain Garmins have an icon for 'white buoy' while certain Magellans have icons for 'red buoy' and 'green buoy'. How liberal do you get with the translations? Do you dumb everything down to 'buoy'? The symbol/icon thing is so messy that in the early days of GPSBabel I totally threw my hands up on the whole thing. Only later did I cave to user demand and even try to do any kind of conversion of icons between formats and it's been a recurring source of pain in the project. RJL
salcedo+yahoo.com on Sun Jan 16 14:09:46 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: ... > > I've got one map that has about a hundred miles of trails, at 100 > track points per mile, that works fine in gpx format. > ... Hi Dave (and the rest of the group), I'm curious how you save trails that fork off in two or more directions. For instance if you have set of trails that begins from point A to point B, then forks to either Point C or Point D: A | B / \ C \ | D Is there an element in GPX to store that as a single entity, or would you save it as multiple tracks. If you save this as multiple tracks, do you recommend three tracks (A-B, B-C, B-D), or two tracks (A-C, A-D). As I think about it, there are other combinations that would be valid too, and it is probably a matter of opinion. In your experience though, which is the best way to store trail data like this in GPX? Thanks, Ricardo
davewissenbach+yahoo.com on Mon Jan 17 11:38:33 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Ricardo" <salcedo+y...> wrote: > > --- In gpsxml+yahoogroups.com, "David S. Wissenbach" > <davewissenbach+y...> wrote: > ... > > > > I've got one map that has about a hundred miles of trails, at 100 > > track points per mile, that works fine in gpx format. > > > ... > > Hi Dave (and the rest of the group), > > I'm curious how you save trails that fork off in two or more > directions. For instance if you have set of trails that begins from > point A to point B, then forks to either Point C or Point D: > > A > | > B > / \ > C \ > | > D > > Is there an element in GPX to store that as a single entity, or would > you save it as multiple tracks. If you save this as multiple tracks, > do you recommend three tracks (A-B, B-C, B-D), or two tracks (A-C, > A-D). As I think about it, there are other combinations that would be > valid too, and it is probably a matter of opinion. In your experience > though, which is the best way to store trail data like this in GPX? > > Thanks, > Ricardo I'm still experimenting with this, so my experience isn't too relevant. The people who are downloading my trails and mapping program seem to be the early adopter types -- technically astute and tolerant of bugs and programming errors. Right now I just have monster trail networks where each track is a separate track. Dan Foster suggested about a month ago that these maps are really overlays, and I agree with that suggestion. For usability, I will begin creating new maps where each track or route represents a complete suggested trip. Then most of the trail data on the any given map would be in the form of gpx overlay polylines, if that's the way Dan and the rest of the group want to go. Again, I'm thinking out loud here. Use the undeveloped gpx_overlay, or even one of the SVG-based formats for the overall map, and save the gpx portion of the document for specific routes or trails. On a suggested travel plan or log, two trails ABC and ABD. On a lightweight map showing an entire network, the 3 trails ab, bc, and bd are separate. In preparation for the summer mountain biking season I'll be breaking my big maps into smaller suggested routes, and referencing these separate gpx files from the main map. I'll probably modify my program so that it actually will follow these links and open the linked gpx files, once I figure out what the mime type for gpx is (or should be). I want the trail following to be as easy as possible, because I've found that when exhausted or in a new place, the human brain doesn't function so well and the GPS gets a be complicated to use. So the trails should be as easy to follow as possible. Regards, Dave
gps_maps+travelbygps.com on Tue Jan 18 03:02:52 2005 (link)
gpx'ers, I recently went through my collection of data files, opening each in ExpertGPS 1.3.7, edited File Information, then saved. The result is that many still can not be open with MapSource ver 6.5. It is not clear to me what is missing and/or what needs to be changed. Is there a utility that will make the necessary corrections? - Doug
robertlipe+usa.net on Tue Jan 18 07:36:55 2005 (link), replying to msg
Doug Adomatis wrote: > I recently went through my collection of data files, opening each in > ExpertGPS 1.3.7, edited File Information, then saved. The result is > that many still can not be open with MapSource ver 6.5. It is not > clear to me what is missing and/or what needs to be changed. Is there > a utility that will make the necessary corrections? An advantage of GPX is that rather than focusing on corrections at the user level, we can place "blame" at the program level. :-) The rules of the blame game are pretty simple: If the output of ExpertGPS validates and Mapsource won't read it, shame on Mapsource. If the output of ExpertGPS doesn't validate, then shame on ExpertGPS. If you would like a hand analyzing that interim file for correctness, put one up publicly and any number of us on this list can help check it for correctness and conformance. Since both factions are actively represented here, I'd have high hopes of getting any potential issues addressed. RJL
gps_maps+travelbygps.com on Tue Jan 18 10:02:26 2005 (link), replying to msg
Doug Adomatis wrote: > Is there a utility that will make the necessary corrections? Robert Lipe wrote: > An advantage of GPX is that rather than focusing on corrections > at the user level, we can place "blame" at the program level. :-) Hi Robert, I'm not looking for who to blame, just trying to make a big task a little easier. And it's not just me. There are other publishers that need to update their files so that MapSource users can access them. For example, it appears that an earlier post here by Troy +dirworld went unanswered: http://groups.yahoo.com/group/gpsxml/message/849 Anyway, I'll take you up on your offer. Take for example Dave Wissenbach's Loon Lake data hosted on my web at http://www.travelbygps.com/guides/loonlake/LoonLakeRoutes.gpx Just prior to this post I open the file in ExpertGPS 1.3.7, made a small change and saved the file back to the server. The resulting file would not open in MapSource 6.5. Any help you can provide is greatly appreciated. - Doug
egroups+topografix.com on Tue Jan 18 10:34:10 2005 (link), replying to msg
Hello, Tuesday, January 18, 2005, 1:02:18 PM, Doug wrote: D>it appears that an earlier post here by Troy +dirworld D> went unanswered: D> http://groups.yahoo.com/group/gpsxml/message/849 I answered him off-list, since his post was addressed to me. D> Anyway, I'll take you up on your offer. Take for example Dave D> Wissenbach's Loon Lake data hosted on my web at D> http://www.travelbygps.com/guides/loonlake/LoonLakeRoutes.gpx SaxCount rules against ExpertGPS on this one. ExpertGPS 1.3.7 is erroneously writing out GPX 1.0 url/urlname into a GPX 1.1 file, where those two elements were replaced by <link>. I accept the blame, and it is fixed in the upcoming ExpertGPS 2.0 release. Until then, you'll have to search and replace <url> and <urlname> in your GPX 1.1 files with the appropriate <link> construction. <link href="http://www.travelbygps.com"> <text>Travel by GPS Web site</text> </link> I'm pretty sure that I saw some debugging information in Garmin's log file that indicates the problem with any GPX file it rejects. Thanks, Rob L, for the earlier "who to blame" post. Well said! Off-topic: I'm in the process of implementing all the suggested changes in gpx_style and gpx_overlay (plus some I discovered while implementing them in ExpertGPS). I'll post again when the schema and documentation are back in sync. -- Dan Foster
robertlipe+usa.net on Tue Jan 18 11:50:34 2005 (link), replying to msg
> I'm not looking for who to blame, just trying to make a big task a Sorry, I really didn't mean to make it sound confrontational. I was just pointing out that the whole idea of a formal definition is to allow seamless movement of that data and we can test the files to see where the problem is - the reader or the writer. > Anyway, I'll take you up on your offer. Take for example Dave > Wissenbach's Loon Lake data hosted on my web at > http://www.travelbygps.com/guides/loonlake/LoonLakeRoutes.gpx We can test that easily enough: $ SAX2Count LoonLakeRoutes.gpx Error at file /tmp/LoonLakeRoutes.gpx, line 33, char 7 Message: Unknown element 'url' Error at file /tmp/LoonLakeRoutes.gpx, line 35, char 7 Message: Element 'url' is not valid for content model: '(ele?,time?,magvar?,geoidheight?,name?,cmt?,desc?,src?,link*,sym?,type?,fix?,sat?,hdop?,vdop?,pdop?,ageofdgpsdata?,dgpsid?,extensions?)' If we open it up, we see the file claims to be GPX 1.1: xmlns="http://www.topografix.com/GPX/1/1"^M xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">^M Yet line 33 contains a GPX 1.0 "<url>" tag for "LOONLK". <url>http://www.travelbygps.com/guides/loonlake/loonlake.php</url>^M Remove this one tag and it validates. I'm guessing that Mapsource will then gobble it right up. The GPX 1.1 spelling of this would appear to be: <link href="http://www.travelbygps.com/guides/loonlake/loonlake.php"> </link> The view from inside my own glass house is a little cloudy, too, as this highlights that I subtly bozoed the case in the GPX writer in GPSBabel. I was outputting tracks before routes which is technically forbidden. I've just fixed that. I did kind of a promiscuous thing with GPSBabel's reader and I actually parse <url> tags even if the file claims to be GPX 1.1. (Likewise, I'll parse <link> even if the file claims to be GPX 1.0.) So given a suitably new GPSBabel (within the last three minutes in order to get the the fix for the ordering problem I just described) you can use GPSBabel to "reclock" the url/link tags to either the 1.0 or 1.1 style and the specific file you showed us will become valid. That doesn't get Dan off the hook for fixing his writer, too, though. :-) > The resulting file would not open in MapSource 6.5. In this case, Mapsource is wise to reject the file instead of jumping through the hoops to "guess" what's intended. RJL
robertlipe+usa.net on Tue Jan 18 12:35:55 2005 (link), replying to msg
> SaxCount rules against ExpertGPS on this one. > [ ... ] > accept the blame, and it is fixed in the upcoming ExpertGPS 2.0 release. This kind of resolution really is a poster child for GPX. There was an interoperability problem reported, we were able to use documented tools to point to formal specifications to find the problem, another problem in an unrelated GPX producer was found and immediately as a result of the investigation, two workarounds were within a few hours, and a fix to the "offending" program has already been made. That's pretty darned sweet. Remember that when Word 2007 won't read your files created in Word 2006. ;-) RJL
dananderson2+yahoo.com on Tue Jan 18 13:18:36 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: [snip] > I did kind of a promiscuous thing with GPSBabel's reader and I actually > parse <url> tags even if the file claims to be GPX 1.1. (Likewise, > I'll parse <link> even if the file claims to be GPX 1.0.) So given a > suitably new GPSBabel (within the last three minutes in order to get the > the fix for the ordering problem I just described) you can use GPSBabel > to "reclock" the url/link tags to either the 1.0 or 1.1 style and the > specific file you showed us will become valid. > > That doesn't get Dan off the hook for fixing his writer, too, though. :-) > > > The resulting file would not open in MapSource 6.5. > > In this case, Mapsource is wise to reject the file instead of jumping > through the hoops to "guess" what's intended. > > RJL I generally go with a lenient reader/receiver and a strict (correct) writer/sender. The user primarily only cares about whether it works or not. Not doing it that way can put a big strain on your technical support department even though your product is right. Dan Anderson
robertlipe+usa.net on Tue Jan 18 19:13:53 2005 (link), replying to msg
> I generally go with a lenient reader/receiver and a strict (correct) > writer/sender. The user primarily only cares about whether it works Depending on the severity of the encountered problem, that's a decision any individual developer can make. I just demonstrated that I implemented a promiscuous reader in GPSBabel to compensate that handles this very specific case. <devils advocate> In doing so, I realize I've become an enabler. "GPSBabel will read this file; what's wrong with Mapsource?" is a less clear and strong position of GPX interoperability than "No other GPX reader reads this ExpertGPS file without hocking up an error, what's wrong with your writer?" </devils advocate> Ideally, I'd much rather each writer get fixed than fix dozens of readers to coddle broken writers. > or not. Not doing it that way can put a big strain on your technical > support department even though your product is right. I'm basically with you. I'm generally against tormenting users unless there's a really good reason. The problem is that it becomes a slippery slope. You can easily spend a LOT of effort trying to guess "what they really meant" and you won't always get it right. Someone recently observed that 60% of the code in typical HTML rendering engines is special case guessing for malformed HTML. In fact, http://w3.org/TR/2004/REC-xml-20040204/ spells out a large number of cases where an XML reader *must* abort processing, so you there are cases where you really can't recover gracefully. I'm pretty happy with the way this story ended. There was a problem and it got fixed. RJL P.S. All trademarks used without permission, but in the hopes that they realize these are examples and not chop-busting. :-)
avalon73+caerleon.us on Wed Jan 19 04:44:51 2005 (link), replying to msg
On Tue, 18 Jan 2005, Robert Lipe wrote: > Someone recently observed that 60% of the code in typical HTML rendering > engines is special case guessing for malformed HTML. I can personally attest to that one, given the amount of code I've written in the past to digest HTML into text. Gah... A couple of times with that, I did resist a bit when asked to "fix" something that ended up being a product of bad HTML, but ended up breaking down and handling those special cases after a while. -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator Knowledge is knowing a street is one way. Wisdom is still looking in both directions.
egroups+topografix.com on Wed Jan 19 05:03:54 2005 (link)
Hello, The <extensions> element in GPX 1.1 imposes "lax" processing on elements included from other schemas. Because of this our SaxCount validation test will fail to show errors in a GPX file if the errors are related to a second or third namespace. I've created a simple file that puts a bogus <flooz> element in <extensions>. This validates using SaxCount. Try it: http://www.topografix.com/gpx/samples/TopoGrafix/flooz.gpx The fix is to change the "lax" processing on <extensions> to "strict". I've created a GPX 1.2 namespace with this single change so that I could continue testing my instance documents correctly. Feel free to use it for your own testing, but be sure to switch back to GPX 1.1 namespace before releasing software. Please keep this in mind if you are working with multiple namespaces and using <extensions>. I apologize for allowing this error to get into GPX 1.1. I have a feeling GPX 1.0 is broken in a similar fashion, since I copied processContents="lax" directly from GPX 1.0. -- Dan Foster - egroups+topografix.com
egroups+topografix.com on Wed Jan 19 11:34:35 2005 (link)
Hello, I've updated the gpx_overlay and gpx_style schemas to reflect the comments you all made on the prior attempt. I made some further changes based on issues that arose when I tried to implement most of gpx_overlay in ExpertGPS. Major changes: There were three different "text" elements. Renamed to: <label> (gpx_overlay for text labels) <label_text> (actual text string in a <label>) <text> (gpx_style for text) Removed the dependency on GPX 1.1 schema by copying elements like latitudeType, ptType, extensionsType to gpx_overlay. (Alternative solution: create a base definitions schema that only contains elements that will be referenced by other schemas) I'd like guidance on how to proceeed here. The GPX 1.1 base is structured so that <gpx> is the only element that can be referenced (<xsd:element ref="foo") from other schemas. None of the complex or simple types can be referenced in other schemas. I'd like to be able to add <link> elements to <polyline>. Any solutions? Added <point>, <translate>, <rotate>, and <margin> to allow user and default label positions, as per our earlier mailing list discussions. Schemas, documentation, and a sample file follow: gpx_style 0.2: http://www.topografix.com/gpx/gpx_style/0/2/ (documentation) http://www.topografix.com/gpx/gpx_style/0/2/gpx_style.xsd gpx_overlay 0.2: http://www.topografix.com/gpx/gpx_overlay/0/2/ (documentation) http://www.topografix.com/gpx/gpx_overlay/0/2/gpx_overlay.xsd Sample file and screenshot: http://www.topografix.com/gpx/samples/topografix/poly.gpx http://www.topografix.com/gpx/samples/topografix/poly.png The sample file validates against GPX 1.1, the strict GPX 1.2 (if you change the namespace in the file), and opens successfully in ExpertGPS 1.3.7 and MapSource 6.5 -- Dan Foster - egroups+topografix.com
davewissenbach+yahoo.com on Wed Jan 19 18:04:56 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > > I'm not looking for who to blame, just trying to make a big task a > > Sorry, I really didn't mean to make it sound confrontational. I was > just pointing out that the whole idea of a formal definition is to allow > seamless movement of that data and we can test the files to see where > the problem is - the reader or the writer. > > > Anyway, I'll take you up on your offer. Take for example Dave > > Wissenbach's Loon Lake data hosted on my web at > > http://www.travelbygps.com/guides/loonlake/LoonLakeRoutes.gpx > > We can test that easily enough: > > $ SAX2Count LoonLakeRoutes.gpx > > Error at file /tmp/LoonLakeRoutes.gpx, line 33, char 7 > Message: Unknown element 'url' > > Error at file /tmp/LoonLakeRoutes.gpx, line 35, char 7 > Message: Element 'url' is not valid for content model: '(ele?,time?,magvar?,geoidheight?,name?,cmt?,desc?,src?,link*, sym?,type?,fix?,sat?,hdop?,vdop?,pdop?,ageofdgpsdata?,dgpsid?,extensi ons?)' > > > If we open it up, we see the file claims to be GPX 1.1: > > xmlns="http://www.topografix.com/GPX/1/1"^M > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">^M > > Yet line 33 contains a GPX 1.0 "<url>" tag for "LOONLK". > > Busted again!! I believe that the file in question was not created by any recent version of my program as I have been paying much closer attention to validation since MapSource forced the issue. G7toWin also appears to validate strictly. <url>http://www.travelbygps.com/guides/loonlake/loonlake.php</url>^M > > > Remove this one tag and it validates. I'm guessing that Mapsource will > then gobble it right up. > > The GPX 1.1 spelling of this would appear to be: > > <link href="http://www.travelbygps.com/guides/loonlake/loonlake.php"> > </link> > > > > > The view from inside my own glass house is a little cloudy, too, as this > highlights that I subtly bozoed the case in the GPX writer in GPSBabel. > I was outputting tracks before routes which is technically forbidden. > I've just fixed that. > > I did kind of a promiscuous thing with GPSBabel's reader and I actually > parse <url> tags even if the file claims to be GPX 1.1. (Likewise, > I'll parse <link> even if the file claims to be GPX 1.0.) So given a > suitably new GPSBabel (within the last three minutes in order to get the > the fix for the ordering problem I just described) you can use GPSBabel > to "reclock" the url/link tags to either the 1.0 or 1.1 style and the > specific file you showed us will become valid. > > That doesn't get Dan off the hook for fixing his writer, too, though. :-) > > > The resulting file would not open in MapSource 6.5. > > In this case, Mapsource is wise to reject the file instead of jumping > through the hoops to "guess" what's intended. > > RJL
davewissenbach+yahoo.com on Wed Jan 19 18:12:55 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > The <extensions> element in GPX 1.1 imposes "lax" processing on > elements included from other schemas. Because of this our SaxCount > validation test will fail to show errors in a GPX file if the errors > are related to a second or third namespace. > > I've created a simple file that puts a bogus <flooz> element in > <extensions>. This validates using SaxCount. Try it: > http://www.topografix.com/gpx/samples/TopoGrafix/flooz.gpx > > The fix is to change the "lax" processing on <extensions> to "strict". > I've created a GPX 1.2 namespace with this single change so that I > could continue testing my instance documents correctly. Feel free to > use it for your own testing, but be sure to switch back to GPX 1.1 > namespace before releasing software. > > Please keep this in mind if you are working with multiple namespaces > and using <extensions>. > > I apologize for allowing this error to get into GPX 1.1. I have a > feeling GPX 1.0 is broken in a similar fashion, since I copied > processContents="lax" directly from GPX 1.0. > > -- > Dan Foster - egroups+t... This is a good idea. I'll make sure that future versions of WM3D validate strictly even in the extensions. I'm using extensions now to save the 3D setup of the program and also reference digital elevation models, and all of this has apparently been untested, so I doubt that WM3D would pass this more stringent test now. Thanks for finding and correcting this problem. Regards, Dave Wissenbach
salcedo+yahoo.com on Wed Jan 19 19:06:33 2005 (link), replying to msg
Dave, Thanks for the feedback!
robertlipe+usa.net on Thu Jan 20 08:00:27 2005 (link)
In the GPSBabel mailing list, Ron Parker and I just had this discussion: > >We have code to compute bounding box. It's used by the GPX muncher. > Which reminds me... how does that code deal with points on both sides > of 180? longitude? How should it? If it dealt with them "correctly", > e.g. by making the minimum longitude positive and the maximum longitude > negative, would programs reading the resulting GPX file be able to deal > with it? It occurred to me this was a two part question. The answer to the second part is "if we write the correct thing and the readers don't read it, the readers are broken" but I can't say it's apparent to me what the Right Thing is to answer the first part. For those nutty cases where a GPX file spans a hemisphere boundry, is the answer to this any more complicated than a direct decimal comparison of lat/lon? RJL
egroups+topografix.com on Thu Jan 20 11:57:02 2005 (link), replying to msg
Hello, Thursday, January 20, 2005, 9:56:23 AM, Robert wrote: R> In the GPSBabel mailing list, Ron Parker and I just had this discussion: >> >We have code to compute bounding box. It's used by the GPX muncher. >> Which reminds me... how does that code deal with points on both sides >> of 180? longitude? How should it? If it dealt with them "correctly", >> e.g. by making the minimum longitude positive and the maximum longitude >> negative, would programs reading the resulting GPX file be able to deal >> with it? I think you've described the "correct" solution correctly. minLon should be the left or westernmost boundary of all the points in the file. maxLon should be the right or easternmost boundary. For a bunch of waypoints clustered around the International Date Line, minLon would be +179.xxx and maxLon would be -179.xxx My programs write <bounds> but ignore it when reading a GPX file. Perhaps we should come up with a list of tricky test cases so GPX producers can verify that their output not only validates, but also makes sense. -- Dan Foster
robertlipe+usa.net on Thu Jan 20 13:36:43 2005 (link), replying to msg
> >> Which reminds me... how does that code deal with points on both sides > >> of 180? longitude? How should it? If it dealt with them "correctly", > >> e.g. by making the minimum longitude positive and the maximum longitude > >> negative, would programs reading the resulting GPX file be able to deal > >> with it? > > I think you've described the "correct" solution correctly. minLon > should be the left or westernmost boundary of all the points in the > file. maxLon should be the right or easternmost boundary. For a > bunch of waypoints clustered around the International Date Line, > minLon would be +179.xxx and maxLon would be -179.xxx In that case, GPSBabel bozos this and would reverse those. I used the "obvious" mathematical definition of max and min where -179 is the smallest, so it's thea "min". Is there a clever way to code this other than to test for non-equal signs and potentially reverse the extreme values then? > My programs write <bounds> but ignore it when reading a GPX file. Me, too. I understand why the map folks find it useful. > Perhaps we should come up with a list of tricky test cases so GPX > producers can verify that their output not only validates, but also > makes sense. I'd sign up for testing with that and addressing any issues that pop up. RJL
egroups+topografix.com on Thu Jan 20 14:27:21 2005 (link), replying to msg
Hello, Thursday, January 20, 2005, 3:45:14 PM, Robert wrote: >> I think you've described the "correct" solution correctly. minLon >> should be the left or westernmost boundary of all the points in the >> file. maxLon should be the right or easternmost boundary. For a >> bunch of waypoints clustered around the International Date Line, >> minLon would be +179.xxx and maxLon would be -179.xxx R> Is there a clever way to code this other than to test for non-equal R> signs and potentially reverse the extreme values then? Look at any point in the file that isn't on one of the left/right boundaries. Is min < testLon < max? If so, the points don't cross the date line. If you only have two points, it doesn't really matter how you handle it, but choosing the shorter distance would make sense. Two examples: left: San Francisco right: New York test: Chicago bounds cover the US. (minLon = San Francisco) left: San Francisco right: New York test: Tokyo bounds wrap the other way around the world. (minLon = New York) -- Dan Foster
davewissenbach+yahoo.com on Fri Jan 21 04:55:50 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > I've updated the gpx_overlay and gpx_style schemas to reflect the > comments you all made on the prior attempt. I made some further > changes based on issues that arose when I tried to implement most of > gpx_overlay in ExpertGPS. > > Major changes: > There were three different "text" elements. Renamed to: > <label> (gpx_overlay for text labels) > <label_text> (actual text string in a <label>) > <text> (gpx_style for text) > > Removed the dependency on GPX 1.1 schema by copying elements like > latitudeType, ptType, extensionsType to gpx_overlay. (Alternative > solution: create a base definitions schema that only contains elements > that will be referenced by other schemas) I'd like guidance on how to > proceeed here. The GPX 1.1 base is structured so that <gpx> is the > only element that can be referenced (<xsd:element ref="foo") from > other schemas. None of the complex or simple types can be referenced > in other schemas. I'd like to be able to add <link> elements to > <polyline>. Any solutions? > Yes. I've played around a bit with the 1.2 schema and have a demonstration of at least using the linkType. I already use an element called resource, of linkType, in map3d.xsd to automatically serve DEM files needed by my 3D maps. The problem appears to be the namespace="##other" constraint in the /extensions field. I don't think that this is needed now that the extensions are separately wrapped. The purpose of this construct when the any element was at the top level of gpx was to keep people from rearranging or reusing elements, and this is no longer needed once the extensions are moved down a level. I've published an alternate version of the schema at http://www.gpstrailmaps.com/gpx/1/1/strict/gpx.xsd which is referenced in http://www.gpstrailmaps.com/map3d/map3d.xsd and used in example file http://www.gpstrailmaps.com/gpx/1/1/strict/PolyValidateTest.gpx I targeted the alternate schema to the used the topografix gpx 1 1 namespace, but just pointed the files to the alternate strict schema. (Strict in this case means that I promise that my extensions validate) The only changes from Dan's 1/2 schema are removing the namespace=other from the extensions type and changing the target namespace and gpx versions back to 1.1. Will this be an acceptable solution to the validation problem? (I assume that topografix would host the strict schema, not gpstrailmaps.) > Added <point>, <translate>, <rotate>, and <margin> to allow user and > default label positions, as per our earlier mailing list discussions. > > Schemas, documentation, and a sample file follow: > > gpx_style 0.2: > http://www.topografix.com/gpx/gpx_style/0/2/ (documentation) > http://www.topografix.com/gpx/gpx_style/0/2/gpx_style.xsd > > gpx_overlay 0.2: > http://www.topografix.com/gpx/gpx_overlay/0/2/ (documentation) > http://www.topografix.com/gpx/gpx_overlay/0/2/gpx_overlay.xsd > > Sample file and screenshot: > http://www.topografix.com/gpx/samples/topografix/poly.gpx > http://www.topografix.com/gpx/samples/topografix/poly.png Nice work! This is very impressive. As usual, I have a nit to pick. The dots on the trail are spaced 5 on the view but the file says 1. (This might be the windows Graphics/GDI+ quirk of scaling user patterns by line width) > The sample file validates against GPX 1.1, the strict GPX 1.2 (if you > change the namespace in the file), and opens successfully in ExpertGPS > 1.3.7 and MapSource 6.5 > > -- > Dan Foster - egroups+t...
egroups+topografix.com on Fri Jan 21 08:46:32 2005 (link), replying to msg
Hello, Friday, January 21, 2005, 7:55:46 AM, David wrote: D> I targeted the alternate schema to the used the topografix gpx 1 1 D> namespace, but just pointed the files to the alternate strict D> schema. (Strict in this case means that I promise that my extensions D> validate) The only changes from Dan's 1/2 schema are removing the D> namespace=other from the extensions type and changing the target D> namespace and gpx versions back to 1.1. D> Will this be an acceptable solution to the validation problem? (I D> assume that topografix would host the strict schema, not D> gpstrailmaps.) This will force us to switch to GPX 1.2, or retroactively apply these changes to GPX 1.1. I don't have a problem with that, but I suspect others will. I don't like knowing that GPX 1.1 allows invalid GPX to validate. I don't like the fact that GPX 1.1 makes it very difficult (I won't say impossible, but I can't figure out how to do it) to reference base types in extension schemas. Garmin MapSource 6.5 will not open any file with a GPX 1.2 namespace. Surprisingly enough, it handles Dave's polyValidationTest.gpx file, but that's because he's still using the GPX 1.1 namespace, but pointing it at a different schema. I have a feeling Garmin is validating it against the schema included in their product, however. As I see it, there are three "solutions": 1. Immediately release a GPX 1.2 with the two <extensions> fixes in Dave's sample. (Paul Tomblin's degreesType fix should go in as well) MapSource users will have to wait for Garmin to add a GPX 1.2 schema to MapSource. 2. "Unfreeze" GPX 1.1 and retroactively apply the fixes, keeping the namespace and version number the same. MapSource will continue to open GPX 1.1 files, and since Garmin appear to use any data in <extensions>, the fact that they have a different internal schema won't make a difference. Dave W's PolyValidateTest.gpx file (as it currently exists) is an example of this solution, since it claims to be GPX 1/1 but points to a schema that is different from what we agreed was the "frozen" version. This solution also has the benefit of immediately exposing any invalid GPX 1.1 files out there, and (assuming developers are validating their output) preventing any more bad GPX 1.1 files from being created. 3. GPX 1.1 stays frozen, and we agree not to do a GPX 1.2 for 6 months or so. Any namespaces used between now and then will have to work around any problems uncovered. GPX 1.1 outputters will have to be extra careful they are writing GPX that is actually valid, since SAXCount can miss errors in <extensions>. When GPX 1.2 comes out, any work arounds in external schemas should be discarded. Your thoughts? -- Dan Foster
robertlipe+usa.net on Fri Jan 21 10:47:53 2005 (link), replying to msg
Dan Foster wrote: > As I see it, there are three "solutions": > 1. Immediately release a GPX 1.2 with the two <extensions> fixes in > 2. "Unfreeze" GPX 1.1 and retroactively apply the fixes, keeping the > 3. GPX 1.1 stays frozen, and we agree not to do a GPX 1.2 for 6 months If we're looking for widespread vendor acceptance, #3 is the only realistic choice. Neither Rapid-fire releases nor slipstream releases ("It worked on thursday and started failing on friday even though your file didn't change and my code didn't change?") amuse developers committing to what was thought to be a stable spec. There may be a middle ground between 1 and 3, making a "1.2-beta" or something that could be available now and used by folks that don't mind the xsd's changing beneath them. That could get some airtime for those that absolutely positively need this change. RJL
ptomblin+gmail.com on Fri Jan 21 11:15:47 2005 (link), replying to msg
On Fri, 21 Jan 2005 11:47:18 -0500, Dan Foster <egroups+topografix.com> wrote: > As I see it, there are three "solutions": > 1. Immediately release a GPX 1.2 with the two <extensions> fixes in > Dave's sample. (Paul Tomblin's degreesType fix should go in as well) > MapSource users will have to wait for Garmin to add a GPX 1.2 schema > to MapSource. > I'm obviously in favour of this one, but I'm probably outnumbered by MapSource users. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
davewissenbach+yahoo.com on Fri Jan 21 11:20:37 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Friday, January 21, 2005, 7:55:46 AM, David wrote: > > D> I targeted the alternate schema to the used the topografix gpx 1 1 > D> namespace, but just pointed the files to the alternate strict > D> schema. (Strict in this case means that I promise that my extensions > D> validate) The only changes from Dan's 1/2 schema are removing the > D> namespace=other from the extensions type and changing the target > D> namespace and gpx versions back to 1.1. > > D> Will this be an acceptable solution to the validation problem? (I > D> assume that topografix would host the strict schema, not > D> gpstrailmaps.) > > This will force us to switch to GPX 1.2, or retroactively apply these > changes to GPX 1.1. I don't have a problem with that, but I suspect > others will. I don't like knowing that GPX 1.1 allows invalid GPX to > validate. I don't like the fact that GPX 1.1 makes it very difficult > (I won't say impossible, but I can't figure out how to do it) to > reference base types in extension schemas. > Actually, what I propose is that the authoring application gets to choose whether to use the 1.1 lax (current) or 1.1 (strict) schema. We to not change the current schema at all. So when I called this an alternate schema I mean alternate, (not replacement.) I have seen the W3C do this with their DTDs for html -- strict, transitional, etc. That's where I got the idea. > Garmin MapSource 6.5 will not open any file with a GPX 1.2 namespace. > Surprisingly enough, it handles Dave's polyValidationTest.gpx file, > but that's because he's still using the GPX 1.1 namespace, but > pointing it at a different schema. I have a feeling Garmin is > validating it against the schema included in their product, however. > > As I see it, there are three "solutions": > 1. Immediately release a GPX 1.2 with the two <extensions> fixes in > Dave's sample. (Paul Tomblin's degreesType fix should go in as well) > MapSource users will have to wait for Garmin to add a GPX 1.2 schema > to MapSource. > > 2. "Unfreeze" GPX 1.1 and retroactively apply the fixes, keeping the > namespace and version number the same. MapSource will continue to > open GPX 1.1 files, and since Garmin appear to use any data in > <extensions>, the fact that they have a different internal schema > won't make a difference. Dave W's PolyValidateTest.gpx file (as it > currently exists) is an example of this solution, since it claims to > be GPX 1/1 but points to a schema that is different from what we > agreed was the "frozen" version. > > This solution also has the benefit of immediately exposing any invalid > GPX 1.1 files out there, and (assuming developers are validating their > output) preventing any more bad GPX 1.1 files from being created. > > 3. GPX 1.1 stays frozen, and we agree not to do a GPX 1.2 for 6 months > or so. Any namespaces used between now and then will have to work > around any problems uncovered. GPX 1.1 outputters will have to be > extra careful they are writing GPX that is actually valid, since > SAXCount can miss errors in <extensions>. When GPX 1.2 comes out, any > work arounds in external schemas should be discarded. > > Your thoughts? > -- > Dan Foster 4. Authoring application decides whether to use the existing (lax) or new (strict) schema, both of which are compatible with existing applications. Existing applications which validate to a fixed schema should validate to the existing (lax) schema and will not be affected. Regards, Dave
egroups+topografix.com on Fri Jan 21 11:40:38 2005 (link), replying to msg
Hello, Friday, January 21, 2005, 2:20:26 PM, David wrote: D> Actually, what I propose is that the authoring application gets to D> choose whether to use the 1.1 lax (current) or 1.1 (strict) schema. D> We to not change the current schema at all. So when I called this an D> alternate schema I mean alternate, (not replacement.) My apologies for mis-representing your proposal. D> 4. Authoring application decides whether to use the existing (lax) D> or new (strict) schema, both of which are compatible with existing D> applications. Existing applications which validate to a fixed schema D> should validate to the existing (lax) schema and will not be D> affected. This raises a question about whether there is a need or want for lax processing going forward. A year from now, if GPX 1.2 is released, would there be a need for lax processing? I'm of the opinion that strict should be the only [long-term] option, since it forces SAXCount to validate the entire file against all namespaces. This would be a problem for anyone hoping to mix their GPX with SVG, XHTML, or some other XML-based namespace that doesn't validate. If anyone is considering such a thing, now would be a good time to speak up. -- Dan Foster
dananderson2+yahoo.com on Fri Jan 21 13:01:38 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: [snip] > > Sample file and screenshot: > > http://www.topografix.com/gpx/samples/topografix/poly.gpx > > http://www.topografix.com/gpx/samples/topografix/poly.png > > Nice work! This is very impressive. I'll second that! > As usual, I have a nit to pick. The dots on the trail are spaced 5 > on the view but the file says 1. (This might be the windows > Graphics/GDI+ quirk of scaling user patterns by line width) David S. Wissenbach's PolyValidateTest has: <gpx_style:dasharray><gpx_style:dash mark="0.000001" space="5.000000" /> and Dan Foster's "poly" has: <dash mark="0.000001" space="1"/> I don't know what PolyValidateTest's display looks like but in both cases I would think a mark of length 0.000001 mm would be hard to see and doesn't seem to match the space length of 1 mm (or 5 mm). Or am I misreading the specification? Dan Anderson
egroups+topografix.com on Fri Jan 21 13:43:34 2005 (link), replying to msg
Hello, Friday, January 21, 2005, 4:01:29 PM, dananderson2 wrote: d> and Dan Foster's "poly" has: d> <dash mark="0.000001" space="1"/> d> I don't know what PolyValidateTest's display looks like but in both d> cases I would think a mark of length 0.000001 mm would be hard to see d> and doesn't seem to match the space length of 1 mm (or 5 mm). Or am I d> misreading the specification? You have to take the linecap into consideration. <width>1.5</width> <pattern>Dot</pattern> <linecap>round</linecap> <dasharray> <dash mark="0.000001" space="1" /> </dasharray> Without the linecap, I described a dash with an infinitely short length and a 1.5mm height. When you add the round linecap to both ends of that infinitely short line, you end up with a dot with a 1.5mm diameter. Why "0.0000001" and not "0.0"? Windows GDI+ won't display it otherwise. At one point I started working on an XSL transform to turn GPX into SVG. Perhaps that would be a useful and unbiased test for making sure our gpx_style and gpx_overlay output means what we think it means. -- Dan Foster
robertlipe+usa.net on Wed Jan 26 06:50:05 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > This would be a problem for anyone hoping to mix their GPX with SVG, > XHTML, or some other XML-based namespace that doesn't validate. If > anyone is considering such a thing, now would be a good time to speak > up. There are folks that probably _should_ be considerin this, but I don't think they know it. :-) Many of the geocaching extensions to GPX include tags that allow some degree of HTML markup. The content tends to be poorly defined and frequently isn't legal HTML at all, is of unspecified versions, doesn't call out whether it's a fragment, an entire html/body doc, and so on. Some kind of marriage with XHTML probably would solve a lot of problems for the readers, but that's not a corner of the world I undertand well enough to drive.
simonstl+simonstl.com on Wed Jan 26 07:05:41 2005 (link), replying to msg
robertlipe+usa.net (Robert Lipe) writes: >--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: >> This would be a problem for anyone hoping to mix their GPX with SVG, >> XHTML, or some other XML-based namespace that doesn't validate. If >> anyone is considering such a thing, now would be a good time to speak >> up. > >There are folks that probably _should_ be considerin this, but I >don't think they know it. :-) > >Many of the geocaching extensions to GPX include tags that allow some >degree of HTML markup. The content tends to be poorly defined and >frequently isn't legal HTML at all, is of unspecified versions, >doesn't call out whether it's a fragment, an entire html/body doc, and > so on. > >Some kind of marriage with XHTML probably would solve a lot of >problems for the readers, but that's not a corner of the world I >undertand well enough to drive. For a data collection project I'm working on, I'm planning to mix GPX with my own custom markup, but cook up a system to extract the GPX for those who want want pure GPX. I don't see any benefit to locking my system to the GPX schema, but figure it's useful as a starting point. (Also, SVG and XHTML do offer validation, and it would at least be possible to define GPX as a module that could be intermixed with them. On the other hand, GPX tools probably don't want to process, XHTML, SVG, or MyOwnMarkup.) Simon St.Laurent http://livingindryden.org/
davewissenbach+yahoo.com on Wed Jan 26 18:58:01 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+u...> wrote: > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > > This would be a problem for anyone hoping to mix their GPX with SVG, > > XHTML, or some other XML-based namespace that doesn't validate. If > > anyone is considering such a thing, now would be a good time to speak > > up. > > There are folks that probably _should_ be considerin this, but I > don't think they know it. :-) > > Many of the geocaching extensions to GPX include tags that allow some > degree of HTML markup. The content tends to be poorly defined and > frequently isn't legal HTML at all, is of unspecified versions, > doesn't call out whether it's a fragment, an entire html/body doc, and > so on. > > Some kind of marriage with XHTML probably would solve a lot of > problems for the readers, but that's not a corner of the world I > undertand well enough to drive. I was going to say that xhtml was expressed as DTDs and not schemas, but I guess that the W3C has been rectifying this problem. For example, see http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/ So creating a valid document that includes xhtml is certainly possible. And I would hope that anyone pretending to use xhtml would produce valid output -- after all, xhtml was developed in large part to get way from the tag soup of HTML. Dave
davewissenbach+yahoo.com on Wed Jan 26 19:07:34 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Simon St.Laurent" <simonstl+s...> wrote: > robertlipe+u... (Robert Lipe) writes: > >--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > >> This would be a problem for anyone hoping to mix their GPX with SVG, > >> XHTML, or some other XML-based namespace that doesn't validate. If > >> anyone is considering such a thing, now would be a good time to speak > >> up. > > > >There are folks that probably _should_ be considerin this, but I > >don't think they know it. :-) > > > >Many of the geocaching extensions to GPX include tags that allow some > >degree of HTML markup. The content tends to be poorly defined and > >frequently isn't legal HTML at all, is of unspecified versions, > >doesn't call out whether it's a fragment, an entire html/body doc, and > > so on. > > > >Some kind of marriage with XHTML probably would solve a lot of > >problems for the readers, but that's not a corner of the world I > >undertand well enough to drive. > > For a data collection project I'm working on, I'm planning to mix GPX > with my own custom markup, but cook up a system to extract the GPX for > those who want want pure GPX. I don't see any benefit to locking my > system to the GPX schema, but figure it's useful as a starting point. > > (Also, SVG and XHTML do offer validation, and it would at least be > possible to define GPX as a module that could be intermixed with them. > On the other hand, GPX tools probably don't want to process, XHTML, SVG, > or MyOwnMarkup.) > I'm not so sure. The next version of Wissenbach Map3D (which you might not ever see but is partly alive on my desktop) embeds an html browser in the application on a tab pane identical in size to the main map display pane. I'll mainly use this for displaying linked documents within the application frame, but will probably also run a stylesheet transformation to extract the contents of the gpx document to present a dual (graphical and textual) view of the information. This dual view might lead people to want to include fragments of html in the gpx file. As for SVG, I think that the big problem is that an SVG map implies that a coordinate tranformation has already taken place, where gpx has in my opinion, a big advantage in allowing the user agent to define the transform. So I view SVG as mainly an output format. (WM3D currently does very primative SVG output which will look much better once I teach the SVG converter to process the new gpx_overlay and gpx_style schemas.) Regards, Dave > Simon St.Laurent > http://livingindryden.org/
simonstl+simonstl.com on Thu Jan 27 06:30:01 2005 (link), replying to msg
davewissenbach+yahoo.com (David S. Wissenbach) writes: >I was going to say that xhtml was expressed as DTDs and not schemas, >but I guess that the W3C has been rectifying this problem. For >example, see > >http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/ > >So creating a valid document that includes xhtml is certainly >possible. The schema specification doesn't make creating many kinds of modules particularly simple, so I'm not sure that's any real advantage. It may be something the GPX community wants to explore, however, and might not take major retrofitting. >And I would hope that anyone pretending to use xhtml would produce >valid output -- after all, xhtml was developed in large part to get >way from the tag soup of HTML. Personally, I rarely care about validation. The tag soup problems I have with HTML are far more frequently syntactic (missing tags) than structural. That bias factors into my lack of interest in using GPX for anything beyond the simplest of data structures - the schemas that seem to be the focus of GPX development send me running for the hills. With a GPS, of course! Simon St.Laurent http://simonstl.com/
gps_maps+travelbygps.com on Thu Jan 27 10:18:52 2005 (link), replying to msg
Getting back to how to fix my files... I have well over a 100 gpx files that potientially will not validate to GPX 1.1 standard and therefore cannot be opened by the latest release of MapSource. The files were created with a version of ExpertGPS writing to the GPX 1.0 standard. When I modified the files with the latest version of ExpertGPS, some reminants of the old standard reamined causing my present validation problem. Previoulsy in this thread, Robert pointed out that it was the <url> tag which was causing (at least one of) the problems. As Robert pointed said: > Remove this one tag and it validates. I'm guessing that Mapsource > will then gobble it right up. Yes! bravo! But Robert goes on to say: > The GPX 1.1 spelling of this would appear to be: > > <link href="http://www.travelbygps.com/guides/loonlake/loonlake.php"> > </link> Nope. I can't get this to work. I was hoping that I could do a simple find-and-repalce operation, finding the offinding tag <url> and replacing it with ... what? I would rather not simply delete the line. Is there a tag that I can use in place of <url> which will be ignored, a tag that I can use as a place holder until I figure out what the proper syntax should be? Please reply, - Doug
robertlipe+usa.net on Thu Jan 27 11:53:13 2005 (link), replying to msg
> > The GPX 1.1 spelling of this would appear to be: > > > > <link > href="http://www.travelbygps.com/guides/loonlake/loonlake.php"> > > </link> > > Nope. I can't get this to work. Can you be more specific? That is the way to express this in 1.1 and it does validate. > I was hoping that I could do a simple find-and-repalce operation, > finding the offinding tag <url> and replacing it with ... what? I > would rather not simply delete the line. For the example you sent, a "simple" find-and-replace is all it takes: $ SAX2Count /tmp/LoonLakeRoutes.gpx Error at file /tmp/LoonLakeRoutes.gpx, line 33, char 7 Message: Unknown element 'url' Error at file /tmp/LoonLakeRoutes.gpx, line 35, char 7 Message: Element 'url' is not valid for content model: '(ele?,time?,magvar?,geoidheight?,name?,cmt?,desc?,src?,link*,sym?,type?,fix?,sat?,hdop?,vdop?,pdop?,ageofdgpsdata?,dgpsid?,extensions?)' (robertl) rjloud:/tmp $ sed 's#<url>#<link href="#;s#</url>#"></link>#' LoonLakeRoutes.gpx > fixed.gpx (robertl) rjloud:/tmp $ SAX2Count fixed.gpx fixed.gpx: 422 ms (5647 elems, 2966 attrs, 9396 spaces, 51642 chars) We start with a file the contains the error, fixed it, and now it validates. The files differ in only the one line: (robertl) rjloud:/tmp $ diff LoonLakeRoutes.gpx fixed.gpx 33c33 < <url>http://www.travelbygps.com/guides/loonlake/loonlake.php</url> --- > <link href="http://www.travelbygps.com/guides/loonlake/loonlake.php"></link> My guess is that you have at least one _other_ problem in the files that's resulting in them still being invalid. /me wonders if it would be appropriate to offer consulting services for automating fixing your hundred files, validating them, and returning them... RJL
gps_maps+travelbygps.com on Fri Jan 28 03:16:06 2005 (link), replying to msg
--- Robert Lipe wrote: > /me wonders if it would be appropriate to offer consulting services for > automating fixing your hundred files, validating them, and returning. Would you promise to retain my metadata? ;) OK, I got this to validate, I had to deal with the <urlname> tag also. The result is that the file opens in MapSource, but now ExpertGPS does not display the waypoint or route link info. I guess I can sacrafice some of my data not being displayed in ExpertGPS, in exchange for MapSource being able to open them. - Doug
robertlipe+usa.net on Fri Jan 28 08:18:56 2005 (link), replying to msg
> > /me wonders if it would be appropriate to offer consulting services > for > automating fixing your hundred files, validating them, and > returning. > > Would you promise to retain my metadata? ;) Yes, for something like this, I'd just write a custom brute force "fix whatever is broken" editor and not try to wrap GPSBabel's brain around "you must now not track merely tracks, waypoints, and routes but you must also drag around parent file information" which is what GPSBabel really needs to handle metadata sensibly at all. > OK, I got this to validate, I had to deal with the <urlname> tag also. > > The result is that the file opens in MapSource, but now ExpertGPS > does not display the waypoint or route link info. Sigh. Presumably ExpertGPS wants to see the same (wrong) thing it wrote. > I guess I can sacrafice some of my data not being displayed in > ExpertGPS, in exchange for MapSource being able to open them. If it _really_ matters to you, perhaps you can provide both variations until ExpertGPS is revved. If these are in some kind of database and generated "on the fly" that might not be too hard at all. RJL
azbithead+gmail.com on Mon Jan 31 15:26:39 2005 (link), replying to msg
We at Garmin want to continue to import and export GPX files in our applications. If you release a new version of GPX that uses "strict" processing for wildcards it will be difficult to do so. Our applications currently do not require Internet accessibility. We chose this because there are use cases (most notably automotive laptop usage) where Internet accessibility can be difficult. When strict processing is specified the XML processor requires that all schemas used in an instance document be available. If any are not available the document will fail to validate. The only way we can hope to make all possibles schemas available is if they are accessed via the Internet. We chose to build the schemas we care about into our executables so that we know they will always be available. That means that we cannot validate wildcards that use unknown schemas. However that's OK because, by definition, we don't care about data using unknown schemas. Lax processing of wildcards allows us to fully validate all the parts of a GPX document that we know and care about and ignore the rest. Strict processing will make that impossible for us. Thanks, Steve
davewissenbach+yahoo.com on Tue Feb 01 06:02:27 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "azbithead" <azbithead+g...> wrote: > > We at Garmin want to continue to import and export GPX files in our > applications. If you release a new version of GPX that uses "strict" > processing for wildcards it will be difficult to do so. > > Our applications currently do not require Internet accessibility. We > chose this because there are use cases (most notably automotive laptop > usage) where Internet accessibility can be difficult. When strict > processing is specified the XML processor requires that all schemas > used in an instance document be available. If any are not available > the document will fail to validate. The only way we can hope to make > all possibles schemas available is if they are accessed via the > Internet. We chose to build the schemas we care about into our > executables so that we know they will always be available. That means > that we cannot validate wildcards that use unknown schemas. However > that's OK because, by definition, we don't care about data using > unknown schemas. Lax processing of wildcards allows us to fully > validate all the parts of a GPX document that we know and care about > and ignore the rest. Strict processing will make that impossible for us. > > Thanks, > Steve What I proposed previously was the use of an alternate strict schema, which can be specified with the schema location. Garmin could always use the default, lax version of the schema, regardless of what the author specified. Remember that MapSource did operate correctly with the proposed alternate schema. So I DID keep you needs in mind with this proposal. We would always publish a lax version of the schema, and a strict version of the schema. Those of us who choose to use the gpx_overlay and gpx_style schemas should also be able to benefit from the interoperability improvements imposed by unambiguous validation, just as Garmin has chosen to protect itself from poorly-formed data in the base specification. Also remember that this data is in the extension namespaces and not in the main namespace in the first place in order to preserve compatibility for the long term as required by commercial enterprises such as yours. In return, you might make a concession that allows those of us pioneering the overlay schema to progress. I think that the need for gpx_overlay and gpx_style come about because they address a few problems that the SVG working group has not addressed -- that text is specified at device resolution, and that the user agent can choose the cartographic transform. So eventually Garmin might want to support gpx_style and gpx_overlay as well. Or at least give use the benefit of your experience and tell us why not. Regards, Dave
egroups+topografix.com on Tue Feb 01 07:15:37 2005 (link), replying to msg
Hello, Tuesday, February 1, 2005, 8:59:57 AM, David wrote: D> What I proposed previously was the use of an alternate strict D> schema, which can be specified with the schema location. Garmin D> could always use the default, lax version of the schema, regardless D> of what the author specified. D> Remember that MapSource did operate correctly with the proposed D> alternate schema. So I DID keep you needs in mind with this proposal. I think we can take this even further, and arrive at a solution that works for everyone. From what I've understood from the emails on this topic, there are some perceived uses for a lax schema, but nobody has actually mixed in a non-validating schema yet, or has concrete plans to do so. If we can solve Garmin's issue, I strongly believe we should require all future GPX files to reference a strict schema, and that the strict schema should be the only version posted online. Since the lax version is only needed by MapSource, and MapSource stores its schemas within the application, there's no need to have a second version of the schema online. I believe Garmin can solve their local-validation issue with a few lines of code. This is conjecture based on two observations: 1. GPX 1.1 schema is included as a resource in MapSource. 2. Dave W's instance document that referenced a different GPX 1.1 schema (strict) was correctly opened in MapSource. That shows that MapSource can validate against a schema that isn't a word-for-word copy of the actual schema used in the instance doc. My solution: 1. Garmin includes the identical strict GPX 1.2 schema in their app. 2. MapSource loads this schema into a string object "GPX_output_schema" 3. MapSource copies this string object to "GPX_input_schema" 4. MapSource replaces "##strict" with "##lax" in GPX_input_schema only. 5. When importing a file, MapSource validates against GPX_input_schema. 6. When exporting a file, MapSource validates (does MapSource even do this?) against GPX_output_schema. If MapSource doesn't do any validation of the GPX data it creates, there's an even simpler solution: Steve takes the strict GPX 1.2 schema and replaces "##strict" with "##lax" before pasting it into MapSource. No program changes required. This is essentially what Dave W did with his MapSource test - and it worked! (Dave made and referenced a strict 1.1 schema by replacing ##lax with ##strict and posting it on his Web site.) By replacing strict with lax before validating, MapSource is telling the XML parser "I only care about validating against the GPX base schema that I use. Ignore the extension schemas that I don't care about." That matches perfectly with what Garmin is trying to accomplish. -- Dan Foster
azbithead+gmail.com on Tue Feb 01 10:32:15 2005 (link), replying to msg
I guess I'm a little confused about the need for strict processing. Do you want it so that content for these overlay and style schemas is always validated? Or is it that you actually want *any* data in an extension to be always validated? As an aside, I did some experimenting on the behavior associated with lax processing. My experiments seem to indicate that validation does not occur only if the root element of a wildcard is not recognized to be defined by any available schema. If the root element does appear to be defined by an available schema then that whole element and its children will be validated. Given that, perhaps lax processing is not as bad you think it is. - Steve
egroups+topografix.com on Tue Feb 01 13:55:24 2005 (link), replying to msg
Hello, Tuesday, February 1, 2005, 1:31:06 PM, Steve wrote: a> I guess I'm a little confused about the need for strict processing. Do a> you want it so that content for these overlay and style schemas is a> always validated? Or is it that you actually want *any* data in an a> extension to be always validated? I want all data in all GPX files to validate. I don't see how anything less could be acceptable. What's the point of saying "most of the data in your GPX file must validate", or "your base GPX must validate, but you can put garbage in <extensions>"? And by "validate", I mean "pass the SAXCount test". I don't mean "pass the MapSource test". As I understand it, the MapSource test only tests against the schemas that MapSource understands, which currently are the GPX 1.0 and 1.1 base schemas. MapSource is the only program I know of that checks incoming GPX data for any kind of correctness. The rest of us just run any files that generate program errors through SAXCount to determine who is at fault. If you mean something else when you say "validate", please let us know so there's no confusion. a> As an aside, I did some experimenting on the behavior associated with a> lax processing. My experiments seem to indicate that validation does a> not occur only if the root element of a wildcard is not recognized to a> be defined by any available schema. If the root element does appear to a> be defined by an available schema then that whole element and its a> children will be validated. Given that, perhaps lax processing is not a> as bad you think it is. I'd argue that if ##lax allows even a single error, we should use ##strict instead. The upside is that it catches *all* errors. The downsides are that: 1. MapSource needs a slight change. 2. People can't mix non-validating schemas in using <extensions> I think I addressed #1 in my last email. I'm interested to hear if you agree. If you don't, perhaps you'd be willing to post a code snippet that shows how you validate the GPX on input? If #2 (mixing in non-validating schemas) is going to be needed in the future, there's an easy way to implement this: create another sub-schema "gpx_lax" that just defines its own non-validating extensions element (using ##lax). Something like: <wpt> <extensions> <gpx_lax:lax-stuff-goes-here> <svg>...</svg> </gpx_lax:lax-stuff-goes-here> </extensions> </wpt> -- Dan Foster
simonstl+simonstl.com on Tue Feb 01 14:07:37 2005 (link), replying to msg
egroups+topografix.com (Dan Foster) writes: >I want all data in all GPX files to validate. I don't see how >anything less could be acceptable. What's the point of saying "most >of the data in your GPX file must validate", or "your base GPX must >validate, but you can put garbage in <extensions>"? It opens up a lot of possibilities to say that, actually. So long as the data in the extensions is well-formed, there's no need to validate that data if you don't understand (or care) what the extension is about. It makes for a much more flexible system without people stepping on each other's toes everytime someone wants to do something different. Simon St.Laurent http://simonstl.com/
egroups+topografix.com on Tue Feb 01 14:42:16 2005 (link), replying to msg
Hello, Tuesday, February 1, 2005, 5:07:17 PM, Simon wrote: S> It opens up a lot of possibilities to say that, actually. So long as S> the data in the extensions is well-formed, there's no need to validate S> that data if you don't understand (or care) what the extension is about. S> It makes for a much more flexible system without people stepping on each S> other's toes everytime someone wants to do something different. You can do anything you want within your own private schema, including defining your own <extensions>-style wildcard (with lax processing, if you like) for mixing in whatever you want. Are you saying that you want to be able to do this without declaring any additional schemas? If that's a real concern, we could define TWO wildcard placeholders, one with strict processing for those of us that want to exchange data between programs, and one with lax [or no] processing for those who just want a hands-off sandbox to work in for their own needs. -- Dan Foster
davewissenbach+yahoo.com on Tue Feb 01 18:16:19 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "azbithead" <azbithead+g...> wrote: > > I guess I'm a little confused about the need for strict processing. Do > you want it so that content for these overlay and style schemas is > always validated? Or is it that you actually want *any* data in an > extension to be always validated? > > As an aside, I did some experimenting on the behavior associated with > lax processing. My experiments seem to indicate that validation does > not occur only if the root element of a wildcard is not recognized to > be defined by any available schema. If the root element does appear to > be defined by an available schema then that whole element and its > children will be validated. Given that, perhaps lax processing is not > as bad you think it is. > > - Steve Thanks for setting me straight, and thanks for caring enough to run this experiment. I was able to replicate your testing with the same results. The test files, which contain validation errors in both gpx_style and map3d namespaces, throw validation errors with either lax or strict processing but not when the schema locations for the extension namespaces are missing. I've posted the test files at http://www.gpstrailmaps.com/map3d/1/1/strict/ Regards, Dave
azbithead+gmail.com on Wed Feb 02 09:42:22 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > And by "validate", I mean "pass the SAXCount test". I don't mean > "pass the MapSource test". As I understand it, the MapSource test > only tests against the schemas that MapSource understands, which > currently are the GPX 1.0 and 1.1 base schemas. MapSource is the only > program I know of that checks incoming GPX data for any kind of > correctness. The rest of us just run any files that generate program > errors through SAXCount to determine who is at fault. > > If you mean something else when you say "validate", please let us know > so there's no confusion. When I say "validate" I am referring to the processing performed by an XML processor that conforms to the XML Schema recommendation when it parses an instance document and determines that its data satisfies the constraints specified in its associated schema(s). Note that this is not my definition of the term but rather the definition of the XML Schema recommendation. Pehaps it would be good for the sake of our discussions if we defined a term other than "validate" for "pass the SaxCount test" since "validate" already has a meaning in the larger XML Schema context. Here's how MapSource processes GPX documents: MapSource has the Xerces parser (the same one as SaxCount) compiled and linked in. When MapSource opens a GPX document it immediately passes the document to the Xerces parser to be parsed and validated (as defined above). MapSource supplies the schemas that it knows about (currently GPX 1.0 and 1.1 as well as others) to the Xerces parser for this processing. MapSource configures the Xerces parser to disregard any "schemaLocation" attributes contained in the instance and instead use only the schemas we've supplied. If any part of the document fails to validate (according to the rules of the supplied schemas), MapSource is notified by Xerces and the document is rejected. Otherwise, Xerces gives MapSource a DOM node tree that represents the document's contents. MapSource first looks at the the namespace of the root node to determine what kind of data is contained in the tree. This lets us know if the document is a GPX 1.0, GPX 1.1 or other type of document. Then MapSource traverses the node tree, extracts the data and stores it in MapSource's internal data format. Note that the lax processing specified for extensions in GPX 1.1 allows the Xerces parser to suspend validation for data in extensions that have no schema or a schema that MapSource has not supplied. The document as a whole will then pass the validation processing done by Xerces and MapSource can then extract the data for the parts that conform to the schemas supplied. In no case can MapSource do anything with extension data defined by schemas that it doesn't understand. This situation allows producers of GPX instance documents to insert their own extensions, distribute them to programs like MapSource which will be able to safely ignore the extension and still retrieve the base GPX data. - Steve
simonstl+simonstl.com on Wed Feb 02 10:06:08 2005 (link), replying to msg
egroups+topografix.com (Dan Foster) writes: >Tuesday, February 1, 2005, 5:07:17 PM, Simon wrote: >>It opens up a lot of possibilities to say that, actually. So long as >> the data in the extensions is well-formed, there's no need to >>validate that data if you don't understand (or care) what the >>extension is about. > >> It makes for a much more flexible system without people stepping on >>each other's toes everytime someone wants to do something different. > >You can do anything you want within your own private schema, including >defining your own <extensions>-style wildcard (with lax processing, if >you like) for mixing in whatever you want. Are you saying that you >want to be able to do this without declaring any additional schemas? No, I was just saying that I thought the comment you'd made earlier was dramatically overblown: >I want all data in all GPX files to validate. I don't see how >anything less could be acceptable. What's the point of saying "most >of the data in your GPX file must validate", or "your base GPX must >validate, but you can put garbage in <extensions>"? "Anything less" is perfectly acceptable or even preferred in a lot of circumstances, so I have a hard time seeing why you think this is a problem. As I noted earlier, I'm using the GPX vocabulary in one of my own projects, but completely ignoring the schemas. That works better for me by far than trying to fit what I want to do into the schema framework that seems to be the main subject of this mailing list. Simon St.Laurent http://simonstl.com/
davewissenbach+yahoo.com on Wed Feb 02 11:43:50 2005 (link), replying to msg
> > Thanks for setting me straight, and thanks for caring enough to run > this experiment. > > I was able to replicate your testing with the same results. The test > files, which contain validation errors in both gpx_style and map3d > namespaces, throw validation errors with either lax or strict > processing but not when the schema locations for the extension > namespaces are missing. > > I've posted the test files at > > http://www.gpstrailmaps.com/map3d/1/1/strict/ > I should have said http://www.gpstrailmaps.com/gpx/1/1/strict/ (This time I cut and pasted.) Dave
ptomblin+gmail.com on Wed Feb 02 13:40:59 2005 (link), replying to msg
Just to revive an old topic: On Thu, 13 Jan 2005 13:45:40 -0500, Dan Foster <egroups+topografix.com> wrote: > Thursday, January 13, 2005, 7:28:25 AM, Paul wrote: > > P> On Thu, 13 Jan 2005 11:46:55 -0000, gpsmap196 <gpsmap196+yahoo.com> > wrote: > >> Is there a way to implement this into the GPX file format, so that > >> the waypoint also holds a Class, sub class and country code?? > > P> In order for a > P> GPX extension schema to be useful in a case like this, the program > P> that takes the GPX data and puts it into your Garmin would have to > P> know about the extension schema as well. Is the program you are using > P> to do this from Garmin or from a third party? Either way, I would be > P> interested in cooperating with them to put together an extension > P> schema that we could all use. > > I will implement this in EasyGPS and ExpertGPS if we develop a common > schema. Well, somebody from Garmin wrote to this list a few days ago, so I contacted them about putting this information into GPX and modifying Garmin's program to pass this information into the GPS, and all he had to say was: "Unfortunately, we don't have the resources at this time to pursue the development effort you are suggesting. We appreciate your interest in our products." Do you think there is a point in doing this if there isn't any interest from Garmin? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
jame_smith009+yahoo.com on Thu Mar 10 04:00:23 2005 (link)
HELLO FRIEND'S!! THIS IS 4 YOU?? THIS IS A FREE CALLING CARDS SITE..ABSOLUTELY FREEEEE??....ITS REAL BUDDY!!!!DONT DELAY YOU JUST SIGN IN AND GO THROUGH THIS SITE ....LOGIN,SIGNUP AND GET FREE CALLING CARDS?? THIS IS NOT A SPAM.REALLY CHEECK IT AND LOGIN http://ww3.6URL.com/D4O If u are looking for free cash then login to http://ww3.6URL.com/8KZ
smitha_kathy+yahoo.com on Sun Mar 13 20:53:15 2005 (link)
Hello, I have always had problems using search engines to find what I wanted,as it always poped up results that I was in no way looking for. I just happen to go through a very simple page, with relavent links on computing and felt that it could be useful to you too. You may go to http://www.yahoouk.org/computing for the computing catalog with the following sub areas : Computer Hardware, Computer Peripherals,Computer Programming,Computer Security,Computer Services,Computer Storage Devices,Document Management,Ecommerce, Email, Enterprise Software Help Desk Services, Internet Service Providers, Memory, Network Design & Construction, Network Hardware, Online Content, Printers, Software Applications, Software Development and Web Hosting. Kathy
betlis007+yahoo.de on Tue Mar 15 11:44:56 2005 (link)
New GPS devices as Garmin eTrex Vista Color, Garmin GPSmap 60, etc. use different colors for the visualization of tracks. How is the correct syntax within <trk></trk>, if I like to represent a track e.g. red? Many thanks for the help. Christian
egroups+topografix.com on Tue Mar 15 12:00:05 2005 (link), replying to msg
Hello, Tuesday, March 15, 2005, 2:44:12 PM, betlis007 wrote: b> New GPS devices as Garmin eTrex Vista Color, Garmin GPSmap 60, etc. b> use different colors for the visualization of tracks. How is the b> correct syntax within <trk></trk>, if I like to represent a track b> e.g. red? Many thanks for the help. Christian Take a look at the <line> element at http://www.topografix.com/gpx/gpx_style/0/2/ For the rest of the GPX mailing list: ExpertGPS with support for gpx 1.1, gpx_style 0.2 and gpx_overlay 0.2 is now available. Comments on the GPX support would be appreciated. See /Program Files/ExpertGPS/Sample Files/Stow.gpx for a GPX file that uses most of the new overlay and style elements. http://www.expertgps.com/beta.asp -- Dan Foster
feedback+gpxchange.com on Tue Mar 15 15:24:37 2005 (link)
Hello, Please visit http://www.gpxchange.com and give it a whirl. Although pretty basic at this point, it should allow reasonably good sharing of GPX files and visualization of the data contained within. Use the Contact link at the bottom of any page to forward questions or comments. I'm sure things will break at this early stage and some may be irked that the current focus is the US. However, things should develop rapidly. Hope to have a forum up soon! Thanks Fred Williams
davewissenbach+yahoo.com on Wed Mar 16 20:05:25 2005 (link)
Dan, I've taken a cursory look at this -- the new version of Expert GPS has really nice output. One compatibility issue is still the interpretation of the dots and dashes, and whether these should scale with zoom in or out. I've chosen in WM3D 3.0 vaporware to always interpret these in display coordinates, so the 7.0 mm 2.0 mm pattern comes out fairly large, as you can see in the screen shot linked below. I see that ExpertGPS scales this with the view, but the problem comes up -- at what scale does the pattern actually match the screen. Another problem I see with interchange is that I'm using a fairly large default font size -- can we agree on a default font size? (Because Expert GPS is the reference implementation, I'll just go with what you are already using, but I'd like the default value to be documented.) I also like the text following along a path, but I think that this is highly implementation dependent. I did this for SVG output, but probably won't in my new application. Will Expert GPS ignore rotation and draw text along the path, or implement rotation if requested? Here's a screen shot of the output of WM3D 3.0 prototype 0.1 with your sample map. In general, graphics match well but not text. http://www.gpstrailmaps.com/gpx.samples/Stow.png I also wonder whether rendering order will eventually give a problem with large overlapping areas. For example, the overlap of the pond at the upper left with the boundary region. Do we need Z-order? Or perhaps a rule that fully opaque objects must be rendered first? I suggest that polylines be rendered first in the order in which they appear, followed by tracks, routes, waypoints, and then all associated text and labels. Regards, Dave
betlis007+yahoo.de on Wed Mar 16 23:40:50 2005 (link), replying to msg
Hi Dan For the further development, I think the support of fonts etc. is a good thing. For the practical use with the current GPS devices is however only the track color of importance (to be not oversized). The not specified parameters (opacity, family generic, pattern, etc.) for visualization in software products such as ExpertGPS as default values (in the software products). What do you think from the following minimum declaration?: <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="ExpertGPS 1.9 b1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.topografix.com/GPX/gpx_style/0/2 http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd http://www.topografix.com/GPX/gpx_overlay/0/2 http://www.topografix.com/GPX/gpx_overlay/0/2/gpx_overlay.xsd"> <metadata> <time>2005-03-15T21:16:34Z</time> <bounds minlat="46.6301354080533" minlon="9.221943373" maxlat="46.6518348735701" maxlon="9.279043373"/> </metadata> <trk> <name>ACTIVE LOG</name> <type>Track rouge</type> <extensions> <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>ff0000</color> </line> </extensions> <trkseg> <trkpt lat="46.6457919844388" lon="9.252943373"/> <trkpt lat="46.6456546460495" lon="9.260743373"/> <trkpt lat="46.6455173076601" lon="9.221943373"/> </trkseg> </trk> </gpx> Christian Steiner / www.GPS-Tracks.com --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Hello, > > Tuesday, March 15, 2005, 2:44:12 PM, betlis007 wrote: > > b> New GPS devices as Garmin eTrex Vista Color, Garmin GPSmap 60, etc. > b> use different colors for the visualization of tracks. How is the > b> correct syntax within <trk></trk>, if I like to represent a track > b> e.g. red? Many thanks for the help. Christian > > Take a look at the <line> element at > http://www.topografix.com/gpx/gpx_style/0/2/ > > > For the rest of the GPX mailing list: > ExpertGPS with support for gpx 1.1, gpx_style 0.2 and gpx_overlay 0.2 > is now available. Comments on the GPX support would be appreciated. > See /Program Files/ExpertGPS/Sample Files/Stow.gpx for a GPX file that > uses most of the new overlay and style elements. > http://www.expertgps.com/beta.asp > > -- > Dan Foster
dananderson2+yahoo.com on Thu Mar 17 11:34:22 2005 (link)
I'd like to see some additional functionality incorporated in the GPX_Overlay. I've added a few sample files to the "FILES" section, DiscussionExamples folder: OziExplorerNoteExample.png, OziExplorerPicExample.png, and NG_TopoNotePicExample.jpg 1. One item is images overlaid on the background map, for instance the yellow arrows in the examples given. This type is not a "hot spot" ? no link to anything else. I wouldn't use a waypoint for these since sending the location of the arrows to a GPS receiver is of no use. 2. Another item is images overlaid on the background map to form a "hot spot". It represents a link to some other type of document (image, sound, video, text, etc.). The note and camera icons in the OziExplorer examples and the "picture" rectangle in the TOPO! example represent this kind of functionality. In the Ozi note example, the map feature MF 3 is a text note that is "attached" to the text note icon above the dialog by the red line. In the Ozi picture example, the map feature MF 5 is linked to the camera icon below the dialog. In some cases a waypoint could serve the purpose; however, in some programs it takes many "clicks" to get to the document. It should be as simple as double clicking on the icon. In other cases the location of the icon on the map may not be useful in the real world so it shouldn't be a waypoint. So I'd like to see this type of function available without the use of waypoints. An icon on the map linked to an HTML document would give at lot of flexibility and functionality. It could be something similar to the html "<a href=URL> <img= >" and include lat/long values for placement of the image. Dan A.
egroups+topografix.com on Tue Mar 22 09:37:34 2005 (link), replying to msg
Hello, Wednesday, March 16, 2005, 11:04:37 PM, David wrote: D> One compatibility issue is still the interpretation of the dots and D> dashes, and whether these should scale with zoom in or out. I've D> chosen in WM3D 3.0 vaporware to always interpret these in display D> coordinates, so the 7.0 mm 2.0 mm pattern comes out fairly large, as D> you can see in the screen shot linked below. I see that ExpertGPS D> scales this with the view, but the problem comes up -- at what scale D> does the pattern actually match the screen. I proposed 1:24000 scale earlier, and that's what ExpertGPS uses. The best way to get a 1:24000 scale view in ExpertGPS is to click Zoom to Scale on the Map menu when viewing a Quick or Scanned map. Topo/Aerial is locked to Terraserver sizes. I've checked the line widths with calipers and a scanned USGS quad printed at 1:24K scale. I'm willing to believe that any dash patterns ExpertGPS writes out are incorrect, though. D> Another problem I see with interchange is that I'm using a fairly D> large default font size -- can we agree on a default font size? D> (Because Expert GPS is the reference implementation, I'll just go D> with what you are already using, but I'd like the default value to D> be documented.) ExpertGPS doesn't write out a text size for text that scales up and down with map scale changes. The scaling up and down only occurs if you set a max_scale for the object. The default text size for a waypoint with no max_scale in ExpertGPS is 10.0 pixels. D> I also like the text following along a path, but I think that this D> is highly implementation dependent. I did this for SVG output, but D> probably won't in my new application. Will Expert GPS ignore D> rotation and draw text along the path, or implement rotation if D> requested? Text along a path is the only option in ExpertGPS. I believe that a program should not fill GPX files with descriptions of "default" behavior that the user didn't specify. Using the text size example above, there's no reason to write out a "text size = 10 pixels" unless the user specifically changed the font size. D> Here's a screen shot of the output of WM3D 3.0 prototype 0.1 with D> your sample map. In general, graphics match well but not text. D> http://www.gpstrailmaps.com/gpx.samples/Stow.png 404 File not found. D> I also wonder whether rendering order will eventually give a problem D> with large overlapping areas. For example, the overlap of the pond D> at the upper left with the boundary region. Do we need Z-order? Or D> perhaps a rule that fully opaque objects must be rendered first? I think the Z-order is implied by the order that objects are listed (within their category only) D> I suggest that polylines be rendered first in the order in which D> they appear, followed by tracks, routes, waypoints, and then all D> associated text and labels. My order looks like this: FillPolylines (draw the water in the pond) FillTracks FillRoutes LinePolylines (draw the shoreline of the pond) LineTracks LineRoutes DrawTextNotes DrawWaypoints Feel free to contact me off-list if you want to do some in-depth compatibility testing. -- Dan Foster
egroups+topografix.com on Tue Mar 22 09:51:54 2005 (link), replying to msg
Hello, Thursday, March 17, 2005, 2:39:37 AM, Christian wrote: b> For the further development, I think the support of fonts etc. is a b> good thing. For the practical use with the current GPS devices is b> however only the track color of importance (to be not oversized). b> The not specified parameters (opacity, family generic, pattern, b> etc.) for visualization in software products such as ExpertGPS as b> default values (in the software products). What do you think from b> the following minimum declaration?: b> <?xml version="1.0" encoding="UTF-8"?> b> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" b> creator="ExpertGPS 1.9 b1" b> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" b> xsi:schemaLocation="http://www.topografix.com/GPX/1/1 b> http://www.topografix.com/GPX/1/1/gpx.xsd b> http://www.topografix.com/GPX/gpx_style/0/2 b> http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd b> http://www.topografix.com/GPX/gpx_overlay/0/2 b> http://www.topografix.com/GPX/gpx_overlay/0/2/gpx_overlay.xsd"> b> <metadata> b> <time>2005-03-15T21:16:34Z</time> b> <bounds minlat="46.6301354080533" minlon="9.221943373" b> maxlat="46.6518348735701" maxlon="9.279043373"/> b> </metadata> b> <trk> b> <name>ACTIVE LOG</name> b> <type>Track rouge</type> b> <extensions> b> <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> b> <color>ff0000</color> b> </line> b> </extensions> b> <trkseg> b> <trkpt lat="46.6457919844388" lon="9.252943373"/> b> <trkpt lat="46.6456546460495" lon="9.260743373"/> b> <trkpt lat="46.6455173076601" lon="9.221943373"/> b> </trkseg> b> </trk> b> </gpx> This is valid GPX, and displays as a red line in ExpertGPS. I was a little to quick to suggest that this should be the way to specify that you want a red track sent to the GPS, however. It's the best way we have *now* to express this, but maybe it could be improved in the future. I can see a case where the user wants their three types of roads displayed like this: Asphalt Road Thick black line on map Green line on GPS Dirt Road Grey line on map Yellow line on GPS Footpath Dashed black line on map Red line on GPS My point is that a computer screen map and a GPS screen map may have totally different meanings to the user. When the gpx_style color is used in a gpx_overlay, I'm indicating that this is a color to be used on a computer or printed map. Perhaps we need a gps_display schema that would use the same gpx_style color to indicate a GPS track color. I'm already doing something similar in my private schema to allow a wider range of map symbols in ExpertGPS, while still allowing the user to specify a gpx <sym> for the GPS. -- Dan Foster
egroups+topografix.com on Tue Mar 22 10:05:15 2005 (link), replying to msg
Hello, Thursday, March 17, 2005, 2:34:13 PM, dananderson2 wrote: d> I'd like to see some additional functionality incorporated in the d> GPX_Overlay. I would, too. All three of your suggestions would be good additions to gpx_overlay. Care to propose a schema for them? The idea of "geo-referenced links to photos" is one that several GPX applications already support, but I'd like to see it standardized and usable outside a <wpt>. <link> seems the obvious place for this, but it's in the main schema, and we didn't leave any way to extend it. On a related note (since we're discussing adding to gpx_overlay), I'd like to allow <polyline> to have more than one set of points, similar to the way that <trk> can contain multiple <trkseg>s. I'm tracing some of the local streams of topo maps, and it would be nice to have a single "Elizabeth Brook" <polyline> object that contained both the main stream and its side branch. -- Dan Foster
geetha2505+yahoo.co.in on Sat Mar 26 07:55:45 2005 (link)
Hi.. Check this useful link ... http://www.google.com/url?sa=U&start=1&q=http://efrendz.info/all/computing.htm Nisha
paulh+logicsquad.net on Sun Mar 27 00:58:28 2005 (link)
Hello, This is bound to be a FAQ, though I could not find an answer in the list archive, nor could I find any relevant files. Is there a DTD version of the GPX schema, or, even better, a RELAX NG schema? My preferred XML editor is emacs + nxml-mode, and the latter needs a RELAX NG schema. I can build that from a DTD with Trang, but not from an XSD. -- Paul. w http://logicsquad.net/ h http://paul.hoadley.name/ [Non-text portions of this message have been removed]
egroups+topografix.com on Sun Mar 27 05:57:14 2005 (link), replying to msg
Hello, Sunday, March 27, 2005, 3:58:20 AM, Paul wrote: P> This is bound to be a FAQ, though I could not find an answer in the P> list archive, nor could I find any relevant files. Is there a DTD P> version of the GPX schema, or, even better, a RELAX NG schema? My P> preferred XML editor is emacs + nxml-mode, and the latter needs a P> RELAX NG schema. I can build that from a DTD with Trang, but not from P> an XSD. The XSD schema is the only definition of the GPX specification. In fact, by definition, it IS the definition. Nobody has ported the schema to DTD or RELAX NG, but I'm sure it would be welcomed if someone did. However, in cases of disagreement over meaning, we have decided that the XSD trumps the documentation or any other definition (DTD, "how it works in EasyGPS", etc). -- Dan Foster
paulh+logicsquad.net on Sun Mar 27 21:38:07 2005 (link), replying to msg
Hello, On Sun, Mar 27, 2005 at 08:58:43AM -0500, Dan Foster wrote: > Nobody has ported the schema to DTD or RELAX NG, but I'm sure it > would be welcomed if someone did. Attached are the straight conversions of GPX 1.0 and 1.1 from XSD to RNG by Sun's rngconv tool. Also attached are the straight conversions from RNG to RNC (RELAX NG Compact) by James Clark's Trang. Notes: 1. Trang was unable to convert either RNG schema to a DTD. 2. I modified the output of rngconv with the 1.1 XSD schema, as it included a local name that Trang didn't like: 'any(lax:##other)'. Knowing very little about XSD schemas, the significance of this name escapes me, so I have no idea if changing this to 'anylaxother' just to satisfy Trang will have any effect on the semantics of the RNG schema, though if it's just a name, I doubt it will. 3. By "straight conversions" I mean that I have not tested them in any way. It's just the output of the tools, so your mileage may vary. -- Paul. w http://logicsquad.net/ h http://paul.hoadley.name/ ---------- <?xml version="1.0"?> <grammar ns="http://www.topografix.com/GPX/1/0" xmlns="http://relaxng.org/ns/structure/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <start> <choice> <notAllowed/> <element name="gpx"> <attribute name="creator"> <data type="string"/> </attribute> <attribute name="version"> <value type="string">1.0</value> </attribute> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="author"> <ref name="string"/> </element> </optional> <optional> <element name="email"> <data type="string"> <param name="pattern">[\p{L}_]+(\.[\p{L}_]+)*+[\p{L}_]+(\.[\p{L}_]+)+</param> </data> </element> </optional> <optional> <element name="url"> <ref name="anyURI"/> </element> </optional> <optional> <element name="urlname"> <ref name="string"/> </element> </optional> <optional> <element name="time"> <ref name="dateTime"/> </element> </optional> <optional> <element name="keywords"> <ref name="string"/> </element> </optional> <optional> <element name="bounds"> <attribute name="maxlon"> <data type="decimal"> <param name="minInclusive">-180</param> <param name="maxInclusive">180</param> </data> </attribute> <attribute name="maxlat"> <data type="decimal"> <param name="minInclusive">-90</param> <param name="maxInclusive">90</param> </data> </attribute> <attribute name="minlon"> <data type="decimal"> <param name="minInclusive">-180</param> <param name="maxInclusive">180</param> </data> </attribute> <attribute name="minlat"> <data type="decimal"> <param name="minInclusive">-90</param> <param name="maxInclusive">90</param> </data> </attribute> </element> </optional> <zeroOrMore> <element name="wpt"> <attribute name="lon"> <data type="decimal"> <param name="minInclusive">-180</param> <param name="maxInclusive">180</param> </data> </attribute> <attribute name="lat"> <data type="decimal"> <param name="minInclusive">-90</param> <param name="maxInclusive">90</param> </data> </attribute> <optional> <element name="ele"> <ref name="decimal"/> </element> </optional> <optional> <element name="time"> <ref name="dateTime"/> </element> </optional> <optional> <element name="magvar"> <ref name="degreesType"/> </element> </optional> <optional> <element name="geoidheight"> <ref name="decimal"/> </element> </optional> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="cmt"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="src"> <ref name="string"/> </element> </optional> <optional> <element name="url"> <ref name="anyURI"/> </element> </optional> <optional> <element name="urlname"> <ref name="string"/> </element> </optional> <optional> <element name="sym"> <ref name="string"/> </element> </optional> <optional> <element name="type"> <ref name="string"/> </element> </optional> <optional> <element name="fix"> <ref name="fixType"/> </element> </optional> <optional> <element name="sat"> <ref name="nonNegativeInteger"/> </element> </optional> <optional> <element name="hdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="vdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="pdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="ageofdgpsdata"> <ref name="decimal"/> </element> </optional> <optional> <element name="dgpsid"> <ref name="dgpsStationType"/> </element> </optional> </element> </zeroOrMore> <zeroOrMore> <element name="rte"> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="cmt"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="src"> <ref name="string"/> </element> </optional> <optional> <element name="url"> <ref name="anyURI"/> </element> </optional> <optional> <element name="urlname"> <ref name="string"/> </element> </optional> <optional> <element name="number"> <ref name="nonNegativeInteger"/> </element> </optional> <zeroOrMore> <element name="rtept"> <attribute name="lon"> <data type="decimal"> <param name="minInclusive">-180</param> <param name="maxInclusive">180</param> </data> </attribute> <attribute name="lat"> <data type="decimal"> <param name="minInclusive">-90</param> <param name="maxInclusive">90</param> </data> </attribute> <optional> <element name="ele"> <ref name="decimal"/> </element> </optional> <optional> <element name="time"> <ref name="dateTime"/> </element> </optional> <optional> <element name="magvar"> <ref name="degreesType"/> </element> </optional> <optional> <element name="geoidheight"> <ref name="decimal"/> </element> </optional> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="cmt"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="src"> <ref name="string"/> </element> </optional> <optional> <element name="url"> <ref name="anyURI"/> </element> </optional> <optional> <element name="urlname"> <ref name="string"/> </element> </optional> <optional> <element name="sym"> <ref name="string"/> </element> </optional> <optional> <element name="type"> <ref name="string"/> </element> </optional> <optional> <element name="fix"> <ref name="fixType"/> </element> </optional> <optional> <element name="sat"> <ref name="nonNegativeInteger"/> </element> </optional> <optional> <element name="hdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="vdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="pdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="ageofdgpsdata"> <ref name="decimal"/> </element> </optional> <optional> <element name="dgpsid"> <ref name="dgpsStationType"/> </element> </optional> </element> </zeroOrMore> </element> </zeroOrMore> <zeroOrMore> <element name="trk"> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="cmt"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="src"> <ref name="string"/> </element> </optional> <optional> <element name="url"> <ref name="anyURI"/> </element> </optional> <optional> <element name="urlname"> <ref name="string"/> </element> </optional> <optional> <element name="number"> <ref name="nonNegativeInteger"/> </element> </optional> <zeroOrMore> <element name="trkseg"> <zeroOrMore> <element name="trkpt"> <attribute name="lon"> <data type="decimal"> <param name="minInclusive">-180</param> <param name="maxInclusive">180</param> </data> </attribute> <attribute name="lat"> <data type="decimal"> <param name="minInclusive">-90</param> <param name="maxInclusive">90</param> </data> </attribute> <optional> <element name="ele"> <ref name="decimal"/> </element> </optional> <optional> <element name="time"> <ref name="dateTime"/> </element> </optional> <optional> <element name="course"> <ref name="degreesType"/> </element> </optional> <optional> <element name="speed"> <ref name="decimal"/> </element> </optional> <optional> <element name="magvar"> <ref name="degreesType"/> </element> </optional> <optional> <element name="geoidheight"> <ref name="decimal"/> </element> </optional> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="cmt"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="src"> <ref name="string"/> </element> </optional> <optional> <element name="url"> <ref name="anyURI"/> </element> </optional> <optional> <element name="urlname"> <ref name="string"/> </element> </optional> <optional> <element name="sym"> <ref name="string"/> </element> </optional> <optional> <element name="type"> <ref name="string"/> </element> </optional> <optional> <element name="fix"> <ref name="fixType"/> </element> </optional> <optional> <element name="sat"> <ref name="nonNegativeInteger"/> </element> </optional> <optional> <element name="hdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="vdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="pdop"> <ref name="decimal"/> </element> </optional> <optional> <element name="ageofdgpsdata"> <ref name="decimal"/> </element> </optional> <optional> <element name="dgpsid"> <ref name="dgpsStationType"/> </element> </optional> </element> </zeroOrMore> </element> </zeroOrMore> </element> </zeroOrMore> </element> </choice> </start> <define name="degreesType"> <data type="decimal"> <param name="minInclusive">0</param> <param name="maxInclusive">360</param> </data> </define> <define name="nonNegativeInteger"> <data type="nonNegativeInteger"/> </define> <define name="anyURI"> <data type="anyURI"/> </define> <define name="decimal"> <data type="decimal"/> </define> <define name="dateTime"> <data type="dateTime"/> </define> <define name="dgpsStationType"> <data type="integer"> <param name="minInclusive">0</param> <param name="maxInclusive">1023</param> </data> </define> <define name="fixType"> <choice> <value type="string">3d</value> <value type="string">none</value> <value type="string">dgps</value> <value type="string">pps</value> <value type="string">2d</value> </choice> </define> <define name="string"> <data type="string"/> </define> </grammar> ---------- default namespace = "http://www.topografix.com/GPX/1/0" start = notAllowed | element gpx { attribute creator { xsd:string }, attribute version { xsd:string "1.0" }, element name { \string }?, element desc { \string }?, element author { \string }?, element email { xsd:string { pattern = "[\p{L}_]+(\.[\p{L}_]+)*+[\p{L}_]+(\.[\p{L}_]+)+" } }?, element url { anyURI }?, element urlname { \string }?, element time { dateTime }?, element keywords { \string }?, element bounds { attribute maxlon { xsd:decimal { minInclusive = "-180" maxInclusive = "180" } }, attribute maxlat { xsd:decimal { minInclusive = "-90" maxInclusive = "90" } }, attribute minlon { xsd:decimal { minInclusive = "-180" maxInclusive = "180" } }, attribute minlat { xsd:decimal { minInclusive = "-90" maxInclusive = "90" } } }?, element wpt { attribute lon { xsd:decimal { minInclusive = "-180" maxInclusive = "180" } }, attribute lat { xsd:decimal { minInclusive = "-90" maxInclusive = "90" } }, element ele { decimal }?, element time { dateTime }?, element magvar { degreesType }?, element geoidheight { decimal }?, element name { \string }?, element cmt { \string }?, element desc { \string }?, element src { \string }?, element url { anyURI }?, element urlname { \string }?, element sym { \string }?, element type { \string }?, element fix { fixType }?, element sat { nonNegativeInteger }?, element hdop { decimal }?, element vdop { decimal }?, element pdop { decimal }?, element ageofdgpsdata { decimal }?, element dgpsid { dgpsStationType }? }*, element rte { element name { \string }?, element cmt { \string }?, element desc { \string }?, element src { \string }?, element url { anyURI }?, element urlname { \string }?, element number { nonNegativeInteger }?, element rtept { attribute lon { xsd:decimal { minInclusive = "-180" maxInclusive = "180" } }, attribute lat { xsd:decimal { minInclusive = "-90" maxInclusive = "90" } }, element ele { decimal }?, element time { dateTime }?, element magvar { degreesType }?, element geoidheight { decimal }?, element name { \string }?, element cmt { \string }?, element desc { \string }?, element src { \string }?, element url { anyURI }?, element urlname { \string }?, element sym { \string }?, element type { \string }?, element fix { fixType }?, element sat { nonNegativeInteger }?, element hdop { decimal }?, element vdop { decimal }?, element pdop { decimal }?, element ageofdgpsdata { decimal }?, element dgpsid { dgpsStationType }? }* }*, element trk { element name { \string }?, element cmt { \string }?, element desc { \string }?, element src { \string }?, element url { anyURI }?, element urlname { \string }?, element number { nonNegativeInteger }?, element trkseg { element trkpt { attribute lon { xsd:decimal { minInclusive = "-180" maxInclusive = "180" } }, attribute lat { xsd:decimal { minInclusive = "-90" maxInclusive = "90" } }, element ele { decimal }?, element time { dateTime }?, element course { degreesType }?, element speed { decimal }?, element magvar { degreesType }?, element geoidheight { decimal }?, element name { \string }?, element cmt { \string }?, element desc { \string }?, element src { \string }?, element url { anyURI }?, element urlname { \string }?, element sym { \string }?, element type { \string }?, element fix { fixType }?, element sat { nonNegativeInteger }?, element hdop { decimal }?, element vdop { decimal }?, element pdop { decimal }?, element ageofdgpsdata { decimal }?, element dgpsid { dgpsStationType }? }* }* }* } degreesType = xsd:decimal { minInclusive = "0" maxInclusive = "360" } nonNegativeInteger = xsd:nonNegativeInteger anyURI = xsd:anyURI decimal = xsd:decimal dateTime = xsd:dateTime dgpsStationType = xsd:integer { minInclusive = "0" maxInclusive = "1023" } fixType = xsd:string "3d" | xsd:string "none" | xsd:string "dgps" | xsd:string "pps" | xsd:string "2d" \string = xsd:string ---------- <?xml version="1.0"?> <grammar ns="http://www.topografix.com/GPX/1/1" xmlns="http://relaxng.org/ns/structure/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <start> <choice> <notAllowed/> <element name="gpx"> <attribute name="creator"> <data type="string"/> </attribute> <attribute name="version"> <value type="string">1.1</value> </attribute> <optional> <element name="metadata"> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="author"> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="email"> <attribute name="domain"> <data type="string"/> </attribute> <attribute name="id"> <data type="string"/> </attribute> </element> </optional> <optional> <element name="link"> <ref name="linkType"/> </element> </optional> </element> </optional> <optional> <element name="copyright"> <attribute name="author"> <data type="string"/> </attribute> <optional> <element name="year"> <data type="gYear"/> </element> </optional> <optional> <element name="license"> <data type="anyURI"/> </element> </optional> </element> </optional> <zeroOrMore> <element name="link"> <ref name="linkType"/> </element> </zeroOrMore> <optional> <element name="time"> <ref name="dateTime"/> </element> </optional> <optional> <element name="keywords"> <ref name="string"/> </element> </optional> <optional> <element name="bounds"> <attribute name="maxlon"> <data type="decimal"> <param name="minInclusive">-180</param> <param name="maxExclusive">180</param> </data> </attribute> <attribute name="maxlat"> <data type="decimal"> <param name="minInclusive">-90</param> <param name="maxInclusive">90</param> </data> </attribute> <attribute name="minlon"> <data type="decimal"> <param name="minInclusive">-180</param> <param name="maxExclusive">180</param> </data> </attribute> <attribute name="minlat"> <data type="decimal"> <param name="minInclusive">-90</param> <param name="maxInclusive">90</param> </data> </attribute> </element> </optional> <optional> <element name="extensions"> <ref name="extensionsType"/> </element> </optional> </element> </optional> <zeroOrMore> <element name="wpt"> <ref name="wptType"/> </element> </zeroOrMore> <zeroOrMore> <element name="rte"> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="cmt"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="src"> <ref name="string"/> </element> </optional> <zeroOrMore> <element name="link"> <ref name="linkType"/> </element> </zeroOrMore> <optional> <element name="number"> <ref name="nonNegativeInteger"/> </element> </optional> <optional> <element name="type"> <ref name="string"/> </element> </optional> <optional> <element name="extensions"> <ref name="extensionsType"/> </element> </optional> <zeroOrMore> <element name="rtept"> <ref name="wptType"/> </element> </zeroOrMore> </element> </zeroOrMore> <zeroOrMore> <element name="trk"> <optional> <element name="name"> <ref name="string"/> </element> </optional> <optional> <element name="cmt"> <ref name="string"/> </element> </optional> <optional> <element name="desc"> <ref name="string"/> </element> </optional> <optional> <element name="src"> <ref name="string"/> </element> </optional> <zeroOrMore> <element name="link"> <ref name="linkType"/> </element> </zeroOrMore> <optional> <element name="number"> <ref name="nonNegativeInteger"/> </element> </optional> <optional> <element name="type"> <ref name="string"/> </element> </optional> <optional> <element name="extensions"> <ref name="extensionsType"/> </element> </optional> <zeroOrMore> <element name="trkseg"> <zeroOrMore> <element name="trkpt"> <ref name="wptType"/> </element> </zeroOrMore> <optional> <element name="extensions"> <ref name="extensionsType"/> </element> </optional> </element> </zeroOrMore> </element> </zeroOrMore> <optional> <element name="extensions"> <ref name="extensionsType"/> </element> </optional> </element> </choice> </start> <define name="anylaxother"> <element> <anyName> <except> <nsName ns=""/> <nsName/> </except> </anyName> <mixed> <zeroOrMore> <choice> <attribute> <anyName/> </attribute> <ref name="anylaxother"/> </choice> </zeroOrMore> </mixed> </element> </define> <define name="extensionsType"> <zeroOrMore> <ref name="anylaxother"/> </zeroOrMore> <empty/> </define> <define name="linkType"> <group> <attribute name="href"> <data type="anyURI"/> </attribute> <optional> <choice> <notAllowed/> <element name="text"> <ref name="string"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="type"> <ref name="string"/> </element> </choice> </optional> </group> <empty/> </define> <define name="nonNegativeInteger"> <data type="nonNegativeInteger"/> </define> <define name="wptType"> <group> <attribute name="lon"> <data type="decimal"> <param name="minInclusive">-180</param> <param name="maxExclusive">180</param> </data> </attribute> <attribute name="lat"> <data type="decimal"> <param name="minInclusive">-90</param> <param name="maxInclusive">90</param> </data> </attribute> <optional> <choice> <notAllowed/> <element name="ele"> <ref name="decimal"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="time"> <ref name="dateTime"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="magvar"> <data type="decimal"> <param name="minInclusive">0</param> <param name="maxExclusive">360</param> </data> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="geoidheight"> <ref name="decimal"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="name"> <ref name="string"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="cmt"> <ref name="string"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="desc"> <ref name="string"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="src"> <ref name="string"/> </element> </choice> </optional> <zeroOrMore> <choice> <notAllowed/> <element name="link"> <ref name="linkType"/> </element> </choice> </zeroOrMore> <optional> <choice> <notAllowed/> <element name="sym"> <ref name="string"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="type"> <ref name="string"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="fix"> <choice> <value type="string">3d</value> <value type="string">none</value> <value type="string">dgps</value> <value type="string">pps</value> <value type="string">2d</value> </choice> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="sat"> <ref name="nonNegativeInteger"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="hdop"> <ref name="decimal"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="vdop"> <ref name="decimal"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="pdop"> <ref name="decimal"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="ageofdgpsdata"> <ref name="decimal"/> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="dgpsid"> <data type="integer"> <param name="minInclusive">0</param> <param name="maxInclusive">1023</param> </data> </element> </choice> </optional> <optional> <choice> <notAllowed/> <element name="extensions"> <ref name="extensionsType"/> </element> </choice> </optional> </group> <empty/> </define> <define name="decimal"> <data type="decimal"/> </define> <define name="dateTime"> <data type="dateTime"/> </define> <define name="string"> <data type="string"/> </define> </grammar> ---------- namespace local = "" default namespace ns1 = "http://www.topografix.com/GPX/1/1" start = notAllowed | element gpx { attribute creator { xsd:string }, attribute version { xsd:string "1.1" }, element metadata { element name { \string }?, element desc { \string }?, element author { element name { \string }?, element email { attribute domain { xsd:string }, attribute id { xsd:string } }?, element link { linkType }? }?, element copyright { attribute author { xsd:string }, element year { xsd:gYear }?, element license { xsd:anyURI }? }?, element link { linkType }*, element time { dateTime }?, element keywords { \string }?, element bounds { attribute maxlon { xsd:decimal { minInclusive = "-180" maxExclusive = "180" } }, attribute maxlat { xsd:decimal { minInclusive = "-90" maxInclusive = "90" } }, attribute minlon { xsd:decimal { minInclusive = "-180" maxExclusive = "180" } }, attribute minlat { xsd:decimal { minInclusive = "-90" maxInclusive = "90" } } }?, element extensions { extensionsType }? }?, element wpt { wptType }*, element rte { element name { \string }?, element cmt { \string }?, element desc { \string }?, element src { \string }?, element link { linkType }*, element number { nonNegativeInteger }?, element type { \string }?, element extensions { extensionsType }?, element rtept { wptType }* }*, element trk { element name { \string }?, element cmt { \string }?, element desc { \string }?, element src { \string }?, element link { linkType }*, element number { nonNegativeInteger }?, element type { \string }?, element extensions { extensionsType }?, element trkseg { element trkpt { wptType }*, element extensions { extensionsType }? }* }*, element extensions { extensionsType }? } anylaxother = element * - (local:* | ns1:*) { mixed { (attribute * { text } | anylaxother)* } } extensionsType = anylaxother*, empty linkType = (attribute href { xsd:anyURI }, (notAllowed | element text { \string })?, (notAllowed | element type { \string })?), empty nonNegativeInteger = xsd:nonNegativeInteger wptType = (attribute lon { xsd:decimal { minInclusive = "-180" maxExclusive = "180" } }, attribute lat { xsd:decimal { minInclusive = "-90" maxInclusive = "90" } }, (notAllowed | element ele { decimal })?, (notAllowed | element time { dateTime })?, (notAllowed | element magvar { xsd:decimal { minInclusive = "0" maxExclusive = "360" } })?, (notAllowed | element geoidheight { decimal })?, (notAllowed | element name { \string })?, (notAllowed | element cmt { \string })?, (notAllowed | element desc { \string })?, (notAllowed | element src { \string })?, (notAllowed | element link { linkType })*, (notAllowed | element sym { \string })?, (notAllowed | element type { \string })?, (notAllowed | element fix { xsd:string "3d" | xsd:string "none" | xsd:string "dgps" | xsd:string "pps" | xsd:string "2d" })?, (notAllowed | element sat { nonNegativeInteger })?, (notAllowed | element hdop { decimal })?, (notAllowed | element vdop { decimal })?, (notAllowed | element pdop { decimal })?, (notAllowed | element ageofdgpsdata { decimal })?, (notAllowed | element dgpsid { xsd:integer { minInclusive = "0" maxInclusive = "1023" } })?, (notAllowed | element extensions { extensionsType })?), empty decimal = xsd:decimal dateTime = xsd:dateTime \string = xsd:string [Non-text portions of this message have been removed]
dananderson2+yahoo.com on Wed Mar 30 10:37:45 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > Thursday, March 17, 2005, 2:34:13 PM, dananderson2 wrote: > d> I'd like to see some additional functionality incorporated in the > d> GPX_Overlay. > > I would, too. > > All three of your suggestions would be good additions to > gpx_overlay. Care to propose a schema for them? See below for some suggestions. [snip] > On a related note (since we're discussing adding to gpx_overlay), > I'd like to allow <polyline> to have more than one set of > points, similar to the way that <trk> can contain multiple > <trkseg>s. [snip] I'm all in favor of symmetry between polylines and tracks. I see tracks as a special case of polylines that has timestamps. Polylines may or may not have elevation. Elevation might be useful for some polylines (a polyline of a stream with elevation could be presented as a profile for rafters, etc., a contour line ought to have one). For the anchor element there could be a choice between an image or a text label on the map. Or perhaps a "linkType" element could be added to LabelType. Dan A. Here are some ideas for GPX_Overlay: <xsd:element name="imageOverlay" type="imageOverlayType"> <xsd:annotation> <xsd:documentation> Image overlay (arrows, parking symbols, picnic tables, drawing that can't be done with existing elements) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="anchor" type="anchorType"> <xsd:annotation> <xsd:documentation> Image or text overlay on map linked to another object </xsd:documentation> </xsd:annotation> </xsd:element> <!-- image definition --> <xsd:complexType name="imageOverlayType"> <xsd:sequence> <xsd:element name="type" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation> Type of content (image/jpeg, image/gif, etc.) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="max_scale" minOccurs="0"> <xsd:annotation> <xsd:documentation> Max scale at which the image is displayed on the map </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="points" type="pointsType" minOccurs="0"> <xsd:annotation> <xsd:documentation> User-specified lat/lon positions for the image (center?, upper left?) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:attribute name="imgLink" type="xsd:anyURI" use="required"> <xsd:annotation> <xsd:documentation> URL of image location. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:sequence> </xsd:complexType> <!-- anchor definition --> <xsd:complexType name="anchorType"> <xsd:sequence> <xsd:element name="destType" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation> Type of content of the destination (image/jpeg, text/plain, text/html, video/mpeg, audio/mid, etc.) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="imageOverlay" type="imageOverlayType" minOccurs="0"> <xsd:annotation> <xsd:documentation> User-specified lat/lon position for the image (center?, upper left?) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:attribute name="href" type="xsd:anyURI" use="required"> <xsd:annotation> <xsd:documentation> URL of destination. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:sequence> </xsd:complexType>
dananderson2+yahoo.com on Wed Mar 30 11:11:26 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "dananderson2" <dananderson2+y...> wrote: > Here are some ideas for GPX_Overlay: > > <xsd:element name="imageOverlay" type="imageOverlayType"> > <xsd:annotation> > <xsd:documentation> > Image overlay (arrows, parking symbols, picnic tables, > drawing that can't be done with existing elements) > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > <xsd:element name="anchor" type="anchorType"> > <xsd:annotation> > <xsd:documentation> > Image or text overlay on map linked to another object > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > > <!-- image definition --> > <xsd:complexType name="imageOverlayType"> > <xsd:sequence> > <xsd:element name="type" type="xsd:string" minOccurs="0"> > <xsd:annotation> > <xsd:documentation> > Type of content (image/jpeg, image/gif, etc.) > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > <xsd:element ref="max_scale" minOccurs="0"> > <xsd:annotation> > <xsd:documentation> > Max scale at which the image is displayed on the map > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > <xsd:element name="points" type="pointsType" minOccurs="0"> > <xsd:annotation> > <xsd:documentation> > User-specified lat/lon positions for the image (center?, > upper left?) > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > <xsd:attribute name="imgLink" type="xsd:anyURI" use="required"> > <xsd:annotation> > <xsd:documentation> > URL of image location. > </xsd:documentation> > </xsd:annotation> > </xsd:attribute> > > </xsd:sequence> > </xsd:complexType> > > > <!-- anchor definition --> > <xsd:complexType name="anchorType"> > <xsd:sequence> > <xsd:element name="destType" type="xsd:string" minOccurs="0"> > <xsd:annotation> > <xsd:documentation> > Type of content of the destination (image/jpeg, > text/plain, text/html, video/mpeg, audio/mid, etc.) > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > <xsd:element name="imageOverlay" type="imageOverlayType" > minOccurs="0"> > <xsd:annotation> > <xsd:documentation> > User-specified lat/lon position for the image (center?, > upper left?) > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > <xsd:attribute name="href" type="xsd:anyURI" use="required"> > <xsd:annotation> > <xsd:documentation> > URL of destination. > </xsd:documentation> > </xsd:annotation> > </xsd:attribute> > > </xsd:sequence> > </xsd:complexType> Of course, just after posting this I think of something else - I don't really envision scaling the image so it can just shrink to "nothing". So max_scale should probably be removed. Dan A.
egroups+topografix.com on Wed Mar 30 11:11:36 2005 (link), replying to msg
Hello, Monday, February 23, 2004, 4:52:01 PM, I wrote: D> Has any other Windows developer out there implemented copy and paste D> in their applications? I've been using GPX for copy and paste and for D> drag and drop in EasyGPS for a while now. It would be great to be D> able to copy a waypoint in EasyGPS and paste it directly into another D> GPX-enabled program. I'm still wondering if anyone else has implemented copy/paste in their GPX-enabled software. My programs currently put GPX data on the clipboard as CF_TEXT/CF_UNICODE_TEXT. I'm now switching to ::RegisterClipboardFormat("GPX") If anyone else implements this and wants to do some interchange testing, please contact me off-list. -- Dan Foster
rgniqtbfoaq+yahoo.com on Wed Mar 30 23:37:30 2005 (link)
Your computer is at risk; protect your credit card, and personal info. download this free software. http://www.spyware-list.info/?aid=506 http://www.spyware-list.info/discon
kkfnqzclxn+yahoo.com on Thu Mar 31 10:03:34 2005 (link)
Your computer is at risk; protect your credit card, and personal info. download this free software. http://www.spyware-list.info/?aid=506 http://www.spyware-list.info/discon
davewissenbach+yahoo.com on Tue Apr 05 20:51:29 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "dananderson2" <dananderson2+y...> wrote: > > --- In gpsxml+yahoogroups.com, "dananderson2" <dananderson2+y...> wrote: > > > Here are some ideas for GPX_Overlay: > > > > <xsd:element name="imageOverlay" type="imageOverlayType"> > > <xsd:annotation> > > <xsd:documentation> > > Image overlay (arrows, parking symbols, picnic tables, > > drawing that can't be done with existing elements) > > </xsd:documentation> > > </xsd:annotation> > > </xsd:element> > > > > <xsd:element name="anchor" type="anchorType"> > > <xsd:annotation> > > <xsd:documentation> > > Image or text overlay on map linked to another object > > </xsd:documentation> > > </xsd:annotation> > > </xsd:element> > > > > > > <!-- image definition --> > > <xsd:complexType name="imageOverlayType"> > > <xsd:sequence> > > <xsd:element name="type" type="xsd:string" minOccurs="0"> > > <xsd:annotation> > > <xsd:documentation> > > Type of content (image/jpeg, image/gif, etc.) > > </xsd:documentation> > > </xsd:annotation> > > </xsd:element> > > > > <xsd:element ref="max_scale" minOccurs="0"> > > <xsd:annotation> > > <xsd:documentation> > > Max scale at which the image is displayed on the map > > </xsd:documentation> > > </xsd:annotation> > > </xsd:element> > > > > <xsd:element name="points" type="pointsType" minOccurs="0"> > > <xsd:annotation> > > <xsd:documentation> > > User-specified lat/lon positions for the image (center?, > > upper left?) > > </xsd:documentation> > > </xsd:annotation> > > </xsd:element> > > > > <xsd:attribute name="imgLink" type="xsd:anyURI" use="required"> > > <xsd:annotation> > > <xsd:documentation> > > URL of image location. > > </xsd:documentation> > > </xsd:annotation> > > </xsd:attribute> > > > > </xsd:sequence> > > </xsd:complexType> > > > > > > <!-- anchor definition --> > > <xsd:complexType name="anchorType"> > > <xsd:sequence> > > <xsd:element name="destType" type="xsd:string" minOccurs="0"> > > <xsd:annotation> > > <xsd:documentation> > > Type of content of the destination (image/jpeg, > > text/plain, text/html, video/mpeg, audio/mid, etc.) > > </xsd:documentation> > > </xsd:annotation> > > </xsd:element> > > > > <xsd:element name="imageOverlay" type="imageOverlayType" > > minOccurs="0"> > > <xsd:annotation> > > <xsd:documentation> > > User-specified lat/lon position for the image (center?, > > upper left?) > > </xsd:documentation> > > </xsd:annotation> > > </xsd:element> > > > > <xsd:attribute name="href" type="xsd:anyURI" use="required"> > > <xsd:annotation> > > <xsd:documentation> > > URL of destination. > > </xsd:documentation> > > </xsd:annotation> > > </xsd:attribute> > > > > </xsd:sequence> > > </xsd:complexType> > > Of course, just after posting this I think of something > else - I don't really envision scaling the image so it > can just shrink to "nothing". So max_scale should probably > be removed. > > Dan A. I think that a lot of these concepts could be expressed in a container element similar to waypoint, perhaps called a point of interest, or poi. I especially like the idea of images and links just being one click away. I've implemented a simple version of this concept for waypoints in GPS Trail Mapper (unreleased software) by highlighting a waypoint symbol with a blue square (or could be a yellow arrow as in your examples) but only when the link tool is enabled. (When the link tool is enabled clicking on a link opens.) But I'd also like to refine and definitely implement your ideas for allowing images to be scaled and placed at arbitrary locations. These comments are not substantive, but I just wanted to offer encouragement and interest and promise to revisit this discussion within the next few months. Dave Wissenbach
dananderson2+yahoo.com on Wed Apr 06 09:20:15 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "David S. Wissenbach" <davewissenbach+y...> wrote: [snip] > I think that a lot of these concepts could be expressed in a > container element similar to waypoint, perhaps called a > point of interest, or poi. I especially like the idea of images and > links just being one click away. I've implemented a simple version > of this concept for waypoints in GPS Trail Mapper (unreleased > software) by highlighting a waypoint symbol with a blue square (or > could be a yellow arrow as in your examples) but only when the link > tool is enabled. (When the link tool is enabled clicking on a link > opens.) The yellow arrows in the examples are just image overlays. In this case they aren't intended to be a link to anything but are just "tic" marks to indicate what part of the trail the mileage is for. "AAA" state road maps use a diamond shaped arrow for this purpose. Example: <imageOverlay imgLink="./images/South_Arrow.gif"> <points> <pt lat="12.345" lon="56.789"/> <pt lat="21.345" lon="34.789"/> <pt lat="13.345" lon="28.789"/> <pt lat="23.345" lon="17.789"/> </points) </imageOverlay> <imageOverlay imgLink="./images/NE_Arrow.gif"> <points> <pt lat="21.123" lon="34.543"/> <pt lat="13.123" lon="28.543"/> <pt lat="23.123" lon="17.543"/> </points) </imageOverlay> > But I'd also like to refine and definitely implement your ideas for > allowing images to be scaled and placed at arbitrary locations. > > These comments are not substantive, but I just wanted to offer > encouragement and interest and promise to revisit this discussion > within the next few months. Thanks. I hope we can get somewhere in less than a few months. Dan A.
jkzsyifzoge+yahoo.com on Tue Apr 12 09:07:54 2005 (link)
I refinanced my home loan at an incredible interest rate; this saved me 500.00 this month alone. This free service can help. http://goodloane.biz/?affiliate=rcc1 take 30 seconds and fill out this free form
rwmech+keenpeople.com on Fri Apr 22 05:51:46 2005 (link), replying to msg
www.travelertags.com uses cut and paste of the GPX XML for logging of where tags/caches are located. It uses JavaScript to parse the XML and populate into form fields for submission. -----Original Message----- From: Dan Foster [mailto:egroups+topografix.com] Sent: Wednesday, March 30, 2005 1:13 PM To: Dan Foster Subject: Re: [gpsxml] Copy/Paste GPX to clipboard in Windows programs Hello, Monday, February 23, 2004, 4:52:01 PM, I wrote: D> Has any other Windows developer out there implemented copy and paste D> in their applications? I've been using GPX for copy and paste and for D> drag and drop in EasyGPS for a while now. It would be great to be D> able to copy a waypoint in EasyGPS and paste it directly into another D> GPX-enabled program. I'm still wondering if anyone else has implemented copy/paste in their GPX-enabled software. My programs currently put GPX data on the clipboard as CF_TEXT/CF_UNICODE_TEXT. I'm now switching to ::RegisterClipboardFormat("GPX") If anyone else implements this and wants to do some interchange testing, please contact me off-list. -- Dan Foster Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=129clbeq7/M=298184.6018725.7038619.3001176/ D=groups/S=1706030390:HM/EXP=1112296296/A=2593423/R=0/SIG=11el9gslf/*htt p://www.netflix.com/Default?mqso=60190075> click here <http://us.adserver.yahoo.com/l?M=298184.6018725.7038619.3001176/D=group s/S=:HM/A=2593423/rand=576141554> _____ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/gpsxml/ * To unsubscribe from this group, send an email to: gpsxml-unsubscribe+yahoogroups.com <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]
robertlipe+usa.net on Fri Apr 22 07:36:23 2005 (link), replying to msg
Brian Lalor wrote: > I know the GPX 1.1 schema is pretty straight-forward, but I'm wondering > if anyone's got a MySQL database schema they'd like to share? I don't know what MySQL offers that makes it special here, but at first blush, that seems kind of wierd. Use GPX (which as you observe, is a pretty straightforward XML) to get it into your database. From there, you're free to manipulate it as you like. Why would you want to restate GPX based on the destination consumer? RJL
cool_ghost+hotmail.com on Mon May 09 00:09:18 2005 (link)
Hey! Has anyone bumped in to conversion tools from shp/gml or other to gpx? I have a lot of data in those before mentioned formats and I'm in a dire need to have them converted. Thanks, Kasper
robertlipe+usa.net on Mon May 09 06:36:51 2005 (link), replying to msg
naughty_coolghost wrote: > Has anyone bumped in to conversion tools from shp/gml or other to gpx? GPSBabel has a crude shp reader. It requires source modification to tell it what shp fields map to the target modification. It's really usable only by programmers for custom tasks - that's why it's not in the doc. But if you have a stack of data to convert, it may be worth pursuing since it's very automatable and well suited to bulk conversions. It doesn't have GML, but that could be implemented. A lot depends on how wild and crazy your GML is. GML is more expressive than GPX, so if youre data takes advantage of that expressiveness, we'd need to define the mappings between GML tags and GPX tags. > I have a lot of data in those before mentioned formats and I'm in a > dire need to have them converted. I do custom conversion work on a consulting basis... RJL
murphy+enterprise.net on Tue May 10 06:43:36 2005 (link), replying to msg
For shp to gpx conversion I can offer you "GPS Utility" - see www.gpsu.co.uk. Please not though that the Freeware version is limited in capacity, but it should work with small datasets. If you have a problem or a special need which is not supported, then please email me direct. Alan Murphy (author GPSU) On 9 May 2005 09:16:02 -0000, you wrote: > Date: Mon, 09 May 2005 07:07:58 -0000 > From: "naughty_coolghost" <cool_ghost+hotmail.com> >Subject: Conversion to GPX > >Hey! > >Has anyone bumped in to conversion tools from shp/gml or other to gpx? >I have a lot of data in those before mentioned formats and I'm in a >dire need to have them converted. > >Thanks, > >Kasper >
azbithead+gmail.com on Thu May 12 15:51:26 2005 (link)
This is just a heads up to the forum to let you know that version 6.6 of Garmin's MapSource application is in a public beta test period now. This version of MapSource now outputs GPX with MapSource-specific extensions. These extensions include MapSource data that does not fit well into the available elements of GPX version 1.1. If you are interested in testing this beta version of MapSource go to http://www.garmin.com/support/download_details.jsp?id=877. Note that you must already own a previous version of MapSource in order to install and test the beta version. If you are interested in the MapSource-specific extensions to GPX 1.1, the schema is available at http://www.garmin.com/xmlschemas/GpxExtensions/v1/GpxExtensionsv1.xsd. Thanks, Steve
azbithead+gmail.com on Thu May 12 15:54:37 2005 (link), replying to msg
The forum software did not do a good job of making the URLs in my previous post clickable. So here are the URLs again. The beta software is here: http://www.garmin.com/support/download_details.jsp?id=877 The schema is here: http://www.garmin.com/xmlschemas/GpxExtensions/v1/GpxExtensionsv1.xsd Thanks, Steve
egroups+topografix.com on Fri May 13 06:21:31 2005 (link), replying to msg
Hello, Thursday, May 12, 2005, 6:51:23 PM, Steve wrote: a> This version of MapSource now outputs GPX with MapSource-specific a> extensions. It's great to see that Garmin is committed to supporting GPX transfer, and that you're extending it to allow for richer data interchange. I'll begin adding support for depth and some of your other extensions to my programs. I found one validation error - if I export a waypoint with categories, SAXCount complains about the <category> tag. If I edit the file and replace with <gpxx:category> like the rest of your extensions, it validates. -- Dan Foster
azbithead+gmail.com on Fri May 13 08:54:46 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > I found one validation error - if I export a waypoint with categories, > SAXCount complains about the <category> tag. If I edit the file and > replace with <gpxx:category> like the rest of your extensions, it > validates. Thanks, Dan, we are aware of this issue. It will be fixed in the next beta, if we have one, or in the final release. Thanks, Steve
egroups+topografix.com on Wed May 18 12:02:51 2005 (link), replying to msg
Hello, Thursday, May 12, 2005, 6:51:23 PM, Steve wrote: a> This is just a heads up to the forum to let you know that version 6.6 a> of Garmin's MapSource application is in a public beta test period now. a> This version of MapSource now outputs GPX with MapSource-specific a> extensions. These extensions include MapSource data that does not fit a> well into the available elements of GPX version 1.1. Would it be possible to make DisplayMode and Categories in WaypointExtension optional elements (minOccurs="0") like the other elements? I'm trying to pass depth data [only] to MapSource, but the file doesn't validate without DisplayMode and Categories. It might make sense to make IsAutoNamed in RouteExtension optional, just in case you ever add additional elements there. -- Dan Foster
azbithead+gmail.com on Fri May 20 16:02:39 2005 (link), replying to msg
We have posted a new beta of MapSource and a new version of our extensions to GPX 1.1. The new beta can be found at: http://www.garmin.com/support/download_details.jsp?id=878 The new schema can be found at: http://www.garmin.com/xmlschemas/GpxExtensions/v2/GpxExtensionsv2.xsd Please note that the v1 schema is now obsolete. It has been removed from the Internet. The new beta and future versions of MapSource will not support it. Thanks, Steve --- In gpsxml+yahoogroups.com, "azbithead" <azbithead+g...> wrote: > This is just a heads up to the forum to let you know that version 6.6 > of Garmin's MapSource application is in a public beta test period now. > This version of MapSource now outputs GPX with MapSource-specific > extensions. These extensions include MapSource data that does not fit > well into the available elements of GPX version 1.1. If you are > interested in testing this beta version of MapSource go to > http://www.garmin.com/support/download_details.jsp?id=877. Note that > you must already own a previous version of MapSource in order to > install and test the beta version. If you are interested in the > MapSource-specific extensions to GPX 1.1, the schema is available at > http://www.garmin.com/xmlschemas/GpxExtensions/v 1/GpxExtensionsv1.xsd. > > Thanks, > Steve
feedback+gpxchange.com on Tue May 31 22:02:03 2005 (link)
Lots of changes made recently, but a fun one is the addition of KML files for account holders who wish to do the conversion. Just upload your own GPX and then use the Build KML File button to produce a formatted overlay for use with Keyhole/Google Earth.
gsmbargain5000+yahoo.com on Sat Jun 04 07:34:01 2005 (link)
LATEST PDA/MOBILE PHONES STOCKS We are certified wholesalers of various Mobile Phones at very good prices. Attached please kindly find the latest full Price-List our New Tri-Band GSM Phones for your reference. Please dont hesitate to inform us if you are interested in our products. Any of your suggestions and specific enquiries will receive our prompt attention. Brand New Tri - band GSM Phones Nokia 1100......25 USD Nokia 2300......20 USD Nokia 2650......30 USD Nokia 3100......30 USD Nokia 3108......30 USD Nokia 3120......30 USD Nokia 3200......40 USD Nokia 3220......60 USD Nokia 3300......60 USD Nokia 3660......70 USD Nokia 5100......60 USD Nokia 5140......70 USD Nokia 6100......50 USD Nokia 6108......60 USD Nokia 6220......70 USD Nokia 6230......90 USD Nokia 6260......120 USD Nokia 6600......100 USD Nokia 6630......90 USD Nokia 6610......70 USD Nokia 6610i.....90 USD Nokia 6650......120 USD Nokia 6670 Smartphone...160 USD Nokia 6820......70 USD Nokia 7200......80 USD Nokia 7210......60 USD Nokia 3230......240 USD Nokia 7610......120 USD Nokia 9300......320 USD Nokia 7250......70 USD Nokia 7250i.....75 USD Nokia 7260......160 USD Nokia 7600......90 USD Nokia 7610......120 USD Nokia 8910i.....140 USD Nokia 8910i.....140 USD Nokia 9210i Communicator..360 USD Nokia 9500 Communicator..460 USD Nokia 9300 Communicator..400 USD Nokia N-Gage....180 USD Nokia N-gage QD.200 USD Panasonic A100...50 USD Panasonic G50...80 USD Panasonic G51M..80 USD Panasonic G70...100 USD Panasonic GD55..60 USD Panasonic GD88..170 USD Panasonic X11...180 USD Panasonic X300..170 USD Panasonic X500..170 USD Panasonic X66...110 USD Panasonic x70...140 USD Panasonic X77...140 USD Panasonic X88...170 USD Samsung E600...140 USD Samsung E800...180 USD Samsung P510...120 USD Samsung SGH-D410.170 USD Samsung SGH-E700..150 USD Samsung SGH-E715..170 USD Samsung SGH-P100..130 USD Samsung SGH-P400..95 USD Samsung SGH-P408..240 USD Samsung SGH-P730..150 USD Samsung SGH-S200..90 USD Samsung SGH-S300..70 USD Samsung SGH-S300M..100 USD Samsung SGH-S500...100 USD Samsung SGH-V200...110 USD Samsung SGH-X400...100 USD Samsung SGH-X430...100 USD Samsung SGH-X600...100 USD Samsung X450.......100 USD Siemens A60.....80 USD Siemens C62.....60 USD Siemens CF62....90 USD Siemens CX65....110 USD Siemens M55.....90 USD Siemens MC60....90 USD Siemens S65 w/ Bluetooth..200 USD Siemens SL55....90 USD Siemens ST-60...170 uSD Siemens SX-1....50 USD Siemens Xelibri 1..60 USD Siemens Xelibri 2..60 USD Siemens Xelibri 3..80 USD Siemens Xelibri 4..60 USD Siemens Xelibri 5..100 USD Siemens Xelibri 6..140 USD Siemens Xelibri 7..140 USD Siemens Xelibri 8..200 USD Siements M65.......200 USD Sony Ericsson K500i.....130 USD Sony Ericsson P800......260 USD Sony Ericsson P900......400 USD Sony Ericsson P910i.....500 USD Sony Ericsson T230......80 USD Sony Ericsson T310......80 USD Sony Ericsson T610......100 USD Sony Ericsson Z1010.....340 USD Sony Ericsson Z200......90 USD Sony Ericsson Z600......130 USD Sony Ericssson T630.....130 USD Sony Ericsson S700i.....350 USD Motorola A388C......230 USD Motorola A760.......250 USD Motorola A768.......370 USD Motorola A768i......300 USD Motorola A780.......600 USD Motorola C550.......90 USD Motorola C650.......100 USD Motorola E365.......100 USD Motorola E398.......120 USD Motorola E680.......340 USD Motorola RAZR V3....500 USD Motorola V220.......170 USD Motorola V303.......100 USD Motorola V400.......150 USD Motorola V500.......150 USD Motorola V501.......200 USD Motorola V525.......150 USD Motorola V600 (OEM) w/ Bluetooth Headset..260 USD Motorola V600 OEM...200 USD Motorola V690.....170 USD Motorola V750.....180 USD Motorola V80......200 USD Motorola V80 with Bluetooth...260 USD Motorola V872.....200 USD Motorola V878....180 USD Motorola V300....150 USD PDA's HP IPaq Pocket PC H4150 ========= $190 Asus MyPal A716 ================= $175 HP IPaq Pocket PC H4350 ========= $185 Toshiba Pocket PC E405 ========== $120 Sony Clie PEG-TH55 ============== $155 Toshiba Pocket PC E800 ========== $220 PalmOne Zire 72================== $120 PalmOne Tungsten E ============== $90 PalmOne Tungsten C ============== $140 PalmOne Zire 31 ================= $65 We give discount for large purchases, and our products are guaranteed brand new, with complete accessories and warranty. Please feel free to contact us with your Quotation and Location EMAIL - optimalbargain+yahoo.com Thanks ===== Mark Cole (CEO) Wide Associates Ltd 30 Solomon Lar Close , Ikeja - Lagos . Nigeria Tel - +2348034855515, +2348055308737 http://www.wideassociates.com NOTE ALL CORRESPONDENT MUST BE THROUGH THIS EMAIL EMAIL - OPTIMALBARGAIN+YAHOO.COM
gsmbargain5000+yahoo.com on Sat Jun 04 07:34:05 2005 (link)
LATEST PDA/MOBILE PHONES STOCKS We are certified wholesalers of various Mobile Phones at very good prices. Attached please kindly find the latest full Price-List our New Tri-Band GSM Phones for your reference. Please dont hesitate to inform us if you are interested in our products. Any of your suggestions and specific enquiries will receive our prompt attention. Brand New Tri - band GSM Phones Nokia 1100......25 USD Nokia 2300......20 USD Nokia 2650......30 USD Nokia 3100......30 USD Nokia 3108......30 USD Nokia 3120......30 USD Nokia 3200......40 USD Nokia 3220......60 USD Nokia 3300......60 USD Nokia 3660......70 USD Nokia 5100......60 USD Nokia 5140......70 USD Nokia 6100......50 USD Nokia 6108......60 USD Nokia 6220......70 USD Nokia 6230......90 USD Nokia 6260......120 USD Nokia 6600......100 USD Nokia 6630......90 USD Nokia 6610......70 USD Nokia 6610i.....90 USD Nokia 6650......120 USD Nokia 6670 Smartphone...160 USD Nokia 6820......70 USD Nokia 7200......80 USD Nokia 7210......60 USD Nokia 3230......240 USD Nokia 7610......120 USD Nokia 9300......320 USD Nokia 7250......70 USD Nokia 7250i.....75 USD Nokia 7260......160 USD Nokia 7600......90 USD Nokia 7610......120 USD Nokia 8910i.....140 USD Nokia 8910i.....140 USD Nokia 9210i Communicator..360 USD Nokia 9500 Communicator..460 USD Nokia 9300 Communicator..400 USD Nokia N-Gage....180 USD Nokia N-gage QD.200 USD Panasonic A100...50 USD Panasonic G50...80 USD Panasonic G51M..80 USD Panasonic G70...100 USD Panasonic GD55..60 USD Panasonic GD88..170 USD Panasonic X11...180 USD Panasonic X300..170 USD Panasonic X500..170 USD Panasonic X66...110 USD Panasonic x70...140 USD Panasonic X77...140 USD Panasonic X88...170 USD Samsung E600...140 USD Samsung E800...180 USD Samsung P510...120 USD Samsung SGH-D410.170 USD Samsung SGH-E700..150 USD Samsung SGH-E715..170 USD Samsung SGH-P100..130 USD Samsung SGH-P400..95 USD Samsung SGH-P408..240 USD Samsung SGH-P730..150 USD Samsung SGH-S200..90 USD Samsung SGH-S300..70 USD Samsung SGH-S300M..100 USD Samsung SGH-S500...100 USD Samsung SGH-V200...110 USD Samsung SGH-X400...100 USD Samsung SGH-X430...100 USD Samsung SGH-X600...100 USD Samsung X450.......100 USD Siemens A60.....80 USD Siemens C62.....60 USD Siemens CF62....90 USD Siemens CX65....110 USD Siemens M55.....90 USD Siemens MC60....90 USD Siemens S65 w/ Bluetooth..200 USD Siemens SL55....90 USD Siemens ST-60...170 uSD Siemens SX-1....50 USD Siemens Xelibri 1..60 USD Siemens Xelibri 2..60 USD Siemens Xelibri 3..80 USD Siemens Xelibri 4..60 USD Siemens Xelibri 5..100 USD Siemens Xelibri 6..140 USD Siemens Xelibri 7..140 USD Siemens Xelibri 8..200 USD Siements M65.......200 USD Sony Ericsson K500i.....130 USD Sony Ericsson P800......260 USD Sony Ericsson P900......400 USD Sony Ericsson P910i.....500 USD Sony Ericsson T230......80 USD Sony Ericsson T310......80 USD Sony Ericsson T610......100 USD Sony Ericsson Z1010.....340 USD Sony Ericsson Z200......90 USD Sony Ericsson Z600......130 USD Sony Ericssson T630.....130 USD Sony Ericsson S700i.....350 USD Motorola A388C......230 USD Motorola A760.......250 USD Motorola A768.......370 USD Motorola A768i......300 USD Motorola A780.......600 USD Motorola C550.......90 USD Motorola C650.......100 USD Motorola E365.......100 USD Motorola E398.......120 USD Motorola E680.......340 USD Motorola RAZR V3....500 USD Motorola V220.......170 USD Motorola V303.......100 USD Motorola V400.......150 USD Motorola V500.......150 USD Motorola V501.......200 USD Motorola V525.......150 USD Motorola V600 (OEM) w/ Bluetooth Headset..260 USD Motorola V600 OEM...200 USD Motorola V690.....170 USD Motorola V750.....180 USD Motorola V80......200 USD Motorola V80 with Bluetooth...260 USD Motorola V872.....200 USD Motorola V878....180 USD Motorola V300....150 USD PDA's HP IPaq Pocket PC H4150 ========= $190 Asus MyPal A716 ================= $175 HP IPaq Pocket PC H4350 ========= $185 Toshiba Pocket PC E405 ========== $120 Sony Clie PEG-TH55 ============== $155 Toshiba Pocket PC E800 ========== $220 PalmOne Zire 72================== $120 PalmOne Tungsten E ============== $90 PalmOne Tungsten C ============== $140 PalmOne Zire 31 ================= $65 We give discount for large purchases, and our products are guaranteed brand new, with complete accessories and warranty. Please feel free to contact us with your Quotation and Location EMAIL - optimalbargain+yahoo.com Thanks ===== Mark Cole (CEO) Wide Associates Ltd 30 Solomon Lar Close , Ikeja - Lagos . Nigeria Tel - +2348034855515, +2348055308737 http://www.wideassociates.com NOTE ALL CORRESPONDENT MUST BE THROUGH THIS EMAIL EMAIL - OPTIMALBARGAIN+YAHOO.COM
zqdbpojjmu+yahoo.com on Fri Jun 17 16:20:19 2005 (link)
I save hundreds of dollars a month because I refinanced my home loan for nearly half the interest rate. Here is a free service that can help. http://tpbaj.com/i/LzQvaW5kZXgvd2F6ZWUvMnVnYnNuaWJwbHdvZGRtcTl5OW9w take 30 seconds and fill out this free form
ninamub7hl+yahoo.com on Fri Jun 17 21:59:52 2005 (link)
Bored? Want to meet someone new? Chat with Real Women in YOUR AREA Just Call 1-800-335-9396 Only $0.99 a min with a major credit card. NO CONNECT FEES! No credit card? No problem! Just call 1-206-576-1797 Only $0.99 a min with a $4.99 connect fee. Billed discreetly as a collect call on your phone bill.
ninamub7hl+yahoo.com on Fri Jun 17 22:00:57 2005 (link)
Hey I just wanted to tell you about a great company I found! I applyed for a lower mortgage rate and i only had to fill in a simple form. This month alone I saved $500 dollars! check out their site http://www.greatrefi.com/?a=candi I hope it helps you as much as it did for me!
comosicus+hotmail.com on Sat Jun 25 09:19:15 2005 (link), replying to msg
S P A M!!! --- In gpsxml+yahoogroups.com, "ninamub7hl" <ninamub7hl+y...> wrote: > Hey I just wanted to tell you about a great company I found! > I applyed for a lower mortgage rate and i only had to > fill in a simple form. This month alone I saved $500 dollars! > check out their site http://www.greatrefi.com/?a=candi > I hope it helps you as much as it did for me!
gps_maps+travelbygps.com on Sun Jun 26 04:04:21 2005 (link)
Would someone be so kind as to have a look at this file and tell me why WissenbachMaps will open it but ExpertGPS won't. http://www.travelbygps.com/guides/BC/AlpineMeadowsTrail.gpx Thanks - Doug
robertlipe+usa.net on Sun Jun 26 10:18:40 2005 (link), replying to msg
Doug Adomatis wrote: > Would someone be so kind as to have a look at this file and tell me > why WissenbachMaps will open it but ExpertGPS won't. > > http://www.travelbygps.com/guides/BC/AlpineMeadowsTrail.gpx My guess is that ExpertGPS is rejecting the file because of the illegal dates. Feed it to SAX2Count and you'll see dozens of errors of the form: $ SAX2Count AlpineMeadowsTrail.gpx Error at file /tmp/AlpineMeadowsTrail.gpx, line 8, char 32 Message: Datatype error: Type:InvalidDatatypeValueException, Message:Value '2:51:14 PM' is not in enumeration . It's writing times like <time>2:51:14 PM</time> which isn't a legal GPX date format. If you use GPSBabel to read the file and write it back to GPX, you'll get legal GPX, but your dates will still be doodoo. gpsbabel -i gpx -f AlpineMeadowsTrail.gpx -o gpx -F FixedAlpine.gpx SAX2Count FixedAlpine.gpx /tmp/A.gpx: 366 ms (215 elems, 143 attrs, 429 spaces, 2175 chars) Note that your dates now look like: <time>1969-12-31T17:59:59Z</time> Since there was no year, GPSBabel defaulted to 1-1-1970 and then subtracted out the current timezone. It looks like this file was created by http://www.gpsvisualizer.com/ so you may want to work this with the author of that program. RJL
gps_maps+travelbygps.com on Mon Jun 27 04:02:10 2005 (link), replying to msg
Robert wrote: > It's writing times like > <time>2:51:14 PM</time> > which isn't a legal GPX date format. > > If you use GPSBabel to read the file and write it back to GPX, you'll get legal GPX, but your dates will still be doodoo. My reply in rap lyrics: I did what you said and got doodoo dates, but was easy to fix with find-and-replace. Once again, thanks Robert. - Doug www.TravelByGPS.com Travel by GPS (tm) Maps Waypoints and Tracks to Adventure
robertlipe+usa.net on Mon Jun 27 10:01:49 2005 (link), replying to msg
> > It's writing times like > > <time>2:51:14 PM</time> > > which isn't a legal GPX date format. > > > > If you use GPSBabel to read the file and write it back to GPX, > you'll get legal GPX, but your dates will still be doodoo. > > My reply in rap lyrics: > > I did what you said > and got doodoo dates, > but was easy to fix > with find-and-replace. Cute. If your search and replace mojo is strong enough, you could have done it without GPSBabel's help. It was just a convenient way to normalize the timezones to GMT. Of course, without a stated timezone and without a date, that's pretty hokey anyway. I also realized I'd been talking to the author of GPSVisualizer about other things in recent days and brought this up with him. He knows this feature in his GPX writer is toast and he's working on it. Enjoy. RJL
robertlipe+usa.net on Tue Jun 28 19:11:57 2005 (link)
I think I just programmed myself into a corner. I'm working with another developer on a module for GPSBabel that happens to strongly desire the DOP brothers plus speed and course. I've long posited that speed and course are kind of silly, but I remembered reading that GPX supported those things, so I decided to roll over and add them to my internal data structures and GPX handlers on the grounds that if two formats could express it, someone must consider them non-silly. The doc is pretty clear on how they work: http://www.topografix.com/gpx_manual.asp So I blasted the code in and, like all good GPX developers, went to validate my output. No dice becuase <speed> and <course> aren't in the GPX 1.0 XSD and I write GPX 1.0 by default. OK, no big deal, it must be a new GPX 1.1 thing, so I conditionalized it to my GPX 1.1 output. Still no dice because they aren't in the 1.1 XSD either. Was it our plan to support these in GPX? Did we change our minds or am I just overlooking them? RJL
egroups+topografix.com on Wed Jun 29 07:22:39 2005 (link), replying to msg
Hello, Tuesday, June 28, 2005, 5:37:10 PM, Robert wrote: R> So I blasted the code in and, like all good GPX developers, went to R> validate my output. No dice becuase <speed> and <course> aren't in the R> GPX 1.0 XSD and I write GPX 1.0 by default. OK, no big deal, it must R> be a new GPX 1.1 thing, so I conditionalized it to my GPX 1.1 output. R> Still no dice because they aren't in the 1.1 XSD either. They are in 1.0. I removed them (by mistake) from 1.1. Since we can't change 1.1 to add them in, perhaps they should be rolled into an extension schema with other NMEA-derived values. http://www.topografix.com/gpx/1/0/gpx.xsd trkpt: <xsd:element name="ele" type="xsd:decimal" minOccurs="0" /> <xsd:element name="time" type="xsd:dateTime" minOccurs="0" /> <xsd:element name="course" type="gpx:degreesType" minOccurs="0" /> <xsd:element name="speed" type="xsd:decimal" minOccurs="0" /> -- Dan Foster
robertlipe+usa.net on Wed Jun 29 09:49:05 2005 (link), replying to msg
Thanx for the answer, Dan. > R> validate my output. No dice becuase <speed> and <course> aren't in the > R> GPX 1.0 XSD and I write GPX 1.0 by default. OK, no big deal, it must > > They are in 1.0. I removed them (by mistake) from 1.1. Since we can't (Ding.) Embarrassingly, I was overlooking them. Apparently the 'search in document' feature in Firefox is goofy on .xsd's. These things are legal only in tracks while the test case I was working with was waypoints. SAX2Count was pretty clear that these weren't valid tags and I didn't see them in the xsd because of the FF issue. I changed my stuff to write these only for trackpts and that was my ticket back to validatedsville. Thanx! > change 1.1 to add them in, perhaps they should be rolled into an > extension schema with other NMEA-derived values. Let's not on my account. While it's a little wierd, I'm not unhappy with the status quo to rock that boat. (As I said, I always thought it was strange to store this anyway. :-) Thanx, RJL
gps_maps+travelbygps.com on Wed Jun 29 20:03:35 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > Lots of changes made recently, but a fun one is the addition of KML > files for account holders who wish to do the conversion. Just upload > your own GPX and then use the Build KML File button to produce a > formatted overlay for use with Keyhole/Google Earth. Compare to NASA's World Wind program to Google Earth. Google Earth appears to be a re-marketing of prior Keyhole product/service. The pro version is down to $400/yr. There is a free version but to import GPS data in KML format you have to pay at least the $20/yr fee. Compare to NASA's World Wind http://worldwind.arc.nasa.gov/ It's free and will import *and* export GPX data directly. All in all, good news for GPX proponents. - Doug www.TravelByGPS.com Where you will find many free GPX data files, waypoints and tracks, to adventure.
feedback+gpxchange.com on Wed Jun 29 22:02:42 2005 (link), replying to msg
The free version of Google Earth will display your GPX data just fine. Simply upload your GPX data to GPXchange.com and then click the "Build KML File" button to convert the GPX into a KML file. Next, download the KML file onto your local machine and launch it there. If the free version of Google Earth (or any other version) is installed on the same machine, double clicking the KML file will launch the app and load the overlay, with descriptive data etc. No need to pay the $20. Google Earth Plus allows you to import GPS data or GPX, however it renders tracks as a series of points instead of a polyline etc. Using GPXchange provides a much cleaner overlay and does a better job of listing the track and waypoint data. If you want to see how this works without uploading a file, simply go to GPXchange.com, navigate to the example (Yosemite Falls) and download its KML. Worldwind is interesting, but the free version of Google Earth will be widely used. All in all, very cool stuff. --- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+t...> wrote: > --- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > > Lots of changes made recently, but a fun one is the addition of KML > > files for account holders who wish to do the conversion. Just upload > > your own GPX and then use the Build KML File button to produce a > > formatted overlay for use with Keyhole/Google Earth. > > Compare to NASA's World Wind program to Google Earth. > Google Earth appears to be a re-marketing of prior Keyhole > product/service. The pro version is down to $400/yr. There is a free > version but to import GPS data in KML format you have to pay at least > the $20/yr fee. > > Compare to NASA's World Wind > http://worldwind.arc.nasa.gov/ > It's free and will import *and* export GPX data directly. > > All in all, good news for GPX proponents. > - Doug > www.TravelByGPS.com > Where you will find many free GPX data files, waypoints and tracks, > to adventure.
gps_maps+travelbygps.com on Thu Jun 30 03:24:38 2005 (link), replying to msg
--- "offroute2000" wrote: > The free version of Google Earth will display your GPX data just fine. In that case, I'm glad I'm wrong! Thanks for correcting me Fred. I was going by info on the Google web site that said you needed to $20/yr version to import GPS data. I assumed that data had to be in KML format. But you are saying that KML can be overlayed on the free version. I guess I'll be installing Google Earth today. Google is taking over the world. Many eyeballs indeed. - Doug www.TravelByGPS.com Where you will find many free, adventure related, GPX files you can overlay on World Wind *or* Google Earth.
robertlipe+usa.net on Thu Jun 30 06:13:35 2005 (link), replying to msg
offroute2000 wrote: > The free version of Google Earth will display your GPX data just fine. A free copy of GPSBabel goes to the first person that figures out _how_ Google Earth reads your GPX data and provides it to a program that speaks KML natively. Hint: it involves a tool that will also most likely talk to your GPS (and is so used by Google Earth), knows KML, fluently speaks GPX, and about a six dozen other formats. > Google Earth Plus allows you to import GPS data or GPX, however it > renders tracks as a series of points instead of a polyline etc. Using That isn't immutable. It's been proposed. It's known that tracks make more sense as an arc/polyline. > Worldwind is interesting, but the free version of Google Earth will be > widely used. All in all, very cool stuff. I concur. Google Earth - and the API to Google maps that was released - today puts world class mapping in the hands of many more users than were available to us just yesterday. This has been a whirlwind week for Google's mapping group. Signed, Writing a GPX->Google API Thingy in Another Window At This Very Moment.
robertlipe+usa.net on Thu Jun 30 11:22:47 2005 (link), replying to msg
Michael Collinson wrote: > 3) There is other popular information coming out of GPS devices relating > to such things as heart-rate. There appears to be a general but not total > consensus on this list that these COULD be in the spec, but is not a good > idea as it is hard to see a limit on what to put in and the current > simplicity would be lost. Right. The trend (hope?) has been to keep the core of GPX pretty focused on GPS and navigation-y things and put other things in their own namespaces where they can be maintained and supported independently. > My own view is that the spec should, as one of its primary objectives. > support the "NMEA 0183 $GPxxx wrapper" concept so that developers can There are several such sentences. I'm not sure that everything in GP* is a good fit for GPX. For example the GPGSA "list of satellites used" seems a pretty bad fit. > extensions, which limits portability. The most straight-forward way to do > this is to map NMEA scalar parameters to single GPX elements CDATA. Thus A 1:1 mapping for all sentences wouldn't be a good thing. Some of the sentences are incomplete (i.e. absence of a data in a time) or overlapping. Is there something (the absence of course and speed duly noted, but as we've observed, it can be recomputed if you need it badly enough) that NMEA can represent that's missing from GPX? RJL
radu.sora+giscover.com on Thu Jun 30 12:32:38 2005 (link), replying to msg
You can also upload GPX tracks on this free portal: www.giscover.com. Then you can download them in many formats, like GPX, KML (Google Earth), PLT (Ozi & CompeGPS), Fugawi... Hope you like it. Radu Doug Adomatis wrote: > --- "offroute2000" wrote: > > The free version of Google Earth will display your GPX data just > fine. > > In that case, I'm glad I'm wrong! Thanks for correcting me Fred. I > was going by info on the Google web site that said you needed to > $20/yr version to import GPS data. I assumed that data had to be in > KML format. But you are saying that KML can be overlayed on the free > version. I guess I'll be installing Google Earth today. > Google is taking over the world. > Many eyeballs indeed. > - Doug > www.TravelByGPS.com > Where you will find many free, adventure related, GPX files you can > overlay on World Wind *or* Google Earth. > > > > ------------------------------------------------------------------------ > YAHOO! GROUPS LINKS > > * Visit your group "gpsxml > <http://groups.yahoo.com/group/gpsxml>" on the web. > > * To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/>. > > > ------------------------------------------------------------------------ > > .
andres_narvaez+sbcglobal.net on Thu Jun 30 17:09:14 2005 (link)
Is there some kind of service where I can buy a gps device, and get my coordinates streamed automatically in xml to me? Thanks, Drace [Non-text portions of this message have been removed]
jcasseng+yahoo.fr on Sat Jul 09 12:36:28 2005 (link), replying to msg
http://kanadier.gps-info.de/ ___________________________________________________________________________ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger T?chargez cette version sur http://fr.messenger.yahoo.com
wtimvgqctn+yahoo.com on Sun Jul 10 13:26:54 2005 (link)
I got an incredible interest rate on my home loan, I am self employed I refinanced my home. This service can help. http://tpbaj.com/i/LzMvaW5kZXgvd2F6ZWUvcWw0ZzZqdXFwd2hjMnJj take 30 seconds and fill out this free form to save money
mebijohn+earthlink.net on Sun Jul 10 18:27:53 2005 (link)
Hi, I just noticed that in the GPX Schema 1.1, in the definition of the "lon" element, the description says "latitude". I assume this mailing list is the place to report that. Thanks! -John
robertlipe+usa.net on Mon Jul 11 13:10:11 2005 (link), replying to msg
Brian Lalor wrote: > Subject says it all. I've got some archived GPX files that are GPX > 1.0 and I'd like to process them as GPX 1.1. A quick google didn't If you don't have additional namespaces, GPSBabel can do it. The transformation isn't flawless, but for simple files, it handles the drudgery of fixing the bounds, time, and link stuff just fine. It will sometimes trip on redefining the xsi:schemealocation in the header. If you do have adidtional namespaces that are incompatible with 1.1, GPSBabel pretty much bursts into flames and I've not really convinced myself this is worth addressing. http://www.gpsbabel.org > Are the GPX 1.0 docs still available anywhere? I don't see any links > on the Topografix site. http://www.topografix.com/gpx_manual.asp (I actually liked the old style of doc better.)
jeremy+groundspeak.com on Mon Jul 11 13:46:57 2005 (link)
He understood. There isn't one. ________________________________________ Subject: Re: [gpsxml] MySQL schema for GPX 1.1 I'm not sure we understand each other. :-) I'm looking for a predefined database table structure and relationships between them for storing waypoints and tracklogs
robertlipe+usa.net on Tue Jul 19 13:43:23 2005 (link)
Hi, Gang. I've recently been tinkering with some other tools to process GPX files and it occurs to me we have an opportunity to improve compatibility and presentation. Most of the developers here are reading tags like <desc>, <type>, and <cmt> and passing them to some kind of tookit for display to the user. Many toolkits in this era accept some set of HTML markup for presentation to let you do some text markup for emphasis. So it's tempting to pass the GPX fields straight to those. Unfortunately, we don't really have a way in GPX to express whether the source actually _is_ HTML or not. If I knew that the GPX file was going to be consumed by such an application, I might write: <desc><b>alligators</b> may eat you</desc> which would, of course, be ugly in other applications. If if I don't know that it's going to be consumed and write a GPX file that contains <desc></body></desc> it could do Bad Things to an application that is reading it as HTML. So my strict reading of GPX is that developers should thus be careful to _not_ treat GPX files as potentially containing HTML unless they have control of -or knowledge of- both the producer and consumer. (This, of course, sort of violates the interoperability goals of GPX, but the world is a dangerous place.) There's a potential for malice otherwise. It does seem that a "html=(true|false)" flag on the various GPX tags that are essentially free-form text would allow this class of apps to more intelligently display such data. And I have no idea what strain or subset of HTML/XML should be allowed in there. I'm just tossing it out for consideration in a future GPX. :-) RJL
azbithead+gmail.com on Tue Jul 19 15:46:03 2005 (link), replying to msg
Trying to reliably put HTML into elements of type xsd:string is difficult at best. I did some research on this and found two solutions: escape all the markup (as in your example) or use CDATA. However, as you surmised, the real problem starts when someone is trying to consume this as it is difficult to know when the element contains HTML vs. plain text. There really is no good way to do this within the current GPX schema. A book I have titled "Definitive XML Schema" suggests the following complex type definition for this purpose: <xsd:complexType> name="TextType" mixed="true"> <xsd:sequence> <xsd:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute ref="xml:lang"/> </xsd:complexType> Because this type allows mixed content, plain text can be present in an element of this type. It also allows marked up content. In particular, it is possible to put XHTML content in it. Since XHTML has its own namespace it is easy for the consumer to identify that the element contains plain text or XHTML or perhaps some other kind of markup that can be ignored if it is not understood by the consumer. We might want to incorporate this type in the next version of GPX. - Steve
robertlipe+usa.net on Tue Jul 19 16:20:21 2005 (link), replying to msg
> On Jul 19, 2005, at 5:46 PM, azbithead wrote: > > > We might want to incorporate this type in the next version of GPX. Nice summary. I do think it's something we should kick around for GPX. Brian Lalor wrote: > It seems to me that the <extension/> element already exists for this > purpose, at least in part. Why not just stick > <div xmlns="..."> > <b>html</b> content here! > </div> > in the <extension/> element? You could augment that content with the > <name/> element... If you wanted to duplicate the contents of <desc>, <cmt>, and friends, and were willing to forgo interoperability of those fields, that would probably work OK. (And I'm not saying that an marked up and plain text duplication is necessarily a terrible thing; just a little distasteful.) Or is there something I'm missing here other than extension being an escape hatch for "that which my program understands but yours probably won't"? RJL
jeremy+groundspeak.com on Tue Jul 19 16:28:47 2005 (link)
Our internal data format contains IsHtml=true or false, depending on whether the user checked the box. It is a simple way of doing it on the database side and rendering the format correctly on the display side. As we?ll be adding HTMLTidy to descriptions and cleaning up future HTML (read: badly formed) it will help clean up the bad html problem, but it is not a universal solution. This is also not the perfect solution, but considering the context of html data you could reliably determine if something is html by checking for markup. < /> will catch the majority of markup code. Jeremy From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Robert Lipe Sent: Tuesday, July 19, 2005 4:20 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Re: HTML in GPX fields > On Jul 19, 2005, at 5:46 PM, azbithead wrote: > > > We might want to incorporate this type in the next version of GPX. Nice summary. I do think it's something we should kick around for GPX. Brian Lalor wrote: > It seems to me that the <extension/> element already exists for this > purpose, at least in part. Why not just stick > <div xmlns="..."> > <b>html</b> content here! > </div> > in the <extension/> element? You could augment that content with the > <name/> element... If you wanted to duplicate the contents of <desc>, <cmt>, and friends, and were willing to forgo interoperability of those fields, that would probably work OK. (And I'm not saying that an marked up and plain text duplication is necessarily a terrible thing; just a little distasteful.) Or is there something I'm missing here other than extension being an escape hatch for "that which my program understands but yours probably won't"? RJL [Non-text portions of this message have been removed]
gps_maps+travelbygps.com on Wed Jul 20 07:06:24 2005 (link)
I created GPX file with ExpertGPS 1.9 b7: http://www.travelbygps.com/special/letour05/letour05.gpx which appears to validate to GPX 1.1 version standard using the online validation tool at http://www.fahrradspass.de/GpxSearch/GpxSearch but Garmin MapSource v6.5 will not open it. Any ideas? - Doug BTW I've reported this issue to Dan Foster earlier this morning but I have a anxious patron who wants to track down Lance Armstrong this weekend and I have found the forum typically provides faster and more detailed response.
robertlipe+usa.net on Wed Jul 20 07:46:54 2005 (link), replying to msg
Doug Adomatis wrote: > I created GPX file with ExpertGPS 1.9 b7: > http://www.travelbygps.com/special/letour05/letour05.gpx > which appears to validate to GPX 1.1 version standard using the online > validation tool at > http://www.fahrradspass.de/GpxSearch/GpxSearch Your validation tool isn't militant enough. $ SAX2Count letour05.gpx Error at file /tmp/letour05.gpx, line 330, char 56 Message: Datatype error: Type:InvalidDatatypeFacetException, Message: Invalid chars encountered.. Error at file /tmp/letour05.gpx, line 2390, char 58 Message: Datatype error: Type:InvalidDatatypeFacetException, Message: Invalid chars encountered.. The two offenders are a routepoint for LES-TROIS-MOUTIE and a waypoint for TDF050306. The longitude is represented in exponential notation which, according to our XSD, isn't valid. Manually tweak those two line from the form <wpt lat="47.0666666931535" lon="1.66666600868727E-02">^M to <wpt lat="47.0666666931535" lon=".0166666600868727">^M Move the decimal two points to the left. GPSBabel will actually read this file and "fix" it on the way through if you don't want to do it by hand. $ gpsbabel -i gpx -f letour05.gpx.1 -o gpx,gpxver=1.1 -F le.gpx (robertl) rjloud:/tmp $ SAX2Count le.gpx le.gpx: 1358 ms (2041 elems, 532 attrs, 5150 spaces, 12689 chars) > BTW I've reported this issue to Dan Foster earlier this morning but I > have a anxious patron who wants to track down Lance Armstrong this Catching Lance isn't easy. :-)
egroups+topografix.com on Wed Jul 20 10:05:26 2005 (link), replying to msg
Hello, Wednesday, July 20, 2005, 10:23:35 AM, Robert wrote: R> The two offenders are a routepoint for LES-TROIS-MOUTIE and a waypoint R> for TDF050306. The longitude is represented in exponential notation R> which, according to our XSD, isn't valid. R> Manually tweak those two line from the form R> <wpt lat="47.0666666931535" lon="1.66666600868727E-02">^M R> to R> <wpt lat="47.0666666931535" lon=".0166666600868727">^M Thanks Rob for tracking this down for me. As I wrote to Doug off-list, my development computer isn't connected to the Web right now, so I wasn't in a position to run SAXCount on the offending file. Since you pinpointed the error, I tracked it down in my code. The problem is in using MSXML to create attributes. I store latitude and longitude as C++ doubles, and MSXML writes 0.005 in exponential notation. The schema specifies that lat and lon are of type decimal, not float, so exponents aren't allowed. I don't see an obvious way to tell MSXML to treat as a decimal, so I'm going to do something like: StoreGPXLatitude( double dblLatitude ) { CString strValue; strValue.Format( "%.6f", dblLatitude ); // 6 decimal places StoreGPXString( strValue ); // pass to generic string handler } My question to you all: How many decimal places are you storing for your lat/lon values? 5 seems a minimum. (I realize the default answer is "as many as needed or the user entered", but if you zoom WAY into a scanned map and mark a waypoint, you could be dealing with nanometer precision...) I've gone back and added an explicit "decimal places" parameter to each call to store a double or floating-point number to a GPX file. Here's what I'm using for place values: latitude: 6 (roughly centimeter accuracy) longitude: 6 elevation : 2 (1 cm accuracy) almost everything else: 1 Any concerns with that approach? If your app writes GPX data, now would be a good time to run 0.005 and 0.00005 through as lat, lon, and ele values, and ensure that your output validates. Mine obviously didn't, but I believe I've fixed it now. -- Dan Foster
robertlipe+usa.net on Wed Jul 20 11:24:36 2005 (link), replying to msg
> Thanks Rob for tracking this down for me. As I wrote to Doug "Robert", please. > My question to you all: How many decimal places are you storing for > your lat/lon values? 5 seems a minimum. (I realize the default Storing or splashing in GPX output? > answer is "as many as needed or the user entered", but if you zoom WAY > into a scanned map and mark a waypoint, you could be dealing with > nanometer precision...) The far more common case is just math gibberish presenting "fake" precision ala 43.666666666666666666667 . > I've gone back and added an explicit "decimal places" parameter to > each call to store a double or floating-point number to a GPX file. > Here's what I'm using for place values: > latitude: 6 (roughly centimeter accuracy) > longitude: 6 > elevation : 2 (1 cm accuracy) > almost everything else: 1 > > Any concerns with that approach? I was backed into the corner of nine decimal places for lat and long. Ironically, it was for compatibility with ExpertGPS. :-) Arguments that the precision was totally bogus got me nowhere. People wanted to get out of GPSBabel what came out of ExpertGPS, never mind that the resolution was approaching the diameter of a dirt molecule. So I'm using "%0.9lf" when printing the coords. > If your app writes GPX data, now would be a good time to run 0.005 and > 0.00005 through as lat, lon, and ele values, and ensure that your > output validates. Mine obviously didn't, but I believe I've fixed it Good idea. I just checked. I'm good. Thanx, RJL
gps_maps+travelbygps.com on Thu Jul 21 08:39:54 2005 (link), replying to msg
--- Robert Lipe wrote: > Your validation tool isn't militant enough. Once again, thanks Robert. The file has been repaired and is available for consumption by Mapsource users. http://www.travelbygps.com/special/letour05/letour05.gpx - Doug
gps_maps+travelbygps.com on Thu Jul 21 08:41:38 2005 (link), replying to msg
--- "offroute2000" wrote: > The free version of Google Earth will display your GPX data just fine. > Simply upload your GPX data to GPXchange.com and then click the "Build > KML File" button to convert the GPX into a KML file. Fred Here is my first KML file http://www.travelbygps.com/guides/glen_canyon/Davis_Gulch.kml I created using the conversion utility at GPXchange.com. Thanks for maintaining this valuable resource for map authors. - Doug
cybarber+gmail.com on Sun Jul 24 08:01:43 2005 (link), replying to msg
Google Earth just opens GPX files so there is no need to first convert them to kml files. cybarber --- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+t...> wrote: > --- "offroute2000" wrote: > > The free version of Google Earth will display your GPX data just > fine. > > Simply upload your GPX data to GPXchange.com and then click > the "Build > > KML File" button to convert the GPX into a KML file. > > Fred > Here is my first KML file > http://www.travelbygps.com/guides/glen_canyon/Davis_Gulch.kml > I created using the conversion utility at GPXchange.com. > Thanks for maintaining this valuable resource for map authors. > - Doug
cybarber+gmail.com on Sun Jul 24 08:04:28 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > The free version of Google Earth will display your GPX data just fine. Choose Open and browse to our local GPX file. > Simply upload your GPX data to GPXchange.com and then click the "Build No need to convert it first. > KML File" button to convert the GPX into a KML file. Next, download > the KML file onto your local machine and launch it there. If the free > version of Google Earth (or any other version) is installed on the > same machine, double clicking the KML file will launch the app and > load the overlay, with descriptive data etc. No need to pay the $20. > > Google Earth Plus allows you to import GPS data or GPX, however it > renders tracks as a series of points instead of a polyline etc. Using > GPXchange provides a much cleaner overlay and does a better job of > listing the track and waypoint data. The free version of Google Earth does make a polyline from a GPX file. > If you want to see how this works without uploading a file, simply go > to GPXchange.com, navigate to the example (Yosemite Falls) and > download its KML. > > Worldwind is interesting, but the free version of Google Earth will be > widely used. All in all, very cool stuff. > > --- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+t...> wrote: > > --- In gpsxml+yahoogroups.com, "offroute2000" <feedback+g...> wrote: > > > Lots of changes made recently, but a fun one is the addition of KML > > > files for account holders who wish to do the conversion. Just upload > > > your own GPX and then use the Build KML File button to produce a > > > formatted overlay for use with Keyhole/Google Earth. > > > > Compare to NASA's World Wind program to Google Earth. > > Google Earth appears to be a re-marketing of prior Keyhole > > product/service. The pro version is down to $400/yr. There is a free > > version but to import GPS data in KML format you have to pay at least > > the $20/yr fee. > > > > Compare to NASA's World Wind > > http://worldwind.arc.nasa.gov/ > > It's free and will import *and* export GPX data directly. > > > > All in all, good news for GPX proponents. > > - Doug > > www.TravelByGPS.com > > Where you will find many free GPX data files, waypoints and tracks, > > to adventure.
robertlipe+usa.net on Mon Jul 25 13:24:08 2005 (link), replying to msg
cybarber wrote: > Google Earth just opens GPX files so there is no need to first convert > them to kml files. More precisely, Google Earth calls GPSBabel to convert the GPX to KML on your behalf and then slurps up the KML. But a normal user probably doesn't need to know that detail. RJL
gps_maps+travelbygps.com on Mon Jul 25 21:04:45 2005 (link), replying to msg
--- "cybarber" wrote: > No need to convert it first. In my opinion the converter at GPXchange.com produces a better looking overlay in Google Earth that what Google Earth renders when importing GPX directly. - Doug www.travelbygps.com
cybarber+gmail.com on Fri Jul 29 05:42:02 2005 (link), replying to msg
I wonder if that is true. I expect Google Earth to use an ?internal? XSLT transformation to convert a GPX to KML. That is very easy and quick. Do you have inside info onGE's conversion? Cybarber On 7/25/05, Robert Lipe <robertlipe+usa.net> wrote: > cybarber wrote: > > Google Earth just opens GPX files so there is no need to first convert > > them to kml files. > > More precisely, Google Earth calls GPSBabel to convert the GPX to KML on > your behalf and then slurps up the KML. > > But a normal user probably doesn't need to know that detail. > > RJL > > > ________________________________ > YAHOO! GROUPS LINKS > > Visit your group "gpsxml" on the web. > > To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > ________________________________ >
jeremy+groundspeak.com on Fri Jul 29 08:54:59 2005 (link), replying to msg
> Do you have inside info onGE's conversion? Read the credits. They personally thank Robert for the use of GPSBabel. So yeah, I think he knows what he is talking about ;) ----- Original Message ----- From: cybarber <cybarber+gmail.com> To: gpsxml+yahoogroups.com Sent: Fri, 29 Jul 2005 05:40:58 -0700 Subject: Re: [gpsxml] Re: GPX to KML conversion now available at GPXchange.com > [Non-text portions of this message have been removed]
yahoo+markwigmore.co.uk on Tue Aug 09 09:24:30 2005 (link)
Hi! I have a 3D graphics package written in C++ and OpenGL and I've been asked to add a GPX file reader to it. I've not used XML before and I was wondering if anyone here could give me some pointers to get me started. So far I've downloaded the MSXML 3.0 SDK, but it all seems gibberish to me! Most of the examples seem to be in VB too. I've tried implementing the C++ example for the DOMDocument2schemas() method, but it keeps failing on the line: _bstr_t namespaceURI(_T("http://www.topografix.com/GPX/1/1")); hr = pIXMLDOMSchemaCollection->add(namespaceURI, _variant_t(_T ("C:\\MyProjects\\XML\\gpx.xsd"))); hr is always E_FAIL. :-( Thanks in anticipation! Mark
yahoo+markwigmore.co.uk on Tue Aug 09 09:45:46 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Mark Wigmore" <yahoo+m...> wrote: > I've not used XML before and I > was wondering if anyone here could give me some pointers to get me > started. For a good, quick introduction to XML and XML-related technologies check out http://www.w3schools.com/. Beyond that, there are numerous books on the subject. > So far I've downloaded the MSXML 3.0 SDK, but it all seems gibberish > to me! FWIW, we have implemented XML parsing in our C++ projects using the Xerces parser (http://xml.apache.org/xerces-c/index.html) and it has worked well for us. We looked at MSXML but didn't really like it. I will also say that if you're just starting out with XML you got a bit of a large task ahead of you. However, I think it's worth the effort as XML is a powerful technology. - Steve
yahoo+markwigmore.co.uk on Tue Aug 09 10:13:28 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "azbithead" <azbithead+g...> wrote: Thanks for the advice. > will also say that if you're just starting out with XML you got a bit > of a large task ahead of you. I thought XML was supposed to be this wonderful technology that would solve everyone's data file problems! Surely it should be a simple matter of plugging in a library and having simple commands, like ReadXMLFile() and GetXMLData()!!! Bring back binary files. At least you knew where you were with them. ;-) Mark
azbithead+gmail.com on Tue Aug 09 10:21:12 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Mark Wigmore" <yahoo+m...> wrote: > Surely it should be a simple > matter of plugging in a library and having simple commands, like > ReadXMLFile() and GetXMLData()!!! Oh, how I wish that life was that simple. > Bring back binary files. At least you knew where you were with them. Yeah, usually in a hex editor. ;-) - Steve
yahoo+markwigmore.co.uk on Wed Aug 10 09:09:52 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Michael Collinson <mikes+a...> wrote: > Mark, > > An alternative approach to using the schema is just to parse the GPX XML > directly and pull out what you are looking for. Less elegant in the long > run perhaps but much faster to implement immediately ... and get ones head > around it. I had thought of doing that but was under the impression XML was more plug-and-play that it seems to be. > Are you able to use MS .NET framework in your C++ project? Have been avoiding it as much as possible. It's a graphics-intensive real-time 3D app and I can do without the massive overheads of .NET. Many thanks for the code snippet. I shall have a good browse through it. Regards, Mark
jwo+soi.city.ac.uk on Fri Aug 12 07:25:27 2005 (link)
Does anyone know of any downloadable examples of complex GPX 1.1 files that include most or all of the lesser used tags such as <dgpsid>, <fix>, <hdop>, <geoidheight> etc.? While I can create such files myself, I am now at the stage where I need to test with output from 'real' applications that generate the more complex forms of GPX file. Thanks, Jo.
cybarber+gmail.com on Sat Aug 13 01:30:59 2005 (link), replying to msg
Hi, For writting a XSLT transformation sheet to convert GPX 1.0 to 1.1 and from 1.1 to 1.0(lot of apps don't accept v1.1 yet) I have been looking for GPX v1.1 files aswell lately as most on the web are v 1.0. However the http://www.travelbygps.com/trails.php site has several files for download with wpt, rte and trk. However I could not find a file yet with all the metadata elements and all elements available for wpt-rpt etc. Best bet is to use the XML Schema which is available at http://www.topografix.com/GPX/1/1/gpx.xsd If you are interested I will post tomorrow some links to my gpx10t011.xslt<http://members.home.nl/cybarber/geomatters/gpx10to11.xslt>and to my gpx11to10.xslt <http://members.home.nl/cybarber/geomatters/gpx11to10.xslt> and to a small HTML application to do the transforms and save them locally. I hope that also my gpx to kml and kml to gpx transformation sheets will be ready then. William A Slabbekoorn On 8/12/05, jo_wood_london <jwo+soi.city.ac.uk> wrote: > Does anyone know of any downloadable examples of complex GPX 1.1 > files > that include most or all of the lesser used tags such as <dgpsid>, > <fix>, <hdop>, <geoidheight> etc.? > > While I can create such files myself, I am now at the stage where I > need to test with output from 'real' applications that generate the > more complex forms of GPX file. > > Thanks, > > Jo. > > > > ________________________________ > YAHOO! GROUPS LINKS > > Visit your group "gpsxml" on the web. > > To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > ________________________________ > [Non-text portions of this message have been removed]
cybarber+gmail.com on Sun Aug 14 16:07:21 2005 (link), replying to msg
Links to my gpx10t011.xslt<http://members.home.nl/cybarber/geomatters/gpx10to11.x slt>and to my gpx11to10.xslt <http://members.home.nl/cybarber/geomatters/gpx11to10.xslt> are active. Hope to post this week also a small HTML application to do the transforms and save them locally. I hope that also my gpx to kml and kml to gpx transformation sheets will be ready then. William A Slabbekoorn --- In gpsxml+yahoogroups.com, "Troy Hopwood" <troyh+d...> wrote: > These XSLT transformations would be very useful. Please let us know when > they're available to look at. > > > > Thanks, > > > > Troy > > > > _____ > > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of > cybarber > Sent: Saturday, August 13, 2005 1:31 AM > To: gpsxml+yahoogroups.com > Subject: Re: [gpsxml] Examples of complex GPX files > > > > Hi, > > For writting a XSLT transformation sheet to convert GPX 1.0 to 1.1 and from > 1.1 to 1.0(lot of apps don't accept v1.1 yet) I have been looking for GPX > v1.1 files aswell lately as most on the web are v 1.0. > > However the http://www.travelbygps.com/trails.php site has several files for > > download with wpt, rte and trk. However I could not find a file yet with all > > the metadata elements and all elements available for wpt-rpt etc. > Best bet is to use the XML Schema which is available at > http://www.topografix.com/GPX/1/1/gpx.xsd > If you are interested I will post tomorrow some links to my > gpx10t011.xslt<http://members.home.nl/cybarber/geomatters/gpx10to11.x slt>and > to my > gpx11to10.xslt <http://members.home.nl/cybarber/geomatters/gpx11to10.xslt> > and to a small HTML application to do the transforms and save them locally. > I hope that also my gpx to kml and kml to gpx transformation sheets will be > ready then. > William A Slabbekoorn > > On 8/12/05, jo_wood_london <jwo+s...> wrote: > > Does anyone know of any downloadable examples of complex GPX 1.1 > > files > > that include most or all of the lesser used tags such as <dgpsid>, > > <fix>, <hdop>, <geoidheight> etc.? > > > > While I can create such files myself, I am now at the stage where I > > need to test with output from 'real' applications that generate the > > more complex forms of GPX file. > > > > Thanks, > > > > Jo. > > > > > > > > ________________________________ > > YAHOO! GROUPS LINKS > > > > Visit your group "gpsxml" on the web. > > > > To unsubscribe from this group, send an email to: > > gpsxml-unsubscribe+yahoogroups.com > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > To unsubscribe from this group, send an email to: > > gpsxml-unsubscribe+yahoogroups.com > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > ________________________________ > > > > > [Non-text portions of this message have been removed] > > > > > SPONSORED LINKS > > > Xml > <http://groups.yahoo.com/gads? t=ms&k=Xml+specification&w1=Xml+specification& > w2=Xml+format&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s= 96&.sig > =x6fKGLPGUJ9tB5dEbVs5DA> specification > > Xml > <http://groups.yahoo.com/gads? t=ms&k=Xml+format&w1=Xml+specification&w2=Xml+ > format&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.sig =FEyYr4 > xAtd1L99t4J2eSjw> format > > Data > <http://groups.yahoo.com/gads? t=ms&k=Data&w1=Xml+specification&w2=Xml+format > &w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.sig=AAQoF MvojfQE > t6AG7q55tg> > > > Java > <http://groups.yahoo.com/gads? t=ms&k=Java+xml&w1=Xml+specification&w2=Xml+fo > rmat&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.sig=b jFEA2zi > SwGZpHe3d86zbA> xml > > Voice > <http://groups.yahoo.com/gads? t=ms&k=Voice+xml&w1=Xml+specification&w2=Xml+f > ormat&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.sig= idCXn57 > 49nmM2Q6J7kN-jg> xml > > Xml > <http://groups.yahoo.com/gads? t=ms&k=Xml+database&w1=Xml+specification&w2=Xm > l+format&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.s ig=VwnI > DaMFtNYo3GTS52YW2g> database > > > > _____ > > YAHOO! GROUPS LINKS > > > > * Visit your group "gpsxml <http://groups.yahoo.com/group/gpsxml> " > on the web. > > * To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com > <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > * Your use of Yahoo! Groups is subject to the Yahoo! > <http://docs.yahoo.com/info/terms/> Terms of Service. > > > > _____ > > > > [Non-text portions of this message have been removed]
cybarber+gmail.com on Sun Aug 14 16:26:28 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "cybarber" <cybarber+g...> wrote: > Links to my > gpx10t011.xslt <http://members.home.nl/cybarber/geomatters/gpx10to11.xslt> >and to my > gpx11to10.xslt <http://members.home.nl/cybarber/geomatters/gpx11to10.xslt> > are active. > > Hope to post this week also a small HTML application to do the > transforms and save them locally. > I hope that also my gpx to kml and kml to gpx transformation sheets > will be ready then. > > William A Slabbekoorn > > > --- In gpsxml+yahoogroups.com, "Troy Hopwood" <troyh+d...> wrote: > > These XSLT transformations would be very useful. Please let us > know when > > they're available to look at. > > > > > > > > Thanks, > > > > > > > > Troy > > > > > > > > _____ > > > > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On > Behalf Of > > cybarber > > Sent: Saturday, August 13, 2005 1:31 AM > > To: gpsxml+yahoogroups.com > > Subject: Re: [gpsxml] Examples of complex GPX files > > > > > > > > Hi, > > > > For writting a XSLT transformation sheet to convert GPX 1.0 to 1.1 > and from > > 1.1 to 1.0(lot of apps don't accept v1.1 yet) I have been looking > for GPX > > v1.1 files aswell lately as most on the web are v 1.0. > > > > However the http://www.travelbygps.com/trails.php site has several > files for > > > > download with wpt, rte and trk. However I could not find a file > yet with all > > > > the metadata elements and all elements available for wpt-rpt etc. > > Best bet is to use the XML Schema which is available at > > http://www.topografix.com/GPX/1/1/gpx.xsd > > If you are interested I will post tomorrow some links to my > > > gpx10t011.xslt<http://members.home.nl/cybarber/geomatters/gpx10to11.x > slt>and > > to my > > gpx11to10.xslt > <http://members.home.nl/cybarber/geomatters/gpx11to10.xslt> > > and to a small HTML application to do the transforms and save them > locally. > > I hope that also my gpx to kml and kml to gpx transformation > sheets will be > > ready then. > > William A Slabbekoorn > > > > On 8/12/05, jo_wood_london <jwo+s...> wrote: > > > Does anyone know of any downloadable examples of complex GPX 1.1 > > > files > > > that include most or all of the lesser used tags such as > <dgpsid>, > > > <fix>, <hdop>, <geoidheight> etc.? > > > > > > While I can create such files myself, I am now at the stage > where I > > > need to test with output from 'real' applications that generate > the > > > more complex forms of GPX file. > > > > > > Thanks, > > > > > > Jo. > > > > > > > > > > > > ________________________________ > > > YAHOO! GROUPS LINKS > > > > > > Visit your group "gpsxml" on the web. > > > > > > To unsubscribe from this group, send an email to: > > > gpsxml-unsubscribe+yahoogroups.com > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > > To unsubscribe from this group, send an email to: > > > gpsxml-unsubscribe+yahoogroups.com > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > > ________________________________ > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > SPONSORED LINKS > > > > > > Xml > > <http://groups.yahoo.com/gads? > t=ms&k=Xml+specification&w1=Xml+specification& > > > w2=Xml+format&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s= > 96&.sig > > =x6fKGLPGUJ9tB5dEbVs5DA> specification > > > > Xml > > <http://groups.yahoo.com/gads? > t=ms&k=Xml+format&w1=Xml+specification&w2=Xml+ > > > format&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.sig > =FEyYr4 > > xAtd1L99t4J2eSjw> format > > > > Data > > <http://groups.yahoo.com/gads? > t=ms&k=Data&w1=Xml+specification&w2=Xml+format > > > &w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.sig=AAQoF > MvojfQE > > t6AG7q55tg> > > > > > > Java > > <http://groups.yahoo.com/gads? > t=ms&k=Java+xml&w1=Xml+specification&w2=Xml+fo > > > rmat&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.sig=b > jFEA2zi > > SwGZpHe3d86zbA> xml > > > > Voice > > <http://groups.yahoo.com/gads? > t=ms&k=Voice+xml&w1=Xml+specification&w2=Xml+f > > > ormat&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.sig= > idCXn57 > > 49nmM2Q6J7kN-jg> xml > > > > Xml > > <http://groups.yahoo.com/gads? > t=ms&k=Xml+database&w1=Xml+specification&w2=Xm > > > l+format&w3=Data&w4=Java+xml&w5=Voice+xml&w6=Xml+database&c=6&s=96&.s > ig=VwnI > > DaMFtNYo3GTS52YW2g> database > > > > > > > > _____ > > > > YAHOO! GROUPS LINKS > > > > > > > > * Visit your group "gpsxml > <http://groups.yahoo.com/group/gpsxml> " > > on the web. > > > > * To unsubscribe from this group, send an email to: > > gpsxml-unsubscribe+yahoogroups.com > > <mailto:gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > > > * Your use of Yahoo! Groups is subject to the Yahoo! > > <http://docs.yahoo.com/info/terms/> Terms of Service. > > > > > > > > _____ > > > > > > > > [Non-text portions of this message have been removed]
gonzzo+gmx.li on Tue Aug 16 07:20:00 2005 (link)
hi there, first of all i appologize for any strange or silly question. I am not a programmer, just a very curious user.. the gpx file below is made with NH-Top50Trans from an NMEA log file. Garmin MapSource 6.7 won't read in this file anymore. Previous versions did read it with no problem. Garmin claims to support GPX 1.1 with own extensions. they call it GPXXv2 (new for MS6.7, MS6.5 supported GPXXv1). http://www.garmin.com/xmlschemas/GpxExtens...xtensionsv2.xsd after some debugging (I really was only curious), I figured out that by removing the line <number>1</number> the file is accepted my MS6.7. someone told me I could instead also remove the line <name>Track 1</name> or change the order of those lines to <name>Track 1</name> <number>1</number> and MS6.7 would read it too. actually, according to XMLSPY, it seems the order of those lines...? now, looking at http://www.topografix.com/gpx/1/1/#type_trkType (I did not find 1.0), I can't really see that there is a prerequisite on the order of those lines. well, perhaps it's different with GPX 1.0... anyway, I wonder.. is NH-Top50Trans the "bad" guy by creating a wrong GPX XML file, or is MapSource the "bad" guy, by not being able to read correct XML files with just the order of the lines mixed up? in any case, is the GPX1.0 description still anywhere on the net? thanks dan -------------------------------------------- <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> <gpx xmlns="http://www.topografix.com/GPX/1/0" 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" version="1.0" creator="NH-Top50Trans"> <time>2005-08-16T01:08:16Z</time> <trk> <number>1</number> <name>Track 1</name> <trkseg> <trkpt lat="46.955292" lon="7.549332"> <ele>622</ele> <time>2005-08-13T17:10:17Z</time> <course>206</course> <speed>16.11</speed> <sat>6</sat> </trkpt> <trkpt lat="46.954898" lon="7.549072"> <ele>620</ele> <time>2005-08-13T17:10:20Z</time> <course>205</course> <speed>15.28</speed> <sat>7</sat> </trkpt> <trkpt lat="46.954540" lon="7.548832"> <ele>618</ele> <time>2005-08-13T17:10:23Z</time> <course>206</course> <speed>13.33</speed> <sat>6</sat> </trkpt> </trkseg> </trk> </gpx> -------------------------------------------
azbithead+gmail.com on Tue Aug 16 10:52:51 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Dan" <gonzzo+g...> wrote: > is NH-Top50Trans the "bad" guy by creating a wrong GPX XML file, or > is MapSource the "bad" guy, by not being able to read correct XML > files with just the order of the lines mixed up? I tried validating your file in XMLSpy and it failed. That would indicate that NH-Top50Trans created the file incorrectly. - Steve
cybarber+gmail.com on Tue Aug 16 16:18:38 2005 (link)
Have been using Microsofts research WWMX proggie location stamper to match my track GPX timestamps with the Digital images timestamp to add GPS data to the JPG's EXIF info. A disavantage of WWMX is that it canot export the images with there location stamped coordinats and elevation in an XML file. When making a trip of a few hours with over a hundred photo.s taken along the route is manually not feasable. I found RoboGEO which does the job for you. You can drop a folder of images in the program together with your GPX track file. RoboGEO will then math/location stamp and make a caption on the images. One can then export the whole lot in a Goolge Maps (you need to get a Google API key) ready folder. That folder contains an XML file with image names, lat, long, elevatin, time and image links. To get this stuff easy into Google Earth instead of Google Maps I wrote an XSLT transformation sheet which transforms the RoboGEO.xml file into a GE KML file with the image es as Waypoints and all points as a path. (I am still working on an update of the transformation sheet to calculate for each waypoint a heading(for camera animation) ). The result is fabulous. SO the procedure is: Download the track from your GPS(GPS 60 into Mapsource) export the GPS track as an GPX version 1.1 file. Dowenload your images from the trip to a folder. Open Robogeo, load the image folder and the GPXS track. Do the stamping and captioning if desired. Then Export from Robogeo to a Google Maps format. In that process you can set a title and description for each image. Then transform the resulted RoboGEO.xml file with my style sheet and load the resulting file into Google Earth. Robogeo photo file to KML stylesheet http://members.home.nl/cybarber/geomatters/PhotoTrack2KML.xslt can be downloaded as of Agust 17th. PhotoTrack2KML.xslt application for RoboGEO input file transformation to KML is now online including Bearing, distance to next Waypoint and Slope degree calculations Good Luck William A Slabbekoorn aka Cybarber
cybarber+gmail.com on Tue Aug 16 16:25:42 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Dan" <gonzzo+g...> wrote: > hi there, > > first of all i appologize for any strange or silly question. I am not > a programmer, just a very curious user.. > > the gpx file below is made with NH-Top50Trans from an NMEA log file. > Garmin MapSource 6.7 won't read in this file anymore. Previous > versions did read it with no problem. Garmin claims to support GPX > 1.1 with own extensions. they call it GPXXv2 (new for MS6.7, MS6.5 > supported GPXXv1). > http://www.garmin.com/xmlschemas/GpxExtens...xtensionsv2.xsd > > > after some debugging (I really was only curious), I figured out that > by removing the line > <number>1</number> > the file is accepted my MS6.7. someone told me I could instead also > remove the line > <name>Track 1</name> > or change the order of those lines to > <name>Track 1</name> > <number>1</number> > and MS6.7 would read it too. actually, according to XMLSPY, it seems > the order of those lines...? According to the version 1.0 Schema (also the version 1.1 schema Name has to come before number. name, cmt,desc,src,url,urlname,number etc in that sequential order. > now, looking at http://www.topografix.com/gpx/1/1/#type_trkType (I > did not find 1.0), I can't really see that there is a prerequisite on > the order of those lines. well, perhaps it's different with GPX 1.0... > > anyway, I wonder.. > is NH-Top50Trans the "bad" guy by creating a wrong GPX XML file, or > is MapSource the "bad" guy, by not being able to read correct XML > files with just the order of the lines mixed up? > > in any case, is the GPX1.0 description still anywhere on the net? Why do you ask? You wrote the loacation already below!! http://www.topografix.com/GPX/1/0/gpx.xsd > thanks > dan > > > -------------------------------------------- > <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> > <gpx > xmlns="http://www.topografix.com/GPX/1/0" > 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" version="1.0" > creator="NH-Top50Trans"> > > <time>2005-08-16T01:08:16Z</time> > > <trk> > <number>1</number> > <name>Track 1</name> > <trkseg> > <trkpt lat="46.955292" lon="7.549332"> > <ele>622</ele> > <time>2005-08-13T17:10:17Z</time> > <course>206</course> > <speed>16.11</speed> > <sat>6</sat> > </trkpt> > <trkpt lat="46.954898" lon="7.549072"> > <ele>620</ele> > <time>2005-08-13T17:10:20Z</time> > <course>205</course> > <speed>15.28</speed> > <sat>7</sat> > </trkpt> > <trkpt lat="46.954540" lon="7.548832"> > <ele>618</ele> > <time>2005-08-13T17:10:23Z</time> > <course>206</course> > <speed>13.33</speed> > <sat>6</sat> > </trkpt> > </trkseg> > </trk> > > </gpx> > -------------------------------------------
cybarber+gmail.com on Mon Aug 22 05:16:13 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "cybarber" <cybarber+g...> wrote: > Have been using Microsofts research WWMX proggie location stamper to > match my track GPX timestamps with the Digital images timestamp to > add GPS data to the JPG's EXIF info. > > A disavantage of WWMX is that it canot export the images with there > location stamped coordinats and elevation in an XML file. When > making a trip of a few hours with over a hundred photo.s taken along > the route is manually not feasable. > > I found RoboGEO which does the job for you. You can drop a folder of > images in the program together with your GPX track file. RoboGEO > will then math/location stamp and make a caption on the images. > One can then export the whole lot in a Goolge Maps (you need to get > a Google API key) ready folder. That folder contains an XML file > with image names, lat, long, elevatin, time and image links. > > To get this stuff easy into Google Earth instead of Google Maps I > wrote an XSLT transformation sheet which transforms the RoboGEO.xml > file into a GE KML file with the image es as Waypoints and all > points as a path. (I am still working on an update of the > transformation sheet to calculate for each waypoint a heading(for > camera animation) ). > > The result is fabulous. > > SO the procedure is: > > Download the track from your GPS(GPS 60 into Mapsource) export the > GPS track as an GPX version 1.1 file. > > Dowenload your images from the trip to a folder. > > Open Robogeo, load the image folder and the GPXS track. > Do the stamping and captioning if desired. > Then Export from Robogeo to a Google Maps format. In that process > you can set a title and description for each image. > > Then transform the resulted RoboGEO.xml file with my style sheet and > load the resulting file into Google Earth. > > Robogeo photo file to KML stylesheet > http://members.home.nl/cybarber/geomatters/PhotoTrack2KML.xslt can > be downloaded as of Agust 17th. PhotoTrack2KML.xslt application for > RoboGEO input file transformation to KML is now online including > Bearing, distance to next Waypoint and Slope degree calculations. August 19th: added cumulative climbing meters from start to finish. August 20th: Updated path with icons August 22nd: added Elevation polygon profile of track. added Polygon Bounding box of track region. > Good Luck > William A Slabbekoorn aka Cybarber
verntessi0+yahoo.com on Mon Aug 22 22:40:40 2005 (link)
The documentation at http://www.topografix.com/GPX/1/1/ states that <rtept> elements are wptTypes yet when I create a .GPX file that includes <desc> and <time> elements (perfectly valid for wptTypes) in <rtept> tags, the file no longer validates. It seems that the schema and documentation do not match.
egroups+topografix.com on Tue Aug 23 04:14:40 2005 (link), replying to msg
Hello, Tuesday, August 23, 2005, 1:39:19 AM, verntessi0 wrote: v> The documentation at http://www.topografix.com/GPX/1/1/ states that v> <rtept> elements are wptTypes yet when I create a .GPX file that v> includes <desc> and <time> elements (perfectly valid for wptTypes) in v> <rtept> tags, the file no longer validates. v> It seems that the schema and documentation do not match. Did you put them in the correct order? <time> before <desc> ? The GPX 1.1 schema says that <rte> contains zero or more <rtept>, and <rtept> is the same type as <wpt>. <xsd:complexType name="rteType"> <xsd:sequence> ... <xsd:element name="rtept" type="wptType" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> -- Dan Foster
chris.lawless+worktech.com on Tue Aug 23 04:26:14 2005 (link)
Have any of you written applications in Delphi to write GPX files? I'm keen to find any examples that might be out there to see how you went about it. Chris.
doolaard+gmail.com on Tue Aug 23 06:01:22 2005 (link), replying to msg
Hi, Writing gpx-files are just xlm files, so you can write them to file etc... lik eyou do with xml-files. For this you can for instance use the XML DOM structure. Greetings, Jan On 8/23/05, Chris Lawless <chris.lawless+worktech.com> wrote: > Have any of you written applications in Delphi to write GPX files? I'm > keen to find any examples that might be out there to see how you went > about it. > > Chris. > > > > > > > Yahoo! Groups Links > > > > > > > > -- J.K. Pieters tel : +31 6 1850 1847
chris.lawless+worktech.com on Tue Aug 23 06:03:07 2005 (link)
Well yes, if you're familiar with writing XML files... which I'm not, yet. I thought an example might make it a bit easier if anyone has any. Chris. -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Jan Pieters Sent: Tuesday, August 23, 2005 9:01 AM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Creating GPX Files from Delphi Hi, Writing gpx-files are just xlm files, so you can write them to file etc... lik eyou do with xml-files. For this you can for instance use the XML DOM structure. Greetings, Jan On 8/23/05, Chris Lawless <chris.lawless+worktech.com> wrote: > Have any of you written applications in Delphi to write GPX files? I'm > keen to find any examples that might be out there to see how you went > about it. > > Chris. > > > > > > > Yahoo! Groups Links > > > > > > > > -- J.K. Pieters tel : +31 6 1850 1847 Yahoo! Groups Links
doolaard+gmail.com on Tue Aug 23 06:06:44 2005 (link), replying to msg
Hi, there is many info available for this. Maybe you find something here: http://delphi.about.com/od/objectpascalide/l/aa072500a.htm Jan On 8/23/05, Chris Lawless <chris.lawless+worktech.com> wrote: > Well yes, if you're familiar with writing XML files... which I'm not, > yet. I thought an example might make it a bit easier if anyone has any. > > Chris. > > -----Original Message----- > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf > Of Jan Pieters > Sent: Tuesday, August 23, 2005 9:01 AM > To: gpsxml+yahoogroups.com > Subject: Re: [gpsxml] Creating GPX Files from Delphi > > Hi, > > Writing gpx-files are just xlm files, so you can write them to file > etc... lik eyou do with xml-files. For this you can for instance use > the XML DOM structure. > > Greetings, > > Jan > > On 8/23/05, Chris Lawless <chris.lawless+worktech.com> wrote: > > Have any of you written applications in Delphi to write GPX files? I'm > > keen to find any examples that might be out there to see how you went > > about it. > > > > Chris. > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > -- > J.K. Pieters > tel : +31 6 1850 1847 > > > > > Yahoo! Groups Links > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > -- J.K. Pieters tel : +31 6 1850 1847
verntessi0+yahoo.com on Tue Aug 23 09:35:56 2005 (link), replying to msg
--- Dan Foster <egroups+t...> wrote: > Did you put them in the correct order? <time> before <desc> ? DOH! That was the problem. I was unaware that the elements had to appear in a specific order. Upon changing this, the file validates. Thank you for your help.
chris.lawless+worktech.com on Sun Aug 28 19:46:22 2005 (link)
I'm not an XML expert so please go easy..! Does anyone have a very simple track example they could send me? I'm looking to write an app that will record a track as I drive. The data will come from my PC GPS, I'd like to log the latitude, longitude, time, speed and maybe elevation too. If I understand things correctly in its most basic form this would be a GPX file with one track? Now, I assume if I get that right then adding a second track should be pretty easy, it's just the same over again, essentially? Finally I would like to map my track at www.motionbased.com but I've had some odd results testing there. The majority of the time it rejects any GPX file I try to upload. One limitation I know they have is no more than one point per second, is this just their limitation? I assume it isn't a limitation in the GPX format? Thanks in advance for any help. Chris.
robertlipe+usa.net on Sun Aug 28 22:18:31 2005 (link), replying to msg
> Does anyone have a very simple track example they could send me? I'm There are several such tracks in both the GPX examples at Topografix and in the reference/tracks/ directory of the GPSBabel source tree. > will come from my PC GPS, I'd like to log the latitude, longitude, time, > speed and maybe elevation too. You can also convert from a bazillion such formats (NMEA, GPL, Mapsend, Mapsource, etc.) to GPX with GPSBabel. > If I understand things correctly in its most basic form this would be a > GPX file with one track? That's implementation-defined. For example, if your GPS lost lock, it would be up to the implementation to decide if it started another track or continued on the same one. If it lost lock and regained it four seconds later, it probably makes sense to consider it the same track. If it regained it four hours later, it probably makes sense for it to be a different track. > some odd results testing there. The majority of the time it rejects any > GPX file I try to upload. One limitation I know they have is no more The acid test of GPX is "does the GPX validate?" If the reader is rejecting GPX that validates, shame on the reader. If you're using a product that creates GPX that won't validate, shame on the writer. Notice how we have a formally defined line in the sand that decrees where blame is to be placed. :-) > than one point per second, is this just their limitation? I assume it > isn't a limitation in the GPX format? I really can't think of any such limit that's inherent in GPX itself. I certainly don't contrive such a thing in my GPX writers. It sounds sort of weird to have such an artificial limit. > Thanks in advance for any help. Enjoy. RJL
chris.lawless+worktech.com on Wed Aug 31 13:46:39 2005 (link)
Ok, I know it's not pretty, but I'm experimenting with creating my GPX file in Delphi. I know what I'm trying to achieve but I think there's something I don't get about XML. This is a trimmed down fells_loop GPX file, for now I'm just trying to recreate this. So here is the objective: <?xml version="1.0"?> <gpx version="1.0" creator="ExpertGPS 1.1 - http://www.topografix.com" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <time>2002-02-27T17:18:33Z</time> <trk> <trkseg> <trkpt lat="42.402805" lon="-71.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> <course>234.88657553856572</course> <speed>9.033266067504883</speed> </trkpt> <trkpt lat="42.402805" lon="-71.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> <course>234.88657553856572</course> <speed>9.033266067504883</speed> </trkpt> </trkseg> </trk> </gpx> Pretty simple huh? Well, I have some Delphi XML code, it is long hand for now, shown at the bottom of this email. I'm trying to add the attributes to the GPX node with all the parameters. It all works great except for the xmlns attribute. If I include this anywhere it then also appears as an attribute for the <trk> node like this: <xml version="1.0"> <gpx version="1.0" creator="lawlessc+gmail.com" xmlns="http://www.topografix.com/GPX/1/0" 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"> <trk xmlns=""> <trkseg> <trkpt lat="42.402805" lon="-71.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> <course>234.88657553856572</course> <speed>9.033266067504883</speed> </trkpt> <trkpt lat="42.402805" lon="-71.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> <course>234.88657553856572</course> <speed>9.033266067504883</speed> </trkpt> </trkseg> </trk> </gpx> </xml> You see how both <gpx... and <trk... have the xmlns attribute? Yet I only add it to <gpx... If I change the attribute name to "chris" this no longer happens. If I don't add it at all everything is fine too. Is there some XML issue here I should be aware of that causes this attribute to be treated differently? Delphi code follows for those who are interested: var iXml: IDOMDocument; xmlNode, gpxNode, trksegNode, trkNode, trkptNode, iChild, iAttribute: IDOMNode; begin // empty the document XMLDoc.Active := False; XMLDoc.XML.Text := ''; XMLDoc.Active := True; // root iXml := XmlDoc.DOMDocument; xmlNode := iXml.appendChild (iXml.createElement ('xml')); iAttribute := iXml.createAttribute ('version'); iAttribute.nodeValue := '1.0'; xmlNode.attributes.setNamedItem (iAttribute); //GPX gpxNode := xmlNode.appendChild(iXml.createElement ('gpx')); iAttribute := iXml.createAttribute ('version'); iAttribute.nodeValue := '1.0'; gpxNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('creator'); iAttribute.nodeValue := 'lawlessc+gmail.com'; gpxNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('xmlns'); iAttribute.nodeValue := 'http://www.topografix.com/GPX/1/0'; gpxNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('xmlns:xsi'); iAttribute.nodeValue := 'http://www.w3.org/2001/XMLSchema-instance'; gpxNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('xsi:schemalocation'); iAttribute.nodeValue := 'http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd'; gpxNode.attributes.setNamedItem (iAttribute); trkNode := gpxNode.appendChild(iXml.createElement ('trk')); trksegNode := trkNode.appendChild(iXml.createElement ('trkseg')); trkptNode := trksegNode.appendChild (iXml.createElement ('trkpt')); iAttribute := iXml.createAttribute ('lat'); iAttribute.nodeValue := '42.402805'; trkptNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('lon'); iAttribute.nodeValue := '-71.11377'; trkptNode.attributes.setNamedItem (iAttribute); iChild := trkptNode.appendChild (iXml.createElement ('ele')); iChild.appendChild (iXml.createTextNode('15')); iChild := trkptNode.appendChild (iXml.createElement ('time')); iChild.appendChild (iXml.createTextNode('2004-11-12T05:19:10-05:00')); iChild := trkptNode.appendChild (iXml.createElement ('course')); iChild.appendChild (iXml.createTextNode('234.88657553856572')); iChild := trkptNode.appendChild (iXml.createElement ('speed')); iChild.appendChild (iXml.createTextNode('9.033266067504883')); trkptNode := trksegNode.appendChild (iXml.createElement ('trkpt')); iAttribute := iXml.createAttribute ('lat'); iAttribute.nodeValue := '42.402805'; trkptNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('lon'); iAttribute.nodeValue := '-71.11377'; trkptNode.attributes.setNamedItem (iAttribute); iChild := trkptNode.appendChild (iXml.createElement ('ele')); iChild.appendChild (iXml.createTextNode('15')); iChild := trkptNode.appendChild (iXml.createElement ('time')); iChild.appendChild (iXml.createTextNode('2004-11-12T05:19:10-05:00')); iChild := trkptNode.appendChild (iXml.createElement ('course')); iChild.appendChild (iXml.createTextNode('234.88657553856572')); iChild := trkptNode.appendChild (iXml.createElement ('speed')); iChild.appendChild (iXml.createTextNode('9.033266067504883')); // show XML in memo Memo1.Lines.Text := FormatXMLData (XMLDoc.XML.Text);
chris.lawless+worktech.com on Wed Aug 31 14:14:15 2005 (link)
Ahh ha..! Looks like my problem is because I was adding the <TRK> as a child of <GPX> instead of a child of <XML>. Sorry to waste peoples time. Chris. -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Chris Lawless Sent: Wednesday, August 31, 2005 4:49 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Basic XML, GPX and Delphi Help Ok, I know it's not pretty, but I'm experimenting with creating my GPX file in Delphi. I know what I'm trying to achieve but I think there's something I don't get about XML. This is a trimmed down fells_loop GPX file, for now I'm just trying to recreate this. So here is the objective: <?xml version="1.0"?> <gpx version="1.0" creator="ExpertGPS 1.1 - http://www.topografix.com" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <time>2002-02-27T17:18:33Z</time> <trk> <trkseg> <trkpt lat="42.402805" lon="-71.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> <course>234.88657553856572</course> <speed>9.033266067504883</speed> </trkpt> <trkpt lat="42.402805" lon="-71.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> <course>234.88657553856572</course> <speed>9.033266067504883</speed> </trkpt> </trkseg> </trk> </gpx> Pretty simple huh? Well, I have some Delphi XML code, it is long hand for now, shown at the bottom of this email. I'm trying to add the attributes to the GPX node with all the parameters. It all works great except for the xmlns attribute. If I include this anywhere it then also appears as an attribute for the <trk> node like this: <xml version="1.0"> <gpx version="1.0" creator="lawlessc+gmail.com" xmlns="http://www.topografix.com/GPX/1/0" 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"> <trk xmlns=""> <trkseg> <trkpt lat="42.402805" lon="-71.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> <course>234.88657553856572</course> <speed>9.033266067504883</speed> </trkpt> <trkpt lat="42.402805" lon="-71.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> <course>234.88657553856572</course> <speed>9.033266067504883</speed> </trkpt> </trkseg> </trk> </gpx> </xml> You see how both <gpx... and <trk... have the xmlns attribute? Yet I only add it to <gpx... If I change the attribute name to "chris" this no longer happens. If I don't add it at all everything is fine too. Is there some XML issue here I should be aware of that causes this attribute to be treated differently? Delphi code follows for those who are interested: var iXml: IDOMDocument; xmlNode, gpxNode, trksegNode, trkNode, trkptNode, iChild, iAttribute: IDOMNode; begin // empty the document XMLDoc.Active := False; XMLDoc.XML.Text := ''; XMLDoc.Active := True; // root iXml := XmlDoc.DOMDocument; xmlNode := iXml.appendChild (iXml.createElement ('xml')); iAttribute := iXml.createAttribute ('version'); iAttribute.nodeValue := '1.0'; xmlNode.attributes.setNamedItem (iAttribute); //GPX gpxNode := xmlNode.appendChild(iXml.createElement ('gpx')); iAttribute := iXml.createAttribute ('version'); iAttribute.nodeValue := '1.0'; gpxNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('creator'); iAttribute.nodeValue := 'lawlessc+gmail.com'; gpxNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('xmlns'); iAttribute.nodeValue := 'http://www.topografix.com/GPX/1/0'; gpxNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('xmlns:xsi'); iAttribute.nodeValue := 'http://www.w3.org/2001/XMLSchema-instance'; gpxNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('xsi:schemalocation'); iAttribute.nodeValue := 'http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd'; gpxNode.attributes.setNamedItem (iAttribute); trkNode := gpxNode.appendChild(iXml.createElement ('trk')); trksegNode := trkNode.appendChild(iXml.createElement ('trkseg')); trkptNode := trksegNode.appendChild (iXml.createElement ('trkpt')); iAttribute := iXml.createAttribute ('lat'); iAttribute.nodeValue := '42.402805'; trkptNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('lon'); iAttribute.nodeValue := '-71.11377'; trkptNode.attributes.setNamedItem (iAttribute); iChild := trkptNode.appendChild (iXml.createElement ('ele')); iChild.appendChild (iXml.createTextNode('15')); iChild := trkptNode.appendChild (iXml.createElement ('time')); iChild.appendChild (iXml.createTextNode('2004-11-12T05:19:10-05:00')); iChild := trkptNode.appendChild (iXml.createElement ('course')); iChild.appendChild (iXml.createTextNode('234.88657553856572')); iChild := trkptNode.appendChild (iXml.createElement ('speed')); iChild.appendChild (iXml.createTextNode('9.033266067504883')); trkptNode := trksegNode.appendChild (iXml.createElement ('trkpt')); iAttribute := iXml.createAttribute ('lat'); iAttribute.nodeValue := '42.402805'; trkptNode.attributes.setNamedItem (iAttribute); iAttribute := iXml.createAttribute ('lon'); iAttribute.nodeValue := '-71.11377'; trkptNode.attributes.setNamedItem (iAttribute); iChild := trkptNode.appendChild (iXml.createElement ('ele')); iChild.appendChild (iXml.createTextNode('15')); iChild := trkptNode.appendChild (iXml.createElement ('time')); iChild.appendChild (iXml.createTextNode('2004-11-12T05:19:10-05:00')); iChild := trkptNode.appendChild (iXml.createElement ('course')); iChild.appendChild (iXml.createTextNode('234.88657553856572')); iChild := trkptNode.appendChild (iXml.createElement ('speed')); iChild.appendChild (iXml.createTextNode('9.033266067504883')); // show XML in memo Memo1.Lines.Text := FormatXMLData (XMLDoc.XML.Text); Yahoo! Groups Links
dstewartms+winisp.net on Thu Sep 01 22:41:36 2005 (link)
Figured folks here might find this interesting: http://www.blogthevote.net/vetrax/map.aspx? track=http://www.singletracks.com/trax/functions/gpxDL2.php?id=1 Replace the second URL with your favorite GPX file (just needs to have <trk/> data in it!)
gps_maps+travelbygps.com on Fri Sep 02 03:16:43 2005 (link), replying to msg
--- In "dstewartms" wrote: > Figured folks here might find this interesting: > > http://www.blogthevote.net/vetrax/map.aspx? > track=http://www.singletracks.com/trax/functions/gpxDL2.php?id=1 > > Replace the second URL with your favorite GPX file (just needs to > have > <trk/> data in it!) I tried Katrina http://www.blogthevote.net/vetrax/map.aspx?track=http://www.travelbygps.com/special/katrina/katrina.gpx but it had a server error: <gpx xmlns='http://www.topografix.com/GPX/1/1'> was not expected. :(Doug
gps_maps+travelbygps.com on Fri Sep 02 03:55:51 2005 (link)
I grow weary of all the tweeking I've been doing lately to get my data to look good in the popular GPX viewers. I do most of my authoring in ExpertGPS, I publish the GPX from ExpertGPS on my web. I also have published a few files at GPXchange, especially files that I want to convert to KML for posting at bbs.keyhole.com (Google Earth Community). GPXchange has a 6 character limit on waypoint names which is not so bad because I've got a comment field. But when I use the GPX to KML converter at GPXchange, the comment field is droped and the waypoint name is used as the Placemark label. So I have to go back and edit all the KML Placemark names. This is time consuming. Am I missing a setting in ExpertGPS? one that would tell the converter to use the comment field instead of the waypoint field? Or, am I stuck with having to make edits because Google did not consult with this group;) - Doug
robertlipe+usa.net on Fri Sep 02 08:18:59 2005 (link), replying to msg
> I tried Katrina > http://www.blogthevote.net/vetrax/map.aspx?track=http://www.travelbygps.com/special/katrina/katrina.gpx > > but it had a server error: > <gpx xmlns='http://www.topografix.com/GPX/1/1'> was not expected. Converting the file to GPX 1.0 eliminates the error and allows the site to not work in exactly the same way as the original example. %-/ You can do that with GPSBabel thusly: gpsbabel -i gpx -f katrina.gpx -o gpx -F kat10.gpx
robertlipe+usa.net on Fri Sep 02 08:36:38 2005 (link), replying to msg
Doug Adomatis wrote: > I grow weary of all the tweeking I've been doing lately to get my data > to look good in the popular GPX viewers. I do most of my authoring in The fact that you have to tweak at all means (IMHO) that we've collectively missed the mark somewhere. > GPXchange has a 6 character limit on waypoint names which is not so If true, that'd be a good example of missing the mark. GPX itself has no such length limit. Imposing lowest common denominator on an implementation of data that may not even go to a GPS based on limits of certain GPSes seems pretty artificial. > bad because I've got a comment field. But when I use the GPX to KML > converter at GPXchange, the comment field is droped and the waypoint > name is used as the Placemark label. So I have to go back and edit > all the KML Placemark names. This is time consuming. Having some experience in the conversion game, I'll say this is a hard problem in the general case to solve automatically. GPX has at least three different "string things" (name, cmt, desc) that can be associated with points. All are optional. So you may have zero or more of them to be mapped to the target format. KML has a similar number. So trying to figure out what to put where is icky. > Am I missing a setting in ExpertGPS? one that would tell the converter > to use the comment field instead of the waypoint field? Seems like that is GPXchange's decision, not ExpertGPS' decision, isn't it? It would probably be a pretty easy XSLT/Perl transformation to move one field to another if you need to 'coddle' such a program. Heck, isn't it a search and replace exercise to replace <cmt>foo</cmt> with <name>foo</name> (or whatever) ? > Or, am I stuck with having to make edits because Google did not > consult with this group;) In fairness, you have similar problems even when KML/GPX conversions aren't involved, right? Lots of GPX files tend to use cmt and desc pretty willy nilly. I know in my own product, to compensate for this problem, I have code like this all over the place: odesc = waypointp->notes; /* GPX desc */ if (!odesc) { odesc = waypointp->description; /* GPX cmt */ } if (!odesc) { odesc = waypointp->shortname; /* GPX name */ } It's kind of a problem at the edge between GPX and the rest of the world. RJL
egroups+topografix.com on Fri Sep 02 09:15:56 2005 (link), replying to msg
Hello, Friday, September 2, 2005, 11:36:35 AM, Robert wrote: R> Having some experience in the conversion game, I'll say this is a hard R> problem in the general case to solve automatically. GPX has at least R> three different "string things" (name, cmt, desc) that can be associated R> with points. All are optional. So you may have zero or more of them to R> be mapped to the target format. KML has a similar number. So trying R> to figure out what to put where is icky. ExpertGPS 2.0 is going to make things worse, not better. All objects in ExpertGPS 2.0 have a Label field, which is the text that is displayed on the map for that object. This is my answer to the missing "short description" field that gets discussed in GPX circles occasionally. This data gets written to the gpx_overlay::label_text field in the GPX file. <name> and <cmt> have very precise definitions - they are the GPS name and GPS comment of the waypoint/route/track. They shouldn't be used for general purpose text interchange between mapping programs, for example. <desc> is just defined as "A text description of the element. Holds additional information about the element intended for the user, not the GPS." In practice, desc has been used to transfer two different types of information: feature names, and long-winded descriptions. Many mapping programs have a "short name" field and a "long description/notes" field. ExpertGPS 1.x didn't, ExpertGPS 2.0 does. I'm putting "short name" into <gpx_overlay:label_text> and "long description/notes" into <desc>. Since <name> and <cmt> contain GPS data that has different restrictions based on the GPS receiver that uses it, ExpertGPS 2.0 doesn't even bother to fill these fields unless the user specifically places data there. Waypoint names and comments are generated on the fly from the contents of the Label field. GPX readers should behave gracefully when receiving a waypoint that doesn't have text in any of the optional fields. It would be nice to reach some consensus on how these fields should be mapped in GPX 1.1 (and fix it right in GPX 1.2) so Doug doesn't have to handcraft his GPX files for specific GPX programs, and so Robert can write converters that don't have to worry about "flavors" of GPX. -- Dan Foster
robertlipe+usa.net on Fri Sep 02 15:29:28 2005 (link), replying to msg
> ExpertGPS 2.0 is going to make things worse, not better. All objects I could just choose to ignore your newfangled tags. :-) > <name> and <cmt> have very precise definitions - they are the GPS name > and GPS comment of the waypoint/route/track. They shouldn't be used > for general purpose text interchange between mapping programs, for > example. I guess I missed a beat somwwhere. I thought the goal was to provide data files that were interoperable. /me checks first sentence of http://www.topografix.com/gpx.asp and returns. Yep. "format for the interchange of GPS data (waypoints, routes, and tracks) between applications" seems to say that "interchange between mapping programs" was in our crosshairs. "-----------------------" is a perfectly legal GPS name on some units (Explorist will support 20 characters and dashes are legal) and totally illegal on a base Etrex as dashes aren't legal and even if they were, it's only six characters. So if our goal was to allow exchange, trying to code that in the data instead of at the target won't work. But I think that giving up on names and moving it to another namespace isn't the right solution. > Since <name> and <cmt> contain GPS data that has different > restrictions based on the GPS receiver that uses it, ExpertGPS 2.0 > doesn't even bother to fill these fields unless the user specifically Oh, dear. That's not good. > places data there. Waypoint names and comments are generated on the > fly from the contents of the Label field. GPX readers should behave > gracefully when receiving a waypoint that doesn't have text in any of > the optional fields. So if someone receives a file from an ExpertGPS user and uses GPSBabel to upload it to their receiver or merge it with another (we'll say it's a Mac or Solaris user just so the "just use ExpertGPS" defense doesn't apply :-) may get waypoints named things like "WPT097" becuase this perfectly lovely field in the GPX file for waypoint name is empty.[1] My definition of "graceful" in the absence of a receiver name was to give it one. I do have an option for some format that will pick a name from cmt or desc but that only works on "edge" formats so I _know_ the characterstics of the target namespace. > It would be nice to reach some consensus on how these fields should be > mapped in GPX 1.1 (and fix it right in GPX 1.2) so Doug doesn't have > to handcraft his GPX files for specific GPX programs, and so Robert > can write converters that don't have to worry about "flavors" of GPX. Yes, having content creatores/collectors and software dudes not having to coddle programs or cater to special extensions should very much be a goal for us. RJL
azbithead+gmail.com on Fri Sep 02 16:41:40 2005 (link), replying to msg
I just want to make one, perhaps obvious, point on this topic. XML Schema can be used to specify data structures and valid content for those data structures. It cannot be used to specify how those data structures are to be used or processed. So, Dan's statements about how the name, desc and cmt fields are intended to be used really don't have any power to make applications use them that way. That isn't to say that there shouldn't be suggestions for the usage of various fields. Just that those suggestions can't be enforced by an XML Schema validating parser. Adding new string elements to the GPX schema won't improve this situation. - Steve
dstewartms+winisp.net on Sat Sep 03 10:17:15 2005 (link), replying to msg
Ah, but you shouldn't have to convert ;-) ... I only had a 1.0 file to test with when I wrote the site, but now it works with 1.1 files as well, thanks! --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > > I tried Katrina > > http://www.blogthevote.net/vetrax/map.aspx? track=http://www.travelbygps.com/special/katrina/katrina.gpx > > > > but it had a server error: > > <gpx xmlns='http://www.topografix.com/GPX/1/1'> was not expected. > > Converting the file to GPX 1.0 eliminates the error and allows the site > to not work in exactly the same way as the original example. %-/ > > You can do that with GPSBabel thusly: > gpsbabel -i gpx -f katrina.gpx -o gpx -F kat10.gpx
gps_maps+travelbygps.com on Sun Sep 04 05:01:34 2005 (link), replying to msg
--- Dan Foster <egroups+t...> wrote: > It would be nice to reach some consensus on how these fields should > be mapped in GPX 1.1 (and fix it right in GPX 1.2) so Doug doesn't > have to handcraft his GPX files for specific GPX programs, I'm mostly agree with Dan, but really all that it would take to make me happy is for Google Earth to display the Label field as the Placemark name. Here are my thoughts on the rest: Waypoint Name - I think I understand why GPXchange limits to 6 characters - the old GPS units could only dispaly 6 characters. I too try to live by this limitation as I still use my trusty Garmin 12XL. This limitation only proves cumbersom when I want to combine several data files. It is difficult to maintain uniqueness and meaningfulness, hundreds of times over, with only six characters. Comment - Also for hardware reasons, I try to keep comment fields to 16 characters. It is usually not a problem. I'd guess only 10 or 20 percent of place names are more than 16 characters and evenso you can do a lot of meaningful abbreviation with 16 characters. Description - I don't want any limits here as this is where I'm "long winded." I'd also like there not be any character limitations but I do refrain from using common delimiters because someone will inevitably export the data to a text file and find that, usually a comma, has messed up everything. Labels - If I go to the trouble to make labels for display on a map: I want them used; I don't want them ignored and something else used instead, and I don't want a 6, 16, or even 26 character limitation. If I were to go back and edit (once again) all my files to include a Label, I would simply copy the Comment field. From here on out, I intend to create meaningfull and thoughtfull Lables. Hopefully the popular mapping appilications will use them. - Doug www.TravelByGPS.com Travel By GPS (tm) Maps Waypoints and Tracks to Adventure
ce_reisinger+yahoo.com on Tue Sep 06 20:03:39 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Chris Lawless" <chris.lawless+w...> wrote: > Finally I would like to map my track at www.motionbased.com but I've had > some odd results testing there. The majority of the time it rejects any > GPX file I try to upload. One limitation I know they have is no more > than one point per second, is this just their limitation? I assume it > isn't a limitation in the GPX format? > I just tries to upload a gpx file with one track, also without any luck. The file was created with mapsource 6.5. I tried running the gpx file through gpsbabel converting from/to a gpx file (as a means of cleanup). Still no go. I ran both files through SAXCount which verifies the file and which I have used in the pass to catch gpsbabel issues. Still no luck. I'd point the finger at motionbased right about now. Carl
chris.lawless+worktech.com on Wed Sep 07 04:15:41 2005 (link)
ce_reisinger+yahoo.com on Wed Sep 07 09:08:31 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Chris Lawless" <chris.lawless+w...> wrote: > From my testing a few months ago I know one limitation they have is that > it will not accept more than one point per second. Not sure about other > restrictions. The other restriction is that there must be timestamps on the trkpts. Downloading tracks from my Garmin GPS V via mapsource seems to strip any timepoints. Quite a pain since all I really want is a elevation profile. Carl
chris.lawless+worktech.com on Wed Sep 07 13:46:14 2005 (link)
I actually once got a file to upload so there is one in my inbox but if I export it as GPX it will not re-import to motionbased, it says it has errors. Funny eh! Chris. -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of ce_reisinger Sent: Wednesday, September 07, 2005 12:08 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: Simple GPX Track Example --- In gpsxml+yahoogroups.com, "Chris Lawless" <chris.lawless+w...> wrote: > From my testing a few months ago I know one limitation they have is that > it will not accept more than one point per second. Not sure about other > restrictions. The other restriction is that there must be timestamps on the trkpts. Downloading tracks from my Garmin GPS V via mapsource seems to strip any timepoints. Quite a pain since all I really want is a elevation profile. Carl Yahoo! Groups Links
dananderson2+yahoo.com on Wed Sep 07 13:47:18 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "ce_reisinger" <ce_reisinger+y...> wrote: > The other restriction is that there must be timestamps on the > trkpts. > > Downloading tracks from my Garmin GPS V via mapsource seems to strip > any timepoints. Mapsource does not strip timestamps. The active log has timestamps and the "saved" logs do not for most Garmin models. The "save" function is not a "save" in the usual sense of the word. It strips timestamps and will reduce a 10,000 point active log to 250 points or less in a "saved" log in the case of a GPSmap 76. The sizes and whether timestamps are stripped or not are dependent on the receiver model. The "saved" logs are for Tracback(TM) routes but are useful in other ways too. Dan A.
kathy_tn189+yahoo.com on Sat Sep 10 09:38:00 2005 (link)
Hello! Look at this Computing & Internet information directory. URL : http://www.hi-fiweb.com/users/amitha/ Cheers! Amitha
ravirao888+yahoo.co.in on Sat Sep 17 09:37:32 2005 (link)
It is a FREE 3-4 page full-color weekly newsletter that talks about current trends, opportunities, and challenges in the global IT industry. Articles are submitted by leading consulting firms in the field. It also has career opportunities on occassion. www.indiaitweekly.com www.indiaitweekly.in
gps_maps+travelbygps.com on Sun Sep 18 11:42:30 2005 (link)
ExpertGPS 2.0 beta version has new "display styles", which I find to be simular to flexible "symbology" in the GIS world. While I understand why this a good feature, It is taking myself and others a little longer to create GPS maps with the new ExpertGPS because we are getting bogged down with defining the symbology. That is, if we haven't already created a waypoint for, say a Visitor Center, we have to create a new waypoint type and define it. I would rather have pre-defined choices ( dare I say a *standard* set of waypoints/route/track types ). In programs like ESRI ArcMap, I believe that you can load to a "layer file (.lyr)" that associates symbology with data. But I do not see where ExpertGPS maintains such a file. The symbol types appear to be saved internally to program, so it is not clear to me how this symbology passed along when the data files are shared. I would like for Dan or someone else in the know to shed a little light on this subject - without using a lot of XML jargon - and tell me the best way for ExpertGPS user groups, like Travel By GPS contributors to share their symbolgy definitions. Thanks, - Doug www.TravelByGPS.com
egroups+topografix.com on Mon Sep 19 05:28:05 2005 (link), replying to msg
Hello, Sunday, September 18, 2005, 2:41:55 PM, Doug wrote: D> ExpertGPS 2.0 beta version has new "display styles", which I find to D> be simular to flexible "symbology" in the GIS world. D> I do not see D> where ExpertGPS maintains such a file. The symbol types appear to be D> saved internally to program, so it is not clear to me how this D> symbology passed along when the data files are shared. D> I would like for Dan or someone else in the know to shed a little D> light on this subject - without using a lot of XML jargon - and tell D> me the best way for ExpertGPS user groups, like Travel By GPS D> contributors to share their symbolgy definitions. Yes, ExpertGPS 2.0 allows you to create your own symbology, and share it with other ExpertGPS users and other programs that use the gpx_style and gpx_overlay schemas. Each object (<wpt>, <rte>, etc) has a <type> field. In ExpertGPS, this is not a freeform text entry field - you have to pick a type from a list of types you've previously created. The list of types for all of the objects in ExpertGPS forms your Personal Symbology. ExpertGPS stores this in the Windows registry, just like other program settings and preferences. Every aspect of a type's display characteristics (trk type "Hiking Trail" is a brown dashed line, 5mm wide, which uses label font Arial, 9mm, bold) can be described in GPX using the gpx_overlay and gpx_style schemas. When you save a GPX file in ExpertGPS, all of the information needed to recreate the visual appearance of the object is written to the GPX file as part of the object's GPX element. When ExpertGPS opens a GPX file, it reads the visual display information for each GPX element, and stores it into a separate File Symbology. This is separate from the user's Personal Symbology. (You probably don't want your well-crafted styles wiped out by my pink and orange color scheme when you open a file I send you) When ExpertGPS displays an object on the map, it first has to choose what style to use. It looks at the object's <type> field ("Hiking Trail"). It looks in the Personal Symbology for a match, and uses it if found. If there isn't a match in the Personal Symbology, ExpertGPS looks for a match in the File Symbology. If it still hasn't found a match, it displays the object using a rather boring default style. So, if Doug sends Dan a GPX file with a brown dashed "Hiking Trail" and a pink "Racetrack" and Dan has already created a red solid "Hiking Trail" in his copy of ExpertGPS, Dan will see a red solid "Hiking Trail" and a pink "Racetrack" displayed. This is the default behavior in ExpertGPS, and it favors the user's symbology over the file author's symbology. Doug probably doesn't like the default behavior, since his well-crafted GPX files will look different on different user's computers, depending on how they have set up their Personal Symbologies. Luckily for him, there's a way to reverse ExpertGPS' behavior on a file-by-file basis. For map authors who want to ensure that their GPX maps display in ExpertGPS exactly as they do on the map author's system, there is a check box "Override global map style settings" in the File Information dialog in ExpertGPS (on the File menu). If checked, ExpertGPS makes a note of this in the private topografix namespace in the GPX file. The GPX file is read into ExpertGPS as described above, and the File Symbology is still created. But now the search order is changed, and ExpertGPS looks at the File Symbology first. The document is displayed as the map author intended. By toggling the "Override global map style settings" check box in ExpertGPS, you can switch back and forth between displaying a GPX file using your own symbology, or using the symbology of the map author. So, the one line answer to Doug's question is: "If it is important that the end user see the GPX data exactly as you intended, check "Override global map style settings" in the File Information dialog in ExpertGPS." I hope this makes it easier to author your maps, Doug. I had you in mind when I created that override setting. For other software designers still reading this: obviously, everything above is extremely ExpertGPS-specific. Feel free to mimic or ignore as you see fit. -- Dan Foster
gps_maps+travelbygps.com on Tue Sep 20 07:11:50 2005 (link), replying to msg
--- Dan Foster wrote: > Yes, ExpertGPS 2.0 allows you to create your own symbology, and share > it with other ExpertGPS users and other programs that use the > gpx_style and gpx_overlay schemas. Dan, Thank you for your detailed reply. I now have the motivation to take time for creating good symbology. - Doug
mll1013+yahoo.com on Wed Sep 21 13:45:38 2005 (link), replying to msg
Is this still possible? I don't see a way to turn on lat/lon in the turn-by-turn directions from mapsonus. Perhaps there's a back-door trick to getting this to work? --- In gpsxml+yahoogroups.com, "kz6g" <kz6g+y...> wrote: > Maps on us [www.mapsonus.com]can save turn by turn lat/lon GPS > waypoint data to an html file. It would be great if this could be > converted to gpx for importing into GPS applications like EasyGPS, > ExpertGPS, etc. > I am not a GPX developer, but I know a lot of GPS users would love a > way to import a series of waypoints into a GPS application from an > on-line trip planning application. Mapblast, mapquest, etc., do not > have this functionality. > Thoughts anyone? > > Thanks > KZ6G
cybarber+gmail.com on Thu Sep 29 01:04:19 2005 (link)
Hi Group, In below Google Earth-Keyhole forum message I put some links to XSLT stylesheets i created to transform GPX v1.0 to 1.1 and v1.1 to 1.0, GPX to Gooogle Ear6ths KML format and vice-versa. You will also find a GML to KML transformation sheet. I included a draft GUI(windows/IE HTA application). (link will be broken!) http://bbs.keyhole.com/ubb/remlinker.php? Cat=0&Entry=19257&F_Board=SupportKML&Thread=132922&Main=132922 Cybarber
josemoliver+msn.com on Fri Sep 30 08:18:39 2005 (link)
Anybody know if there is an IFilter available for .GPX files? IFilters are plugins for indexing files and other content on Windows. More info: http://channel9.msdn.com/wiki/default.aspx/Channel 9.DesktopSearchIFilte rs
cybarber+gmail.com on Sat Oct 01 04:39:12 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "cybarber" <cybarber+g...> wrote: > Hi Group, > > In below Google Earth-Keyhole forum message I put some links to XSLT > stylesheets i created to transform GPX v1.0 to 1.1 and v1.1 to 1.0, GPX > to Google Earths KML format and vice-versa. > You will also find a GML to KML transformation sheet. Today I added the robogeo.xml (Geocoded photo file) to KML trasnformation sheet to the GUI: http://members.home.nl/cybarber/geomatters/KmlGpxGmlTransform.hta > I included a draft GUI(windows/IE HTA application). > > (link will be broken!) > http://bbs.keyhole.com/ubb/remlinker.php? > Cat=0&Entry=19257&F_Board=SupportKML&Thread=132922&Main=132922 > > > Cybarber
chris.lawless+worktech.com on Sat Oct 01 05:26:31 2005 (link)
Although not a HPX specific issue I wondered if any of you could guide me a little on the creation of an XML GPX file using the MSXML control, specifically in setting up attributes. The XML I am generating is below, the problem I have is that the parser puts xmlns="" into the <trk> tag even though I am not asking it to (or not intentionally anyway). I'm still feeling my way through this a little, I add the version to get the <?xml then create the root node and add the attributes. Once that is done I start adding tags. If I remove the section that adds the xmlns attribute all is well but of course it isn't in the first part then. Should this reference be added in a different way? Any help appreciated. Chris. <?xml version="1.0"?> <gpx xmlns="http://www.topografix.com/GPX/1/0" version="1.0" creator="lawlessc+gmail.com" xmlns:TopoFusion="http://www.TopoFusion.com" 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.TopoFusion.com http://www.TopoFusion.com/topofusion.xsd"> <trk xmlns=""> <trkseg> <trkpt lat="44.402805" lon="-73.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> </trkpt> <trkpt lat="44.402805" lon="-73.11377"> <ele>15</ele> <time>2004-11-12T05:19:10-05:00</time> </trkpt> </trkseg> </trk> </gpx>
chachkov+yahoo.com on Mon Oct 03 07:07:06 2005 (link)
Hi, We are doing a community web site for hikers (kind of hiking blog portal). Development is "user-driven". Some users asked to add GPX upload to the site, so we added the possibility to share GPX files (using application/xml-gpx mime type for the download, is this right?) Now, what other useful/cool things it is possible to do with gpx on the web site? We can see those: display distance, height gain/loss, time, height/time profile, draw some kind of "map". Something else? It is possible to display it on google maps for example? Are there somme browser plugins to show maps? Any idea welcome! Thanks, Stan
chris.lawless+worktech.com on Mon Oct 03 11:27:51 2005 (link)
Just a quickie, I haven't really fully comprehended all the ISO 8601 time date formatting stuff. Can someone give me a quick pointer as to what I should be using in my GPX file? For example it is currently October 3rd 2005 2:24PM EST here in Boston. My GPS returns a time of 10/3/2005 2:25:18 PM (I guess it knows where I am, clever huh!). So in ISO format what should I write? 2005-10-03T14:25:18.000 ? Should I be converting to Zulu time maybe? Should the GPS be able to tell me the time zone I am in? Thanks for any help you can offer. Chris.
robertlipe+usa.net on Mon Oct 03 12:18:53 2005 (link), replying to msg
> For example it is currently October 3rd 2005 2:24PM EST here in Boston. > My GPS returns a time of 10/3/2005 2:25:18 PM (I guess it knows where I > am, clever huh!). > > So in ISO format what should I write? > [ ... ] > 2005-10-03T14:25:18.000 ? Should I be converting to Zulu time maybe? There are about a bazillion variations you _can_ use. But I don't think your example is one you'd want to use as it would read "wrong" on a system in a different TZ than you. Boston MA is GMT-4 for another few weeks since your area observes DST. Soon you will be GMT-5. Exhibit A is: http://wwp.greenwichmeantime.com/time-zone/usa/massachusetts/index.htm Thus you could use local time, but you have to specify the TZ: <time>2005-10-03T14:14:18.000-05:00</time> You could adjust the time to some _other_ timezone, as long as you specify the correct offset. For example, we could teleport you to Silicon Valley: <time>2005-10-03T10:25:18.000-09:00</time> Stylistically, I prefer busting everything to GMT: <time>2005-10-03T19:25:18.000Z</time> Your GPX reader needs to handle these and the other bazillion variants. As a developer tip, you'll make yourself _far_ less crazy if you store everything internally as GMT and convert to/from localtime on the way in and out of your program. > Should the GPS be able to tell me the time zone I am in? Most GPSes (at least handhelds) know what timezone you're in only becuase the user told them. The rules about which counties do or don't observe DST and TZ boundaries and such just aren't encoded in most units. You tell them the hour and they'll take it from there.[1] RJL [1] Well, except for one certain brand that keeps time like a $2 watch...
chris.lawless+worktech.com on Mon Oct 03 12:24:05 2005 (link)
That's great Robert, thanks for the tips. I think my GPS is fine but the Delphi component I'm using to talk to it seems abit troublesome right now, it does a great job of telling me the time just not the time zone, so it's making it kind of hard to handle right now. I'll keep researching! Chris. -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Robert Lipe Sent: Monday, October 03, 2005 3:18 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Date/Time in a GPX File > For example it is currently October 3rd 2005 2:24PM EST here in Boston. > My GPS returns a time of 10/3/2005 2:25:18 PM (I guess it knows where I > am, clever huh!). > > So in ISO format what should I write? > [ ... ] > 2005-10-03T14:25:18.000 ? Should I be converting to Zulu time maybe? There are about a bazillion variations you _can_ use. But I don't think your example is one you'd want to use as it would read "wrong" on a system in a different TZ than you. Boston MA is GMT-4 for another few weeks since your area observes DST. Soon you will be GMT-5. Exhibit A is: http://wwp.greenwichmeantime.com/time-zone/usa/massachusetts/index.htm Thus you could use local time, but you have to specify the TZ: <time>2005-10-03T14:14:18.000-05:00</time> You could adjust the time to some _other_ timezone, as long as you specify the correct offset. For example, we could teleport you to Silicon Valley: <time>2005-10-03T10:25:18.000-09:00</time> Stylistically, I prefer busting everything to GMT: <time>2005-10-03T19:25:18.000Z</time> Your GPX reader needs to handle these and the other bazillion variants. As a developer tip, you'll make yourself _far_ less crazy if you store everything internally as GMT and convert to/from localtime on the way in and out of your program. > Should the GPS be able to tell me the time zone I am in? Most GPSes (at least handhelds) know what timezone you're in only becuase the user told them. The rules about which counties do or don't observe DST and TZ boundaries and such just aren't encoded in most units. You tell them the hour and they'll take it from there.[1] RJL [1] Well, except for one certain brand that keeps time like a $2 watch... Yahoo! Groups Links
martinp13+earthlink.net on Mon Oct 03 12:28:02 2005 (link), replying to msg
--- Robert Lipe <robertlipe+usa.net> wrote: > > Thus you could use local time, but you have to specify the TZ: > > <time>2005-10-03T14:14:18.000-05:00</time> > > You could adjust the time to some _other_ timezone, as long as you > specify > the correct offset. For example, we could teleport you to Silicon > Valley: > > <time>2005-10-03T10:25:18.000-09:00</time> > Wouldn't that teleport them into the ocean? :) -05:00 is ET, but -8:00 is PT. Martin __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
robertlipe+usa.net on Mon Oct 03 12:42:26 2005 (link)
> > For example, we could teleport you to Silicon Valley: > > > > <time>2005-10-03T10:25:18.000-09:00</time> > > > > Wouldn't that teleport them into the ocean? :) -05:00 is ET, but -8:00 > is PT. Into the ocean for you, too! :-) Yes, I screwed up. (I mentally did the math relative to _my_ TZ, not Boston's.) CA is -7/-8 from GMT - never -9.[1] http://wwp.greenwichmeantime.com/time-zone/usa/california/time.htm Hope that typo didn't distract too much from the punchline. RJL [1] Remarks about continental drift and CA succeeding from North America suppressed.
robertlipe+usa.net on Mon Oct 03 13:17:54 2005 (link), replying to msg
> the Delphi component I'm using to talk to it seems abit troublesome > right now, it does a great job of telling me the time just not the > time zone, so it's making it kind of hard to handle right now. > > I'll keep researching! No parlez vous Delphi, but sprechen sie Google. It's fairly common for languages to prefer to expose time in local time and make you take an extra step to get the current timezone relative to GMT. Does http://www.delphi32.com/info_facts/tips/GetTimeZoneInfo.asp solve any problems for you? RJL
chris.lawless+worktech.com on Mon Oct 03 13:23:49 2005 (link)
I can get the time ok from the system and localize it to zulu (or whatever). I had hoped to use the GPS time entirely though just to be thorough. I guess I'll use the time from the GPS maybe then the get the local time zone from the system, probably the best option for now. Thanks for the link! Chris. -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Robert Lipe Sent: Monday, October 03, 2005 3:33 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Date/Time in a GPX File > the Delphi component I'm using to talk to it seems abit troublesome > right now, it does a great job of telling me the time just not the > time zone, so it's making it kind of hard to handle right now. > > I'll keep researching! No parlez vous Delphi, but sprechen sie Google. It's fairly common for languages to prefer to expose time in local time and make you take an extra step to get the current timezone relative to GMT. Does http://www.delphi32.com/info_facts/tips/GetTimeZoneInfo.asp solve any problems for you? RJL Yahoo! Groups Links
robertlipe+usa.net on Mon Oct 03 13:49:58 2005 (link), replying to msg
Chris Lawless wrote: > I can get the time ok from the system and localize it to zulu (or > whatever). I had hoped to use the GPS time entirely though just to be > thorough. All the GPSes that come to immediate mind (i.e. the popular Magellans and Garmins) represent data on the wire or storage device as GMT, I think. > > I guess I'll use the time from the GPS maybe then the get the local time > zone from the system, probably the best option for now. > > Thanks for the link! > > Chris. > > -----Original Message----- > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf > Of Robert Lipe > Sent: Monday, October 03, 2005 3:33 PM > To: gpsxml+yahoogroups.com > Subject: Re: [gpsxml] Date/Time in a GPX File > > > the Delphi component I'm using to talk to it seems abit troublesome > > right now, it does a great job of telling me the time just not the > > time zone, so it's making it kind of hard to handle right now. > > > > I'll keep researching! > > No parlez vous Delphi, but sprechen sie Google. It's fairly common > for languages to prefer to expose time in local time and make you > take an extra step to get the current timezone relative to GMT. > > Does > http://www.delphi32.com/info_facts/tips/GetTimeZoneInfo.asp > solve any problems for you? > > RJL > > > > > Yahoo! Groups Links > > > > > > > > > > > > Yahoo! Groups Links > > > > > >
egroups+topografix.com on Mon Oct 03 13:51:35 2005 (link), replying to msg
Hello, Monday, October 3, 2005, 3:18:23 PM, Robert wrote: >> For example it is currently October 3rd 2005 2:24PM EST here in Boston. >> My GPS returns a time of 10/3/2005 2:25:18 PM (I guess it knows where I >> am, clever huh!). >> >> So in ISO format what should I write? >> [ ... ] >> 2005-10-03T14:25:18.000 ? Should I be converting to Zulu time maybe? R> There are about a bazillion variations you _can_ use. But I don't think R> your example is one you'd want to use as it would read "wrong" on a system R> in a different TZ than you. Didn't we agree way back when that timestamps would always be expressed in Zulu/Greenwich/UTC? The schema just specifies that the timestamp is a valid xsd:dateTime. The xsd-derived documentation states: "Creation/modification timestamp for element. Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs." If we really want to enforce the Zulu-only rule, the correct solution would be to redefine timestamp in the schema so that only the Zulu version of the ISO dateTime base type validates. That's beyond my XML skillz. Anyone want to propose a better schema definition? -- Dan Foster
robertlipe+usa.net on Mon Oct 03 14:32:42 2005 (link), replying to msg
> Didn't we agree way back when that timestamps would always be > expressed in Zulu/Greenwich/UTC? The schema just specifies that the > timestamp is a valid xsd:dateTime. The xsd-derived documentation states: Without looking it up, I think we agreed it was a good idea to encourage the UTC format, but since we deferred to ISO 8601, we didn't disallow the form with the override of TZ that it allows. As you highlighted, the XSD doesn't enforce it; the following validates fine: <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <url>blah</url> <urlname>blah</urlname> <wpt lat="0" lon="0"> <time>2005-10-03T14:25:18.000-05:00</time> </wpt> <wpt lat="0" lon="0"> <time>2005-10-03T10:25:18.000-09:00</time> </wpt> <wpt lat="0" lon="0"> <time>2005-10-03T19:25:18.000Z</time> </wpt> </gpx> > "Creation/modification timestamp for element. Date and time in are in > Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 > specification for date/time representation. Fractional seconds are > allowed for millisecond timing in tracklogs." I like the wording in http://www.w3.org/TR/NOTE-datetime This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. A standard referencing this profile should permit one or both of these ways of handling time zone offsets. If we were to try to tighten anything in the XSD, I'd like to disambiguate the two cases. If you don't have a TZ offset, we should require the Z. This would bust GPX creators that tried to write the above timestamp as <wpt lat="0" lon="0"> <time>2005-10-03T19:25:18.000</time> </wpt> Though that's equivalent to the above three stamps for me (CDT) the absence of the 'Z' tag reduces to one of two probable options and I'd pick "author didn't think about timezones" over "Author was in GMT and special cased the zero offset to save bytes in the output file". (But that borders on legislating taste...) As the GPSBabel guy, I have had to call a few GPX creators on this. RJL
azbithead+gmail.com on Tue Oct 04 14:54:48 2005 (link), replying to msg
> If we really want to enforce the Zulu-only rule, the correct solution > would be to redefine timestamp in the schema so that only the Zulu > version of the ISO dateTime base type validates. That's beyond my XML > skillz. Anyone want to propose a better schema definition? Here's a schema snippet that will only allow UTC times: <xsd:simpleType name="utcDateTimeType"> <xsd:annotation> <xsd:documentation> Represents a date and time in UTC time only. </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:dateTime"> <xsd:pattern value=".+Z"/> </xsd:restriction> </xsd:simpleType> - Steve
gps_maps+travelbygps.com on Thu Oct 06 20:08:13 2005 (link)
Try using http://www.travelbygps.com/premium/SearchTravelByGPS.kmz to geographically search for GPS data at TravelByGPS.com Special thanks to "Cybarber" for developing the utility used for converting my GPX file to this useful KML file. Ref: Google Earth Community > Support > KML Discussions > GPX KML GML XSLT converter http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/132922/an/0/page/1#132922 Enjoy! - Doug
ignacio+hernandez-ros.com on Sat Oct 08 06:50:21 2005 (link)
Hello, During the development of a simple stylesheet to transform KML files to GPX format I realised that there is a minor error in the definition of the emailType type. The minus character "-" is a valid character in a server name. My email address is in a domain with a hypen on it. I reveive a schema validation error because this character is not allowed in the data type. I would appreciate if you update the schema http://www.topografix.com/GPX/1/0/gpx.xsd to add the hyphen "-" character in the email addresses. Regards, IHR <xsd:simpleType name="emailType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[\p{L}_]+(\.[\p{L}_]+)*+[\p{L}_]+(\.[\p{L}_] +)+" /> </xsd:restriction> </xsd:simpleType>
azbithead+gmail.com on Sat Oct 08 10:50:41 2005 (link), replying to msg
I would recommend that you change your project to use the newer 1.1 version of the GPX schema located at http://www.topografix.com/GPX/1/1/gpx.xsd. It does not have the problem you are seeing. - Steve
egroups+topografix.com on Tue Oct 25 08:08:47 2005 (link)
Hello All, There are now 54 programs that support GPX listed at http://www.topografix.com/gpx_resources.asp, as well as several dozen Web sites that accept or provide GPX data. If your program or Web site isn't listed, please drop me a line at the email address at the bottom of the page. -- Dan Foster
gps_maps+travelbygps.com on Tue Nov 01 12:07:20 2005 (link)
I just received word on this and couldn't help telling everyone: My Travel by GPS web site is presently ranked #1, in the "Travel" category for *digging* by Yahoo! Search (yahoo.co.uk/digging) This to me from Yahoo! Search: "Digging is a new social phenomenon where people have a passionate interest and use the web to find items or information on things that are cool or unique. We looked at finding the coolest, most underground sites and putting them in a place that was easy to share with like-minded enthusiasts. Yours was one of them." To see the ranking, visit http://www.digging.yahoo.co.uk/travel.html Special thanks to everyone, including many participating in this group, who have helped make www.TravelByGPS.com a success. - Doug Travel by GPS (tm) Maps Waypoints and Tracks to Adventure
egroups+topografix.com on Tue Nov 01 12:29:11 2005 (link), replying to msg
Hello, Tuesday, November 1, 2005, 3:04:54 PM, Doug wrote: D> I just received word on this and couldn't help telling everyone: D> My Travel by GPS web site is presently ranked #1, in the "Travel" D> category for *digging* by Yahoo! Search (yahoo.co.uk/digging) D> This to me from Yahoo! Search: D> "Digging is a new social phenomenon where people have a passionate D> interest... Is digging the new dogging? /Runs to register www.gpx-dogging.co.uk ... Congrats! -- Dan Foster
kathy_tn189+yahoo.com on Thu Nov 03 19:19:00 2005 (link)
Hello! Do check the website of the week by visiting http://newwebsitepick.info . The website also says how you can nomiate your website if you have one. Regards, Kathy __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
bryce1+obviously.com on Fri Nov 04 15:43:04 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "chachkov" <chachkov+y...> wrote: > Now, what other useful/cool things it is possible to do with gpx on > the web site? We can see those: display distance, height gain/loss, > time, height/time profile, draw some kind of "map". Something else? It > is possible to display it on google maps for example? Are there somme > browser plugins to show maps? Any idea welcome! No plugin needed, just a html file and a gpx file: See http://www.obviously.com/gis/gpx_loader.html
bryce1+obviously.com on Fri Nov 04 16:08:56 2005 (link)
Here's yet another script that can load GPX files, and display them in a Google Map. Feedback or patches are welcome: http://www.obviously.com/gis/gpx_loader.html
ptomblin+gmail.com on Sat Nov 05 07:09:57 2005 (link), replying to msg
On 11/4/05, Bryce Nesbitt <bryce1+obviously.com> wrote: > Here's yet another script that can load GPX files, and display them in > a Google Map. Feedback or patches are welcome: > http://www.obviously.com/gis/gpx_loader.html I tried it with a 914 point GPX 1.1 file showing airports, navaids and waypoints (all as wpt records) in Ontario and Quebec, and it showed me a map of the high arctic. So I scrolled down to where I knew the points were, and none of them were shown. Then I tried the same file on the tom-carden page, and it's been loading for 25 minutes now without showing anything. My file passes SAXCount validation, but it does have my own extensions. Could that be the problem? See http://xcski.com/~ptomblin/gpx_loader.html and http://xcski.com/~ptomblin/gpx_loader.gpx -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
cwilder3+cfl.rr.com on Thu Nov 10 13:55:30 2005 (link)
I am trying to present a point by point playback of my GPX formatted track data so that I can correlate certain events in time with my location at that same time. I am driving my car with my GPS recording position while taking data with another program. I have combined my time data with my GPS track, but since I retrace the route a number of times it is difficult to tell what happened which time I passed a certain location. Is there any software available (free or at cost) that I can use to play the track back at a selected update rate? Thanks for all the help you have provided in your past "musings" in this group. You have helped a total novice get up to speed very quickly with the wonderful world of GPX!
egroups+topografix.com on Fri Nov 11 08:00:48 2005 (link), replying to msg
Hello, Thursday, November 10, 2005, 4:54:12 PM, Christofer wrote: C> I am trying to present a point by point playback of my GPX formatted C> track data C> Is there any software available (free or at cost) C> that I can use to play the track back at a selected update rate? I believe TopoFusion does this. -- Dan Foster
bryce1+obviously.com on Fri Nov 11 10:44:49 2005 (link)
I have two questions: 1) First relates to validating the output of programs that create GPX files. Many of the online XML validation tools require a DOCTYPE. How can these online tools be used? For example: http://www.hcrc.ed.ac.uk/~richard/xml-check.html With url: http://www.topografix.com/fells_loop.gpx Note that I was unable to get SAXCount to work locally. 2) I'd like to write GPX 1.0 files, but the online documentation is all for GPX 1.1. Where can I find complete GPX 1.0 information? Is there any estimate of the percentage of programs that are 1.1 vs. 1.0?
cwilder3+cfl.rr.com on Fri Nov 11 11:03:54 2005 (link), replying to msg
Yes, thanks...I found it and purchased it after a short eval run. --- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Hello, > > Thursday, November 10, 2005, 4:54:12 PM, Christofer wrote: > > C> I am trying to present a point by point playback of my GPX formatted > C> track data > C> Is there any software available (free or at cost) > C> that I can use to play the track back at a selected update rate? > > I believe TopoFusion does this. > > -- > Dan Foster >
robertlipe+usa.net on Fri Nov 11 11:57:53 2005 (link), replying to msg
Bryce Nesbitt wrote: > Note that I was unable to get SAXCount to work locally. Pursue that angle. > 2) I'd like to write GPX 1.0 files, but the online documentation is > all for GPX 1.1. Where can I find complete GPX 1.0 information? http://www.topografix.com/gpx_manual.asp (Which, as an aside, I find a more useful presentation to read than the marked up schema since it describes _intent_ and usage of the tags... For reference the approach taken in 1.1 is nice.) > Is there any estimate of the percentage of programs that are 1.1 > vs. 1.0? I'm sure it varies by market, but I've seen very little GPX 1.1 action in GPSBabel (which defaults to 1.0 for this reason) compared to 1.0 traffic. In the markets that use GPX as "GPS Exchange" instead of "markup/content provider" it's not like there's really that much that you can represent in 1.1 that you can't in 1.0 (even setting aside the whole DOP issues) so there's not been much motivation to change it there... RJL
bryce1+obviously.com on Fri Nov 11 12:33:50 2005 (link), replying to msg
Your GPX file has no <bounds>, so the loader has no idea where to center the map. But I did remove the javascript error this creates, and now your file loads fine. Pick up the new version at. http://www.obviously.com/gis/gpx_loader.html --- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > > On 11/4/05, Bryce Nesbitt <bryce1+o...> wrote: > > Here's yet another script that can load GPX files, and display them in > > a Google Map. Feedback or patches are welcome: > > http://www.obviously.com/gis/gpx_loader.html > > I tried it with a 914 point GPX 1.1 file showing airports, navaids and > waypoints (all as wpt records) in Ontario and Quebec, and it showed me > a map of the high arctic. So I scrolled down to where I knew the > points were, and none of them were shown. > > Then I tried the same file on the tom-carden page, and it's been > loading for 25 minutes now without showing anything. > > My file passes SAXCount validation, but it does have my own > extensions. Could that be the problem? > > See http://xcski.com/~ptomblin/gpx_loader.html and > http://xcski.com/~ptomblin/gpx_loader.gpx
cwilder3+cfl.rr.com on Fri Nov 11 12:53:09 2005 (link)
I have to let you know in advance...I am trying to hack my way through an existing gpx file that I created from a Garmin download. I do NOT know xml at all. That said, I have been trying to set the color of a track by using extensions in my gpx file without success. I have placed a small piece of my track in a file which verifies in SaxCount: <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <gpx xmlns="http://www.topografix.com/GPX/1/1" creator="Me" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <trk> <extensions> <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>008000</color> </line> </extensions> <trkseg> <trkpt lat="51.500113333" lon="-0.141190000"> <ele>26.093014</ele> <time>2005-08-10T17:36:25Z</time> </trkpt> <trkpt lat="51.500187000" lon="-0.141279000"> <ele>26.092896</ele> <time>2005-08-10T17:36:30Z</time> </trkpt> <trkpt lat="51.500642000" lon="-0.141031000"> <ele>21.766968</ele> <time>2005-08-10T17:36:48Z</time> </trkpt> <trkpt lat="51.500965000" lon="-0.140823000"> <ele>22.728271</ele> <time>2005-08-10T17:37:00Z</time> </trkpt> <trkpt lat="51.501010000" lon="-0.140794000"> <ele>21.766968</ele> <time>2005-08-10T17:37:02Z</time> </trkpt> <trkpt lat="51.501139000" lon="-0.140904000"> <ele>21.766968</ele> <time>2005-08-10T17:37:07Z</time> </trkpt> <trkpt lat="51.501247000" lon="-0.141027000"> <ele>19.844360</ele> <time>2005-08-10T17:37:11Z</time> </trkpt> </trkseg> </trk> </gpx> This file displays fine in TopoFusion, Google Earth and Mapsource except they all ignore the color that has bee set by my file! As a matter of fact, the colors shows differently in each program. I have searched all over for examples and have only found one (on this forum) but it doesn't work any differently. What am I doing wrong? Thanks, Chris
yahoo+needham.net on Fri Nov 11 13:13:56 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Christofer Wilder" <cwilder3+c...> wrote: > That said, I have been trying to set the color of a track by using > extensions in my gpx file without success. I have placed a small > piece of my track in a file which verifies in SaxCount: I am no expert yet in GPX either, but for routes this seems to work in the programs I've tried it in: <rte> <extensions><gpx_style:color>0000FF</gpx_style:color></extensions> ... </rte> Marcus Needham, President and CEO, Mountain Dynamics Inc. Makers of SnowRanger? Ski Resort Maps for Garmin� GPS www.mountaindynamics.com marcus+mountaindynamics.com 520-319-1720
cwilder3+cfl.rr.com on Fri Nov 11 13:28:02 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Mappicus" <yahoo+n...> wrote: > > --- In gpsxml+yahoogroups.com, "Christofer Wilder" <cwilder3+c...> wrote: > > That said, I have been trying to set the color of a track by using > > extensions in my gpx file without success. I have placed a small > > piece of my track in a file which verifies in SaxCount: > > I am no expert yet in GPX either, but for routes this seems to work in > the programs I've tried it in: > > <rte> > <extensions><gpx_style:color>0000FF</gpx_style:color></extensions> > ... > </rte> > > Marcus Needham, President and CEO, Mountain Dynamics Inc. > Makers of SnowRanger? Ski Resort Maps for Garmin� GPS > www.mountaindynamics.com marcus+m... 520-319-1720 > Thanks for the response... I tried this and it appears you must be using a different schema style reference in your file. I get an error upon verification that says "...the prefix gpx_style has not been mapped to any URI". I don't see that Type defined in the GPX schema on topografix.com. Could you show me the header you use in your files that successfully control color this way? Thanks again, Chris
yahoo+needham.net on Fri Nov 11 14:11:22 2005 (link), replying to msg
> I tried this and it appears you must be using a different schema > style reference in your file. I get an error upon verification that > says "...the prefix gpx_style has not been mapped to any URI". I > don't see that Type defined in the GPX schema on topografix.com. > > Could you show me the header you use in your files that successfully > control color this way? Actually I take that back--the GPX file with this in it can be opened (with colored routes) in ExpertGPS, but Google Earth ignores the color, and Mapsource won't even open the file. I am using the headers that reference http://www.topografix.com/GPX/Private, per some of the examples in http://www.topografix.com/gpx_sample_files.asp, which is why ExpertGPS probably likes it.
cwilder3+cfl.rr.com on Fri Nov 11 14:29:44 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Mappicus" <yahoo+n...> wrote: > > > I tried this and it appears you must be using a different schema > > style reference in your file. I get an error upon verification that > > says "...the prefix gpx_style has not been mapped to any URI". I > > don't see that Type defined in the GPX schema on topografix.com. > > > > Could you show me the header you use in your files that successfully > > control color this way? > > Actually I take that back--the GPX file with this in it can be opened > (with colored routes) in ExpertGPS, but Google Earth ignores the > color, and Mapsource won't even open the file. > > I am using the headers that reference > http://www.topografix.com/GPX/Private, per some of the examples in > http://www.topografix.com/gpx_sample_files.asp, which is why ExpertGPS > probably likes it. > Maybe someone knows how to get this to work in TF? :-) I can't buy another program :-) Thanks for the help though...
egroups+topografix.com on Fri Nov 11 14:34:22 2005 (link), replying to msg
Hello, Friday, November 11, 2005, 5:11:15 PM, Mappicus wrote: M> Actually I take that back--the GPX file with this in it can be opened M> (with colored routes) in ExpertGPS, but Google Earth ignores the M> color, and Mapsource won't even open the file. M> I am using the headers that reference M> http://www.topografix.com/GPX/Private, per some of the examples in M> http://www.topografix.com/gpx_sample_files.asp, which is why ExpertGPS M> probably likes it. If you are testing with ExpertGPS, you should switch to the preview version of ExpertGPS 2.0, http://www.expertgps.com/beta.asp, which behaves differently than ExpertGPS 1.3.7. It uses the GPX 1.1 schema (correctly - 1.3.7 contains some errors). It reads and writes the <gpx_style:color> attribute, however, the <color> in the GPX file is not always honored. In ExpertGPS 2.0, all of the "style" attributes (color, line width, dash pattern) are part of the overall "type" of the object. So a track with type "Expert Ski Trail" might have a black, dashed line, and a track with type "Beginner Ski Trail" might have a green, dashed line. ExpertGPS 2.0 keeps an internal "style library", and if your GPX file contains a type that already exists in ExpertGPS, your file's style is ignored (by default). I mention this so you don't go nuts wondering why your validating GPX 1.1 file looks different in ExpertGPS 2.0. Dave Wissenbach's Map3D program also reads and displays GPX 1.1 style information, I believe. Other programs may just ignore it. -- Dan Foster
bbalxx+yahoo.com on Fri Nov 11 14:38:55 2005 (link)
hello, I am new to this forum, an in the process of configuring a server. I have noticed many ISP's serve up .xml files, though my current ISP does not serve up .gpx files. To configure Apache, what is the proper MIME type which should be used to serve .gpx files? thanks, brian.
cwilder3+cfl.rr.com on Fri Nov 11 14:40:45 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Hello, > > Friday, November 11, 2005, 5:11:15 PM, Mappicus wrote: > > M> Actually I take that back--the GPX file with this in it can be opened > M> (with colored routes) in ExpertGPS, but Google Earth ignores the > M> color, and Mapsource won't even open the file. > > M> I am using the headers that reference > M> http://www.topografix.com/GPX/Private, per some of the examples in > M> http://www.topografix.com/gpx_sample_files.asp, which is why ExpertGPS > M> probably likes it. > > If you are testing with ExpertGPS, you should switch to the preview > version of ExpertGPS 2.0, http://www.expertgps.com/beta.asp, which > behaves differently than ExpertGPS 1.3.7. It uses the GPX 1.1 schema > (correctly - 1.3.7 contains some errors). It reads and writes the > <gpx_style:color> attribute, however, the <color> in the GPX file is > not always honored. > > In ExpertGPS 2.0, all of the "style" attributes (color, line width, > dash pattern) are part of the overall "type" of the object. So a > track with type "Expert Ski Trail" might have a black, dashed line, > and a track with type "Beginner Ski Trail" might have a green, dashed > line. > > ExpertGPS 2.0 keeps an internal "style library", and if your GPX file > contains a type that already exists in ExpertGPS, your file's style is > ignored (by default). > > I mention this so you don't go nuts wondering why your validating GPX > 1.1 file looks different in ExpertGPS 2.0. Dave Wissenbach's Map3D > program also reads and displays GPX 1.1 style information, I believe. > Other programs may just ignore it. > > -- > Dan Foster > Any tips on TopoFusion,and how it works with colors? Is it the same as ExpertGPS?
cybarber+gmail.com on Sat Nov 12 03:42:52 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Bryce Nesbitt" <bryce1+o...> wrote: > > I have two questions: > > 1) First relates to validating the output of programs that create GPX > files. Many of the online XML validation tools require a DOCTYPE. > How can these online tools be used? > > For example: > http://www.hcrc.ed.ac.uk/~richard/xml-check.html > With url: > http://www.topografix.com/fells_loop.gpx Here is above file converted to GPX v1.1 (and from 1.0 and 1.1 to a Google Earth kmz(kml) files) with below mentioned XSLT gui: http://members.home.nl/cybarber/geomatters/fells_loopv11.gpx http://members.home.nl/cybarber/geomatters/fells_loopGPXv10toKML.kmz http://members.home.nl/cybarber/geomatters/fells_loopv11GPX2KML.kmz Cybarber > Note that I was unable to get SAXCount to work locally. > > > 2) I'd like to write GPX 1.0 files, but the online documentation is > all for GPX 1.1. Where can I find complete GPX 1.0 information? I have an utility online (Also for download) which can transform (XSLT) a v1.1 to a V1.0 GPX file. The file is validated on transformation. (Besides that you can transform a GPX(either 1.0 or 1.1) to KML (Google Earth) and a Google Earth KML file to GPX 1.1 etc. See post at Google Earth/Keyhole BBS: http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/132922/an/0/ page/1#132922 Tha reads: (sep 28) Finally, I have more or less a Windows/Internet Explorer (sorry, Firefox and Mac adepts) GUI ready as an HTA Application to XSLT- transform the following formats: GPX v1.0 to GPX v1.1 (with GPX Schema validation) GPX v1.1 to GPX v1.0 (with GPX Schema validation) GPX to KML (Stylesheets handles both GPX 1.0 and 1.1) KML to GPX v1.1 ((with GPX Schema validation) GML v2.1 Polygon-Geometry to KML Some of the draft transformation sheets are really dirty and I have to do quite a lot of cleaning up before posting the final versions. The GUI(also dirty in draft) allows the user to brows to the input file and from a select box one of the above mentioned XSLT transformation sheets can be selected. The application tests for the presence of MSXML 3.0, 4.0 or 5.0(office2003 users). An HTA application has a low security level and allows writing to disc. Best would be to download Gui and use it from Local disc. With the final version I will make a zip file with the GUI and support files. Draft XSLT sheets: Update October1st: added robogeo.xml transformation: robogeoXML to KML http://members.home.nl/cybarber/geomatters/KML2GPXpull.xslt http://members.home.nl/cybarber/geomatters/GPX2KML.xslt http://members.home.nl/cybarber/geomatters/gpx10to11.xslt http://members.home.nl/cybarber/geomatters/gpx11to10.xslt GML2KML ( a bit dirty) Update Sept 28: Online GUI: http://members.home.nl/cybarber/geomatters/KmlGpxGmlTransform.hta Application (IE only!) (Browser security setting may influence the usage from the website, so better download below kmlgpxgml.zip file. (Note that the transformed files are saved by default to root of C:\\) I just tested the online GUI with the 3.7 mb(local disc browsed) World Borders.gml file and it made a perfect transformation online to a 930 kb World Borders KML file to my C drive. A 1.1mB zipped (unzipped 3.7mb) GML polygon format world map for transforming test to KML: World Borders.zip The resulting KML world map after transformation: World Borders.kmz Allthough not all in final version below links to zip file with all above XSLT sheets GUI hta with some supporting images and sound files for fun: http://members.home.nl/cybarber/geomatters/kmlgpxgml.zip(228kb) I need to update the zip file with the latest stylesheets but the GPX 1.0 to 1.1 and 1.1 to 1.0 are final versions. >Is > there any estimate of the percentage of programs that are 1.1 vs. 1.0? >
gpsxml+yahoogroups.com on Sat Nov 12 09:43:21 2005 (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 : /XSLT transformation Sheets/gpx11to10.xslt Uploaded by : cybarber <cybarber+gmail.com> Description : Transforms GPXv1.1 to v1.0 You can access this file at the URL: http://groups.yahoo.com/group/gpsxml/files/XSLT%20transformation%20Sheets/gpx11to10.xslt To learn more about file sharing for your group, please visit: http://help.yahoo.com/help/us/groups/files Regards, cybarber <cybarber+gmail.com>
gpsxml+yahoogroups.com on Sat Nov 12 09:44:16 2005 (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 : /XSLT transformation Sheets/gpx10to11.xslt Uploaded by : cybarber <cybarber+gmail.com> Description : Transforms GPX v1.0 to v1.1 You can access this file at the URL: http://groups.yahoo.com/group/gpsxml/files/XSLT%20transformation%20Sheets/gpx10to11.xslt To learn more about file sharing for your group, please visit: http://help.yahoo.com/help/us/groups/files Regards, cybarber <cybarber+gmail.com>
gps_maps+travelbygps.com on Fri Nov 18 10:01:28 2005 (link)
Anyone have an idea when I'll be able to specify a area (i.e. fire perimeter, avelanch area, crime zone, parcel...) in GPS and transfer that map data to Garmin handheld reciever. - Doug www.TravelByGPS.com Travel by GPS (tm) Maps Waypoints and Tracks to Adventure
gps_maps+travelbygps.com on Fri Nov 18 10:04:01 2005 (link), replying to msg
--- I wrote: > ...in GPS and transfer that map data to Garmin... I ment to write "GPX" instead of "GPS"> - Doug
yahoo+markwigmore.co.uk on Mon Nov 28 04:49:27 2005 (link)
Sorry for the neophitic question, but I've come across a GPX file where all the stuff between the tags is wrapped like this: <time><![CDATA[2005-11-09T10:24:32Z]]></time> What does this mean please? Mark
doolaard+gmail.com on Mon Nov 28 04:58:01 2005 (link), replying to msg
Hi Mark, CDATA is a construction for xml files. normally when an xml file is parsed and all data is interpreted by the software that handles the xml (for instance Google Earth). You can use CDATA to prevent this interpretation. This is often used when you want to send xml within xml, but you can place a pieve of software code in it to Jan On 11/28/05, Mark Wigmore <yahoo+markwigmore.co.uk> wrote: > Sorry for the neophitic question, but I've come across a GPX file where > all the stuff between the tags is wrapped like this: > > <time><![CDATA[2005-11-09T10:24:32Z]]></time> > > What does this mean please? > > Mark > > > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
yahoo+markwigmore.co.uk on Mon Nov 28 06:56:17 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > CDATA is a construction for xml files. normally when an xml file is > parsed and all data is interpreted by the software that handles the > xml (for instance Google Earth). You can use CDATA to prevent this > interpretation. This is often used when you want to send xml within > xml, but you can place a pieve of software code in it to This is very strange because useful things like the name of the track also have this CDATA wrapper: <trk> <name><![CDATA[Wednesday 09/11/05]]></name> <type><![CDATA[Track]]></type> <trkseg> <trkpt lat="50.3994066556" lon="-3.5079966545"><ele>4</ele><time><! [CDATA[2005-11-09T10:24:32Z]]></time> </trkpt> <trkpt lat="50.3991116524" lon="-3.5078049978"><ele>0</ele><time><! [CDATA[2005-11-09T10:24:42Z]]></time> </trkpt> The data was recorded on an iPAQ running a program called 'Pocket Navigator' from Memory-Map Inc, then uploaded into Memory-Map OS 2004 edition. Is there another way of exporting the data to GPX without these CDATA elements? Regards, Mark
egroups+topografix.com on Mon Nov 28 07:16:52 2005 (link), replying to msg
Hello, Monday, November 28, 2005, 9:55:48 AM, Mark wrote: M> This is very strange because useful things like the name of the track M> also have this CDATA wrapper: M> <trk> M> <name><![CDATA[Wednesday 09/11/05]]></name> M> <type><![CDATA[Track]]></type> Some programs (earlier versions of mine included) wrap all user-modifiable text strings in CDATA rather than checking for reserved characters (like < and >). This is still valid GPX and XML, but it's not the way CDATA was intended to be used. -- Dan Foster
yahoo+markwigmore.co.uk on Mon Nov 28 07:43:16 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+t...> wrote: > > Some programs (earlier versions of mine included) wrap all > user-modifiable text strings in CDATA rather than checking for > reserved characters (like < and >). The <time> strings are also wrapped in CDATA, which doesn't follow your argument. It would appear from examining the file that ALL non-numeric fields are wrapped in CDATA. > This is still valid GPX and XML, but it's not the way CDATA was > intended to be used. I'm using System::Xml::XmlTextReader which seems to ignore all CDATA fields, so how can you be expected to parse the full GPX data set? Cheers, Mark
doolaard+gmail.com on Mon Nov 28 07:59:06 2005 (link), replying to msg
Mark, the use of CDATA is most of the tiome not necessary. It is the developer of the software and xml structure that decides on that. CDATA is many times not needed. but it doesn't matter, the software that 'processes' the xml nows how to handle it Greetings, Jan On 11/28/05, Mark Wigmore <yahoo+markwigmore.co.uk> wrote: > --- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > > CDATA is a construction for xml files. normally when an xml file is > > parsed and all data is interpreted by the software that handles the > > xml (for instance Google Earth). You can use CDATA to prevent this > > interpretation. This is often used when you want to send xml within > > xml, but you can place a pieve of software code in it to > > This is very strange because useful things like the name of the track > also have this CDATA wrapper: > > <trk> > <name><![CDATA[Wednesday 09/11/05]]></name> > <type><![CDATA[Track]]></type> > <trkseg> > <trkpt lat="50.3994066556" lon="-3.5079966545"><ele>4</ele><time><! > [CDATA[2005-11-09T10:24:32Z]]></time> > </trkpt> > <trkpt lat="50.3991116524" lon="-3.5078049978"><ele>0</ele><time><! > [CDATA[2005-11-09T10:24:42Z]]></time> > </trkpt> > > The data was recorded on an iPAQ running a program called 'Pocket > Navigator' from Memory-Map Inc, then uploaded into Memory-Map OS 2004 > edition. Is there another way of exporting the data to GPX without > these CDATA elements? > > Regards, > > Mark > > > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
egroups+topografix.com on Mon Nov 28 08:24:15 2005 (link), replying to msg
Hello, Monday, November 28, 2005, 10:42:47 AM, Mark wrote: M> The <time> strings are also wrapped in CDATA, which doesn't follow M> your argument. It would appear from examining the file that ALL M> non-numeric fields are wrapped in CDATA. I can't speak for Memory-Map. My older software created a similar output, and I changed it when shown how to do it better. Have you asked them about it? M> I'm using System::Xml::XmlTextReader which seems to ignore all CDATA M> fields, so how can you be expected to parse the full GPX data set? Our parsers are behaving differently, then. I get the following from MSXML: <desc>This is the description</desc> "This is the description" <desc><![CDATA[This is the description]]></desc> "This is the description" <desc>This is <![CDATA[the description]]></desc> "This is " Anyone want to comment on what the correct behavior is? -- Dan Foster
doolaard+gmail.com on Mon Nov 28 08:51:51 2005 (link), replying to msg
This is the behaviour of de XmlTextReader: XmlTextReader.ReadString returns the contents of a node as a string. It concatenates the contents of a node including text , white space and CDATA and returns the concatenated string. This can be differetn from MSXML because this is a different aproach on handling xml GReets, Jan On 11/28/05, Dan Foster <egroups+topografix.com> wrote: > Hello, > > Monday, November 28, 2005, 10:42:47 AM, Mark wrote: > > M> The <time> strings are also wrapped in CDATA, which doesn't follow > M> your argument. It would appear from examining the file that ALL > M> non-numeric fields are wrapped in CDATA. > > I can't speak for Memory-Map. My older software created a similar > output, and I changed it when shown how to do it better. Have you > asked them about it? > > M> I'm using System::Xml::XmlTextReader which seems to ignore all CDATA > M> fields, so how can you be expected to parse the full GPX data set? > > Our parsers are behaving differently, then. I get the following from > MSXML: > > <desc>This is the description</desc> > "This is the description" > > <desc><![CDATA[This is the description]]></desc> > "This is the description" > > <desc>This is <![CDATA[the description]]></desc> > "This is " > > Anyone want to comment on what the correct behavior is? > > -- > Dan Foster > > > > > > Yahoo! Groups Links > > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
robertlipe+usa.net on Mon Nov 28 11:07:01 2005 (link), replying to msg
Dan Foster wrote: > <desc>This is <![CDATA[the description]]></desc> > "This is " > > Anyone want to comment on what the correct behavior is? I'd consider that not correct, Dan. I don't have time to cite W3.org chapter and verse, but I remember looking this up and you can have zero or more cdata's inside any other tag. If you wanted to torment your users for no particularly good reason, you could even write that as: <desc><![CDATA[T]]><![CDATA[h]]><![CDATA[i]]><![CDATA[s]]><![CDATA[ ]]><![CDATA[t]]...> Yeah, that's pretty pathological, but I'm pretty sure that's legal. The expat parser gives multiple callbacks on the edges of the CDATA bounds (it's documented that you have to be prepared to concatenate cdata callbacks for this very reason) but it does parse it and deliver the expected string: (robertl) rjloud:/home/robertl/src/gpsbabel.virgin $ cat /tmp/zzz.gpx <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <wpt lat="35.972033333" lon="-87.134700000"> <name>GCEBB</name> <desc>This is <![CDATA[the description]]></desc> </wpt> </gpx> (robertl) rjloud:/home/robertl/src/gpsbabel.virgin $ ./gpsbabel -i gpx -f /tmp/zzz.gpx 35.972033N 87.134700W GCEBB/This is the description Since we're throwing around internal dirty laundry, you can even see the expat parser handing us data/length pairs on that edge: Breakpoint 1, gpx_cdata (dta=0x0, s=0x903d794 "This is <![CDATA[the description]]></desc>\n</desc>\n</wpt>\n</gpx>\n", len=8) at gpx.c:996 (gdb) x /8c s 0x903d794: 84 'T' 104 'h' 105 'i' 115 's' 32 ' ' 105 'i' 115 's' 32 ' ' (gdb) c Continuing. Breakpoint 1, gpx_cdata (dta=0x0, s=0x903d7a5 "the description]]></desc>\n</desc>\n</wpt>\n</gpx>\n", len=15) at gpx.c:996 996 size_t slen = strlen(cdatastr.mem); (gdb) x /15c s 0x903d7a5: 116 't' 104 'h' 101 'e' 32 ' ' 100 'd' 101 'e' 115 's' 99 'c' 0x903d7ad: 114 'r' 105 'i' 112 'p' 116 't' 105 'i' 111 'o' 110 'n' It's worth disclaiming that I did have a version of GPSBabel somewhere in history that did get this wrong. RJL
egroups+topografix.com on Mon Nov 28 11:55:18 2005 (link), replying to msg
Hello, Monday, November 28, 2005, 1:04:31 PM, Robert wrote: R> Dan Foster wrote: >> <desc>This is <![CDATA[the description]]></desc> >> "This is " >> >> Anyone want to comment on what the correct behavior is? R> I'd consider that not correct, Dan. I don't have time to cite W3.org R> chapter and verse, but I remember looking this up and you can have zero R> or more cdata's inside any other tag. I took another look. This wasn't an MSXML behavior - MSXML was doing exactly what I asked. My code was reading the first text node of the element, making the assumption that there could never be more than one text node. I switched to using "get_text", and it now works as expected. Bring on your pathological GPX files... (Seriously, maybe it's time to put together a test suite of strange-but-legal GPX snippets) -- Dan Foster
mll1013+yahoo.com on Mon Nov 28 12:28:22 2005 (link), replying to msg
Is this still possible? I don't see a way to turn on lat/lon in the turn-by-turn directions from mapsonus. Perhaps there's a back-door trick to getting this to work? --- In gpsxml+yahoogroups.com, "kz6g" <kz6g+y...> wrote: > > Maps on us [www.mapsonus.com]can save turn by turn lat/lon GPS > waypoint data to an html file. It would be great if this could be > converted to gpx for importing into GPS applications like EasyGPS, > ExpertGPS, etc. > I am not a GPX developer, but I know a lot of GPS users would love a > way to import a series of waypoints into a GPS application from an > on-line trip planning application. Mapblast, mapquest, etc., do not > have this functionality. > Thoughts anyone? > > Thanks > KZ6G >
yahoo+markwigmore.co.uk on Tue Nov 29 03:28:10 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > It's worth disclaiming that I did have a version of GPSBabel somewhere > in history that did get this wrong. I've tried the dubious data file with both Google Earth and MapSource and they both fail to read it. I think the error message from GE is connected with a 'babel' of some description.
yahoo+markwigmore.co.uk on Tue Nov 29 04:48:41 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, I wrote: > > I've tried the dubious data file with both Google Earth and MapSource > and they both fail to read it. I think the error message from GE is > connected with a 'babel' of some description. Success! I've made a simple modification to my code and can now read the file. Just needed the CDATA part of this: while( m_reader->NodeType != XmlNodeType::Text && m_reader->NodeType != XmlNodeType::CDATA ) { ... Otherwise it was just going into an infinite loop. Thanks guys for pointing me in the right direction. Mark
robertlipe+usa.net on Tue Nov 29 18:11:30 2005 (link), replying to msg
> R> I'd consider that not correct, Dan. I don't have time to cite W3.org > > I took another look. This wasn't an MSXML behavior - MSXML was doing > exactly what I asked. My code was reading the first text node of the Nice find. I suspected that something like that was the case. It's a really maddening trait of most XML parsers. The problem is that the "obvious" approach works *most of the time* and only fails on various data-dependent patterns. > Bring on your pathological GPX files... > (Seriously, maybe it's time to put together a test suite of > strange-but-legal GPX snippets) I'd support that. Start with my "cdata from hell" example. throw in a mixture of things like mixed encodings, whitespaces, self-closing tags, and we might scare people out of coding their own XML parsers (Programmers sometimes think they want to do this becuase using "real" XML parsers correctly looks hard but it's almost always a mistake.) I'll start the ball rolling with one waypoint expressed four different ways: <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <wpt lat="35.972033333" lon="-87.134700000"> <name>GCEBB</name> <desc>This is <![CDATA[the description with ]]>seven words.</desc> </wpt> <wpt lat="35.972033333" lon="-87.134700000"> <name>GCEBB</name> <desc>Same name as above.</desc> </wpt> <wpt lat= "35.972033333" lon = "-87.134700000" > <name>GCEBB</name> <desc>Same name as above.</desc> </wpt> <wpt lat="35.972033333" lon="-87.134700000"/> </gpx> $ gpsbabel -i gpx -f /tmp/zzz.gpx 35.972033N 87.134700W GCEBB/This is the description with seven words. 35.972033N 87.134700W GCEBB/Same name as above. 35.972033N 87.134700W GCEBB/Same name as above. 35.972033N 87.134700W WPT004/WPT004 GPSBabel will even de-uglify that XML at no extra charge: $ gpsbabel -i gpx -f /tmp/zzz.gpx -o gpx -F - <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <time>2005-11-30T02:08:26Z</time> <bounds minlat="35.972033333" minlon ="-87.134700000" maxlat="35.972033333" maxlon="-87.134700000" /> <wpt lat="35.972033333" lon="-87.134700000"> <name>GCEBB</name> <cmt>This is the description with seven words.</cmt> <desc>This is the description with seven words.</desc> </wpt> <wpt lat="35.972033333" lon="-87.134700000"> <name>GCEBB</name> <cmt>Same name as above.</cmt> <desc>Same name as above.</desc> </wpt> <wpt lat="35.972033333" lon="-87.134700000"> <name>GCEBB</name> <cmt>Same name as above.</cmt> <desc>Same name as above.</desc> </wpt> <wpt lat="35.972033333" lon="-87.134700000"> <name>WPT004</name> <cmt>WPT004</cmt> <desc>WPT004</desc> </wpt> </gpx> We should probably throw in more entity stuff. Geocachers that speak languages other than English tend to exercise much more of of the entity encodings than you'd expect. RJL
robertlipe+usa.net on Tue Nov 29 19:30:29 2005 (link), replying to msg
Mark Wigmore wrote: > --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > > It's worth disclaiming that I did have a version of GPSBabel somewhere > > in history that did get this wrong. > > I've tried the dubious data file with both Google Earth and MapSource > and they both fail to read it. I think the error message from GE is I just fed that horror I posted as an example to Mapsource 6.9.1 and it does indeed get the multiple cdata case wrong. I'll bet they fell for the same trick Dan and I did. GE doesn't seem to read the cmt or desc tags when importing GPX, but if I do the multiple cdata thing in a name tag, it does get correctly parsed. So what it does, it seems to do correctly. RJL
egroups+topografix.com on Wed Nov 30 08:09:32 2005 (link), replying to msg
Hello, Tuesday, November 29, 2005, 9:11:27 PM, Robert wrote: R> I'll start the ball rolling with one waypoint expressed four different R> ways I've created a test suite page at http://www.topografix.com/gpx_test_suite.asp Contributions of gpx files or suggestions of test cases are welcome. Some starters: GPX 1.0 GPX 1.1 GPX 1.0 with private namespace (geocaching?) GPX 1.1 with private namespace GPX 1.1 with gpx_style, gpx_overlay namespaces waypoints with lat/lon in north/south/east/west hemispheres elevation below sea level buffer overrun tests: 1000 character waypoint, comment, description GPX 1.0-style hyperlink GPX 1.1-style hyperlinks (more than one in a single waypoint) Strange formatting: whitespace padding self-closing tags Encodings: mixed "Missing" data: waypoint with no waypoint name route made up of waypoints without names It would also be nice to have a section with example output from each program that produces GPX, with as many fields populated as possible. -- Dan Foster
thomas.landspurg+in-fusio.com on Tue Dec 06 14:54:13 2005 (link)
Hello, What is the best way to provide speed and course with GPX1.1? I've read that it was supported with GPX1.0, but not anymore? What is you're suggestion?
salcedo+yahoo.com on Fri Dec 09 09:16:33 2005 (link), replying to msg
I think course and speed would be calculated values based on two points that include a time element. Course and speed don't really mean anything for a single point. --- In gpsxml+yahoogroups.com, "tomsoft2002" <thomas.landspurg+i...> wrote: > > Hello, > > What is the best way to provide speed and course with GPX1.1? I've > read that it was supported with GPX1.0, but not anymore? > What is you're suggestion? >
ianjdeller+yahoo.com on Thu Dec 15 09:41:06 2005 (link)
Hi I'm very new to GPX and just wondered if someone can give some advice. I have a Database Table recording Vehicle Lat/Long coordinates & Date/Time. I want to use this information with GoogleMaps and wondererd if it might be possible to read and convert the table to GPX format XML document. Anyone got any advice ? Thanks very much - a prize for the most helpfull solution! - thanks Ian
robertlipe+usa.net on Thu Dec 15 09:54:55 2005 (link)
> I have a Database Table recording Vehicle Lat/Long coordinates & > Date/Time. > > I want to use this information with GoogleMaps and wondererd if it > might be possible to read and convert the table to GPX format XML > document. Is your question "can I represent lat, long, date, and time in GPX"? If so, "yes". Or are you looking for a contractor to do the actual conversion? If so, mail me. I have a pretty good toolbox for this kind of thing.
kerry.raymond+gmail.com on Thu Dec 15 20:08:28 2005 (link)
I am new to GPS, but an old hand at information modelling. So, I wonder if anyone can explain to me why ptsegType and ptType are defined but never used in the GPX schema. I had expected to find that trkType would have been defined as a sequence of ptsegTypes, or that trksegType would have been defined a sequence of ptTypes. And why does ptType looks like it should have been a parent type of wptType but isn't? In conceptual terms, a point is just a point, whereas a waypoint is a point of interest that we choose to distinguish by assigning it a name and a description etc. So, I would have expected waypoints to be subtypes of points and hence track segments to be sequences of points (some of which might happen to be waypoints through subtyping). Thanks for any insights anyone can give me on the design of the schema. Kerry
subhro16+rediffmail.com on Tue Dec 20 04:24:29 2005 (link)
� Dear Friends, I'm a Software Developer and assigned a project on GPS device. The objective of our project is to --- When we lose a key, get the actual location of the key from the mobile phone. We have to attach some device (probably some GPS enabled device) to the key. Please advice me what should be the devices and technology in use. Please provide me with the architecture of the project. Let me tell you about our way of thinking. 1. A GPS-GPRS device should be attached to the key-chain. 2. This device continuously updates about its location to a central server database (we yet to know how to do it). 3. A program (written under J2EE technology) will extract positional data from server database). 4. A program (written using J2ME) would run in mobile phone. When user wants this program will hook into the server and get the positional information in his handset. Do you think this architecture would work? We could not find out a suitable device which can extract positional information from the GPS device and update it to our server database in a predetermined frequency. If you have idea about this please let me know. Thank you. Subhro(Software Developer) [Non-text portions of this message have been removed]
gps_maps+travelbygps.com on Tue Dec 20 05:02:41 2005 (link)
One of the frequent questions I get is from folks who try to "Save as..." a .gpx file from my site and end up with the file having a .xml extension. What can I do to keep this from happening to my patrons. - Doug www.travelbygps.com
doolaard+gmail.com on Tue Dec 20 05:45:46 2005 (link), replying to msg
Hello, The architecture will work if implemented, however to find a small gps device combined with a GPRS/GSM module will be impossible 9when size does matter). the hardware will be much bigger than the key so it will be impratical to use. Jan Pieters, Senior software Engineer TJIP Bv On 20 Dec 2005 09:36:39 -0000, subhro roy <subhro16+rediffmail.com> wrote: > > Dear Friends, > I'm a Software Developer and assigned a project on GPS device. > The objective of our project is to --- > When we lose a key, get the actual location of the key from the mobile phone. We have to attach some device (probably some GPS enabled device) to the key. > > Please advice me what should be the devices and technology in use. Please provide me with the architecture of the project. > > Let me tell you about our way of thinking. > 1. A GPS-GPRS device should be attached to the key-chain. > 2. This device continuously updates about its location to a central server database (we yet to know how to do it). > 3. A program (written under J2EE technology) will extract positional data from server database). > 4. A program (written using J2ME) would run in mobile phone. When user wants this program will hook into the server and get the positional information in his handset. > > Do you think this architecture would work? > > We could not find out a suitable device which can extract positional information from the GPS device and update it to our server database in a predetermined frequency. > If you have idea about this please let me know. > Thank you. > > > Subhro(Software Developer) > > > [Non-text portions of this message have been removed] > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
doolaard+gmail.com on Tue Dec 20 05:55:22 2005 (link), replying to msg
Hello, me again there are a number of simple programs that work on a Symbian phone (like the Nokia 660, which I use): AFTrack and GSM Tracker(AspiCore) the both can send the GPS data to a webserver that should process the data (put it in a database or/and show it on a map). Greets, Jan Pieters, Senior software Engineer TJIP Bv On 12/20/05, Jan Pieters <doolaard+gmail.com> wrote: > Hello, > > The architecture will work if implemented, however to find a small gps > device combined with a GPRS/GSM module will be impossible 9when size > does matter). the hardware will be much bigger than the key so it will > be impratical to use. > > Jan Pieters, > Senior software Engineer TJIP Bv > > On 20 Dec 2005 09:36:39 -0000, subhro roy <subhro16+rediffmail.com> wrote: > > > > Dear Friends, > > I'm a Software Developer and assigned a project on GPS device. > > The objective of our project is to --- > > When we lose a key, get the actual location of the key from the mobile phone. We have to attach some device (probably some GPS enabled device) to the key. > > > > Please advice me what should be the devices and technology in use. Please provide me with the architecture of the project. > > > > Let me tell you about our way of thinking. > > 1. A GPS-GPRS device should be attached to the key-chain. > > 2. This device continuously updates about its location to a central server database (we yet to know how to do it). > > 3. A program (written under J2EE technology) will extract positional data from server database). > > 4. A program (written using J2ME) would run in mobile phone. When user wants this program will hook into the server and get the positional information in his handset. > > > > Do you think this architecture would work? > > > > We could not find out a suitable device which can extract positional information from the GPS device and update it to our server database in a predetermined frequency. > > If you have idea about this please let me know. > > Thank you. > > > > > > Subhro(Software Developer) > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > -- > Wil je stap voor stap van je schulden af komen? > Kijk dan op www.schuldenvrij.com > > J.K. Pieters > tel : +31 6 1850 1847 > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
yahoo+needham.net on Tue Dec 20 15:01:51 2005 (link)
Can anyone point me to an algorithm for deciding whether any points in a GPX track log ought to be discarded as being "bad"? I am talking about those spurious readings one's GPS takes every so often (due to reduction in signal or whatever) that are a few hundred yards off the real track. I am putting together some web based track visualization tools, and these points really mess up a map overlay or a speed graph. I imagine it can be done based on whether their distance from their adjacent points is unsually high, or something along those lines, but I'd rather not reinvent the wheel if anyone knows of a published method. Thanks.
lisah2u+gmail.com on Wed Dec 21 04:18:14 2005 (link), replying to msg
How about removing any segment that is less than 10 track points as a quick-and-dirty method? Lisa On 12/20/05, Mappicus <yahoo+needham.net> wrote: > Can anyone point me to an algorithm for deciding whether any points in > a GPX track log ought to be discarded as being "bad"? I am talking > about those spurious readings one's GPS takes every so often (due to > reduction in signal or whatever) that are a few hundred yards off the > real track. > > I am putting together some web based track visualization tools, and > these points really mess up a map overlay or a speed graph. I imagine > it can be done based on whether their distance from their adjacent > points is unsually high, or something along those lines, but I'd > rather not reinvent the wheel if anyone knows of a published method. > > Thanks. > > > > > > ________________________________ > YAHOO! GROUPS LINKS > > > Visit your group "gpsxml" on the web. > > 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. > > ________________________________ > -- Lisa Harper Mid-Atlantic D.O.G.S. - http://www.midatlanticdogs.org Personal website - http://www.lisaharper.org Mobile Video on the Go - http://movogo.blogspot.com
salcedo+yahoo.com on Wed Dec 21 09:38:43 2005 (link), replying to msg
Hi Doug, I was going to try this out, to see if I could help. I know I've seen the problem that you are talking about, but now I'm not having it. To test this I created a small HTML file on my local hard drive that has a link to a gpx file. I was able to save the file to another directory on my hard drive, and neither IE nor Firefox added the .xml extension. It may be that they've fixed this issue in version of IE that I'm currently using (6.0.2800.1106.xpsp2.050301-1526). It may also be that the problem does not happen because the file is on my local hard drive. Do you have a sample link on the web that we could test with? -Ricardo --- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+t...> wrote: > > One of the frequent questions I get is from folks who try to "Save > as..." a .gpx file from my site and end up with the file having a .xml > extension. > What can I do to keep this from happening to my patrons. > - Doug > www.travelbygps.com >
gps_maps+travelbygps.com on Wed Dec 21 12:24:30 2005 (link), replying to msg
--- "Ricardo" wrote: > > Hi Doug, > Do you have a sample link on the web that we > could test with? Thanks for your reply Ricardo. The incident that prompted this query was email I recieved from a patron trying to open the .gpx file associated with my Everglades data. Ref: http://www.travelbygps.com/premium/everglades/salt.php The text of patrons complain is pasted below. I emailed him and told him to try striping the .xml off the file name. (He said the file was saved as .gpx but he may have had his preferences set to not show file type extnesions. At any rate he never worte me back saying that didn't work. Based on what you've said, Ricardo, next time I'll ask what browser and version they are using. Thanks again, Doug www.travelbygps.com <snip> I am trying to download the Travel by GPS map for the 10,000 Islands area of the Everglades but am unable to do so. I've downloaded the EasyGPS program and have it running, but whenever I click on the "free GPS map" link, I am taken to another website http://www.travelbygps.com/premium/everglades/everglades.gpx The message at the top reads: "This XML file does not appear to have any style information associated with it. The document tree is shown below." I have saved this page (as "everglades.gpx", an "XML Document"), but then am unable to open it with the EasyGPS program. Am I doing something wrong? Sorry to trouble you, but will appreciate whatever assistance you can give. cheers, <snip>
ptomblin+gmail.com on Wed Dec 21 17:20:15 2005 (link), replying to msg
On 12/20/05, Doug Adomatis <gps_maps+travelbygps.com> wrote: > > One of the frequent questions I get is from folks who try to "Save > as..." a .gpx file from my site and end up with the file having a .xml > extension. > What can I do to keep this from happening to my patrons. I've had a user complaining about this, and he was using Safari (the Mac OS X default browser). I changed the mime type of the download from text/xml to application/octet-stream, and the problem seems to have gone away. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt [Non-text portions of this message have been removed]
gps_maps+travelbygps.com on Thu Dec 22 03:09:56 2005 (link), replying to msg
--- In Paul Tomblin wrote: > I changed the mime type of the download from text/xml to > application/octet-stream, and the problem seems to have gone away. I vaguely remember prior discussion of this. And now that you all have prompted me to check, I have: User Defined Mime Types application/xml .gpx Which clearly, me the "User", has set, but doesn't exaclty match what Paul has. I have not clue what an "octet-stream" is, so I hesitate to change. Anyone offer to clear these muddy waters for me? - Doug
ptomblin+gmail.com on Thu Dec 22 04:21:26 2005 (link), replying to msg
On 12/22/05, Doug Adomatis <gps_maps+travelbygps.com> wrote: > --- In Paul Tomblin wrote: > > > I changed the mime type of the download from text/xml to > > application/octet-stream, and the problem seems to have gone away. > > I vaguely remember prior discussion of this. And now that you all > have prompted me to check, I have: > > User Defined Mime Types > application/xml .gpx application/octet-stream is what your web server is supposed to serve up as the mime type when it just wants your browser to treat it as a binary file (aka a stream of bytes). The problem is that Microsoft, in their arrogance, think that the browser knows better than the server what type of file the server is sending them, so IE will often ignore the mime type and key off the file extension instead. So setting the correct mime type on the server is no guarantee that the user will get what they want. But in cases like that, I tell people to switch to Firefox. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
yahoo+needham.net on Thu Dec 22 07:20:34 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+g...> wrote: > The problem is that Microsoft, in their arrogance, think that the > browser knows better than the server what type of file the server is > sending them, so IE will often ignore the mime type and key off the > file extension instead. So setting the correct mime type on the > server is no guarantee that the user will get what they want. But in > cases like that, I tell people to switch to Firefox. I am not seeing this happen though in this case, indeed I am seeing IE behaviour as being more useful. When I try Doug's site in Firefox and IE, both of them see the GPX downloads as being XML (per the MIME type) and show it as formatted XML. But when I do Save As in Firefox it wants to use .xml as the extension, per Doug's original problem, while IE retains the .gpx. In this case at least, IE's behaviour seems best. But I do concur that setting the MIME type to application/octet-stream is a good fix, since I don't think you'd want the browser to display the formatted XML anyway. Ideally it will proceed straight to the "download as" step and then open the downloaded file in your default tool for GPX files. Montjoux
gps_maps+travelbygps.com on Thu Dec 22 12:11:33 2005 (link), replying to msg
--- "Mappicus" wrote: > When I try Doug's site in Firefox and > IE, both of them see the GPX downloads as being XML (per the MIME > type) and show it as formatted XML. But when I do Save As in Firefox > it wants to use .xml as the extension, per Doug's original problem, > while IE retains the .gpx. In this case at least, IE's behaviour > seems best. Montjoux, Paul, Thanks for taking the time to look at this. I have changed my User Defined Mime Types application/octet-stream .gpx It seems that this will be better than what I had before. Best Regards to this group. - Doug
k.raymond+qut.edu.au on Thu Dec 22 16:17:56 2005 (link), replying to msg
> I imagine > it can be done based on whether their distance from their adjacent > points is unsually high, or something along those lines, but I'd > rather not reinvent the wheel if anyone knows of a published method. I'm not familiar with the literature, so can't advise you there. But if you are writing your own algorithm, and if your track data still contains the time of the observations (i.e. it hasn't already been stripped out), then I would suggest that you do calculations of the speed between successive points. That is, to get from the "true" track to the bad point and back to the "true" track will show a big increase in speed compared to the speed when you are observing on the "true" track. So localised spikes in the speed are probably indicators of bad points. So, if you calculate the speed between each pair of points, then you can probably eliminate any point that suddenly increases the speed a certain percentage P above the weighted average speed over the previous N pairs of points. I think you need a weighted average so that more recent points have greater impact as the person/vehicle may be accelerating. Of course, you have to take into account any knowledge you have of the normal speed profile of the person/vehicle making the track in deciding how sensitive to set the thresholds for declaring a point to be "bad". Given that your aim is to get a nice display, I would suggest you just use trial and error until you are happy with the display. Kerry
yahoo+needham.net on Fri Dec 23 10:11:10 2005 (link), replying to msg
--- In gpsxml+yahoogroups.com, "kr_afol" <k.raymond+q...> wrote: > I'm not familiar with the literature, so can't advise you there. But > if you are writing your own algorithm, and if your track data still > contains the time of the observations (i.e. it hasn't already been > stripped out), then I would suggest that you do calculations of the > speed between successive points. Good ideas thanks. I do have timestamps, or at least I do for tracks that I have any hope of grooming the data for. > That is, to get from the "true" track to the bad point and back to > the "true" track will show a big increase in speed compared to the > speed when you are observing on the "true" track. So localised > spikes in the speed are probably indicators of bad points. So, if > you calculate the speed between each pair of points, then you can > probably eliminate any point that suddenly increases the speed a > certain percentage P above the weighted average speed over the > previous N pairs of points. I think you need a weighted average so > that more recent points have greater impact as the person/vehicle > may be accelerating. In this case these are skier tracks. A skier may slow or stop fairly rapidly but would not be able increase speed suddenly so I think your approach ought to work and I'll give it a try. ... > Given that your aim is to get a nice display, I would > suggest you just use trial and error until you are happy with the > display. I want the display to be nice for any future uploaded tracks without me having to do any manual inspection of the data, but certainly I can play around with the tracks I have gathered so far. Thanks, Montjoux
saldiase1+yahoo.com on Tue Jan 17 00:52:16 2006 (link)
Hi, I'm doing my first project using a GPS. My question is, there some program that converts NMEA-0183 to GPX?
egroups+topografix.com on Tue Jan 17 06:02:02 2006 (link), replying to msg
Hello, Tuesday, January 17, 2006, 3:47:27 AM, saldiase1 wrote: s> Hi, s> I'm doing my first project using a GPS. My question is, there some s> program that converts NMEA-0183 to GPX? ExpertGPS can import a log file with the .nmea extension and save it as a GPX file. http://www.expertgps.com -- Dan Foster
chris+ainslie.co.za on Tue Jan 17 07:33:19 2006 (link), replying to msg
The following application will do exactly that. I have however limited the number of trackpoints to 500. http://www.ainslie.co.za/gpx.zip (211kb) Chris. Chris Ainslie chris+ainslie.co.za 083 639 1391 Skype: cainslie -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of saldiase1 Sent: 17 January 2006 10:47 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] convert data to GPX Hi, I'm doing my first project using a GPS. My question is, there some program that converts NMEA-0183 to GPX? Yahoo! Groups Links
rich.gibson+gmail.com on Tue Jan 17 12:12:50 2006 (link), replying to msg
gpsbabel is the 'Swiss army chainsaw' of gps format tools. http://www.gpsbabel.org/ It also has no arbitrary limits on functionality. The power is in the command line :-) Assume this data in nmea.txt $GPGGA,000000,3342.800,N,11817.021,W,04,0,0,0.000,M,0.0,M,,*78 $GPGGA,000000,3342.820,N,11816.974,W,04,0,0,0.000,M,0.0,M,,*72 $GPGGA,000000,3342.818,N,11816.901,W,04,0,0,0.000,M,0.0,M,,*7B (and some more records) This command converts to gpx from the command line in Windows, Linux, or OSX: gpsbabel -i nmea -f nmea.txt -o gpx -F outfile.gpx And given a gpx file, this command converts back to nmea. gpsbabel -i gpx -f outfile.gpx -o nmea -F nmea2.txt On 1/17/06, saldiase1 <saldiase1+yahoo.com> wrote: > Hi, > > I'm doing my first project using a GPS. My question is, there some > program that converts NMEA-0183 to GPX? > > > > > > > > Yahoo! Groups Links > > > > > > >
chris+ainslie.co.za on Tue Jan 17 12:40:06 2006 (link), replying to msg
This is true, however, GPSBabel discards the timestamp - this makes the conversion worthless to me. Chris Ainslie chris+ainslie.co.za 083 639 1391 Skype: cainslie From: Rich Gibson <rich.gibson+gmail.com> gpsbabel is the 'Swiss army chainsaw' of gps format tools. http://www.gpsbabel.org/ It also has no arbitrary limits on functionality. The power is in the command line :-) Assume this data in nmea.txt $GPGGA,000000,3342.800,N,11817.021,W,04,0,0,0.000,M,0.0,M,,*78 $GPGGA,000000,3342.820,N,11816.974,W,04,0,0,0.000,M,0.0,M,,*72 $GPGGA,000000,3342.818,N,11816.901,W,04,0,0,0.000,M,0.0,M,,*7B (and some more records) This command converts to gpx from the command line in Windows, Linux, or OSX: gpsbabel -i nmea -f nmea.txt -o gpx -F outfile.gpx And given a gpx file, this command converts back to nmea. gpsbabel -i gpx -f outfile.gpx -o nmea -F nmea2.txt -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Chris Ainslie Sent: 17 January 2006 04:07 PM To: gpsxml+yahoogroups.com Subject: RE: [gpsxml] convert data to GPX The following application will do exactly that. I have however limited the number of trackpoints to 500. http://www.ainslie.co.za/gpx.zip (211kb) Chris. Chris Ainslie chris+ainslie.co.za 083 639 1391 Skype: cainslie -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of saldiase1 Sent: 17 January 2006 10:47 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] convert data to GPX Hi, I'm doing my first project using a GPS. My question is, there some program that converts NMEA-0183 to GPX? Yahoo! Groups Links Yahoo! Groups Links
robertlipe+usa.net on Tue Jan 17 12:54:10 2006 (link), replying to msg
Chris Ainslie wrote: > This is true, however, GPSBabel discards the timestamp - this makes the It may be true on your data, but it's not categorically true. $ gpsbabel -i nmea -f nmea -o gpx -F - | grep time | head <time>2006-01-17T20:49:18Z</time> <time>2004-08-07T03:29:08Z</time> <time>2004-08-07T03:29:09Z</time> <time>2004-08-07T03:29:10Z</time> <time>2004-08-07T03:29:11Z</time> <time>2004-08-07T03:29:12Z</time> <time>2004-08-07T03:29:13Z</time> <time>2004-08-07T03:29:14Z</time> <time>2004-08-07T03:29:15Z</time> <time>2004-08-07T03:29:16Z</time> The date on the first one is wacky becuase we have a GGA (which contains time) without having seen a corresponding sentence that contains a date yet. A carefully worded bug report including sample data to the GPSBabel guys would probably help. RJL
rodwaski+yahoo.com.au on Wed Jan 18 15:39:47 2006 (link)
I am trying to write an application using visual studio 2003 and the GPX schema. Using the 1.0 gpx schema, the schema can be validated fine and I can easily generate a dataset. Using the 1.1 schema the schema returns an error. "the same table (link) cannot be the child in two nested relations". I assume this is a Visual Studio 2003 issue in the schema validatation and now within XML schemas these type of relationships are now allowed. Any advise would be most appreciated Rod
mdoherty+wanadoo.fr on Mon Jan 23 04:46:49 2006 (link)
Hi all, I am creating a web site to distribute co-ordinates for interesting historical buildings in various European cities. I would like to follow the geocaching.com team and standidise on the the Degrees and Digital Minutes format eg N 43� 27.986 E 006� 54.894, as this is the most common format used on GPS units. I would like to distribute the co-ordintate file as a .GPX. So I capture the co-ordinates using TomTom on a HP iPAQ, convert them the OV2 file to GPX using 'the wonderful' GPSBABEL. I import the GPX into Mapsourse which I have set to Lat/Long hddd�mm.mmm (Degrees and Digital minutes). I then save the file to a new GPX file. When I look at the GPX file, it seems to be in the format of hddd.dddd� (Digital Degrees). Do all GPX files get converted into Digital Degrees by default? I also realised that the LOC files distributed by geocaching.com team look like they are in Digital Degrees, even though on their web site there is a general statement announcing that the standard co- ordinate format that they use is Degrees and Digital minutes? Could you possibly clarify this for me please? Many thanks,
avalon73+caerleon.us on Mon Jan 23 05:00:19 2006 (link), replying to msg
You'll probably find that most data storage formats for waypoints use the decimal degrees format. Not only is it the most universal internal format for that kind of thing, it's a LOT easier to parse than any other format you can think of. As far as the other formats, like "hddd mm.mmm", you can convert decimal degrees to those as you want for display. -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator Katz' Law: Man and nations will act rationally when all other possibilities have been exhausted.
doolaard+gmail.com on Mon Jan 23 05:06:49 2006 (link), replying to msg
Hi, I don't know if there is any standard way of using one of the formats. I only know that working with a format like hddd.dddd� because it can be treated as a normal decimal number in software. So any 'standard' that contains geographical coordinates states what format it contains. for GPX the format is defined in its schema: Simple Type: latitudeType Parent type: xsd:decimal (derivation method: restriction) I am not aware of other formats Greetings Jan On 1/23/06, mdoherty850 <mdoherty+wanadoo.fr> wrote: > Hi all, > > I am creating a web site to distribute co-ordinates for interesting > historical buildings in various European cities. > > I would like to follow the geocaching.com team and standidise on the > the Degrees and Digital Minutes format eg N 43� 27.986 E 006� > 54.894, as this is the most common format used on GPS units. > > I would like to distribute the co-ordintate file as a .GPX. > > So I capture the co-ordinates using TomTom on a HP iPAQ, convert > them the OV2 file to GPX using 'the wonderful' GPSBABEL. I import > the GPX into Mapsourse which I have set to Lat/Long hddd�mm.mmm > (Degrees and Digital minutes). I then save the file to a new GPX > file. When I look at the GPX file, it seems to be in the format of > hddd.dddd� (Digital Degrees). Do all GPX files get converted into > Digital Degrees by default? > > I also realised that the LOC files distributed by geocaching.com > team look like they are in Digital Degrees, even though on their web > site there is a general statement announcing that the standard co- > ordinate format that they use is Degrees and Digital minutes? > > Could you possibly clarify this for me please? > > Many thanks, > > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
tigerqt+yahoo.com on Tue Jan 24 05:42:23 2006 (link)
I took the xsd and turned it into C# classes using xsd.exe in Visual Studios 2005. Now, I'm in the process of changing the arrays to generic collections (List<T>). Has anyone else done this or foresee any problem with changing the code to use these new structures? I'm leaving everything else alone. I've even loaded a few gpx files in after changing some of the main arrays to lists and then saved them out and reopened them with no problems. Thanks -G
doolaard+gmail.com on Tue Jan 24 06:40:18 2006 (link), replying to msg
Hi, I am not shure what you want, but there are no difficulties in changing arrays to a Generic collection in c# for .NET 2.0 When you have questions, give me please more details and preferably a piece of code related to your question Grtz, Jan Pieters, Senior Software Engineer On 1/24/06, wvsftwrengr <tigerqt+yahoo.com> wrote: > I took the xsd and turned it into C# classes using xsd.exe in Visual > Studios 2005. Now, I'm in the process of changing the arrays to > generic collections (List<T>). Has anyone else done this or foresee > any problem with changing the code to use these new structures? > > I'm leaving everything else alone. I've even loaded a few gpx files > in after changing some of the main arrays to lists and then saved them > out and reopened them with no problems. > > Thanks > -G > > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
chris+ainslie.co.za on Tue Jan 24 07:19:47 2006 (link), replying to msg
Stolen from another forum: The various formats of giving out a position are all accurate to one degree or another, but there are convincing arguments for using the dd.ddddd format. Let's look at the popular formats is use today. 1 - dd.ddddd (Decimal Degrees) 2 - ddd mm.mmm (Degrees and Decimal Minutes) 3 - ddd mm ss.ss (Degrees, Minutes, Decimal Seconds)
dananderson2+yahoo.com on Tue Jan 24 08:56:17 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Chris Ainslie" <chris+a...> wrote: > > Stolen from another forum: > > The various formats of giving out a position are all accurate to one degree > or another, but there are convincing arguments for using the dd.ddddd > format. > > Let's look at the popular formats is use today. > > 1 - dd.ddddd (Decimal Degrees) > 2 - ddd mm.mmm (Degrees and Decimal Minutes) > 3 - ddd mm ss.ss (Degrees, Minutes, Decimal Seconds) > > From the above, you can already visually see why #1 is better. It's a simple > format that brooks no confusion. > > Communication of positional information is the main reason for using Decimal > Degrees( dd.ddddd ) > > Whether it be verbal, sms, mail, radio communication, written, whatever it > may be, the simplest format to use is #1 [snip] > Then - there is accuracy. > (Yes, you can extend the decimal places out ad infinitum, however, the > GPSr's and software we use typically limits you to the above.) > > 1 - 100,000 units per degree > 2 - 60,000 units per degree > 3 - 36,000 units per degree > > Need I say more? Ok, I will. > On the 26th parallel, 1 degree is 100km > Thus for > 1 - 1 meter is your resolution. > 2 - 1.67 meters is your resolution. > 3 - 2.78 meters is your resolution. > Yes, I know, for a waypoint this is not all that critical. 1 / 0.00001 deg = 100,000 units per degree so # 1 is correct 0.001 min = 0.00001667 deg 1 / 0.0000167 deg = 60,000 units per degree so # 2 is correct 0.01 sec = 0.0001667 min = 0.0000028 deg 1 / 0.0000028 deg = 360,000 units per degree so # 3 is incorrect Or going in the other direction: 0.00001 deg = 0.0006 min (.00001 deg is less than .001 min) = 0.036 sec (.00001 deg is greater than .01 sec) Dan A.
chris+ainslie.co.za on Tue Jan 24 14:52:31 2006 (link), replying to msg
Quite correct, yes. Anyway, I think the point is made, even if the example had an error (an error which helps to prove the point :) 1 / 0.00001 deg = 100,000 units per degree so # 1 is correct 0.001 min = 0.00001667 deg 1 / 0.0000167 deg = 60,000 units per degree so # 2 is correct 0.01 sec = 0.0001667 min = 0.0000028 deg 1 / 0.0000028 deg = 360,000 units per degree so # 3 is incorrect Or going in the other direction: 0.00001 deg = 0.0006 min (.00001 deg is less than .001 min) = 0.036 sec (.00001 deg is greater than .01 sec) Dan A. Yahoo! Groups Links
avalon73+caerleon.us on Tue Jan 24 21:34:49 2006 (link), replying to msg
On Tue, 24 Jan 2006, dananderson2 wrote: > 0.01 sec = 0.0001667 min = 0.0000028 deg > 1 / 0.0000028 deg = 360,000 units per degree so # 3 is incorrect It's correct, though, when related to 95% of the pasted post. At the very beginning, seconds had 2 decimal places in the format listing. All of the examples, though, only had 1 decimal place for seconds. -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator Katz' Law: Man and nations will act rationally when all other possibilities have been exhausted.
salcedo+yahoo.com on Wed Jan 25 09:59:06 2006 (link), replying to msg
Now you've done it. You're going to get all the propellerheads posting now. > Using an arbitrary point > 1 - S26.11351 E27.88223 > 2 - S26 06.811 E27 52.934 > 3 - S26 06 48.6 E27 52 56.0 This example was chosen specifically to prove the point that #1 is more accurate, but it is not in all cases. The fact is the world was divided into degrees, minutes, and seconds. Perhaps not the smartest way to do it, but that's the way it is. I can use another example to show that format 3 is more accurate. Let's you assume that this point truly is: S26 06 48.6 E27 52 56.0 In this case, using format 3 is the most accurate. If you were to display this point using format 2, you get: S26 06.810 E27 52.933 And using format 1 you get: S26.11350 E27.882222 Using format 1 for this point, we are in fact 0.002 seconds away from the the actual position due to rounding. Wheras using format 3 gets us the exact position!
edhall+brillig.com on Wed Jan 25 10:29:12 2006 (link), replying to msg
> Using format 1 for this point, we are in fact 0.002 seconds away from > the the actual position due to rounding. Wheras using format 3 gets us > the exact position! Doesn't 0.002 seconds represent something like an eigth of an inch (or 4 mm) on the Earth's surface? For all intents and purposes, especially given the accuracy of today's GPSRs and how they are used today, that's the same point. -Buxley, Propellerhead Deluxe -- Ed Hall (edhall+brillig.com) http://www.brillig.com/ "There's a hell of a universe next door: let's go!" - e. e. cummings > -----Original Message----- > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] > On Behalf Of Ricardo > Sent: Wednesday, January 25, 2006 9:59 AM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Re: Digital Degrees v Degrees and Digital > Minutes file format > > > Now you've done it. You're going to get all the propellerheads > posting now. > > > Using an arbitrary point > > 1 - S26.11351 E27.88223 > > 2 - S26 06.811 E27 52.934 > > 3 - S26 06 48.6 E27 52 56.0 > > This example was chosen specifically to prove the point that #1 is > more accurate, but it is not in all cases. The fact is the world was > divided into degrees, minutes, and seconds. Perhaps not the smartest > way to do it, but that's the way it is. I can use another example to > show that format 3 is more accurate. Let's you assume that this point > truly is: > > S26 06 48.6 E27 52 56.0 > > In this case, using format 3 is the most accurate. If you were to > display this point using format 2, you get: > > S26 06.810 E27 52.933 > > And using format 1 you get: > > S26.11350 E27.882222 > > Using format 1 for this point, we are in fact 0.002 seconds away from > the the actual position due to rounding. Wheras using format 3 gets us > the exact position! > > > > > > > Yahoo! Groups Links > > > > > >
salcedo+yahoo.com on Wed Jan 25 10:29:57 2006 (link), replying to msg
BTW, I'm not saying that I disagree that using decimal degrees is the best choice, just that it is quite easy to choose an example to support either side of the argument.
salcedo+yahoo.com on Wed Jan 25 11:07:57 2006 (link), replying to msg
LOL! > Doesn't 0.002 seconds represent something like an eigth of an inch (or 4 > mm) on the Earth's surface?
david_z_lawson+yahoo.com on Fri Jan 27 14:38:28 2006 (link)
I'm very new to xml. I downloade fells_loop.gpx and opened it in xmlspy and it tried to validate it but complained that it was invalid. Did I do something wrong? If not, is there .gpx example that I can look at that does validate? thanks, David
egroups+topografix.com on Fri Jan 27 14:43:13 2006 (link), replying to msg
Hello, Friday, January 27, 2006, 5:38:17 PM, david_z_lawson wrote: d> I'm very new to xml. d> I downloade fells_loop.gpx and opened it in xmlspy and it tried to d> validate it but complained that it was invalid. Did I do something d> wrong? If not, is there .gpx example that I can look at that does d> validate? I just checked it again using the SAXCount validation test described at http://www.topografix.com/gpx_validation.asp, and it passes. I don't have experience with xmlspy. -- Dan Foster
friteam+gmail.com on Sun Jan 29 17:00:17 2006 (link)
Hi there, I'm newbie in GIS and just started working on small 'data' server to achieve online/offline vehicles tracking. I know there are many solutions out there to do the same job but I want to do it just for fun.. Here is what I would like to achieve: 1. GPS powered devices could periodically send theirs location (+ elevation, speed etc.) -through GPRS- to my 'data' server or the owner of the GPS powered device could upload (through some external application) recorded raw GPS data to my 'data' server. 2. External applications could periodically contact my 'data' server to receive current location ( + elevation, ...) of GPS powered devices or the external application could request my 'data' server for raw GPS data for certain time period and display them on map. So the flow of data is: GPS powered device -> my 'data' server to store raw GPS data -> external application to display raw GPS data The thing is that I would like the transport fomat of raw GPS data to be based on some kind of standard to achieve better interoperability. I would prefer one transport format between my 'data' server and all external applications so everybody could use his/her favourite application to display the data (if that app doesn't support that format anyone could make a plugin for it). Here is where GPX comes in .. GPX is exhange format of GPS data, but from what I've read GPS data means waypoints, routes and tracks.. I will only have 'raw' GPS data (location, elevation, speed..). And here are my questions: 1) Does it make sense to adhere to GPX schema in transport format of raw GPS data between GPS powered device and my 'data' server? 2) Does it make sense to adhere to GPX schema in transport format of raw GPS data between my 'data' server and external applications? Thanks fo answers.
robertlipe+usa.net on Sun Jan 29 17:19:10 2006 (link), replying to msg
m.kantera wrote: > 1) Does it make sense to adhere to GPX schema in transport format of > raw GPS data between GPS powered device and my 'data' server? This is just presumably a beacon transmitting a position every N seconds, right? If you're not doing any manipulation of the data, have total control on both the producer and the consumer, and don't have any reason to make it much more complicated than lat/lon pairs, what benefit would you stand to gain? > 2) Does it make sense to adhere to GPX schema in transport format of > raw GPS data between my 'data' server and external applications? If you consider it valuable to be able to use commodity software like track analyzers, maps, and such for analyzing those collections of data, you'll likely find this more benefecial. I had some recent experience with this very problem. I used some (yet unfinished) features of GPSBabel to turn the time stamped locations into tracks. GPSBabel's filtering allowed me to easily smooth the tracks to make them a manageable size and "rechunk" them based on time. For example, if two "adjacent" trackpoints are on different days, you probably want to treat them as separate tracks. RJL
doolaard+gmail.com on Mon Jan 30 00:24:37 2006 (link), replying to msg
Hello, I created almost the exact application but i keep it simple. I use the reeived NMEA senteces from my GPS and store them in a database. this is my common and standard format. If i need some different format i either use GPSBabel or write a conversion program myself. Works as a clock. Why transform GPS data you receive to something that uses more memory/idks space!? Greetings Jan On 1/30/06, Robert Lipe <robertlipe+usa.net> wrote: > m.kantera wrote: > > > 1) Does it make sense to adhere to GPX schema in transport format of > > raw GPS data between GPS powered device and my 'data' server? > > This is just presumably a beacon transmitting a position every N > seconds, right? If you're not doing any manipulation of the data, have > total control on both the producer and the consumer, and don't have any > reason to make it much more complicated than lat/lon pairs, what benefit > would you stand to gain? > > > 2) Does it make sense to adhere to GPX schema in transport format of > > raw GPS data between my 'data' server and external applications? > > If you consider it valuable to be able to use commodity software like > track analyzers, maps, and such for analyzing those collections of data, > you'll likely find this more benefecial. > > I had some recent experience with this very problem. I used some (yet > unfinished) features of GPSBabel to turn the time stamped locations > into tracks. GPSBabel's filtering allowed me to easily smooth the > tracks to make them a manageable size and "rechunk" them based on time. > For example, if two "adjacent" trackpoints are on different days, you > probably want to treat them as separate tracks. > > RJL > > > > > Yahoo! Groups Links > > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
friteam+gmail.com on Mon Jan 30 11:58:17 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+u...> wrote: > > m.kantera wrote: > > > 1) Does it make sense to adhere to GPX schema in transport format of > > raw GPS data between GPS powered device and my 'data' server? > > This is just presumably a beacon transmitting a position every N > seconds, right? If you're not doing any manipulation of the data, have > total control on both the producer and the consumer, and don't have any > reason to make it much more complicated than lat/lon pairs, what benefit > would you stand to gain? Well I was thinking of one interface for receveiving data.. no matter if the sender is GPS powered device (online mode) or any other application (offline mode).. the only distinction is in the amount of data: GPS powered devices will be sending data to my server every N seconds, on the other hand other applications could send all of data in one chunk to my server (e.g. upload track log to my server). The data itself would be just lat/long, ele, speed in both cases (or maybe i could add some metadata in offline mode).. And I just want to use some kind of standard transport format for this data. To sum up: offline mode - today anybody can quite easily transform his GPS data to GPX format and so my server could benefit from supporting GPX. online mode - here GPX doesn't play that role, I could came up with my own very lightweigth format but it is really needed? GPX can already hold lat/long, ele etc., so instead of having 2 interfaces on my server (online, offline) I could have just one.. > > 2) Does it make sense to adhere to GPX schema in transport format of > > raw GPS data between my 'data' server and external applications? > > If you consider it valuable to be able to use commodity software like > track analyzers, maps, and such for analyzing those collections of data, > you'll likely find this more benefecial. Yes I consider it valuable so I will use GPX as transport format. Just to be 110% sure: i should use 'track' nodes of GPX to hold my track log data, is that right? i just want to be sure cause i'm really newbie in GPS world. > I had some recent experience with this very problem. I used some (yet > unfinished) features of GPSBabel to turn the time stamped locations > into tracks. GPSBabel's filtering allowed me to easily smooth the > tracks to make them a manageable size and "rechunk" them based on time. > For example, if two "adjacent" trackpoints are on different days, you > probably want to treat them as separate tracks. > > RJL > m.
friteam+gmail.com on Mon Jan 30 14:38:47 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > Hello, > > I created almost the exact application but i keep it simple. I use the > reeived NMEA senteces from my GPS and store them in a database. this > is my common and standard format. If i need some different format i > either use GPSBabel or write a conversion program myself. Works as a > clock. > Why transform GPS data you receive to something that uses more > memory/idks space!? > > Greetings > > Jan > Well from what I've read NMEA is too low-level, not equally supported by all GPS devices and mostly you don't have Time/Position/Velocity in one sentence.. have a look at: http://gpsd.berlios.de/gps-hacking.html http://gpsd.berlios.de/replacing-nmea.html m.
doolaard+gmail.com on Tue Jan 31 00:19:47 2006 (link), replying to msg
This is complete nonsense, almost all data delivered by current gps's use NMEA data to deliver positional data etc... Jan On 1/30/06, m.kantera <friteam+gmail.com> wrote: > --- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > > > Hello, > > > > I created almost the exact application but i keep it simple. I use > the > > reeived NMEA senteces from my GPS and store them in a database. this > > is my common and standard format. If i need some different format i > > either use GPSBabel or write a conversion program myself. Works as a > > clock. > > Why transform GPS data you receive to something that uses more > > memory/idks space!? > > > > Greetings > > > > Jan > > > > Well from what I've read NMEA is too low-level, not equally supported > by all GPS devices and mostly you don't have Time/Position/Velocity in > one sentence.. have a look at: > http://gpsd.berlios.de/gps-hacking.html > http://gpsd.berlios.de/replacing-nmea.html > > m. > > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
friteam+gmail.com on Tue Jan 31 06:13:31 2006 (link), replying to msg
As I understand what I've read, it doesn't mean that current gps's don't deliver data in NMEA.. just some gps's use their own extensions to NMEA/slightly vary in implemenation of sentences in NMEA.. Whether it is true or not it is actually not my point.. what I really want is to have one record/row in DB table that represents Time + Position + Velocity and this data is spread in at least 2 sentences of NMEA (as far as I know) and furthermore contain data which is not needed for me.. so I want to rely on little client app (Pocket PC app / Java app) for gps powered device to format data as I need it. Maybe I'm totally wrong, as I said I'm just beginner, feel free to argue.. m. --- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > This is complete nonsense, almost all data delivered by current gps's > use NMEA data to deliver positional data etc... > > Jan > > On 1/30/06, m.kantera <friteam+g...> wrote: > > --- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > > > > > Hello, > > > > > > I created almost the exact application but i keep it simple. I use > > the > > > reeived NMEA senteces from my GPS and store them in a database. this > > > is my common and standard format. If i need some different format i > > > either use GPSBabel or write a conversion program myself. Works as a > > > clock. > > > Why transform GPS data you receive to something that uses more > > > memory/idks space!? > > > > > > Greetings > > > > > > Jan > > > > > > > Well from what I've read NMEA is too low-level, not equally supported > > by all GPS devices and mostly you don't have Time/Position/ Velocity in > > one sentence.. have a look at: > > http://gpsd.berlios.de/gps-hacking.html > > http://gpsd.berlios.de/replacing-nmea.html > > > > m. > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > -- > Wil je stap voor stap van je schulden af komen? > Kijk dan op www.schuldenvrij.com > > J.K. Pieters > tel : +31 6 1850 1847 >
robertlipe+usa.net on Tue Jan 31 06:22:35 2006 (link)
> don't deliver data in NMEA.. just some gps's use their own extensions > to NMEA/slightly vary in implemenation of sentences in NMEA.. ...as NMEA allows and even encourages. > Whether it is true or not it is actually not my point.. what I really > want is to have one record/row in DB table that represents Time + > Position + Velocity and this data is spread in at least 2 sentences of > NMEA (as far as I know) and furthermore contain data which is not It's true that you probably don't want to store NMEA sentences directly in your database. NMEA was designed to be easy to parse. Certainly any programmer worth their salt can hand the exercise of reading more than one line of ascii text and reducing it to whatever you want. > needed for me.. so I want to rely on little client app (Pocket PC app > / Java app) for gps powered device to format data as I need it. That's far more hardware than needed to parse a few lines every second or two and reduce it to anything you like. Reading NMEA should be a walk in the park. > Maybe I'm totally wrong, as I said I'm just beginner, feel free to > argue.. I'm not sure thist list is the right place to argue about the crunchy goodness of NMEA.
doolaard+gmail.com on Tue Jan 31 06:27:19 2006 (link), replying to msg
The big question is of course where your (GPS) data is coming from. When you use a source that delivers all your required data in one sentence it is easy to extract it and put it in a database. However I am not aware that there is a GPS that is doing this. what equipment are you using? Or do you enter everything by hand? Jan On 1/31/06, m.kantera <friteam+gmail.com> wrote: > As I understand what I've read, it doesn't mean that current gps's > don't deliver data in NMEA.. just some gps's use their own extensions > to NMEA/slightly vary in implemenation of sentences in NMEA.. > > Whether it is true or not it is actually not my point.. what I really > want is to have one record/row in DB table that represents Time + > Position + Velocity and this data is spread in at least 2 sentences of > NMEA (as far as I know) and furthermore contain data which is not > needed for me.. so I want to rely on little client app (Pocket PC app > / Java app) for gps powered device to format data as I need it. > > Maybe I'm totally wrong, as I said I'm just beginner, feel free to > argue.. > > m. > > --- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > > > This is complete nonsense, almost all data delivered by current > gps's > > use NMEA data to deliver positional data etc... > > > > Jan > > > > On 1/30/06, m.kantera <friteam+g...> wrote: > > > --- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > > > > > > > Hello, > > > > > > > > I created almost the exact application but i keep it simple. I > use > > > the > > > > reeived NMEA senteces from my GPS and store them in a database. > this > > > > is my common and standard format. If i need some different > format i > > > > either use GPSBabel or write a conversion program myself. Works > as a > > > > clock. > > > > Why transform GPS data you receive to something that uses more > > > > memory/idks space!? > > > > > > > > Greetings > > > > > > > > Jan > > > > > > > > > > Well from what I've read NMEA is too low-level, not equally > supported > > > by all GPS devices and mostly you don't have Time/Position/ > Velocity in > > > one sentence.. have a look at: > > > http://gpsd.berlios.de/gps-hacking.html > > > http://gpsd.berlios.de/replacing-nmea.html > > > > > > m. > > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Wil je stap voor stap van je schulden af komen? > > Kijk dan op www.schuldenvrij.com > > > > J.K. Pieters > > tel : +31 6 1850 1847 > > > > > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
doolaard+gmail.com on Tue Jan 31 06:32:34 2006 (link), replying to msg
Hi, For making it clear: Every GPs that supports NMEA will send you a so called RMC message: $GPRMC Sentence (Position and time) an example: $GPRMC,092204.999,A,4250.5589,S,14718.5084,E,0.00,89.68,211200,,*25 This sentence contains position and velocity (see the standard for the complete structure) It is really a piece of cake to decompose this sentence in what ewver you want and put it in a database of whatever structure. Jan On 1/31/06, Jan Pieters <doolaard+gmail.com> wrote: > The big question is of course where your (GPS) data is coming from. > When you use a source that delivers all your required data in one > sentence it is easy to extract it and put it in a database. However I > am not aware that there is a GPS that is doing this. what equipment > are you using? Or do you enter everything by hand? > > Jan > > On 1/31/06, m.kantera <friteam+gmail.com> wrote: > > As I understand what I've read, it doesn't mean that current gps's > > don't deliver data in NMEA.. just some gps's use their own extensions > > to NMEA/slightly vary in implemenation of sentences in NMEA.. > > > > Whether it is true or not it is actually not my point.. what I really > > want is to have one record/row in DB table that represents Time + > > Position + Velocity and this data is spread in at least 2 sentences of > > NMEA (as far as I know) and furthermore contain data which is not > > needed for me.. so I want to rely on little client app (Pocket PC app > > / Java app) for gps powered device to format data as I need it. > > > > Maybe I'm totally wrong, as I said I'm just beginner, feel free to > > argue.. > > > > m. > > > > --- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > > > > > This is complete nonsense, almost all data delivered by current > > gps's > > > use NMEA data to deliver positional data etc... > > > > > > Jan > > > > > > On 1/30/06, m.kantera <friteam+g...> wrote: > > > > --- In gpsxml+yahoogroups.com, Jan Pieters <doolaard+g...> wrote: > > > > > > > > > > Hello, > > > > > > > > > > I created almost the exact application but i keep it simple. I > > use > > > > the > > > > > reeived NMEA senteces from my GPS and store them in a database. > > this > > > > > is my common and standard format. If i need some different > > format i > > > > > either use GPSBabel or write a conversion program myself. Works > > as a > > > > > clock. > > > > > Why transform GPS data you receive to something that uses more > > > > > memory/idks space!? > > > > > > > > > > Greetings > > > > > > > > > > Jan > > > > > > > > > > > > > Well from what I've read NMEA is too low-level, not equally > > supported > > > > by all GPS devices and mostly you don't have Time/Position/ > > Velocity in > > > > one sentence.. have a look at: > > > > http://gpsd.berlios.de/gps-hacking.html > > > > http://gpsd.berlios.de/replacing-nmea.html > > > > > > > > m. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Wil je stap voor stap van je schulden af komen? > > > Kijk dan op www.schuldenvrij.com > > > > > > J.K. Pieters > > > tel : +31 6 1850 1847 > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > -- > Wil je stap voor stap van je schulden af komen? > Kijk dan op www.schuldenvrij.com > > J.K. Pieters > tel : +31 6 1850 1847 > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
yahoo+needham.net on Tue Jan 31 13:46:33 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Greg <MtnBiker+l...> wrote: > I clean my tracks by hand by looking at the speeds. Mine are usually > off by miles (and this is walking or biking). I'm not sure this get > rid of all the bad ones, but it gets rid of the one's that mess up > the presentation. Another indicator that this is a good approach that > often (always?) the time and altitude change (I have a Garmin eTrex > Vista which in part a barometer to show the altitude), but the > latitude and longitude are identical. > > It would probably work in my case to eliminate all pairs of adjacent > identical points. Of course it's possible to have identical > positions, but the PGS seems to drift more than that and eliminating > identical tracks wouldn't affect the route presented unless one made > a short jog that was only those two points--unlikely but not impossible. ... > Did you succeed in writing something to clean up the tracks. If so > could you share your results? I'd appreciate a copy. I really haven't time to devote to this yet, but it's still on the to-do list. I've recently done some track "grooming" changes for my site's upload processing code, to divide single multi-day tracks into seperate tracks for each day, since the tracks are uploaded by resort skiers/boarders and each day needs to be shown drawn over the appropriate resort map. Likewise it also puts back together seperate segments of the ACTIVE LOG into a single track during each day too. But I didn't get a chance to play around with detecting the bad points. Mappicus/Montjoux Don't Get Lost - The Gadgets in the Outdoors Blog http://www.mountaindynamics.com/dgl
subhro16+rediffmail.com on Mon Feb 06 22:39:40 2006 (link)
Hi, I would like to receive SMS from my j2me application.But I think it's not possible to listen the default SMS port of the mobile from j2me application(using jsr 120,that is ,Wireless Messeging Api). So only other option is to read the message inbox of the mobile. But how to read the inbox? I would remain thankful to a the person who would help me. Subhro [Non-text portions of this message have been removed]
ghopdata+yahoo.com.au on Fri Feb 10 05:15:28 2006 (link)
I prefer to log my data in UTM and looking through the GPX 1.1 Schema documentation (topographix site)for the first time, I see only mention of lat/long. While obviously I could add a UTM element, I'm a fan of keeping a standard, standard. Can I have your comments on using UTM co-ords in GPX. Thanks!
egroups+topografix.com on Fri Feb 10 05:29:17 2006 (link), replying to msg
Hello, Friday, February 10, 2006, 8:14:23 AM, peter wrote: p> I prefer to log my data in UTM and looking through the GPX 1.1 Schema p> documentation (topografix site)for the first time, I see only p> mention of lat/long. While obviously I could add a UTM element, I'm a p> fan of keeping a standard, standard. p> Can I have your comments on using UTM co-ords in GPX. Yes, don't do it. Having a single format (lat/lon WGS84) for expressing position data is what allows your GPX file to be understood by every GPX-aware program out there. Your program can work natively in whatever format you want, but you must transform it to lat/lon WGS84 when writing GPX. -- Dan Foster
majwar37+yahoo.com on Tue Feb 14 05:24:44 2006 (link)
Hi, I have a large MS Access database with a large amount of locations in germany. The database contains all the fields necessary (lat, long etc.). To visualize these (with EasyGPS), I would like to save the database as a gpx file. Access can create xml files as an output format. Does this help me? Can I convert the Access xml file to gpx? I installed XML Spy, maybe it's suitable for that task? Maybe it is easy, but I'm a newby to xml. Could anybody help me? Thanks a lot. Ralph
oagi-logisti4+un.unhcr.biz on Sun Feb 26 23:41:01 2006 (link)
Hi, First i'm new with GPX. I would like to know if GPX allow to customized the type and the symbol (the display) of waypoints Example : i would like to put a my specific image (whatever the extension) as symbol display on a map, Does it possible ? I have look to expertGPS tool and it only allow to add few symbols. Does anybody can help me ? Thanks, Regards, Pascal
robertlipe+usa.net on Mon Mar 06 09:54:18 2006 (link), replying to msg
gpxuser wrote: > I would like to know if GPX allow to customized the type and the > symbol (the display) of waypoints GPX itself allows just about anything to be in that tag. But the intent isn't for it to be freeform. > Example : i would like to put a my specific image (whatever the > extension) as symbol display on a map, Does it possible ?
lildevil+gpxspinner.com on Mon Mar 06 10:22:11 2006 (link)
> I have look to expertGPS tool and it only allow to add few symbols. ExpertGPS only shows you the symbols that your GPS unit supports. Use the Preferences window to select a different GPS unit and then you will be able to select symbols allowed in that unit. Lil Devil
egroups+topografix.com on Mon Mar 06 10:22:31 2006 (link), replying to msg
Hello, >> Example : i would like to put a my specific image (whatever the >> extension) as symbol display on a map, Does it possible ? R> We do, however, have a reason to believe in the case of ExpertGPS that R> you'll be taken care of. ExpertGPS uses a private extension to the GPX 1.1 schema to include other information about the symbols that ExpertGPS displays on the map. If you have specific requests for symbols that you'd like to see supported in ExpertGPS, contact me off-list at http://www.expertgps.com/support.asp If you want to specify a bitmap symbol for display in any GPX program, there are two problems: 1. few, if any, programs currently support this. 2. there's no standard way to specify this in GPX. You'd need to round up a few application developers and convince them of the need, and then propose an extension to GPX to allow custom map symbology using external bitmap files. (probably an extension to gpx_overlay) -- Dan Foster
subhro16+rediffmail.com on Fri Mar 10 03:37:19 2006 (link)
� Hi, I?ll send the GPS data (latitude and longitude) to a third party server and it?ll return the street address. If any body has any information about a service provider, who can provide this kind of service, Please let me know. Thanking you, Subhro [Non-text portions of this message have been removed]
robertlipe+usa.net on Fri Mar 10 07:18:28 2006 (link), replying to msg
subhro roy wrote: > I?ll send the GPS data (latitude and longitude) to a third party server and it?ll return the street address. > If any body has any information about a service provider, who can provide this kind of service, Please let me know. Not knowing what country of data you're looking for, it's hard to give precise recommendations, but the process you're looking for (hint: google keyword follows) is called "geocoding" and has nothing to do with GPX, really. Many options are discussed in the O Reilley book "Mapping Hacks". RJL
subhro16+rediffmail.com on Fri Mar 10 20:18:08 2006 (link)
� Hi Robert, Thank u for ur suggestion. Actually I'm interested about USA. I've already searched google using geocode,geocode is just the reverse which i want.Geocode maps address to lati longi,but i want lati longi to street level address(I'm interested about USA). Subhro On Fri, 10 Mar 2006 Robert Lipe wrote : >subhro roy wrote: > > > I?ll send the GPS data (latitude and longitude) to a third party server and it?ll return the street address. > > If any body has any information about a service provider, who can provide this kind of service, Please let me know. > >Not knowing what country of data you're looking for, it's hard to give >precise recommendations, but the process you're looking for (hint: >google keyword follows) is called "geocoding" and has nothing to do with >GPX, really. > >Many options are discussed in the O Reilley book "Mapping Hacks". > >RJL > > > > >Yahoo! Groups Links > > > > > > [Non-text portions of this message have been removed]
rich.gibson+gmail.com on Fri Mar 10 20:29:43 2006 (link), replying to msg
Hi Subhro (and Robert :-) You want reverse geocoding. I run geocoder.us, which is regular geocoding. Schuyler and I have frequently thought about doing reverse geocoding. I just created a blog for geocoder.us at http://geocoder.us/blog/ It is really quite ugly still, but that is where I'll announce reverse geocoding capability if/when I get to it. Regards, Rich On 11 Mar 2006 04:16:31 -0000, subhro roy <subhro16+rediffmail.com> wrote: > > Hi Robert, > Thank u for ur suggestion. > Actually I'm interested about USA. > I've already searched google using geocode,geocode is just the > reverse which i want.Geocode maps address to lati longi,but i want lati > longi to street level address(I'm interested about USA). > > > Subhro > > > > > > > On Fri, 10 Mar 2006 Robert Lipe wrote : > > >subhro roy wrote: > > > > > I'll send the GPS data (latitude and longitude) to a third party > server and it'll return the street address. > > > If any body has any information about a service provider, who can > provide this kind of service, Please let me know. > > > >Not knowing what country of data you're looking for, it's hard to give > >precise recommendations, but the process you're looking for (hint: > >google keyword follows) is called "geocoding" and has nothing to do with > >GPX, really. > > > >Many options are discussed in the O Reilley book "Mapping Hacks". > > > >RJL > > > > > > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > ________________________________ > YAHOO! GROUPS LINKS > > > Visit your group "gpsxml" on the web. > > 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. > > ________________________________ >
gpavelic+gmail.com on Sat Mar 11 09:26:46 2006 (link)
I must admit that I didn't have much time to look into general XML issues so this might be a stupid question, sorry if that's the case. I am creating a small GPS log visualizer in VS.NET 2005. I used VS to automaticaly create needed classes for using GPX files using GPX 1.1 schema. The problem is that now I get an error when trying to open a GPX 1.0 file (and most of the sample GPX files found on the Net are 1.0). This is the error: {"<gpx xmlns='http://www.topografix.com/GPX/1/0'> was not expected."} If I change this line in the GPX to "...www.topografix.com/GPX/1/1..." it reads the file OK. Thanks
egroups+topografix.com on Sat Mar 11 10:02:47 2006 (link), replying to msg
Hello, Saturday, March 11, 2006, 12:26:09 PM, Goran wrote: G> I am creating a small GPS log visualizer in VS.NET 2005. I used VS to G> automaticaly create needed classes for using GPX files using GPX 1.1 G> schema. The problem is that now I get an error when trying to open a G> GPX 1.0 file (and most of the sample GPX files found on the Net are 1.0). G> This is the error: G> {"<gpx xmlns='http://www.topografix.com/GPX/1/0'> was not expected."} G> If I change this line in the GPX to "...www.topografix.com/GPX/1/1..." G> it reads the file OK. You could call get_namespaces on the XML document, check whether you have a GPX 1.0 or 1.1 namespace, and then call the appropriate parsing routine. I'm not familiar with VS.NET's automatic class generation, so I can't help you there. -- Dan Foster
kaz+okuda.ca on Sun Mar 12 23:52:54 2006 (link)
Hey all, I'm new to this group and this is my first post. I apologize if anything I'm asking has been discussed before. I have been using the GPX file format since I first got my GPS and started playing with GeoTagging on Photographs. GPX is well defined and well supported and works very well for my work with Google Maps using simple XML parsing in Javascript. I have a project that I've been working on to view GPX files in Google Maps. It shows tracks as lines and waypoints as markers in a Google Map. It is written entirely in Javascript in an AJAX sort of way, so the files can be loaded dynamically without refreshing the page. It is still in early stages of development. More information can be found here... http://notions.okuda.ca/geotagging/projects-im-working-on/gpx-viewer/ <http://notions.okuda.ca/geotagging/projects-im-working-on/gpx-viewer/> The project is relatively straight forward and can easily be extended or modified for many purposes. My original purpose was to use this for displaying GeoTagged Photos. Unfortunately, the GPX file format doesn't explicitly define a good way of doing this so my script recognizes a slightly enhanced content. I have added a <html> tag within a <wpt>. The content is not embedded with a CDATA, but rather it is expected to be valid XML (XHTML). If my script sees this tag in a waypoint it inserts the entire content into the GMap popup window. You can see an example at my link above. I had thought of adding just a photo URL to a waypoint, but decided that wasn't very flexible. By inserting HTML I can format the entire content within the GPX file and it could be used for non-photo content. First question... What do you think of the concept? Second question... What sort of discussions have taken place around HTML content in GPX files. I have seen a couple of discussions about inserting it in existing tags, but that isn't my goal either and I'm not sure I'm in favour of that. I was going for a new tags rather than a modification of existing tags. I don't see any reason why the default tags should be formatted. I just wanted something very specific. My script is pretty simple and I am open to better ways to handle the HTML content. If there is a proposed standard or extension that others are using I would like to hear about them. I designed my system in a vacuum and I would be grateful for any input. [Non-text portions of this message have been removed]
azbithead+gmail.com on Mon Mar 13 18:59:42 2006 (link), replying to msg
> Unfortunately, the GPX file format doesn't > explicitly define a good way of doing this so my script recognizes a > slightly enhanced content. Actually, the GPX schema does define a method for extending its content. It is the <extensions> tag. > I have added a <html> tag within a <wpt>. Adding this tag will cause the GPX file to be invalid according to its schema. As such, other applications will most likely not be able to successfully parse the file. If you don't intend to share your modified GPX files with others then that's OK. > First question... What do you think of the concept? I think it's just fine. > Second question... What sort of discussions have taken place around HTML > content in GPX files. I don't know but I see nothing wrong with placing XHTML (with a proper defining schema) in an <extensions> element. After all, that's what the <extensions> tag is for: extending the GPX schema.
robertlipe+usa.net on Mon Mar 13 21:26:27 2006 (link), replying to msg
Kaz Okuda wrote: > started playing with GeoTagging on Photographs. GPX is well defined and > well supported and works very well for my work with Google Maps using > simple XML parsing in Javascript. Yes, it's called out as such in the recent O Reilly book "Google Mapping Hacks" > I have added a <html> tag within a <wpt>. The content is not embedded > with a CDATA, but rather it is expected to be valid XML (XHTML). If my <extensions> allows you a way to do that, but <html> isn't it. If portability across readers matters to you, please reconsider. > Second question... What sort of discussions have taken place around HTML > content in GPX files. I have seen a couple of discussions about You can see in the archives that there have been several discussions about it. > tags should be formatted. I just wanted something very specific. ...which typically precludes portability amongst readers. RJL
yahoo+markwigmore.co.uk on Wed Mar 15 08:09:57 2006 (link)
My current project has a module for writing data out to a custom XML file and I want to modify it to write GPX. The previous author is no longer around so I'm looking for some guidance for writing GPX that will conform to the Schema. Does anyone have some sample code for doing this please? Cheers, Mark
doolaard+gmail.com on Wed Mar 15 08:31:03 2006 (link), replying to msg
Hi, Maybe I can be of help for you. First of all I understand that you have some data stored. in what form is this data available? can you give me an overview of how your code must work? Jan On 3/15/06, Mark Wigmore <yahoo+markwigmore.co.uk> wrote: > My current project has a module for writing data out to a custom XML > file and I want to modify it to write GPX. The previous author is no > longer around so I'm looking for some guidance for writing GPX that > will conform to the Schema. > > Does anyone have some sample code for doing this please? > > Cheers, Mark > > > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
yahoo+markwigmore.co.uk on Thu Mar 16 08:12:35 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Jan Pieters" <doolaard+...> wrote: > Maybe I can be of help for you. First of all I understand that you > have some data stored. in what form is this data available? can you > give me an overview of how your code must work? I have tracks with lat, long, altitude and time that I'm transferring between two programs. I already have a reader for GPX in one program, I just need a writer for the other. I'm hoping to write valid GPX so the files can be read by any other GPX enabled program. The thing I'm not sure about is all the namespace, schema and other stuff that goes before the data. Can you help? Cheers, Mark
yahoo+markwigmore.co.uk on Thu Mar 16 08:15:34 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dave Patton <dpatton+...> wrote: > Have you tried taking your XML data and using an > XSLT transform to convert it to GPX? If you can > do that, you only need a few lines of new code > to produce a GPX file from your project. I don't have any XML data, it is in binary form and I want to write it as GPX. Thanks, Mark
yahoo+markwigmore.co.uk on Thu Mar 16 09:03:54 2006 (link), replying to msg
Dave Patton said: > In your first email, you said: > My current project has a module for writing data out > to a custom XML file and I want to modify it to write GPX. > Sounds to me like you have "XML data" ;-) Sorry for the confusion. That XML writer is designed to work on different source data and is used in a different way to what I'm doing. > Here's what I did when I wrote the PHP code to do the > generation of GPX files from the Degree Confluence Project's > Search page: http://www.confluence.org/search.php [snip] > The actual C# code for that is trivial - you are just > writing string data to a file that is saved with an > extension of ".gpx". That's very useful to know, thanks. I thought it was going to be more complex. I've written some code now to add the various nodes to <gpx> so I just need the <metadata> stuff and your pointers are very helpful. Many thanks, Mark
yahoo+markwigmore.co.uk on Thu Mar 16 09:24:10 2006 (link), replying to msg
Dave Patton said: > You can 'borrow' the 'namespace and schema stuff' from > example GPX files you can find on the net, write code OK I've found some header stuff from a MapSource output: <gpx xmlns="http://www.topografix.com/GPX/1/1" creator="MapSource 6.5" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> And so I've got this code: root = doc.CreateElement("gpx"); root.SetAttribute( "xmlns", "http://www.topografix.com/GPX/1/1" ); root.SetAttribute( "creator", "Me" ); root.SetAttribute( "version", "1.1" ); root.SetAttribute( "xmlns:xsi", "http://www.w3.org/2001/XMLSchema-instance" ); root.SetAttribute( "xsi:schemaLocation", "http://www.topografix.com/GPX/1/1/gpx.xsd" ); I noticed that the last one had two URIs in the MapSource version. Is that correct? Cheers, Mark
ldgregory+gmail.com on Thu Mar 16 10:44:27 2006 (link), replying to msg
Hello Mark, Thursday, March 16, 2006, 10:24:04 AM, you wrote: > OK I've found some header stuff from a MapSource output: I know your pain. When I wrote the GPX Generator for Geocaching, I hard a bit of a time trying to put it all together. If you want, you can take a look at the output of this at where you can also look directly at the GPX file. http://gps.pcwize.com/cache.php?cache=gcprpe I tried a while back to find out if there was an open namespace to use that most Geocaching programs would recognize. I was pointed at forum entries by Jeremy of Geocaching.com where he states that applications generating and reading GPX files can use the Groundspeak namespace. At any rate all the Geocaching related programs import the GPX files my generator creates just fine. There is one known issue which is that I didn't actually encode the file with UTF-8 so umlats and whatnot will not be encoded properly. I plan on fixing it, but just haven't had the opportunity to yet. -- TBUDL/BETA/DEV/TECH Lists Moderator / PGP 0x6C0AB16B __ ____ ____ ____ Geocaching: http://gps.PCWize.com ( ) ( ___)(_ _)( ___) TBUDP Wiki Site: http://www.PCWize.com/thebat/tbudp )(__ )__) _)(_ )__) Roguemoticons & Smileys: http://PCWize.com/thebat (____)(____)(____)(__) PHP Tutorials and snippets: http://www.DevTek.org My mail reader can beat up your mail reader.
kaz+okuda.ca on Fri Mar 17 16:38:11 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "azbithead" <azbithead+...> wrote: > > > Unfortunately, the GPX file format doesn't > > explicitly define a good way of doing this so my script recognizes a > > slightly enhanced content. > > Actually, the GPX schema does define a method for extending its > content. It is the <extensions> tag. > Thanks. I started this almost a year ago and haven't done much with it since then. I recently started up again by posting it publicly for someone who was interested. The last time I looked at the schema I guess it was the 1.0 and there was no mention of the <extensions> tag. I will define my own schema and add the html content within the <extensions> tag. > > Second question... What sort of discussions have taken place around HTML > > content in GPX files. > > I don't know but I see nothing wrong with placing XHTML (with a proper > defining schema) in an <extensions> element. After all, that's what > the <extensions> tag is for: extending the GPX schema. > Then that is what I will do. Thanks for your feedback.
mhaxx+postino.it on Tue Mar 21 04:08:35 2006 (link)
Is there possibility to store velocity and direction on a GPX file? Which tags? Mhaxx
chris+ainslie.co.za on Tue Mar 21 04:44:30 2006 (link), replying to msg
There is very little point as the rest of the data in the file will give you the tools to calculate both velocity and direction. It would be redundant information. If you have to do it, it can be stored in the <extentions> tag... but you *don't* have to do it. Chris Ainslie chris+ainslie.co.za 083 639 1391 Skype: cainslie -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Mhaxx Sent: 21 March 2006 02:08 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Velocity and direction Is there possibility to store velocity and direction on a GPX file? Which tags? Mhaxx Yahoo! Groups Links
robertlipe+usa.net on Tue Mar 21 06:25:44 2006 (link), replying to msg
> > Is there possibility to store velocity and direction on a GPX file? > > Which tags? GPX 1.0 has a "speed" and "course" tags: http://www.topografix.com/gpx_manual.asp Unfortunately, these were accidentally left out of 1.1. http://www.topografix.com/GPX/1/1/gpx.xsd > little point as the rest of the data in the file will give you the > tools to calculate both velocity and direction. It would be redundant This is generally true. It's also why we didn't notice they were left out of 1.1 until it had been published... RJL
james.carlyle+takepart.com on Tue Mar 21 06:30:05 2006 (link)
Hi I've been building a website that allows people to register and share GPS routes. It uses the GPX format for both input and output, and provides various tools for people to plot and visualise their routes. It is aimed at mountain bikers and runners. http://routeburner.com/ Although many bikers use proprietary binary formats, such as .mno (Mapping Objects) and .trl (Tracklogs.co.uk), I am firmly behind an xml-based format that is openly described like GPX and will be doing all I can to encourage its use. Anyway I would appreciate any feedback on the idea, the website, and whether you encounter any problems if you use it. Kind regards James -- James Carlyle +44 7816 520775 http://routeburner.com/ - share your GPS routes!
doolaard+gmail.com on Tue Mar 21 06:48:38 2006 (link), replying to msg
i think the idea is pretty good. I like that you want to adhere to something like GPX. that makes life easier. I wonder though when ther eare many routes how one can find a specific route. This can be based on location (country, coordinates, etc...) and also some specifics. for instance i am currently looking for routes that i can use for training uphill and downhill running in the Netherlands. how can i find this. Even a simple selection as on distance. Also comments of users who ran/biked the route are probably valuable for other future users. These are some points that occur to me, but i think your idea has potential. Greetings, Jan, The Netherlands On 3/21/06, James Carlyle <james.carlyle+takepart.com> wrote: > Hi > > I've been building a website that allows people to register and share > GPS routes. It uses the GPX format for both input and output, and > provides various tools for people to plot and visualise their routes. > It is aimed at mountain bikers and runners. > > http://routeburner.com/ > > Although many bikers use proprietary binary formats, such as .mno > (Mapping Objects) and .trl (Tracklogs.co.uk), I am firmly behind an > xml-based format that is openly described like GPX and will be doing all > I can to encourage its use. > > Anyway I would appreciate any feedback on the idea, the website, and > whether you encounter any problems if you use it. > > Kind regards > > James > > -- > James Carlyle > +44 7816 520775 > http://routeburner.com/ - share your GPS routes! > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847
gps_maps+travelbygps.com on Tue Mar 21 10:47:20 2006 (link), replying to msg
--- James Carlyle wrote: > I've been building a website that allows people to register and share > GPS routes. Welcome James, When I got started a few years ago I kept a list of sites related to this subject. I've not been very diligent keeping up with new sites, but I still believe it is good survey of how others are sharing GPX data. Look here, under "Recreational GPS Websites" http://www.travelbygps.com/authoring.php#gpsdatasrce - Doug www.TravelByGPS.com Travel by GPS (tm) Maps Waypoints and Tracks to Adventure
james.carlyle+takepart.com on Tue Mar 21 13:00:46 2006 (link), replying to msg
Jan, Greg, Doug Your feedback is very valuable. Many thanks. Jan Pieters wrote: > I wonder though when ther eare many routes how one can find a specific > route. This can be based on location (country, coordinates, etc...) > and also some specifics. for instance i am currently looking for > routes that i can use for training uphill and downhill running in the > Netherlands. how can i find this. Even a simple selection as on > distance. This is great advice. I will look at adding filtering to the global map so that it is easier to find routes by certain criteria. > Also comments of users who ran/biked the route are probably valuable > for other future users. Already there - though requires registration. I want people to be responsible for their comments. Greg wrote: > GPX is probably the best main download option, but it might be useful > have a kml option too. Maybe poll this after you get more routes. You > can point them to http://gpsvisualizer.com/gpsbabel/. Thanks - I will take a look at KML. As long as the formats are openly specified, any should be easy. > Good to see gradients. How hard would it be to break that down more? > Maybe something like how many m or km between 10 and 15 percent and so > many km between 5 and 10, etc. I'm guessing at the numbers, some > thought needs to go into the ranges used. Actually I had another page of numbers but thought it was a bit nerdy! I'll reinstate it. > Think hard about requiring registration. I wanted to comment on Mr. > Toads, but I'm not going to register to post a one short comment. The > comment was that there is a better way up that's not on the main road. OK, I don't want people to slang or spam the routes of others. I might remove it and reinstate only if there is an issue. > Can you offer a miles option for we "do it our own way people" here in > the US? Good point! A little point but I want to welcome routes in the U.S. too. Doug Adomatis wrote: > Welcome James, Thanks! > data. Look here, under "Recreational GPS Websites" > http://www.travelbygps.com/authoring.php#gpsdatasrce Wow! I did some study on the prior art but didn't realise there was this wealth of applications. Hopefully what I do will complement them. James
k.raymond+qut.edu.au on Tue Mar 21 16:01:59 2006 (link)
> > little point as the rest of the data in the file will give you the > > tools to calculate both velocity and direction. It would be redundant > > This is generally true. It's also why we didn't notice they were left > out of 1.1 until it had been published... Redundant, perhaps, but if you have already calculated the velocity/direction, someone may prefer to store these results and not recalculate them. Kerry
salcedo+yahoo.com on Tue Mar 21 19:49:26 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Kerry Raymond" <k.raymond+...> wrote: > > > > > little point as the rest of the data in the file will give you the > > > tools to calculate both velocity and direction. It would be > redundant > > > > This is generally true. It's also why we didn't notice they were left > > out of 1.1 until it had been published... > > Redundant, perhaps, but if you have already calculated the > velocity/direction, someone may prefer to store these results and not > recalculate them. > > Kerry > I know that a lot of people have brought this up, and these values are even included in at least one of the NMEA sentences, but I have to agree with Chris. As I see it, including these values would lead to confusion. Do you store the values for velocity and direction "to" this point, or the velocity and direction "from" this point? I suppose that distinction could be defined, or you could even include both. But if we had a vote, I would say leave them out.
yahoo+markwigmore.co.uk on Wed Mar 22 07:30:53 2006 (link), replying to msg
Ricardo said: > both. But if we had a vote, I would say leave them out. If you are in a boat or flying then your instruments will give you a different course and speed to the GPS if there is significant wind and/or tide. It is only when you are in contact with the ground that there is no (significant) difference, so my vote would be to allow for these to be included in the GPX file. Mark
yahoo+markwigmore.co.uk on Thu Mar 23 07:56:13 2006 (link)
Having managed to create some GPX files (thanks for the help guys!) I am now viewing them in Google Earth as a kind of sanity check. They look fine until you tilt the view and then you see that all the paths have been drawn on the surface. It seems to be ignoring the elevation tags. My paths are supposed to be at 30,000ft or so! Is this correct or have I made a mistake? Mark
robertlipe+usa.net on Thu Mar 23 08:24:56 2006 (link)
> Having managed to create some GPX files (thanks for the help guys!) I > am now viewing them in Google Earth as a kind of sanity check. They > look fine until you tilt the view and then you see that all the paths > have been drawn on the surface. It seems to be ignoring the elevation > tags. My paths are supposed to be at 30,000ft or so! > > Is this correct or have I made a mistake? The defaults in Earth are optimized for those that are terrestially bound. GE uses GPSBabel to do the internal conversion of GPX to KML. The option to get GPSBabel to act as you want is "floating", but I can't recall how that's plumbed to the outside in GE and I don't have a copy within reach right now. gpsbabel -i gpx -f blah.gpx -o kml,floating -F blah.kml You may find -o kml,floating,lines,points=0 to be more visually pleasing for aircraft tracks.
yahoo+markwigmore.co.uk on Thu Mar 23 08:41:44 2006 (link), replying to msg
Robert Lipe said: > The defaults in Earth are optimized for those that are terrestially bound. > > GE uses GPSBabel to do the internal conversion of GPX to KML. The option > to get GPSBabel to act as you want is "floating", but I can't recall how > that's plumbed to the outside in GE and I don't have a copy within reach > right now. Thanks. I've just found this page: http://www.keyhole.com/GoogleEarthHelp/GoogleEarth.htm#Importing/Importing_GPS_Data.htm It shows how to import data directly from a GPS device into GE and it has a facility to 'float' tracks onto the earth's surface. Would be nice to have a similar switch for GPX import! Cheers, Mark
yahoo+markwigmore.co.uk on Thu Mar 23 09:18:24 2006 (link), replying to msg
I said: > a facility to 'float' tracks onto the earth's surface. Would be nice to > have a similar switch for GPX import! Found it! Right-clicking the item in the list on the lefthand panel allows you to Edit the display including three options for how the height data are to be interpreted. Sorry to disturb you... ;-) Mark
robertlipe+usa.net on Thu Mar 23 09:20:26 2006 (link), replying to msg
> > GE uses GPSBabel to do the internal conversion of GPX to KML. The option > It shows how to import data directly from a GPS device into GE and it has > a facility to 'float' tracks onto the earth's surface. It's no coincidence that the available options closely parallel the ones I just mentioned. It uses GPSBabel for receiver interchange, too. :-) > Would be nice to have a similar switch for GPX import! Request that of the GE development group if you have a need for it. RJL
hannu.lohi+tracker.fi on Thu Mar 30 02:13:57 2006 (link), replying to msg
This is intersting question, where I also wait answer. We are making tracking devices to many systems one example is wild animal. In there the device must be having battery life over 2 years. In that case, track point is taken only e.g. every 2 hour. Calculating speed from track for those points is not giving much information, but having it from GPS would give lot more. I am going to specify this parameter inside of our format, but where do you recommend to put that? Do you recommend to put it in to extensions, when the specification will have more variations or in to main nodes of the point?
mhaxx+postino.it on Thu Mar 30 07:05:47 2006 (link)
Is there somewhere a simple/light/freeware program to visualize a GPX file, i.e. a track? I need it but I can find it.. :-( Massimo
egroups+topografix.com on Thu Mar 30 07:28:40 2006 (link), replying to msg
Hello, Thursday, March 30, 2006, 10:05:35 AM, mhaxx wrote: m> Is there somewhere a simple/light/freeware program to visualize a GPX file, m> i.e. a track? m> I need it but I can find it.. :-( http://www.easygps.com/ is free. See also http://www.gpsu.co.uk and http://www.topografix.com/gpx_resources.asp -- Dan Foster
egroups+topografix.com on Thu Mar 30 07:30:38 2006 (link), replying to msg
Hello, Thursday, March 30, 2006, 10:21:32 AM, Greg wrote: G> Are there applications or spreadsheets that calculate slope or grade G> from gpx files? The basic calculation isn't too hard, but some G> smoothing options are needed given the errors in some gps data. In ExpertGPS, select a track, click Show Trackpoint List on the View menu. If the grade column isn't visible, click Select List Columns on the View menu and add it. http://www.expertgps.com -- Dan Foster
mhaxx+postino.it on Thu Mar 30 07:49:47 2006 (link), replying to msg
> m> Is there somewhere a simple/light/freeware program to visualize a GPX Excuse me, I forgot to tell you I need a GPX viewer on a map. EasyGPS shows only the track, but nothing about the map.. Massimo
james.carlyle+takepart.com on Thu Mar 30 07:55:37 2006 (link), replying to msg
> Is there somewhere a simple/light/freeware program to visualize a GPX file, > i.e. a track? > > I need it but I can find it.. :-( > > Massimo Massimo, If you upload a GPX file to the routeburner, you can visualise it and also see gradient information eg http://routeburner.com/route/show/4 and http://routeburner.com/route/statistics/4 There is a caveat however: the mapping and photos come from Google, and there is little map coverage of Italy at the moment. Photo coverage is fair. Where is your route situated? -- James Carlyle +44 7816 520775 http://routeburner.com/ - share your GPS routes
chris+ainslie.co.za on Thu Mar 30 08:34:24 2006 (link)
Hi All, I've been playing with some software to "average" my tracks in order to get one final accurate tracklog. Ok, that doesn't make much sense. Imagine you drive to work every day with your GPSr on and creating a tracklog. This tracklog will not be identical every day due to a number of factors such as accuracy and which side of the road you are on etc. I'm hoping to average all of these tracks into one that is an accurate combination of them all, but I would like to know if there is any software out there that can already do this? Any pointers would be great! Thanks Chris Ainslie chris+ainslie.co.za 083 639 1391 Skype: cainslie [Non-text portions of this message have been removed]
gps_maps+travelbygps.com on Fri Mar 31 08:22:26 2006 (link)
I am very please that Fugawi (Ver. 4.0.12)will import and export waypoints, routes, tracks in GPX format. Prior to this, I had been publishing GPX *and* Fugawi (WPT/RTE/TRK) formats for GPS adventures located outside the United States. No more. Fugawi's GPX import and export process works a little differently than I anticipated. When you import either waypoints, routes or tracks from a GPX file, Fugawi loads all waypoints, routes and tracks found in the file. But when you export to GPX, you can only export waypoint, routes or tracks. Said another way, you import all elements at once but you export elements seperately. Maybe someone in this group will develop - or already has - a utility that will input three GPX files (one waypoints, one for routes, and one for tracks) and output a single GPX file that includes everything. If you would like to see how Fugawi does GPX, their demo policy has changed, allowing time-limited access to most all features. - Doug http://www.travelbygps.com/software.php
robertlipe+usa.net on Fri Mar 31 08:58:08 2006 (link), replying to msg
Doug Adomatis wrote: > Maybe someone in this group will develop - or already has - a utility > that will input three GPX files (one waypoints, one for routes, and > one for tracks) and output a single GPX file that includes everything. GPSBabel will merge GPX files like that. RJL
james.carlyle+takepart.com on Sun Apr 02 06:02:48 2006 (link), replying to msg
Hi The one function that I want to add to http://routeburner.com is the ability to accept Tracklogs .trl files. Unfortunately this seems to be an undocumented proprietary binary format. Can anyone point me to any documentation for the format, or an open source conversion or reading tool? The jackpot would be a .trl to .gpx conversion tool. GpsBabel does not support .trl - and the only 3rd party tool I have found that does is GpsUtility, again closed source. Many thanks if you can help James -- James Carlyle +44 7816 520775 http://routeburner.com/ - share your GPS routes!
gpsxml+iantomey.com on Thu Apr 06 04:50:26 2006 (link)
Hi guys, Im developing a GPS website and I want the users to have the ability to download the entire GPS db & associated html information files. This I can do easily by generating a zip file with GPX & HTML files. Can you recommend a (preferably free) windows app that is able to view these points on a map and - crucially - allow the opening of the relative URL from the interface? I tried a couple of apps from the list on the website but they didnt handle it, and I dont want to go down the entire list any ideas? Cheers Ian
kaz+okuda.ca on Thu Apr 06 16:21:10 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "runthisriverdry" <gpsxml+...> wrote: > > Hi guys, > > Im developing a GPS website and I want the users to have the ability > to download the entire GPS db & associated html information files. > This I can do easily by generating a zip file with GPX & HTML files. > > Can you recommend a (preferably free) windows app that is able to view > these points on a map and - crucially - allow the opening of the > relative URL from the interface? I tried a couple of apps from the > list on the website but they didnt handle it, and I dont want to go > down the entire list > > any ideas? > > Cheers > Ian > It sounds like you are trying to build something like TripTracker http://triptracker.net/ <http://triptracker.net/> ? It looks like they created their own uploader to handle that. I've been thinking about extending my Google Maps GPX viewer <http://notions.okuda.ca/geotagging/projects-im-working-on/gpx-viewer/> to be able to run locally by essentially implementing a simple http server to feed a local browser just like Me Here <http://mehere.glenmurphy.com/> . You might be able to modify that Python script to do what you want. My Here <http://mehere.glenmurphy.com/> + GPX viewer <http://notions.okuda.ca/geotagging/projects-im-working-on/gpx-viewer/> + your own hacks = what you want? [Non-text portions of this message have been removed]
gpsxml+iantomey.com on Fri Apr 07 11:06:07 2006 (link), replying to msg
thanks for the reply > It sounds like you are trying to build something like TripTracker > http://triptracker.net/ <http://triptracker.net/> ? It looks like they > created their own uploader to handle that. Nope, i'm not doing anything particularly like that, I don't think there is anything particularly like what I am doing at the moment Thanks for the info but thats not quite what I am looking for, I need something to run locally when not connected to the net. What I am after is something like POIEdit, but it shows all the items one the map at once and clicking on the item would show the web page. I might just have to slam together an app to do this, shouldnt be too difficult. Oh and Im also using Virtual Earth instead of Google Maps on my site as VE has at least some support for europe, google pretends theres nothing on the continent :) regards Ian
cybarber+gmail.com on Sat Apr 15 06:47:50 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > > > GE uses GPSBabel to do the internal conversion of GPX to KML. The option > > > It shows how to import data directly from a GPS device into GE and it has > > a facility to 'float' tracks onto the earth's surface. > > It's no coincidence that the available options closely parallel the ones > I just mentioned. It uses GPSBabel for receiver interchange, too. :-) > > > Would be nice to have a similar switch for GPX import! > > Request that of the GE development group if you have a need for it. > > RJL You could use my GPX2KML transformation tool to convert the GPX to KML instead of openeing GPX in GE(The GPSbabel programm is a limited in its conversion). In transforming to KML(I use XSLT) you can set several parameters. Its an HTA application so use Internet Explorer. (output file is save to C:\ by default) http://members.home.nl/cybarber/geomatters/KmlGpxGmlTransform.hta Cybarber
cybarber+gmail.com on Sat Apr 15 06:52:32 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Greg <MtnBiker+...> wrote: > > Are there applications or spreadsheets that calculate slope or grade > from gpx files? The basic calculation isn't too hard, but some > smoothing options are needed given the errors in some gps data. > > Thanks > My GPX2KML XSLT transformation application calculates slope/grade from the GPX trkpt's. You can checkout the XSLT sheet used to see how it is done Internet Explorer HTA application: http://members.home.nl/cybarber/geomatters/KmlGpxGmlTransform.hta XSLT sheet: http://members.home.nl/cybarber/geomatters/GPX2KML.xslt Cybarber
cybarber+gmail.com on Sat Apr 15 06:54:12 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "runthisriverdry" <gpsxml+...> wrote: > > Hi guys, > > Im developing a GPS website and I want the users to have the ability > to download the entire GPS db & associated html information files. > This I can do easily by generating a zip file with GPX & HTML files. > > Can you recommend a (preferably free) windows app that is able to view > these points on a map and - crucially - allow the opening of the > relative URL from the interface? I tried a couple of apps from the > list on the website but they didnt handle it, and I dont want to go > down the entire list > > any ideas? > > Cheers > Ian Just to view your GPS file open it in Google Earth, the best viewer you can imagen. Cybarber
gpsxml+yahoogroups.com on Sat Apr 15 07:01:40 2006 (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 : /XSLT transformation Sheets/GPX2KML.xslt Uploaded by : cybarber <cybarber+gmail.com> Description : Transforms a GPXv1.1/v1.0 to KML Google Earth You can access this file at the URL: http://groups.yahoo.com/group/gpsxml/files/XSLT%20transformation%20Sheets/GPX2KML.xslt To learn more about file sharing for your group, please visit: http://help.yahoo.com/help/us/groups/files Regards, cybarber <cybarber+gmail.com>
hannu.lohi+tracker.fi on Tue Apr 18 03:10:31 2006 (link)
Has anyone already made compression systems for the GPX format? My goal is to send GPX data within the SMS message, whith maximum length of 160 characters. Because of that there is need to compress the format quite much. Do you have some ready formats already?
doolaard+gmail.com on Tue Apr 18 03:39:29 2006 (link), replying to msg
Hi, GPX is nothing more than XML which is basically plain text (with a certain structure) so you can use any available compression tool/format you want e.g. WinZip, RAR, ... If that is enough for you I don't know, the size of your comnpressed data of course depends on how big the original file is :)), so you can't always tell if it fits in your 160 characters, but it seems unlikely. SMS is not the right way to send data over a mobile phone, you should use GPRS or somethinf similar. Greetings, Jan On 4/18/06, hlohi <hannu.lohi+tracker.fi> wrote: > > Has anyone already made compression systems for the GPX format? My > goal is to send GPX data within the SMS message, whith maximum length > of 160 characters. Because of that there is need to compress the > format quite much. Do you have some ready formats already? > > > > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847 [Non-text portions of this message have been removed]
egroups+topografix.com on Tue Apr 18 04:52:50 2006 (link), replying to msg
Hello, Tuesday, April 18, 2006, 6:39:28 AM, Jan wrote: J> GPX is nothing more than XML which is basically plain text (with a certain J> structure) so you can use any available compression tool/format you want e.g. J> WinZip, RAR, ... Some of the other popular XML formats have defined a compressed (zipped) format as well. Is there any interest in making this part of the GPX standard? I know of at least one program that already supports zipped GPX files. -- Dan Foster
doolaard+gmail.com on Tue Apr 18 05:05:13 2006 (link), replying to msg
Dan, I am aware of that. For instance the compressed files for Google Earth (KMZ) is an example of this and is a normal standard zip format. This means only that the software knows how to handle (i.e. decomnpress) compressed files. Jan On 4/18/06, Dan Foster <egroups+topografix.com> wrote: > > Hello, > > Tuesday, April 18, 2006, 6:39:28 AM, Jan wrote: > > J> GPX is nothing more than XML which is basically plain text (with a > certain > J> structure) so you can use any available compression tool/format you > want e.g. > J> WinZip, RAR, ... > > Some of the other popular XML formats have defined a compressed > (zipped) format as well. Is there any interest in making this part of > the GPX standard? I know of at least one program that already > supports zipped GPX files. > > -- > Dan Foster > > > > > Yahoo! Groups Links > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847 [Non-text portions of this message have been removed]
merlin_r68+hotmail.com on Tue Apr 18 13:02:42 2006 (link), replying to msg
You might try Huffman encoding the data and then use a base64 encoder to get character data. Justin >From: "Jan Pieters" <doolaard+gmail.com> >Reply-To: gpsxml+yahoogroups.com >To: gpsxml+yahoogroups.com >Subject: Re: Re[2]: [gpsxml] Any ready compression method available for >GPX? >Date: Tue, 18 Apr 2006 14:05:09 +0200 >MIME-Version: 1.0 >X-Originating-IP: 64.233.182.190 >X-Sender: doolaard+gmail.com >Received: from n12a.bullet.sc5.yahoo.com ([66.163.187.155]) by >bay0-mc9-f3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 >Apr 2006 05:05:14 -0700 >Received: from [66.163.187.120] by n12.bullet.sc5.yahoo.com with NNFMP; 18 >Apr 2006 12:05:14 -0000 >Received: from [66.218.69.4] by t1.bullet.sc5.yahoo.com with NNFMP; 18 Apr >2006 12:05:14 -0000 >Received: from [66.218.66.103] by t4.bullet.scd.yahoo.com with NNFMP; 18 >Apr 2006 12:05:14 -0000 >Received: (qmail 60988 invoked from network); 18 Apr 2006 12:05:13 -0000 >Received: from unknown (66.218.67.34) by m31.grp.scd.yahoo.com with QMQP; >18 Apr 2006 12:05:13 -0000 >Received: from unknown (HELO nproxy.gmail.com) (64.233.182.190) by >mta8.grp.scd.yahoo.com with SMTP; 18 Apr 2006 12:05:12 -0000 >Received: by nproxy.gmail.com with SMTP id x4so569929nfb for ><gpsxml+yahoogroups.com>; Tue, 18 Apr 2006 05:05:09 -0700 (PDT) >Received: by 10.49.36.2 with SMTP id o2mr1562769nfj; Tue, 18 Apr >2006 05:05:09 -0700 (PDT) >Received: by 10.48.30.3 with HTTP; Tue, 18 Apr 2006 05:05:09 -0700 (PDT) >X-Message-Info: JGTYoYF78jHc3r7CHi8lc1IM1fl5wcqoDYhJcAMvQ6I= >X-Yahoo-Newman-Property: groups-email >X-Apparently-To: gpsxml+yahoogroups.com >References: <e22dsd+p87g+eGroups.com> ><bdca9f6b0604180339y7d8a9753oe1c3d5691a67aa2b+mail.gmail.com> ><1768183193.20060418075550+topografix.com> >X-eGroups-Msg-Info: 1:12:0:0 >X-Yahoo-Profile: jkpieters >Mailing-List: list gpsxml+yahoogroups.com; contact >gpsxml-owner+yahoogroups.com >Delivered-To: mailing list gpsxml+yahoogroups.com >List-Id: <gpsxml.yahoogroups.com> >Precedence: bulk >List-Unsubscribe: <mailto:gpsxml-unsubscribe+yahoogroups.com> >Return-Path: >sentto-3994186-1275-1145361913-merlin_r68=hotmail.com+returns.groups.yahoo.com >X-OriginalArrivalTime: 18 Apr 2006 12:05:14.0643 (UTC) >FILETIME=[59DC1630:01C662E0] > >Dan, > >I am aware of that. For instance the compressed files for Google Earth >(KMZ) >is an example of this and is a normal standard zip format. This means only >that the software knows how to handle (i.e. decomnpress) compressed files. > >Jan > >On 4/18/06, Dan Foster <egroups+topografix.com> wrote: > > > > Hello, > > > > Tuesday, April 18, 2006, 6:39:28 AM, Jan wrote: > > > > J> GPX is nothing more than XML which is basically plain text (with a > > certain > > J> structure) so you can use any available compression tool/format you > > want e.g. > > J> WinZip, RAR, ... > > > > Some of the other popular XML formats have defined a compressed > > (zipped) format as well. Is there any interest in making this part of > > the GPX standard? I know of at least one program that already > > supports zipped GPX files. > > > > -- > > Dan Foster > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > >-- >Wil je stap voor stap van je schulden af komen? >Kijk dan op www.schuldenvrij.com > >J.K. Pieters >tel : +31 6 1850 1847 > > >[Non-text portions of this message have been removed] >
kaz+okuda.ca on Tue Apr 18 13:21:57 2006 (link), replying to msg
I would expect you could get the data even smaller if you were to encode it differently. Compressing text with a general purpose compression codec will work quite well, but given that you know the format of a GPX file and what it contains, I would bet you could do much better if it were encoded in a binary format first. There is a lot of wasted space in the text formatting of a GPX file. There are very good reasons for it to be text, but not for its size. If you are talking about compressing it then you are talking about making it unreadable (by humans) anyway so whether it is zip or another format is up to you. If you control the encoding and decoding then I expect you could make it much smaller if you chose a special binary encoding. Sure this isn't generic and flexible or readable by anyone else, but that doesn't sound like the requirements. --- In gpsxml+yahoogroups.com, "Jan Pieters" <doolaard+...> wrote: > > Dan, > > I am aware of that. For instance the compressed files for Google Earth (KMZ) > is an example of this and is a normal standard zip format. This means only > that the software knows how to handle (i.e. decomnpress) compressed files. > > Jan > > On 4/18/06, Dan Foster <egroups+...> wrote: > > > > Hello, > > > > Tuesday, April 18, 2006, 6:39:28 AM, Jan wrote: > > > > J> GPX is nothing more than XML which is basically plain text (with a > > certain > > J> structure) so you can use any available compression tool/format you > > want e.g. > > J> WinZip, RAR, ... > > > > Some of the other popular XML formats have defined a compressed > > (zipped) format as well. Is there any interest in making this part of > > the GPX standard? I know of at least one program that already > > supports zipped GPX files. > > > > -- > > Dan Foster > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > -- > Wil je stap voor stap van je schulden af komen? > Kijk dan op www.schuldenvrij.com > > J.K. Pieters > tel : +31 6 1850 1847 > > > [Non-text portions of this message have been removed] >
doolaard+gmail.com on Tue Apr 18 13:26:41 2006 (link), replying to msg
Hello, The question for sending it in an SMS. SMS canonly contain character data if I am not mistaken. so all kind of exotic stuff is out off the question, only a compression that transforms the GPX to a character encoded/compressed format will work. Jan On 4/18/06, Poco <kaz+okuda.ca> wrote: > > > I would expect you could get the data even smaller if you were to > encode it differently. Compressing text with a general purpose > compression codec will work quite well, but given that you know the > format of a GPX file and what it contains, I would bet you could do > much better if it were encoded in a binary format first. There is a > lot of wasted space in the text formatting of a GPX file. There are > very good reasons for it to be text, but not for its size. > > If you are talking about compressing it then you are talking about > making it unreadable (by humans) anyway so whether it is zip or > another format is up to you. If you control the encoding and decoding > then I expect you could make it much smaller if you chose a special > binary encoding. Sure this isn't generic and flexible or readable by > anyone else, but that doesn't sound like the requirements. > > --- In gpsxml+yahoogroups.com, "Jan Pieters" <doolaard+...> wrote: > > > > Dan, > > > > I am aware of that. For instance the compressed files for Google > Earth (KMZ) > > is an example of this and is a normal standard zip format. This > means only > > that the software knows how to handle (i.e. decomnpress) compressed > files. > > > > Jan > > > > On 4/18/06, Dan Foster <egroups+...> wrote: > > > > > > Hello, > > > > > > Tuesday, April 18, 2006, 6:39:28 AM, Jan wrote: > > > > > > J> GPX is nothing more than XML which is basically plain text (with a > > > certain > > > J> structure) so you can use any available compression tool/format you > > > want e.g. > > > J> WinZip, RAR, ... > > > > > > Some of the other popular XML formats have defined a compressed > > > (zipped) format as well. Is there any interest in making this part of > > > the GPX standard? I know of at least one program that already > > > supports zipped GPX files. > > > > > > -- > > > Dan Foster > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Wil je stap voor stap van je schulden af komen? > > Kijk dan op www.schuldenvrij.com > > > > J.K. Pieters > > tel : +31 6 1850 1847 > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > Yahoo! Groups Links > > > > > > > > -- Wil je stap voor stap van je schulden af komen? Kijk dan op www.schuldenvrij.com J.K. Pieters tel : +31 6 1850 1847 [Non-text portions of this message have been removed]
hannu.lohi+tracker.fi on Wed Apr 19 01:34:54 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "merlin_r68 _-_" <merlin_r68+...> wrote: > > You might try Huffman encoding the data and then use a base64 encoder to get > character data. > > Justin Thanks Justin Now we are getting closer what I am looking for. Do you have any links as refernce, for the components, which could do those methods?
merlin_r68+hotmail.com on Wed Apr 19 06:00:53 2006 (link), replying to msg
Hannu, Depending on the application, I usually roll my own codecs. You may look at the following links for help tho: 1. Crypto++ -- Has a base64 encoder/decoder (among other useful stuff) http://www.eskimo.com/~weidai/cryptlib.html 2. Huffman encoders http://datacompression.info/Huffman.shtml and from the good ol' Wikipedia: http://en.wikipedia.org/wiki/Adaptive_Huffman_coding Those should get you started. These are very common encoding schemes, so Googling will turn up many more references. Good Luck! Justin >From: "Hannu Lohi" <hannu.lohi+tracker.fi> >Reply-To: gpsxml+yahoogroups.com >To: gpsxml+yahoogroups.com >Subject: [gpsxml] Re: Any ready compression method available for GPX? >Date: Wed, 19 Apr 2006 08:33:33 -0000 >MIME-Version: 1.0 >X-Originating-IP: 66.163.187.157 >X-Sender: hannu.lohi+tracker.fi >Received: from n24c.bullet.sc5.yahoo.com ([66.163.187.215]) by >bay0-mc3-f14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, >19 Apr 2006 01:36:54 -0700 >Received: from [66.163.187.120] by n24.bullet.sc5.yahoo.com with NNFMP; 19 >Apr 2006 08:35:34 -0000 >Received: from [66.218.69.1] by t1.bullet.sc5.yahoo.com with NNFMP; 19 Apr >2006 08:35:34 -0000 >Received: from [66.218.66.156] by t1.bullet.scd.yahoo.com with NNFMP; 19 >Apr 2006 08:35:34 -0000 >Received: (qmail 63181 invoked from network); 19 Apr 2006 08:34:33 -0000 >Received: from unknown (66.218.66.166) by m16.grp.scd.yahoo.com with QMQP; >19 Apr 2006 08:34:33 -0000 >Received: from unknown (HELO n14a.bullet.sc5.yahoo.com) (66.163.187.157) >by mta5.grp.scd.yahoo.com with SMTP; 19 Apr 2006 08:34:30 -0000 >Received: from [66.163.187.120] by n14.bullet.sc5.yahoo.com with NNFMP; 19 >Apr 2006 08:33:34 -0000 >Received: from [66.218.66.58] by t1.bullet.sc5.yahoo.com with NNFMP; 19 Apr >2006 08:33:34 -0000 >Received: from [66.218.66.74] by t7.bullet.scd.yahoo.com with NNFMP; 19 Apr >2006 08:33:34 -0000 >X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8= >X-Yahoo-Newman-Property: groups-email >X-Apparently-To: gpsxml+yahoogroups.com >User-Agent: eGroups-EW/0.82 >X-Mailer: Yahoo Groups Message Poster >X-eGroups-Msg-Info: 1:12:0:0 >X-Yahoo-Post-IP: 62.236.30.42 >X-Yahoo-Profile: hlohi >Mailing-List: list gpsxml+yahoogroups.com; contact >gpsxml-owner+yahoogroups.com >Delivered-To: mailing list gpsxml+yahoogroups.com >List-Id: <gpsxml.yahoogroups.com> >Precedence: bulk >List-Unsubscribe: <mailto:gpsxml-unsubscribe+yahoogroups.com> >Return-Path: >sentto-3994186-1279-1145435695-merlin_r68=hotmail.com+returns.groups.yahoo.com >X-OriginalArrivalTime: 19 Apr 2006 08:36:54.0299 (UTC) >FILETIME=[697CB6B0:01C6638C] > >--- In gpsxml+yahoogroups.com, "merlin_r68 _-_" <merlin_r68+...> wrote: > > > > You might try Huffman encoding the data and then use a base64 >encoder to get > > character data. > > > > Justin > >Thanks Justin > >Now we are getting closer what I am looking for. Do you have any links >as refernce, for the components, which could do those methods? > > > >
tkvgzcf02+sneakemail.com on Fri Apr 21 04:58:27 2006 (link)
--- In gpsxml+yahoogroups.com, "teisha-reifel140+..." <teisha-reifel140+...> wrote: > > I am really gettin tired of all the same old stuff online now days, so i was pretty suprised when i saw this http://www.chilloverhere.info/fhlx . Looks pretty fresh, wat you all reckon. > NSFW SPAM
dragonstun+hotmail.com on Sat May 06 18:42:12 2006 (link)
Hello, I'm researching the possibility of inputting GPX data collected with a Gremlin receiver to plot Lats and Longs into AutoCAD... any advise?
mhoegh+gmail.com on Tue May 16 12:56:44 2006 (link), replying to msg
Hi James, Nice site! Im working on a similar software project (right now for California, New York and Norway). My initially idea was a trace tool, so it would be possible to create a gpx from scratch. I've now added import of gpx and working on enhancements of the editing tool for gpx. Maybe a mechanism to exchange gpx's between two sites on server level would be an good idea - maybe using rss? check it out on http://cal.mapuse.net /martin
hombre+gmail.com on Sun May 21 14:24:56 2006 (link), replying to msg
You'll have a hard time finding a modern GPS that does *not* support the GPX format. All Garmin units support it through their Mapsource software. I don't have hands-on experience with other brands, but even in the unlikely case where it's not supported natively, you can use GPSBabel to convert from the propriatry format to GPX. Have a look here http://www.gpsbabel.org/capabilities.html to check out the formats that are supported. One thing that's generally *not* supported is to upload self created maps to a GPS. But waypoints and routes shouldn't be a problem. Tom On 5/21/06, Eric S. Theise <mataro+cyberwerks.com> wrote: > > Hello, > > Last fall, I co-taught a class on mapping, broadly defined, at an > art school here in San Francisco. We're teaching it again, and I > have a window of opportunity where I can make recommendations to > the school for equipment purchases. > > I want to order one or more handheld GPS units that are capable of > importing/exporting data via gpx, and I don't know the codeword for > that. For example, I picked up an extensive feature comparison > chart from REI last week, and gpx does not appear anywhere on it; > the same is true for their online GPS finder tool at > > http://www.rei.com/rei/gearshop/advisor/gps.html > > The paper chart has rows for "custom mapping capable", "additional > mapping software utilized", "pc compatible", and "pc interface > type", and elsewhere I've seen the phrase "geocaching ready"-- > > > http://www.rated4stars.com/html/session-start.php?source=GoA-HandheldGPS&dest=handheldgps&gclid=CMiIxuG1g4UCFQ1kGAoddnzjFw > > --and I'm hoping someone one this list could clue me in as to what > to look for. > > We'd like, early in the class, to do a geocaching field trip, and > we'd like to give the students the option to work with the google > maps API and MapServer. We'd like to have some data going back and > forth between the handheld GPS(s) and maps they create. The school > has one PC-lab, but Macs predominate, and these are art students, > not programmers, though some are quite sophisticated users of > Illustrator, Flash, Photoshop, and tools specific to the architecture > program. > > Any tips would be much appreciated. > > --Eric > > > SPONSORED LINKS > Computer internet security<http://groups.yahoo.com/gads?t=ms&k=Computer+internet+security&w1=Computer+internet+security&w2=Computer+internet+business&w3=Xml+format&w4=Computer+internet+access&w5=Computer+internet+privacy+securities&w6=Xml+specification&c=6&s=175&.sig=IlD-TGv7JZJ9CWp7Z_hSfA> Computer > internet business<http://groups.yahoo.com/gads?t=ms&k=Computer+internet+business&w1=Computer+internet+security&w2=Computer+internet+business&w3=Xml+format&w4=Computer+internet+access&w5=Computer+internet+privacy+securities&w6=Xml+specification&c=6&s=175&.sig=_86a6JCggoSCQt7K4-wyxg> Xml > format<http://groups.yahoo.com/gads?t=ms&k=Xml+format&w1=Computer+internet+security&w2=Computer+internet+business&w3=Xml+format&w4=Computer+internet+access&w5=Computer+internet+privacy+securities&w6=Xml+specification&c=6&s=175&.sig=ZgUABvRYiWcQhhJFGamqqA> Computer > internet access<http://groups.yahoo.com/gads?t=ms&k=Computer+internet+access&w1=Computer+internet+security&w2=Computer+internet+business&w3=Xml+format&w4=Computer+internet+access&w5=Computer+internet+privacy+securities&w6=Xml+specification&c=6&s=175&.sig=NQVW53utmY4-hzBQMWaPBQ> Computer > internet privacy securities<http://groups.yahoo.com/gads?t=ms&k=Computer+internet+privacy+securities&w1=Computer+internet+security&w2=Computer+internet+business&w3=Xml+format&w4=Computer+internet+access&w5=Computer+internet+privacy+securities&w6=Xml+specification&c=6&s=175&.sig=zimEQXHjTV7fTjb7GQRr_A> Xml > specification<http://groups.yahoo.com/gads?t=ms&k=Xml+specification&w1=Computer+internet+security&w2=Computer+internet+business&w3=Xml+format&w4=Computer+internet+access&w5=Computer+internet+privacy+securities&w6=Xml+specification&c=6&s=175&.sig=HWwOgn346rRRyAtWan8u_g> > ------------------------------ > YAHOO! GROUPS LINKS > > > - Visit your group "gpsxml <http://groups.yahoo.com/group/gpsxml>" > on the web. > > - To unsubscribe from this group, send an email to: > gpsxml-unsubscribe+yahoogroups.com<gpsxml-unsubscribe+yahoogroups.com?subject=Unsubscribe> > > - Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/>. > > > ------------------------------ > [Non-text portions of this message have been removed]
o.z.fw+seznam.cz on Wed Jun 14 22:45:06 2006 (link)
Hello, I would like to ask if anyone knows about a mobile (j2me) application which is able to record data recieved from Bluetooth GPS (and save them in mobile device). GPX format is, of course, preferred, but any other will be also fine. Such midlet would be of great usability, since your mobile will take care of recording and you won't need super-smart-expensive GPS. Thanks, Ondrej Zara
thomas.landspurg+gmail.com on Thu Jun 15 12:11:22 2006 (link)
Ondrej, Check my application, J2MEmap. Currently, data can be send to the server, but the next version, soon to be ready, is able to save "tracks", then, export/import them either in GPX, KML through Bluetooth or to the file system, depending of your phone capacities. What is your phone model, and I eventually can send it to you a preview?. Http://j2memap.landspurg.net <http://j2memap.landspurg.net/> -- Thomas Landspurg http://blog.landspurg.net [Non-text portions of this message have been removed]
dave.paylor+aspiren.com on Sat Jun 17 13:25:32 2006 (link)
Hi All, I am a new member so if I am off at a tangent then please forgive me. I use a GPS in UK mainly for walking/running/canoeing and GPX seems to be an ideal format to set up the routes on my PC and then transfer them to my GPS. However, I do not seem to be able to find software that will enable me to do this in a simple way - particularly from UK. I did try Topofusion and GPS Utility but while US maps are supported the UK is not. I was thinking that it should be feasible to upload an image of a route, input LatLong for opposite corners and then for the software to graduate the image from the number of pixels. You could then add waypoints along the route with simple clicks of the mouse, add height info if needed and hey presto, export a GPX route for transfer to the GPS. I appreciate that the accuracy would be dependent upon how "square" the user managed to get the image but it should work with pretty much anything. Am I talking about something that already exists? I have done some basic PHP coding though I am not sure I am up to a project like this? Any suggestions? Dave
markp99+gmail.com on Wed Jun 28 11:15:40 2006 (link)
I've been playing around with GPX files for a bit using MS Access to read, parse and populate fileds in an Access database. I use the Accesss database to filter the information and produce a GoogleMaps format file using colored pushpins for found/not found, etc. I am *mostly* successful reading the complete GPX file. I seem to be getting hung up occasionally with records which contain unexpected punctuation and HTML strings. I'd rather not have to test/replace for each offending character as I'd like to keep performance (~3 seconds for a 200 cache GPX file - ~25K lines in XML file). Are there any existing or generic robust GPX parsing utilties I might be able to use to pull GPX data into my Access Database? I feel like I am re-inventing the wheel. Someone has got to have figured this out already. Any ideas or pointers? Thanks, mark Note: MS Access XML Import Wizard fails miserably trying to import the data. It is FAST, but just does not build the desired table atructures.
ptomblin+gmail.com on Mon Jul 03 13:11:55 2006 (link)
What is the difference between <fix> and <type>? I've been using the <type> record for "AIRPORT", "VOR", "VFR-WPT", etc. But would it be better to put that in <fix>? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
ptomblin+gmail.com on Mon Jul 03 15:17:55 2006 (link)
Doing a "SAXCount -n -s -f" to test my new schema and GPX file generator, I get this wierd error: Error at file /home/ptomblin/waypoint.gpx, line 751, char 35 Message: Datatype error: Type:InvalidDatatypeFacetException, Message:Value '0' must be greater than or equal to MinInclusive '0.0' . Last time I looked, '0' *is* greater than or equal to '0.0'. Is this a SAXCount bug, or should I modify my code to force it to put a single digit after the decimal point? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
urvasi1993+yahoo.com on Tue Jul 04 02:56:08 2006 (link)
visit, join , forward http://www.studyjava.org/forums/
urvasi1993+yahoo.com on Fri Jul 14 22:18:52 2006 (link)
visit, join , forward http://www.studyjava.org/forums/ --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1�/min. [Non-text portions of this message have been removed]
egroups+topografix.com on Wed Jul 26 07:47:19 2006 (link)
Hello, Is anyone currently writing geocaching information into a GPX 1.1 document using the groundspeak schema? GPX 1.1 requires all other schema data to be in the <extensions> element, so geocaching-aware programs would have to make a few simple changes to be able to read/write cache info from a GPX 1.1 document. I've confirmed with saxcount that this produces a valid GPX file, but I was just wondering if anyone is actually set up to read and write these files. Here's a stripped-down cache description with a GPX 1.1 header pasted on: <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="Copy and Paste" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.topografix.com/GPX/gpx_style/0/2 http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd http://www.topografix.com/GPX/gpx_overlay/0/3 http://www.topografix.com/GPX/gpx_overlay/0/3/gpx_overlay.xsd http://www.topografix.com/GPX/Private/TopoGrafix/0/3 http://www.topografix.com/GPX/Private/TopoGrafix/0/3/topografix.xsd http://www.groundspeak.com/cache/1/0 http://www.groundspeak.com/cache/1/0/cache.xsd"> <metadata> <name>GPX 1.1 Geocache</name> </metadata> <wpt lat="42.42315" lon="-71.4934833333333"> <time>2006-02-20T00:00:00.0000000-08:00</time> <name>GCTHHT</name> <desc>Stow it, Gladys! by deuxfreres, Traditional Cache (2/3)</desc> <sym>Geocache</sym> <type>Geocache|Traditional Cache</type> <extensions> <groundspeak:cache id="350544" available="True" archived="False" xmlns:groundspeak="http://www.groundspeak.com/cache/1/0"> <groundspeak:name>Stow it, Gladys!</groundspeak:name> <groundspeak:placed_by>deuxfreres</groundspeak:placed_by> <groundspeak:owner id="27583">deuxfreres</groundspeak:owner> <groundspeak:type>Traditional Cache</groundspeak:type> <groundspeak:container>Regular</groundspeak:container> <groundspeak:difficulty>2</groundspeak:difficulty> <groundspeak:terrain>3</groundspeak:terrain> <groundspeak:country>United States</groundspeak:country> <groundspeak:state>Massachusetts</groundspeak:state> <groundspeak:short_description html="False">Located in the Gardner Hill Conservation Land in Stow.</groundspeak:short_description> <groundspeak:long_description html="False">The Town of Stow has developed a great network of conservation land trails, that we have enjoyed hiking many times. We've stowed a cache in Stow on President's Day 2006. Suggested parking is at 42 25.826, 71 29.082, a two-car, trail-head spur on Heritage Lane, the first right off White Pond Rd. From here, follow the green blazed trail which leads you to a network of trails and the cache. A second parking area is available at the ballfield at the south end of Bradley Rd. Round trip time is an hour or so, depending on hunting time. The cache is on the small side, but requires little bushwhacking. We can't take credit for what the summer months might do to GPS reception, bug density or unfriendly plant life in the area, but in mid-winter, we had an accuracy within 20 feet. We started the cache with a well-traveled baseball, a travel bug and a log book. Depending on which direction you approach the cache from, the terrain rating is anywhere between a 2.5 and 4. As with all caches, please sign our log book, and replace camo as best you can. </groundspeak:long_description> <groundspeak:encoded_hints>elev. is three-seventy-four feet A.S.L.</groundspeak:encoded_hints> <groundspeak:logs> <groundspeak:log id="13278432"> <groundspeak:date>2006-02-25T08:00:00</groundspeak:date> <groundspeak:type>Found it</groundspeak:type> <groundspeak:finder id="593450">gogglehead</groundspeak:finder> <groundspeak:text encoded="False">Flipflopfinder foundit</groundspeak:text> </groundspeak:log> </groundspeak:logs> <groundspeak:travelbugs /> </groundspeak:cache> </extensions> </wpt> </gpx>
robertlipe+usa.net on Wed Jul 26 09:29:30 2006 (link), replying to msg
Dan Foster wrote: > Is anyone currently writing geocaching information into a GPX 1.1 > document using the groundspeak schema? GPX 1.1 requires all other A large part of my (GPSBabel's) user base is geocachers. Since Groundspeak itself doesn't do GPX 1.1, I handle their extensions -both read and write- only in GPX 1.0. I predict that if you handed a GPX 1.1 file with Groundspeak's geocaching extensions to any of the applications specializing in that format that the majority of them would fail. RJL
dananderson2+yahoo.com on Wed Jul 26 11:12:26 2006 (link)
I'm trying to encourage the addition of certain types of map annotations so that GPX Overlay is more useful for map publishing. I tried last year in the thread starting with message 945. Perhaps this way might get more interest? I'm particularly looking for the ability to put an icon (symbol) on the map with an optional hyperlink to an HTML file. The mapping program would launch a browser with the link and contain anything appropriate to HTML. Here's one idea that is close to the structure of a waypoint in an attempt to make it easier to implement: <xsd:element name="hotspot" type="hotspotType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation> A list of points that link to html pages, etc. from an graphic shown on the map. These points aren't intended to be sent to a GPS receiver possibly because of a lack of geographic significance. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complexType name="hotspotType"> <xsd:annotation> <xsd:documentation> Hotspot represents a symbol/graphic on a map to provide a link to some other document. This is intended to be similar to waypoints but aren't intended to be sent to the receiver so parameters that don't apply are left out. </xsd:documentation> </xsd:annotation> <xsd:sequence> <!-- elements must appear in this order --> <!-- Description info --> <xsd:element name="name" type="xsd:string" minOccurs="0"> ***>>> or type="labelType" <<<*** <xsd:annotation> <xsd:documentation> A label for the hotspot. The display of this name on the map is optional. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="desc" type="xsd:string" minOccurs="0"> ***>>> I don't know that I would use this <<<*** <xsd:annotation> <xsd:documentation> A text description of the element. Holds additional information about the element but is not the information linked to by the "hotspot". </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="link" type="linkType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation> Link to additional information - what the hotspot is all about. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="sym" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation> Text of symbol name. This is a program dependent mapping to some graphic which probably matches the name of icons/symbols used by waypoints in the program. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="type" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation> Type (classification) of the hotspot. This places the hotspot in a group which can specify what text, if any, is displayed; the font for the text, when it is displayed on the map based on zoom scale, etc. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="extensions" type="extensionsType" minOccurs="0"> <xsd:annotation> <xsd:documentation> You can add extend by adding your own elements from another schema here. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="max_scale" type="xsd:decimal"> ***>>> this is not in the waypoint attribute list <<<*** <xsd:annotation> <xsd:documentation> Maximum scale at which the parent object is displayed on a map. "24000" for a 1:24000 scale USGS topo, e.g. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:attribute name="lat" type="latitudeType" use="required"> <xsd:annotation> <xsd:documentation> The latitude of the point. Decimal degrees, WGS84 datum. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="lon" type="longitudeType" use="required"> <xsd:annotation> <xsd:documentation> The latitude of the point. Decimal degrees, WGS84 datum. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType>
avalon73+caerleon.us on Thu Jul 27 18:37:58 2006 (link), replying to msg
On Wed, 26 Jul 2006, Dan Foster wrote: > Is anyone currently writing geocaching information into a GPX 1.1 > document using the groundspeak schema? GPX 1.1 requires all other > schema data to be in the <extensions> element, so geocaching-aware > programs would have to make a few simple changes to be able to > read/write cache info from a GPX 1.1 document. CacheMate can import GPX 1.0 and 1.1 with extensions, but at present is only writing 1.0. You're right in that it wouldn't take much to add 1.1 writing, but I haven't done it yet pretty much for the same reasons as Robert stated. -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator "I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
richard+jelbert.com on Mon Jul 31 09:26:24 2006 (link)
Hi I have created a locaton recording device for my camera that stores long and lat and the compass direction on a FLASH card in CSV format each time I take a photo. For interest, see a picture of my prototype GeoTagger here: http://www.jelbert.com/geotagger.jpg I'd like to convert the CSV file it creates into GPX data but can't find the tag for compass direction... I am not really interested in speed because most images are taken standing still (but I guess some might not be in the future). Also, is it best to use a waypoint or route? Many thanks in advance for any feedback / answers. Richard
lisah2u+gmail.com on Mon Jul 31 10:03:01 2006 (link), replying to msg
If you don't mind my asking... how did you send data from the camera to the your box to indicate that you had just taken a picture? I rigged up something far dumber as a test... just wore a etrex summit on my hat to get compass data (head direction) and location. Even then I'm looking for a better solution for logging compass data. Lisa On 7/31/06, Richard Jelbert <richard+jelbert.com> wrote: > > Hi > > I have created a locaton recording device for my camera that stores > long and lat and the compass direction on a FLASH card in CSV format > each time I take a photo. > > For interest, see a picture of my prototype GeoTagger here: > http://www.jelbert.com/geotagger.jpg > > I'd like to convert the CSV file it creates into GPX data but can't > find the tag for compass direction... I am not really interested in > speed because most images are taken standing still (but I guess some > might not be in the future). > > Also, is it best to use a waypoint or route? > > Many thanks in advance for any feedback / answers. > > Richard > > > [Non-text portions of this message have been removed]
richard+jelbert.com on Mon Jul 31 15:18:06 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Lisa Harper" <lisah2u+...> wrote: > > If you don't mind my asking... how did you send data from the camera to the > your box to indicate that you had just taken a picture? I rigged up > something far dumber as a test... just wore a etrex summit on my hat to get > compass data (head direction) and location. Even then I'm looking for a > better solution for logging compass data. > Lisa Hi Lisa My GeoTagger connects to the camera flash shoe and on the Canon EOS5D the centre connection pin is taken low each time a picture is taken - flash or no flash. I just pick that signal up. I decided to use the Garmin geko 301 because it has an electronic compass and NMEI support. I've also seen it get down to 6 feet accuracy with WAAS switched on. When I am finished taking photos, I have two FLASH cards. The one from the camera with the photos and the one from the GeoTagger with the CSV file. Just need to convert it into (say) GPX so I can import the whole lot into RoboGeo or similar to merge the data. If only Canon supported the geko connection direct like Nikon do on their latest D-SLRs. Richard > > > On 7/31/06, Richard Jelbert <richard+...> wrote: > > > > Hi > > > > I have created a locaton recording device for my camera that stores > > long and lat and the compass direction on a FLASH card in CSV format > > each time I take a photo. > > > > For interest, see a picture of my prototype GeoTagger here: > > http://www.jelbert.com/geotagger.jpg > > > > I'd like to convert the CSV file it creates into GPX data but can't > > find the tag for compass direction... I am not really interested in > > speed because most images are taken standing still (but I guess some > > might not be in the future). > > > > Also, is it best to use a waypoint or route? > > > > Many thanks in advance for any feedback / answers. > > > > Richard > > > > > > > > > [Non-text portions of this message have been removed] >
lisah2u+gmail.com on Mon Jul 31 15:23:53 2006 (link), replying to msg
Sounds like a simple perl script. The heading data is relatively non-standard, I believe. I had trouble using gpsbabel for this purpose. Lisa On 7/31/06, Richard Jelbert <richard+jelbert.com> wrote: > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, "Lisa Harper" > <lisah2u+...> wrote: > > > > If you don't mind my asking... how did you send data from the camera > to the > > your box to indicate that you had just taken a picture? I rigged up > > something far dumber as a test... just wore a etrex summit on my hat > to get > > compass data (head direction) and location. Even then I'm looking for a > > better solution for logging compass data. > > Lisa > > Hi Lisa > > My GeoTagger connects to the camera flash shoe and on the Canon EOS5D > the centre connection pin is taken low each time a picture is taken - > flash or no flash. I just pick that signal up. > > I decided to use the Garmin geko 301 because it has an electronic > compass and NMEI support. I've also seen it get down to 6 feet > accuracy with WAAS switched on. > > When I am finished taking photos, I have two FLASH cards. The one from > the camera with the photos and the one from the GeoTagger with the CSV > file. Just need to convert it into (say) GPX so I can import the whole > lot into RoboGeo or similar to merge the data. > > If only Canon supported the geko connection direct like Nikon do on > their latest D-SLRs. > > Richard > > > > > > > > On 7/31/06, Richard Jelbert <richard+...> wrote: > > > > > > Hi > > > > > > I have created a locaton recording device for my camera that stores > > > long and lat and the compass direction on a FLASH card in CSV format > > > each time I take a photo. > > > > > > For interest, see a picture of my prototype GeoTagger here: > > > http://www.jelbert.com/geotagger.jpg > > > > > > I'd like to convert the CSV file it creates into GPX data but can't > > > find the tag for compass direction... I am not really interested in > > > speed because most images are taken standing still (but I guess some > > > might not be in the future). > > > > > > Also, is it best to use a waypoint or route? > > > > > > Many thanks in advance for any feedback / answers. > > > > > > Richard > > > > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > [Non-text portions of this message have been removed]
robertlipe+usa.net on Mon Jul 31 15:40:53 2006 (link), replying to msg
Lisa Harper wrote: > Sounds like a simple perl script. The heading data is relatively > non-standard, I believe. I had trouble using gpsbabel for this purpose. A well worded help request to the GPSBabel list may help. RJL
lesrandoactifs+wanadoo.fr on Mon Jul 31 22:40:47 2006 (link)
Hi all, I'm trying to open a gpx file with OpenOffice. I'm using "StarXpert xml calc filter" everything works except I'm not able to see latitudes and longitudes datas. Is existing a way to do this ? thanks for your help. Luc
kaz+okuda.ca on Tue Aug 01 01:08:05 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Louis" <clovis+...> wrote: > > > I have created a locaton recording device for my camera that stores > > long and lat and the compass direction on a FLASH card in CSV format > > each time I take a photo. > > ... > > Richard > > A naive question: why you don't use the time value from your photo (EXIF tag) to get the gps position from a recorded track? > Something like OziPhotoTool: > http://alistairdickie.com/oziphototool/index.html > > Louis > There are actually quite a few tools for doing this. Some are free and some not. The easiest one I've used (free) is from wwmx.org (Microsoft) and there are other commercial applications (Robogeo at robogeo.com looks very promising). I've written a few thoughts on the process and how I use it here http://notions.okuda.ca/geotagging/. I agree that it would be nice for Canon to do this like Nikon, but it takes only a minute to download your GPS track and stamp your photos with the GPS track. Robogeo will even export your photo locations to a GPX file as waypoints as well as the ability to stamp the photo Exif.
richard+jelbert.com on Tue Aug 01 02:48:48 2006 (link), replying to msg
Hello Indeed there are a number of tools to merge GPS tracks with EXIF data but as far as I can see, they are all blunt instruments trying to solve a rather more subtle problem. I'll explain my thinking. In the context of taking geo-tagged photographs, GPS tracks or waypoints stored on the GPS don't record the direction of the device at the time a photo is taken. Instead they allow you to interpolate the general direction of travel by looking at multiple track or waypoints. The reality is that most of the time the camera is pointing in a completely different direction when a photo is taken. I created this GeoTagger device because I wanted to record the exact compass direction (and location) when the photo was taken. the Garmin 301 provides both on its serial output in NMEA format so I store it in a CVS file on the flash card. The next generation of mobile camera phones will have GPS, the compact and D-SLR camera manufacturers are all looking for a differentiators so it wouldn't surprise me that in the next few years many more camera devices will appear with geo-tagging capability built in. The GPX format does not seem to have the expressiveness to cope with what will be a much larger requirement than tracks and waypoints in the near future - geo-tagged image data... So perhaps the wider question is should GPX as a standard be extended to cope with a new type of location data called a "VIEW"? A view would have long, lat AND direction of view. The alternative is to hijack a waypoint or track and kludge the direction into one of these. Richard As far as I can see, --- In gpsxml+yahoogroups.com, "Poco" <kaz+...> wrote: > > --- In gpsxml+yahoogroups.com, "Louis" <clovis+> wrote: > > > > > I have created a locaton recording device for my camera that stores > > > long and lat and the compass direction on a FLASH card in CSV format > > > each time I take a photo. > > > ... > > > Richard > > > > A naive question: why you don't use the time value from your photo > (EXIF tag) to get the gps position from a recorded track? > > Something like OziPhotoTool: > > http://alistairdickie.com/oziphototool/index.html > > > > Louis > > > > There are actually quite a few tools for doing this. Some are free > and some not. The easiest one I've used (free) is from wwmx.org > (Microsoft) and there are other commercial applications (Robogeo at > robogeo.com looks very promising). > > I've written a few thoughts on the process and how I use it here > http://notions.okuda.ca/geotagging/. I agree that it would be nice > for Canon to do this like Nikon, but it takes only a minute to > download your GPS track and stamp your photos with the GPS track. > Robogeo will even export your photo locations to a GPX file as > waypoints as well as the ability to stamp the photo Exif. >
lisah2u+gmail.com on Tue Aug 01 04:27:04 2006 (link), replying to msg
Hi Richard, I have an understanding of your specific problem and can send you a gpx schema extension in a separate email. I'm working on a project where orientation is important, as well. We already contacted topographix and they suggested a custom extension --- as much as possible, we'd like to make it generally available, since like you, I think it's a question of time before most photographic devices have access to a wider array of sensor data such as location and orientation. Lisa On 8/1/06, Richard Jelbert <richard+jelbert.com> wrote: > > Hello > > Indeed there are a number of tools to merge GPS tracks with EXIF data > but as far as I can see, they are all blunt instruments trying to > solve a rather more subtle problem. I'll explain my thinking. > > In the context of taking geo-tagged photographs, GPS tracks or > waypoints stored on the GPS don't record the direction of the device > at the time a photo is taken. Instead they allow you to interpolate > the general direction of travel by looking at multiple track or > waypoints. The reality is that most of the time the camera is pointing > in a completely different direction when a photo is taken. > > I created this GeoTagger device because I wanted to record the exact > compass direction (and location) when the photo was taken. the Garmin > 301 provides both on its serial output in NMEA format so I store it in > a CVS file on the flash card. > > The next generation of mobile camera phones will have GPS, the compact > and D-SLR camera manufacturers are all looking for a differentiators > so it wouldn't surprise me that in the next few years many more camera > devices will appear with geo-tagging capability built in. > > The GPX format does not seem to have the expressiveness to cope with > what will be a much larger requirement than tracks and waypoints in > the near future - geo-tagged image data... > > So perhaps the wider question is should GPX as a standard be extended > to cope with a new type of location data called a "VIEW"? A view would > have long, lat AND direction of view. The alternative is to hijack a > waypoint or track and kludge the direction into one of these. > > Richard > > As far as I can see, > > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, "Poco" <kaz+...> > wrote: > > > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, "Louis" > <clovis+> wrote: > > > > > > > I have created a locaton recording device for my camera that stores > > > > long and lat and the compass direction on a FLASH card in CSV format > > > > each time I take a photo. > > > > ... > > > > Richard > > > > > > A naive question: why you don't use the time value from your photo > > (EXIF tag) to get the gps position from a recorded track? > > > Something like OziPhotoTool: > > > http://alistairdickie.com/oziphototool/index.html > > > > > > Louis > > > > > > > There are actually quite a few tools for doing this. Some are free > > and some not. The easiest one I've used (free) is from wwmx.org > > (Microsoft) and there are other commercial applications (Robogeo at > > robogeo.com looks very promising). > > > > I've written a few thoughts on the process and how I use it here > > http://notions.okuda.ca/geotagging/.<http://notions.okuda.ca/geotagging/>I agree that it would be nice > > for Canon to do this like Nikon, but it takes only a minute to > > download your GPS track and stamp your photos with the GPS track. > > Robogeo will even export your photo locations to a GPX file as > > waypoints as well as the ability to stamp the photo Exif. > > > > > [Non-text portions of this message have been removed]
pratheepacareer+yahoo.co.in on Tue Aug 01 04:30:15 2006 (link)
Hi World's First Largest PCMM Level 5 Company Chennai / Bangalore / Hyderabad / Pune / Kolkata / USA / UK / Singapore / Malaysia Required the following Skills Position 1 ? Java / J2EE Developers [Mail to pratheepa+career- impact.com Experience: 3-12 years Position : Developers / Senior Developers / Project Leaders / Project Managers / Delivery Managers Mandatory skills: Java, J2EE, EJB, Websphere/Weblogic excellent communication skill Location : Chennai / Bangalore / Hyderabad / Pune / Kolkata / USA [Candidates Avalible in US With H1 Visa ] Position 2 ? J2EE With ATG Dynamo[Mail to pratheepa+career- impact.com ] Experience: 3-5 years Position : Developers / Senior Developers / Project Leaders / Project Managers / Delivery Managers Mandatory skills: Java, J2EE, ATG Dynamo excellent communication skill Location : Chennai / Bangalore / Hyderabad / Pune / Kolkata / USA [Candidates Avalible in US With H1 Visa ] Position 3 ? J2EE With Documentum[Mail to pratheepa+career- impact.com Experience: 3-5 years Position : Developers / Senior Developers / Project Leaders / Project Managers / Delivery Managers Mandatory skills: Java, J2EE, XML,Documentum Excellent communication skill. Location : Chennai / Bangalore / Hyderabad / Pune / Kolkata / USA [Candidates Avalible in US With H1 Visa ] Position 4 ? J2EE With MQSERIES [Mail to pratheepa+career-impact.com ] Experience: 3-5 years Position : Developers / Senior Developers / Project Leaders / Project Managers / Delivery Managers Mandatory skills: Java, J2EE, MQ Series, excellent communication skill Location : Chennai / Bangalore / Hyderabad / Pune / Kolkata / USA [Candidates Avalible in US With H1 Visa ] Position 5 ? J2EE With Webmethods [Mail to pratheepa+career- impact.com Experience: 3-5 years Position : Developers / Senior Developers / Project Leaders / Project Managers / Delivery Managers Mandatory skills: Java, J2EE, Webmethods excellent communication skill Location : Chennai / Bangalore / Hyderabad / Pune / Kolkata / USA [Candidates Avalible in US With H1 Visa ] Position 6 ? TIBCO Professionals [Mail to pratheepa+career-impact.com Experience: 3-5 years Position : Developers / Senior Developers / Project Leaders / Project Managers / Delivery Managers Mandatory skills: TIB / Rendevzous,TIBCO Adapters excellent communication skill Location : Chennai / Bangalore / Hyderabad / Pune / Kolkata / USA [Candidates Avalible in US With H1 Visa ] If you are interested, email your resume with contact numbers to pratheepa+career-impact.com We will be Online in Yahoo Chat ID career_impact. With Regards, Pratheepa.k Ph: 98400 70743 E-Mail : pratheepa+career-impact.com Career Impact Consultancy Services Chennai
yahoo+markwigmore.co.uk on Tue Aug 01 06:55:34 2006 (link), replying to msg
Lisa Harper writes: > Hi Richard, I have an understanding of your specific problem and can send > you a gpx schema extension in a separate email. I'm working on a project > where orientation is important, as well. We already contacted topographix > and they suggested a custom extension --- as much as possible, we'd like I understand there used to be a 'heading' field, as well as 'course', in version 1.0. 'Heading' would be ideal for your purpose as it represents the direction you're pointing, whereas 'course' is the direction you're travelling, not always the same thing if you're on water or in the air. I really don't understand why it was removed. Mark
lisah2u+gmail.com on Tue Aug 01 09:50:10 2006 (link), replying to msg
It turns out we haven't finished our GPX extension... but there are some considerations beyond heading. We need a date-uploaded and date-modified as well as support for some additional annotations. Dave, can you give an example of what you mean? Lisa On 8/1/06, Dave Patton <dpatton+confluence.org> wrote: > > Richard Jelbert wrote: > > So perhaps the wider question is should GPX as a standard be extended > > to cope with a new type of location data called a "VIEW"? A view would > > have long, lat AND direction of view. > > A schema for a "view" should be more flexible than just > adding 'compass direction'. It should include all the > data necessary for orthorectification of the photo. > The same type of data used when photographs taken from > airplanes are turned into orthophotos. Having that > capability within the schema wouldn't prevent using > 'just direction' for the type of thing Richard wants > to do, but it would, for example, permit a suitably > equipped small plane to capture and store the data > needed to be able to orthorectify 'photos taken > out the cockpit window'. > > -- > Dave Patton > > Co-Lead Developer, Punt > http://punt.sourceforge.net/ > > Canadian Coordinator, Degree Confluence Project > http://www.confluence.org/ > > Personal website - Maps, GPS, etc. > http://members.shaw.ca/davepatton/ > > > [Non-text portions of this message have been removed]
richard+jelbert.com on Tue Aug 01 11:57:40 2006 (link), replying to msg
Hello David / Lisa I was going to suggest including many of the EXIF tags in the "VIEW" description as this would give much more flexibility when exchanging image related location data between devices and applications. Also, to include aerial photography then height, pitch, roll and yaw (the heading) would cover the cameras position reference the ground. I can just imagine the type of applications like 3D modeling and automated photo stitching that would be possible... I also fly (student PPL) and can see times when a it would be very useful to communicate the pitch of the image to help sort out the straight ahead, 45 degrees down and 90 degrees down images which would basically be like a satellite photo. In the future Google will be able to use this data to help search for just the image you are looking for. My first version of the GeoTagger had a tilt sensor in it to measure tilt angle but I took it out when I switched the GPS over to the Garmin. Might put it back for the next version. I'd be happy to help work on a full spec proposal. Richard --- In gpsxml+yahoogroups.com, Dave Patton <dpatton+...> wrote: > > Richard Jelbert wrote: > > So perhaps the wider question is should GPX as a standard be extended > > to cope with a new type of location data called a "VIEW"? A view would > > have long, lat AND direction of view. > > A schema for a "view" should be more flexible than just > adding 'compass direction'. It should include all the > data necessary for orthorectification of the photo. > The same type of data used when photographs taken from > airplanes are turned into orthophotos. Having that > capability within the schema wouldn't prevent using > 'just direction' for the type of thing Richard wants > to do, but it would, for example, permit a suitably > equipped small plane to capture and store the data > needed to be able to orthorectify 'photos taken > out the cockpit window'. > > -- > Dave Patton > > Co-Lead Developer, Punt > http://punt.sourceforge.net/ > > Canadian Coordinator, Degree Confluence Project > http://www.confluence.org/ > > Personal website - Maps, GPS, etc. > http://members.shaw.ca/davepatton/ >
lisah2u+gmail.com on Tue Aug 01 12:10:31 2006 (link), replying to msg
Speaking of photo stitching... take a look at this... http://labs.live.com/photosynth/ I'm not aware that they are using any of this sort of information to do the things you describe... but this is ground imagery and not aerial. Different issues. Lisa On 8/1/06, Richard Jelbert <richard+jelbert.com> wrote: > > Hello David / Lisa > > I was going to suggest including many of the EXIF tags in the "VIEW" > description as this would give much more flexibility when exchanging > image related location data between devices and applications. > > Also, to include aerial photography then height, pitch, roll and yaw > (the heading) would cover the cameras position reference the ground. > > I can just imagine the type of applications like 3D modeling and > automated photo stitching that would be possible... I also fly > (student PPL) and can see times when a it would be very useful to > communicate the pitch of the image to help sort out the straight > ahead, 45 degrees down and 90 degrees down images which would > basically be like a satellite photo. In the future Google will be able > to use this data to help search for just the image you are looking for. > > My first version of the GeoTagger had a tilt sensor in it to measure > tilt angle but I took it out when I switched the GPS over to the > Garmin. Might put it back for the next version. > > I'd be happy to help work on a full spec proposal. > > Richard > > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, Dave Patton > <dpatton+...> wrote: > > > > Richard Jelbert wrote: > > > So perhaps the wider question is should GPX as a standard be extended > > > to cope with a new type of location data called a "VIEW"? A view would > > > have long, lat AND direction of view. > > > > A schema for a "view" should be more flexible than just > > adding 'compass direction'. It should include all the > > data necessary for orthorectification of the photo. > > The same type of data used when photographs taken from > > airplanes are turned into orthophotos. Having that > > capability within the schema wouldn't prevent using > > 'just direction' for the type of thing Richard wants > > to do, but it would, for example, permit a suitably > > equipped small plane to capture and store the data > > needed to be able to orthorectify 'photos taken > > out the cockpit window'. > > > > -- > > Dave Patton > > > > Co-Lead Developer, Punt > > http://punt.sourceforge.net/ > > > > Canadian Coordinator, Degree Confluence Project > > http://www.confluence.org/ > > > > Personal website - Maps, GPS, etc. > > http://members.shaw.ca/davepatton/ > > > > > [Non-text portions of this message have been removed]
richard+jelbert.com on Tue Aug 01 13:20:01 2006 (link), replying to msg
I spotted that too on the BBC web site. http://news.bbc.co.uk/2/hi/technology/5235724.stm I think the data would be useful when selecting or searching for images of an area that would then feed into photosynth. Richard --- In gpsxml+yahoogroups.com, "Lisa Harper" <lisah2u+...> wrote: > > Speaking of photo stitching... take a look at this... > http://labs.live.com/photosynth/ > > I'm not aware that they are using any of this sort of information to do the > things you describe... but this is ground imagery and not aerial. Different > issues. > > Lisa > > > On 8/1/06, Richard Jelbert <richard+...> wrote: > > > > Hello David / Lisa > > > > I was going to suggest including many of the EXIF tags in the "VIEW" > > description as this would give much more flexibility when exchanging > > image related location data between devices and applications. > > > > Also, to include aerial photography then height, pitch, roll and yaw > > (the heading) would cover the cameras position reference the ground. > > > > I can just imagine the type of applications like 3D modeling and > > automated photo stitching that would be possible... I also fly > > (student PPL) and can see times when a it would be very useful to > > communicate the pitch of the image to help sort out the straight > > ahead, 45 degrees down and 90 degrees down images which would > > basically be like a satellite photo. In the future Google will be able > > to use this data to help search for just the image you are looking for. > > > > My first version of the GeoTagger had a tilt sensor in it to measure > > tilt angle but I took it out when I switched the GPS over to the > > Garmin. Might put it back for the next version. > > > > I'd be happy to help work on a full spec proposal. > > > > Richard > > > > > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, Dave Patton > > <dpatton+> wrote: > > > > > > Richard Jelbert wrote: > > > > So perhaps the wider question is should GPX as a standard be extended > > > > to cope with a new type of location data called a "VIEW"? A view would > > > > have long, lat AND direction of view. > > > > > > A schema for a "view" should be more flexible than just > > > adding 'compass direction'. It should include all the > > > data necessary for orthorectification of the photo. > > > The same type of data used when photographs taken from > > > airplanes are turned into orthophotos. Having that > > > capability within the schema wouldn't prevent using > > > 'just direction' for the type of thing Richard wants > > > to do, but it would, for example, permit a suitably > > > equipped small plane to capture and store the data > > > needed to be able to orthorectify 'photos taken > > > out the cockpit window'. > > > > > > -- > > > Dave Patton > > > > > > Co-Lead Developer, Punt > > > http://punt.sourceforge.net/ > > > > > > Canadian Coordinator, Degree Confluence Project > > > http://www.confluence.org/ > > > > > > Personal website - Maps, GPS, etc. > > > http://members.shaw.ca/davepatton/ > > > > > > > > > > > > [Non-text portions of this message have been removed] >
ajcartmell+fonant.com on Tue Aug 01 14:02:40 2006 (link), replying to msg
> The one function that I want to add to http://routeburner.com is the > ability to accept Tracklogs .trl files. Unfortunately this seems to be > an undocumented proprietary binary format. Can anyone point me to any > documentation for the format, or an open source conversion or reading > tool? Current Tracklogs .trl files are gzip-compressed and hex-encoded XML, contained within a simple XML wrapper. To read them, convert the hex string inside the Data tags to binary, then gzuncompress it. You then have undocumented-but-easy-to-read XML. Shout if you need more help with this, I have a PHP class that reads .trl files. Anthony
dave.paylor+aspiren.com on Wed Aug 02 04:36:07 2006 (link), replying to msg
What about altitude as well? Some GPS can provide this info? I guess if we are talking about potential aerial photography then this becomes even more important? Dave --- In gpsxml+yahoogroups.com, Dave Patton <dpatton+...> wrote: > > Lisa Harper wrote: > > It turns out we haven't finished our GPX extension... but there are > > some considerations beyond heading. We need a date-uploaded and > > date-modified as well as support for some additional annotations. > > > > Dave, can you give an example of what you mean? > > You might need 'camera orientation' info, such as the > camera tilt, etc. > > > > On 8/1/06, Dave Patton <dpatton+...> wrote: > >> Richard Jelbert wrote: > >>> So perhaps the wider question is should GPX as a standard be extended > >>> to cope with a new type of location data called a "VIEW"? A view would > >>> have long, lat AND direction of view. > >> A schema for a "view" should be more flexible than just > >> adding 'compass direction'. It should include all the > >> data necessary for orthorectification of the photo. > >> The same type of data used when photographs taken from > >> airplanes are turned into orthophotos. Having that > >> capability within the schema wouldn't prevent using > >> 'just direction' for the type of thing Richard wants > >> to do, but it would, for example, permit a suitably > >> equipped small plane to capture and store the data > >> needed to be able to orthorectify 'photos taken > >> out the cockpit window'. > >> > >> -- > >> Dave Patton > >> > >> Co-Lead Developer, Punt > >> http://punt.sourceforge.net/ > >> > >> Canadian Coordinator, Degree Confluence Project > >> http://www.confluence.org/ > >> > >> Personal website - Maps, GPS, etc. > >> http://members.shaw.ca/davepatton/ > >> > >> > >> > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > -- > Dave Patton > > Co-Lead Developer, Punt > http://punt.sourceforge.net/ > > Canadian Coordinator, Degree Confluence Project > http://www.confluence.org/ > > Personal website - Maps, GPS, etc. > http://members.shaw.ca/davepatton/ >
lisah2u+gmail.com on Wed Aug 02 04:49:30 2006 (link), replying to msg
It makes sense to encode elements like altitude and heading in the gpx file, if available and useful. But why not just leave the EXIF data pertaining to camera orientation (if available) in the photo... perhaps edit a reference ( e.g., URI) to the GPS track in the EXIF data and do the same in the gpx file? Lisa On 8/2/06, davepaylor <dave.paylor+aspiren.com> wrote: > > What about altitude as well? > > Some GPS can provide this info? > > I guess if we are talking about potential aerial photography then > this becomes even more important? > > Dave > > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, Dave Patton > <dpatton+...> wrote: > > > > Lisa Harper wrote: > > > It turns out we haven't finished our GPX extension... but there > are > > > some considerations beyond heading. We need a date-uploaded and > > > date-modified as well as support for some additional annotations. > > > > > > Dave, can you give an example of what you mean? > > > > You might need 'camera orientation' info, such as the > > camera tilt, etc. > > > > > > > On 8/1/06, Dave Patton <dpatton+...> wrote: > > >> Richard Jelbert wrote: > > >>> So perhaps the wider question is should GPX as a standard be > extended > > >>> to cope with a new type of location data called a "VIEW"? A > view would > > >>> have long, lat AND direction of view. > > >> A schema for a "view" should be more flexible than just > > >> adding 'compass direction'. It should include all the > > >> data necessary for orthorectification of the photo. > > >> The same type of data used when photographs taken from > > >> airplanes are turned into orthophotos. Having that > > >> capability within the schema wouldn't prevent using > > >> 'just direction' for the type of thing Richard wants > > >> to do, but it would, for example, permit a suitably > > >> equipped small plane to capture and store the data > > >> needed to be able to orthorectify 'photos taken > > >> out the cockpit window'. > > >> > > >> -- > > >> Dave Patton > > >> > > >> Co-Lead Developer, Punt > > >> http://punt.sourceforge.net/ > > >> > > >> Canadian Coordinator, Degree Confluence Project > > >> http://www.confluence.org/ > > >> > > >> Personal website - Maps, GPS, etc. > > >> http://members.shaw.ca/davepatton/ > > >> > > >> > > >> > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Dave Patton > > > > Co-Lead Developer, Punt > > http://punt.sourceforge.net/ > > > > Canadian Coordinator, Degree Confluence Project > > http://www.confluence.org/ > > > > Personal website - Maps, GPS, etc. > > http://members.shaw.ca/davepatton/ > > > > > [Non-text portions of this message have been removed]
chris+ainslie.co.za on Wed Aug 02 05:12:38 2006 (link)
Wise words Lisa. Certainly the most sane way to do this is to keep the data separated, yet linked. Only include location based data in the GPX file, while picture data can stay in the image file (EXIF). Orientation would be picture data in my opinion, altitude would be location data. Using a custom "extension" would be the way to tie the two together with a URI or similar reference. Personally, I don't like the idea of "geotagging" as it is currently being done. My application (offline and custom designed for a client) uses the logic of two separate files (jpg & gpx) instead of encoding the coordinates into the EXIF data. This way, you can manipulate the data in far more interesting ways. Chris. Chris Ainslie chris+ainslie.co.za 078 209 8955 Skype: cainslie _____ From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Lisa Harper Sent: 02 August 2006 01:48 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Re: camera device - tagging compass direction It makes sense to encode elements like altitude and heading in the gpx file, if available and useful. But why not just leave the EXIF data pertaining to camera orientation (if available) in the photo... perhaps edit a reference ( e.g., URI) to the GPS track in the EXIF data and do the same in the gpx file? Lisa On 8/2/06, davepaylor <dave.paylor+ <mailto:dave.paylor%40aspiren.com> aspiren.com> wrote: > > What about altitude as well? > > Some GPS can provide this info? > > I guess if we are talking about potential aerial photography then > this becomes even more important? > > Dave > > > --- In gpsxml+yahoogroups. <mailto:gpsxml%40yahoogroups.com> com <gpsxml%40yahoogroups.com>, Dave Patton > <dpatton+...> wrote: > > > > Lisa Harper wrote: > > > It turns out we haven't finished our GPX extension... but there > are > > > some considerations beyond heading. We need a date-uploaded and > > > date-modified as well as support for some additional annotations. > > > > > > Dave, can you give an example of what you mean? > > > > You might need 'camera orientation' info, such as the > > camera tilt, etc. > > > > > > > On 8/1/06, Dave Patton <dpatton+...> wrote: > > >> Richard Jelbert wrote: > > >>> So perhaps the wider question is should GPX as a standard be > extended > > >>> to cope with a new type of location data called a "VIEW"? A > view would > > >>> have long, lat AND direction of view. > > >> A schema for a "view" should be more flexible than just > > >> adding 'compass direction'. It should include all the > > >> data necessary for orthorectification of the photo. > > >> The same type of data used when photographs taken from > > >> airplanes are turned into orthophotos. Having that > > >> capability within the schema wouldn't prevent using > > >> 'just direction' for the type of thing Richard wants > > >> to do, but it would, for example, permit a suitably > > >> equipped small plane to capture and store the data > > >> needed to be able to orthorectify 'photos taken > > >> out the cockpit window'. > > >> > > >> -- > > >> Dave Patton > > >> > > >> Co-Lead Developer, Punt > > >> http://punt. <http://punt.sourceforge.net/> sourceforge.net/ > > >> > > >> Canadian Coordinator, Degree Confluence Project > > >> http://www.confluen <http://www.confluence.org/> ce.org/ > > >> > > >> Personal website - Maps, GPS, etc. > > >> http://members. <http://members.shaw.ca/davepatton/> shaw.ca/davepatton/ > > >> > > >> > > >> > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Dave Patton > > > > Co-Lead Developer, Punt > > http://punt. <http://punt.sourceforge.net/> sourceforge.net/ > > > > Canadian Coordinator, Degree Confluence Project > > http://www.confluen <http://www.confluence.org/> ce.org/ > > > > Personal website - Maps, GPS, etc. > > http://members. <http://members.shaw.ca/davepatton/> shaw.ca/davepatton/ > > > > > [Non-text portions of this message have been removed] [Non-text portions of this message have been removed]
mark+pfeifers.org on Wed Aug 02 08:11:55 2006 (link)
I've been lurking here for a few days, and I guess it's time to break my silence. I'm Mark Pfeifer and I live in Delaware, USA. I've been using the Microsoft Research WWMX utilities to record tracklog from my Garmin GPSMAP 76S and match the log with pictures off of my Nikon D70. I came to gpsxml because I wasn't entirely happy with the WWMX utilities and wanted to read the GMX 1.0 files directly. My first attempt was to process the GMX 1.0 schema through the .Net 2.0 XSD utility to generate a set of classes and use .Net XML serialization to read the GMX file and create instances of the generated classes. This failed. Before I get in to questions about code to read GMX files, is there an easier alternative? Are there better utilities for doing basic GPS coordinate insertion into JPG files than the WWMX utilities? My needs are pretty basic - I don't need to know what direction I was facing, for instance. I just want to encode where each picture was taken into the picture. Thanks for any assistance. Mark Pfeifer
richard+jelbert.com on Wed Aug 02 09:35:17 2006 (link), replying to msg
Hello I think it's important to think of how geotagged images will be used in the future and why it is different from the current waypoint and track data usage. Personally I believe that the location and orientation information should be included in a GPX extension. Here are the reasons: 1) The data is probably coming from different sources right now. The camera is taking the image but a separate system or device is capturing the orientation and location data. A data format is required that can link the two together and will work in isolation and offline. 2) When cameras do have built in GPS and compass in the future, users might want to share the location/orientation information without passing around the image (as with the EXIF way). 3) Searching against geotagged data without having to trawl through the 8MB images will be key in the future. Separating the tag information from the image is the best route forward long term. 4) A geo-tagged image is only as useful as the data that describes it. Having location and altitude but not the orientation information takes away the ability to work out of the image is any use for the person searching a database for it (without having to physically look at all the pictures or getting access to the EXIF from the source images!) I am writing a proposal document for a "Viewpoint" schema extension to GPX and will post it to this group shortly. Hope it stimulates debate. Regards Richard --- In gpsxml+yahoogroups.com, "Chris Ainslie" <chris+...> wrote: > > Wise words Lisa. > > Certainly the most sane way to do this is to keep the data separated, yet > linked. Only include location based data in the GPX file, while picture > data can stay in the image file (EXIF). Orientation would be picture data > in my opinion, altitude would be location data. Using a custom "extension" > would be the way to tie the two together with a URI or similar reference. > > Personally, I don't like the idea of "geotagging" as it is currently being > done. My application (offline and custom designed for a client) uses the > logic of two separate files (jpg & gpx) instead of encoding the coordinates > into the EXIF data. This way, you can manipulate the data in far more > interesting ways. > > Chris. > > Chris Ainslie > chris+... > 078 209 8955 > Skype: cainslie > > > _____ > > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of > Lisa Harper > Sent: 02 August 2006 01:48 PM > To: gpsxml+yahoogroups.com > Subject: Re: [gpsxml] Re: camera device - tagging compass direction > > > > It makes sense to encode elements like altitude and heading in the gpx file, > if available and useful. But why not just leave the EXIF data pertaining to > camera orientation (if available) in the photo... perhaps edit a reference ( > e.g., URI) to the GPS track in the EXIF data and do the same in the gpx > file? > Lisa > > On 8/2/06, davepaylor <dave.paylor+ <mailto:dave.paylor%40aspiren.com> > aspiren.com> wrote: > > > > What about altitude as well? > > > > Some GPS can provide this info? > > > > I guess if we are talking about potential aerial photography then > > this becomes even more important? > > > > Dave > > > > > > --- In gpsxml+yahoogroups. <mailto:gpsxml%40yahoogroups.com> com > <gpsxml%40yahoogroups.com>, Dave Patton > > <dpatton+> wrote: > > > > > > Lisa Harper wrote: > > > > It turns out we haven't finished our GPX extension... but there > > are > > > > some considerations beyond heading. We need a date-uploaded and > > > > date-modified as well as support for some additional annotations. > > > > > > > > Dave, can you give an example of what you mean? > > > > > > You might need 'camera orientation' info, such as the > > > camera tilt, etc. > > > > > > > > > > On 8/1/06, Dave Patton <dpatton+> wrote: > > > >> Richard Jelbert wrote: > > > >>> So perhaps the wider question is should GPX as a standard be > > extended > > > >>> to cope with a new type of location data called a "VIEW"? A > > view would > > > >>> have long, lat AND direction of view. > > > >> A schema for a "view" should be more flexible than just > > > >> adding 'compass direction'. It should include all the > > > >> data necessary for orthorectification of the photo. > > > >> The same type of data used when photographs taken from > > > >> airplanes are turned into orthophotos. Having that > > > >> capability within the schema wouldn't prevent using > > > >> 'just direction' for the type of thing Richard wants > > > >> to do, but it would, for example, permit a suitably > > > >> equipped small plane to capture and store the data > > > >> needed to be able to orthorectify 'photos taken > > > >> out the cockpit window'. > > > >> > > > >> -- > > > >> Dave Patton > > > >> > > > >> Co-Lead Developer, Punt > > > >> http://punt. <http://punt.sourceforge.net/> sourceforge.net/ > > > >> > > > >> Canadian Coordinator, Degree Confluence Project > > > >> http://www.confluen <http://www.confluence.org/> ce.org/ > > > >> > > > >> Personal website - Maps, GPS, etc. > > > >> http://members. <http://members.shaw.ca/davepatton/> > shaw.ca/davepatton/ > > > >> > > > >> > > > >> > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Dave Patton > > > > > > Co-Lead Developer, Punt > > > http://punt. <http://punt.sourceforge.net/> sourceforge.net/ > > > > > > Canadian Coordinator, Degree Confluence Project > > > http://www.confluen <http://www.confluence.org/> ce.org/ > > > > > > Personal website - Maps, GPS, etc. > > > http://members. <http://members.shaw.ca/davepatton/> shaw.ca/davepatton/ > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > [Non-text portions of this message have been removed] >
kaz+okuda.ca on Wed Aug 02 11:42:46 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Mark Pfeifer" <mark+...> wrote: > > I've been lurking here for a few days, and I guess it's time to break > my silence. I'm Mark Pfeifer and I live in Delaware, USA. > > I've been using the Microsoft Research WWMX utilities to record > tracklog from my Garmin GPSMAP 76S and match the log with pictures off > of my Nikon D70. I came to gpsxml because I wasn't entirely happy > with the WWMX utilities and wanted to read the GMX 1.0 files directly. > > My first attempt was to process the GMX 1.0 schema through the .Net > 2.0 XSD utility to generate a set of classes and use .Net XML > serialization to read the GMX file and create instances of the > generated classes. This failed. > > Before I get in to questions about code to read GMX files, is there an > easier alternative? Are there better utilities for doing basic GPS > coordinate insertion into JPG files than the WWMX utilities? My needs > are pretty basic - I don't need to know what direction I was facing, > for instance. I just want to encode where each picture was taken into > the picture. > > Thanks for any assistance. > > Mark Pfeifer > This looks like a good time for a shameless plug. I have been doing the same and written about some of it here http://notions.okuda.ca/geotagging/. I've been considering writing something of my own as well, but I just can't find the time. My plan is to make a browser based tool to avoid the "install" overhead and potentially make it server based. Reading the GPX files directly is easy with Javascript and the DOM. I have written a browser based GPX viewer that does just that http://notions.okuda.ca/geotagging/projects-im-working-on/gpx-viewer/. One promising looking application is RoboGeo. It looks like it has similar functionality, plus more, and isn't too expensive http://www.robogeo.com/home/.
avalon73+caerleon.us on Tue Aug 08 06:31:23 2006 (link), replying to msg
On Thu, 27 Jul 2006, Brian Smith wrote: > CacheMate can import GPX 1.0 and 1.1 with extensions, but at present is > only writing 1.0. You're right in that it wouldn't take much to add 1.1 > writing, but I haven't done it yet pretty much for the same reasons as > Robert stated. That changed as of last night, at least for the Pocket PC version, but I'd still be interested in what is capable of reading it at the moment :-) I had some other changes to make, and decided to toss that one in as an option. -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator People are more violently opposed to fur than to leather because it's safer to harass rich women than motorcycle gangs.
sweetfashions6+yahoo.com on Tue Aug 15 00:24:51 2006 (link)
please join my group : http://groups.yahoo.com/group/myspacelayout --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. [Non-text portions of this message have been removed]
dewchugr+yahoo.com on Tue Aug 15 07:38:09 2006 (link)
If I allow users to upload GPX files I would like to verify that they are valid GPX files or at the very least valid XML files. Has anyone done this or know the best way to go about it? Thanks, Steve
ldgregory+gmail.com on Tue Aug 15 09:02:10 2006 (link), replying to msg
Hello dewchugr, Tuesday, August 15, 2006, 8:33:11 AM, you wrote: > If I allow users to upload GPX files I would like to verify that > they are valid GPX files or at the very least valid XML files. > > Has anyone done this or know the best way to go about it? What language? If PHP, this might help. http://www.phpbuilder.com/columns/adam_delves20060719.php3 -- TBUDL/BETA/DEV/TECH Lists Moderator / PGP 0x5D167202 __ ____ ____ ____ Geocaching: http://gps.PCWize.com ( ) ( ___)(_ _)( ___) TBUDP Wiki Site: http://www.PCWize.com/thebat/tbudp )(__ )__) _)(_ )__) Roguemoticons & Smileys: http://PCWize.com/thebat (____)(____)(____)(__) PHP Tutorials and snippets: http://www.DevTek.org Slurm, n.: The slime that accumulates on the underside of a soap bar when it sits in the dish too long. -- Rich Hall, "Sniglets"
dewchugr+yahoo.com on Tue Aug 15 12:14:55 2006 (link), replying to msg
Yes PHP. Thanks, I'll take a look at that link. Steve --- In gpsxml+yahoogroups.com, Leif Gregory <ldgregory+...> wrote: > > Hello dewchugr, > > Tuesday, August 15, 2006, 8:33:11 AM, you wrote: > > If I allow users to upload GPX files I would like to verify that > > they are valid GPX files or at the very least valid XML files. > > > > Has anyone done this or know the best way to go about it? > > What language? If PHP, this might help. > > http://www.phpbuilder.com/columns/adam_delves20060719.php3 > > > -- > TBUDL/BETA/DEV/TECH Lists Moderator / PGP 0x5D167202 > __ ____ ____ ____ Geocaching: http://gps.PCWize.com > ( ) ( ___)(_ _)( ___) TBUDP Wiki Site: http://www.PCWize.com/thebat/tbudp > )(__ )__) _)(_ )__) Roguemoticons & Smileys: http://PCWize.com/thebat > (____)(____)(____)(__) PHP Tutorials and snippets: http://www.DevTek.org > > Slurm, n.: The slime that accumulates on the underside of a soap bar when it > sits in the dish too long. -- Rich Hall, "Sniglets" >
gpsxml+yahoogroups.com on Wed Aug 16 09:28:33 2006 (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 : /Viewpoint_proposal_V1_01.doc Uploaded by : richardjelbert <richard+jelbert.com> Description : GPX Viewpoint schema proposal v1.01 You can access this file at the URL: http://groups.yahoo.com/group/gpsxml/files/Viewpoint_proposal_V1_01.doc To learn more about file sharing for your group, please visit: http://help.yahoo.com/help/us/groups/files Regards, richardjelbert <richard+jelbert.com>
richard+jelbert.com on Wed Aug 16 09:35:55 2006 (link)
Hello I've just uploaded my proposal to extend the GPX standard to support GPS enabled cameras. The Viewpoint as I've called it is based on a waypoint but also inludes direction and other camera orientation information. Many thanks to those who have provided feedback so far. I am now very interested to see if anyone else supports my ideas and to see if the GPX standard is the right home for a solution. The proposal document is on the files section of this Yahoo group. Many thanks Richard www.jelbert.com
steveg+swapneat.com on Wed Aug 16 12:04:28 2006 (link), replying to msg
Richard Jelbert wrote: Hi Richard Thanks for crafting this document. It really brings a lot of good perspective on the topic. I too am very interested in geotagging images, but with a bias towards embedding into the image files. I see the value in your Viewpoint Schema as a parallel and very valuable approach. This format could be embedded in image files too, but i agree with you that having the information separate from the images speeds searching significantly. I wanted to express my particular preferences while there's still a chance to make compatible improvements... In particular, to support image stitching, the values for lat, long, and pitch, head, roll, g_height, and s_height and flen all need to be able to support floating point values, preferably double precision. By mentioning these in the schema early, it will prevent applications from having trouble if a floating point value is seen later. In my particular application, camera distortions are also a factor, but i think that information can be embedded into the image rather than the vpt struct. However, there's one thing that might be added to considerably simplify the process... I guess since a camera might scale differentially in x and y, (pixels not necessarily square) and this might affect whether a view direction includes an object, there might be some value in being able to specify this information here, but it's pretty obscure, and most cameras use approximately square pixels anyway. What i am trying to get at is that the aspect ratio of the picture, and the focal length say a lot about what's in the field of view. The resolution of the picture implies the aspect ratio but does not actually guarantee it. Allowing a pixel aspect ratio float value would be sufficient. It would be nominally 1.0 if not present. It would represent the angular extent of a pixel in the nominal X direction divided by that extent in Y, and would basically be a property of the camera that took the picture. Thanks for bringing this information together so well. Steve Germann > Hello > > I've just uploaded my proposal to extend the GPX standard to support > GPS enabled cameras. The Viewpoint as I've called it is based on a > waypoint but also inludes direction and other camera orientation > information. > > Many thanks to those who have provided feedback so far. I am now very > interested to see if anyone else supports my ideas and to see if the > GPX standard is the right home for a solution. > > The proposal document is on the files section of this Yahoo group. > > Many thanks > > Richard > www.jelbert.com > >
jhedmonton+hotmail.com on Wed Aug 16 14:12:44 2006 (link)
Hi I have written a GPS program called FarmerGPS (www.farmergps.com). It currently stores GPS data in a text file and I'd like to use GPX as an export format. I started with .net 2.0, the xsd file and created classes. What I wondering about isn't latitude, longitude information BUT coverage area. FarmerGPS is a GPS guidance program. It records lat, lon information BUT also the witdh of your equipment. So when a farmer is seeding with a 51' seeder, I have the center latitude and longitude and the path he is going. How do I add the width information of 51' in GPX? Comments? ideas? Any help is greatly appriciated! Johannes
kerry.raymond+gmail.com on Wed Aug 16 15:18:32 2006 (link)
Yes, the proposal is a good starting point. I also share the concern about whether the data is in the image file or external to it. I think the trick here is to define a format that can be use both internally or externally. Personally I am of the view that every image should carry its own metadata (or else it invariably gets separated -- look at all those photo album programs where you spend hours keying in captions only to lose that data when you give the images to a friend). If the data is in the image, it can always be extracted into a external form and of course vice versa. For this reason, I'd see elements like <image> as optional as they would not be needed for the internal format. I am not terribly comfortable with the lat/long appearing as XML attributes instead of XML elements. I presume this is for consistency with waypoints etc in GPX (and yeah I think GPX got it wrong). The drawback is that attributes can't be extended in the way elements can be. One thing we might also want to consider (and probably implement through extending the elements -- which is why I worry about the use of XML attributes) is support for accuracy/precision in values. With GPS, we know there might be a 10 metre error. WIth differential GPS or NGSS, we expect that to be a lot smaller. It would be good to have a way to capture accuracy (I'd see it as an optional element within the various other elements). Of course, this is not just about viewpoints but about GPX generally. But when we start talking about geocoding photos, accuracy becomes a lot more of an issue. Why? Because some of the geocoding data may not be coming from a GPS but may be based on people using a map or Google Earth and a very rough clock to retrospectively add geo-coding to existing photos. For example, suppose I have a photo of grandma as a girl taken at the family farm. I might get my lat/long from a map and the time will be "about 1920". The accuracy here will be way-off the accuracy we are accustomed to with GPS. So while GPX use has traditionally been by GPS users, geocoding of photos may introduce non-GPS users into the mix. Of course, there is no guarantee that any user would provide the accuracy data, but if there's no provision for it, they certainly won't. Actually, I can see a nice extension to Google Earth (or other GIS display tool) where you upload some non-geo-coded photos and then navigate to the place you think the photos were taken and then rotating the view to get the heading information and then save the geo-coding into the photo files. Once we have search engines tools that do things like "find me the view from this place" and online tools that stitch such photos into panoramas or mosaics, I can see a lot of people keen to add geo-coding into existing photo images. Also, I think we want to be careful to limit the proposal to the positional information. The proposal includes elements for focal length and image resolution that relate to the image itself. But why not all the other data that a digital camera typically captures (shutter speed, exposure time, flash mode, etc)? This opens up a much larger can of worms. It's better think to define an element <imagedata> for putting this stuff but leave its contents unspecified. Then let the image community people come up with XML schemas they think appropriate. The proposal makes the comment about the <name> being unique. Fat chance! A lot of cameras use the same file naming schemes :-) And where we are talking about internal meta-data, it is irrelevant. Obviously when we have a number of images with external metadata, we want to have those images uniquely named relative to the collection as a whole. But this is situation-dependent. If they are a collection of photos on the WWW, then URL would be the unique name. If they are a collection of photos on a disk, then filename is the unique name. If the meta-data is held internally, then anyone making a collection of photos (for whatever purpose) can extract the meta-data into the external form and add the <name> in the external format using whatever name the image is called in that context. Put simply, "unique name" is not an inherent property of the image, it is an artefact of the container in which the images are agggregated. On the minor quibble, we need to define the units for everything. And I encourage the use of "-90.0" rather than "L90" to make it easier to process. Probably a good test of getting the design of GPX Viewpoint right is to see whether it can be converted to/from Google Earth's KML schema. If it can't, then that tells us something's not quite right. This does not mean they have to be identical in their information content, but that they can be "usefully" converted. Kerry [Non-text portions of this message have been removed]
dananderson2+yahoo.com on Thu Aug 17 11:04:57 2006 (link), replying to msg
A typo: You have "<imgage>" in the example. You have "<image>" in the description. Dan A.
ldgregory+gmail.com on Thu Aug 17 11:36:47 2006 (link), replying to msg
Hello jhedmonton, Wednesday, August 16, 2006, 3:07:16 PM, you wrote: > FarmerGPS is a GPS guidance program. It records lat, lon information > BUT also the witdh of your equipment. So when a farmer is seeding > with a 51' seeder, I have the center latitude and longitude and the > path he is going. How do I add the width information of 51' in GPX? I'd stick it in the <cmt> node. The comment isn't required that I know of, and it's general purpose use I think would work for you. Plus when you transfer the waypoint to the GPSr, the comment is usually available in most GPSrs. -- TBUDL/BETA/DEV/TECH Lists Moderator / PGP 0x5D167202 __ ____ ____ ____ Geocaching: http://gps.PCWize.com ( ) ( ___)(_ _)( ___) TBUDP Wiki Site: http://www.PCWize.com/thebat/tbudp )(__ )__) _)(_ )__) Roguemoticons & Smileys: http://PCWize.com/thebat (____)(____)(____)(__) PHP Tutorials and snippets: http://www.DevTek.org Stare at someone long enough, eventually you'll get what you want.
jhedmonton+hotmail.com on Thu Aug 17 11:53:13 2006 (link), replying to msg
Hi Lelf, thanks for the quick reply! The problem with the cmt node is that I may be able to save the info, but no other GPX program will be able to display the width of the track. I was hoping I could make other GPX capable programs display a proper coverage map. Maybe that can't be done? Johannes >From: Leif Gregory <ldgregory+gmail.com> >Reply-To: gpsxml+yahoogroups.com >To: jhedmonton <gpsxml+yahoogroups.com> >Subject: Re: [gpsxml] Newbie wants to write gpx file >Date: Thu, 17 Aug 2006 12:22:36 -0600 > >Hello jhedmonton, > >Wednesday, August 16, 2006, 3:07:16 PM, you wrote: > > FarmerGPS is a GPS guidance program. It records lat, lon information > > BUT also the witdh of your equipment. So when a farmer is seeding > > with a 51' seeder, I have the center latitude and longitude and the > > path he is going. How do I add the width information of 51' in GPX? > >I'd stick it in the <cmt> node. The comment isn't required that I know >of, and it's general purpose use I think would work for you. Plus when >you transfer the waypoint to the GPSr, the comment is usually >available in most GPSrs. > >-- > TBUDL/BETA/DEV/TECH Lists Moderator / PGP >0x5D167202 > __ ____ ____ ____ Geocaching: >http://gps.PCWize.com >( ) ( ___)(_ _)( ___) TBUDP Wiki Site: >http://www.PCWize.com/thebat/tbudp > )(__ )__) _)(_ )__) Roguemoticons & Smileys: >http://PCWize.com/thebat >(____)(____)(____)(__) PHP Tutorials and snippets: >http://www.DevTek.org > >Stare at someone long enough, eventually you'll get what you want. > >
ldgregory+gmail.com on Thu Aug 17 12:48:21 2006 (link), replying to msg
Hello Johannes, Thursday, August 17, 2006, 12:42:01 PM, you wrote: > thanks for the quick reply! The problem with the cmt node is that I > may be able to save the info, but no other GPX program will be able > to display the width of the track. I was hoping I could make other > GPX capable programs display a proper coverage map. Ohhhhhhhh. Now I understand what you're after. I'm not definite, but I don't think you can specify a track width. The only thing I can think of is to do some calculations in your program for the following: 1. Get the starting coordinate 2. Get the ending coordinate 3. Calculate the area 4. Divide that by the width of the seeder on the side perpendicular to the direction of the track which will tell you how many tracks you'd need to make. 5. Then some crazy math to actually put lat/long coords to the start and end points for each pass. 6. Put that in a GPX file as a route. The only real caveat I can see to this is if their starting coordinate and ending coordinate end on the same lat or long as they started. i.e. he started seeding by going due North, and finished seeding heading due South which means that while the longitude changed due to the East/West travel, the latitude wouldn't reflect how far he drove North before turning around to lay down the next track of seed in the Southbound direction. You'd have to look at some intermediary point to determine that. Then again, I could be making this so much more difficult than it should be. Won't be the first time, and I'll just make my excuses as being a natural blonde. <grin> -- TBUDL/BETA/DEV/TECH Lists Moderator / PGP 0x5D167202 __ ____ ____ ____ Geocaching: http://gps.PCWize.com ( ) ( ___)(_ _)( ___) TBUDP Wiki Site: http://www.PCWize.com/thebat/tbudp )(__ )__) _)(_ )__) Roguemoticons & Smileys: http://PCWize.com/thebat (____)(____)(____)(__) PHP Tutorials and snippets: http://www.DevTek.org See, these two penguins walked into a bar, which was really stupid, 'cause the second one should have seen it
egroups+topografix.com on Thu Aug 17 13:29:27 2006 (link), replying to msg
Hello, Thursday, August 17, 2006, 2:42:01 PM, Johannes wrote: > The problem with the cmt node is that I may be able to save the info, but no > other GPX program will be able to display the width of the track. > I was hoping I could make other GPX capable programs display a proper > coverage map. > Maybe that can't be done? > Johannes http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd The GPX style schema contains a line width element. The default usage is to specify the width in millimeters of the line on a map at 1:24,000 scale. Since you have a real-world width in meters, you can convert that to an appropriate value using some math: double ConvertMillimetersToMeters( double dblWidthMillimeters ) { // divide by 1000 to convert millimeters to meters // multiply by USGS map scale (24000) return dblWidthMillimeters * 24000.0 / 1000.0; } double ConvertMetersToMillimeters( double dblWidthMeters ) { return dblWidthMeters * 1000.0 / 24000.0; } ExpertGPS implements this, if you are looking for a program to test against. http://www.expertgps.com -- Dan Foster
ldgregory+gmail.com on Thu Aug 17 14:17:31 2006 (link), replying to msg
Hello Dan, Thursday, August 17, 2006, 2:09:51 PM, you wrote: > The GPX style schema contains a line width element. The default > usage is to specify the width in millimeters of the line on a map at > 1:24,000 scale. Since you have a real-world width in meters, you can > convert that to an appropriate value using some math: Learn something new every day. Thanks Dan. -- TBUDL/BETA/DEV/TECH Lists Moderator / PGP 0x5D167202 __ ____ ____ ____ Geocaching: http://gps.PCWize.com ( ) ( ___)(_ _)( ___) TBUDP Wiki Site: http://www.PCWize.com/thebat/tbudp )(__ )__) _)(_ )__) Roguemoticons & Smileys: http://PCWize.com/thebat (____)(____)(____)(__) PHP Tutorials and snippets: http://www.DevTek.org Spelunk: The sound you make as you hit the bottom of the cave.
jhedmonton+hotmail.com on Thu Aug 17 16:32:41 2006 (link), replying to msg
Great news!! Will try this out. Thanks, Johannes >From: Dan Foster <egroups+topografix.com> >Reply-To: gpsxml+yahoogroups.com >To: Johannes Heupel <gpsxml+yahoogroups.com> >Subject: Re[2]: [gpsxml] Newbie wants to write gpx file >Date: Thu, 17 Aug 2006 16:09:51 -0400 > >Hello, > >Thursday, August 17, 2006, 2:42:01 PM, Johannes wrote: > > > The problem with the cmt node is that I may be able to save the info, >but no > > other GPX program will be able to display the width of the track. > > I was hoping I could make other GPX capable programs display a proper > > coverage map. > > Maybe that can't be done? > > Johannes > >http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd > >The GPX style schema contains a line width element. The default usage >is to specify the width in millimeters of the line on a map at >1:24,000 scale. Since you have a real-world width in meters, you can >convert that to an appropriate value using some math: > >double ConvertMillimetersToMeters( double dblWidthMillimeters ) >{ > // divide by 1000 to convert millimeters to meters > // multiply by USGS map scale (24000) > return dblWidthMillimeters * 24000.0 / 1000.0; >} > >double ConvertMetersToMillimeters( double dblWidthMeters ) >{ > return dblWidthMeters * 1000.0 / 24000.0; >} > >ExpertGPS implements this, if you are looking for a program to test >against. http://www.expertgps.com > >-- >Dan Foster >
kerry.raymond+gmail.com on Fri Aug 18 00:56:27 2006 (link)
> http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd > The GPX style schema contains a line width element. The default usage > is to specify the width in millimeters of the line on a map at > 1:24,000 scale. Perhaps I'm a bit confused here, but how does the schema above relate to GPX (as defined by the schema in the File area of this yahoo group)? Is this a private extension? A widely supported extension? Kerry
parang.saraf+gmail.com on Sun Aug 20 14:03:22 2006 (link)
Hi, I am trying to develop a decision support system which takes in information from a spatial database, perform some queries and publish the result in a well structured form(GML/XML) so that it can be used by the users. It should also be able to input information from the user and update the database accordingly. I am having a spatial database (Postgres-postgis / oracle ) having spatial data. Now I want to use GML/XML as a transporting agent to do this data transportation for me. I should be able to take the GML data from the user and store it in the database and vice - verse. I randomly did some net surfing, read some papers and books on XML/GML for finding out a way to do this. But still i am not able to find any heading. I am relatively new in this field. I will highly appreciate if you can guide me in this regard or can provide me with some links or similar work, basically some sort of heading. It would be a great help If I can get some example xml/gml files and scripts for doing this work. Thanks and Regards Parang Saraf parang.saraf+gmail.com [Non-text portions of this message have been removed]
mhoegh+gmail.com on Mon Aug 21 00:21:02 2006 (link), replying to msg
Hi, I've written a php lib that can do that: http://appformap.cvs.sourceforge.net/appformap/appformap/libs/phpgeometry_class.php?revision=1.8&view=markup $g=new gmlConverter; $wkt=$g->gmlToWKT($gml); // $gml is a gml feed print_r($wkt); // $wkt is an array with the geo features in wkt (well know text format). Wkt can be inserted in a postgis table. The lib can also do the revers: $g=new geometryfactory; $geoObejct=$g->createGeometry($wkt); // takes a wkt string $gml=$geoObejct->getGML();// $gml is the geo feature in gml format On 8/20/06, Parang Saraf <parang.saraf+gmail.com> wrote: > > Hi, > > I am trying to develop a decision support system which takes in > information > from a spatial database, perform some queries and publish the result in a > well structured form(GML/XML) so that it can be used by the users. It > should > also be able to input information from the user and update the database > accordingly. > > I am having a spatial database (Postgres-postgis / oracle ) having spatial > data. Now I want to use GML/XML as a transporting agent to do this data > transportation for me. I should be able to take the GML data from the user > and store it in the database and vice - verse. > > I randomly did some net surfing, read some papers and books on XML/GML for > finding out a way to do this. But still i am not able to find any heading. > I > am relatively new in this field. I will highly appreciate if you can guide > me in this regard or can provide me with some links or similar work, > basically some sort of heading. > > It would be a great help If I can get some example xml/gml files and > scripts > for doing this work. > > Thanks and Regards > Parang Saraf > parang.saraf+gmail.com <parang.saraf%40gmail.com> > > [Non-text portions of this message have been removed] > > > [Non-text portions of this message have been removed]
jhedmonton+hotmail.com on Tue Aug 22 09:24:37 2006 (link), replying to msg
Hi Dan, I like your idea and I am in the process of extending FarmerGPS so it has an option to export to ExpertGPS. Unfortunetly I am having some trouble with extending the GPX.xds with the linetype. All I really need (for now) is the linetype as part of the extensions on trk. Since I am using .net and the class generation tool xsd I was going to modify GPX.xsd, adding the linetype defintions to the extensions on trktype and generate new classes with the tool. Since I am a newbie on XML and XSD I am having trouble just doing that. Can you help? Do you have a file GPXextended.xsd which includes the proper GPX.xsd PLUS the extensions (linetype is all I need) so I can generate .net classes? Any other/better suggestions? Thanks, Johannes >From: Dan Foster <egroups+topografix.com> >Reply-To: gpsxml+yahoogroups.com >To: Johannes Heupel <gpsxml+yahoogroups.com> >Subject: Re[2]: [gpsxml] Newbie wants to write gpx file >Date: Thu, 17 Aug 2006 16:09:51 -0400 > >Hello, > >Thursday, August 17, 2006, 2:42:01 PM, Johannes wrote: > > > The problem with the cmt node is that I may be able to save the info, >but no > > other GPX program will be able to display the width of the track. > > I was hoping I could make other GPX capable programs display a proper > > coverage map. > > Maybe that can't be done? > > Johannes > >http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd > >The GPX style schema contains a line width element. The default usage >is to specify the width in millimeters of the line on a map at >1:24,000 scale. Since you have a real-world width in meters, you can >convert that to an appropriate value using some math: > >double ConvertMillimetersToMeters( double dblWidthMillimeters ) >{ > // divide by 1000 to convert millimeters to meters > // multiply by USGS map scale (24000) > return dblWidthMillimeters * 24000.0 / 1000.0; >} > >double ConvertMetersToMillimeters( double dblWidthMeters ) >{ > return dblWidthMeters * 1000.0 / 24000.0; >} > >ExpertGPS implements this, if you are looking for a program to test >against. http://www.expertgps.com > >-- >Dan Foster >
kruhc+seznam.cz on Fri Aug 25 01:53:44 2006 (link)
Hello, I'd like to ask you for help - I'm not sure how to mix waypoints and tracks withing a gpx file when I use streamed-writing. I have an application that records a track with /gpx/trk/trkseg/trkpt. Now, in an interesting place, I want record it as a wpt so that I can attach an audio/image/text note, or reuse again for navigation in the future - and here is the problem. My understanding of GPX 1.1 scheme is that I have to close /trk/trkseg/trkpt (ie. return to /gpx), add <wtp>...</wpt>, and again open /trk/trkseg/trkpt and continue recording. But Google Earth, for example, will not then display the track as a continuous line, but with breaks where waypoints were inserted, and it looks a bit ugly. Am I using correct GPX elements to achieve what I want? Thank you.
robertlipe+usa.net on Fri Aug 25 06:54:56 2006 (link), replying to msg
> I have an application that records a track with /gpx/trk/trkseg/trkpt. > Now, in an interesting place, I want record it as a wpt so that I can > attach an audio/image/text note, or reuse again for navigation in the > future - and here is the problem. You can put URLs in trkpt. > My understanding of GPX 1.1 scheme is that I have to > close /trk/trkseg/trkpt (ie. return to /gpx), add <wtp>...</wpt>, and > again open /trk/trkseg/trkpt and continue recording. But Google Earth, > for example, will not then display the track as a continuous line, but > with breaks where waypoints were inserted, and it looks a bit ugly. Right. You closed the track so Google Earth's GPX reader (actually GPSBabel behind the scenes) knows that it's a different trk/trkseg and restarts the polyline. Either prescan and write all the wpts that you want up front before you start spilling trks or just put hte <link> info straight into the trk. The latter seems more natural. Have you explored that? RJL
dananderson2+yahoo.com on Fri Aug 25 07:28:17 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "kruch_cz" <kruhc+...> wrote: > > Hello, > > I'd like to ask you for help - I'm not sure how to mix waypoints and > tracks withing a gpx file when I use streamed-writing. > > I have an application that records a track with /gpx/trk/trkseg/trkpt. > Now, in an interesting place, I want record it as a wpt so that I can > attach an audio/image/text note, or reuse again for navigation in the > future - and here is the problem. > > My understanding of GPX 1.1 scheme is that I have to > close /trk/trkseg/trkpt (ie. return to /gpx), add <wtp>...</wpt>, and > again open /trk/trkseg/trkpt and continue recording. But Google Earth, > for example, will not then display the track as a continuous line, but > with breaks where waypoints were inserted, and it looks a bit ugly. > > Am I using correct GPX elements to achieve what I want? Thank you. > Would putting the waypoints in one file and the trackpoints into a different file and possibly combining them at the end work? Dan A.
kruhc+seznam.cz on Fri Aug 25 07:34:07 2006 (link), replying to msg
> Right. You closed the track so Google Earth's GPX reader (actually > GPSBabel behind the scenes) knows that it's a different trk/trkseg and > restarts the polyline. > > Either prescan and write all the wpts that you want up front before > you start spilling trks or just put hte <link> info straight into the > trk. The latter seems more natural. Have you explored that? I tried <link> to link an image to a trkpt, but Google Earth won't display anything, which is what I'm basically after. I guess I'll keep <wpt>s insert by user in memory (and backed in a separate file), and add them to the "main" gpx file when user stops recording. BTW, is there a way to link another gpx file into the "main" one? Couldn't eg. /gpx/link/+href point to another gpx resource for inclusion? Thank you! -k
kruhc+seznam.cz on Fri Aug 25 07:41:55 2006 (link), replying to msg
> Would putting the waypoints in one file and the trackpoints into a > different file and possibly combining them at the end work? You are right! That's a most robust solution.
robertlipe+usa.net on Fri Aug 25 07:49:05 2006 (link), replying to msg
> I tried <link> to link an image to a trkpt, but Google Earth won't > display anything, which is what I'm basically after. Aaah, now what any given program _does_ with GPX is a very different question than what's legal to express in GPX. :-) I do believe that GE4/Beta does what you're looking for. If you're sure that it does not, privately send me one of your GPX files and we'll see how it can be all play nicer. RJL
kruhc+seznam.cz on Fri Aug 25 08:03:58 2006 (link), replying to msg
> I do believe that GE4/Beta does what you're looking for. If you're sure > that it does not, privately send me one of your GPX files and we'll see > how it can be all play nicer. I'll try GE4b, currently I use GE3. In addition to attaching a video/audio data to a point (eg. for "multimedia" presentation in GE :-) ), I'd like to allow users to create a set of points for navigation on the track, to share it with friends etc. Therefore, it has to be <wpt> I should use, anyway. Thank you! -k
egroups+topografix.com on Fri Aug 25 10:27:26 2006 (link)
Hello gpsxml, The base GPX schema <wpt> has a <time> element, which is ambiguously defined as "Creation/modification timestamp". So which is it? There is also a <time> element in <metadata>. This is defined as "the creation date of the file." Definitions from the GPX 1.1 schema: metadata/time: The creation date of the file. wpt/time: Creation/modification timestamp for element. Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs. A common problem when importing or pasting GPX data into an existing file is to determine how to merge data correctly. Knowing which data is newer is key to merging correctly, so you don't overwrite newer data with older, stale data. For this reason, I will be including a modification timestamp with elements in my GPX files. I believe modification data should not be put in wpt/time or metadata/time, because these elements are commonly used to hold the creation time of the element. (example: GPX pocket queries put the cache placement date in wpt/time) Since "modification time" is fairly generic and may be useful outside my application, I propose it here as a GPX extension schema, rather than putting it in a topografix_private schema. http://www.topografix.com/gpx/gpx_modified/0/1/gpx_modified.xsd The schema contains one element: <time> This is an ISO-8601 timestamp, but is restricted to UTC time as Steve suggested in this post: http://groups.yahoo.com/group/gpsxml/message/1091 Here's a GPX snippet showing a file creation time and a file modification time: <gpx .... <metadata> <time>2006-08-18T21:34:18Z</time> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2006-08-25T15:57:56.328Z</time> </extensions> </metadata> .... </gpx> I'd like to change the wpt/time documentation on the existing 1.1 schema to indicate that wpt/time is for creation time only. Comments? -- Dan Foster
egroups+topografix.com on Fri Aug 25 11:03:04 2006 (link), replying to msg
Hello, Wednesday, August 16, 2006, 12:34:35 PM, Richard wrote: > I've just uploaded my proposal to extend the GPX standard to support > GPS enabled cameras. The Viewpoint as I've called it is based on a > waypoint but also inludes direction and other camera orientation > information. > > Many thanks to those who have provided feedback so far. I am now very > interested to see if anyone else supports my ideas and to see if the > GPX standard is the right home for a solution. I would certainly like to see this evolve into a GPX extension schema for adding photo and camera information to GPX files. Some comments: Several of your elements are duplicating elements already defined in the GPX base schemas but with different names. For example, <ele> is identical to your "<s_height> is the height / altitude above mean sea level" I'd really like to see a formal XSD schema and a validated example GPX file. How do I add my own extensions onto your <vpt> element? As I learned in GPX 1.1, leaving <extensions> off of complex elements (like <link>) means nobody can extend it further. What base schema do you propose to use? GPX 1.0 or GPX 1.1? How can we insert photo info into other GPX objects? How do you express the following: a waypoint that contains a photo a bunch of photos that were time-synced to a tracklog a photo that doesn't have a waypoint associated with it. -- Dan Foster
dananderson2+yahoo.com on Fri Aug 25 12:36:36 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > Hello gpsxml, > > The base GPX schema <wpt> has a <time> element, which is ambiguously > defined as "Creation/modification timestamp". So which is it? > > There is also a <time> element in <metadata>. This is defined as "the > creation date of the file." > > Definitions from the GPX 1.1 schema: > metadata/time: > The creation date of the file. > > wpt/time: > Creation/modification timestamp for element. Date and time in are in > Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 > specification for date/time representation. Fractional seconds are > allowed for millisecond timing in tracklogs. > > > A common problem when importing or pasting GPX data into an existing > file is to determine how to merge data correctly. Knowing which data > is newer is key to merging correctly, so you don't overwrite newer > data with older, stale data. For this reason, I will be including a > modification timestamp with elements in my GPX files. I believe > modification data should not be put in wpt/time or metadata/time, > because these elements are commonly used to hold the creation time of > the element. (example: GPX pocket queries put the cache placement > date in wpt/time) > > > Since "modification time" is fairly generic and may be useful outside > my application, I propose it here as a GPX extension schema, rather > than putting it in a topografix_private schema. > > http://www.topografix.com/gpx/gpx_modified/0/1/gpx_modified.xsd > > The schema contains one element: <time> > > This is an ISO-8601 timestamp, but is restricted to UTC time as Steve > suggested in this post: > http://groups.yahoo.com/group/gpsxml/message/1091 > > Here's a GPX snippet showing a file creation time and a file > modification time: > <gpx .... > <metadata> > <time>2006-08-18T21:34:18Z</time> > <extensions> > <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2006-08-25T15:57:56.328Z</time> > </extensions> > </metadata> > .... > </gpx> > > > I'd like to change the wpt/time documentation on the existing 1.1 > schema to indicate that wpt/time is for creation time only. > > > Comments? Is an extension schema better or a new version of GPX incorporating perhaps other new elements? Dan A.
egroups+topografix.com on Fri Aug 25 13:16:02 2006 (link), replying to msg
Hello, Friday, August 25, 2006, 3:32:34 PM, dananderson2 wrote: > Is an extension schema better or a new version of GPX incorporating > perhaps other new elements? If we do a new GPX 1.2 or 2.0 schema, I would suggest breaking most of the GPX 1.1 elements off into their own schemas for reusability purposes. This stuff all belongs together somewhere: <fix> fixType </fix> [0..1] ? <sat> xsd:nonNegativeInteger </sat> [0..1] ? <hdop> xsd:decimal </hdop> [0..1] ? <vdop> xsd:decimal </vdop> [0..1] ? <pdop> xsd:decimal </pdop> [0..1] ? <ageofdgpsdata> xsd:decimal </ageofdgpsdata> [0..1] ? <dgpsid> dgpsStationType </dgpsid> [0..1] ? This needs to get fixed so it can be extended: <link> linkType </link> <xsd:complexType name="linkType"> <xsd:sequence> <-- elements must appear in this order --> <xsd:element name="text" type="xsd:string" minOccurs="0"/> <xsd:element name="type" type="xsd:string" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="href" type="xsd:anyURI" use="required"/> </xsd:complexType> It seems to me that the best way to proceed would be to work on making a bunch of highly-specialized sub-schemas that can all be mixed together to meet individual needs. We do need to come up with some answers as to how GPX should handle things like photos embedded in waypoints, waypoints embedded in photos, and your hotspots and other map symbols. -- Dan Foster
dananderson2+yahoo.com on Sun Aug 27 12:01:08 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: [snip] > If we do a new GPX 1.2 or 2.0 schema, I would suggest breaking most of > the GPX 1.1 elements off into their own schemas for reusability > purposes. > > This stuff all belongs together somewhere: > <fix> fixType </fix> [0..1] ? > <sat> xsd:nonNegativeInteger </sat> [0..1] ? > <hdop> xsd:decimal </hdop> [0..1] ? [snip] > It seems to me that the best way to proceed would be to work on making > a bunch of highly-specialized sub-schemas that can all be mixed > together to meet individual needs. To make sure we are talking about the same thing, I'd like to clarify what's a sub-schema. Would you call GPX Overlay and Styles sub-schema? I take it you would like to put the fix related data together in a "sub-schema" so it can be used for more than just <wpt>? > We do need to come up with some answers as to how GPX should handle > things like photos embedded in waypoints, waypoints embedded in > photos, and your hotspots and other map symbols. I take "embedded" to mean that the actual image data is stored in the GPX file (I just can't wait for gigabyte sized GPX files. **Smile**). So there might by something such as: <imageType>JPEG</imageType><imageData>actual jpeg data</imageData> As far as waypoints embedded in images ? Seems to me that's more in the hands of those creating the image format standards. The JPEG EXIF already has: Lat/Long, Lat/Long reference, Altitude, Alt. Reference, GPS date stamp, GPS time, GPS satellites, GPS status, GPS measure mode, GPS degree of precision, GPS speed, GPS speed reference, Direction of GPS, Reference for direction, Direction of image, DOI reference, Geodetic survey data, Destination lat/long and ref, Bearing to destination, Destination distance, GPS processing method, and GPS differential. One of the complaints of the JPEG EXIF was that you have to send the large image file to send a small amount of location data. Embedding the image in the waypoint will also have that problem although it might be a bit easier to strip the waypoint of the image than to strip the image from the JPEG EXIF data with currently available programs (at least with what I have on my computer ? I can strip EXIF from the image but not the other way). Currently I just plan on using the URL in the waypoint to point to the picture. And of course, I'd like to see a point type object in GPX_Overlay that could be represented by a symbol on the map and have a link to a picture (or any other type of file). -- Dan A. (www.gpsmap.net)
robertlipe+usa.net on Mon Aug 28 10:19:24 2006 (link), replying to msg
Dan Foster wrote: > It seems to me that the best way to proceed would be to work on making > a bunch of highly-specialized sub-schemas that can all be mixed > together to meet individual needs. I can't speak for the others, but I'm much more interested in supporting one widely encompassing "GPX" than a bunch of fragmented extensions built upon the GPX core. > We do need to come up with some answers as to how GPX should handle > things like photos embedded in waypoints, waypoints embedded in > photos, and your hotspots and other map symbols. I'd like to see experts in the respective areas interested in driving such extensions drive them into a standardized mainstream GPX core. If we have GPX plus scores of extensions with little standardization, what have we really standardized? For example, a user recently pointed out to me that his Mapsource GPX files had a Garmin extension to store the colour of his tracks and ExpertGPS had a Topografix extension to store the colour of his tracks. (I didn't look at the files, so I don't know that either are true, but it seems believable.) The user was annoyed that he lost the color becuase from his view there shouldn't be incompatible GPX; GPX 1.1 should be GPX 1.1. His annoyance was understandable to me. The 'X' in GPX didn't pan out for him. RJL
dananderson2+yahoo.com on Mon Aug 28 22:36:36 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: [snip] > For example, a user recently pointed out to me that his Mapsource GPX > files had a Garmin extension to store the colour of his tracks and > ExpertGPS had a Topografix extension to store the colour of his tracks. > (I didn't look at the files, so I don't know that either are true, > but it seems believable.) The user was annoyed that he lost the color > becuase from his view there shouldn't be incompatible GPX; GPX 1.1 > should be GPX 1.1. > > His annoyance was understandable to me. The 'X' in GPX didn't pan out > for him. Garmin has extensions for at least display mode: <gpxx:WaypointExtension http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd"> <gpxx:DisplayMode>SymbolAndName</gpxx:DisplayMode> and color: <gpxx:TrackExtension xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.garmin.com/xmlschemas/GpxExtensions/v3 http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd"> <gpxx:DisplayColor>Blue</gpxx:DisplayColor> ExpertGPS uses GPX_Style: <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>0000ff</color> <opacity>1.0</opacity> <width>0.042</width> <pattern>Solid</pattern> I certainly hope that GPX will be updated so that exchanging GPS related data is as painless as possible. Dan A.
robertlipe+usa.net on Tue Aug 29 06:17:35 2006 (link), replying to msg
> Garmin has extensions for [ ... ] color: > <gpxx:DisplayColor>Blue</gpxx:DisplayColor> > > ExpertGPS uses GPX_Style: > <color>0000ff</color> > > I certainly hope that GPX will be updated so that exchanging GPS > related data is as painless as possible. This is a lovely example of the "same" data (yes, I realize that both were trying to solve harder problems than just polyline colour) being represented in incompatible ways. But if you look at the Garmin extensions, in particular, there are some concepts that are pretty clearly generic to a point. Temperature, address, and colour, for example, are hardly concepts proprietary to Garmin. Subclass, an 18 digit hex number, doesn't lend itself nearly as well to a portable spec. While it's great that GPX _can be_ extended with vendor-specific stuff, if we grow the GPX core to include those concepts, then we get the benefits of true interoperability. RJL
kruhc+seznam.cz on Tue Sep 12 06:54:08 2006 (link)
In my struggle with "GPX vs Google Earth" I came across this: GPX manual (http://www.topografix.com/gpx_manual.asp) mentions <speed> and <course> as optional in <wpt> <rtept> <trkpt> but GPX 1.1 schema does not define them. Will future GPX versions support speed and course (azimuth)? Thanks, kruch
avalon73+caerleon.us on Tue Sep 12 09:20:25 2006 (link), replying to msg
This has been discussed before... http://tech.groups.yahoo.com/group/gpsxml/message/1237 http://tech.groups.yahoo.com/group/gpsxml/message/984 -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator Never be afraid to try something new. Remember... amateurs built the ark, professionals built the Titanic.
kruhc+seznam.cz on Tue Sep 12 12:31:15 2006 (link), replying to msg
Thank you. The Search function in this forum just does not work :-( -k. --- In gpsxml+yahoogroups.com, Brian Smith <avalon73+...> wrote: > > This has been discussed before... > > http://tech.groups.yahoo.com/group/gpsxml/message/1237 > > http://tech.groups.yahoo.com/group/gpsxml/message/984 > > -- > ------------------------------------------------------------------- ---- > Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ > Software Developer // Gamer // Webmaster // System Administrator > Never be afraid to try something new. Remember... amateurs built the > ark, professionals built the Titanic. >
kruhc+seznam.cz on Tue Sep 12 12:39:18 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Chris Ainslie" <chris+...> wrote: > > There is very little point as the rest of the data in the file will give you > the tools to calculate both velocity and direction. It would be redundant > information. I disagree. The file may not hold enough data for a precise calculation. With sparse data (eg. using a "azimuth-has-changed-by-5- degrees" filter for saving a position to a file) one would get wrong results. > > If you have to do it, it can be stored in the <extentions> tag... but you > *don't* have to do it. I do :-) Thanks, k. > > > Chris Ainslie > chris+... > 083 639 1391 > Skype: cainslie > > -----Original Message----- > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of > Mhaxx > Sent: 21 March 2006 02:08 PM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Velocity and direction > > Is there possibility to store velocity and direction on a GPX file? > Which tags? > > Mhaxx > > > > > > > > Yahoo! Groups Links >
egroups+topografix.com on Mon Sep 18 07:40:46 2006 (link)
Hello gpsxml, I'm adding support for geocaching.com Pocket Queries to one of my programs. I'd like to be able to save out a GPX file that preserves this data, and adds additional GPS data (tracklogs, drawn shapes, etc) as well as adds user data (photos, corrected coordinates, took X, left Y, etc) to the geocaches themselves. Two problems came up: 1. the cache schema used by geocaching.com is based on GPX 1.0, and I'm using GPX 1.1. 2. the cache schema cannot be extended to include any other GPX elements. My solution was to recreate a GPX 1.1 schema that contains the same elements as the GPX 1.0 cache schema, with the addition of <extension> blocks to allow further extension. The resulting schema can be found at http://www.geobuddy.com/cache/1/1/cache.xsd A validating example file (two waypoints, one geocache) can be found at http://www.geobuddy.com/cache/1/1/cache.gpx I realize that there are already a number of flavors of geocaching schemas out there, each tailored for a specific GPS-related game or Web site. My intention was to create a public schema that mirrors the geocaching.com one as much as possible (with a few minor "fixes"), and then to create a private schema to hold any additions that are unique to my program. This should allow a well-written, GPX-aware program to import GPX files from either schema using a single parsing routine. I'd be interested to hear your comments, especially if you are a developer who reads or writes GPX files with geocaching data. -- Dan Foster TopoGrafix Support: egroups+topografix.com http://forums.topografix.com
robertlipe+usa.net on Mon Sep 18 08:23:37 2006 (link), replying to msg
Dan Foster wrote: > My solution was to recreate a GPX 1.1 schema that contains the > same elements as the GPX 1.0 cache schema, with the addition of > <extension> blocks to allow further extension. For better and worse, in doing so you've created a format that is not going to be usable by the majority of the programs that know how to read Groundspeak pocket queries. Perhaps that interopability won't matter to you and your users. It really is unfortunate just how incompatible GPX 1.0 and 1.1 are. > I realize that there are already a number of flavors of geocaching > schemas out there, each tailored for a specific GPS-related game or > Web site. Some time ago, when those competing sites were sprouting left and right, I tried to get them to unify around one set of extensions to the GPX core instead of everyone doing their own thing. Those conversations went pretty much nowhere. > I'd be interested to hear your comments, especially if you are a > developer who reads or writes GPX files with geocaching data. Geocachers are a big part of my user base. I'm pretty plugged in to that market. I believe until Groundspeak goes to GPX 1.1 (and I don't see a strong motivation for them to do so) anyone that values compatibility with that user base kind of has to stick with 1.0. RJL
joshzcanete+yahoo.com on Mon Sep 18 17:07:22 2006 (link)
When the stock market is going up and all your stocks and mutual funds are making money you feel like a genius. It is too bad that some folks don?t remember what happened in 2000. Of course, right now we are in one of those genius phases. Your broker and financial planner are encouraging you to buy, buy, buy. And I can?t fault that at this time. You remember back in 2000 how many times they told you to buy, buy, buy while the market was going down, down, down. Are we in another of those periods now that are leading up to a humongous crash? Hey, I don?t predict, but I do listen to the voice of the market. http://hyper-stocks.blogspot.com/2006/09/great-stock-market-secret.html --------------------------------- Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail. --------------------------------- Get your email and more, right on the new Yahoo.com [Non-text portions of this message have been removed]
joshzcanete+yahoo.com on Wed Sep 20 11:47:02 2006 (link)
The bulls and bears of the stock market are both tempting and scary to the investors. Speculators are enchanted by the stock market's potential to help them in making quick money with a big M. While those who tread with care and caution, often shy away for fear of losing. However, the stock market is not all about speculative gains or black Tuesdays. It is a place where committed companies look for raising money to fund their activities. Serious investors can actually create wealth not only for themselves, but also for the companies and the nation. A wise way to invest in the stock market is to empower your self with information. You have to know and learn about the company you invest in, from past records and future plans. http://hyper-stocks.blogspot.com/2006/09/stock-market-investment-plan-that.html --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2�/min or less. [Non-text portions of this message have been removed]
sweetfashions6+yahoo.com on Thu Sep 21 09:40:50 2006 (link)
Hi Friends! Sometimes u just cant predict what ur gonna find in ur mail! Just opened my mail n guess what? hot or not ! Check it now Have fun Guys, i think am gonna love it here, i just hope somebody sends me a mail soon! sam http://www.hotornots.net/ratemypic/index.php --------------------------------- Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail. --------------------------------- Stay in the know. Pulse on the new Yahoo.com. Check it out. [Non-text portions of this message have been removed]
joshzcanete+yahoo.com on Thu Sep 21 22:12:39 2006 (link)
The classic image of the stock market is that of a place where fortunes are made and lost throughout the course of the day, and where those who take the biggest risks are rewarded by a hefty payout when all is said and done. Of course, this is the movie version of the market? no matter how thrilling the day-to-day dramas of investment trading become, they'll never compete with the images of the stock market that have been created for the silver screen. There is a small grain of truth to those images from the movies, however? those individuals who choose to deal in high-risk stocks can make a lot of money if they handle the risks correctly. If they don't, however, then there's a good chance that they could lose their entire investment. Below you'll find more information on the world of high-risk (and high-yield) investments, including ways to help insure yourself against major losses when dealing with higher levels of investment risk. http://hyper-stocks.blogspot.com/2006/09/guide-to-high-yield-high-risk-stocks.html --------------------------------- All-new Yahoo! Mail - Fire up a more powerful email and get things done faster. --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1�/min. [Non-text portions of this message have been removed]
richard+jelbert.com on Sun Sep 24 16:05:52 2006 (link), replying to msg
I've finally released the commercial version of my GPS based GeoTagger device. See http://www.geotagger.co.uk for info. I've also got around the problem with the GPX standard for the time being because www.robogeo.com now supports my own file JTR format direct. To recap, I wanted to retain the photo direction information but it had been removed from the latest version of the schema. Any update on this aspect would be appreciated... Richard --- In gpsxml+yahoogroups.com, "Lisa Harper" <lisah2u+...> wrote: > > Hi Richard, I have an understanding of your specific problem and can send > you a gpx schema extension in a separate email. I'm working on a project > where orientation is important, as well. We already contacted topographix > and they suggested a custom extension --- as much as possible, we'd like to > make it generally available, since like you, I think it's a question of time > before most photographic devices have access to a wider array of sensor data > such as location and orientation. > Lisa > > > On 8/1/06, Richard Jelbert <richard+...> wrote: > > > > Hello > > > > Indeed there are a number of tools to merge GPS tracks with EXIF data > > but as far as I can see, they are all blunt instruments trying to > > solve a rather more subtle problem. I'll explain my thinking. > > > > In the context of taking geo-tagged photographs, GPS tracks or > > waypoints stored on the GPS don't record the direction of the device > > at the time a photo is taken. Instead they allow you to interpolate > > the general direction of travel by looking at multiple track or > > waypoints. The reality is that most of the time the camera is pointing > > in a completely different direction when a photo is taken. > > > > I created this GeoTagger device because I wanted to record the exact > > compass direction (and location) when the photo was taken. the Garmin > > 301 provides both on its serial output in NMEA format so I store it in > > a CVS file on the flash card. > > > > The next generation of mobile camera phones will have GPS, the compact > > and D-SLR camera manufacturers are all looking for a differentiators > > so it wouldn't surprise me that in the next few years many more camera > > devices will appear with geo-tagging capability built in. > > > > The GPX format does not seem to have the expressiveness to cope with > > what will be a much larger requirement than tracks and waypoints in > > the near future - geo-tagged image data... > > > > So perhaps the wider question is should GPX as a standard be extended > > to cope with a new type of location data called a "VIEW"? A view would > > have long, lat AND direction of view. The alternative is to hijack a > > waypoint or track and kludge the direction into one of these. > > > > Richard > > > > As far as I can see, > > > > > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, "Poco" <kaz+> > > wrote: > > > > > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, "Louis" > > <clovis+> wrote: > > > > > > > > > I have created a locaton recording device for my camera that stores > > > > > long and lat and the compass direction on a FLASH card in CSV format > > > > > each time I take a photo. > > > > > ... > > > > > Richard > > > > > > > > A naive question: why you don't use the time value from your photo > > > (EXIF tag) to get the gps position from a recorded track? > > > > Something like OziPhotoTool: > > > > http://alistairdickie.com/oziphototool/index.html > > > > > > > > Louis > > > > > > > > > > There are actually quite a few tools for doing this. Some are free > > > and some not. The easiest one I've used (free) is from wwmx.org > > > (Microsoft) and there are other commercial applications (Robogeo at > > > robogeo.com looks very promising). > > > > > > I've written a few thoughts on the process and how I use it here > > > http://notions.okuda.ca/geotagging/.<http://notions.okuda.ca/geotagging/>I agree that it would be nice > > > for Canon to do this like Nikon, but it takes only a minute to > > > download your GPS track and stamp your photos with the GPS track. > > > Robogeo will even export your photo locations to a GPX file as > > > waypoints as well as the ability to stamp the photo Exif. > > > > > > > > > > > > [Non-text portions of this message have been removed] >
dating_online_internet+yahoo.com on Sat Sep 30 01:18:47 2006 (link)
Do you want to find a warm, sincere ,best friend, lover and partner to share lifes ups and downs? So many hot sexy cowboy and cow girl are there : http://www.geocities.com/hothorseloveronline Do you have a love for horses but no one special to share it with? Do you wish there was a place where you could meet riding buddies, discover new trails, and maybe even meet someone to share your passion? To find something different form your ordinary life. All you need is there: http://www.geocities.com/hothorseloveronline
idieden+yahoo.com on Thu Oct 05 22:20:44 2006 (link)
I Will Show You The Way To Make Easy And Fast Money. Watch this! It's generating thousands of dollar per week in personal income for you. join free and get money free. http://tinyurl.com/jxyte ENJOY YOUR LIFE. U.S & CANADA Members only.
renlindon+yahoo.com on Thu Oct 12 08:58:51 2006 (link)
Using the Stock Market to Plan for Retirement The stock market can be a powerful investment tool, especially if you're planning on making long-term investments. Unfortunately, the instability of the market can make many people hesitant to trust in it for financial planning. Despite this, if you're looking for a way to make plans for your eventual retirement you might want to set aside some of your mistrust for the market's instability and consider using the stock market as a tool for planning your retirement. Below you'll find suggestions on how to best work the market to your advantage for long-term investment planning, as well as some basic information on common retirement plans that utilize stock investment. http://hyper-stocks.blogspot.com/2006/09/using-stock-market-to-plan-for.html --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail. [Non-text portions of this message have been removed]
renlindon+yahoo.com on Fri Oct 13 12:51:37 2006 (link)
How To Make It Big In The Stock Market! Want to get rich quick. Then you need to be wise and plan accordingly. Trading in stock is an option to make money fast. Mutual funds and financial institutions use stock option trading to reap benefits. The stock trading system is very supportive to them rather than the small investor. The individual investor can gain as well but prudence is the watch word. Advice to help you if you are a new entrant; professional help can provide you the least risk and good reward stocks. http://i-riches.blogspot.com/2006/10/how-to-make-it-big-in-stock-market.html --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1�/min. --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail. [Non-text portions of this message have been removed]
doug.fales+gmail.com on Sat Oct 14 15:59:26 2006 (link)
Hi all, I'm pleased to announce the first release of my GPX ruby gem: http://gpx.rubyforge.org This 100% ruby gem supports reading, editing, and writing of GPX files. It is the same code that powers the trip-editing part of my site, http://walkingboss.org. In addition to parsing GPX files, this gem also supports: * parsing and conversion of the NMEA output from Magellan GPS devices * deletion and cropping of points within/outside of a rectangular bounds * calculation of meta-data about files, tracks, segments * creating new GPX files -Doug Fales http://guod.net http://walkingboss.org
renlindon+yahoo.com on Sun Oct 15 13:11:25 2006 (link)
Hi all, I am using in an application then gpx schema with the style extension. There is an attribute to make a icon waypoint or a line track visible or not? There is an attribute to make a label waypoint or a label track visible or not? May be usefull make labels visible or not if there are many object on screen. There is an attribute to choose the waypoint bitmap to draw? I apologize for my english.... Many Thanks
renlindon+yahoo.com on Thu Oct 19 20:23:44 2006 (link)
The new(ish) breed of Garmin GPS receivers (Forerunner 305, Edge 305) have additional sensors for heart rate and cadence and log them with each point. I'd like to be able to represent this data within the GPX format - what existing practice is there for encoding it? I'm aware of the GPXDATA extension created by/for LoadMyTracks - http://www.cluetrust.com/Schemas/gpxdata10.xsd - is there anything other than that program using it? Is it likely to become a (de facto/actual) standard? Are there other contenders? -dan -- http://www.coruskate.net/
robertlipe+usa.net on Mon Oct 23 09:20:36 2006 (link), replying to msg
Daniel Barlow wrote: > The new(ish) breed of Garmin GPS receivers (Forerunner 305, Edge 305) > have additional sensors for heart rate and cadence and log them with > each point. I'd like to be able to represent this data within the GPX > format - what existing practice is there for encoding it? Garmin's own Training Center program doesn't use GPX, but it has a pretty well defined schema: http://www.garmin.com/xmlschemas/TrainingCenterDatabasev1.xsd > I'm aware of the GPXDATA extension created by/for LoadMyTracks - > http://www.cluetrust.com/Schemas/gpxdata10.xsd - is there anything > other than that program using it? Is it likely to become a (de > facto/actual) standard? Are there other contenders? In GPSBabelsville, I hear an increasing amount about receivers with this capability. We process it in the Garmin Training Center formats and make it available in the XCSV formats, but otherwise don't process it. GPSBabel, much like GPX core, really isn't in the 'workout/training manager' business, but a lot of people are happy enough just being able to stick heart rate, wheel cadence, and crank cadence on their track logs for study. Google Earth 4 does this, too, but it's smuggled in text and not really part of KML. RJL
egroups+topografix.com on Mon Oct 23 12:11:49 2006 (link), replying to msg
Hello, Monday, October 23, 2006, 6:08:36 AM, Daniel wrote: > > > > > > The new(ish) breed of Garmin GPS receivers (Forerunner 305, Edge 305) > have additional sensors for heart rate and cadence and log them with > each point. I'd like to be able to represent this data within the GPX > format - what existing practice is there for encoding it? > > I'm aware of the GPXDATA extension created by/for LoadMyTracks - > http://www.cluetrust.com/Schemas/gpxdata10.xsd - is there anything > other than that program using it? Is it likely to become a (de > facto/actual) standard? Are there other contenders? Garmin's MapSource saves temperature and depth data for trackpoints using this GPX 1.1 extension schema: http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd ExpertGPS reads and writes this data as well. As long as there's an effort going on to standardize on a schema for heart rate and other measured values along a track, I'd like to see temp and depth considered as well. I'll support heart rate and cadence in my software if a standard schema emerges. -- Dan Foster
spock_009+yahoo.com on Mon Oct 23 21:52:05 2006 (link)
Hello all I need to write a passer to extract some data from GPX files, but i am not familiar with GPX neither XML formats. Hi have looking to the official site, but the documentation looks very confusing to me. Can some one advise me a better path to studdy and get in GPX format? regards Antonio Fernandes
salcedo+yahoo.com on Wed Oct 25 09:39:13 2006 (link), replying to msg
First you need to understand XML (and XSD), then the GPX schema will make more sense. There are a lot of online resources for learning XML. Here are a few that you can take a look at http://www.w3schools.com/xml/default.asp http://www.xml.org/xml/resources_cover.shtml http://www.xml.com/ http://www.w3.org/XML/ --- In gpsxml+yahoogroups.com, "af_465" <af465+...> wrote: > > Hello all > > I need to write a passer to extract some data from GPX files, but i am > not familiar with GPX neither XML formats. > Hi have looking to the official site, but the documentation looks very > confusing to me. > Can some one advise me a better path to studdy and get in GPX format? > > regards > Antonio Fernandes >
af465+netcabo.pt on Thu Oct 26 17:28:09 2006 (link), replying to msg
Tanks Ricardo I will do my work on this. Regards Antonio
mandycaloma+yahoo.com on Fri Oct 27 02:19:53 2006 (link)
I posted this over in the sci.geo.satellite-nav group http://groups.google.com/group/sci.geo.satellite-nav/msg/4611b54879973a19 and thought it worth a try here. In brief, I'm looking for navigation appilications that run on Windows Mobile powered Smartphones that feature GPX import wirelessly over the Internet. Reply here or contact me directly. - Doug www.TravelByGPS.com/contact.php
mandycaloma+yahoo.com on Thu Nov 02 15:50:03 2006 (link)
Is this still the place for talking about GPX or is this now just a place for me to get stock trading tips? In the Map Authors group, a few of us are working on Tour Guides in Garmin GPI format. So far as I know, we can't assign a phone number to a point of interst. Given that ther are many more appilications using GPX than GPI format, i thought I would bring this up to members of this group and suggest that when the GPX schema is revised it incude phone number attribute for waypoints. Do other agree? - Doug www.TravelByGPS.com
egroups+topografix.com on Thu Nov 30 09:32:10 2006 (link), replying to msg
Hello, Thursday, November 30, 2006, 11:06:22 AM, Doug wrote: > Is this still the place for talking about GPX or is this now just a > place for me to get stock trading tips? > > In the Map Authors group, a few of us are working on Tour Guides in > Garmin GPI format. So far as I know, we can't assign a phone number > to a point of interst. Given that ther are many more appilications > using GPX than GPI format, i thought I would bring this up to members > of this group and suggest that when the GPX schema is revised it > incude phone number attribute for waypoints. > Do other agree? Doug, here's how this group works now: 1. You ask for something to be added to the GPX schema. 2. If you're lucky, a few people will chime in with "yeah, I want that, too". 3. Someone might mention that phone numbers aren't generally considered to be an attribute of GPS data, and suggest that you develop your own schema to hold them. 4. No further action will be taken, by you or anyone else.
ptomblin+gmail.com on Thu Nov 30 12:36:29 2006 (link), replying to msg
On 11/30/06, Dan Foster <egroups+topografix.com> wrote: > From what I've observed, people are generally content with GPX 1.0 and > GPX 1.1, and have absolutely no interest in contributing ideas to a > GPX 1.2. If you're really serious about putting phone numbers in GPX > files, I'd suggest you do the following: So I guess that means I'll never get a fix to the bug with the magnetic declination which I've squawked about several times in the past? That sucks. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
hannu.lohi+tracker.fi on Fri Dec 01 02:47:57 2006 (link), replying to msg
Hello We are interested of phone numbers as well. We planned to put it in extencions, if no better idea. www.tracker.fi let's see, where Nokia puts them. Hopefully they use GPX as well. --- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > Hello, > > Thursday, November 30, 2006, 11:06:22 AM, Doug wrote: > > > Is this still the place for talking about GPX or is this now just a > > place for me to get stock trading tips? > > > > In the Map Authors group, a few of us are working on Tour Guides in > > Garmin GPI format. So far as I know, we can't assign a phone number > > to a point of interst. Given that ther are many more appilications > > using GPX than GPI format, i thought I would bring this up to members > > of this group and suggest that when the GPX schema is revised it > > incude phone number attribute for waypoints. > > Do other agree? > > Doug, here's how this group works now: > > 1. You ask for something to be added to the GPX schema. > 2. If you're lucky, a few people will chime in with "yeah, I want > that, too". > 3. Someone might mention that phone numbers aren't generally > considered to be an attribute of GPS data, and suggest that you > develop your own schema to hold them. > 4. No further action will be taken, by you or anyone else. > > From what I've observed, people are generally content with GPX 1.0 and > GPX 1.1, and have absolutely no interest in contributing ideas to a > GPX 1.2. If you're really serious about putting phone numbers in GPX > files, I'd suggest you do the following: > > Find a similar sub-schema and modify it to suit your needs. > Prove it works by incorporating it into your software or Web service. > Prove it validates. > Announce its existance here. > Wait a week to see if anyone offers suggestions. > Announce its availability on a "take it or leave it" basis. > > -- > Dan Foster >
distobj+acm.org on Fri Dec 01 06:02:30 2006 (link), replying to msg
Extensions seem a great place for it, and you don't have to worry about coordinating with the community. On the other hand, the "X" in XML means "extensible", so it seems odd that extensions are limited to one GPX-specific extension stanza rather than being allowed anywhere. I suppose that's because GPX is defined by schema, and most schema languages are intended to restrict extensibility rather than support it (which is why I never use them). Oh well, at least GPX provides a way forward. BTW, I'd also encourage using an http URI for your namespace, and putting a descriptive HTML document behind that URI so that people who find a GPX document using your extension will be able to get more info about it. Mark. On 12/1/06, Hannu Lohi <hannu.lohi+tracker.fi> wrote: > Hello > > We are interested of phone numbers as well. We planned to put it in > extencions, if no better idea. > > www.tracker.fi > > let's see, where Nokia puts them. Hopefully they use GPX as well. > > --- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > > > Hello, > > > > Thursday, November 30, 2006, 11:06:22 AM, Doug wrote: > > > > > Is this still the place for talking about GPX or is this now just > a > > > place for me to get stock trading tips? > > > > > > In the Map Authors group, a few of us are working on Tour Guides > in > > > Garmin GPI format. So far as I know, we can't assign a phone > number > > > to a point of interst. Given that ther are many more > appilications > > > using GPX than GPI format, i thought I would bring this up to > members > > > of this group and suggest that when the GPX schema is revised it > > > incude phone number attribute for waypoints. > > > Do other agree? > > > > Doug, here's how this group works now: > > > > 1. You ask for something to be added to the GPX schema. > > 2. If you're lucky, a few people will chime in with "yeah, I want > > that, too". > > 3. Someone might mention that phone numbers aren't generally > > considered to be an attribute of GPS data, and suggest that you > > develop your own schema to hold them. > > 4. No further action will be taken, by you or anyone else. > > > > From what I've observed, people are generally content with GPX 1.0 > and > > GPX 1.1, and have absolutely no interest in contributing ideas to a > > GPX 1.2. If you're really serious about putting phone numbers in > GPX > > files, I'd suggest you do the following: > > > > Find a similar sub-schema and modify it to suit your needs. > > Prove it works by incorporating it into your software or Web > service. > > Prove it validates. > > Announce its existance here. > > Wait a week to see if anyone offers suggestions. > > Announce its availability on a "take it or leave it" basis. > > > > -- > > Dan Foster > > > > > > > > Yahoo! Groups Links > > > >
tristanzvazquez+yahoo.com on Fri Dec 01 17:16:28 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+...> wrote: > > Is this still the place for talking about GPX or is this now just a > place for me to get stock trading tips? > > In the Map Authors group, a few of us are working on Tour Guides in > Garmin GPI format. So far as I know, we can't assign a phone number > to a point of interst. Given that ther are many more appilications > using GPX than GPI format, i thought I would bring this up to members > of this group and suggest that when the GPX schema is revised it > incude phone number attribute for waypoints. > Do other agree? > - Doug > www.TravelByGPS.com Yes, I think a common extension for contact information would be a good addition. There should also be fields for email address, web address, street address, etc. (Note that Garmin has a PhoneNumber extension already). I wish Dan F. (TopoGrafix) would add reasonably common requests to an extension or the basic schema even if he doesn't plan on adding support for it to ExpertGPS. I thought GPX was created to help solve the proliferation of file formats for GPS information. Are we headed for a hundred different GPX extensions? Garmin has extensions for PhoneNumber, Address, Categories, DisplayMode, Depth, Temperature, and Proximity. Groundspeak has extensions for geocaching - has Geobuddy added more geocaching extensions that are similar to Groundspeak's? I hope the authors of GPSBabel are ready to add a bunch of conversions from one type of GPX file to another.
egroups+topografix.com on Sun Dec 03 09:39:47 2006 (link), replying to msg
Hello, Sunday, December 3, 2006, 11:35:44 AM, dananderson2 wrote: > I wish Dan F. (TopoGrafix) would add reasonably common requests to an > extension or the basic schema even if he doesn't plan on adding > support for it to ExpertGPS. There seems to be a common mis-understanding about how this mailing list (and GPX itself) works. Nobody is in charge. Decisions are made by consensus. If you want something done, step up to the plate and make a case for it, and present a finished, working schema. The only thing that distinguishes me from anyone else in this group is that: 1. I offered to host the schema on topografix.com 2. I offered to write some documentation for the 1.0 and 1.1 schemas. I'd be more than happy to sever those ties. Let's register gpxschemas.org or something - I'll pitch in $20 toward hosting fees. -- Dan Foster
dananderson2+yahoo.com on Mon Dec 04 08:43:32 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > Hello, > > Sunday, December 3, 2006, 11:35:44 AM, dananderson2 wrote: > > > I wish Dan F. (TopoGrafix) would add reasonably common requests to an > > extension or the basic schema even if he doesn't plan on adding > > support for it to ExpertGPS. > > There seems to be a common mis-understanding about how this mailing > list (and GPX itself) works. Nobody is in charge. Decisions are > made by consensus. If you want something done, step up to the plate > and make a case for it, and present a finished, working schema. > > The only thing that distinguishes me from anyone else in this group is > that: > 1. I offered to host the schema on topografix.com > 2. I offered to write some documentation for the 1.0 and 1.1 schemas. > > I'd be more than happy to sever those ties. Let's register > gpxschemas.org or something - I'll pitch in $20 toward hosting fees. > I think we have a process problem. How many people need to be interested in a particular addition before it will be added? Who (committee members) decides whether a particular addition makes sense to GPX or to an extension? Who makes the changes? The person(s) asking for a new addition may not know enough to write the schema. Garmin might have decided to create their extension because it was easier than trying to get the fields added to GPX. If that's the case, it's a problem because it encourages multiple file formats. I believe there's a tendency for people to only focus on what they are currently interested in so getting a consensus is tough even if it's a great idea. What's it going to take to get Paul Tomblin's magnetic declination problem fixed? I have no objection to TopoGrafix hosting the schema. The URL's are all over the place. But maybe a more formal procedure needs to be specified so that changes can get done.
robertlipe+usa.net on Mon Dec 04 10:05:58 2006 (link), replying to msg
> Yes, I think a common extension for contact information would be a > good addition. There should also be fields for email address, web > address, street address, etc. (Note that Garmin has a PhoneNumber > extension already). If Garmin has an extension that solves this problem, is there an objection to using it? Their competitors may (or may not) find it distasteful, but that seems to be sort of the point of open standards. > support for it to ExpertGPS. I thought GPX was created to help solve > the proliferation of file formats for GPS information. Are we headed > for a hundred different GPX extensions? Garmin has extensions for > PhoneNumber, Address, Categories, DisplayMode, Depth, Temperature, and > Proximity. Groundspeak has extensions for geocaching - has Geobuddy > added more geocaching extensions that are similar to Groundspeak's? I think the core of GPX does sufficiently cover the core GPS information that's pretty much common across the board. It has a large (and growing!) acceptance and seems to solve a lot of problems for a lot of people. Different folks have extended it in different ways. Garmin has hardware that supports categories, so it make sense for them to extend GPX in that way. Groundspeak needs to include a hint for geocaches, so it makes sense for them to extend GPX in that way. > I hope the authors of GPSBabel are ready to add a bunch of conversions > from one type of GPX file to another. I'd be delighted for GPSBabel to never be in the business of converting arbitrary extensions into each other and instead leave that to XSLT and other more XML-specific tools. As the opening line of http://www.gpsbabel.org says, "GPSBabel converts waypoints, tracks, and routes from one format to another" - it's not a general purpose XML translator. I don't _want_ to convert Geocaches into Navicaches and so on. RJL
robertlipe+usa.net on Mon Dec 04 10:11:57 2006 (link), replying to msg
> made by consensus. If you want something done, step up to the plate > and make a case for it, and present a finished, working schema. Dan does raise an interesting point. In this crowd we seem to have plenty of Geolocational-ish expertise that knows what they'd like to see in a file, but we don't have a proportional amount of XML expertise to grind out the well crafted schemas. I know I'm definitely in that camp. > I'd be more than happy to sever those ties. Let's register > gpxschemas.org or something - I'll pitch in $20 toward hosting fees. I have facilities to host it and can distribute access to others. That's the easy part of this problem. Finding more hands (brains) to share in the work is the harder piece. RJL
kerry.raymond+gmail.com on Mon Dec 04 12:07:07 2006 (link)
I think we get getting this whole extension idea back-to-front and getting into some bad modelling. Take hints for geocaching as an example. Caches have locations; caches have hints; locations don't have hints. That is, hints are not a property of locations generally. So what should be happening is that there needs to be an XML schema for geocaches of which one component is a location represented in (say) GPX and another component is the hint. This is same with phone numbers. People and buildings etc have phone numbers and people and buildings have locations. But it does not follow that locations have phone numbers. Make XML schemas for people etc that contain both a location and a phone number. Don't add phone numbers to locations. Unfortunately it is very tempting to say "I need to exchange information about Foo and Foo has a location and a Bar so lets incorporate Bar into GPX" but clearly everyone from geocachers to real estate agents to miners to farmers can come along and say that because most things have a location. Do we propose to extend GPX to accommodate information on house prices, vegetation cover, mining rights and a partridge in a pear tree? It makes sense to extend GPX for properties of locations, but it does not make sense to extend GPX for other properties of things that have locations. What about street address? If I am standing at 123 Main Street, Smalltown when I make my waypoint, should I be allowed to extend GPX to accommodate address information? Isn't that location information? Now we get into the more subtle issues of whether GPX is about locations or whether GPX is about GPS waypoints, tracks, and routes. Just to illustrate the difference, I create a waypoint at a particular time when I press the button on my GPS so time is an inherent property of a waypoint, but time is not a property of a location in general (as locations persist throughout time). Garmin have apparently extended their schema for temperature. Certainly at the moment I create a waypoint, there is an ambient temperature for that time and place and the GPS unit might be able to record that. So temperature is a property of a waypoint, but not a property of a location (clearly temperature can vary at a given location over time). So temperature might arguably be an extension of GPX if GPX is about GPS waypoints etc and not about locations. But then what about street addresses and cadastral mapping more generally? Global positioning gives us spatial coordinates, which can be translated into street addresses etc by the use of maps (and some GPS units can do this), but is GPX concerned with location in the broader sense or raw GPS readings? But now we go back to the earlier discussion of geocaching and phone numbers. I talked about creating a schema for geocaching in which a location might be represented as GPX. Do we really think the time or the temperature at the point I pressed the button to make a waypoint for the location of the cache is relevant to geocaching? No, not really. So unless the role of GPX is to represent location information as opposed to waypoints, then maybe it should not be used as a component of a geocache at all. If you are involved in modelling information professionally (and I am), you soon learn that the more you try to model something (i.e. build some kind of schema to represent it), the more subtle distinctions like the difference between a location and a waypoint start to matter and you have to understand the relationship between these things. So in terms of this discussion ... Many things (e.g. houses, geocaches) have locations and other properties. Locations can be spatial coordinates (e.g. latitude, longitude) and/or cadastral information (e.g. street address, land title data). Spatial coordinates are part of a GPS reading, which may contain other information (e.g. time, temperature). Which thing do we want GPX to represent? Figure that out first! An interesting aside. Do geocaches have locations or spatial coordinates? That is, is a street address acceptable for geocaching? Kerry [Non-text portions of this message have been removed]
gps_maps+travelbygps.com on Tue Dec 05 03:22:05 2006 (link), replying to msg
--- Kerry Raymond wrote: > It makes sense to extend GPX for properties of locations, but it does not make sense to extend GPX for other properties of things that have locations. In my mind there is a difference between Waypoints and Points of Interest; I think of waypoints more in context with navigation and POI more in context with travel and tours. Basic location information is all that is necessary for waypoints and waypoint comment and description fields are nice. POIs, for example on a guided tours, may require more attributes to fully describe. - Doug www.TravelByGPS.com
gps_maps+travelbygps.com on Tue Dec 05 03:24:11 2006 (link), replying to msg
--- Robert Lipe wrote: > In this crowd we seem to have > plenty of Geolocational-ish expertise that knows what they'd like to see > in a file, but we don't have a proportional amount of XML expertise to > grind out the well crafted schemas. I'm not one to implement suggested changes in schema, I'm just a voice in the crowd that's saying if there going to be change, then how about...
gps_maps+travelbygps.com on Tue Dec 05 03:35:23 2006 (link)
The GPX file information, dare I say meta data, includes fields for file description, key words, etc. I would like to see a field for what I call the quintessential point. For example the quintessential point for a trail would be the trailhead. I would use this point as an index for a collection of GPX files. This would be helpful when searching a collection of files and presenting search results by proximity. Are there others that agree this would be a useful? - Doug www.TravelByGPS.com
guido+gps.nl on Tue Dec 05 05:07:52 2006 (link), replying to msg
found where garmin is letting it in the gpx file. <wpt lat="52.317361" lon="6.532597"> <name>waypoint test</name> <cmt>adres</cmt> <sym>Waypoint</sym> − <extensions> − <gpxx:WaypointExtension> <gpxx:PhoneNumber>+31600000000</gpxx:PhoneNumber> </gpxx:WaypointExtension> </extensions> </wpt> I will test it in the poiloader as well. Guido (starter of the topic in map authors) --- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+...> wrote: > > --- Robert Lipe wrote: > > In this crowd we seem to have > > plenty of Geolocational-ish expertise that knows what they'd like to see > > in a file, but we don't have a proportional amount of XML expertise to > > grind out the well crafted schemas. > > I'm not one to implement suggested changes in schema, I'm just a voice > in the crowd that's saying if there going to be change, then how about... >
egroups+topografix.com on Tue Dec 05 10:30:04 2006 (link), replying to msg
Hello, Tuesday, December 5, 2006, 7:43:57 AM, guido_p_schmidt wrote: > found where garmin is letting it in the gpx file. > > <wpt lat="52.317361" lon="6.532597"> > <name>waypoint test</name> > <cmt>adres</cmt> > <sym>Waypoint</sym> > − > <extensions> > − > <gpxx:WaypointExtension> > <gpxx:PhoneNumber>+31600000000</gpxx:PhoneNumber> > </gpxx:WaypointExtension> > </extensions> > </wpt> > > I will test it in the poiloader as well. Be very careful about relying on Garmin's private GPX extensions. I've been burned once already - I implemented temperature and depth in ExpertGPS when MapSource first added it to their GPX files. A few months later my GPX files stopped validating, and I learned that Garmin had come out with a new version of their private schema, and deleted the old schema from their Web site! By doing so, they've retroactively broken a whole bunch of GPX files, including anything saved from their older version of MapSource. -- Dan Foster
egroups+topografix.com on Tue Dec 05 10:43:17 2006 (link), replying to msg
Hello, Tuesday, December 5, 2006, 6:27:23 AM, Doug wrote: > The GPX file information, dare I say meta data, includes fields for > file description, key words, etc. I would like to see a field for > what I call the quintessential point. For example the quintessential > point for a trail would be the trailhead. I would use this point as > an index for a collection of GPX files. This would be helpful when > searching a collection of files and presenting search results by > proximity. > > Are there others that agree this would be a useful? My programs fill in the <bounds> information, and have a private extension that stores the "active point" (the starting point for distance/bearing calculations) for the GPX file. I've spoken to others that would like to see a "center point for printing" or a number of "bookmarked points" as part of the GPX file. I would be happy to replace my use of a private "active point" with something that would be compatible with your indexing system and use a public extension schema. <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="GeoBuddy 2.06" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.topografix.com/GPX/gpx_style/0/2 http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd http://www.topografix.com/GPX/gpx_overlay/0/3 http://www.topografix.com/GPX/gpx_overlay/0/3/gpx_overlay.xsd http://www.topografix.com/GPX/gpx_modified/0/1 http://www.topografix.com/GPX/gpx_modified/0/1/gpx_modified.xsd http://www.topografix.com/GPX/Private/TopoGrafix/0/3 http://www.topografix.com/GPX/Private/TopoGrafix/0/3/topografix.xsd"> <metadata> <bounds minlat="44.35351113" minlon="-68.25335934" maxlat="44.35351113" maxlon="-68.25335934"/> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2006-12-05T18:29:11.015Z</time> <active_point xmlns="http://www.topografix.com/GPX/Private/TopoGrafix/0/3" lat="44.34999497" lon="-68.24625934"> </active_point> </extensions> </metadata> ... -- Dan Foster
gps_maps+travelbygps.com on Tue Dec 05 10:44:27 2006 (link), replying to msg
--- Dave Patton wrote: > Or you could load all the data into a spatial database... Thanks, Dave. As you may know, what I have is not a database, per se, but a growing collectionof gpx files. Until recently I provided geographic index files in gpx and kml format. The gpx index file was used with Google Map API and the KML with Google Earth. These files were not built on-the-fly. Rather manually, I had the task of identifying the quintessential point in the each individual file, giving each quintessential point the URL of the file's download page, then copying and pasting all quentessential points into an index file. This task was a maintenance problem in itself let alone trying to keep up with changes from Google etc. I'm looking for a better solution. My web master tells me if each individual gpx file contained the quintessential point info in the header, she could use simple process to display search results ranked by porximaty to the requestor (assuming that the requestor provides thier location info with the query). I'm asking this group if others have contimplated or implemented something simular. If yes, then there may be some merit to including in the standard. Other ideas are welcome and I appreciate your's Dave. - Doug
dananderson2+yahoo.com on Tue Dec 05 12:45:42 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: [snip] > Be very careful about relying on Garmin's private GPX extensions. > I've been burned once already - I implemented temperature and depth > in ExpertGPS when MapSource first added it to their GPX files. A few > months later my GPX files stopped validating, and I learned that > Garmin had come out with a new version of their private schema, and > deleted the old schema from their Web site! By doing so, they've > retroactively broken a whole bunch of GPX files, including anything > saved from their older version of MapSource. We have GPX_Overlay and Style. Perhaps we can add a GPX_POI extension schema that has fields to support points-of-interest. I'm sure lots of map authors would appreciate something like that. The question is will any programs/products support it.
dorgemano+yahoo.com on Tue Dec 05 22:53:47 2006 (link)
Beliefs of Successful Market Timers Successful market timers, meaning profitable market timers, have several "common" beliefs that help them achieve consistent profits. On the flip side of this, those who are unsuccessful also have a set of common beliefs. It is a good idea to know which beliefs will help you to succeed, and which ones you may have, that need to be changed. http://www.blogcharm.com/topstocks/53634/Beliefs+of+Successful+Market+Timers.html --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. [Non-text portions of this message have been removed]
guido+gps.nl on Wed Dec 06 05:23:56 2006 (link), replying to msg
this message we did become from garmin: " Q.1: How is it possible to use the GPX format and POI Loader to create Custom POI files that allow direct dialling of phone numbers? What about photo attachments? A.1: It is possible to add the telephone number as part of the text, in the "Comment" field, as in the HELP file of the POI loader, but it is not possible to link the phone number for direct dial via BlueTooth. Custom POI files are different from the Travel Guide (Falk Marco Polo or Fodors) Rich POIs and at the moment the phone field is not linkable via POI Loader. As for the photo, the POI Loader HELP file says: "Adding Pictures to TourGuide Points You can add .jpg images to your TourGuide points. To do so, include the path to the .jpg image in the ID3 data of your TourGuide .mp3 file. Search the internet for more information on ID3 tags for .mp3 files." The following link is to a page on there site that lists many programs that will work with ID3 tags. http://www.id3.org/implement.html" I did find out Zortam is working fine for the ID3 tags. Phone numbers won't work then. --- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+...> wrote: > > --- Kerry Raymond wrote: > > It makes sense to extend GPX for properties of locations, but it > does not make sense to extend GPX for other properties of things that > have locations. > > In my mind there is a difference between Waypoints and Points of > Interest; I think of waypoints more in context with navigation and POI > more in context with travel and tours. Basic location information is > all that is necessary for waypoints and waypoint comment and > description fields are nice. POIs, for example on a guided tours, may > require more attributes to fully describe. > > - Doug > www.TravelByGPS.com >
dananderson2+yahoo.com on Wed Dec 06 11:23:19 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: [snip] > > I hope the authors of GPSBabel are ready to add a bunch of conversions > > from one type of GPX file to another. > > I'd be delighted for GPSBabel to never be in the business of converting > arbitrary extensions into each other and instead leave that to XSLT and > other more XML-specific tools. > > As the opening line of http://www.gpsbabel.org says, "GPSBabel converts > waypoints, tracks, and routes from one format to another" - it's not a > general purpose XML translator. I don't _want_ to convert Geocaches into > Navicaches and so on. Okay so it won't be GPSBabel. Maybe it'll be POIBabel (containing an XSLT processor or calling one already on the system). Someone has to write XSLT documents to do the conversions. Some conversions won't be trivial. I'm just hoping to keep the number of different, similar formats to a minimum.
dorgemano+yahoo.com on Thu Dec 07 21:12:43 2006 (link), replying to msg
--- "Dan Anderson" wrote: > We have GPX_Overlay and Style. Perhaps we can add a GPX_POI extension > schema that has fields to support points-of-interest. I'm sure lots > of map authors would appreciate something like that. The question is > will any programs/products support it. > Point taken Dan; the silence here is loud. I'm not surprised that Garmin is not speaking up because they are pushing format - GPI - for which I understand they are developing an authoring tool which they would like to sell licenses for. It is my belief that a proprietary format for expensive dashtop devices will not flourish. What surprises me is the silence of other software developers like GPSS, GARtrip, GPSutility, et al. - Doug www.TravelByGPS.com
dorgemano+yahoo.com on Mon Dec 11 00:53:00 2006 (link)
Hello gpsxml, A long time ago, I remember someone created a utility that would create various geometric patterns (circles, spirals) in GPX format. If anyone knows what I'm talking about, could you please send me an email off-line (Dan Foster <egroups+topografix.com>) pointing me to this utility? -- Dan Foster
lildevil+gpxspinner.com on Mon Dec 11 21:03:37 2006 (link)
> A long time ago, I remember someone created a utility that would > create various geometric patterns (circles, spirals) in GPX format. I don't think it does GPX directly, but gpsfeed+ does circles and spirals in NMEA sentences. http://users.hol.gr/~dzach/gpsfeed/index.html Lil Devil
guido+gps.nl on Tue Dec 12 06:28:12 2006 (link), replying to msg
a step further in the tourguide, with the new beta software it is possible to use the phone when active. Even when it loaded as tourguide. see: http://static.flickr.com/128/320428424_d7716a2d9d_o.jpg In this beta the size of the text fields are limeted. I have asked garmin to fix this problem. guido --- In gpsxml+yahoogroups.com, "guido_p_schmidt" <guido+...> wrote: > > this message we did become from garmin: > > " > Q.1: How is it possible to use the GPX format and POI Loader to create > Custom POI files that allow direct dialling of phone numbers? What > about photo attachments? > > A.1: It is possible to add the telephone number as part of the text, in > the "Comment" field, as in the HELP file of the POI loader, but it is > not possible to link the phone number for direct dial via BlueTooth. > Custom POI files are different from the Travel Guide (Falk Marco Polo > or Fodors) Rich POIs and at the moment the phone field is not linkable > via POI Loader. As for the photo, the POI Loader HELP file says: > > "Adding Pictures to TourGuide Points > > You can add .jpg images to your TourGuide points. To do so, include the > path to the .jpg image in the ID3 data of your TourGuide .mp3 file. > Search the internet for more information on ID3 tags for .mp3 files." > > The following link is to a page on there site that lists many programs > that will work with ID3 tags. http://www.id3.org/implement.html" > > I did find out Zortam is working fine for the ID3 tags. Phone numbers > won't work then. > > > --- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+> wrote: > > > > --- Kerry Raymond wrote: > > > It makes sense to extend GPX for properties of locations, but it > > does not make sense to extend GPX for other properties of things that > > have locations. > > > > In my mind there is a difference between Waypoints and Points of > > Interest; I think of waypoints more in context with navigation and POI > > more in context with travel and tours. Basic location information is > > all that is necessary for waypoints and waypoint comment and > > description fields are nice. POIs, for example on a guided tours, may > > require more attributes to fully describe. > > > > - Doug > > www.TravelByGPS.com > > >
dorgemano+yahoo.com on Tue Dec 12 19:27:57 2006 (link)
Are there and resources to read on the web about developing geocaching utilities (or just reading the .gpx file) in VB? Just like to know what methods I can use to parse the .gpx file and display it the way I want... or even to sign into geocaching.com and getting information from personal queries under a specific log in ID.... Thanks.... Barry
chrisjweber+chrisjweber.com on Tue Dec 19 13:15:31 2006 (link), replying to msg
Are you referring to VB 6 or VB.net? For the first I'm not sure. For the latter I have found very little and I have mostly built my own. The nice thing in .NET is that you can generate a class from a schema and then just deserialze the gpx file into a class and work with it or vice versa. This works very well for gpx 1.1 but not very for gpx 1.0 because the .Net serialization infrastructure doesn't handle the nested lists very well. You can use xsd.exe to generate either classes or datasets. I prefer classes. You can also generate the class as either vb or C#. Good Luck! Chris W.
dorgemano+yahoo.com on Tue Dec 19 18:33:10 2006 (link), replying to msg
Sorry. VB6. I'm just now getting into C# and passing on vb.net :-( I don't have enough XML experience to fully understand what you were saying, but I think it is that I can use Visual Studio .Net to create a class based on an XML file? It will create the properties and methods? And then I use those to manipulate the data in the .gpx file as I wish? Not sure I'm ready for this undertaking yet... pragmaticlabs <chrisjweber+chrisjweber.com> wrote: Are you referring to VB 6 or VB.net? For the first I'm not sure. For the latter I have found very little and I have mostly built my own. The nice thing in .NET is that you can generate a class from a schema and then just deserialze the gpx file into a class and work with it or vice versa. This works very well for gpx 1.1 but not very for gpx 1.0 because the .Net serialization infrastructure doesn't handle the nested lists very well. You can use xsd.exe to generate either classes or datasets. I prefer classes. You can also generate the class as either vb or C#. Good Luck! Chris W. Yahoo! Groups Links __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com [Non-text portions of this message have been removed]
kemoelhref12+yahoo.com on Wed Dec 20 08:06:58 2006 (link), replying to msg
It seems that the cluetrust GPXDATA extension has recreated portions of the Garmin TrainingCenter namespace as GPX extensions. I'm not convinced for example that adding the Run/Laps to GPX (or an extension) is necessary. Many of the values that are stored in clueTrust:lapType for example either exist in gpx:trkseg or can be calculated, e.g. startPoint == the first gpx:trkpt in the gpx:trkseg. There are also elements in which to store elapsed time and cumulative distance, both of which can be calculated and therefore perhaps should not be stored in a data file. Comments? I'm working on an uploader tool to import data from Garmin initially, eventually various fitness GPS formats and send them to a web service. The client tool will be able to downsample the data in the event that the resolution is too high. The web service will accept GPX only, rather than multiple proprietary GPS data formats. I definitely need to upload more than the core GPX data so an extension is required. I'd rather not reinvent the wheel by creating my own proprietary extension to GPX if there is/could be a broadly accepted "fitness" extension. I think the cluetrust extension is a good starting point but it seems to need paring down. I've worked on standards efforts before and I have seen the value of input from multiple interested parties. Is there any interest in creating an "official" GPX extensions project, perhaps with a sourceforge site? Thanks, Gareth. --- In gpsxml+yahoogroups.com, Daniel Barlow <dan+...> wrote: > > > The new(ish) breed of Garmin GPS receivers (Forerunner 305, Edge 305) > have additional sensors for heart rate and cadence and log them with > each point. I'd like to be able to represent this data within the GPX > format - what existing practice is there for encoding it? > > I'm aware of the GPXDATA extension created by/for LoadMyTracks - > http://www.cluetrust.com/Schemas/gpxdata10.xsd - is there anything > other than that program using it? Is it likely to become a (de > facto/actual) standard? Are there other contenders? > > > -dan > > -- > http://www.coruskate.net/ >
robertlipe+usa.net on Fri Dec 22 09:36:20 2006 (link), replying to msg
> It seems that the cluetrust GPXDATA extension has recreated portions > of the Garmin TrainingCenter namespace as GPX extensions. I'm not > convinced for example that adding the Run/Laps to GPX (or an > extension) is necessary. Many of the values that are stored in It depends on what you want to do with the data, of course. GPSBabel's internal data structures more closely match what's representable in the data set you describe. Some people find that "enough" but the actual workout geeks need more robust data in training-specific programs. I get the impression that a lot of folks in this market just want relatively straightforward HRM/Cadence/Temp collection. > rather not reinvent the wheel by creating my own proprietary extension > to GPX if there is/could be a broadly accepted "fitness" extension. I > think the cluetrust extension is a good starting point but it seems to > need paring down. Glancing through the XSD, most of the items you're concerned about are optional. If you just don't populate them and/or don't read them does that extension otherwise work for you? RJL
gobrien+oai.cc on Fri Dec 22 10:14:05 2006 (link)
Robert, I could ignore the items that I don't want to use. The only concern that I have with this is that I have seen situations where there are several ways to express the same data within the same schema. If I choose element A to represent particular data and another developer uses element B to represent the same data, the result is no interop, i.e. my gpx file and his are not interchangeable even though we are both using the same schema and trying to represent the same workout session. By keeping to the absolutely smallest schema possible and only adding an element or attribute if there is no existing way to represent the desired data the opportunities for such mismatches are reduced. GPX seems to be recognized as a de-facto low-level GPS data interchange format and the level of interop seems high. I'm thinking that a GPX-Fitness schema extension and a GPX-Aviation schema extension, etc. might lead to better interop in those specific domains. Gareth. _____ From: Robert Lipe [mailto:robertlipe+usa.net] Sent: Friday, December 22, 2006 11:35 To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Re: Extensions for heart rate/cadence data? > It seems that the cluetrust GPXDATA extension has recreated portions > of the Garmin TrainingCenter namespace as GPX extensions. I'm not > convinced for example that adding the Run/Laps to GPX (or an > extension) is necessary. Many of the values that are stored in It depends on what you want to do with the data, of course. GPSBabel's internal data structures more closely match what's representable in the data set you describe. Some people find that "enough" but the actual workout geeks need more robust data in training-specific programs. I get the impression that a lot of folks in this market just want relatively straightforward HRM/Cadence/Temp collection. > rather not reinvent the wheel by creating my own proprietary extension > to GPX if there is/could be a broadly accepted "fitness" extension. I > think the cluetrust extension is a good starting point but it seems to > need paring down. Glancing through the XSD, most of the items you're concerned about are optional. If you just don't populate them and/or don't read them does that extension otherwise work for you? RJL [Non-text portions of this message have been removed]
robertlipe+usa.net on Fri Dec 22 10:44:40 2006 (link), replying to msg
> I could ignore the items that I don't want to use. The only concern that > I have with this is that I have seen situations where there are several > ways to express the same data within the same schema. If I choose > element A to represent particular data and another developer uses > element B to represent the same data, the result is no interop, i.e. my You may have no interop. If you the other developer uses schema A and you create schema B, you will definitely have no interop. I'm not saying there's never a reason to fork, of course; only that you shouldn't enter it lightly. Have you taken your concerns to cluetrust? Would you be better off getting your efforts behind a revised version of theirs? > format and the level of interop seems high. I'm thinking that a > GPX-Fitness schema extension and a GPX-Aviation schema extension, etc. > might lead to better interop in those specific domains. All it takes is experts in the respective areas to drive them. That's what we've lacked in this group. The result has been that folks tend to "scratch their own itch" with schemas much like the one you cite. ..which tends to suffer from lack of peer review, interop concerns, etc. RJL
ptomblin+gmail.com on Fri Dec 22 19:27:15 2006 (link), replying to msg
On 12/22/06, Gareth O'Brien <gobrien+oai.cc> wrote: > GPX seems to be recognized as a de-facto low-level GPS data interchange > format and the level of interop seems high. I'm thinking that a > GPX-Fitness schema extension and a GPX-Aviation schema extension, etc. > might lead to better interop in those specific domains. I wish there was a "GPX-Aviation" schema. I wish I was in contact with more people interested in aviation data. I threw a lot of aviation specific data into my "navaid" extension to the GPX schema mostly as an experiment, and so far I've only been in contact with one person who is actually using the extra data I provide. And since my major source of data for the world outside of the US (DAFIF) has gone away, anything that would make it easier to share data between the various flight planning and en-route programs would be a good thing. Sorry, I didn't really have anything useful to contribute to this discussion, I'm just ranting. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
dorgemano+yahoo.com on Tue Dec 26 05:33:20 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, "guido_p_schmidt" <guido+...> wrote: > a step further in the tourguide, > > with the new beta software it is possible to use the phone when > active. Even when it loaded as tourguide. see: > http://static.flickr.com/128/320428424_d7716a2d9d_o.jpg > > In this beta the size of the text fields are limeted. I have asked > garmin to fix this problem. The phone number field doesn't need 'tourguide' to work. You can just use the phone number element in a .gpx field: <wpt lat ="44.39874" lon ="2.730013"> <name>Eddie's House</name> <extensions> <gpxx:WaypointExtension> <gpxx:PhoneNumber Category="Phone">+44 1245 123456</gpxx:PhoneNumber> <gpxx:PhoneNumber Category="Phone2">123-4568</gpxx:PhoneNumber> <gpxx:PhoneNumber Category="Fax">611-1635</gpxx:PhoneNumber> <gpxx:PhoneNumber Category="Email">bobby+example.com</ gpxx:PhoneNumber> </gpxx:WaypointExtension> </extensions> </wpt> If a BlueTooth phone is connected the 'dial' button will appear next to the number in the 'Phone' category. There doesn't seem to be any special feature for numbers in other categories.
slavins+hearsay.demon.co.uk on Sun Dec 31 15:08:05 2006 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > If you can come up with a detailed description of what > you'd like to be able to express in your GPX files, I will help by > converting it to an external schema. The Garmin extensions allow for a Proximity alert element. Since some Garmin SatNav units also provide for a speed alert (for speed cameras) I have had to unofficially invent my own Speed element: <wpt lat ="44.39874" lon ="2.730013"> <name>Eddie's House</name> <extensions> <gpxx:WaypointExtension> <gpxx:Proximity>1000</gpxx:Proximity> <gpxx:Speed>13.91</gpxx:Speed> <!-- this line is not legal XML --> </gpxx:WaypointExtension> </extensions> </wpt> Since both alert elements are present in the above example, it represents a speed alert: if you are within 1000metres of the point and your speed is greater than 13.91m/s, the alert will sound. Garmin's extension is defined here http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd but Garmin's documentation is often a little behind what their devices can actually do. I'm hoping that since GEv3 is one of their own specifications they'll expand it to include the Speed element. These extensions include many valuable additions to GPX including address and phone number information. I think it would be great if they formed a basis for discussion on a future version of GPX. Simon.
bcwatson+yahoo.com on Sun Dec 31 15:21:04 2006 (link), replying to msg
But what I'd really like to see Garmin or anyone else come out with is a proximity alert based on "type" of waypoint. So, if I need a restroom/gas station (or whatever the proper type is for that) I could just select the proper symbol and have it tell me when I'm within a mile of one. But much better used for geocaching. I could set the proximity alarm on the geocache symbol and it will tell me when I'm within 'x' miles of it instead of me having to set a specific waypoint. I mean what's the point of that when I already know where it is? But with a prox. alarm on the type, I can upload a large amount of them and then just carry on about my business and not have to check the GPS every x minutes to see if I'm near any.... Barry simonslavin <slavins+hearsay.demon.co.uk> wrote: --- In gpsxml+yahoogroups.com, Dan Foster wrote: > If you can come up with a detailed description of what > you'd like to be able to express in your GPX files, I will help by > converting it to an external schema. The Garmin extensions allow for a Proximity alert element. Since some Garmin SatNav units also provide for a speed alert (for speed cameras) I have had to unofficially invent my own Speed element: Eddie's House 1000 13.91 Since both alert elements are present in the above example, it represents a speed alert: if you are within 1000metres of the point and your speed is greater than 13.91m/s, the alert will sound. Garmin's extension is defined here http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd but Garmin's documentation is often a little behind what their devices can actually do. I'm hoping that since GEv3 is one of their own specifications they'll expand it to include the Speed element. These extensions include many valuable additions to GPX including address and phone number information. I think it would be great if they formed a basis for discussion on a future version of GPX. Simon. Yahoo! Groups Links __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com [Non-text portions of this message have been removed]
kerry.raymond+gmail.com on Sun Dec 31 16:05:13 2006 (link)
It sounds a very handy feature to me. Maybe you should suggest it to Garmin? Technically I can't see this as being any big problem. The only issue would be the availability of the data sets and the the size of the data sets to be downloaded into the GPS unit - every tourist attraction, bar, restroom, gas station, post office, cafe, parking station, parking meter, etc ... could all add up. But it's only memory and that is increasingly less of a limitation than it once was. Being in IT myself, I think part of the problem that Garmin have is one of mindset. They've come from an engineering background with the challenge of making as accurate a GPS unit as they could in an era when they were sold at high cost to a small set of people for what you might call "serious application". However, they succeeded. They now sell to a large consumer market whose first question is no longer "how accurate is it?" but rather "what useful thing can it do for me?". This means that internal to Garmin they have to switch from an engineering build-a-positioning-device mindset to a provide-the-user-with-a-location-based-service suite of applications mindset. Many engineering businesses find this a difficult switch to make as it's a different skill set. I have to say that as a consumer device, my Gamin GPS (eTrex Vista C) is appallingly un-user-friendly. The interface is completely un-intuitive. It is easy to put it into strange modes of operation for which the simplest solution is to turn it off and on again! The manual is a disaster, thick but unhelpful. Many pages take a form of "To turn on the whatsitfeature, do this sequence of menu choices. To turn off the whatsitfeature, do this sequence of menu choices." without every explaining what the feature actually does, how it interacts with any other enabled feature etc. As a consequence, I have a device with many features that I simply never use. I notice that some of the companies that get good reviews for GPS-based products aren't the companies with a long history in developing GPS devices. Which is why I think Garmin need to make that mindset switch, or they will be overtaken by other companies in terms of product appeal. Kerry ----- Original Message ----- From: Doc To: gpsxml+yahoogroups.com Sent: Monday, January 01, 2007 9:17 AM Subject: Re: [gpsxml] Re: Proximity Alarms But what I'd really like to see Garmin or anyone else come out with is a proximity alert based on "type" of waypoint. So, if I need a restroom/gas station (or whatever the proper type is for that) I could just select the proper symbol and have it tell me when I'm within a mile of one. But much better used for geocaching. I could set the proximity alarm on the geocache symbol and it will tell me when I'm within 'x' miles of it instead of me having to set a specific waypoint. I mean what's the point of that when I already know where it is? But with a prox. alarm on the type, I can upload a large amount of them and then just carry on about my business and not have to check the GPS every x minutes to see if I'm near any.... Barry simonslavin <slavins+hearsay.demon.co.uk> wrote: --- In gpsxml+yahoogroups.com, Dan Foster wrote: > If you can come up with a detailed description of what > you'd like to be able to express in your GPX files, I will help by > converting it to an external schema. The Garmin extensions allow for a Proximity alert element. Since some Garmin SatNav units also provide for a speed alert (for speed cameras) I have had to unofficially invent my own Speed element: Eddie's House 1000 13.91 Since both alert elements are present in the above example, it represents a speed alert: if you are within 1000metres of the point and your speed is greater than 13.91m/s, the alert will sound. Garmin's extension is defined here http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd but Garmin's documentation is often a little behind what their devices can actually do. I'm hoping that since GEv3 is one of their own specifications they'll expand it to include the Speed element. These extensions include many valuable additions to GPX including address and phone number information. I think it would be great if they formed a basis for discussion on a future version of GPX. Simon. Yahoo! Groups Links __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com [Non-text portions of this message have been removed] [Non-text portions of this message have been removed]
kemoelhref12+yahoo.com on Sun Dec 31 23:04:34 2006 (link)
Who is the moderator for this group? Anyone?
ptomblin+gmail.com on Sun Jan 07 09:28:35 2007 (link), replying to msg
On 1/6/07, Martin <martinp13+earthlink.net> wrote: > Who is the moderator for this group? Anyone? Nobody. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
martinp13+earthlink.net on Sun Jan 07 12:19:01 2007 (link), replying to msg
Thanks, that's what I thought. :( > Martin >
kemoelhref12+yahoo.com on Sun Jan 07 16:27:43 2007 (link), replying to msg
Hello, I had no idea there was so much spam coming through - my email filters have been catching it all. I banned the three latest spammers. Feel free to send member names to me directly at Dan Foster <egroups+topografix.com> for removal. This is an unmoderated list. I set up the mailing list on Yahoo Groups, so in their view I "own" it and can delete messages or ban people. If spam is a problem (and it sounds like it is), I'd be willing to change the list to a moderated discussion group, but only if at least two people step forward and agree to be moderators. That would ensure that there's no censorship of posts on my part, and would keep the group from grinding to a halt when I go on vacation. -- Dan Foster -- Dan Foster
robertlipe+usa.net on Mon Jan 08 09:24:15 2007 (link), replying to msg
> I banned the three latest spammers. Feel free to send member names to Thank you. > If spam is a problem (and it sounds like it is), I'd be willing to > change the list to a moderated discussion group, but only if at least > two people step forward and agree to be moderators. That would ensure Is there a way to just moderate the first post by a user? In other groups, that's been very effective at keeping out the riff-raff. I don't know the yahoogroup scheme, but I'll help if I can. It's not like this is a high-traffic list. RJL
gps_maps+travelbygps.com on Mon Jan 08 09:28:46 2007 (link), replying to msg
--- Dan Foster wrote: > I had no idea there was so much > spam coming through Now I understand why you did not seem to get my sarcasm about this being the place to get stock trading tips. I forgive you ;) - Doug
dananderson2+yahoo.com on Tue Jan 09 07:21:59 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > If spam is a problem (and it sounds like it is), I'd be willing to > > change the list to a moderated discussion group, but only if at least > > two people step forward and agree to be moderators. That would ensure > > Is there a way to just moderate the first post by a user? In other > groups, that's been very effective at keeping out the riff-raff. > > I don't know the yahoogroup scheme, but I'll help if I can. It's not > like this is a high-traffic list. I'm also willing to help if needed.
egroups+topografix.com on Wed Jan 10 10:12:43 2007 (link), replying to msg
Hello, Wednesday, January 10, 2007, 11:21:21 AM, Simon wrote: > I have the task of inventing an extended GPX format to cope with > multilanguage text. > My resulting file does not have to be absolutely compliant with GPX > as it stands, but it should try not to freak out non-validating > parsers too much. It cannot not have a .gpx extension then. If it's a GPX file, it *must* validate. If it's an XML file that just happens to reference the GPX schema for part of its contents, that GPX content should validate. None of the examples you offered validated when I pasted them into a GPX 1.1 file. EasyGPS refused to open the file, and pointed to the line number that contained the mal-formed GPX. What about the following GPX solutions? 1. Distribute a different GPX file for each language. This would work with any GPX program. 2. Distribute a single GPX file that repeats every waypoint once per language, and have some extension schema that tells your program what language is in use: <wpt ...> <desc>Gut zum Fr?hst?ck.</desc> <extensions> <my_schema:lang="DE"/> </extensions> </wpt> <wpt ...> <desc>Bon pour le petit d?uner.</desc> <extensions> <my_schema:lang="FR"/> </extensions> </wpt> Programs that didn't understand my_schema:lang would end up with multiple copies of each waypoint, but at least the file would open. 3. Propose a GPX 2.0 that allows multiple language support. -- Dan Foster
bengt.baverman+gmail.com on Sun Jan 14 14:41:03 2007 (link)
I cannot find a word about GPX 1.0 on the web site. The forum speaks about it and how long it will take to upgrade all programs from understanding 1.0to understanding (and writing) 1.1. Still I cannot find anything formal about the 1.0 version of the GPX standard. Where can I find it? /Bengt B [Non-text portions of this message have been removed]
salcedo+yahoo.com on Mon Jan 15 10:20:42 2007 (link), replying to msg
Hi Bengt, The good folks (folk) at TopoGrafix have the schema definitions available online at: http://www.topografix.com/GPX/1/0/gpx.xsd http://www.topografix.com/GPX/1/1/gpx.xsd -Ricardo
robertlipe+usa.net on Mon Jan 15 10:56:14 2007 (link)
> Mind you, the best (only ?) documentation on GPX 1.1 is here: > > <http://www.topografix.com/gpx_manual.asp> Actually, that's 1.0. I'll admit that I actually liked the terse, highly focused format of that spec when I was in development mode - it was very easy to sit and _read_ but I've warmed up to the format of http://www.topografix.com/GPX/1/1/ over time. It makes a nice reference, but I doesn't lend itself as well to a top-down understanding of things.
ptomblin+gmail.com on Mon Jan 15 11:00:44 2007 (link), replying to msg
On 1/15/07, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > > > > Mind you, the best (only ?) documentation on GPX 1.1 is here: > > <http://www.topografix.com/gpx_manual.asp> > > and frankly that's short to the point of terseness. > > There is a bit more at http://www.topografix.com/gpx_resources.asp but I'm curious as to where there is no mention of GPX 1.2 at all anywhere on this site that I can find. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt [Non-text portions of this message have been removed]
robertlipe+usa.net on Mon Jan 15 11:11:27 2007 (link)
> There is a bit more at http://www.topografix.com/gpx_resources.asp > but I'm curious as to where there is no mention of GPX 1.2 at all Because it doesn't exist? Just a guess. I could be wrong.
ptomblin+gmail.com on Mon Jan 15 11:34:55 2007 (link), replying to msg
> > There is a bit more at http://www.topografix.com/gpx_resources.asp > > but I'm curious as to where there is no mention of GPX 1.2 at all > > Because it doesn't exist? That will be a big surprise to anybody who implemented based on http://www.topografix.com/GPX/1/2/gpx.xsd I remember somebody, probably Dan Foster, telling me over a year ago I shouldn't bother extending the 1.1 schema because 1.2 is current. What happened? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
robertlipe+usa.net on Mon Jan 15 12:16:43 2007 (link), replying to msg
> > Because it doesn't exist? > > That will be a big surprise to anybody who implemented based on > http://www.topografix.com/GPX/1/2/gpx.xsd I recall the change in question (there's one material line different between that one and 1.1) being proposed, but I didn't recall anything past 1.1 being actually released. I've never seen a GPX 1.2 file "in the wild" and didn't know it was ever made official. I'm still not sure if it _is_ official or if this was a placeholder to discuss a work in progress. Did I really miss that page turning? Dan? RJL
egroups+topografix.com on Mon Jan 15 13:51:27 2007 (link), replying to msg
Hello, >> > There is a bit more at http://www.topografix.com/gpx_resources.asp >> > but I'm curious as to where there is no mention of GPX 1.2 at all >> >> Because it doesn't exist? Monday, January 15, 2007, 2:26:18 PM, Paul wrote: > That will be a big surprise to anybody who implemented based on > http://www.topografix.com/GPX/1/2/gpx.xsd > > I remember somebody, probably Dan Foster, telling me over a year ago I > shouldn't bother extending the 1.1 schema because 1.2 is current. > What happened? I just re-read every message on this mailing list containing the phrase "GPX 1.2". I didn't find anything that suggested that GPX 1.2 is current, or available for public use. I did, however, find this, which explains why there is a GPX 1.2 schema on the server: Dan Foster - 19 Jan, 2005: re: [gpsxml] GPX 1.1 <extensions> allows broken GPX to validate The <extensions> element in GPX 1.1 imposes "lax" processing on elements included from other schemas. Because of this our SaxCount validation test will fail to show errors in a GPX file if the errors are related to a second or third namespace. I've created a simple file that puts a bogus <flooz> element in <extensions>. This validates using SaxCount. Try it: http://www.topografix.com/gpx/samples/TopoGrafix/flooz.gpx The fix is to change the "lax" processing on <extensions> to "strict". I've created a GPX 1.2 namespace with this single change so that I could continue testing my instance documents correctly. Feel free to use it for your own testing, but be sure to switch back to GPX 1.1 namespace before releasing software. -- Dan Foster
ptomblin+gmail.com on Mon Jan 15 14:31:51 2007 (link), replying to msg
On 1/15/07, Dan Foster <egroups+topografix.com> wrote: > The fix is to change the "lax" processing on <extensions> to "strict". > I've created a GPX 1.2 namespace with this single change so that I > could continue testing my instance documents correctly. Feel free to > use it for your own testing, but be sure to switch back to GPX 1.1 > namespace before releasing software. > Well, that explains why I was using 1.2. I guess I forgot the part about changing back to 1.1 for release. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
egroups+topografix.com on Tue Jan 16 13:20:37 2007 (link), replying to msg
Hello, Monday, January 8, 2007, 12:06:20 PM, I wrote: > If spam is a problem (and it sounds like it is), I'd be willing to > change the list to a moderated discussion group, but only if at least > two people step forward and agree to be moderators. That would ensure > that there's no censorship of posts on my part, and would keep the > group from grinding to a halt when I go on vacation. The group is now moderated and new members will have their posts approved before they are sent out to everyone on this list. Hopefully this will cut down on the spam problem. This group's moderators are: Dan Anderson Dan Foster Robert Lipe -- Dan Foster
yahoo+slacy.com on Tue Jan 16 17:53:23 2007 (link), replying to msg
I'd like to know this as well. I'm doing some GPX-based web application development, and the codebase uses mime type as an identifier for the contents of the file, so using text/xml for the mime type isn't really right, since there are other GPS formats that use XML as well. I've hardcoded it as application/x-gpx, but it would be nice if there were an "official" stance on the proper mime type, and submission to the right standards body to get it officially approved. Steve --- In gpsxml+yahoogroups.com, "bbalxx" <bbalxx+...> wrote: > > hello, > > I am new to this forum, an in the process of configuring a server. I have noticed many ISP's > serve up .xml files, though my current ISP does not serve up .gpx files. To configure Apache, > what is the proper MIME type which should be used to serve .gpx files? > > thanks, > brian. >
distobj+acm.org on Tue Jan 16 18:17:10 2007 (link), replying to msg
On 1/16/07, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > > On 17 Jan 2007, at 1:06am, smlacy wrote: > > > I'd like to know this as well. I'm doing some GPX-based web > > application development, and the codebase uses mime type as an > > identifier for the contents of the file, so using text/xml for the > > mime type isn't really right, since there are other GPS formats that > > use XML as well. > > Can you tell us why text/xml isn't the right solution ? Because the role of the media type in an HTTP message is to help the recipient identify the specification needed to interpret the body of the message, and "text/xml" or "application/xml" doesn't do that. It's akin to sending HTML as text/plain. If you're interested in a more exhaustive explanation, see; http://www.w3.org/2001/tag/doc/mime-respect.html I've done two media type registrations with IANA, and currently moderate the IETF media type mailing list. I'd be happy to help with the registration process. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
simonstl+simonstl.com on Tue Jan 16 18:37:06 2007 (link), replying to msg
Simon Slavin wrote: > On 17 Jan 2007, at 2:13am, Mark Baker wrote: > Okay, I can understand that. > > So in your view what would be the perfect type ? 'xml/gpx' ? Or > since I see there's no 'xml/', 'text/gpx' ? > > Or is now the time to create a 'xml/' content type ? I'd recommend application/gpx+xml. See RFC 3023: http://ietf.org/rfc/rfc3023.txt Thanks, Simon St.Laurent http://simonstl.com/
ebook4sania+yahoo.com on Tue Jan 16 22:51:52 2007 (link), replying to msg
sania dev wrote: [ Confession of an evil spammer ] POOF! User banned and removed from list. It's good to have superpowers... RJL
robertlipe+usa.net on Wed Jan 17 00:14:38 2007 (link), replying to msg
> Can you tell us why text/xml isn't the right solution ? All the GPX brokers/vendors I've seen have dealt with this with a AddType application/xml gpx in their ~/.htaccess (or moral equivalent). RJL
jhempy+gmail.com on Wed Jan 17 07:00:20 2007 (link), replying to msg
Yay! Not only was that spam, it was long spam. Talk about adding insult to injury! ;-) Janine On 1/17/07, Robert Lipe <robertlipe+usa.net> wrote: > > sania dev wrote: > > [ Confession of an evil spammer ] > > POOF! User banned and removed from list. > > It's good to have superpowers... > > RJL > > > [Non-text portions of this message have been removed]
lorax1284+yahoo.com on Wed Jan 17 08:30:35 2007 (link)
Hello gpsxml, I'm looking for suggestions as to how geo-referenced photos (synced by timestamp between the camera and the GPS tracklog) should be expressed in a GPX file. When the photo location coincides with a waypoint, it's pretty obvious how to proceed (photo goes in the <link> element of the waypoint). What about photos that lie along a recorded tracklog but aren't associated with any waypoint? How should they be expressed in GPX? -- Dan Foster
lorax1284+yahoo.com on Wed Jan 17 08:58:05 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > > Can you tell us why text/xml isn't the right solution ? > > All the GPX brokers/vendors I've seen have dealt with this with a > AddType application/xml gpx > in their ~/.htaccess (or moral equivalent). Hi; I'm new to the group, but 'old' to XML. I haven't had time to thoroughly review the RFC at http://ietf.org/rfc/rfc3023.txt but it was written in 2001, and I've heard not even faint rumblings of this gaining acceptance as a recommended way to craft mime types. You can set your own server up any old way you want and serve .jpg files a text/applesauce if you want, but all that will do is throw off client-side apps that should logically be able to process the data. A distinct mime-type will allow the app and OS to a lesser extent to deal with the file regardless of the file extension: except on Windows. I have AGONIZED trying to find out how to configure the Windows OS with file type / mime type / threeletterextension combinations such that arbitrarily served filenames 'announced' with the proper MIME-Type can automatically launch the correct client application. I searched and searched for literally DAYS (I'm talking maybe 20 hours in front of various search engines, MSDN, etc, trying to get enough info to assemble a report for the developers at the software company where I'm employed.) The only solution was to ensure ALL files are served with the correct file extension for Windows OS. Sending a datastream without a file name, and that filename not having a three letter extension known by the OS is NOT ENOUGH. It should be. The Mime-Type should trump everything else the OS thinks it knows about the file... but alas that's not true on Windows. So, I'd suggest you standardize the mime-type and three letter extension for both at once. Personally, "text/xml" is equivilant to saying "text/plain", which as was previously mentioned, does nothing to assist the client side application or OS to properly parse the file. I have seen mime-type naming-convention standards that are vendor-specific: "application/vnd.vendorname.filetype" but that's not applicable here. If you can hold off making a decision, I'll read through that RFC, consult with colleagues and hopefully provide an 'informed' opinion (not that you all aren't informed, just that I'd be happy to contribute, as I have some experience in this area.) Thanks for all your efforts on the GPX standard, and I hope I can contribute. Ryan
robertlipe+usa.net on Wed Jan 17 08:58:08 2007 (link)
> I'm looking for suggestions as to how geo-referenced photos (synced by > timestamp between the camera and the GPS tracklog) should be expressed > in a GPX file. When the photo location coincides with a waypoint, > it's pretty obvious how to proceed (photo goes in the <link> element > of the waypoint). > > What about photos that lie along a recorded tracklog but aren't > associated with any waypoint? How should they be expressed in GPX? Every time I've seen this done, they're just <link> elements of the closest (distance or time) trackpoint.
egroups+topografix.com on Wed Jan 17 09:24:07 2007 (link)
Hello gpsxml, Most of us have been using <link> to store URIs to photos in our GPX files. In GPX 1.1, the <link> element didn't get an <extensions> element, so there's no way to add additional information to a link. <xsd:complexType name="linkType"> <xsd:sequence> <-- elements must appear in this order --> <xsd:element name="text" type="xsd:string" minOccurs="0"/> <xsd:element name="type" type="xsd:string" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="href" type="xsd:anyURI" use="required"/> </xsd:complexType> <!-- this probably should have been after "type"... --> <xsd:element name="extensions" type="extensionsType" minOccurs="0"/> For many applications, just having a link to an image file is probably sufficient. For others, however, it would be nice to have some more metadata available for images, especially photos. Some of the things that come to mind are: URI to image image type (might not be obvious if URI is to a cgi script, e.g.) image height and width URI to thumbnail image geo-referencing/calibration data (if the image is a scanned map, e.g.) timestamp photo taken camera model I could see this being useful for interchange between programs that support any of the following: photos (geo-referenced or not) scanned raster basemaps bitmaps (Garmin custom icons, etc) Is anyone else interested in collaborating on an extensible schema for images that could be used within GPX files? -- Dan Foster
kaz+okuda.ca on Wed Jan 17 09:27:27 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > Hello gpsxml, > > I'm looking for suggestions as to how geo-referenced photos (synced by > timestamp between the camera and the GPS tracklog) should be expressed > in a GPX file. When the photo location coincides with a waypoint, > it's pretty obvious how to proceed (photo goes in the <link> element > of the waypoint). > > What about photos that lie along a recorded tracklog but aren't > associated with any waypoint? How should they be expressed in GPX? > The problem with using existing points in the file to reference your photos is that your photo may not coincide exactly with a tracklog point or waypoint. You may have a photo that you manually located because the GPS didn't have a good signal at the time you took it. If you are using the tracklog to automatically identify the location of the photos then you still have the problem of what if the time the photo was taken is between two trackpoints (most likely if you were moving at the time). I have played around with this a bit and the first thing is to put the GPS data in the photo EXIF header, then it is with the photo. If you need an external file, like a GPX, to reference the photo then I would recommend creating a waypoint just for that photo. I have used this model in a GPX viewing script that I wrote specifically to show photos on a track (though I never wrote the back-end to automatically add it). This page (http://notions.okuda.ca/geotagging/projects-im-working-on/gpx-viewer/) gives an example of what I mean - though it is never complete.
lorax1284+yahoo.com on Wed Jan 17 09:55:08 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > > Can you tell us why text/xml isn't the right solution ? > > All the GPX brokers/vendors I've seen have dealt with this with a > AddType application/xml gpx > in their ~/.htaccess (or moral equivalent). Based on my read of: http://tools.ietf.org/html/rfc2046 specifically http://tools.ietf.org/html/rfc2046#page-6 "4.1.4. Unrecognized Subtypes Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset." ...which makes "text" type inappropriate, as GPX is not plain text and other processing platforms that don't have explicit GPX support will fall back to text/plain wrongly for this particular XML dialect. I suggest GPX correctly belongs in the "application" space, which is what the GPS vendors are doing in their .htaccess... but is that a space character I see in the subtype? "application/xml[space]gpx"? Although spaces may be allowed in mime-subtypes, I think a hyphen or period is more common. Just checking, while I continue to read various IETF RFCs.
lorax1284+yahoo.com on Wed Jan 17 10:00:21 2007 (link), replying to msg
Sorry to reply to my own posting, but I don't believe I could edit a posting to add new information (which is an argument for not posting until you have all the information, but...) This document: ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt is an excellent backgrounder for MIME-type discussion. It's not that difficult to read, once you get past the ascii pagination. To summarize: MIME-subtypes are not supposed to have space chars. If GPS vendors are indeed using a MIME-subtype with a space in it on their Web servers, they shouldn't, according to this spec. Fallback to "plain text" for any unregistered "text" type subtypes is not suitable for documents containing markup, so something like "text/xml.gpx" is not recommended. "text/xml" is too generic for the purposes GPX serves. So, after reading that RFC, it seems clear that the "application" type is most appropriate. For subtype, since GPX is not vendor-specific, personal, or experimental, "vnd", "prs" or "x" are not suitable. I'm going to throw this out there: application/gps.gpx That leaves the door open to setting MIME types for vendor-specific (proprietary? patented?) GPS data as application/gps.garmin etc. You might also decide it's best to differentiate GPS data 'compartments' with another level of granularity: application/gps.waypoint.gpx application/gps.waypoint.garmin leaving room for future innovation without disrupting the naming convention.
egroups+topografix.com on Wed Jan 17 10:03:40 2007 (link), replying to msg
Hello, Wednesday, January 17, 2007, 12:25:26 PM, Poco wrote: > The problem with using existing points in the file to reference your > photos is that your photo may not coincide exactly with a tracklog > point or waypoint. > > You may have a photo that you manually located because the GPS didn't > have a good signal at the time you took it. That's an important point - there may be photos that aren't associated with any GPS data. It would be nice if there was one way to deal with all of these situations. I'm invisioning something like this (in pseudo-GPX): <img> would be a new element, defined in it's own schema and included via the <extensions> element in <wpt> and <trk>. <gpx> <wpt lat="12.34" lon="45.67"> <img...> // this image is directly associated with the waypoint, and inherits its location. </wpt> ... <trk> <img lat="12.34" lon="45.67"> // this image occurs somewhere along the track <trkseg.../> // trackpoints here </trk> ... <img lat="12.34" lon="45.67"> // this image is independent from all the other GPS data in the file. </gpx> -- Dan Foster
gps_maps+travelbygps.com on Wed Jan 17 10:29:59 2007 (link), replying to msg
--- "bbalxx" wrote: > what is the proper MIME type which should be used to serve .gpx files? Brian, There are the server control panel setting I'm using for User Defined MIME Types: application/octet-stream .gpx Most of the time when a visitor clicks on a .gpx file link, the associated application (i.e. ExpertGPS) will automatically launch and open the file. Every now and then someone will email me with "Hey I clicked on the link and all I got was a bunch of computer code garbage" Also, once in a while, someone will email me saying that they tried to "Save As..." and somehow the xml file type extension got appended. The occurance of these reported problems is a fraction of 1% of all downloads. Over the years I've experimented with this setting and this is what seems to work. Of course, If there is a better setting, I'd like to know too. - Doug www.TravelByGPS.com
distobj+acm.org on Wed Jan 17 10:32:42 2007 (link), replying to msg
On 1/17/07, Ryan Germann <lorax1284+yahoo.com> wrote: > Sorry to reply to my own posting, but I don't believe I could edit a > posting to add new information (which is an argument for not posting > until you have all the information, but...) > > This document: > > ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt > > is an excellent backgrounder for MIME-type discussion. It's not that > difficult to read, once you get past the ascii pagination. > > To summarize: MIME-subtypes are not supposed to have space chars. Right, but I believe the previous poster was simply describing the Apache AddType declaration which takes a media type and a file extension; the space was white space. I like Simon's "application/gpx+xml" proposal. Mark.
egroups+topografix.com on Wed Jan 17 12:03:57 2007 (link), replying to msg
Hello, Wednesday, January 17, 2007, 1:46:58 PM, Simon wrote: > What you're > trying to do is take entities (images) and associate data with them. > That's what EXIF is for. You can use that to tag images with > information including many GPS-related attributes: There are many instances where I want to associate data with images that I don't own or have the opportunity to modify. As an example, I want to pass a GPX file containing waypoints for Iraq from ExpertGPS to some other GPX-enabled mapping program, and I want to reference the basemap being used as follows: <img src="http://www.lib.utexas.edu/maps/cia06/iraq_sm_2006.gif"> <width>200</width> <height>200</height> <calibration point lat="23.123" lon="52.234" x="0" y="200"/> <calibration point lat="23.456" lon="52.789" x="400" y="600"/> </img> I don't have access to the U Texas Web site, so I can't modify their image to include all of this in EXIF in the image header. What I'd like to do is to reference another schema in my GPX file that mirrors some of the EXIF (or IPTC, or XMP) fields in an XML format. -- Dan Foster
robertlipe+usa.net on Wed Jan 17 12:20:42 2007 (link), replying to msg
> > All the GPX brokers/vendors I've seen have dealt with this with a > > AddType application/xml gpx > > in their ~/.htaccess (or moral equivalent). > > I suggest GPX correctly belongs in the "application" space, which is > what the GPS vendors are doing in their .htaccess... but is that a > space character I see in the subtype? "application/xml[space]gpx"? > Although spaces may be allowed in mime-subtypes, I think a hyphen or > period is more common. Since this question is usually asked by webmasters, I assumed Apache configuration was an appropriate lingo. Sorry to have confused matters more. The above tells the web server to serve up files whose name end in "gpx" to be of MIME type "application/xml".
azbithead+gmail.com on Wed Jan 17 12:28:22 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Paul Tomblin" <ptomblin+...> wrote: > Well, that explains why I was using 1.2. I guess I forgot the part > about changing back to 1.1 for release. I recommend that this "unofficial" GPX 1.2 be either completely taken off the Topografix server or moved to a different URL. Currently, there is no easy way for developers who accidentally stumble onto this to understand that this is not an officially released version of GPX. I understand that some developers may want to do some testing with this unreleased schema. If so, the URL for the schema should clearly indicate that it is not released (perhaps http://www.topografix.com/GPX/1/2/UNRELEASED/gpx.xsd) and that should also be clearly stated inside the schema itself. - Steve
dananderson2+yahoo.com on Wed Jan 17 13:22:01 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > On 17 Jan 2007, at 6:00pm, Dan Foster wrote: > > > That's an important point - there may be photos that aren't associated > > with any GPS data. It would be nice if there was one way to deal with > > all of these situations. > > > > I'm invisioning something like this (in pseudo-GPX): > > > > <img> would be a new element, defined in it's own schema and included > > via the <extensions> element in <wpt> and <trk>. > > On that basis, those images don't belong in GPX at all. What you're > trying to do is take entities (images) and associate data with them. [snip] I agree that images don't belong in GPX. GPX is for waypoint, route and track data. A waypoint can include a link to anything. I believe a photo/image that is not associated with GPS data belongs in the GPX_Overlay schema assuming that a GPS Utility type program is going to display the image in some way. I proposed some additions to GPX_Overlay to include images in the past but few people were interested. A program that is associating an image with GPS data (matching picture time with timestamps in a track), perhaps, should create a waypoint at whatever coordinates it thinks best match and put a link to the picture in the waypoint. As far as specifying background maps, more fields could be added to my proposal to specify scales, calibration data, projections, etc. GPX_Overlay then could also specify background maps. Dan A. (www.gpsmap.net) (www.westernmaps.us)
kerry.raymond+gmail.com on Wed Jan 17 13:24:01 2007 (link)
It might be simpler to introduce some attribute on waypoint to signify its not really part of the track but is either externally supplied (as in one scenario mentioned) or interpolated (more likely for the typical photo situation). So you still have a waypoint to associate with the photo but its status is different. In theory, you can just take the time the photo was taken from the EXIF data and then use that to find the nearest trackpoints and then interpolate a point (one assumes along the line betwen the two nearest trackpoints). Probably highly inacccurate a if you are running around a maze (say), but OK for more realistic scenarios when you are in a moving vehicle or walking a track. I say "in theory" because obviously you need to synchronise your camera's clock to your GPS's clock for this to work :-) So I don't think it would be particularly hard to write an application that takes a track and a set of photos and creates a new track with the photos added at interpolated waypoints. Kerry [Non-text portions of this message have been removed]
egroups+topografix.com on Wed Jan 17 15:57:37 2007 (link), replying to msg
Hello, Wednesday, January 17, 2007, 3:25:57 PM, azbithead wrote: > I recommend that this "unofficial" GPX 1.2 be either completely taken > off the Topografix server or moved to a different URL. Sounds reasonable. I'll give Paul T. a chance to speak up, since he says he was using the 1.2 schema. If there's no objection or request for delay, I'll remove 1.2 completely next week. -- Dan Foster
ptomblin+gmail.com on Wed Jan 17 16:25:34 2007 (link), replying to msg
On 1/17/07, Dan Foster <egroups+topografix.com> wrote: > > I recommend that this "unofficial" GPX 1.2 be either completely taken > > off the Topografix server or moved to a different URL. > > Sounds reasonable. I'll give Paul T. a chance to speak up, since he > says he was using the 1.2 schema. If there's no objection or request > for delay, I'll remove 1.2 completely next week. I'd rather you just moved it somewhere instead of removing it completely, since it enables strict schema checking which can't be done with 1.1. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
egroups+topografix.com on Wed Jan 17 16:53:17 2007 (link), replying to msg
Hello, I'm going to top-post and quote most of Kerry's message below. I'm surprised this message got so little response - it raises some issues that we really should address regarding the way objects are extended or contained within other objects in GPX. I'm going to suggest that GPX isn't really about exchanging GPS data. It may have started out that way, but it's really become a way to exchange spatial data - points and lines on the Earth. You may have a Web site full of geocaches with hints and descriptions, and I may have a database of oil well locations, but we both use GPX as the basis for our data structures, we can view our data in a program that doesn't know anything about caching or oil, or send it to a GPS receiver, and still get reasonable results (labeled points on a map in the right location). If instead the data structures were arranged to include snippets of GPX for the location- or GPS-specific aspects only, there would be no data interchange possible. Since my program knows nothing of your <geocache> structure, how can it possibly know there's a <gpx> element in there it actually would understand? <geocache schema="geocaching.com/blah..."> <hint>blah...</hint> <location schema="topografix.com/gpx/1/1" lat="42.123"...> </geocache> If we were starting from scratch, I would suggest that the base schema contain nothing more than the definition of a geographic point (lat/lon required, elevation and timestamp optional) and line, and that everything else be built (through extension schemas) on top of that. - Dan Monday, December 4, 2006, 3:06:02 PM, Kerry wrote: > I think we get getting this whole extension idea back-to-front and getting into some bad modelling. > > Take hints for geocaching as an example. Caches have locations; > caches have hints; locations don't have hints. That is, hints are > not a property of locations generally. So what should be happening > is that there needs to be an XML schema for geocaches of which one > component is a location represented in (say) GPX and another component is the hint. > > This is same with phone numbers. People and buildings etc have > phone numbers and people and buildings have locations. But it does > not follow that locations have phone numbers. Make XML schemas for > people etc that contain both a location and a phone number. Don't add phone numbers to locations. > > Unfortunately it is very tempting to say "I need to exchange > information about Foo and Foo has a location and a Bar so lets > incorporate Bar into GPX" but clearly everyone from geocachers to > real estate agents to miners to farmers can come along and say that > because most things have a location. Do we propose to extend GPX to > accommodate information on house prices, vegetation cover, mining > rights and a partridge in a pear tree? > > It makes sense to extend GPX for properties of locations, but it > does not make sense to extend GPX for other properties of things that have locations. > > What about street address? If I am standing at 123 Main Street, > Smalltown when I make my waypoint, should I be allowed to extend GPX > to accommodate address information? Isn't that location information? > Now we get into the more subtle issues of whether GPX is about > locations or whether GPX is about GPS waypoints, tracks, and routes. > Just to illustrate the difference, I create a waypoint at a > particular time when I press the button on my GPS so time is an > inherent property of a waypoint, but time is not a property of a > location in general (as locations persist throughout time). Garmin > have apparently extended their schema for temperature. Certainly at > the moment I create a waypoint, there is an ambient temperature for > that time and place and the GPS unit might be able to record that. > So temperature is a property of a waypoint, but not a property of a > location (clearly temperature can vary at a given location over > time). So temperature might arguably be an extension of GPX if GPX > is about GPS waypoints etc and not about locations. But then what > about street addresses and cadastral mapping more generally? Global > positioning gives us spatial coordinates, which can be translated > into street addresses etc by the use of maps (and some GPS units can > do this), but is GPX concerned with location in the broader sense or raw GPS readings? > > But now we go back to the earlier discussion of geocaching and > phone numbers. I talked about creating a schema for geocaching in > which a location might be represented as GPX. Do we really think the > time or the temperature at the point I pressed the button to make a > waypoint for the location of the cache is relevant to geocaching? > No, not really. So unless the role of GPX is to represent location > information as opposed to waypoints, then maybe it should not be > used as a component of a geocache at all. > > If you are involved in modelling information professionally (and I > am), you soon learn that the more you try to model something (i.e. > build some kind of schema to represent it), the more subtle > distinctions like the difference between a location and a waypoint > start to matter and you have to understand the relationship between > these things. So in terms of this discussion ... > > Many things (e.g. houses, geocaches) have locations and other > properties. Locations can be spatial coordinates (e.g. latitude, > longitude) and/or cadastral information (e.g. street address, land > title data). Spatial coordinates are part of a GPS reading, which > may contain other information (e.g. time, temperature). Which thing > do we want GPX to represent? Figure that out first!
jeremy+groundspeak.com on Wed Jan 17 17:21:08 2007 (link), replying to msg
I disagree with the idea that GPX isn't really about exchanging GPS data. What it comes down to is that it is meant to exchange GPS data but since it so widely adopted it would be far easier to switch the intent of the schema to some personal (non GPS) project or interest. It should allow the exchange of GPS data and do that best. Leave the extra stuff to the other applications that want it. GML is a way to exchange spatial data. Yeah, it's complicated so not widely used, much like GPX would be if there was a change of thinking around GPX. So please keep it simple. This is, of course, a biased opinion. It makes perfect sense to me to have an extension that I handle for Geocaching.com so I can add the necessary changes based on the feature requests from the geocaching community. For that reason I doubt I'd shift to some formal geocache tag created by a committee outside of Groundspeak. There's also GeoRSS, but it's pretty feature poor. There isn't even a place for altitude! Jeremy From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Dan Foster Sent: Wednesday, January 17, 2007 4:49 PM To: gpsxml+yahoogroups.com Subject: Re[2]: [gpsxml] Re: POI/Waypoint Phone Number Attribute Hello, I'm going to top-post and quote most of Kerry's message below. I'm surprised this message got so little response - it raises some issues that we really should address regarding the way objects are extended or contained within other objects in GPX. I'm going to suggest that GPX isn't really about exchanging GPS data. It may have started out that way, but it's really become a way to exchange spatial data - points and lines on the Earth. You may have a Web site full of geocaches with hints and descriptions, and I may have a database of oil well locations, but we both use GPX as the basis for our data structures, we can view our data in a program that doesn't know anything about caching or oil, or send it to a GPS receiver, and still get reasonable results (labeled points on a map in the right location). If instead the data structures were arranged to include snippets of GPX for the location- or GPS-specific aspects only, there would be no data interchange possible. Since my program knows nothing of your <geocache> structure, how can it possibly know there's a <gpx> element in there it actually would understand? <geocache schema="geocaching.com/blah..."> <hint>blah...</hint> <location schema="topografix.com/gpx/1/1" lat="42.123"...> </geocache> If we were starting from scratch, I would suggest that the base schema contain nothing more than the definition of a geographic point (lat/lon required, elevation and timestamp optional) and line, and that everything else be built (through extension schemas) on top of that. - Dan Monday, December 4, 2006, 3:06:02 PM, Kerry wrote: [Non-text portions of this message have been removed]
simonstl+simonstl.com on Wed Jan 17 17:40:29 2007 (link), replying to msg
Ryan Germann wrote: > I'm going to throw this out there: > > application/gps.gpx > > That leaves the door open to setting MIME types for vendor-specific > (proprietary? patented?) GPS data as > > application/gps.garmin > > etc. > > You might also decide it's best to differentiate GPS data > 'compartments' with another level of granularity: > > application/gps.waypoint.gpx > application/gps.waypoint.garmin > > leaving room for future innovation without disrupting the naming > convention. You may not like +xml, but this dotted multi-level naming convention is going to create great pain for you with the MIME community, which isn't fond of anything multi-level. +xml was a big stretch for them, and I can't imagine them accepting gps.XXXX.YYYY. Good luck, Simon St.Laurent http://simonstl.com/
Allen+BSATroop45.Org on Wed Jan 17 18:38:05 2007 (link)
Howdy, First: Yes, I'm a newbie. I'm an old, gray-headed, 50+ years old newbie who learned to program using punch cards and Fortran, then Pascal on some of the first personal PCs that existed. Now, with only a limited working knowledge of current programming in my pocket, I'd like to generate some GPX files of local POIs I can load into my Magellan as waypoints. Second: I've read all the online docs I could find, and I even understood some of them. But, I didn't find the real answer I was looking for. I downloaded GPSBabel. An amazing software package. I've played with it enough to figure out how to generate a small GPX file from comma delimited text files I made of the local POIs. To generate a GPX file the way I'd like, I need what I haven't been able to find. I know it's probably online, but I've searched and can't find it. If someone can point me in the right direction, I'd appreciate it. The question: When GPSBabel receives a GPX file containing Geocaching.Com waypoints, what fields is it expecting to receive, and in what order is it expecting to receive them? I realize this is far more basic a question than most of what goes on in this forum, but not finding the answer anywhere else, I'm turning here for help. Everybody has to start somewhere... My thanks in advance. AllenMcB
ptomblin+gmail.com on Wed Jan 17 18:50:28 2007 (link), replying to msg
On 1/11/07, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > > 3. Propose a GPX 2.0 that allows multiple language support. > > Yes, I guess so. Okay, so suppose I was inventing GPX 2, and suppose > I wanted to pick a way of doing multilanguage which was close to GPX > 1.1 but also one which struck everyone as elegant, pleasing, and > obviously the best way to do it. Does anyone have any favourites, of > the ways I described or any other ways, to express multilanguage > names and descriptions ? I just found this interesting article about internationalization in xml: http://www-128.ibm.com/developerworks/library/x-i18n1.html I would propose that you use the existing tags with the default tag, and then extension tags with a "collection" containing multple versions of an equivalent tag with xml:lang="AA" in each one. So if your tag is called, say, "<description>", I would follow that with <extension> <descriptionCollection> <descr xml:lang="en">English Description</desc> <descr xml:lang="fr">Description Francais</desc> </descriptionCollection> </extension> -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
dananderson2+yahoo.com on Wed Jan 17 19:00:16 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "allenmcb" <Allen+...> wrote: [snip] > The question: > > When GPSBabel receives a GPX file containing Geocaching.Com waypoints, > what fields is it expecting to receive, and in what order is it > expecting to receive them? > > I realize this is far more basic a question than most of what goes on > in this forum, but not finding the answer anywhere else, I'm turning > here for help. Everybody has to start somewhere... When you read the schemas note statements such as: minOccurs="0", (meaning the element/object doesn't need to appear), use="required", <!-- elements must appear in this order -->. http://www.topografix.com/GPX/1/0/gpx.xsd http://www.groundspeak.com/cache/1/0/cache.xsd An example geocaching waypoint (not real): <wpt lat="38.123456" lon="-104.1234"> <time>2006-08-05T00:00:00.0000000-07:00</time> <name>GCxxxx</name> <desc>Another Cache, Unknown Cache (2/2)</desc> <url>http://www.geocaching.com/seek/cache_details.aspx</url> <urlname>Another Cache</urlname> <sym>Geocache</sym> <type>Geocache|Unknown Cache</type> <groundspeak:cache id="123456" available="True" archived="False" xmlns:groundspeak="http://www.groundspeak.com/cache/1/0"> <groundspeak:name>Another Cache</groundspeak:name> <groundspeak:placed_by>some cacher</groundspeak:placed_by> <groundspeak:owner id="55555">Colorado Cacher</groundspeak:owner> <groundspeak:type>Unknown Cache</groundspeak:type> <groundspeak:container>Regular</groundspeak:container> <groundspeak:difficulty>2</groundspeak:difficulty> <groundspeak:terrain>2</groundspeak:terrain> <groundspeak:country>United States</groundspeak:country> <groundspeak:state>Colorado</groundspeak:state> <groundspeak:short_description html="False">Another interesting place</groundspeak:short_description> <groundspeak:long_description html="False">A person can easily park...</groundspeak:long_description> <groundspeak:encoded_hints>Look around a little</groundspeak:encoded_hints> <groundspeak:travelbugs /> </groundspeak:cache> </wpt>
lorax1284+yahoo.com on Wed Jan 17 19:06:20 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Simon St.Laurent" <simonstl+...> wrote: > > You may not like +xml, but this dotted multi-level naming convention > is going to create great pain for you with the MIME community, which > isn't fond of anything multi-level. +xml was a big stretch for them, > and I can't imagine them accepting gps.XXXX.YYYY. The RFC recommending . delimited subtypes, RFC4288, is in status of "Best current practice", dated December 2005. The document recommending +xml, RFC3023, is still in the state of Proposed Recommendation, dated 2001.
distobj+acm.org on Wed Jan 17 19:22:05 2007 (link), replying to msg
On 1/17/07, Ryan Germann <lorax1284+yahoo.com> wrote: > From page four: > > "Registrations in the vendor tree will be distinguished by the leading > facet "vnd.". That may be followed, at the discretion of the > registrant, by either a media subtype name from a well-known producer > (e.g., "vnd.mudpie") or by an IANA-approved designation of the > producer's name that is followed by a media type or product > designation (e.g., vnd.bigcompany.funnypictures)." "." is reserved for such hierarchies, and no new trees will be minted. If Garmin wanted its own media type it might use, for example, application.vnd.garmin.gpx+xml > > and on page 7 > > "In accordance with the rules specified in [RFC3023], media subtypes > that do not represent XML entities MUST NOT be given a name that ends > with the "+xml" suffix. More generally, "+suffix" constructs should > be used with care, given the possibility of conflicts with future > suffix definitions." > > An XML entity is NOT just any old XML file, Sure it is. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
simonstl+simonstl.com on Wed Jan 17 19:27:29 2007 (link), replying to msg
Ryan Germann wrote: > From page four: > > "Registrations in the vendor tree will be distinguished by the leading > facet "vnd.". That may be followed, at the discretion of the > registrant, by either a media subtype name from a well-known producer > (e.g., "vnd.mudpie") or by an IANA-approved designation of the > producer's name that is followed by a media type or product > designation (e.g., vnd.bigcompany.funnypictures)." That only applies to vnd.* types. > and on page 7 > > "In accordance with the rules specified in [RFC3023], media subtypes > that do not represent XML entities MUST NOT be given a name that ends > with the "+xml" suffix. More generally, "+suffix" constructs should > be used with care, given the possibility of conflicts with future > suffix definitions." > > An XML entity is NOT just any old XML file, so the use of +xml should > ONLY be used for entities that are referenced in OTHER XML files. Sorry, but "any old XML file" is indeed an XML entity. It would be strange to have gone to all that effort to define +xml only for external entities. Simon St.Laurent
dananderson2+yahoo.com on Wed Jan 17 19:42:46 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Jeremy Irish" <jeremy+...> wrote: > > I disagree with the idea that GPX isn't really about exchanging GPS data. What it comes down to is that it is meant to exchange GPS data but since it so widely adopted it would be far easier to switch the intent of the schema to some personal (non GPS) project or interest. It should allow the exchange of GPS data and do that best. Leave the extra stuff to the other applications that want it. > > GML is a way to exchange spatial data. Yeah, it's complicated so not widely used, much like GPX would be if there was a change of thinking around GPX. So please keep it simple. > > This is, of course, a biased opinion. It makes perfect sense to me to have an extension that I handle for Geocaching.com so I can add the necessary changes based on the feature requests from the geocaching community. For that reason I doubt I'd shift to some formal geocache tag created by a committee outside of Groundspeak. [snip] Bottom line is that I agree with Jeremy. In principle I agree with Kerry in design. Kerry asked if GPX is about exchanging location data. I'll take my point of view from the following document: http://www.topografix.com/gpx.asp It starts with: "What is GPX? GPX (the GPS Exchange Format) is a light-weight XML data format for the interchange of GPS data (waypoints, routes, and tracks) between applications and Web services on the Internet." I don't see GPX as exchanging "location" data. I see it as exchanging data for GPS receivers. I see GPX_Overlay as exchanging additional map related data not intended for GPS receivers. The GPX schema could have been done differently but it is what we have right now. Because there are many applications that support it, I wouldn't encourage a major change at this time. Someday we may have more receivers that have a public format for maps and POI's. If Garmin doesn't "put their foot down", we are almost there with one brand. I could see a schema in the future that not only supports waypoints, routes, and tracks but also supports polylines, areas, and POI's, etc. - objects intended for the mapping area of the receiver. So we would be able to exchange complete map and POI data for the receivers. I'd like to see us address the immediate problems that people are having. Small additions to the GPX schema and/or the GPX_Overlay schema (or some new extension schema) could help many people. Dan A.
lorax1284+yahoo.com on Wed Jan 17 19:59:09 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Simon St.Laurent" <simonstl+...> wrote: > > That only applies to vnd.* types. ...and illustrates no rejection of dot delimited non-flat subtypes. > Sorry, but "any old XML file" is indeed an XML entity. Technically, yes, but in practical usage, no. If you've put a file on a server that is designed to be included as an entity, as a "module" that isn't really designed to stand alone as a separate file, then the use of +xml mime subtype would be additional useful information for the user agent receiving the file. I was just suggesting that GPX files are not specifically used in that way. ...and the quote I included suggested that +xml type usage should be limited, carefully considered, etc. Take it for what it's worth.
simonstl+simonstl.com on Wed Jan 17 20:36:19 2007 (link), replying to msg
Ryan Germann wrote: >> That only applies to vnd.* types. > > ...and illustrates no rejection of dot delimited non-flat subtypes. Good luck making that case with the people who manage MIME types. "No rejection" doesn't constitute endorsement in that world. >> Sorry, but "any old XML file" is indeed an XML entity. > > Technically, yes, but in practical usage, no. In the technical usage of RFC 3023, it's very certainly a "yes". It's certainly a "yes" in the XML spec itself - for example, see: http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-doc-entity "4.8 Document Entity [Definition: The document entity serves as the root of the entity tree and a starting-point for an XML processor.] This specification does not specify how the document entity is to be located by an XML processor; unlike other entities, the document entity has no name and might well appear on a processor input stream without any identification at all." > If you've put a file on > a server that is designed to be included as an entity, as a "module" > that isn't really designed to stand alone as a separate file, then the > use of +xml mime subtype would be additional useful information for > the user agent receiving the file. The +xml MIME subtype would be additional useful information for the user agent receiving the file whether or not the file is intended for inclusion as a "module". The point of: "In accordance with the rules specified in [RFC3023], media subtypes that do not represent XML entities MUST NOT be given a name that ends with the "+xml" suffix. " is that labeling data as XML when it isn't really XML is a bad idea. > I was just suggesting that GPX > files are not specifically used in that way. It's irrelevant, as RFC 3023 doesn't limit its use of XML entities in that way. > ...and the quote I included suggested that +xml type usage should be > limited, carefully considered, etc. Take it for what it's worth. The quote is: "More generally, "+suffix" constructs should be used with care, given the possibility of conflicts with future suffix definitions." Which was put there because the IETF didn't want to see a million +suffix types blossom across the landscape. If you'd like to see the full history, I'd recommend reviewing the ietf-xml-mime mailing list archive: http://www.imc.org/ietf-xml-mime/mail-archive/ You might also visit the list of MIME types at: http://www.iana.org/assignments/media-types/application/ You'll see a lot of +xml there, even in the vnd.* space. The latest draft of the XML Media Types spec (on which I am no longer active) is at: http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-02.txt Enjoy, Simon St.Laurent Happily Retired Editor, RFC 3023
egroups+topografix.com on Wed Jan 17 20:47:47 2007 (link), replying to msg
Hello, Wednesday, January 17, 2007, 8:20:50 PM, Jeremy wrote: > I disagree with the idea that GPX isn't really about exchanging GPS > data. What it comes down to is that it is meant to exchange GPS data > but since it so widely adopted it would be far easier to switch the > intent of the schema to some personal (non GPS) project or interest. > It should allow the exchange of GPS data and do that best. Leave the > extra stuff to the other applications that want it. > > GML is a way to exchange spatial data. Yeah, it's complicated so > not widely used, much like GPX would be if there was a change of > thinking around GPX. So please keep it simple. Just to be clear, I distinguish between "the base GPX 1.1 or 1.0 schema" and "GPX". I wasn't suggesting that the base GPX schema be made more complicated by adding phone numbers, image sizes, and the like - in fact, I'd like to see it reduced to about 30% of it's current file size. I was talking about expressing other types of data (geocaches, images, oil wells) inside GPX files, through the inclusion of additional schemas. It would be helpful in the future if statements like "that doesn't belong in GPX" were instead phrased as "that doesn't belong in the base GPX schema" or "that doesn't belong in a GPX file, ever". Sorry for making my position unclear - maybe some of you could clarify your positions as well. -- Dan Foster
ajcartmell+fonant.com on Thu Jan 18 01:15:45 2007 (link), replying to msg
> I recommend against +xml suffix, no matter whether or not the > MIME-subtype is flat or 'whatever' delimited multi-level. FWIW, from Google's interpretation of the MIME rules: Google Earth reads KML and KMZ files. The MIME type for KML files is application/vnd.google-earth.kml+xml The MIME type for KMZ files is application/vnd.google-earth.kmz To me, a KML file looks remarkably like a GPX file in that they're both standalone XML data files with well-defined formats. Cheers! Anthony -- www.fonant.com - Quality web sites
robertlipe+usa.net on Thu Jan 18 06:27:23 2007 (link), replying to msg
Dan Anderson handled most of the answer (and the details of the bowels of GPSBabel don't belong here anyway) but since there's some learning potential here for others interested in GPX, let me add a little. > When GPSBabel receives a GPX file containing Geocaching.Com waypoints, > what fields is it expecting to receive, and in what order is it > expecting to receive them? Look at a pocket query from geocaching.com to see what a GPX file from them looks like. If you really want to know how GPSBabel handles it, remember that GPSBabel is one of the relatively few open source projects around that handles this kind of thing. The source is there for you to inspect and aid in your learning. Even if you don't program C, a punched-card Fortran dude like yourself should pretty quickly recognize internal data tables, functions that write the Groundspeak extensions and such inside gpx.c. RJL
egroups+topografix.com on Thu Jan 18 09:12:38 2007 (link), replying to msg
Hello, Thursday, January 18, 2007, 6:48:56 AM, Simon wrote: > Unfortunately, the specification of GPX 1.1 precludes the proper use > of language because of the way certain elements are defined. For > example: > > <xsd:element name="desc" type="xsd:string" minOccurs="0"/> > > The default for 'maxOccurs' is 1. So one could supply one > description in any language, but not two descriptions in two > different languages. So we will certainly have to wait for the next > version of GPX to use multiple languages for the same element. I agree that we should fix this at the source in a future version of GPX, perhaps by replacing all instances of type="xsd:string" with some new type="gpx:stringCollection" or similar. <wpt> <xsd:element name="cmt" type="gpx:stringCollection"... <xsd:element name="desc" type="gpx:stringCollection"... ... or would it be better to keep type="xsd:string" but let maxOccurs be infinite? Should the schema prevent two descriptions in the same language? Should it allow text that doesn't have a language identifier? -- Dan Foster
ptomblin+gmail.com on Thu Jan 18 10:20:15 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > On 18 Jan 2007, at 2:49am, Paul Tomblin wrote: > [slightly tidied-up I hope you don't mind] > > > <extension> > > <descCollection> > > <desc xml:lang="en">English Description</desc> > > <desc xml:lang="fr">Description Francais</desc> > > </descCollection> > > </extension> > > It also gives us a consistent way to represent languages if they are > to be included in any future version of GPX or its extensions. > Unfortunately, the specification of GPX 1.1 precludes the proper use > of language because of the way certain elements are defined. For > example: > > <xsd:element name="desc" type="xsd:string" minOccurs="0"/> I was trying to propose that we keep the existing element, like "cmt", and then an extension with a collection of a new element representing the same thing in different languages, a "cmtCollection", say, holding "cmtWithLang" elements.
lorax1284+yahoo.com on Fri Jan 19 09:35:53 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Anthony Cartmell" <ajcartmell+...> wrote: > Google Earth reads KML and KMZ files. The MIME type for KML files is > application/vnd.google-earth.kml+xml > > The MIME type for KMZ files is > application/vnd.google-earth.kmz > > To me, a KML file looks remarkably like a GPX file in that they're > both standalone XML data files with well-defined formats. and I have found other examples of the +xml usage: Docbook 5.0rc1 recommends application/docbook+xml http://www.docbook.org/specs/docbook-5.0CR1-spec-wd-01.html#media-type-registration XHTML 1.1: application/xhtml+xml http://www.w3.org/TR/xhtml-media-types/ While reviewing the MIME RFC4288, I interpreted the term "entities" in the technical / dtd sense, rather than as a synonym of "instance", which doesn't seem to be used much any more. My interpretation was that the +xml suffix should only be used when serving content that was DESIGNED to serve as a component of a larger data object (like the navigation bar of a Webpage... not much use on it's own). That was an incorrect interpretation. Who will make the final determination that application/gpx+xml is "the" MIME type? I don't see much reason for delay then.
distobj+acm.org on Fri Jan 19 10:51:12 2007 (link), replying to msg
On 1/19/07, Ryan Germann <lorax1284+yahoo.com> wrote: > Who will make the final determination that application/gpx+xml is > "the" MIME type? I don't see much reason for delay then. We will. One of the things we'll need to point to in the registration is a specification. AFAICT though, there's isn't one, just a schema. Is that correct? Mark.
join_10000+yahoo.com on Fri Jan 19 18:58:13 2007 (link)
Anyone know? I'd like to make my GPX files more accessible to mobile users. Google offers webmasters a tool to make acceptance into Google's mobile web index easier, Mobile Web Sitemaps, which as I understand expedite the crawling process when changes have been made to mobile content. However URLs listed in the Mobile Web Sitemap must be a supported format - Mobile CHTML and Mobile WML/XHTML. It appears that GPX is not supported. Should we as a group collectively ask Google to support the GPX format or is there another way to help mobile web surfers find location information in GPX format. - Doug www.travelbygps.com
thomas.landspurg+gmail.com on Mon Jan 22 12:15:27 2007 (link), replying to msg
Hello Doug, You still can check j2memap ( http://j2memap.landspurg.net ). Not as polished as GoogleMap, but still useable on a limited sets of phone, and can be used to create new applications... If you have some GPX to test with it, I am open to do these tests.... Regards, On 1/22/07, Doug Adomatis <gps_maps+travelbygps.com> wrote: > > Anyone know? I'd like to make my GPX files more accessible to mobile > users. Google offers webmasters a tool to make acceptance into > Google's mobile web index easier, Mobile Web Sitemaps, which as I > understand expedite the crawling process when changes have been made > to mobile content. However URLs listed in the Mobile Web Sitemap must > be a supported format - Mobile CHTML and Mobile WML/XHTML. It appears > that GPX is not supported. > Should we as a group collectively ask Google to support the GPX format > or is there another way to help mobile web surfers find location > information in GPX format. > - Doug > www.travelbygps.com > > > -- Thomas Landspurg http://blog.landspurg.net [Non-text portions of this message have been removed]
davidinter2004+yahoo.com.ar on Fri Feb 09 06:02:49 2007 (link)
Two useful tools to transfer waypoints, routes and tracks between Google Earth and GPS. http://www.mcrenox.com.ar/gpx2kml http://www.mcrenox.com.ar/kml2gpx Enjoy!
curtis+flotown.com on Sun Feb 11 07:26:18 2007 (link), replying to msg
Thomas, There appear to be some permission issues with grabbing this from the link you posted. I am interested in checking it out. ct _____ From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Thomas Landspurg Sent: Monday, January 22, 2007 2:39 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] GPX supported in Google Mobile Web sitemaps? Hello Doug, You still can check j2memap ( http://j2memap. <http://j2memap.landspurg.net> landspurg.net ). Not as polished as GoogleMap, but still useable on a limited sets of phone, and can be used to create new applications... If you have some GPX to test with it, I am open to do these tests.... Regards, On 1/22/07, Doug Adomatis <gps_maps+travelbygp <mailto:gps_maps%40travelbygps.com> s.com> wrote: > > Anyone know? I'd like to make my GPX files more accessible to mobile > users. Google offers webmasters a tool to make acceptance into > Google's mobile web index easier, Mobile Web Sitemaps, which as I > understand expedite the crawling process when changes have been made > to mobile content. However URLs listed in the Mobile Web Sitemap must > be a supported format - Mobile CHTML and Mobile WML/XHTML. It appears > that GPX is not supported. > Should we as a group collectively ask Google to support the GPX format > or is there another way to help mobile web surfers find location > information in GPX format. > - Doug > www.travelbygps.com > > > -- Thomas Landspurg http://blog. <http://blog.landspurg.net> landspurg.net [Non-text portions of this message have been removed] [Non-text portions of this message have been removed]
thomas.landspurg+gmail.com on Sun Feb 11 07:32:24 2007 (link), replying to msg
Yes, you choose the wrong day. Apparently my ISP provider shut down my site today due to too many traffic on the MySql server! Hope to solve this shortly, but I will send you the file directly On 2/11/07, Curtis Turner <curtis+flotown.com> wrote: > > Thomas, > > There appear to be some permission issues with grabbing this from the link > you posted. I am interested in checking it out. > > ct > > _____ > > From: gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com> [mailto: > gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>] On Behalf Of > Thomas Landspurg > Sent: Monday, January 22, 2007 2:39 PM > To: gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com> > Subject: Re: [gpsxml] GPX supported in Google Mobile Web sitemaps? > > Hello Doug, > > You still can check j2memap ( http://j2memap. < > http://j2memap.landspurg.net> > landspurg.net ). Not as > polished as GoogleMap, but still useable on a limited sets of phone, and > can > be used to create new applications... > If you have some GPX to test with it, I am open to do these tests.... > > Regards, > > On 1/22/07, Doug Adomatis <gps_maps+travelbygp > <mailto:gps_maps%40travelbygps.com> s.com> wrote: > > > > Anyone know? I'd like to make my GPX files more accessible to mobile > > users. Google offers webmasters a tool to make acceptance into > > Google's mobile web index easier, Mobile Web Sitemaps, which as I > > understand expedite the crawling process when changes have been made > > to mobile content. However URLs listed in the Mobile Web Sitemap must > > be a supported format - Mobile CHTML and Mobile WML/XHTML. It appears > > that GPX is not supported. > > Should we as a group collectively ask Google to support the GPX format > > or is there another way to help mobile web surfers find location > > information in GPX format. > > - Doug > > www.travelbygps.com > > > > > > > > -- > Thomas Landspurg > http://blog. <http://blog.landspurg.net> landspurg.net > > [Non-text portions of this message have been removed] > > [Non-text portions of this message have been removed] > > > -- Thomas Landspurg http://blog.landspurg.net [Non-text portions of this message have been removed]
evilc+evilc.com on Tue Feb 13 04:47:35 2007 (link)
I am trying to write code to allow me to import GPX data into Google Maps. I want the user to be able to supply GPX data and then select which element from the GPX dataset to import. The code then converts the selected element in the GPX file to my internal format (lng lat,lng lat,...) and also prunes the GPX data of all the non-selected elements (ie if you selected a trk from the GPX data set, it filters out everything but that trk), whilst preserving metadata not supported by Google Maps (eg elevation and time data). This "Pruned" XML is then converted to a text string to be stored in the Import field for that location in the database. This is an additional field to the one used to store and retrieve point or line data for overlaying on the (2D) google map. By doing this, when viewing the point or line normally in my google maps app, it needen't worry with parsing the data out of the XML, but if someone wants a copy of the "source" data, or I want to do things with it such as calculate gradient of a line, the data is available in the Import field. If the selected element is a trk (which can be multi-segmented), the user is given the option of glueing all the segments together into one line or importing just one trkseg segment. I am having problems with the latter. When I try to removeChild the unwanted trksegs, the code stops, with no error. Demo dir: http://www.evilc.com/gpx/ <http://www.evilc.com/gpx/> gpxtest.html is the script gpxtext.txt is sample data To replicate: paste the sample data into the top textbox, click PARSE IMPORT XML, select the TRK from the first drop-down box, then SEG 1 from the second drop-down box and hit IMPORT THIS TAG. The checkbox labelled TRY TO DELETE UNSELECTED SEGMENTS will toggle whether it tries to delete these unwanted trksegs or not - just to prove the code works fine without trying to do it ;) In case you are confused, what I am trying to acheive, when it all works, is if you follow the replication steps and tick the TRY TO DELETE UNSELECTED SEGMENTS checkbox, the PRUNED IMPORT XML DATA box should only contain the trkseg selected in the second selectbox (ie SEG 1), not all of them. [Non-text portions of this message have been removed]
ptomblin+gmail.com on Thu Feb 15 07:33:04 2007 (link)
What application type do you use for serving up GPX files? I tried application/xml, but that causes Firefox to churn and churn as it tries to process a gigantic file with 30,000 waypoints. I don't want it to churn, I want it to save, so I tried application/octet-stream. That does the right thing for Firefox, but now I have people telling me that IE (long may its name be cursed) is renaming the files as they upload from foo.gpx to foo.xml. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
distobj+acm.org on Fri Feb 16 09:08:38 2007 (link), replying to msg
On 2/15/07, Paul Tomblin <ptomblin+gmail.com> wrote: > What application type do you use for serving up GPX files? I tried > application/xml, but that causes Firefox to churn and churn as it > tries to process a gigantic file with 30,000 waypoints. I don't want > it to churn, I want it to save, so I tried application/octet-stream. > That does the right thing for Firefox, but now I have people telling > me that IE (long may its name be cursed) is renaming the files as they > upload from foo.gpx to foo.xml. The only way they could get that behaviour is if they had associated ".xml" with "application/octet-stream", which would be pretty silly. IE does the right thing with file extension renaming. Anyhow, there's been talk around here of officially registering application/gpx+xml with IANA, but it seems we're lacking a spec for GPX, which the registration template requires. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
ptomblin+gmail.com on Fri Feb 16 09:42:26 2007 (link), replying to msg
On 2/16/07, Mark Baker <distobj+acm.org> wrote: > On 2/15/07, Paul Tomblin <ptomblin+gmail.com> wrote: > > it to churn, I want it to save, so I tried application/octet-stream. > > That does the right thing for Firefox, but now I have people telling > > me that IE (long may its name be cursed) is renaming the files as they > > upload from foo.gpx to foo.xml. > > The only way they could get that behaviour is if they had associated > ".xml" with "application/octet-stream", which would be pretty silly. > IE does the right thing with file extension renaming. Well, this guy tells me that he got a file named "38ec7b35.xml", but when I grep my logs, I see navaid.com 62.253.128.13 - - [15/Feb/2007:17:35:33 -0500] "GET /tmp/38ec7b35.gpx HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" So I was serving it up as .gpx, but something on his end renamed it. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
distobj+acm.org on Fri Feb 16 09:54:49 2007 (link), replying to msg
On 2/16/07, Paul Tomblin <ptomblin+gmail.com> wrote: > Well, this guy tells me that he got a file named "38ec7b35.xml", but > when I grep my logs, I see > navaid.com 62.253.128.13 - - [15/Feb/2007:17:35:33 -0500] "GET > /tmp/38ec7b35.gpx HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible; MSIE > 6.0; Windows NT 5.1; SV1)" > > So I was serving it up as .gpx, but something on his end renamed it. The file extension you served it as doesn't matter, the media type does. Assuming neither of you have wacky configurations, you must have served the GPX file as application/xml or text/xml for this to happen. This is expected behaviour since about 5 years ago when IE fixed a security problem by doing the renaming. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
jambri+yahoo.com on Wed Feb 21 18:22:50 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+...> wrote: > > Is this still the place for talking about GPX or is this now just a > place for me to get stock trading tips? > > In the Map Authors group, a few of us are working on Tour Guides in > Garmin GPI format. So far as I know, we can't assign a phone number > to a point of interst. Given that ther are many more appilications > using GPX than GPI format, i thought I would bring this up to members > of this group and suggest that when the GPX schema is revised it > incude phone number attribute for waypoints. > Do other agree? > - Doug > www.TravelByGPS.com > There is a unofficial GPX v3 extension out there that garmin already uses (in its map source program) that is also supported by garmins poi loader (both beta versions). go here for format http://www.garmin.com/xmlschemas/GpxExtensions/v3 it supports both phone numbers and addreses (not just a comment field). If you import a .gpx file with this format into one of the newer garmin gps systems (ie streetpiliot or nuvi) that can dial phone numbers you can import dialable phone numbers and FORMATTED addresses as well as the waypoint and name information. I have yet to see a third party waypoint program that supports entering in phone numbers and exporting them into this format. for a example of a working test version that can be uploaded to your gps I have a file located here: http://www.fileden.com/files/2007/2/20/798737/test.gpx
evilc+evilc.com on Thu Feb 22 07:08:55 2007 (link)
I have a page that takes inputted GPX data, manipulates it, and exports a modified version. I would like to be able to present the user with a link or open a new window to the exported data so that the user can save it to their hard disk. I am *not* talking about trying it "push" it to their HDD, more like right clicking a link and selecting "Save As..." or opening the data in a new window and then using File->Save As in the browser window. I have experimented with document.write, but this does not appear to work (it just strips the tags) Example code here: http://www.evilc.com/gpx/ The txt file contains test GPX data, the HTML file is the demo code. Paste the test data into the top box, hit PARSE, select a tag from the drop down box and click IMPORT I need to be able to present the data in the PRUNED IMPORT XML DATA textarea either as a download link or have a button that opens a new window containing the XML data so the user can use the browser's File->Save As option. Any ideas?
tomkralidis+hotmail.com on Thu Feb 22 13:17:31 2007 (link)
Hi, I came across the GPX specification after buying a GPS and starting to work with importing exporting waypoints, tracks, and routes. In looking at http://www.topografix.com/GPX/1/1/gpx.xsd, I see that all geometries use the wptType complexType. Has there been any consideration to using the OGC GML specification to leverage the definition of geometries? Here's an example of what a waypoint could look like leveraging GML: <wpt> <gml:description>This was where the first meeting was held</gml:description> <gml:name>St. Paul</gml:name> <gml:location> <gml:Point srsName="http://www.opengis.net/gml/srs/epsg.xml#4326"> <gml:coord> <gml:X>-93.093055556</gml:X> <gml:Y>44.944444444</gml:Y> </gml:coord> </gml:Point> </gml:location> <extensions> <foo:year>2003</foo:year> <foo:venue>University of Minnesota, St. Paul Campus</foo:venue> <foo:website>http://mapserver.gis.umn.edu/mum/index2003.html</foo:website> <extensions> </wpt> GML already defines some of the core objects and properties of geometry, which GPX would benefit from. Also, there are many software packages out there which can process GML, so the GPX specification would benefit from mature implementations and user tools, etc. Comments? I'm new to this group, so perhaps this has been investigated in the past (I couldn't find anything in the list archives). Keep up the good work! Cheers ..Tom
robertlipe+usa.net on Thu Feb 22 13:43:28 2007 (link), replying to msg
> geometry, which GPX would benefit from. Also, there are many software > packages out there which can process GML, so the GPX specification > would benefit from mature implementations and user tools, etc. GPX isn't GML. They serve different markets. GPX is hardly suffering for mature implementations. http://www.topografix.com/gpx_resources.asp > Comments? I'm new to this group, so perhaps this has been > investigated in the past (I couldn't find anything in the list archives). That's probably becuase the yahoogroup archives are terrible. :-) GML was definitely discussed in the early days. RJL
hadmut+danisch.de on Sun Feb 25 08:51:31 2007 (link)
Hi, just a question: In some regions (e.g. Germany) it is usual to give hiking trails graphical symbols to make it easier to follow them. Usually there are signs on the trail and on maps. But since a tour usually involves several trail segments, there is often more than one symbol used to describe a track/route. What would be the appropriate way to include such symbols in a GPX file? Put the images somewhere on a website and include hyperlinks for some waypoints? regards Hadmut
maschaffner+yahoo.com on Mon Feb 26 04:27:07 2007 (link)
The GPS 1.1 Documentation is unclear of the definition of the <ele> element. It says simply "Elevation (in meters) of the point.", but does not tell wether the elevation is above sea level (geoid) or above the WGS84 ellipsoid. As longitude and latitude use WGS84, I assumed that <ele> is also above WGS84 ellipsoid, but from web searches I get the impresssion that height above sea level is meant. Could the standard be amended to clarify this? Thanks, Martin
hadmut+danisch.de on Mon Feb 26 11:54:21 2007 (link), replying to msg
On Sun, Feb 25, 2007 at 06:04:44PM +0000, Simon Slavin wrote: > > You're talking about two different kinds of symbols here. There's > the symbols you want to use for specific trails, but there's also the > <symbol> element which GPX already uses. GPX symbols for icons > should be specified by standardised name so that all software can > handle your GPX files. Yeah, maybe my posting was ambigous, but that's not what I meant. The symbol element means the name of a standard symbol describing the waypoint, like car or building. > trail generally have no symbol at all (they're 'waypoints'). Are > there others you need for hiking trails ? Yes. Hiking trails often go through the wood in Germany. To make orientation easier, these trails have often an arbitrary logo assigned, which you can find attached to trees etc. There is no common rule how these logos look like, e.g. three bars in different colors, a circle on some background in different color, triangle, ... Most hiking maps include these logos, so you know what to look for when following a trail. But you rarely follow the same symbol from start to end of your tour. It's like using the underground: There are crossings where you change e.g. from the trail with the white-red-white bars to the one with the yellow circle on blue background. So, mathematically spoke, while the normal GPX symbols are assigned to vertices=waypoints and taken from a given list of default symbols, the trail symbols are assigned to edges=ways_between_waypoints, and you don't have a complete list of symbols to choose from. A graphics format is needed, like the icons on web sites. > The other part of this is that you want to use specialised icons for > your particular trails. The way you want to do it is to encode the > image into the GPX file. There's no fixed way to do this at the > moment. You could use a <link> to the image files as you mentioned, > but what you're /really/ trying to do is just put a note into the > point to say which trail the point is related to, so I think you just > need to put the trail's name into a comment or description field. Well, the trails usually don't have "names", and a waypoint can be at the crossing of two trails. > Garmin's units put points into 'categories'. It would make sense to > make one category (or subcategory) for each trail. The simplest way > of doing this is to make a separate .gpx file for each trail. This > will allow you to specify a .BMP icon for each .gpx file and Garmin > units will show that icon for each point in the GPX file. But this > is not a standard feature of GPX, it's something that Garmin's POI > Loader program does. GPX 1.2 ? regards Hadmut
robertlipe+usa.net on Mon Feb 26 13:20:59 2007 (link), replying to msg
> vertices=waypoints and taken from a given list of default symbols, the > trail symbols are assigned to edges=ways_between_waypoints, and you > don't have a complete list of symbols to choose from. A graphics > format is needed, like the icons on web sites. GPX is the "GPS" exchange format. By the percentages, very few units let you load custom icons. Even if you have two that DID let you do it, the required sizes, format, color depths, transparency representations, and so on would be hurdles in trying to standardize such things. If you're truly trying to publish something in a format that's usable across receivers and programs, populate the name and cmt fields in GPX with text descriptions. RJL
ishanul2000+yahoo.com on Tue Feb 27 23:15:19 2007 (link)
[ Moderator note: Not actually GPX related, but approved as it's not spam. ] hi all, i am a new member to this forum. i am expecting to develop GPS module for SAHANA (FOSS disaster management system). so, hope to get lots of feedbacks from you. thanks cheers ishan regards Ishan Liyanage www.ishan-liyanage.blogspot.com --------------------------------- Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. [Non-text portions of this message have been removed]
ishanul2000+yahoo.com on Tue Feb 27 23:16:31 2007 (link)
[ Moderator note: Not actually GPX related, but approved as it's not spam. ] Hi All, These days I'm doing a research about GPS(Global Positioning System) and loking forward to apply those stuffs in Sahana. We can use GPS to 1. record precise locations such as unsafe bridges, buildings etc. 2. find the exact location to give imediate help after a disaster(Intersections). 3. find the missing things any other area that i can use GPS for disaster management? so, I'm expecting your valuable ideas and suggestions to achive this. regards Ishan Liyanage www.ishan-liyanage.blogspot.com --------------------------------- TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. [Non-text portions of this message have been removed]
ishanul2000+yahoo.com on Thu Mar 01 04:59:17 2007 (link)
hi all, anyone knows directly passing GPS data such as waypoints to web server? please let me know. thanks ishan regards Ishan Liyanage www.ishan-liyanage.blogspot.com --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. [Non-text portions of this message have been removed]
salcedo+yahoo.com on Wed Mar 07 08:54:00 2007 (link), replying to msg
Hi Ishan, I'm sure members would like to help, but your question is vague. Are you trying to create a program that runs on your PC that automatically collects and transmits the data to a web service/site? Is there an existing site or web service that you are trying to access, or do you want to create your own? Is GPX the data format that the service/site accepts? Do you need to convert data to or from GPX and another format? I think if you clarify some of these topics, you will get more responses. -Ricardo --- In gpsxml+yahoogroups.com, Ishan Liyanage <ishanul2000+...> wrote: > > hi all, > > anyone knows directly passing GPS data such as waypoints to web server? > > please let me know. > > thanks > > ishan > > > regards > > Ishan Liyanage > www.ishan-liyanage.blogspot.com > > --------------------------------- > Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. > > [Non-text portions of this message have been removed] >
ptomblin+gmail.com on Sun Mar 11 11:54:21 2007 (link)
Somebody contacted me today saying that they were unable to load a large GPX file generated from my web site (http://navaid.com/GPX/) of all the public airports in the US and Canada. He has another file that he generated a different way that is similar, and that one loads but mine doesn't. He's also able to load small subsets of mine if he generates them a state at a time, for example. Mine has more information that the other file doesn't, which is why he'd rather use my generator file, so we're trying to figure out why mine doesn't load. The first thing I notice is that I have a small rounding error in generator (since fixed) so while the schema says that the magnetic declination is >= 0.0 and < 360.0, one of the points in the big file has a magvar of 360.0. Could that be throwing off the Garmin loader? The other thing is that the file coming from my generator has waypoint.gpx: 854 ms (39963 elems, 11426 attrs, 45710 spaces, 309289 chars) whereas the one he generated himself has Airportspub.gpx: 713 ms (22073 elems, 11041 attrs, 115879 spaces, 216563 chars) Is there a limit on the number of elements that the Garmin loader will handle? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
azbithead+gmail.com on Wed Mar 14 13:43:13 2007 (link), replying to msg
POI Loader does not have a limit on the size of GPX files that it processes other than the limits imposed by available OS resources, most notably memory. POI Loader will reject any GPX file that is not valid according to the GPX 1.0 or 1.1 schema even if the offending element in the file is not actually used by POI Loader. Accordingly, a GPX file containing a magvar element with a value of 360.0 would be invalid according to the schema and therefore POI Loader would reject it. I would suggest trying to validate the questionable file using a validating parser. Such a parser will likely report exactly where any invalid elements occur in the file. If the file does validate in such a parser then POI Loader must have a defect which should be reported to Garmin. - Steve
ishanul2000+yahoo.com on Wed Mar 14 18:57:22 2007 (link)
hi all, if you guys have any idea about how GPS can apply in disaster management, please reply me. I am doing research work on "how GPS can apply to SAHANA". SAHANA is FOSS disaster management system (www.sahana.lk, www.sourceforge.net/projects/sahana) and you also can contribute to develop it. looking forward you responses. thanks and regards regards Ishan Liyanage www.ishan-liyanage.blogspot.com --------------------------------- Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. [Non-text portions of this message have been removed]
ishanul2000+yahoo.com on Wed Mar 14 18:58:15 2007 (link), replying to msg
hi ricardo, thanks for your reply. im trying to apply GPS stuffs in SAHANA (FOSS disaster management system.) www.sahana.lk im expecting your valuable support in future. thanks in advance Ricardo <salcedo+yahoo.com> wrote: Hi Ishan, I'm sure members would like to help, but your question is vague. Are you trying to create a program that runs on your PC that automatically collects and transmits the data to a web service/site? Is there an existing site or web service that you are trying to access, or do you want to create your own? Is GPX the data format that the service/site accepts? Do you need to convert data to or from GPX and another format? I think if you clarify some of these topics, you will get more responses. -Ricardo --- In gpsxml+yahoogroups.com, Ishan Liyanage <ishanul2000+...> wrote: > > hi all, > > anyone knows directly passing GPS data such as waypoints to web server? > > please let me know. > > thanks > > ishan > > > regards > > Ishan Liyanage > www.ishan-liyanage.blogspot.com > > --------------------------------- > Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. > > [Non-text portions of this message have been removed] > regards Ishan Liyanage www.ishan-liyanage.blogspot.com --------------------------------- Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. [Non-text portions of this message have been removed]
mregehr_public+yahoo.com on Fri Mar 16 10:13:45 2007 (link)
Hello, I'm trying to create a program that will generate GPX files containing tracks (one track per file). Is there a simple example I can use as a model? I looked around on the web and found several examples but they don't appear to pass GPX validation. For example, the file I downloaded from here: http://www.toposhare.org/sharedroutes?permalink=2176 generates a long list of errors (excerpted below). Am I using the validation tool incorrectly? I called it using SAXCount -v=always -n -s -f c:\C1.gpx (after renaming the downloaded file to C1.gpx). I'll be grateful for any help. Martin Excerpt from list of errors follows: ______________________________ Error at file c:\C1.gpx, line 5, char 56 Message: Unknown element 'gpx' Error at file c:\C1.gpx, line 5, char 56 Message: Attribute 'version' is not declared for element 'gpx' Error at file c:\C1.gpx, line 5, char 56 Message: Attribute 'encoding' is not declared for element 'gpx' Error at file c:\C1.gpx, line 5, char 56 Message: Attribute 'creator' is not declared for element 'gpx' Error at file c:\C1.gpx, line 5, char 56 Message: Attribute '{http://www.w3.org/2000/xmlns/}xsi' is not declared for element 'gpx' Error at file c:\C1.gpx, line 5, char 63 Message: Unknown element 'trk' Error at file c:\C1.gpx, line 6, char 11 Message: Unknown element 'name' Error at file c:\C1.gpx, line 7, char 10 Message: Unknown element 'cmt' Error at file c:\C1.gpx, line 8, char 11 Message: Unknown element 'desc' Error at file c:\C1.gpx, line 9, char 11 Message: Unknown element 'link' Error at file c:\C1.gpx, line 10, char 13 Message: Unknown element 'number' Error at file c:\C1.gpx, line 11, char 11 Message: Unknown element 'type' Error at file c:\C1.gpx, line 12, char 13 Message: Unknown element 'trkseg' Error at file c:\C1.gpx, line 13, char 48 Message: Unknown element 'trkpt'
egroups+topografix.com on Fri Mar 16 11:03:26 2007 (link), replying to msg
Hello, Friday, March 16, 2007, 12:52:30 PM, mregehr_public wrote: > http://www.toposhare.org/sharedroutes?permalink=2176 > generates a long list of errors (excerpted below). Am I using the > validation tool incorrectly? I called it using > SAXCount -v=always -n -s -f c:\C1.gpx > Error at file c:\C1.gpx, line 5, char 56 > Message: Unknown element 'gpx' You are using the validation tool correctly, and it is correctly reporting that the file in question is not a valid GPX file. Toposhare is not including a link to the GPX schema in the xmlns line. <gpx version="1.0" encoding="ISO-8859-1" creator="http://www.toposhare.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> EasyGPS, GPSBabel, and Mapsource are all programs you can use to create valid GPX documents for your reference. Checking with the validator before and after you make your changes is always a smart move. -- Dan Foster
mregehr_public+yahoo.com on Fri Mar 16 15:29:28 2007 (link), replying to msg
Hi Dan, Thanks for the reply. I don't think I can use any of the three programs you listed, because I don't own a GPS unit capable of uploading or downloading data. The reason I enquired is that I manage TopoRoute and some of my users have requested GPX output. Do you know of any simple example files I could use as a model? Or can I use the file I mentioned, and correct just the flaws you identified? Martin --- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > Hello, > > Friday, March 16, 2007, 12:52:30 PM, mregehr_public wrote: > > > http://www.toposhare.org/sharedroutes?permalink=2176 > > generates a long list of errors (excerpted below). Am I using the > > validation tool incorrectly? I called it using > > SAXCount -v=always -n -s -f c:\C1.gpx > > > Error at file c:\C1.gpx, line 5, char 56 > > Message: Unknown element 'gpx' > > You are using the validation tool correctly, and it is correctly > reporting that the file in question is not a valid GPX file. > Toposhare is not including a link to the GPX schema in the xmlns line. > > <gpx > version="1.0" > encoding="ISO-8859-1" > creator="http://www.toposhare.org" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > > EasyGPS, GPSBabel, and Mapsource are all programs you can use to > create valid GPX documents for your reference. Checking with the > validator before and after you make your changes is always a smart > move. > > -- > Dan Foster >
robertlipe+usa.net on Fri Mar 16 15:35:23 2007 (link), replying to msg
mregehr_public wrote: > Thanks for the reply. I don't think I can use any of the three > programs you listed, because I don't own a GPS unit capable of > uploading or downloading data. The reason I enquired is that I manage Fortunately for you, none of the three programs he cited require a GPS. > TopoRoute and some of my users have requested GPX output. Do you know > of any simple example files I could use as a model? Or can I use the > file I mentioned, and correct just the flaws you identified? There are sample files in the file area of this yahoogroup, numerous ones on the web, and any of the aforementioned tools (in addition to most of the scores listed in the GPX developer site) can create and read GPX files. RJL
notdefix+yahoo.com on Tue Mar 20 12:11:50 2007 (link)
Hello GPX Developers Forum, I'm completelly new to GPS-logs and I'm on a complete loss as to the difference between Waypoints, Routes and Tracks. My question is: What is their definition and what are they used for. I think (but please correct me if I'm wrong) Waypoint are 'POINT' data. Entered into a GPS-device before setting of? and uppon reaching your waypoint, you go to the next one etc. Routes are lists of coordinates. Mostly recorded by the GPS-device as you move ? And If the both assumptions above are correct, That what are Tracks? and in what way are they used? Thanks in advance
robertlipe+usa.net on Tue Mar 20 12:31:09 2007 (link), replying to msg
> I think (but please correct me if I'm wrong) > Waypoint are 'POINT' data. > Entered into a GPS-device before setting of? and uppon reaching your > waypoint, you go to the next one etc. A waypoint is a single position. Depending on the gear in question, it can be entered before you leave via a computer or on the GPS itself. It can be entered while you're in the field on some units. An example of a waypoint is your favorite fishing hole. It has a location. It probably has at least one name. > Routes are lists of coordinates. > Mostly recorded by the GPS-device as you move ? This sounds more like tracks. Tracks are sequenced lists of positions. Traditionally (though not always) they are recorded by a GPS that timestamps those positions. Normally, they indicate where you've been. Think "trail of breadcrumbs". An example would be a recording of a bike ride, hike, or parasailing adventure. Routes are also sequenced lists of positions. Normally, routes are used to express some place you want to go. Starting at my house (end 1) to get to grandmother's house (end 2) you turn at position just over the river and you turn again at the position near the woods. The lines between tracks and routes can get a little fuzzy as they express similar data. Typically tracks have more points, most of the points are unnamed, and are timestamped. There's a lot of "traditionally", "typically", and "normally" here as there are a LOT of ways to express location, but don't let the wiggle room I've built myself distract you from the punchline. About the simplest rule of thumb is: A waypoint is a place. A track is where you've been. A route is a set of directions to use. RJL
notdefix+yahoo.com on Tue Mar 20 12:53:56 2007 (link), replying to msg
Thanks a lot for the answer! I'm currently building a (simpel) interface to post GPS-logs to a website in order to display them on a map system. (for a travelog website: webtravellog.com) So clearly I need to allow for 'tracks' to be uploaded. However, the "traditionally", "typically" and "normally" suggests that it is maybe better to let the user choose from the 3 options. Is there any reason that any of the formats could NOT be the results of recorded log by a GPS? Thank again, Jacco --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > > I think (but please correct me if I'm wrong) > > Waypoint are 'POINT' data. > > Entered into a GPS-device before setting of? and uppon reaching your > > waypoint, you go to the next one etc. > > A waypoint is a single position. Depending on the gear in question, it > can be entered before you leave via a computer or on the GPS itself. It > can be entered while you're in the field on some units. > > An example of a waypoint is your favorite fishing hole. It has a > location. It probably has at least one name. > > > Routes are lists of coordinates. > > Mostly recorded by the GPS-device as you move ? > > This sounds more like tracks. > > Tracks are sequenced lists of positions. Traditionally (though not > always) they are recorded by a GPS that timestamps those positions. > Normally, they indicate where you've been. Think "trail of breadcrumbs". > > An example would be a recording of a bike ride, hike, or parasailing > adventure. > > Routes are also sequenced lists of positions. Normally, routes are used > to express some place you want to go. Starting at my house (end 1) to > get to grandmother's house (end 2) you turn at position just over the > river and you turn again at the position near the woods. > > > The lines between tracks and routes can get a little fuzzy as they > express similar data. Typically tracks have more points, most of the > points are unnamed, and are timestamped. > > > There's a lot of "traditionally", "typically", and "normally" here as > there are a LOT of ways to express location, but don't let the wiggle > room I've built myself distract you from the punchline. About the > simplest rule of thumb is: > > A waypoint is a place. > A track is where you've been. > A route is a set of directions to use. > > > RJL >
robertlipe+usa.net on Tue Mar 20 12:57:47 2007 (link)
> I'm currently building a (simpel) interface to post GPS-logs to a > website in order to display them on a map system. (for a travelog > website: webtravellog.com) > > So clearly I need to allow for 'tracks' to be uploaded. > However, the "traditionally", "typically" and "normally" suggests > that it is maybe better to let the user choose from the 3 options. If the user has a GPX file, the file already contains the needed info in the wpt, trk, or rte sections. There's no need for you to guess what the user meant and no reason for you to have to ask, is there? > Is there any reason that any of the formats could NOT be the results > of recorded log by a GPS? Sure, there are lots of reasons you could have a file with geolocational data in it that didn't come from a GPS. Modern mapping programs, web interfaces, coordinates looked up from a paper map, etc.
skhapre+yahoo.com on Fri Mar 23 09:53:31 2007 (link)
Hi All i am interested in knowing if it is possible to define image format other in bmp in GPX.
gepp1+yahoo.com on Fri Mar 23 09:56:01 2007 (link)
Hello, new poster here, I tried doing a forum search, but nothing specifically addressed my questions or I missed it. I'm researching the ability of cell phones to determine their position via the "911 locator" mechanism without a dedicated GPS receiver (embedded or external). I'm finding it very difficult to get any technical information at all. I know that a phone is "aware" of the cell ID it's currently using and I'm pretty sure it is also "aware" of adjacent cells. Can anyone point me at technical resources that address this? Is there one international standard for the cell ID information? Is there some sort of universal standard for how much information is packaged with the cell ID? What is it? Is that carrier specific? What carrier service is it dependant on? What about areas (and cells) that are serviced by multiple carriers? Is there some massive database of cell IDs (like the internet DNS) that links cell IDs and actual geographic location? Is there some "backdoor" for a software app to get at the data? I'm interested in either finding or developing an application that can use the information and feed it to an on-board application for phones that have enough CPU and memory resources to display the information in some user friendly form. If this is not an appropriate topic for this forum, please excuse me but if you have some information, contact me by email. Regards, Gary
robertlipe+usa.net on Fri Mar 23 10:56:17 2007 (link), replying to msg
> > Hello, new poster here, I tried doing a forum search, but nothing > > specifically addressed my questions or I missed it. > > That's because it is not related to GPS. It's a location system, but > does not involve the GPS system or satellite location in any way. It's not related to GPX, at least, so this is probably not the place for this discussion anyway... > > I'm researching the ability of cell phones to determine their position > > via the "911 locator" mechanism without a dedicated GPS receiver > > (embedded or external). > > > > I'm finding it very difficult to get any technical information at all. > > If you're going by what you've seen on _CSI_ and in films, forget > it. It's not possible. In the U.S., at least, the "assisted 911" stuff uses the tower triangulation to feed to the approximate location and time to the (optional) GPS engine for real GPS action. A fairly small number of fones have onboard GPS. An even smaller percentage of carriers allow you access to the location data. http://www.mologogo.com seems to be the common example of what you're trying to do. See their list of carriers and fones at http://mologogo.wikispaces.com/Phone+List But this has nothing to do with GPX... RJL
skhapre+yahoo.com on Fri Mar 23 11:06:03 2007 (link), replying to msg
i want to check if i can use png or jpg or gif with GPX. i would be using this for garmin poi --- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > On 23 Mar 2007, at 16:19, skhapre wrote: > > > i am interested in knowing if it is possible to define image format > > other in bmp in GPX. > > As far as I know, not even BMP format is defined in GPX. Are you > using an extension you haven't mentioned ? What is the BMP image > used for ? > > Simon. >
robertlipe+usa.net on Fri Mar 23 11:28:11 2007 (link), replying to msg
> i want to check if i can use png or jpg or gif with GPX. i would be > using this for garmin poi You can represent any URL you like withing GPX itself - it's just the passthrough. Want to attach a quicktime movie to a waypoint? Fine with us. The question you should be asking is "Does Garmin's POILoader program accept PNG or JPG URLs that are in a GPX file?" I know it'll take JPG and I recall there are all kinds of rules about image size, color depth, transparency, and so on. That question could probably be best answered by digging around in the POILoader doc, though. Welcome to "well, OK, but that's not really a GPX question" Friday. RJL
gepp1+yahoo.com on Sat Mar 24 10:58:18 2007 (link)
but thanks for the input public and private. Felt I owe you something so this is my best attempt. There is a free version of GPSTrackmaker http://www.gpstm.com/ that does quite a few file translation including from and to GPX. Might come in handy for some of you. Regards, Gary
gepp1+yahoo.com on Sat Mar 24 10:58:51 2007 (link), replying to msg
Thanks for the info. Good link ... at least I know its possible and their web led me to their sources for satellite data and their Java code. Like a pig sniffing out truffles. Regards, Gary
mark+pfeifers.org on Thu Mar 29 17:39:57 2007 (link)
I use Breeze Systems Downloader Pro to download pictures from my digital camera to my PC (see http://www.breezesys.com/ for details). The newest version of Downloader Pro includes the ability to geotag pictures as they are transferred from the camera. The problem is that the initial version only supports tracklog files in NMEA format. I'm in contact with the author to hopefully get him to support GPX files as well. For the moment, I'd like to try out the geotagging support, but I can't find an application that can talk to my Garmin GPSMap 76S and produce a tracklog file in NMEA format. Does anyone know of such an application that runs on Windows? Thanks. Mark
richard+jelbert.com on Sat Mar 31 16:58:29 2007 (link)
Hello Mark You should look at www.robogeo.com because it imports a variety of data formats. I've also built a hardware solution to your problem where my geotagger records data on a memory card in a very similar format to nmea. There is a version that works with the Garmin 76csx - see www.geotagger.co.uk Richard www.geotagger.co.uk - original message - Subject: [gpsxml] NMEA file From: "Mark Pfeifer" <mark+pfeifers.org> Date: 30/03/2007 00:40 I use Breeze Systems Downloader Pro to download pictures from my digital camera to my PC (see http://www.breezesys.com/ for details). The newest version of Downloader Pro includes the ability to geotag pictures as they are transferred from the camera. The problem is that the initial version only supports tracklog files in NMEA format. I'm in contact with the author to hopefully get him to support GPX files as well. For the moment, I'd like to try out the geotagging support, but I can't find an application that can talk to my Garmin GPSMap 76S and produce a tracklog file in NMEA format. Does anyone know of such an application that runs on Windows? Thanks. Mark Yahoo! Groups Links
parker_dave+hotmail.com on Tue Apr 03 13:10:54 2007 (link)
This is what I hope to accomplish, I need a few pointers to prevent too many 'learning experiences". I currently have a site where cyclists - generally long distance riders - log their miles daily. Since many of us are using GPS systems -- Garmin for the most part - I would like to allow them to send the ride data from their receiver to the website where the miles, time and possibly elevation would be parsed and entered into the database. Since many of the riders are not too technically inclined, getting data from the receiver cannot be too complicated. I thought that I could possibly transfer track data to Mapsource ( Or something else. I only suggest MS because most Garmin owners have at least the base version of MS). Save the track as a gpx file or even a tab delimited text file and upload that to a tool that would parse the relevant data. Upon some investigation I found that the track data includes hundreds of trackpoints that altogether make up the complete track. Also, I guess that there can be several days in one set of tracks that are transferred to the computer. The only way that I could isolate and save a single track was to delete all but that one track. There is a grid on the Track Properties window that shows track data cumulatively, but when saved as a text file, all the trackpoints are included in the file. I suppose that I could parse the relevant data from this file, but I am hoping that some of you experienced with GPS programming might have a better solution. Also, I am using Visual Studio which handles gpx files as regular XML docs. However, the gpx data does not seem to include mileages - how do you figure distance from gpx files? Any references or sites that anyone knows of regarding this sort of programming would be appreciated. Thanks in advance...
ajcartmell+fonant.com on Tue Apr 03 14:23:55 2007 (link), replying to msg
Dave, > I would like to allow them to send the ride data from their receiver > to the website where the miles, time and possibly elevation would be > parsed and entered into the database. Sounds good. Elevation isn't usually particularly accurate from a GPSR, you might want to use a more consistent elevation database, I use the free SRTM data from NASA on my site. The resolution is mostly good enough for cycle routes, and it's consistent from one ride to the next over the same points. > version of MS). Save the track as a gpx file or even a tab delimited > text file and upload that to a tool that would parse the relevant > data. I read GPX files using PHP for my cycling site. Parsing the GPX file is not that simple, as the file format is used in different ways by different programs. The main problem is dealing with duplicates when waypoints are included as routepoints too, while still keeping off-route waypoints. Also you need to work out what to do with multiple track segments. You mightwant to just merge them when their recorded times are within some tolerance. > Also, I guess that there can be several days in one set of tracks > that are transferred to the computer. The only way that I could > isolate and save a single track was to delete all but that one track. My approach would be to upload the whole file, parse it, and then let the user decide which tracks to save. > Also, I am using Visual Studio which handles gpx files as regular XML > docs. However, the gpx data does not seem to include mileages - how > do you figure distance from gpx files? Depends how accurate you want to be, there are various algorithms. If your points are all close together you can use pythagoras on the longitude and latitude values, if you want better accuracy or your points are a long way apart you need to use spherical geometry to take the earth's curvature into account. Anthony -- www.fonant.com - Quality web sites
daveparker+big-dogs.org on Wed Apr 04 07:00:49 2007 (link), replying to msg
What would be the drawbacks to having the users save and upload the tracks as a text file? I noticed in the one I created that there is a sort of summary line that displays total distance for a track along with time, etc. That might make getting the basics a little easier, but would parsing a text file create problems because it would be more prone to error? Thanks --- In gpsxml+yahoogroups.com, "Anthony Cartmell" <ajcartmell+...> wrote: > > Dave, > > > I would like to allow them to send the ride data from their receiver > > to the website where the miles, time and possibly elevation would be > > parsed and entered into the database. > > Sounds good. Elevation isn't usually particularly accurate from a GPSR, > you might want to use a more consistent elevation database, I use the free > SRTM data from NASA on my site. The resolution is mostly good enough for > cycle routes, and it's consistent from one ride to the next over the same > points. > > > version of MS). Save the track as a gpx file or even a tab delimited > > text file and upload that to a tool that would parse the relevant > > data. > > I read GPX files using PHP for my cycling site. Parsing the GPX file is > not that simple, as the file format is used in different ways by different > programs. The main problem is dealing with duplicates when waypoints are > included as routepoints too, while still keeping off-route waypoints. Also > you need to work out what to do with multiple track segments. You > mightwant to just merge them when their recorded times are within some > tolerance. > > > Also, I guess that there can be several days in one set of tracks > > that are transferred to the computer. The only way that I could > > isolate and save a single track was to delete all but that one track. > > My approach would be to upload the whole file, parse it, and then let the > user decide which tracks to save. > > > Also, I am using Visual Studio which handles gpx files as regular XML > > docs. However, the gpx data does not seem to include mileages - how > > do you figure distance from gpx files? > > Depends how accurate you want to be, there are various algorithms. If your > points are all close together you can use pythagoras on the longitude and > latitude values, if you want better accuracy or your points are a long way > apart you need to use spherical geometry to take the earth's curvature > into account. > > Anthony > -- > www.fonant.com - Quality web sites >
ajcartmell+fonant.com on Wed Apr 04 07:26:25 2007 (link), replying to msg
Dave, > What would be the drawbacks to having the users save and upload the > tracks as a text file? You'd need to define the format of the text file, and unless there's another obvious one to use, GPX is an ideal text file format for this. > I noticed in the one I created that there is > a sort of summary line that displays total distance for a track > along with time, etc. That might make getting the basics a little > easier, but would parsing a text file create problems because it > would be more prone to error? Depends on the format, and how rigidly the users stick to it. Generally XML is easier to parse than some arbitrary text file. No need to re-invent the wheel - GPX is designed for exactly this task! Anthony -- www.fonant.com - Quality web sites
honza+gpsnav.cz on Thu Apr 12 06:00:35 2007 (link)
Hi, has anybody succeeded in writing such tool? Since I have bought my first eTrex, I face the same problem with the logs, so I started to implement a simple Java tool, which also focuses on cleaning described type of errors. It uses acceleration (i.e., speed change over time) limit and works pretty nice, still there are some errorneous points that should be eliminated/corrected, but although I search for further approaches, I have no success. If you are interested, I could share the app and I'm also interested on ideas to further improve the error filtering. --- In gpsxml+yahoogroups.com, "Mappicus" <yahoo+...> wrote: > > Can anyone point me to an algorithm for deciding whether any points in > a GPX track log ought to be discarded as being "bad"? I am talking > about those spurious readings one's GPS takes every so often (due to > reduction in signal or whatever) that are a few hundred yards off the > real track. > > I am putting together some web based track visualization tools, and > these points really mess up a map overlay or a speed graph. I imagine > it can be done based on whether their distance from their adjacent > points is unsually high, or something along those lines, but I'd > rather not reinvent the wheel if anyone knows of a published method. >
robertlipe+usa.net on Thu Apr 12 06:48:31 2007 (link), replying to msg
vodacz wrote: > implement a simple Java tool, which also focuses on cleaning described > type of errors. It uses acceleration (i.e., speed change over time) > limit and works pretty nice, still there are some errorneous points > that should be eliminated/corrected, but although I search for further If you have the math worked out and would like to share, I'd be interested in seeing it and considering it for a filter in GPSBabel. RJL
honza+gpsnav.cz on Fri Apr 13 02:38:24 2007 (link), replying to msg
Looks like an interesting piece of SW. Unfortunatelly, my German skills are not very good -- will try to explore it and see what it is capable of. However, an english page with brief description of the program would be great. > Take a look at http://www.gps-freeware.de/ is this what vour'e > looking for?
honza+gpsnav.cz on Fri Apr 13 02:38:41 2007 (link), replying to msg
Dave, thanks for a hint. Unfortunatelly, Eino's program has impressive variety of options, but it fails to perform filtering in the way I need -- it probably modifies the log so that it loses as small information as possible; unfortunatelly, from this point of view, these misplaced points bear a big amount of information: they create peaks and big speed changes, so they are "important". Furthermore, after filtering the gpx using GeoConv, the data went somehow wrong: the average speed changed from 100 kph to some 200-300 kph (?!) > You might want to take a look at the GeoConv program: > http://www.kolumbus.fi/eino.uikkanen/geoconvgb/index.htm > It can do filtering, and Eino(the author) has started a > Java version.
honza+gpsnav.cz on Fri Apr 13 02:41:03 2007 (link), replying to msg
> > implement a simple Java tool, which also focuses on cleaning described > > type of errors. It uses acceleration (i.e., speed change over time) > > limit and works pretty nice, still there are some errorneous points > > that should be eliminated/corrected, but although I search for further > > If you have the math worked out and would like to share, I'd be > interested in seeing it and considering it for a filter in GPSBabel. Robert, the "math" in the background isn't complicated at all. I a) calculate the velocity for each pair of successive trackpoints b) from these, I calculate acceleration / deceleration in each point optionally: c) calculate azimuth for each pair of successive trackpoints d) calculate the radius of turn in each trackpoint e) calculate "side acceleration" (is it the correct term?) in each trackpoint Then I filter out points with acceleration (obtained from b, or calculated from that obtained in b and that obtained in e) higher than specified value. This is hard to specify, because the acceleration depends on type of vehicle you are using, I tried 5 m.s^(-2) with good results. Further filtering might be based on velocity -- this requires either automatic or manual determining of speed range for current track. I'm working on it, but have no final solution. One approach would be to guess type of vehicle / pedestrian from speed/acceleration characteristics of current tracklog and then applying speed and acceleration filters appropriate for guessed vehicle type. The second one, more universal, would be to get the speed/acceleration characteristics, take speed and acceleration range that covers about 90 - 95% of these values and filter out points with higher speed/acceleration. However, this method will fail treating special situations, such as driving on motorway for a long time (sets speed range to > 100kph), taking a short trip through a nearby town or so (the speed drops under estimated range, so many points from this trip would be left out). So I think many problems have yet to be solved. I would really appreciate if such filtering became part of gpsbabel, but first of all, it would be great to work out a well performing method. Probably I will publish the code and let people who are interested to play with it just to get some feedback and probably some great ideas which will move it further.
eeronpoika+yahoo.com on Sun Apr 22 09:18:00 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "vodacz" <honza+...> wrote: > > Dave, thanks for a hint. Unfortunatelly, Eino's program has impressive > variety of options, but it fails to perform filtering in the way I > need -- it probably modifies the log so that it loses as small > information as possible; unfortunatelly, from this point of view, > these misplaced points bear a big amount of information: they create > peaks and big speed changes, so they are "important". Furthermore, > after filtering the gpx using GeoConv, the data went somehow wrong: > the average speed changed from 100 kph to some 200-300 kph (?!) > > > You might want to take a look at the GeoConv program: > > http://www.kolumbus.fi/eino.uikkanen/geoconvgb/index.htm > > It can do filtering, and Eino(the author) has started a > > Java version. > GeoConv's track reducing algorithm doesn't attempt to "clean up" the track by e.g. filtering peak-points and therefore GeoConv isn't a solution to your problem. I however would like to try to find the reason to the change in the average speed from 100 kph to some 200-300 kph - it worries me!. Could you please send me a sample input file and convertion run, that I could use to recreate the error? You find my e-mail-address from my home page: Eino Uikkanen http://www.kolumbus.fi/eino.uikkanen/gb/index.htm
tom+tomarneson.com on Sun Apr 22 16:36:41 2007 (link)
I'm trying to use MSXSL v4 to parse gpx files instead of using my own parser. I use the J language, and it has an interface to the MSXSL parser. When I tried to parse a gpx file created by ExpertGPS, I got the following error: ------------ error message ---------- Error -1072898035 at 18899,69 The element 'cased' is used but not declared in the DTD/Schema. <cased xmlns="http://www.topografix.com/GPX/Private/TopoGrafix/0/3">true</cased> ^ ---------- end of error message ---- The following is from the J addon interface to the parser: NB. J script fragment DESCRIPTION=: 0 : 0 XSL Transformation of a text XML with a text XSLT. Useful for obtaining a flat text for further processing with J. Windows version requires MSXSL v4. UNIX requires libxml2/libxslt. The idea is to avoid reinventing the wheel trying to make XML parser in J, but use world's best XML tools for what it does best and leave flat structures to the world's best rectangular data tool. Copyright 2003-2007 (C) Oleg Kobchenko ) NB. end of J script fragment Can anyone provide some helpful information? Thanks, Tom
egroups+topografix.com on Mon Apr 23 04:51:04 2007 (link), replying to msg
Hello, Sunday, April 22, 2007, 7:33:54 PM, Tom wrote: > I'm trying to use MSXSL v4 to parse gpx files instead of using my own > parser. I use the J language, and it has an interface to the MSXSL parser. > > When I tried to parse a gpx file created by ExpertGPS, I got the > following error: > > ------------ error message ---------- > > Error -1072898035 at 18899,69 > The element 'cased' is used but not declared in the DTD/Schema. > > <cased > > xmlns="http://www.topografix.com/GPX/Private/TopoGrafix/0/3">true</cased> > ^ > ---------- end of error message ---- Can you post (or email me directly) the GPX file in question? Here's the declaration of <cased> - I'm not sure why your parser is complaining, unless this xsd isn't referenced at the top of the GPX file. http://www.topografix.com/GPX/Private/TopoGrafix/0/3/TopoGrafix.xsd - <!-- Cased definition: draw cased line on map --> - <xsd:element name="cased" type="xsd:boolean"> - <xsd:annotation> <xsd:documentation>Draw a cased (outlined) line on the map</xsd:documentation> </xsd:annotation> </xsd:element> -- Dan Foster
orroberson+yahoo.com on Thu Apr 26 03:48:34 2007 (link)
Hello, I'm looking for an easy way to generate graphical profiles from gpx track data offline. I realize I can do this online now with gpsvisualizer but in the areas where I'm hiking there's typically no network available. I'm using the Nokia 770 with Maemo Mapper. I thought initially about writing a script in Python which the Nokia supports without any dependencies. Seems like overkill though. I don't think that the Opera browser offers much xml support... Otto
egroups+topografix.com on Thu Apr 26 04:05:53 2007 (link), replying to msg
Hello, Thursday, April 26, 2007, 6:05:52 AM, Otto wrote: > I'm looking for an easy way to generate graphical profiles from gpx > track data offline. Are you looking for software to do this? ExpertGPS will export a track elevation profile in PNG format. http://www.expertgps.com/help/cmd_export_profile_image.htm -- Dan Foster
orroberson+yahoo.com on Thu Apr 26 11:29:31 2007 (link), replying to msg
Dan, Thanks for the link, but it looks like it's Windows only. If it's software then it needs to be debian linux and able to run on the ARM processor that the Nokia 770 uses. I think that there's a much simpler solution using xslt, since Maemo Mapper already saves tracks as xml/gpx. Right now my idea is to use a configuration file in conjunction with data input from a web page, all files stored on the Nokia. Otto
orroberson+yahoo.com on Fri Apr 27 04:43:53 2007 (link)
Answering my own question... http://trac.openstreetmap.org/browser/applications/utils/gps-tracks/gpx2svg A script for ruby to convert gpx tracks to svg graphics. Written by 'steve�? http://maemo.mmapps.net/ What seems to be the latest port of Ruby for the Nokia 770. Haven't tried it yet. Since the 770 browser supposedly supports svg-tiny, this should work with minimal editing. Otto
egroups+topografix.com on Mon May 07 14:59:48 2007 (link)
Hello gpsxml, I just noticed that GPX 1.0 files fail to validate if the email address contains a number. <email>cat+dog.com</email> validates. <email>cat+dog123.com</email> does not validate. Here's the offending regular expression for emailType: <xsd:simpleType name="emailType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[\p{L}_]+(\.[\p{L}_]+)*+[\p{L}_]+(\.[\p{L}_]+)+" /> </xsd:restriction> </xsd:simpleType> Anyone care to offer a corrected pattern? Should we just change this back to an xsd:string? (The pattern was suggested as a way to ensure that the email address was valid) A quick google search suggests to me that we punt on this and change it back to xsd:string. I believe this DOES need to get retroactively fixed in the GPX 1.0 schema. Note that this is not an issue in GPX 1.1 because we broke emailType into two parts to thwart email harvesting from GPX files: <xsd:complexType name="emailType"> - <xsd:annotation> <xsd:documentation>An email address. Broken into two parts (id and domain) to help prevent email harvesting.</xsd:documentation> </xsd:annotation> - <xsd:attribute name="id" type="xsd:string" use="required"> - <xsd:annotation> <xsd:documentation>id half of email address (billgates2004)</xsd:documentation> </xsd:annotation> </xsd:attribute> - <xsd:attribute name="domain" type="xsd:string" use="required"> - <xsd:annotation> <xsd:documentation>domain half of email address (hotmail.com)</xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> -- Dan Foster
roky8+yahoo.com on Sun May 13 14:38:51 2007 (link)
Hey I'm fresh to gpx and I don't really have any developing/programming background. I'm searcihg for a easy way (read .exe :) ) to convert the gpx file to a readable html, txt or something else. I'm using a Power Navigator 2 with my N70 and BT GPS. So it has the features of Track/Waypoint. If its possible (I mean if someone already has something like this) to get the info out like this Waypoint #1 - lat = xx.xxx, lon = xx.xxx Waypoint #2 - .. .. .. an example of the file would be: <?xml version="1.0"?> <gpx version="1.0" creator="PowerNavigation 2.0 - http://www.symbianware.com" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <wpt lat="46,849998" lon="0,000000"> <name>Waypoint(0)</name> </wpt> <wpt lat="46,849998" lon="14,983334"> <name>Waypoint(1)</name> </wpt> <wpt lat="46,859520" lon="14,997620"> <name>Waypoint(2)</name> </wpt> <wpt lat="46,515678" lon="14,989304"> <name>Waypoint(3)</name> </wpt> </gpx> If anyone can help me with this I'll be very gratefull.
roky8+yahoo.com on Tue May 15 09:08:51 2007 (link), replying to msg
thanks for all the input so far :) I've posted on a forum and they showed me GPSbabel and I've been using it since. I also noticed, that my coordiates should be with (.) and not with (,) . Now I wanted to ask for something again, but I just found out, that GPSBabel does that too - converting into readable *.txt files. Thanks for the help Rok --- Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > > On 13 May 2007, at 9:00pm, Roky8 wrote: > > > <wpt lat="46,849998" lon="0,000000"> > > Just a note that as far as I know you cannot use > commas in the format > of numbers. You will need to format them in British > style: > > <wpt lat="46.849998" lon="0.000000"> > > Simon. > ____________________________________________________________________________________Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/
khan_maswood+rediffmail.com on Wed May 23 04:22:13 2007 (link)
hi, I am working on GIS systems. I will appreciate any help on how to create a GPX file.
ptomblin+gmail.com on Wed May 23 17:50:04 2007 (link), replying to msg
On 5/23/07, khan_maswood <khan_maswood+rediffmail.com> wrote: > > hi, > > I am working on GIS systems. > I will appreciate any help on how to create a GPX file. > > Well, I don't know about most people, but I create a GPX file with open(XML, ">$xmlfile"); print XML (<<EOF); <?xml version="1.0"?>'; <gpx version="1.1" ... EOF Could you be more specific? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt [Non-text portions of this message have been removed]
yahoo+kaply.com on Thu May 24 10:51:52 2007 (link)
I apologize in advance for newbie stuff on the list. I've been asked to get a quick GPX exporter together for the Firefox Operator extension. All I have for the geo microformat is lat/long and probably a description of what it is. Would I use just a waypoint for that? what would <ele> and <sym> be in that case? and would I put a <time> in this scenario? Thanks Mike Kaply
egroups+topografix.com on Thu May 24 11:09:33 2007 (link), replying to msg
Hello, Thursday, May 24, 2007, 12:21:12 PM, pspmikek wrote: > I apologize in advance for newbie stuff on the list. > > I've been asked to get a quick GPX exporter together for the Firefox > Operator extension. > > All I have for the geo microformat is lat/long and probably a > description of what it is. > > Would I use just a waypoint for that? what would <ele> and <sym> be in > that case? and would I put a <time> in this scenario? In GPX, attributes (things in quotes) are required. Elements (things in angle brackets) are optional. You'd skip <ele>, <sym>, and <time> entirely. ... <wpt lat="45.234" lon="-123.45"> <desc>Description goes here</desc> </wpt> ... -- Dan Foster
khan_maswood+rediffmail.com on Wed May 30 06:35:25 2007 (link)
Hi, i get the following error when i make a Response.WriteFile("my.gpx") on my asp.net web page. Will appreciate any help on this issue. Cannot have a DOCTYPE declaration outside of a prolog. Error processing resource 'http://localhost/ICitiMobi/FrmGenRoute.as...
bobmcm+swbell.net on Tue Jun 05 10:54:01 2007 (link)
I am trying to learn how to create an XSL file for use with GPX files, and am really having problems. If I use the XSL file against the file Untitled.gpx that is in the XSL example in the files area, everything works as expected. I get a list of the waypoints in the gpx file. If I try against one that I generated from inside of ExpertGPS, it gives me all of the data in the GPX file with the tags removed. I have tried the XSL file "gpsxml Quick View.xsl" from the files area, and it does the same thing. Everything works great with the example file that comes with it, but if I point it to the GPX file created with either ExpertGPS, or Mapsource, I get all of the data in the GPX file minus the tags. I'm sure I'm just missing something, but after a week of banging on it, I just don't know what else to try. Thanks, Bob McMahan -- Start XSL File -- <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="gpx"> <html> <body> <xsl:apply-templates select="wpt"/> </body> </html> </xsl:template> <xsl:template match="wpt"> <h1>Name: <xsl:value-of select="name"/></h1> </xsl:template> </xsl:stylesheet> -- End XSL File -- -- Start GPX File -- <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="ExpertGPS 2.4.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.topografix.com/GPX/gpx_overlay/0/3 http://www.topografix.com/GPX/gpx_overlay/0/3/gpx_overlay.xsd http://www.topografix.com/GPX/gpx_modified/0/1 http://www.topografix.com/GPX/gpx_modified/0/1/gpx_modified.xsd http://www.topografix.com/GPX/Private/TopoGrafix/0/3 http://www.topografix.com/GPX/Private/TopoGrafix/0/3/topografix.xsd"> <metadata> <link href="http://www.garmin.com"> <text>Garmin International</text> </link> <bounds minlat="29.76145810" minlon="-95.64355870" maxlat="29.78109730" maxlon="-95.60557110"/> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2007-06- 05T17:33:24.672Z</time> <active_point xmlns="http://www.topografix.com/GPX/Private/TopoGrafix/0/3" lat="29.76968300" lon="-95.64631690"> </active_point> </extensions> </metadata> <wpt lat="29.76145810" lon="-95.60557110"> <ele>17.37</ele> <time>2007-05-28T03:53:09Z</time> <name>Dairy Ashford Parking</name> <cmt>27-MAY-07 12:00:15PM</cmt> <desc>27-MAY-07 12:00:15PM</desc> <sym>Parking Area</sym> <extensions> <label xmlns="http://www.topografix.com/GPX/gpx_overlay/0/3"> <label_text>Dairy Ashford Parking</label_text> </label> </extensions> </wpt> <wpt lat="29.77143440" lon="-95.62040630"> <ele>21.64</ele> <time>2007-05-28T03:53:09Z</time> <name>Eldridge Bathroom</name> <cmt>27-MAY-07 11:35:23AM</cmt> <desc>27-MAY-07 11:35:23AM</desc> <sym>Restroom</sym> <extensions> <label xmlns="http://www.topografix.com/GPX/gpx_overlay/0/3"> <label_text>Eldridge Bathroom</label_text> </label> </extensions> </wpt> <wpt lat="29.76999440" lon="-95.64355870"> <ele>16.76</ele> <time>2007-05-28T03:53:09Z</time> <name>Hwy6 Parking</name> <cmt>27-MAY-07 10:48:23AM</cmt> <desc>27-MAY-07 10:48:23AM</desc> <sym>Parking Area</sym> <extensions> <label xmlns="http://www.topografix.com/GPX/gpx_overlay/0/3"> <label_text>Hwy6 Parking</label_text> </label> </extensions> </wpt> </gpx> -- End GPX file --
monica+glowball.com on Tue Jun 05 14:54:12 2007 (link), replying to msg
I'm new to this group, and I have a Web site with lots of GPX files available for download. Sorry to drag up an old thread, but has anyone found a solution to this? I've tried every MIME type suggested and nothing is working. I have had a few users tell me that they see XML instead of being prompted to save a .gpx file, and I'm personally seeing the same thing. I think it has something to do with IE7. Thanks, Monica --- In gpsxml+yahoogroups.com, "Doug Adomatis" <gps_maps+...> wrote: > > --- "bbalxx" wrote: > > what is the proper MIME type which should be used to serve .gpx files? > > Brian, > There are the server control panel setting I'm using for User Defined > MIME Types: > > application/octet-stream .gpx > > Most of the time when a visitor clicks on a .gpx file link, the > associated application (i.e. ExpertGPS) will automatically launch and > open the file. > > Every now and then someone will email me with "Hey I clicked on the > link and all I got was a bunch of computer code garbage" > > Also, once in a while, someone will email me saying that they tried to > "Save As..." and somehow the xml file type extension got appended. > > The occurance of these reported problems is a fraction of 1% of all > downloads. > > Over the years I've experimented with this setting and this is what > seems to work. Of course, If there is a better setting, I'd like to > know too. > > - Doug > www.TravelByGPS.com >
monica+glowball.com on Tue Jun 05 15:51:09 2007 (link), replying to msg
My GPX files are generated by ExpertGPS and then I upload them, so I'm providing a link directly to the file that already exists there. I would think that I'd have to add my own MIME type in order to get this to work. Right? I just tried your MIME type (application/x-GPS-Exchange-Format) and I'm still getting the XML file in my browser. Any ideas? On a side note, when I change the MIME type in htaccess I close my browser and reopen it before testing the new type. Is that enough to clear out any memory of the previous type I tested?
khan_maswood+rediffmail.com on Wed Jun 06 04:52:22 2007 (link)
hi, I am doing a Response.Write("MyGpxFile.gpx") on an Asp.net web form. I get the following error. Can anybody tell me how to overcome this problem. ====================================================================== 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. Cannot have a DOCTYPE declaration outside of a prolog. Error processing resource 'http://localhost/ICITI-MOBI/FrmGenRoute.a... <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > ----------^ > =======================================================================
ptomblin+gmail.com on Wed Jun 06 18:36:03 2007 (link), replying to msg
On 6/6/07, khan_maswood <khan_maswood+rediffmail.com> wrote: > > hi, > > I am doing a Response.Write("MyGpxFile.gpx") on an Asp.net web form. > I get the following error. Can anybody tell me how to overcome this > problem. > ====================================================================== > 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. > > Cannot have a DOCTYPE declaration outside of a prolog. Error processing > resource 'http://localhost/ICITI-MOBI/FrmGenRoute.a... > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > > ----------^ > > > ======================================================================= > > > The answer is probably the same as when you asked this question on May 30th. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt [Non-text portions of this message have been removed]
andy+pigsonthewing.org.uk on Fri Jun 08 17:31:17 2007 (link)
>On 24 May 2007, at 5:21pm, pspmikek wrote: >> I've been asked to get a quick GPX exporter together for the Firefox >> Operator extension. > >Get the person who asked you for the facility to supply some examples >in the desired format. GPX has many different tags you may or may not >want to use, and many different ways to space out and label points >which may or may not suit the person you're writing for. You might come >up with a file which is perfectly within GPX format and completely >misses out some detail that your user wants. Get them to give you at >least one example of the format they want. Hi, I've just joined this list, in order to participate in this specific discussion. I'll assume you all know what geo and hCard microformats are. If not, please say. I'm the person who made the request, but I'm not a GPS user, and only have a rudimentary knowledge of XML; and the intention is to make the GPS output available to anyone, not just one person. Suppose someone visits a web page with a list of coordinates, marked up using the geo microformat, such as: <http://en.wikipedia.org/wiki/Manchester_Ship_Canal#Features> we want that person to be able to download all those points into their GPS device, in a meaningful way. Those coordinates may - as above - or may not - as in: <http://en.wikipedia.org/wiki/List_of_impact_craters_in_South_America> relate to a linear feature or trail; and may be sorted geographically, alphabetically, in some other way, or not at all. On another website, they may relate specifically to a trail of waypoints: <http://www.poi66.com/maps/show_album.php?album=terhorne1991> Or there may be just a single geo microformat on the page: <http://www.westmidlandbirdclub.com/belvide/> The geo microformats may or may not be in an hCard microformat, which, if they are, provides a name (class="fn org" in microformat terms). I'm sure Mike will be as glad as I shall, to receive your comments and suggestions. Thank you. -- Andy Mabbett * Say "NO!" to compulsory UK ID Cards: <http://www.no2id.net/> * Free Our Data: <http://www.freeourdata.org.uk> * Are you using Microformats, yet: <http://microformats.org/> ?
andy+pigsonthewing.org.uk on Sat Jun 09 03:58:37 2007 (link), replying to msg
In message <97CA5EA7-C204-4E2B-9482-8ABC8F40F3C6+hearsay.demon.co.uk>, Simon Slavin <slavins+hearsay.demon.co.uk> writes >On 9 Jun 2007, at 12:18am, Andy Mabbett wrote: > >> Suppose someone visits a web page with a list of coordinates, >> marked up >> using the geo microformat, such as: >> >> <http://en.wikipedia.org/wiki/Manchester_Ship_Canal#Features> >> >> we want that person to be able to download all those points into their >> GPS device, in a meaningful way. > >In GPX format, a collection of points, with nothing relating one to >another, is a collection of waypoints. That's the most common kind >of GPX file you'll find. Thank you. I think that's probably what we want, at least to start with. What are the minimum, or optimal, properties for such a case? >> Those coordinates may - as above - or may not - as in: >> >> <http://en.wikipedia.org/wiki/List_of_impact_craters_in_South_America> >> >> relate to a linear feature or trail; and may be sorted geographically, >> alphabetically, in some other way, or not at all. > >There are ways to express an ordered collection of points: a track or >a route. Conceptually, tracks are a record of where you've been, >routes are suggestions about where you could go in the future. So, >for instance, you might expect to find timestamps for each point in a >track (because someone is recording where they were and when), but >you're unlikely to find timestamps for each point in a route (because >you're just thinking about it, nobody might ever have travelled it yet). > >Both tracks and routes are simple to express in GPX format. Thanks for explaining that subtle but important distinction. I'd not heard of it before. Geo does not have a facility for encoding a sequence, or a time-stamp. It's possible to have a series of hCalendar microformats which includes an hCard, which includes a geo - so that would allow for marking up trails. For sequencing without time, we could only infer that from the page, such as the order in a list or table, or simply in the source code. Or we could offer the user a dialogue with a set of Geos and ask them to number, or drag them into sequence or have a "move up/ move down" buttons, but I would image that would be unpleasant to code and clunky to use for long lists [...] >I'd recommend you first download a few GPX files and look at them to >see if you can puzzle out what's going on, then learn some XML and >take a look at the GPX specification: >If you're into microformats I can't see you'll have any problem with >GPX. Thank you. I'll have a look, but it's really Mike's baby ;-) I'm going to take the liberty of putting a copy of this post on the microformats mailing list: <http://microformats.org/discuss/mail/microformats-discuss/> you may like to watch for replies there. -- Andy Mabbett * Say "NO!" to compulsory UK ID Cards: <http://www.no2id.net/> * Free Our Data: <http://www.freeourdata.org.uk> * Are you using Microformats, yet: <http://microformats.org/> ?
wwgpx+yahoo.co.uk on Fri Jun 15 05:32:28 2007 (link)
Hi, I'm relatively new to XML / GPX, and new to .NET 2.0 although I have many years of Microsoft development experience. I'm using the XMLWriter Class to create a GPX file. Everything else is in place, but I cannot find a way to write out the root <gpx...> tag in the required format, i.e. : <gpx version="1.0" creator="MyProgram" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> I've tried several different ways of doing this but I cannot seem to get the schema fields correct. I've decided I must be approaching it the wrong way. I've got the version, creator and namespace right, but the rest of it (xmlns:xsi and xsi:schemaLocation), I am defeated by. Any pointers anyone ?
egroups+topografix.com on Fri Jun 15 06:54:43 2007 (link), replying to msg
Hello, Friday, June 15, 2007, 5:44:43 AM, wwgpx wrote: > I'm using the XMLWriter Class to create a GPX file. Everything else > is in place, but I cannot find a way to write out the root <gpx...> > tag in the required format, i.e. : > > <gpx version="1.0" creator="MyProgram" > 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 > http://www.topografix.com/GPX/1/0/gpx.xsd"> > > I've tried several different ways of doing this but I cannot seem to > get the schema fields correct. I've decided I must be approaching it > the wrong way. I've got the version, creator and namespace right, > but the rest of it (xmlns:xsi and xsi:schemaLocation), I am defeated > by. > > Any pointers anyone ? WriteAttributeCString( pXMLDoc, pRootNode, L"xmlns:xsi", FORMAT_STR("http://www.w3.org/2001/XMLSchema-instance") ); void WriteAttributeCString( MSXML2::IXMLDOMDocumentPtr pXMLDoc, MSXML2::IXMLDOMNodePtr pParentNode, BSTR bstrName, CString strValue ) { MSXML2::IXMLDOMAttributePtr pRecIdAttr = NULL; pRecIdAttr = pXMLDoc->createAttribute( bstrName ); BSTR bstr = strValue.AllocSysString(); pRecIdAttr->nodeTypedValue = bstr; SysFreeString( bstr ); pParentNode->attributes->setNamedItem(pRecIdAttr); } -- Dan Foster
wwgpx+yahoo.co.uk on Sun Jun 17 05:43:36 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > Hello, > > Friday, June 15, 2007, 5:44:43 AM, wwgpx wrote: > > > I'm using the XMLWriter Class to create a GPX file. Everything else > > is in place, but I cannot find a way to write out the root <gpx...> > > tag in the required format, i.e. : > > > > <gpx version="1.0" creator="MyProgram" > > 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 > > http://www.topografix.com/GPX/1/0/gpx.xsd"> > > > > I've tried several different ways of doing this but I cannot seem to > > get the schema fields correct. I've decided I must be approaching it > > the wrong way. I've got the version, creator and namespace right, > > but the rest of it (xmlns:xsi and xsi:schemaLocation), I am defeated > > by. > > > > Any pointers anyone ? > > WriteAttributeCString( pXMLDoc, pRootNode, L"xmlns:xsi", FORMAT_STR ("http://www.w3.org/2001/XMLSchema-instance") ); > > void WriteAttributeCString( MSXML2::IXMLDOMDocumentPtr pXMLDoc, MSXML2::IXMLDOMNodePtr pParentNode, BSTR bstrName, CString strValue ) > { > MSXML2::IXMLDOMAttributePtr pRecIdAttr = NULL; > pRecIdAttr = pXMLDoc->createAttribute( bstrName ); > BSTR bstr = strValue.AllocSysString(); > pRecIdAttr->nodeTypedValue = bstr; > SysFreeString( bstr ); > pParentNode->attributes->setNamedItem(pRecIdAttr); > } > > > > -- > Dan Foster > :slapsforehead: Thanks for that Dan, I left out a crucial piece of information from my post, which is, I'm using VB. I can understand the code you attached, however I do specifically want to use the .NET Framework 2.0 XMLWriter object. The problem is I'm unable to get it to create a root node of the required complexity. Thanks. Walter
dale.parson+yahoo.com on Sun Jun 17 05:43:50 2007 (link)
Hi. I am new to GPS and GPX. Is there typically a way to represent outlines of sizable buildings, for example a shopping mall, in GPX or any GPS format? It seems like ptsegType might be a way to represent the outline of a building, although it does not give elevation or height information that you could interpret as floors. I don't want to kludge something if there is a standard or de facto way to represent buildings and other constructs with area, non-rectangular outlines, and possibly height. Thanks.
robertlipe+usa.net on Sun Jun 17 11:24:34 2007 (link)
> > Hi. I am new to GPS and GPX. Is there typically a way to represent > > outlines of sizable buildings, for example a shopping mall, in GPX or > > any GPS format? > > There are lots of GPS formats. I suspect that the sort of formats > used by Goggle might have the sort of thing you're asking about. If you're trying to model building (you'd mentioned internal heights of floors, so I suspect you want more than just a perimeter outline) GPX is probably the wrong tool for the job. Google has some widely accepted tools for building and rendering such thing including integration with Sketechup. I don't know about other similar products. http://earth.google.com/3d.html http://www.gearthblog.com/blog/archives/2006/09/high_quality_3d_buil.html
andy+pigsonthewing.org.uk on Sun Jun 17 14:44:52 2007 (link), replying to msg
In message <f4usp0+jn36+eGroups.com>, dale.parson <dale.parson+yahoo.com> writes >Is there typically a way to represent outlines of sizable buildings, >for example a shopping mall, in GPX or any GPS format? In drafting the proposed extension for the geo microformat: <http://microformats.org/wiki/geo-waypoint-examples#The_Problem> I've wrestled with, but not resolved, the issue of perimeters, not only for buildings but for any polygon (a plot of land, county or country, for example). The issue - at its simplest - is; if I publish four coordinates, do they form a square, or the shape of a letter "U". In other words, how do I indicate that the route continues from point 4 back to point 1? Perhaps we need a fourth GPX type: after waypoint, track and route; polygon? -- Andy Mabbett * Say "NO!" to compulsory UK ID Cards: <http://www.no2id.net/> * Free Our Data: <http://www.freeourdata.org.uk> * Are you using Microformats, yet: <http://microformats.org/> ?
egroups+topografix.com on Sun Jun 17 15:10:17 2007 (link), replying to msg
Hello, Sunday, June 17, 2007, 3:21:11 PM, Andy wrote: > Perhaps we need a fourth GPX type: after waypoint, track and route; > polygon? You're welcome to look at how ExpertGPS stores polygon data in a GPX extension. http://www.expertgps.com/ http://www.topografix.com/GPX/gpx_overlay/0/3/ -- Dan Foster
robertlipe+usa.net on Sun Jun 17 15:14:55 2007 (link)
> The issue - at its simplest - is; if I publish four coordinates, do they > form a square, or the shape of a letter "U". In other words, how do I > indicate that the route continues from point 4 back to point 1? If point 0 == point 3 then it's a closed polyline and thus a polygon. That would make it a triangle if you have four points. It's a very common way to represent this. > Perhaps we need a fourth GPX type: after waypoint, track and route; > polygon? Remembering the goal of GPXs, I'm not sure I see a need for it in this context. Besides, we already have two primitives for representing polylines and a polygon is just a closed polyline. Look at KML, GML, Shape, or a large number of other existing formats that have already had to solve this.
dale.parson+yahoo.com on Mon Jun 18 08:56:04 2007 (link), replying to msg
Thanks for all the informed responses. This one prompts me to make my goals a little more explicit: --- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+...> wrote: > > > > Hi. I am new to GPS and GPX. Is there typically a way to represent > > > outlines of sizable buildings, for example a shopping mall, in GPX or > > > any GPS format? > > > > There are lots of GPS formats. I suspect that the sort of formats > > used by Goggle might have the sort of thing you're asking about. > > If you're trying to model building (you'd mentioned internal heights of > floors, so I suspect you want more than just a perimeter outline) GPX is > probably the wrong tool for the job. Google has some widely accepted tools > for building and rendering such thing including integration with Sketechup. > I don't know about other similar products. I had looked at Google SketchUp as a possible component of what I need, but I guess the second half of my quest is to find existing databases of GPS-oriented data, preferrably open source (if they exist), that model hierarchical buildings/establishments, a shopping mall being an easy example. Of course, some people are doing that with Google SketchUp and attaching their creations to Google Earth. But I had imagined that there might already be activity within the OpenStreetMap project or elsewhere to capture this kind of data in GPX, and therefore at least de facto common practices for representing it in GPS-oriented data. --- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > Hello, > > Sunday, June 17, 2007, 3:21:11 PM, Andy wrote: > > > Perhaps we need a fourth GPX type: after waypoint, track and route; > > polygon? > > You're welcome to look at how ExpertGPS stores polygon data in a GPX > extension. > > http://www.expertgps.com/ > > http://www.topografix.com/GPX/gpx_overlay/0/3/ I helps to see another working solution to the problem. Thanks! I am enough of a newbie not to have an opinion one whether new GPX constructs are warranted. If there is sufficient object-composition and object-extension capability to fill this need from a technical perspective -- and there appears to be -- that leaves the issues of 1) agreeing on usage conventions so as not to come up with two competing usages of those object-composition and object-extension capabilities, and then 2) populating some databases, e.g., OSM or otherwise, to add momentum. It appears from the replies to be part of the work in progress. Thanks again.
yahoo+kaply.com on Mon Jun 25 09:35:12 2007 (link)
OK, so here's my basic GPX file: <gpx version="1.1" creator="Operator Firefox Extension"> - <wpt lat="-122.0822035425683" lon="37.42228990140251"> <desc>Google Campus</desc> </wpt> </gpx> I'm getting an error from Easy GPS that the latitude is invalid? Even though this lat/long works in google earth and google maps. Thanks for any help you can provide. Mike Kaply
ajcartmell+fonant.com on Mon Jun 25 09:43:12 2007 (link), replying to msg
> I'm getting an error from Easy GPS that the latitude is invalid? Even > though this lat/long works in google earth and google maps. Latitude is North-South from -90 to +90 degrees Longitude is East-West from -180 to 180 degress You have them the wrong way round :) Anthony -- www.fonant.com - Quality web sites
egroups+topografix.com on Mon Jun 25 09:50:47 2007 (link), replying to msg
Hello, Monday, June 25, 2007, 11:50:33 AM, pspmikek wrote: > <wpt lat="-122.0822035425683" lon="37.42228990140251"> > I'm getting an error from Easy GPS that the latitude is invalid? You have your latitudes and longitudes reversed. Try this: <wpt lat="37.42228990140251" lon="-122.0822035425683"> -- Dan Foster
andy+pigsonthewing.org.uk on Mon Jun 25 11:00:50 2007 (link), replying to msg
In message <f5oo89+lpku+eGroups.com>, pspmikek <yahoo+kaply.com> writes ><gpx version="1.1" creator="Operator Firefox Extension"> - > <wpt lat="-122.0822035425683" lon="37.42228990140251"> ><desc>Google Campus</desc> ></wpt> ></gpx> > >I'm getting an error from Easy GPS that the latitude is invalid? Perhaps it doesn't believe that you have a GPS device which is accurate to ~0.00001 of a millimetre! Have you tried swapping the lat & long values, truncating the digits (one at a time) or dropping the negative sign, to see if you still get an error message? -- Andy Mabbett
robertlipe+usa.net on Mon Jun 25 11:26:12 2007 (link)
------ Original Message ------ Received: Mon, 25 Jun 2007 01:00:52 PM CDT From: Andy Mabbett <andy+pigsonthewing.org.uk> To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Can't figure out why Easy GPS doesn't like my GPX file > In message <f5oo89+lpku+eGroups.com>, pspmikek <yahoo+kaply.com> writes > > ><gpx version="1.1" creator="Operator Firefox Extension"> - > > <wpt lat="-122.0822035425683" lon="37.42228990140251"> > ><desc>Google Campus</desc> > ></wpt> > ></gpx> > > > >I'm getting an error from Easy GPS that the latitude is invalid? EasyGPS is correct. Lat and lon are swapped. The Google Campus in MTV is 37 lat and -122 long. This file should fail validation. (If it doesn't, we should tighten up the xsd.) > Perhaps it doesn't believe that you have a GPS device which is accurate > to ~0.00001 of a millimetre! GPX doesn't place a limit on precision. Yeah, that's clearly fictitious in this case but a GPX reader should be prepared to read unlimited positions after the decimal, even if they are spurious. But that's not the problem here.
yahoo+kaply.com on Mon Jun 25 14:21:26 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Anthony Cartmell" <ajcartmell+...> wrote: > > > I'm getting an error from Easy GPS that the latitude is invalid? Even > > though this lat/long works in google earth and google maps. > > Latitude is North-South from -90 to +90 degrees > Longitude is East-West from -180 to 180 degress > > You have them the wrong way round :) Doh. Should have noticed that. I copied my testcase from somewhere else that had them swapped. Mike
ptomblin+gmail.com on Fri Aug 17 15:40:34 2007 (link)
I had a complaint from a user of my GPX waypoint generator that whatever tool he was feeding the files into (he didn't explain what tool) was complaining about "illegal characters" in records that contained French names with accented characters in them. Is this something that could be fixed by using the CDATA escape or by using some sort of encoding? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt [Non-text portions of this message have been removed]
robertlipe+usa.net on Fri Aug 17 16:04:01 2007 (link)
> I had a complaint from a user of my GPX waypoint generator that whatever > tool he was feeding the files into (he didn't explain what tool) was > complaining about "illegal characters" in records that contained French > names with accented characters in them. Is this something that could be > fixed by using the CDATA escape or by using some sort of encoding? Validate the GPX file. That'll tell you if the problem is in the reader or the writer. Can a field nave a < in it? Most that allow text can. Then it better be entity encoded or inside a CDATA. Can it have ]]> in it? Then you better not blindly stick it in a CDATA without entity encoding the >. Can it have non-ASCII characters? Then you better get the UTF-8 encoding correct. Be prepared to study it carefully - look at the encoding of the accented character and how it's represented. Probably one in four GPX implemenations that I've tied into get this subtly wrong in some way. It's pretty easy to make a GPX implementation mostly work and still miss these corner cases. One well known GPX implementation, for example, spat numerically encoded tabs and backspaces in data fields, for example, even though they're explictly disallowed.
coolguy982+yahoo.com on Sat Aug 18 09:52:45 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > On 17 Aug 2007, at 11:30pm, Paul Tomblin wrote: > > > I had a complaint from a user of my GPX waypoint generator that > > whatever > > tool he was feeding the files into (he didn't explain what tool) was > > complaining about "illegal characters" in records that contained > > French > > names with accented characters in them. Is this something that > > could be > > fixed by using the CDATA escape or by using some sort of encoding? > > A GPX file is an XML file. At the top of the file there should be a > tag explaining the character encoding: > > <?xml version="1.0" encoding="Encoding.Name"?> > > He should make sure that the encoding stated in the GPX file matches > what he wants to use. The preferred encoding is, of course, UTF-8. > > There are a number of problems connected with this. One is that the > UTF lead-in is composed of characters that various text editors don't > handle properly. For example, this page > > <http://www.usit.uio.no/it/kurs/xml/chap7.html> > > explains some of the above, and goes on to say that Windows 95/98 > NOTEPAD.EXE is unable to save files in Unicode format, no matter what > the contents say. There's another page on this subject: > > <http://www.itworld.com/nl/xml_prac/11232000/> > > and it gives a way to explicitly encode characters in an XML file. > But I don't understand if it's useful, needed, or pointless in the > context of GPX. > > Simon. > > PS: I have exactly the same problem in a GPX tool I wrote and I'm > still trying to work out how to make it all work properly. I'm > having trouble myself in understanding the issues involved. So I do > not consider that this is a solved problem with an obvious solution. > Try replacing the accented character with its HTML-escaped sequence (see here http://www.html-reference.com/Escape.htm). That did the trick for me. I also used ISO-8859-1 encoding for the XML rather than UTF-8. Thanks, Scott Geovative Solutions - create & download your own GPS tour guides http://www.geovative.com
robertlipe+usa.net on Sat Aug 18 13:36:13 2007 (link)
> Try replacing the accented character with its HTML-escaped sequence > (see here http://www.html-reference.com/Escape.htm). That did the XML and HTML entities differ. ' comes to mind.
speleoluc+gmail.com on Tue Sep 11 13:39:46 2007 (link)
Hi, I want to export a cave line plot as GPX to superimpose over a surface map in mapping programs. A cave line plot consists of (visible) stations, i.e. named points, each with a geographic location, linked in pairs by survey shots, i.e. (visible) line segments that can carry a comment. A cave or network of caves can be anywhere between 100-30,000+ survey shots linking a comparable number of stations. I could use wptType to hold stations, but it then seems overkill to declare a route for each pair of stations. The ptType/ptsegType seems more appropriate. Do I have better options? Thanks, -- Luc Le Blanc http://www.speleo.qc.ca/Auriga
dananderson2+yahoo.com on Tue Sep 11 15:31:38 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Luc Le Blanc" <speleoluc+...> wrote: > > Hi, > > I want to export a cave line plot as GPX to superimpose over a surface > map in mapping programs. > > A cave line plot consists of (visible) stations, i.e. named points, > each with a geographic location, linked in pairs by survey shots, i.e. > (visible) line segments that can carry a comment. > > A cave or network of caves can be anywhere between 100-30,000+ survey > shots linking a comparable number of stations. > > I could use wptType to hold stations, but it then seems overkill to > declare a route for each pair of stations. The ptType/ptsegType seems > more appropriate. Do I have better options? Is there a reason not to use tracks with two points?
speleoluc+gmail.com on Wed Sep 12 04:58:32 2007 (link), replying to msg
2007/9/11, Dan Anderson <dananderson2+yahoo.com>: > --- In gpsxml+yahoogroups.com, "Luc Le Blanc" <speleoluc+...> wrote: > > > > Hi, > > > > I want to export a cave line plot as GPX to superimpose over a surface > > map in mapping programs. > > > > A cave line plot consists of (visible) stations, i.e. named points, > > each with a geographic location, linked in pairs by survey shots, i.e. > > (visible) line segments that can carry a comment. > > > > A cave or network of caves can be anywhere between 100-30,000+ survey > > shots linking a comparable number of stations. > > > > I could use wptType to hold stations, but it then seems overkill to > > declare a route for each pair of stations. The ptType/ptsegType seems > > more appropriate. Do I have better options? > > Is there a reason not to use tracks with two points? Because I would have as many tracks as survey shots (the software does not "know' passages, only single survey shots). Isn't there a limit on these? I recall reading something about this. Luc Le Blanc
dananderson2+yahoo.com on Wed Sep 12 09:10:48 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Luc Le Blanc" <speleoluc+...> wrote: > > 2007/9/11, Dan Anderson <dananderson2+...>: > > --- In gpsxml+yahoogroups.com, "Luc Le Blanc" <speleoluc+> wrote: > > > > > > Hi, > > > > > > I want to export a cave line plot as GPX to superimpose over a surface > > > map in mapping programs. > > > > > > A cave line plot consists of (visible) stations, i.e. named points, > > > each with a geographic location, linked in pairs by survey shots, i.e. > > > (visible) line segments that can carry a comment. > > > > > > A cave or network of caves can be anywhere between 100-30,000+ survey > > > shots linking a comparable number of stations. > > > > > > I could use wptType to hold stations, but it then seems overkill to > > > declare a route for each pair of stations. The ptType/ptsegType seems > > > more appropriate. Do I have better options? > > > > Is there a reason not to use tracks with two points? > > > Because I would have as many tracks as survey shots (the software does > not "know' passages, only single survey shots). Isn't there a limit on > these? I recall reading something about this. Any given program may have some limit. I think you can find a program that would let you have 30,000 tracks. One track may also have more than one segment; however, depending on the program, the separate segments may or may not be drawn connected. If you run into a track limit, a program that displays separate segments within a track may help. I primarily use ExpertGPS. The limits are well above my needs, so I don't know what they are. I've seen some high numbers with some objects in ExpertGPS, so you might try a test with it. There's a 30 day free trial period. The number of routes available in GPS receivers is usually very low (30 to 150). Since the number of routes is usually low and even if the number of routes allowed by a program is high, you might be more likely to run into problems with routes (bugs if nothing else). I'm not really clear about what you want to accomplish, but using waypoints and connecting them with routes might be the best way. I don't think I'd call it overkill if it accomplishes what you want. The waypoints give you point type information that you don't get with tracks and trackpoints (even if you don't make use of waypoint names and/or comments now you might be glad you did later). You might do a dummy test to see if the quantity of data you want works.
speleoluc+gmail.com on Wed Sep 12 11:47:41 2007 (link), replying to msg
2007/9/12, Dan Anderson <dananderson2+yahoo.com>: > Any given program may have some limit. I think you can find a program > that would let you have 30,000 tracks. One track may also have more > than one segment; however, depending on the program, the separate > segments may or may not be drawn connected. If you run into a track > limit, a program that displays separate segments within a track may help. Actually, I don't target any specific software, I just want to add a GPX export feature to my cave survey freeware. I know a user would use it with OziExplorer, but others could use PathAway on a Palm or anything else. I am just trying to find the most efficient GPX approach with regards to data types. I plan to build a trial GPX file to send to some GPS users (and cavers.) Luc Le Blanc
speleoluc+gmail.com on Thu Sep 13 06:27:36 2007 (link), replying to msg
2007/9/13, Louis <clovis+libero.it>: > IMHO for a very high number of points / tracks, a GPX file is not the best solution. Instead you should store them in some sort of data base, and extract in GPX format only part of points, for example selected by country, type, ... I am not the repository of each user's data and I don't want to force my users into converting the data back into a GPX via a proprietary format. Auriga is a field tool (runs on a PalmOS PDA), likely used away from a PC. GPX is a readily usable format for mapping software, such as PathAway that also runs under PalmOS. Each cave is stored as a unique database on the PDA and it makes sense it exports as a unique GPX file. Most people won't ever get close to the limit. My only question is: which GPX data type pair is best suited to hold stations+names and segments+comments for a couple of thousands of each. Luc Le Blanc
egroups+topografix.com on Thu Sep 13 07:14:35 2007 (link), replying to msg
Hello, Thursday, September 13, 2007, 7:04:28 AM, Luc wrote: > My only question is: which GPX data type pair is best suited to hold > stations+names and segments+comments for a couple of thousands of > each. After looking at screenshots of your program, I would recommend storing stations as <wpt> and segments as <trk>. -- Dan Foster
speleoluc+gmail.com on Fri Sep 14 10:23:11 2007 (link), replying to msg
2007/9/13, Simon Slavin <slavins+hearsay.demon.co.uk>: > There are advantages to using waypoints and either routes or tracks > for each of your shots: lots of GPX software understands routes and > tracks. However, there's no reason why you shouldn't use segments in > there, if you're certain that the software you want understands > ptsegType and does something useful with it. If I use <wpt> for stations, won't I have to duplicate the lat/lon info in the <trk/trkseg> tag? I don't see a way to first declare all my <wpt> (e.g. stations) and then refer to them by name in the <trk> tag. The <rte> tag could do it, but if software is as limited as GPS with regards to number of routes, it's not a good choice :( Luc Le Blanc
lecrocop+hotmail.fr on Fri Sep 14 14:06:05 2007 (link)
hi, has anybody ever heard about plugins doing that kind of stufs? thanks
kamel_inct+yahoo.fr on Wed Oct 03 04:47:50 2007 (link)
please can someone tell me what is the difference between: track, waypoint and route?? _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail [Non-text portions of this message have been removed]
ptomblin+gmail.com on Wed Oct 03 05:36:13 2007 (link), replying to msg
On 10/2/07, kamel elkedrouci <kamel_inct+yahoo.fr> wrote: > > please can someone tell me what is the difference between: track, > waypoint and route?? > A waypoint is a permanent location, like an airport or a radio navigation aid, or on the ground, an orienteering control. A route is a series of waypoints, such as a flight plan or an orienteering course. A track is a series of locations that aren't waypoints, like a recording of where you actually flew or ran. Typically, you'll program your route in your GPS before going, and download the track afterwards. -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt [Non-text portions of this message have been removed]
doolaard+gmail.com on Wed Oct 03 05:45:58 2007 (link), replying to msg
Waypoint - any point that has coordinates (latitude and longitude) and if applicable height. Waypoints can be defined by you or others. Route - A collection (ordered) of waypoints, that are typically prepared beforehand. Eg. when you plan for a hiking trip. Track - A collection of waypoints that were actually travelled, so when you record a trip in the mountains Jan On 10/3/07, Paul Tomblin <ptomblin+gmail.com> wrote: > > On 10/2/07, kamel elkedrouci <kamel_inct+yahoo.fr<kamel_inct%40yahoo.fr>> > wrote: > > > > please can someone tell me what is the difference between: track, > > waypoint and route?? > > > > A waypoint is a permanent location, like an airport or a radio navigation > aid, or on the ground, an orienteering control. A route is a series of > waypoints, such as a flight plan or an orienteering course. A track is a > series of locations that aren't waypoints, like a recording of where you > actually flew or ran. Typically, you'll program your route in your GPS > before going, and download the track afterwards. > > -- > "To announce that there must be no criticism of the president, or that we > are to stand by the president, right or wrong, is not only unpatriotic and > servile, but is morally treasonable to the American public." -- Teddy > Roosevelt > > [Non-text portions of this message have been removed] > > > -- Met vriendelijke groet/Greetings J.K. Pieters tel : +31 6 1850 1847 -------------------------------------------------------------------- Kijk ook eens op: geocool.reperion.com www.2walkeurope.eu [Non-text portions of this message have been removed]
kamel_inct+yahoo.fr on Wed Oct 03 06:53:36 2007 (link), replying to msg
oh thank you very much for answers.
dananderson2+yahoo.com on Wed Oct 03 08:46:17 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, kamel elkedrouci <kamel_inct+...> wrote: > > please can someone tell me what is the difference between: track, waypoint and route?? > Here's one way of defining them: http://www.gpsmap.net/BasicHints.html#waypointsRoutesTracks
kamel_inct+yahoo.fr on Thu Oct 04 06:02:53 2007 (link), replying to msg
how can I know that the GPX file is not modified, I mean the GPX can be edited by someone? and thanks in advanced for your answers!
martinp13+earthlink.net on Thu Oct 04 06:08:13 2007 (link), replying to msg
Other than the usual Windows modified-date and things like that, I don't think you CAN tell. It's just a text file. If you put some sort of checksum at the end you could probably tell. > Martin kamel wrote: > how can I know that the GPX file is not modified, I mean the GPX can > be edited by someone? > and thanks in advanced for your answers! > > > > > Yahoo! Groups Links > > > > >
egroups+topografix.com on Thu Oct 04 06:21:22 2007 (link), replying to msg
Hello, Thursday, October 4, 2007, 6:13:18 AM, kamel wrote: > how can I know that the GPX file is not modified, I mean the GPX can > be edited by someone? > and thanks in advanced for your answers! 1. explain why you care about this - you might get a better answer. 2. GPX editors are supposed to fill in the creator="my_program.exe" attribute at the top of the file. So if you see creator="EasyGPS 2.7" at the top of a file you created, that's a good sign someone edited it in EasyGPS. Obviously, this won't help you if someone edits it by hand. 3. you are welcome to use the gpx_modified schema as shown below: <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="GeoBuddy 2.6" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.topografix.com/GPX/gpx_style/0/2 http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd http://www.topografix.com/GPX/gpx_overlay/0/3 http://www.topografix.com/GPX/gpx_overlay/0/3/gpx_overlay.xsd http://www.topografix.com/GPX/gpx_modified/0/1 http://www.topografix.com/GPX/gpx_modified/0/1/gpx_modified.xsd http://www.topografix.com/GPX/Private/TopoGrafix/0/3 http://www.topografix.com/GPX/Private/TopoGrafix/0/3/topografix.xsd"> <metadata> <bounds minlat="43.75637555" minlon="-71.56574950" maxlat="43.76099119" maxlon="-71.55958980"/> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2007-09-25T14:49:00.361Z</time> </extensions> </metadata> -- Dan Foster
dananderson2+yahoo.com on Fri Oct 05 07:38:16 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "kamel" <kamel_inct+...> wrote: > > how can I know that the GPX file is not modified, I mean the GPX can > be edited by someone? > and thanks in advanced for your answers! > You can't tell if someone modified the file under normal circumstances. If you need to be able to tell, you would have to add an encrypted signature. A public/private key would allow people other than the creator (or whoever has the private key) to verify that it hasn't been modified.
dananderson2+yahoo.com on Fri Oct 05 07:41:37 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Dan Anderson" <dananderson2+...> wrote: > > --- In gpsxml+yahoogroups.com, "kamel" <kamel_inct+> wrote: > > > > how can I know that the GPX file is not modified, I mean the GPX can > > be edited by someone? > > and thanks in advanced for your answers! > > > You can't tell if someone modified the file under normal > circumstances. If you need to be able to tell, you would have to add > an encrypted signature. A public/private key would allow people other > than the creator (or whoever has the private key) to verify that it > hasn't been modified. > In the above I'm assuming that you don't have the original GPX file. If you have the original file, just run a difference program on the original file and the file suspected of modifications.
davidv+veeneman.com on Fri Nov 09 19:30:46 2007 (link)
I'm creating a GPX document in .NET, and I am having trouble coding the document (root) element. The document element contains an XSI namespace declaration attribute, and an xsi:schemaLocation attribute that points to the w3.org XML Schema Instance. I can't figure out how to code the xsi:schemaLocation attribute, using the XmlDocument.CreateAttribute() method. Can anyone provide sample code in either VB or C# to code the root element of a GPX document? Thanks for your help. David Veeneman Foresight Systems
niccolo.rigacci+yahoo.com on Mon Nov 26 05:49:45 2007 (link)
Hello, I wrote an utility to download tracks from a GPS based on the MTK chip (i-Blue 747 data logger). In the data log there are fields that do not accomodate into the GPX 1.1 schema, so I wrote an XML schema that extends it. Is someone interested in verifying this schema and advocacing it to be adopted for all the MTK based GPS? What is needed in my opinion: - review and test of the schema - hosting the .xsd schema on a public host (I can manage it) The schema can be downloaded from http://www.rigacci.org/gpx/MtkExtensions/v1/MtkExtensionsv1.xsd, here it is an example of a trackpoint conformant to the schema: <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.1" creator="MTKBabel - http://www.rigacci.org/" xmlns="http://www.topografix.com/GPX/1/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mtk="http://www.rigacci.org/gpx/MtkExtensions/v1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.rigacci.org/gpx/MtkExtensions/v1 http://www.rigacci.org/gpx/MtkExtensions/v1/MtkExtensionsv1.xsd"> <trk> <name>2007-11-10T07:22:05Z</name> <trkseg> <trkpt lat="43.846386908" lon="11.144756639"> <ele>76.770355</ele> <time>2007-11-17T15:39:08Z</time> <type>DISTANCE</type> <fix>3d</fix> <sat>9</sat> <hdop>1.24</hdop> <vdop>1.71</vdop> <pdop>2.11</pdop> <ageofdgpsdata>0</ageofdgpsdata> <dgpsid>0</dgpsid> <extensions> <mtk:wptExtension> <mtk:valid>sps</mtk:valid> <mtk:speed>30.236135</mtk:speed> <mtk:heading>214.934341</mtk:heading> <mtk:satinview>12</mtk:satinview> <mtk:satdata sid="22" inuse="1"> <mtk:elevation>55</mtk:elevation> <mtk:azimuth>142</mtk:azimuth> <mtk:snr>51</mtk:snr> </mtk:satdata> <mtk:msec>0</mtk:msec> <mtk:distance>16.526905474</mtk:distance> </mtk:wptExtension> </extensions> </trkpt> </trkseg> </trk> </gpx>
robertlipe+usa.net on Tue Nov 27 10:46:42 2007 (link)
> Is someone interested in verifying this schema and advocacing it to be > adopted for all the MTK based GPS? At a glance, very little of this is actually MTK-specific at all; it's closer to "raw" NMEA capture, right? There have been discussions on this list (long ago) about formalizing such a scheme, but there wasn't a lot of interest as very few of the programs represented here actually care how many satellites are in view when a trackpoint was captured. Most of us that care about things like distance and speed have to have the code to calculate it from the collected points any for those data sets that don't have these extensions, so there wasn't a strong motive to spiff it up. There are lots of niche extensions to GPX. They invariably get lost when sending through programs that don't process them, but in niche markets, you often control the reader and the writer, so that's OK. At a glance, your schema looks OK. If it solves a problem for you, go for it. RJL
egroups+topografix.com on Tue Nov 27 11:07:24 2007 (link), replying to msg
Hello, Tuesday, November 27, 2007, 1:46:35 PM, Robert wrote: >> Is someone interested in verifying this schema and advocacing it to be >> adopted for all the MTK based GPS? > > At a glance, very little of this is actually MTK-specific at all; it's > closer to "raw" NMEA capture, right? Yes, please don't call your schema "MTK" - try to create something as generic and reusable as possible. Put the satellite positioning stuff in a schema called "satellite positioning stuff". If there's really something MTK-specific, put THAT in a schema called MTK. For an example of putting generic stuff in a non-generic schema, please see the Garmin GPX extensions: http://www8.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd All of the POI/Address stuff could have been put into a generic POI schema. Depth and Temperature aren't Garmin-specific, either. If everyone puts the same generic values in their own private schemas, the whole point of GPX being an extensible exchange format is lost. -- Dan Foster
textbin+gmail.com on Wed Dec 12 13:20:22 2007 (link)
I am using .NET Frameworks xsd.exe to generate classes for both the 1.1 and 1.0 version of the gpx.xsd. I am not sure how to quickly tell which class I should use to read a given .gpx file. What is the quickest way to determine what version of .XSD to use with a given GPX file?
ren_at_work+hotmail.com on Wed Dec 12 13:20:52 2007 (link)
Hi, I'm just starting reading GPX data with PHP. I've played with XML before but I'm not a PHP expert by a long shot. I've been able to dump Garmin Training Center files (XML based) into MySQL tables but I'm stuck with GPX. How do I read the first waypoint line where both lat and lon are within the < >? <wpt lat="42.443904" lon="-71.122044"> <ele>50.594727</ele> <time>2001-11-28T21:05:28Z</time> <name>5142</name> <desc>5142</desc> <sym>Dot</sym> <type>Dot</type> </wpt> Any pointers to some PHP source code would be welcome. thanks, Ren
robertlipe+usa.net on Wed Dec 12 17:59:37 2007 (link)
> Or are you reading the file as a text file and rolling your own XML If you are, you're headed down a bad path. If you don't know what XML attributes are, you don't want to be parsing XML. Use an XML parsing library; don't tread them as text with funny brackets.
ren_at_work+hotmail.com on Thu Dec 13 05:25:12 2007 (link), replying to msg
passing funny brackets? sounds very painful indeed I've put the source I'm using in the files section "garmin_tcx_simple_parser.php" Its adapted from a tutorial I found here http://www.kirupa.com/web/xml_php_parse_intermediate.htm as mentioned in my first post it works fine with Garmins files. If I could be pointed in the right direction for parsing GPX I'd be grateful. --- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+...> wrote: > > > > Or are you reading the file as a text file and rolling your own XML > > > If you are, you're headed down a bad path. If you don't know what XML > attributes are, you don't want to be parsing XML. Use an XML parsing > library; don't tread them as text with funny brackets. >
salcedo+yahoo.com on Thu Dec 13 09:16:55 2007 (link), replying to msg
I'm not a PHP programmer either, but I did find that PHP 5 has an extension named SimpleXML. And as the name implies, it certainly looks like it simplifies XML parsing. It does handle attributes, though it is unclear whether it can handle an empty tag, where you open and close the element in a single tag. http://www.php.net/simplexml --- In gpsxml+yahoogroups.com, "Ren" <ren_at_work+...> wrote: > > passing funny brackets? > sounds very painful indeed > > I've put the source I'm using in the files section > > "garmin_tcx_simple_parser.php" > > Its adapted from a tutorial I found here > http://www.kirupa.com/web/xml_php_parse_intermediate.htm > as mentioned in my first post it works fine with Garmins files. > > If I could be pointed in the right direction for parsing GPX I'd be > grateful. > > > > > --- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+> wrote: > > > > > > > Or are you reading the file as a text file and rolling your own XML > > > > > > If you are, you're headed down a bad path. If you don't know what XML > > attributes are, you don't want to be parsing XML. Use an XML parsing > > library; don't tread them as text with funny brackets. > > >
ren_at_work+hotmail.com on Thu Dec 13 10:35:34 2007 (link), replying to msg
Thanks for your input! I found some code to deal with things like <animals pets="dogs">5</animals> <animals pets="cats">3</animals> and it relied on SimpleXML to pick up on dogs or cats and then parse the appropriate number I also just found WampServer http://www.wampserver.com/en/index.php which lets you switch between Apache/PHP/SQL versions on the fly. I'll have a play SimpleXML but like everything, I'd like to waste as little time on the learning process if someone out there could share some code or point to a good resource I'd be grateful. I mean I would guess most people on the list are already doing what I am trying to do. Saving my brain for my daytime work would nice (he says typing at 3:30am) --- In gpsxml+yahoogroups.com, "Ricardo" <salcedo+...> wrote: > > I'm not a PHP programmer either, but I did find that PHP 5 has an > extension named SimpleXML. And as the name implies, it certainly > looks like it simplifies XML parsing. It does handle attributes, > though it is unclear whether it can handle an empty tag, where you > open and close the element in a single tag. > > http://www.php.net/simplexml > > > > --- In gpsxml+yahoogroups.com, "Ren" <ren_at_work+> wrote: > > > > passing funny brackets? > > sounds very painful indeed > > > > I've put the source I'm using in the files section > > > > "garmin_tcx_simple_parser.php" > > > > Its adapted from a tutorial I found here > > http://www.kirupa.com/web/xml_php_parse_intermediate.htm > > as mentioned in my first post it works fine with Garmins files. > > > > If I could be pointed in the right direction for parsing GPX I'd be > > grateful. > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+> wrote: > > > > > > > > > > Or are you reading the file as a text file and rolling your own > XML > > > > > > > > > If you are, you're headed down a bad path. If you don't know > what XML > > > attributes are, you don't want to be parsing XML. Use an XML parsing > > > library; don't tread them as text with funny brackets. > > > > > >
sunburnedsurveyor+yahoo.com on Thu Dec 13 13:36:57 2007 (link)
I'm a hobby Java GIS Programmer. I've been thinking about writing some simple tools to work with GPS Waypoints. It looks like GPX is the logical format to use, but I had a couple questions. Are there any open source libraries that support reading and writing GPX? Do Garmin GPS receivers export GPX directly? (I'm guessing this isn't the case.) If not, what format can I get wapoints in from a Garmin receiver that would be the most easily converted to GPX, and is there a open source programming library that will do this conversion? I'm just trying to avoid writing existing code from scratch. The Sunburned Surveyor
ren_at_work+hotmail.com on Fri Dec 14 11:23:05 2007 (link), replying to msg
Looks like Flash is the easier way to go. I'll tweak this example later ///////////////////////////////////////// var doc:XML = new XML("<mytag name='Val'> item </mytag>"); trace(doc.firstChild.attributes.name); // Val doc.firstChild.attributes.order = "first"; trace (doc.firstChild); // <mytag order="first" name="Val"> item </mytag> for (attr in doc.firstChild.attributes) { trace (attr + " = " + doc.firstChild.attributes[attr]); } // order = first // name = Val ///////////////////////////////////////// lay it in a homepage with PHP and hook it to MySQL. all I'm looking to do is 1 - read in trackpoints from a GPX file (that was massaged in ExpertGPX) 2 - retime the trackspoints (courses in Garmin jargon) based on distance 3 - dump out the retimed "course" as a Garmin training center file 4 - up it to my FR305 5 - go out and hike it might be interesting to adjust the retiming based on gradient or split the file into laps according to key waypoints the bottleneck is step 1 - the rest is easy to do with my current knowledge of PHP
ren_at_work+hotmail.com on Fri Dec 14 11:23:06 2007 (link), replying to msg
Added the following files to the files section flash_GPX_parser.txt flash_GPX_sample.gpx (co-ordinates have been changed to protect the innocent) copy and paste the script into the first frame of a Flash timeline. export to Flash only and the trace window will blurt out trackpoint data. more details in the script body its just a quick start and nothing too complex search strings: macromedia flash adobe actionscript script gpx parse xml
ren_at_work+hotmail.com on Fri Dec 14 15:22:47 2007 (link), replying to msg
> Added the following files to the files section > flash_GPX_parser.txt > flash_GPX_sample.gpx Now outputs trackpoint data suitable for pasting into a Garmin Traning Center course file - suitable for uploading to your Forerunner 305 or similar. You do need Adobe Flash (the authoring app) to be able to run the sripts. I'll tweak it as time permits - maybe a stand alone or web based application to eat ExpertGPS or other GPX files and spit out courses for Garmin sports/fitness GPS range. search strings: macromedia flash adobe actionscript script gpx parse xml garmin forerunner
yahoo+slacy.com on Fri Dec 14 16:26:05 2007 (link), replying to msg
As has been previously mentioned, XML parsing is fairly difficult, but PHP has reasonable library support for it. Check out the docs at http://us.php.net/xml Here's a very simple example script that will print out all the LAT and LON attributes for all the waypoints in a file. This is a very rudimentary example, but hopefully it'll be a good starting point. Parsing GPX in Flash feels like jumping through a few too many hoops for my taste. Here's the script: <html> <body> <?php $file = "20070107.gpx"; $depth = array(); function startElement($parser, $name, $attrs) { if ($name == "TRKPT") { $lat = $attrs{"LAT"}; $lon = $attrs{"LON"}; print "LAT=$lat LON=$lon<br/>"; } } function endElement($parser, $name) { } $xml_parser = xml_parser_create(); xml_set_element_handler($xml_parser, "startElement", "endElement"); if (!($fp = fopen($file, "r"))) { die("could not open XML input"); } while ($data = fread($fp, 4096)) { if (!xml_parse($xml_parser, $data, feof($fp))) { die(sprintf("XML error: %s at line %d", xml_error_string(xml_get_error_code($xml_parser)), xml_get_current_line_number($xml_parser))); } } xml_parser_free($xml_parser); ?> </body> </html> Steve On Dec 13, 2007 10:33 AM, Ren <ren_at_work+hotmail.com> wrote: > > > > > > > Thanks for your input! > > I found some code to deal with things like > <animals pets="dogs">5</animals> > <animals pets="cats">3</animals> > and it relied on SimpleXML to pick up on dogs or cats and then parse > the appropriate number > > I also just found WampServer > http://www.wampserver.com/en/index.php > which lets you switch between Apache/PHP/SQL versions on the fly. > > I'll have a play SimpleXML but like everything, I'd like to waste as > little time on the learning process if someone out there could share > some code or point to a good resource I'd be grateful. > > I mean I would guess most people on the list are already doing what I > am trying to do. > Saving my brain for my daytime work would nice (he says typing at 3:30am) > > > > --- In gpsxml+yahoogroups.com, "Ricardo" <salcedo+...> wrote: > > > > I'm not a PHP programmer either, but I did find that PHP 5 has an > > extension named SimpleXML. And as the name implies, it certainly > > looks like it simplifies XML parsing. It does handle attributes, > > though it is unclear whether it can handle an empty tag, where you > > open and close the element in a single tag. > > > > http://www.php.net/simplexml > > > > > > > > --- In gpsxml+yahoogroups.com, "Ren" <ren_at_work+> wrote: > > > > > > passing funny brackets? > > > sounds very painful indeed > > > > > > I've put the source I'm using in the files section > > > > > > "garmin_tcx_simple_parser.php" > > > > > > Its adapted from a tutorial I found here > > > http://www.kirupa.com/web/xml_php_parse_intermediate.htm > > > as mentioned in my first post it works fine with Garmins files. > > > > > > If I could be pointed in the right direction for parsing GPX I'd be > > > grateful. > > > > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+> wrote: > > > > > > > > > > > > > Or are you reading the file as a text file and rolling your own > > XML > > > > > > > > > > > > If you are, you're headed down a bad path. If you don't know > > what XML > > > > attributes are, you don't want to be parsing XML. Use an XML > parsing > > > > library; don't tread them as text with funny brackets. > > > > > > > > > > >
mhoegh+gmail.com on Sat Dec 15 04:30:45 2007 (link), replying to msg
Take a look at sourceforge.net/projects/appformap/ In the source tree you can find a lib, which can parse gpx and output a sql for inserting the data in a databata or the data as html. You could easily rewrite for other outputs. Get the lib here: http://appformap.cvs.sourceforge.net/appformap/appformap/libs/php_gpxtopgsql_class.php?revision=1.5&view=markup I'm using the lib for www.toposhare.org (or test.toposhare.org) which is all open source /martin --- In gpsxml+yahoogroups.com, "Steve Lacy" <yahoo+...> wrote: > > As has been previously mentioned, XML parsing is fairly difficult, but > PHP has reasonable library support for it. Check out the docs at > > http://us.php.net/xml > > Here's a very simple example script that will print out all the LAT > and LON attributes for all the waypoints in a file. This is a very > rudimentary example, but hopefully it'll be a good starting point. > Parsing GPX in Flash feels like jumping through a few too many hoops > for my taste. Here's the script: > > <html> > <body> > <?php > $file = "20070107.gpx"; > $depth = array(); > > function startElement($parser, $name, $attrs) > { > if ($name == "TRKPT") { > $lat = $attrs{"LAT"}; > $lon = $attrs{"LON"}; > print "LAT=$lat LON=$lon<br/>"; > } > } > > function endElement($parser, $name) { } > > $xml_parser = xml_parser_create(); > xml_set_element_handler($xml_parser, "startElement", "endElement"); > > if (!($fp = fopen($file, "r"))) { > die("could not open XML input"); > } > > while ($data = fread($fp, 4096)) { > if (!xml_parse($xml_parser, $data, feof($fp))) { > die(sprintf("XML error: %s at line %d", > xml_error_string(xml_get_error_code($xml_parser)), > xml_get_current_line_number($xml_parser))); > } > } > xml_parser_free($xml_parser); > ?> > </body> > </html> > > > Steve > > On Dec 13, 2007 10:33 AM, Ren <ren_at_work+...> wrote: > > > > > > > > > > > > > > Thanks for your input! > > > > I found some code to deal with things like > > <animals pets="dogs">5</animals> > > <animals pets="cats">3</animals> > > and it relied on SimpleXML to pick up on dogs or cats and then parse > > the appropriate number > > > > I also just found WampServer > > http://www.wampserver.com/en/index.php > > which lets you switch between Apache/PHP/SQL versions on the fly. > > > > I'll have a play SimpleXML but like everything, I'd like to waste as > > little time on the learning process if someone out there could share > > some code or point to a good resource I'd be grateful. > > > > I mean I would guess most people on the list are already doing what I > > am trying to do. > > Saving my brain for my daytime work would nice (he says typing at 3:30am) > > > > > > > > --- In gpsxml+yahoogroups.com, "Ricardo" <salcedo+> wrote: > > > > > > I'm not a PHP programmer either, but I did find that PHP 5 has an > > > extension named SimpleXML. And as the name implies, it certainly > > > looks like it simplifies XML parsing. It does handle attributes, > > > though it is unclear whether it can handle an empty tag, where you > > > open and close the element in a single tag. > > > > > > http://www.php.net/simplexml > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Ren" <ren_at_work+> wrote: > > > > > > > > passing funny brackets? > > > > sounds very painful indeed > > > > > > > > I've put the source I'm using in the files section > > > > > > > > "garmin_tcx_simple_parser.php" > > > > > > > > Its adapted from a tutorial I found here > > > > http://www.kirupa.com/web/xml_php_parse_intermediate.htm > > > > as mentioned in my first post it works fine with Garmins files. > > > > > > > > If I could be pointed in the right direction for parsing GPX I'd be > > > > grateful. > > > > > > > > > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+> wrote: > > > > > > > > > > > > > > > > Or are you reading the file as a text file and rolling your own > > > XML > > > > > > > > > > > > > > > If you are, you're headed down a bad path. If you don't know > > > what XML > > > > > attributes are, you don't want to be parsing XML. Use an XML > > parsing > > > > > library; don't tread them as text with funny brackets. > > > > > > > > > > > > > > > > >
ren_at_work+hotmail.com on Sat Dec 15 05:39:11 2007 (link), replying to msg
Steve, Martin, thanks for your input, definately what I'm looking for! I'll be sure to have a go at php again once I get the time. > >Parsing GPX in Flash feels like jumping through a few too many hoops > > for my taste. I partially agree. The future may hold simple maps and trackpoint/track playback. Depends on how much free time I get. Take a look at this company's software for thier GPS system. http://www.frwd.fi/index.php?33 Allows you to playback tracks for virtual competitions. "Virtual competitions between friends can be organized by sending performances by e-mail." cheeky sods who can edit GPX data may also be able to cheat LOL cheers, Ren --- In gpsxml+yahoogroups.com, "mhoeghgmailcom" <mhoegh+...> wrote: > > Take a look at sourceforge.net/projects/appformap/ > > In the source tree you can find a lib, which can parse gpx and output > a sql for inserting the data in a databata or the data as html. You > could easily rewrite for other outputs. > > Get the lib here: > > http://appformap.cvs.sourceforge.net/appformap/appformap/libs/php_gpxtopgsql_class.php?revision=1.5&view=markup > > I'm using the lib for www.toposhare.org (or test.toposhare.org) which > is all open source > > /martin > > > --- In gpsxml+yahoogroups.com, "Steve Lacy" <yahoo+> wrote: > > > > As has been previously mentioned, XML parsing is fairly difficult, but > > PHP has reasonable library support for it. Check out the docs at > > > > http://us.php.net/xml > > > > Here's a very simple example script that will print out all the LAT > > and LON attributes for all the waypoints in a file. This is a very > > rudimentary example, but hopefully it'll be a good starting point. > > Parsing GPX in Flash feels like jumping through a few too many hoops > > for my taste. Here's the script: > > > > <html> > > <body> > > <?php > > $file = "20070107.gpx"; > > $depth = array(); > > > > function startElement($parser, $name, $attrs) > > { > > if ($name == "TRKPT") { > > $lat = $attrs{"LAT"}; > > $lon = $attrs{"LON"}; > > print "LAT=$lat LON=$lon<br/>"; > > } > > } > > > > function endElement($parser, $name) { } > > > > $xml_parser = xml_parser_create(); > > xml_set_element_handler($xml_parser, "startElement", "endElement"); > > > > if (!($fp = fopen($file, "r"))) { > > die("could not open XML input"); > > } > > > > while ($data = fread($fp, 4096)) { > > if (!xml_parse($xml_parser, $data, feof($fp))) { > > die(sprintf("XML error: %s at line %d", > > xml_error_string(xml_get_error_code($xml_parser)), > > xml_get_current_line_number($xml_parser))); > > } > > } > > xml_parser_free($xml_parser); > > ?> > > </body> > > </html> > > > > > > Steve > > > > On Dec 13, 2007 10:33 AM, Ren <ren_at_work+> wrote: > > > > > > > > > > > > > > > > > > > > > Thanks for your input! > > > > > > I found some code to deal with things like > > > <animals pets="dogs">5</animals> > > > <animals pets="cats">3</animals> > > > and it relied on SimpleXML to pick up on dogs or cats and then parse > > > the appropriate number > > > > > > I also just found WampServer > > > http://www.wampserver.com/en/index.php > > > which lets you switch between Apache/PHP/SQL versions on the fly. > > > > > > I'll have a play SimpleXML but like everything, I'd like to waste as > > > little time on the learning process if someone out there could share > > > some code or point to a good resource I'd be grateful. > > > > > > I mean I would guess most people on the list are already doing what I > > > am trying to do. > > > Saving my brain for my daytime work would nice (he says typing at > 3:30am) > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Ricardo" <salcedo+> wrote: > > > > > > > > I'm not a PHP programmer either, but I did find that PHP 5 has an > > > > extension named SimpleXML. And as the name implies, it certainly > > > > looks like it simplifies XML parsing. It does handle attributes, > > > > though it is unclear whether it can handle an empty tag, where you > > > > open and close the element in a single tag. > > > > > > > > http://www.php.net/simplexml > > > > > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Ren" <ren_at_work+> wrote: > > > > > > > > > > passing funny brackets? > > > > > sounds very painful indeed > > > > > > > > > > I've put the source I'm using in the files section > > > > > > > > > > "garmin_tcx_simple_parser.php" > > > > > > > > > > Its adapted from a tutorial I found here > > > > > http://www.kirupa.com/web/xml_php_parse_intermediate.htm > > > > > as mentioned in my first post it works fine with Garmins files. > > > > > > > > > > If I could be pointed in the right direction for parsing GPX > I'd be > > > > > grateful. > > > > > > > > > > > > > > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+> wrote: > > > > > > > > > > > > > > > > > > > Or are you reading the file as a text file and rolling > your own > > > > XML > > > > > > > > > > > > > > > > > > If you are, you're headed down a bad path. If you don't know > > > > what XML > > > > > > attributes are, you don't want to be parsing XML. Use an XML > > > parsing > > > > > > library; don't tread them as text with funny brackets. > > > > > > > > > > > > > > > > > > > > > > > >
yahoo+slacy.com on Fri Dec 21 17:38:04 2007 (link), replying to msg
I've been playing around some more with reading GPX in PHP, and found that PHP has a very nice "SimpleXML" support. Here's some even simpler code for printing out waypoints. Note that this code reads the whole file into memory for processing, so if your files are very large (Megabytes) then you may have issues. I suspect that most GPX files are small (hundreds of KB at most). <?php $gpx = simplexml_load_file("20061228.gpx"); foreach ($gpx->wpt as $wpt) { $attrs = $wpt->attributes(); $lat = $attrs['lat']; $lon = $attrs['lon']; print "Waypoint: $lat $lon<br/>\n"; } ?> And you can print out tracks like this: <?php foreach ($gpx->trk as $trk) { print "Begin track \"$trk->name\"<br/>\n"; foreach ($trk->trkseg as $trkseg) { print "Begin track segment<br/>\n"; foreach ($trkseg->trkpt as $trkpt) { $attrs = $trkpt->attributes(); $lat = $attrs["lat"]; $lon = $attrs["lon"]; print "point: $trkpt->time $lat $lon $trkpt->ele<br/>\n"; } } } ?> Routes should be similarly easy. It doesn't get much simpler than that. You hardly need a GPX library. :) Steve On Dec 15, 2007 5:10 AM, Ren <ren_at_work+hotmail.com> wrote: > > > > > > > Steve, Martin, > thanks for your input, definately what I'm looking for! > > I'll be sure to have a go at php again once I get the time. > > > > >Parsing GPX in Flash feels like jumping through a few too many hoops > > > for my taste. > I partially agree. > The future may hold simple maps and trackpoint/track playback. > Depends on how much free time I get. > Take a look at this company's software for thier GPS system. > http://www.frwd.fi/index.php?33 > Allows you to playback tracks for virtual competitions. > > "Virtual competitions between friends can be organized by sending > performances by e-mail." > cheeky sods who can edit GPX data may also be able to cheat LOL > > cheers, > > Ren > > > > --- In gpsxml+yahoogroups.com, "mhoeghgmailcom" <mhoegh+...> wrote: > > > > Take a look at sourceforge.net/projects/appformap/ > > > > In the source tree you can find a lib, which can parse gpx and output > > a sql for inserting the data in a databata or the data as html. You > > could easily rewrite for other outputs. > > > > Get the lib here: > > > > > > http://appformap.cvs.sourceforge.net/appformap/appformap/libs/php_gpxtopgsql_class.php?revision=1.5&view=markup > > > > I'm using the lib for www.toposhare.org (or test.toposhare.org) which > > is all open source > > > > /martin > > > > > > --- In gpsxml+yahoogroups.com, "Steve Lacy" <yahoo+> wrote: > > > > > > As has been previously mentioned, XML parsing is fairly difficult, but > > > PHP has reasonable library support for it. Check out the docs at > > > > > > http://us.php.net/xml > > > > > > Here's a very simple example script that will print out all the LAT > > > and LON attributes for all the waypoints in a file. This is a very > > > rudimentary example, but hopefully it'll be a good starting point. > > > Parsing GPX in Flash feels like jumping through a few too many hoops > > > for my taste. Here's the script: > > > > > > <html> > > > <body> > > > <?php > > > $file = "20070107.gpx"; > > > $depth = array(); > > > > > > function startElement($parser, $name, $attrs) > > > { > > > if ($name == "TRKPT") { > > > $lat = $attrs{"LAT"}; > > > $lon = $attrs{"LON"}; > > > print "LAT=$lat LON=$lon<br/>"; > > > } > > > } > > > > > > function endElement($parser, $name) { } > > > > > > $xml_parser = xml_parser_create(); > > > xml_set_element_handler($xml_parser, "startElement", "endElement"); > > > > > > if (!($fp = fopen($file, "r"))) { > > > die("could not open XML input"); > > > } > > > > > > while ($data = fread($fp, 4096)) { > > > if (!xml_parse($xml_parser, $data, feof($fp))) { > > > die(sprintf("XML error: %s at line %d", > > > xml_error_string(xml_get_error_code($xml_parser)), > > > xml_get_current_line_number($xml_parser))); > > > } > > > } > > > xml_parser_free($xml_parser); > > > ?> > > > </body> > > > </html> > > > > > > > > > Steve > > > > > > On Dec 13, 2007 10:33 AM, Ren <ren_at_work+> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your input! > > > > > > > > I found some code to deal with things like > > > > <animals pets="dogs">5</animals> > > > > <animals pets="cats">3</animals> > > > > and it relied on SimpleXML to pick up on dogs or cats and then > parse > > > > the appropriate number > > > > > > > > I also just found WampServer > > > > http://www.wampserver.com/en/index.php > > > > which lets you switch between Apache/PHP/SQL versions on the fly. > > > > > > > > I'll have a play SimpleXML but like everything, I'd like to > waste as > > > > little time on the learning process if someone out there could > share > > > > some code or point to a good resource I'd be grateful. > > > > > > > > I mean I would guess most people on the list are already doing > what I > > > > am trying to do. > > > > Saving my brain for my daytime work would nice (he says typing at > > 3:30am) > > > > > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Ricardo" <salcedo+> wrote: > > > > > > > > > > I'm not a PHP programmer either, but I did find that PHP 5 has an > > > > > extension named SimpleXML. And as the name implies, it certainly > > > > > looks like it simplifies XML parsing. It does handle attributes, > > > > > though it is unclear whether it can handle an empty tag, > where you > > > > > open and close the element in a single tag. > > > > > > > > > > http://www.php.net/simplexml > > > > > > > > > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Ren" <ren_at_work+> wrote: > > > > > > > > > > > > passing funny brackets? > > > > > > sounds very painful indeed > > > > > > > > > > > > I've put the source I'm using in the files section > > > > > > > > > > > > "garmin_tcx_simple_parser.php" > > > > > > > > > > > > Its adapted from a tutorial I found here > > > > > > http://www.kirupa.com/web/xml_php_parse_intermediate.htm > > > > > > as mentioned in my first post it works fine with Garmins files. > > > > > > > > > > > > If I could be pointed in the right direction for parsing GPX > > I'd be > > > > > > grateful. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+> > wrote: > > > > > > > > > > > > > > > > > > > > > > Or are you reading the file as a text file and rolling > > your own > > > > > XML > > > > > > > > > > > > > > > > > > > > > If you are, you're headed down a bad path. If you don't know > > > > > what XML > > > > > > > attributes are, you don't want to be parsing XML. Use an XML > > > > parsing > > > > > > > library; don't tread them as text with funny brackets. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
mr+marcelruff.info on Sat Dec 29 04:24:47 2007 (link)
Hi, is there a tiny open source lib for GPX for languages Java and Javascript available which can import&export XML and Json? Why is there no speed and course available in GPX 1.1? Thanks Marcel http://watchee.net
allnight4+yahoo.com on Sat Dec 29 04:30:48 2007 (link)
Anybody know of a GPX editor? I'm taking pics at my in-laws, and want to tag the photos with the geo info. Problem is, I haven't had the gps receiver running the whole time I've been here, and even forgot to take it with us on a couple of local adventures. So, I want to craft a gpx file that GPicSync will read to add the geo info to the photos. I (think I) understand the gpx file format well enough, after my first attempt failed. I added waypoints to the gpx file, and then GPicSync still didn't add the tags. Then I read up on gpx a bit, and realized it was because I hadn't supplied a track that covered the time stamps of the photos. Rather than go through the pain of manually coordinating the waypoints and track entries, I figured I'd look for an editor, or write one if needed. Of course, I'd rather not write it if someone else has :) If anyone can point me in any useful directions toward existing tools/code, it would be much appreciated. Mike (The GPS receiver I'm using is a Super TrackStick, and the photos are coming from various cameras: Sony, Nikon and Canon point and shoot, and a Canon DSLR.)
mr+marcelruff.info on Sat Dec 29 04:31:26 2007 (link)
Hi, is there any free and tiny library to parse and dump GPX 1.1 from/to Java and Javascript with XML and Json and NMEA format? Why is there no markup for speed or course? Is it correct that the NMEA lat/lon is in another format than the GPX format? thanks Marcel
kamel_inct+yahoo.fr on Sat Dec 29 05:38:48 2007 (link)
please, can someone tell me how to upload a gpx file with php? thanks in advance
bobmcm+swbell.net on Sat Dec 29 07:53:42 2007 (link), replying to msg
While it's not an editor, you might want to look at Robogeo. Since you seem to know the locations that the pictures where taken, it will allow you geocode the picture via google earth. It will allow you to select the picture, and then brings up Google earth add allows you to scroll around to mark your pictures. Probably faster than trying to get the locations in a route file with the timestamps correct, etc. Check it out at www.robogeo.com . It runs $50 buck, and is well worth the price. Robert McMahan -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Mike Peck Sent: Friday, December 28, 2007 11:07 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] GPX editor? Anybody know of a GPX editor? I'm taking pics at my in-laws, and want to tag the photos with the geo info. Problem is, I haven't had the gps receiver running the whole time I've been here, and even forgot to take it with us on a couple of local adventures. So, I want to craft a gpx file that GPicSync will read to add the geo info to the photos. I (think I) understand the gpx file format well enough, after my first attempt failed. I added waypoints to the gpx file, and then GPicSync still didn't add the tags. Then I read up on gpx a bit, and realized it was because I hadn't supplied a track that covered the time stamps of the photos. Rather than go through the pain of manually coordinating the waypoints and track entries, I figured I'd look for an editor, or write one if needed. Of course, I'd rather not write it if someone else has :) If anyone can point me in any useful directions toward existing tools/code, it would be much appreciated. Mike (The GPS receiver I'm using is a Super TrackStick, and the photos are coming from various cameras: Sony, Nikon and Canon point and shoot, and a Canon DSLR.) Yahoo! Groups Links
bobmcm+swbell.net on Sat Dec 29 07:54:57 2007 (link), replying to msg
Oppa. I meant $40 bucks ($39.95). Robert McMahan -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Mike Peck Sent: Friday, December 28, 2007 11:07 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] GPX editor? Anybody know of a GPX editor? I'm taking pics at my in-laws, and want to tag the photos with the geo info. Problem is, I haven't had the gps receiver running the whole time I've been here, and even forgot to take it with us on a couple of local adventures. So, I want to craft a gpx file that GPicSync will read to add the geo info to the photos. I (think I) understand the gpx file format well enough, after my first attempt failed. I added waypoints to the gpx file, and then GPicSync still didn't add the tags. Then I read up on gpx a bit, and realized it was because I hadn't supplied a track that covered the time stamps of the photos. Rather than go through the pain of manually coordinating the waypoints and track entries, I figured I'd look for an editor, or write one if needed. Of course, I'd rather not write it if someone else has :) If anyone can point me in any useful directions toward existing tools/code, it would be much appreciated. Mike (The GPS receiver I'm using is a Super TrackStick, and the photos are coming from various cameras: Sony, Nikon and Canon point and shoot, and a Canon DSLR.) Yahoo! Groups Links
allnight4+yahoo.com on Sat Dec 29 08:43:56 2007 (link), replying to msg
Ok, so maybe I didn't/don't understand the format as well as I thought. I re-added all the coords as track points in a track, and then GPicSync did it's tagging as I had wanted. So, what drove my initial hunt for an editor, was thinking that track points and way points had to be synchronized, and I wanted something that would take care of that for me. Since they don't, just what are waypoints for? I ended up using an xml editor, called XMLEditor (got there from the post about NUVI's on: http://www.google.com/search?hl=en&q=xmleditor+pavel+ugoltsev&btnG=Search) The hilighting was nice, and the tree view of the elements on the left helped as well, although I haven't figured out how to make it update & reparse the xml after making major changes. If anyone cares to explain what waypoints are for, I'd love to hear it. I understand that tracks are for where you've actually been, and routes are for where you are planning to go...so what's a waypoint for? Thanks again
kerry.raymond+gmail.com on Sat Dec 29 13:28:08 2007 (link)
A waypoint is a named point. Points in tracks and routes are anonymous. Track points have timestamps because they are a record of an actual journey; route points don't have timestamps as they are a journey in abstract. Waypoint may or may not have timestamps, depending on whether they represent a place we've been or a place we want to go to (we don't seem to thave a different name that reflects that distinction). Having said that, it is a perennial mystery to me why we model waypoints, tracks and routes so badly and therefore why software works with them so badly. Clearly they have a lot in common, yet a lot of software out that that works with (say) a track won't work with a set of waypoints and or a mix of waypoints and tracks. Of course a set of waypoints may not represent a journey, but if I want to assert that it does and have them treated like a track, I can't do that. Grrr! Kerry [Non-text portions of this message have been removed]
robertlipe+usa.net on Sat Dec 29 19:41:19 2007 (link)
> Having said that, it is a perennial mystery to me why we model waypoints, tracks and routes so badly and therefore why software works with them so badly. Who is "we" in that sentence? "GPX"? I came in fairly late in GPX 1.0, but we were trying to institutionalize what GPSes of the era did. They drew strong lines between them so we did, too. FWIW, contemporary GPSes and most programs still draw those same distinctions. I remember thinking at the time that tracks and routes were "merely" sequenced position points that just happened to prefer different types of optional data. My design of the internals of GPSBabel reflects that - routes and tracks are linked lists of points. > if I want to assert that it does and have them treated like a track, I can't do that. Grrr! http://www.gpsbabel.org/htmldoc-development/filter_transform.html ...but it does have a bit of an alchemy problem. If you try to convert routes (which don't normally contain timestamps) to tracks (which do) and then feed them to a program like a geocoder that expected to find timestamps, GPSBabel offers you a victory only in principle: you've converted the route to a track that the consuming program may recognize as a track, but it has "missing" data. Of course, that same program would fail on a saved Garmin track which tosses timestamps from tracks, too.
TomBudlong+RoadRunner.com on Sat Dec 29 19:45:16 2007 (link)
Grr, double Grr. Omitting timestamps from any of waypoints, tracks, routes is a monumental design error, considering how cheap it is to store data these days. I ran onto this trying to automate photo locations. One clumsy way to do this is to take a photo and a GPS point at the same time, then let software attach the photo number to the waypoint by examining the time stamp on each. But if the GPS point does not have a time stamp, well, so much for that idea. To further the frustration, the latest Garmins, and others, have electronic compasses, so they could record direction with the point. But, they don't. Go figure. What genius decided to do that, especially in consideration that 2GB cards cost a few tens of dollars these days. And anyway, it's a clumsy solution even without that problem. What we really need is a good camera with a built-in GPS, and an aware product manager that can tell the engineers to put all the data in the waypoint, GPS. Anybody know of one coming along? If we can put GPS locators in cell phones, ... I do a lot of field recording - photo, photo direction, time, hand notes. Right now I spend more time back on the computer integrating these data - laborious, frustrating and error-prone. In this world of gadgets, I expect such a gadget sometime. Sooner the better. ... Tom Budlong
robertlipe+usa.net on Sat Dec 29 19:48:46 2007 (link)
> Omitting timestamps from any of waypoints, tracks, routes is a > monumental design error, considering how cheap it is to store data these Fortunately, it's not one this group committed. Time is an optional member of all three. Why optional? Because a lot of our source formats don't have it. But I share your frustration at the devices that discard data they obviously "know". When GPSes with 8MB of memory were monsters, it may have made some sense. With 2GB of flash going for about $15 OTC in single piece pricing, it doesn't make sense to me, either. RJL
robertlipe+usa.net on Sat Dec 29 20:18:21 2007 (link)
> And altitude ! Why in heaven's name don't Garmin's units log the > altitude when they log track points ? They show it on the display. They are in active tracks. The units that can log straight to GPX (yay!) get this right. It's just the units with the concept of "saved tracks" that toss timestamp, altitude, and most intervening points. http://www.gpsfaqs.org/faqs/garmin/xseries/g60csx/tracks.html#notime
kaz+okuda.ca on Sun Dec 30 01:34:59 2007 (link), replying to msg
> is there any free and tiny library to parse and > dump GPX 1.1 from/to Java and Javascript with XML and > Json and NMEA format? > I have written a Javascript library for parsing GPX files and showing them on a Google Map. It is pretty simple and should give you an example of how to do what you want. http://notions.okuda.ca/geotagging/projects-im-working-on/gpx-viewer/
ptomblin+gmail.com on Sun Dec 30 06:10:44 2007 (link), replying to msg
Simon Slavin wrote: > And altitude ! Why in heaven's name don't Garmin's units log the > altitude when they log track points ? They show it on the display. > The track points are logged in GPX format. It should be easy. Adding > another dimension would make such an improvement to any graphics > showing the route taken and increase purchases by climbers. I'm guessing it's because they used to use NMEA as their data exchange format. I don't know the internals, but I'm guessing the fact that the M stands for Marine means they didn't think altitude would be very important.
glen+cohvco.org on Sun Dec 30 09:49:43 2007 (link)
Does anybody know if any extensions to the gpx format exist to describe the type of trail represented by a track? An example would be an extension to describe a track as open to mountain bikes or closed to mountain bikes. Another example would be to describe a track as paved or unpaved. Thanks, Glen
coolguy982+yahoo.com on Sun Dec 30 13:21:25 2007 (link), replying to msg
Take a look at GeoTours by Geovative Solutions -- http://www.geovative.com. You can use the site for free to create a "tour" by adding locations by address, map, or lat/lon. You can then download an automatically generated GPX file of the locations in your tour. You can also upload pictures or audio to add to each location. Thanks, Scott --- In gpsxml+yahoogroups.com, "Mike Peck" <allnight4+...> wrote: > > Anybody know of a GPX editor? > > I'm taking pics at my in-laws, and want to tag the photos with the geo > info. Problem is, I haven't had the gps receiver running the whole > time I've been here, and even forgot to take it with us on a couple of > local adventures. > > So, I want to craft a gpx file that GPicSync will read to add the geo > info to the photos. > > I (think I) understand the gpx file format well enough, after my first > attempt failed. I added waypoints to the gpx file, and then GPicSync > still didn't add the tags. Then I read up on gpx a bit, and realized > it was because I hadn't supplied a track that covered the time stamps > of the photos. > > Rather than go through the pain of manually coordinating the waypoints > and track entries, I figured I'd look for an editor, or write one if > needed. Of course, I'd rather not write it if someone else has :) > > If anyone can point me in any useful directions toward existing > tools/code, it would be much appreciated. > > Mike > > (The GPS receiver I'm using is a Super TrackStick, and the photos are > coming from various cameras: Sony, Nikon and Canon point and shoot, > and a Canon DSLR.) >
dananderson2+yahoo.com on Sun Dec 30 17:48:35 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > And altitude ! Why in heaven's name don't Garmin's units log the > altitude when they log track points ? They show it on the display. > The track points are logged in GPX format. It should be easy. [snip] I don't know what model you have but the seven Garmin models I've used since the 12XL all record the elevation. The elevation is even kept in the "saved" track logs. And if you happen to have one of the models with a barometric altimeter, the unit will even show you the elevation profile of a "saved" tracklog.
dananderson2+yahoo.com on Sun Dec 30 18:04:48 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Tom Budlong <TomBudlong+...> wrote: > > Grr, double Grr. > > Omitting timestamps from any of waypoints, tracks, routes is a > monumental design error, considering how cheap it is to store data these > days. First of all, I also have a number of problems with Garmin's design and wish I had the money to do my own receiver. However, with regards to timestamps on the "saved" tracklogs note that they are not really "saved" tracklogs but processed logs reduced for a detailed trackback route. Only x,y, and z are usually saved (but depends on the model) for a detailed route. Including the timestamp could potentially lead to data errors in speed and distance traveled by software computing those values. Of course storing different data wouldn't have that problem. The actual tracklog is stored in the "active log" and contains x, y, z, and timestamps. "Saved" is not saved but usually processed and reduced.
dananderson2+yahoo.com on Sun Dec 30 18:15:06 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Dan Anderson" <dananderson2+...> wrote: > And if you happen to have one of the models with a barometric > altimeter, the unit will even show you the elevation profile of a > "saved" tracklog. Correction: The GPSmap 76S will show an elevation profile. The Vista HCx will not. The Vista HCx firmware is similar to the 60CSx and 76CSx so it's possible they won't either.
chris+ainslie.co.za on Mon Dec 31 00:56:27 2007 (link)
> So, I want to craft a gpx file that GPicSync will read to add the geo > info to the photos. 1. Set your PC clock to around the time the photos were taken. 2. Load up Mapsource. 3. Draw a track in the little area that you want to tag the photo's, making sure that you cover the date / time stamp of the photo's with that of your PC clock. 4. Save the Mapsource file to GPX Chris.
chris+ainslie.co.za on Mon Dec 31 00:56:30 2007 (link)
> In fact, most GPS units still can't work > out that information: they deduce it, very unreliably, by comparing > recent data with current data. > Simon, what do you mean by this? GPSr speed is *extremely* accurate. I don't understand your comment. Chris.
chris+ainslie.co.za on Mon Dec 31 01:30:09 2007 (link)
> It's not obvious to me the best way to produce a useful figure. I > doubt the manufacturers of the GPS units we use agree on what is the > best formula. Ah. Now at least, I understand your concern... Some interesting points. Chris.
TomBudlong+RoadRunner.com on Mon Dec 31 06:09:31 2007 (link), replying to msg
Tom Budlong wrote: > Is anyone aware that Garmin documents this stuff. > > I could take a run up the canyon with my GPS III, GPS V, and 60CSX all > humming, recording waypoints and tracks, and then dump all the data to > see what got saved. But, I have better things to do. > > If anyone from Garmin is watching, how about it. > > BTW, I still want a camera-GPS combo gadget that records waypoint > data, including altitude and bearing, and with a keyboard so I can > enter comments. With all they are cramming into miniaturized cell > phones these day, it should not be too hard. > > If anyone from Garmin is watching, how about it. Team up with Canon. > > ... Tom Budlong > > Dan Anderson wrote: >> >> --- In gpsxml+yahoogroups.com <mailto:gpsxml%40yahoogroups.com>, "Dan >> Anderson" <dananderson2+...> wrote: >> > And if you happen to have one of the models with a barometric >> > altimeter, the unit will even show you the elevation profile of a >> > "saved" tracklog. >> >> Correction: The GPSmap 76S will show an elevation profile. The Vista >> HCx will not. The Vista HCx firmware is similar to the 60CSx and 76CSx >> so it's possible they won't either. >> >>
mr+marcelruff.info on Mon Dec 31 06:09:31 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > Why is there no speed and course available in GPX 1.1? > > Because at the time GPX 1.1 was created GPS units couldn't present > that kind of information. In fact, most GPS units still can't work > out that information: they deduce it, very unreliably, by comparing > recent data with current data. > > Simon. > Thanks for your details. I think it is time to have a GPX 1.2 with such markup as above (including a tag for accuracy). Otherwise this info is cluttered in <extensions> by every user of GPX in an incompatible way. thanks Marcel http://watchee.net
mark-yahoo+foxhollow.ca on Mon Dec 31 06:09:33 2007 (link)
I belong to a club with about 2,000 members. I have their name,address, phone numbers and I have created a simple VB6 program to create a CSV file from the club data. POI Loader likes the CSV file and I am getting a nice display with all information. However... some newer Garmin units have bluetooth for cell phones. How do I link the phone number so the GPS will display the [call] button while displaying an entry? I am assuming I need to make a GPX file. Is there a nice example of a file containing name/address info that links the phone number? I can easily create the output in any XML file format that is required. I need a single simple example and I can take it from there. (Note: I have checked the net but I have not found something that links the phone number yet)
dananderson2+yahoo.com on Mon Dec 31 07:22:37 2007 (link), replying to msg
--- In gpsxml+yahoogroups.com, "mbramwel2001" <mark-yahoo+...> wrote: [snip] > However... some newer Garmin units have bluetooth for cell phones. > How do I link the phone number so the GPS will display the [call] > button while displaying an entry? > > I am assuming I need to make a GPX file. Is there a nice example of a > file containing name/address info that links the phone number? I can > easily create the output in any XML file format that is required. I > need a single simple example and I can take it from there. You put the phone number in the phone number field of Garmin's GPX schema extension. Their extension was at: http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd but I got nothing with that link so perhaps there's now a version 4 and they removed the old one. With the latest version of MapSource, try saving a GPX file and look for the schema URL in it. If you can't find it, I have a copy of GpxExtensionsv3.xsd and will post it.
glen+cohvco.org on Mon Dec 31 08:05:08 2007 (link), replying to msg
I was just looking for the Garmin extensions myself. Found them here: http://developer.garmin.com/schemas/gpxx/v3/ -Glen Dan Anderson wrote: > > --- In gpsxml+yahoogroups.com <mailto:gpsxml%40yahoogroups.com>, > "mbramwel2001" <mark-yahoo+...> wrote: > [snip] > > However... some newer Garmin units have bluetooth for cell phones. > > How do I link the phone number so the GPS will display the [call] > > button while displaying an entry? > > > > I am assuming I need to make a GPX file. Is there a nice example of a > > file containing name/address info that links the phone number? I can > > easily create the output in any XML file format that is required. I > > need a single simple example and I can take it from there. > > You put the phone number in the phone number field of Garmin's GPX > schema extension. Their extension was at: > http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd > <http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd> > but I got nothing with that link so perhaps there's now a version 4 > and they removed the old one. > > With the latest version of MapSource, try saving a GPX file and look > for the schema URL in it. > > If you can't find it, I have a copy of GpxExtensionsv3.xsd and will > post it. > >
andy+pigsonthewing.org.uk on Thu Jan 03 10:59:27 2008 (link), replying to msg
In message <4777A6DE.8060800+gmail.com>, Paul Tomblin <ptomblin+gmail.com> writes >Simon Slavin wrote: >> And altitude ! Why in heaven's name don't Garmin's units log the >> altitude when they log track points ? They show it on the display. >> The track points are logged in GPX format. It should be easy. Adding >> another dimension would make such an improvement to any graphics >> showing the route taken and increase purchases by climbers. >I'm guessing it's because they used to use NMEA as their data exchange >format. I don't know the internals, but I'm guessing the fact that the >M stands for Marine means they didn't think altitude would be very >important. Tell that to a submarine captain! -- Andy Mabbett * Are you using Microformats, yet: <http://microformats.org/> ?
ptomblin+gmail.com on Thu Jan 03 11:34:41 2008 (link), replying to msg
On Jan 3, 2008 1:52 PM, Andy Mabbett <andy+pigsonthewing.org.uk> wrote: > In message <4777A6DE.8060800+gmail.com>, Paul Tomblin > <ptomblin+gmail.com> writes > >I'm guessing it's because they used to use NMEA as their data exchange > >format. I don't know the internals, but I'm guessing the fact that the > >M stands for Marine means they didn't think altitude would be very > >important. > > Tell that to a submarine captain! Your GPS picks up signals underwater? How do you do that? -- "To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -- Teddy Roosevelt
evanc+irtech.com on Mon Jan 07 15:08:02 2008 (link)
So would the "velocity" from the GPS be more accurate than v = d/t ? I have a rally application running on a PDA. It cares about distance travelled, average speed and time. It takes each fix reported by the GPS, calculates the distance and divides by the time to calculate current speed. It does "wander" when the vehicle is stopped because the position changes and the cumulative distance and time add up. It seems to match the vehicle speedo and odo fairly closely, but there is always some unexplained error that would be nice to minimize. Would I be better off to somehow use the velocity? maybe like d = vt ? Evan _____ From: Simon Slavin [mailto:slavins+hearsay.demon.co.uk] Sent: Monday, December 31, 2007 1:47 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] GPS velocity measurement (was: GPX Java/Javascript-XML/Json) On 31 Dec 2007, at 4:00pm, Dave Patton wrote: > However, the 'current speed' displayed by the GPSr (i.e. if > it has such a display) may be quite accurate, as it is something > that may be calculated by the GPSr on a far more frequent basis > than the tracklog interval. I agree with your point that the 'points' referred to in my explanation are successive fixes as taken by the unit, and more closely spaced than ones generated for the tracklog shown to the customer. But handheld units don't take even these fixes as often as you might think: each fix represents a lot of computing power and therby battery drainage and the more frequently you take a fix the sooner the battery runs down. Switch to the satellite view of your own handheld unit and watch to see how often the long/lat figures update, then compare that with how often your velocity changes. Perhaps we're used to different ground conditions. In the broken rocky areas where I walk I can rarely hold direction and speed for more than three or four seconds at a time: there's always a rock in the way or a break in the path. Measuring my instantaneous velocity doesn't tell me much. > If the GPSr reports those speed values, > either through a mechanism such as a NMEA data stream, or by > recording an instantaneous value when it records a trackpoint, > then those speed values may be 'fairly accurate'. Those 'speed values' are the ones we're talking about, and my warning was that they are calculated, using formulae that don't really express velocity in a useful way. > Here's a discussion about GPS receivers and velocity measurement: > http://groups. <http://groups.google.ca/group/sci.geo.satellite-nav/browse_thread/thread/b1 67819b6e1e0bcc/> google.ca/group/sci.geo.satellite-nav/browse_thread/thread/b167819b6e1e0bcc/ I spent about ten minutes scanning that page. Anything it mentions about Doppler analysis doesn't count: handheld units do not do Doppler analysis. Other extracts it includes from detailed arguments seem to agree more with what I wrote than with the view that a velocity measurement can be precise, accurate and useful. Simon. [Non-text portions of this message have been removed]
timfpark+gmail.com on Tue Jan 22 07:47:12 2008 (link), replying to msg
I'm interested as well helping work on another revision to the standard. The internet project I am working on (a digital trail database: http://www.tierrawiki.org/) could particularly be helped by the addition of an accuracy metric to each track point. Who is the "owner" of the GPX standard? (What organization put out the current version of the standard?) Tim --- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > On 31 Dec 2007, at 10:05am, marcel.ruff wrote: > > > Thanks for your details. > > You're welcome. > > > I think it is time to have a GPX 1.2 with such markup as above > > (including a tag for accuracy). > > Otherwise this info is cluttered in <extensions> by every user > > of GPX in an incompatible way. > > I completely agree. > > A year ago I tried to work out a small set of fields that would be > useful for a GPX 1.2 I got something that I was fairly happy with, > which would suit the majority of handheld, satnav and marine units, > with a view to modern applications such as geolocating cameras and > satnav devices. There were a number of questions I wanted to ask this > list: opinions on geolocating photography (which I know nothing about) > and about how much 'source' information should be noted. And since I > did my work a couple of new things have come up concerning, for > example, cell-tower methods of location. > > The problem is the next step: can we get anything new adopted as a > real standard ? I don't know how to get a new standard adopted by the > GPS community. And without that I'm not willing to do the detail work > needed to fully specify the new standard. If someone can assure me > that the final steps can be taken, by describing how, I think this > list can come up with a good standard. But it's not worth doing if it > won't lead to anything. > > Simon. >
robertlipe+usa.net on Sat Jan 26 21:02:09 2008 (link)
> I'm interested as well helping work on another revision to the > standard. The internet project I am working on (a digital trail > database: http://www.tierrawiki.org/) could particularly be helped > by the addition of an accuracy metric to each track point. The good news for you is that you don't have to extend the GPX 1.1 standard; there is an "escape hatch" that lets you design your own extensions to the spec in a conforming way. Take a look at the extensions by TopoGrafix, Garmin, and others for examples of doing this. > Who is the "owner" of the GPX standard? (What organization put out > the current version of the standard?) It was developed jointly by this group. Dan at Topografix bore more of the heavy lifting. The current stance on extensions is kind of like that for ANSI C. Lots of people have ideas that "must" be done in the core language, but proven implementations and wide marketshare will get you further than thinking it must be standardized first. RJL
ptomblin+gmail.com on Sun Jan 27 09:28:03 2008 (link), replying to msg
Robert Lipe wrote: > > I'm interested as well helping work on another revision to the > > standard. The internet project I am working on (a digital trail > > database: http://www.tierrawiki.org/ <http://www.tierrawiki.org/>) > could particularly be helped > > by the addition of an accuracy metric to each track point. > > The good news for you is that you don't have to extend the GPX 1.1 > standard; > there is an "escape hatch" that lets you design your own extensions to the > spec in a conforming way. Take a look at the extensions by TopoGrafix, > Garmin, > and others for examples of doing this. The problem with that attitude is that you end up with a bunch of conflicting and redundant extensions to the GPX standard, instead of one. Or, like Simon pointed out, people saying "GPX doesn't do it for me, I'm going to make my own." -- Paul Tomblin <ptomblin+xcski.com> http://blog.xcski.com/ "I'm starting to suspect she has a part-time job in one of the circles of Hell and is telecommuting."
robertlipe+usa.net on Sun Jan 27 10:06:53 2008 (link)
> The problem with that attitude is that you end up with a bunch of conflicting > and redundant extensions to the GPX standard, instead of one. Or, like Simon I agree that's a problem. On the other hand, if none of the conflicting and redundant extensions can really get enough traction in the market to command mindshare, are they really suitable to be formalized anyway? I'm not arguing that it's necessarily a good thing, I'm just highlighting the other side. We don't have to rev the core of GPX to add things to it and there's something to be said about the core being simple and small. That's why we have the <extension> hatch. We have a large base of programs (and even GPSes!) that support GPX and we don't want to break that critical mass. If someone came to this group with a really great set of extensions, we could probably figure out how to "bless" it. Then again, it's not like there is a GPX Consortium or steering committee or such to decide futures. Perhaps there should be. RJL
egroups+topografix.com on Sun Jan 27 11:05:30 2008 (link), replying to msg
Hello, My own personal opinion is that a new version of GPX is needed, and that it should be 2.0, not 1.2 (Signifying that a GPX 1.0 or 1.1 document may not validate as a GPX 2.0 document) I would strip the base GPX 2.0 schema down to the bare minimum, removing things like hdop, magvar, and ageofdgpsdata to their own officially-blessed extension schemas. I agree with the comments others have made that the current situation, where we have multiple private schemas all expressing common items like depth, temperature, and speed in their own way, is wrong. I would like to see a dozen or so officially-blessed extension schemas created to extend the base GPX 2.0 schema in different directions. I'd like to see a commitment from developers using the GPX format to develop common "officially-blessed" schemas for data that might have a use in other hardware or software applications, and to only use private schemas for truly private data that has no meaning outside of that developer's application. I'd also like to see some of our XML design gurus step forward and propose a framework for future GPX schemas based on the latest best practices in XML design. -- Dan Foster
timfpark+gmail.com on Mon Jan 28 00:32:43 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+...> wrote: > > Take a look at the extensions by TopoGrafix, > Garmin, > and others for examples of doing this. > I have seen the TopoGrafix accuracy extensions in the wild (but only occasionally -- not something you can even remotely rely on) but not the Garmin ones -- is there a schema online that you could point me to? Tim
robertlipe+usa.net on Mon Jan 28 00:46:26 2008 (link)
> > Take a look at the extensions by TopoGrafix, > > Garmin, > > and others for examples of doing this. > > > > I have seen the TopoGrafix accuracy extensions in the wild (but only > occasionally -- not something you can even remotely rely on) but not > the Garmin ones -- is there a schema online that you could point me to? I was going more for the policy than the specific examples, but http://developer.garmin.com/schemas/gpxx/v3/ isn't a bad starting point. RJL
speleoluc+gmail.com on Tue Feb 05 05:13:09 2008 (link)
Hi, I succeeded writing a GPX export feature in my cave survey freeware so that users can export the cave line plot into their GPS and walk "over" their cave when looking for cave-related surface features. As displayed by http://www.gpx-view.com, the line plot appears a little different, as if the viewer joined track segments that shouldn't be. Any idea? I uploaded everything at http://auriga.neopages.org/test I put the GPX file, as well as the original line plot (Cave_gif) and what I get in the GPX viewer (GPX.gif). Thanks, Luc Le Blanc http://www.speleo.qc.ca/Auriga
egroups+topografix.com on Thu Feb 07 07:23:18 2008 (link)
I apologize for using this mailing list for what should be a private message to Garmin's development team, but they don't make it easy to contact them. If anyone from Garmin is reading this list, please take a look at the GPX files being written by the new Colorado GPS receivers. They do not validate. They are not valid GPX documents. The files make use of two private Garmin extension schemas, but fail to give proper URIs where these schemas can be located. Please fix this and test the generated files using the validation method described at http://www.topografix.com/gpx_validation.asp SaxCount.exe -v=always -n -s -f my_gpx_file.gpx Here's the Win32 link for SaxCount: http://xml.apache.org/dist/xerces-c/binaries/ On a similar note, the Garmin nuvi 350 generates an invalid XML (not GPX) file in /Garmin/GarminDevice.xml - the first characters in the file are a newline (0x0d0a) which is not legal for XML. http://www.validome.org/xml/ I would appreciate a reply if someone from Garmin reads this.
carlos.tejo+gmail.com on Fri Feb 08 05:16:16 2008 (link)
Hello, This is my first message on this list, so first I should introduce myself: my name is Carlos Tejo, and I'm a student at University of Oviedo. I am going to develop using GPX format my Master Thesis. We need to define POI in the project, so we are thinking to use GPX for that. The problem comes out when we want to define an area for an POI (for instance, define the area of Times Square). Is that possible in GPX? or I will need to use an extension ? Best regards, Carlos Tejo
egroups+topografix.com on Fri Feb 08 05:32:15 2008 (link), replying to msg
Hello, Friday, February 8, 2008, 7:50:36 AM, Carlos wrote: > Hello, > This is my first message on this list, so first I should introduce > myself: my name is Carlos Tejo, and I'm a student at University of > Oviedo. I am going to develop using GPX format my Master Thesis. > We need to define POI in the project, so we are thinking to use GPX > for that. The problem comes out when we want to define an area for an > POI (for instance, define the area of Times Square). Is that possible > in GPX? or I will need to use an extension ? There are already GPX extensions for closed shapes. There isn't an explicit way to associate a <wpt> element with a <polyline>, but you could either just use <polyline> as your POI element, or adopt the convention that a <wpt> that is spatially located inside the boundary of a <polyline> is a POI with area. Below is sample GPX created using the Shape Tool in ExpertGPS. -- Dan Foster <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="ExpertGPS 2.7.6" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.topografix.com/GPX/gpx_style/0/2 http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd http://www.topografix.com/GPX/gpx_overlay/0/3 http://www.topografix.com/GPX/gpx_overlay/0/3/gpx_overlay.xsd http://www.topografix.com/GPX/gpx_modified/0/1 http://www.topografix.com/GPX/gpx_modified/0/1/gpx_modified.xsd"> <metadata> <bounds minlat="42.66392823" minlon="-71.56202900" maxlat="42.67285710" maxlon="-71.54622900"/> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2008-02-08T13:29:27.343Z</time> </extensions> </metadata> <wpt lat="42.67056954" lon="-71.55502900"> <time>2008-02-08T13:27:05.875Z</time> <name>times square</name> <sym>Residence</sym> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2008-02-08T13:27:51.375Z</time> </extensions> </wpt> <extensions> <polyline xmlns="http://www.topografix.com/GPX/gpx_overlay/0/3"> <type>Border</type> <label> <max_scale>1500000</max_scale> <text xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <font> <family generic="sans-serif"> <face>Arial</face> </family> <text-transform>uppercase</text-transform> </font> </text> </label> <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>000000</color> <opacity>1.00</opacity> <width>0.4000</width> <pattern>Boundary - National</pattern> <dasharray> <dash mark="12.500" space="1.875"/> <dash mark="4.375" space="1.875"/> <dash mark="4.375" space="1.875"/> </dasharray> </line> <fill xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>c9ea9d</color> <opacity>0.50</opacity> <pattern>Solid</pattern> </fill> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2008-02-08T13:29:27.343Z</time> </extensions> <points> <pt lat="42.67285710" lon="-71.56122900"/> <pt lat="42.67270951" lon="-71.54622900"/> <pt lat="42.66392823" lon="-71.54682900"/> <pt lat="42.66437098" lon="-71.56202900"/> <pt lat="42.67285710" lon="-71.56122900"/> </points> </polyline> </extensions> </gpx>
carlos.tejo+gmail.com on Sat Feb 09 06:56:31 2008 (link), replying to msg
Hello, > There are already GPX extensions for closed shapes. There isn't an > explicit way to associate a <wpt> element with a <polyline>, but you > could either just use <polyline> as your POI element, or adopt the > convention that a <wpt> that is spatially located inside the boundary > of a <polyline> is a POI with area. Thanks for your example. You have said that it is not way to associate a <wpt> element to a <polyline>. Why we cannot add the polylie inside the <wpt><extension> ? Carlos Tejo
egroups+topografix.com on Sat Feb 09 08:58:11 2008 (link), replying to msg
Hello, Saturday, February 9, 2008, 9:32:56 AM, Carlos wrote: > Hello, >> There are already GPX extensions for closed shapes. There isn't an >> explicit way to associate a <wpt> element with a <polyline>, but you >> could either just use <polyline> as your POI element, or adopt the >> convention that a <wpt> that is spatially located inside the boundary >> of a <polyline> is a POI with area. > Thanks for your example. You have said that it is not way to associate > a <wpt> element to a <polyline>. Why we cannot add the polylie inside > the <wpt><extension> ? That's certainly possible, although doing it that way would mean that 99% of the programs out there wouldn't recognize the polyline (because they'd be expecting it in the second level of the file (child of <gpx>), rather than embedded in another second-level element. On the other hand, it may be that your polyline data really has no meaning outside of the <wpt>, and therefore it logically belongs as a child of <wpt><extensions>. -- Dan Foster
crasses+froggies.be on Sun Feb 10 03:40:25 2008 (link)
Hello to everyone :) I'm developing a software for academic purpose which needs to import GPX or more exactly part of GPX files. In any case I need to parse the GPX to extract the information I want, being extracted either from a list of waypoint or from a route. I'm using Delphi 2007 and wanted to take the easiest way being generating automtaicaly the necessary routines by importing the XSD into Delphi Data Linking XML Expert. However, when trying to interface the generated code based on the XSD (GPX 1.1) with the Fells_loop.gpx file, Delphi refuses to link both. So according to Delphi, the XSD and the GPX file did NOT match. I tried the same using fells_loop.gpx as input and of course it works (it'd better). But fells_loop.gpx is just a sample isn't it? I just can't base my parsing on a single sample, even if it seems to work well. Thank you for help, input, suggestion or whatever which could help me :)
ajcartmell+fonant.com on Sun Feb 10 05:52:58 2008 (link), replying to msg
> Carlos--have you considered using PostGIS, or one of the spatial > formats that handles tagging of all attribute types? I would think > that even a Shapefile would be better suited than GPX. Or kml? Anthony -- www.fonant.com - Quality web sites
carlos.tejo+gmail.com on Sun Feb 10 18:46:09 2008 (link), replying to msg
Hello, I am reading about .kml or .gml to save the information. Do you which GPS devices can handdle a .kml o .gml file ? Carlos Tejo
hannu.lohi+tracker.fi on Tue Feb 12 00:29:54 2008 (link)
I tried to send the e-mail in to info2004 at topografix.com for adding MyWay Navigator product in to supporting SW list, but the mail address seems not to be in use. So hopefully via this forum I can send same information. Our company is Tracker Oy www.tracker.fi and the products supporting GPX are: - MyWay Navigator - MyWay Navigator Lite - Tracker MyWay - Mobile Tracker BTW: We already have also two scale of US topomaps in SW.
jccounihan+yahoo.co.uk on Fri Feb 22 05:03:28 2008 (link)
Hi all, Is there some way of encoding turn by turn instructions into a .gpx file without using some sort of software like Garmin's Mapsource to plan the route? For example I have 200 route points (as defined by <rte> and <rtept> tags) and I want to encode turn by turn information between each of them using some 3rd party software? Also what does the tag <Subclass> (18 digit, in hex/binary base) class in the Garmin version 3 format represent? Is it for turn by turn directions or what? It is related to the RoutePointExtension tags but I have no idea how or what the encoding is!! Any ideas would be greatly appreciated! Thanks.
salcedo+yahoo.com on Mon Feb 25 15:38:20 2008 (link), replying to msg
If you are asking how to represent turns in GPX, my understanding is that each route point should be considered a turn point. While there is no specific XML element in GPX for turn direction, I would probably use the comment field to store the information like "Right on Elm St.", "Bear left", "Exit 17th Ave. North", etc. -Ricardo --- In gpsxml+yahoogroups.com, "jccounihan" <jccounihan+...> wrote: > > > Hi all, > > Is there some way of encoding turn by turn instructions into a .gpx > file without using some sort of software like Garmin's Mapsource to > plan the route? > > For example I have 200 route points (as defined by <rte> and <rtept> > tags) and I want to encode turn by turn information between each of > them using some 3rd party software? > > Also what does the tag <Subclass> (18 digit, in hex/binary base) class > in the Garmin version 3 format represent? Is it for turn by turn > directions or what? > > It is related to the RoutePointExtension tags but I have no idea how > or what the encoding is!! > > Any ideas would be greatly appreciated! > > Thanks. >
chris+ainslie.co.za on Fri Mar 07 05:05:12 2008 (link), replying to msg
Hi All, I have come across an interesting situation when converting a log of NMEA sentences to GPX. Firstly, the NMEA sentences are saved in a CSV file as per below. $GPGGA 122023 2925.4063 S 3041.2592 E 1 5 2 953.4 M 28.6 M 0000*46 $GPRMC 122025 A 2925.4049 S 3041.2562 E 4.29 286.82 10308 *1B $GPGGA 122026 2925.4035 S 3041.2555 E 1 5 2 959.7 M 28.6 M 0000*42 $GPRMC 122027 A 2925.4026 S 3041.2539 E 4.72 301.38 10308 *1F $GPGGA 122028 2925.4011 S 3041.253 E 1 5 2 965.8 M 28.6 M 0000*49 $GPRMC 122030 A 2925.3972 S 3041.2511 E 5.35 334.08 10308 *1B I have written an application to convert this to GPX and this file validates correctly. The problem is that when I open this file in Mapsource, my speeds are completely messed up. For example, the Mapsource tracklog shows speeds going from 18km/h - 32km/h - 11km/h in the space of 3 points not more than 50m from the first point to the last. Is there something I'm missing? I'm toying with converting only one sentence and not the other - I'm not sure if this is the solution. Any ideas? Thanks Chris.
chris+ainslie.co.za on Sun Mar 09 23:12:26 2008 (link), replying to msg
Hi Simon, Yes, each point does have a timestamp and the times are reasonable. For example, the speeds only jump around in smallish amounts, but enough to show the problem. An example would be these speeds for the a sample of 6 trackpoints (in km/h). (18, 30, 13, 17, 20, 40). The speeds aren't ridiculous, but it's also not feasible for these sorts of speeds to be real. It should be noted that the total distance and the total time taken for the entire track is accurate though. Chris. From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Simon Slavin First, take a look at the GPX file with a text editor. Are there timecodes in there associated with each point ? If not, then Mapsource is not seeing any useful time information and is just guessing. Second, look at the times in the text you quoted: 12:20:23, 12:20:25, etc.. It takes only a second or so to get between each point. What is the distance between them ? Would it lead to reasonable speeds or very high ones ? Simon. [Non-text portions of this message have been removed]
ptomblin+gmail.com on Mon Mar 10 05:00:29 2008 (link), replying to msg
<02dd01c8801d$752f9a40$5f8ecec0$+co.za> <981119C9-902E-4055-A913-1D2B725BF34C+hearsay.demon.co.uk> <04c401c88274$8e360020$aaa20060$+co.za> From: Paul Tomblin <ptomblin+gmail.com> Date: Mon, 10 Mar 2008 7:59:45 -0400 Content-transfer-encoding: 7bit On Mon, 10 Mar 2008 08:04:09 +0200 "Chris Ainslie" <chris+ainslie.co.za> wrote: >Yes, each point does have a timestamp and the times are reasonable. For >example, the speeds only jump around in smallish amounts, but enough to show >the problem. An example would be these speeds for the a sample of 6 >trackpoints (in km/h). (18, 30, 13, 17, 20, 40). > >The speeds aren't ridiculous, but it's also not feasible for these sorts of >speeds to be real. It should be noted that the total distance and the total >time taken for the entire track is accurate though. Why don't you think these speeds are reasonable? If you're talking about points taken a few seconds apart, with the uncertainty of gps I can see a fluctuating speed as being quite normal. What happens if you take an average of the previous 10 or 20 points?
natevw+yahoo.com on Mon Mar 24 23:14:25 2008 (link)
I'm developing a geotagging app of sorts that can read GPX files. I've noticed a couple GPX exporters (gpsbabel and Garmin's "Bobcat") that will take a tracklog like "ACTIVE LOG" and split it into literally hundreds of <trk>s, each containing only one <trkseg>: <trk><name>ACTIVE LOG</name><trkseg>...</trkseg></trk> <trk><name>ACTIVE LOG 001</name><trkseg>...</trkseg></trk> ... <trk><name>ACTIVE LOG 145</name><trkseg>...</trkseg></trk> <trk><name>ACTIVE LOG 146</name><trkseg>...</trkseg></trk> ...ad infinitum By my understanding of the format, which is confirmed by other utilities such as G7ToWin, a new track log should NOT be created for every single little time the GPS unit loses signal or whatnot, especially if the GPS itself does not call it a new track. Is this a correct understanding? Are there reasons these programs go out of their way to turn one tracklog into hundreds named in sequence? I'm tempted to start a letter writing campaign so that sanity (IMO) may one day again prevail, but I'm starting to worry that this strange "feature" is more widespread than I imagined, perhaps for some practical reason, and it would be a losing battle. Has anyone noticed the general ratio of programs that keep something like Garmin's "ACTIVE LOG" as one <trk> with many <trksegs>, versus those that go out of their way to make sure there's only one <trkseg> per <trk>? thanks, -natevw ps - sorry for the "get off my yard, you whippersnappers" tone; I was completely befuddled when I noticed how gpsbabel burst my tidy little GPX world with this newfangled idea, and I still have not gotten back into my rocker.
robertlipe+usa.net on Tue Mar 25 00:00:53 2008 (link)
> exporters (gpsbabel and Garmin's "Bobcat") that will take a tracklog like "ACTIVE LOG" and > split it into literally hundreds of <trk>s, each containing only one <trkseg>: Can't speak for Bobcat, but I can speak pretty authoritatively for GPSBabel. Disclosure: I am the Chief Babel Head. > I'm tempted to start a letter writing campaign so that sanity (IMO) may one day again > prevail, but I'm starting to worry that this strange "feature" is more widespread than I Answer A) Letter writing campaigns will just get you on my naughty list and annoy me. Graph my annoyance against my likelihood of changing anything and see where that gets you. A well reasoned question is much more likely to get a well reasoned answer and/or action. Answer B) The whole concept of <trkseg> has simply never made any sense to me. A track is a related connection of points that describe a trip. The concept of a track segment is deeply entrenched in (and seemingly largely rooted in) Garmin parlance to describe where the GPS lost lock. Whether that's because you passed through a tunnel on a train or because you had an older unit and lost lock lock because there was tree visible on the horizon doesn't much matter to me; an artificial construct that the GPS lost lock for a few seconds just doesn't map well into other formats, so I chose to normalize them to a representation that include more sense in more formats: a track is a related, sequenced collection of points. To me, if the GPS has reported that it's lost concept of where it is, then starting a new track make much more sense than pretending it's a new segment of a current track. That's why GPSBabel pretty much ignores trkseg. In my experience with a couple hundred formats, none that weren't dominated by Garmin parlance use "track segments". As their own models are using this less frequently, there may be something to ignoring this model. RJL
mhoegh+gmail.com on Tue Mar 25 01:05:48 2008 (link), replying to msg
natevw, I agree with you: A trkseg should not be turned into a new track resulting in tons of tracks. I also think that trkseg is a very reasonable construct, which is used to describe where no data was recorded. It can be loss of signal or on purpose (like a break on a hike). A track with segments can easily be parsed into a multi polyline, which is supported by KML (google maps/earth) and OGC recommended standards (GML, WMS, WFS etc.) making it easy to map them. So I see no reason not to support trkseg. Martin Hoegh toposhare.org
ajcartmell+fonant.com on Tue Mar 25 03:46:49 2008 (link), replying to msg
> By my understanding of the format, which is confirmed by other utilities > such as G7ToWin, > a new track log should NOT be created for every single little time the > GPS unit loses signal > or whatnot, especially if the GPS itself does not call it a new track. I agree. That would seem to be exactly the purpose of having trksegs in the GPX format. Segments could be used for many different purposes, not only GPS signal breaks. For example a bicycle route could split into on-road and off-road segments. Or an off-road track could be split into different levels of difficulty, or track type, etc. Or you could break a day's journey into segments between stops or meals. Never having more than one trkseg per trk makes the trkseg element obsolete in the GPX schema. Keeping the segments together in a single track from the GPS keeps the information as originally collected by the GPS. Splitting the track into multiple single-segment tracks seems to me to be unnecessary and damaging to the original data. Anthony -- www.fonant.com - Quality web sites
egroups+topografix.com on Tue Mar 25 06:14:39 2008 (link), replying to msg
Hello, Tuesday, March 25, 2008, 8:22:38 AM, Simon wrote: > I think if we were inventing GPX now we wouldn't > think of track segments. Read Martin's email again - every spatial format contains the concept of a multi polyline - a single object that contains multiple lines. There are lots of real-world items that are described using multiple lines (sometimes closed lines or polygons) in a single object: a trail with a spur a river with side creeks a pond with an island a national park boundary with private inholdings your lawn (presumably there's a house in the middle) Your GPS customers might not care about these types of things, but mine absolutely require them. Garmin's GPS receivers allow you to send a single track with multiple segments back to the GPS. Many people use this to represent river branches or to create trail networks. -- Dan Foster
natevw+yahoo.com on Tue Mar 25 10:35:37 2008 (link), replying to msg
> Answer B) The whole concept of <trkseg> has simply never made any sense to me. > A track is > a related connection of points that describe a trip. The concept of a track > segment is deeply > entrenched in (and seemingly largely rooted in) Garmin parlance to describe > where the GPS lost > lock. Whether that's because you passed through a tunnel on a train or > because you had an older unit and lost lock lock because there was tree > visible on the horizon doesn't much matter to me; an artificial construct that > the GPS lost lock for a few seconds just doesn't map well into other formats, > so I chose to normalize them to a representation that include more sense in > more formats: a track is a related, sequenced collection of points. > > To me, if the GPS has reported that it's lost concept of where it is, then > starting a new track make much more sense than pretending it's a new segment > of a current track. That's why GPSBabel pretty much ignores trkseg. As far as how it maps to other GPS related formats, I will defer to your experience there. But as other posters have mentioned, the concept of one item having multiple disjoint parts is certainly a useful idea that has been included in many geographic formats, including GPX. Perhaps looking at it from a user's perspective would be more helpful. You said yourself "a track is a related, sequenced collection of points" and earlier you added "that describe a trip". The thing is on a typical trip, even a better GPS device will lose signal occasionally or get turned off to change batteries on a longer journey. When the user gets back from his "Vacation in New York", do they want it to be reflected as "Vacations in New York, 001 through 123"? Very well you might say, just provide a grouping construct so that the user can lump them all together. That is exactly what a <trk> is: it groups together all the different segments (continuous points) into a tracklog (related collection). As a user, I don't want a bunch of tracklogs like "Vacation in New York #42", many containing only two or three points each, for every time I went between buildings. While out on a trail with an older receiver, I don't want a new <trk> just because my arm got tired holding the thing above my head. That's what <trkseg>s are for. I understand that perhaps some other units and formats do not have the concept of segments within a track. That's fine, but I'd ask that you deal with that while uploading or converting *to* those formats from a format like GPX that does support it. Otherwise not only do you as a GPX provider need to make extra effort when writing to make sure tracks have incrementing numbers added on, everyone who reads your format has to reverse the process and try to figure out which separate segments originally started out together so I don't display hundreds of items to the user. I don't mean to single any one utility out (I appreciate the attention shown to this list, Robert). I just hope this explanation can encourage more GPX providers to understand and take advantage of multiple <trkseg>s inside one coherent <trk>. thanks, -natevw
mhoegh+gmail.com on Tue Apr 01 06:10:00 2008 (link)
Hi, You may find this useful: http://wms.mapuse.net/demo/playground/gpxgeo.phtml This this a demostration of the core PHP4 libs from the open source project toposhare.org. I've started to document and rewrite the code, so it becomes easier to use in other GPX/geo related projects. There is a download link to the source on the demo page. There is a lot more to it than the demo shows and I will continue the documentation/example work Soon I will release a GPX class, which wraps the other classes and have methodes for dealing with time, distance, elevation etc. Right now it does not work without the toposhare database. Hope you find this useful. If you find the toposhare.org project interesting we are always looking for developers. Martin Europa, Denmark
tomkralidis+hotmail.com on Wed Apr 09 09:10:36 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "mhoeghgmailcom" <mhoegh+...> wrote: > > Hi, > You may find this useful: > > http://wms.mapuse.net/demo/playground/gpxgeo.phtml > > This this a demostration of the core PHP4 libs from the open source > project toposhare.org. I've started to document and rewrite the code, > so it becomes easier to use in other GPX/geo related projects. There > is a download link to the source on the demo page. There is a lot more > to it than the demo shows and I will continue the > documentation/example work > > Soon I will release a GPX class, which wraps the other classes and > have methodes for dealing with time, distance, elevation etc. Right > now it does not work without the toposhare database. > > Hope you find this useful. If you find the toposhare.org project > interesting we are always looking for developers. > > Martin > Europa, Denmark > Nice! You might want to check out OGR's (http://www.gdal.org/ogr/) read/write support of GPX (http://www.gdal.org/ogr/drv_gpx.html). ..Tom
ptomblin+gmail.com on Sun Apr 13 13:00:10 2008 (link)
Does a wpt's name field have to be unique? In my aeronautical data, there are a lot of NDB's with the identifier "AA" or "AB". As well, there are places like Bathurst New Brunswick which has an NDB and a DME both with the identifier "2F". -- Paul Tomblin <ptomblin+xcski.com> http://blog.xcski.com/ Home pages are the pet rock of the 90s. They all have them, they all think they're very cute. But in a few years they're going to look back and be pretty embarrassed. -- Kim Alm
robertlipe+usa.net on Sun Apr 13 13:21:52 2008 (link)
> Does a wpt's name field have to be unique? In my aeronautical data, there are GPX doesn't say they have to be unique. Many GPSes (most, in fact) require they be unique. GPSBabel has a bucket full of code that tries to know receiver traits (are "AA" and "aa" the same? Is "A-A" the same as "AA"? How about internationalization? How about waypoint name length? Is "123456" and "123456AA" the same?) and tries to ensure that names are unique when we know the traits of the device we're shipping things to. There are LOTS of hazards in this area.
ptomblin+gmail.com on Sun Apr 13 14:13:04 2008 (link), replying to msg
Simon Slavin wrote: > > In my aeronautical data, there are > > a lot of NDB's with the identifier "AA" or "AB". As well, there are > > places > > like Bathurst New Brunswick which has an NDB and a DME both with the > > identifier "2F". > > I don't know what either of those TLAs mean, but I've seen portable > devices which call all the points they log 'waypoint'. And there's a > tide assessment device (put it in the ocean and see where it goes) > where the first version of the software logged all its locations with > a blank name which annoyed the people analysing the logs. NDB (Non Direction Beacon) and DME (Distance Measuring Equipment) are two types of ground-based navigation aids that it's quite helpful for aeronautical flight planning and navigation devices to know where they are located. If I enter "AA" into my flight plan on a Garmin aviation GPS, it asks me which one I want, so at least I know the Garmin internal database format can handle duplicates. -- Paul Tomblin <ptomblin+xcski.com> http://blog.xcski.com/ I forsee one of those "open your wallet and repeat after me, _help yourself_" moments in your local friendly workshop. -- Tanuki
robertlipe+usa.net on Sun Apr 13 16:30:17 2008 (link)
> Garmin devices seem to handle duplicates okay. I don't know if the > same is true of all devices which handle GPX. That's true of some Garmins. (Their spec actually has weasel words on this.) For example, the 60CSx will detect duplicate names and rename them for you. The 60CS will just use a "last one wins" approach.
robertlipe+usa.net on Sun Apr 13 23:35:43 2008 (link)
> Yeah, Garmin stuff is okay with it. But you're asking whether all > stuff that has to cope with GPX is okay with it. I think that unless "Some" Garmin stuff is OK. > you have the time to build in all the stuff Robert mentioned about > GPSBabel, you're just going to have to go with them all having the > same name and see how many complaints you get. It's the lazy way out > which usually gets my vote. I guess in my world, it's marginally OK. The reality is that as an intermediary, which both GPX and GPSBabel tend to be, you kind of live in a complaint-dominated world. If a quazillion people that are important to you complain the the GPX you produce won't load on a device that's important to a quazillion other people that are important to you, you'll develop defense mechanisms to cope with it. Waypoint names (character set? Length? Valid chars?) icons, and a few other fields in GPX all share these traits where it really does rely upon the producer of the data to selectively "dumb down" hte source GPX data to fit onto the devices that matter to him or her. RJL
azbithead+gmail.com on Mon Apr 14 18:41:25 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > However, that > may be because XML has no way to specify that the names would be > unique. If by "XML" you actually meant the XML Schema language published by WC3 then you are incorrect. XML Schema allows the specification of uniqueness in XML instance documents through its use of the "unique" and "key" elements. For more info on this see here <http://www.w3.org/TR/xmlschema-0/#specifyingUniqueness> and here <http://www.w3.org/TR/xmlschema-0/#specifyingKeysAndtheirRefs> . [Non-text portions of this message have been removed]
sunburned.surveyor+gmail.com on Fri May 09 12:21:12 2008 (link)
I'd like to make a short introduction. I'm an open source Java programmer that will be (hopefully) addins support for the GPX file format to the GeoTools library. I will be using this library to build support for GPX into OpenJUMP, an open source GIS editor. If there are any existing open source Java programming libraries used for reading and writing GPX I'd love to hear about them. Thanks, The Sunburned Surveyor
karl-petter+yelloworb.com on Sat May 10 07:50:03 2008 (link), replying to msg
Hi, I have been looking around a bit but didn't find a couple of clean classes to just read and write gpx so has written that for my GPS logger software, http://www.yelloworb.com/software/mogtrails/ and another piece of software at work. I'm happy to make those classes open source though they are required to compile both on J2ME and J2SE so it might not be what you are looking for. /Kalle sunburned.surveyor wrote: > > I'd like to make a short introduction. > > I'm an open source Java programmer that will be (hopefully) addins > support for the GPX file format to the GeoTools library. I will be > using this library to build support for GPX into OpenJUMP, an open > source GIS editor. > > If there are any existing open source Java programming libraries used > for reading and writing GPX I'd love to hear about them. > > Thanks, > > The Sunburned Surveyor > >
Bradley.Orner+comcast.net on Mon May 12 05:49:18 2008 (link), replying to msg
Kalle, I?ve been working on my own java classes for working with GPX for a website I?m developing. I would strongly recommend going the JAXB route using the gpsxml schema. JAXB is great ? it makes reading and writing XML a snap (as long as the XML uses XML schema). In a nutshell, you run the utility ?xjc? for a given XML schema and it generates java classes for that schema. Those classes may then be used at runtime by a java executable. You?ll simply traverse the class tree using getters and setters to build out the model. Reading an XML file is called ?unmarshalling?. Unmarshalling will create a tree of java objects from the XML file. Writing an XML file is called ?marshalling?. Marshalling will take a tree of objects and write an XML file. Here?s some class snippets to give you the idea. GpxModel is a front-end class I wrote to access the JAXB unmarshaller and marshaller, which is created using a JAXBContext created for both 1.0 and 1.1 versions of the gpsxml schema (this will allow (un)marshalling support for both versions. Here?s a partial screen shot of Eclipse showing the packages generated by xjc (here?s one xjc resource, but a simple google will yield plenty http://www.cs.utah.edu/classes/cs5520/java/JAXB/jaxb/docs/xjc.html) Code snippet: import javax.xml.bind.JAXBElement; import javax.xml.bind.Marshaller; import javax.xml.bind.Unmarshaller; import javax.xml.bind.JAXBContext; import javax.xml.bind.JAXBException; import javax.xml.transform.stream.StreamSource; // the com.topgrafix.gpx packages and classes were // generated using JAXB?s xjc ? run once for the gpx 1.0 schema // and a second time for the 1.1 schema. import com.topografix.gpx._1._0.Gpx; import com.topografix.gpx._1._1.*; public class GpxModel { private static final String JAXB_CONTEXT_PATH= "com.topografix.gpx._1._0:" + "com.topografix.gpx._1._1"; private static JAXBContext jaxbContext = JAXBContext.newInstance(JAXB_CONTEXT_PATH); private static Unmarshaller unmarshaller private static Marshaller marshaller; private static void initialize() { try { jaxbContext = JAXBContext.newInstance(JAXB_CONTEXT_PATH); unmarshaller= GpxModel.jaxbContext.createUnmarshaller(); marshaller = GpxModel.jaxbContext.createMarshaller(); initialized = true; } catch (Exception e) { e.printStackTrace(); } } public static JAXBContext getJaxbContext() { if (!initialized) { GpxModel.initialize();} return jaxbContext; } public static Unmarshaller getUnmarshaller() { if (!initialized) { GpxModel.initialize();} return unmarshaller; } public static Marshaller getMarshaller() { if (!initialized) { GpxModel.initialize();} return marshaller; } ? } Here?s snippet for unmarshalling: File f = new File(?myroute.gpx?); try{ System.out.println("unmarshalling " + f.getPath() + " ..."); root = GpxModel.getUnmarshaller().unmarshal(f); } catch (Exception e) { System.err.println("unmarshal failure"); e.printStackTrace(); } //gpx v1.0 will have a Gpx root, v1.1 will have a GpxType as the root (as created // by xjc when run for each version of the schema if (root.getClass() == Gpx.class) { gpx = (Gpx)root; System.out.println( f.getPath() + " is gpx schema v. " + gpx.getVersion()); } else if (root.getClass() == GpxType.class) { gpxtype = (GpxType)root; System.out.println( f.getPath() + " is gpx schema v. " + gpxtype.getVersion()); } else { fail("unsupported root of class " + root.getClass().toString()); } HTH, Brad _____ From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Karl-Petter �kesson Sent: Saturday, May 10, 2008 3:49 AM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Introduction of Java Programmer Hi, I have been looking around a bit but didn't find a couple of clean classes to just read and write gpx so has written that for my GPS logger software, http://www.yellowor <http://www.yelloworb.com/software/mogtrails/> b.com/software/mogtrails/ and another piece of software at work. I'm happy to make those classes open source though they are required to compile both on J2ME and J2SE so it might not be what you are looking for. /Kalle sunburned.surveyor wrote: > > I'd like to make a short introduction. > > I'm an open source Java programmer that will be (hopefully) addins > support for the GPX file format to the GeoTools library. I will be > using this library to build support for GPX into OpenJUMP, an open > source GIS editor. > > If there are any existing open source Java programming libraries used > for reading and writing GPX I'd love to hear about them. > > Thanks, > > The Sunburned Surveyor > > [Non-text portions of this message have been removed]
baroudi.malek+gmail.com on Wed May 14 10:31:40 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "sunburned.surveyor" <sunburned.surveyor+...> wrote: > > I'd like to make a short introduction. > > I'm an open source Java programmer that will be (hopefully) addins > support for the GPX file format to the GeoTools library. I will be > using this library to build support for GPX into OpenJUMP, an open > source GIS editor. > > If there are any existing open source Java programming libraries used > for reading and writing GPX I'd love to hear about them. > > Thanks, > > The Sunburned Surveyor > Hello lists, I'm about to develop a GPX component in spatialdataintegrator (SDI) with geotools 2.4.2 and it's work properly ! See the GPX+geotools module of Petter Bolla: http://docs.codehaus.org/display/GEOTOOLS/GPX+module For geotools 2.4.2 you have : http://metacortex.hu/~buci/gpx-2.4.zip And for geotools 2.5 see geotools javadoc. Thanks for Petter Bolla to have devolopping this module Regars Malek Baroudi
sunburned.surveyor+gmail.com on Wed May 14 14:04:45 2008 (link)
What does the "cmt" element of a waypoint represent? Thanks, Landon
robertlipe+usa.net on Wed May 14 14:07:42 2008 (link)
> What does the "cmt" element of a waypoint represent? The comment as represent(ed|able) in a GPS. See the spec at: http://www.topografix.com/GPX/1/1/#type_wptType
sunburned.surveyor+gmail.com on Wed May 14 15:06:33 2008 (link), replying to msg
Thanks Robert. I saw that "cmt" was a String type when I looked at the schema documentation, I just didn't realize it represented a "comment". Thanks for the clarification. Landon On Wed, May 14, 2008 at 2:07 PM, Robert Lipe <robertlipe+usa.net> wrote: > > >> What does the "cmt" element of a waypoint represent? > > The comment as represent(ed|able) in a GPS. See the spec at: > > http://www.topografix.com/GPX/1/1/#type_wptType > >
robertlipe+usa.net on Wed May 14 15:34:42 2008 (link)
> Thanks Robert. I saw that "cmt" was a String type when I looked at the > schema documentation, I just didn't realize it represented a > "comment". You're not the first to not immediately recognize that if you allow popups and click on the question mark thingy at the end, you can get a short description of each element.
sunburned.surveyor+gmail.com on Wed May 14 15:53:20 2008 (link), replying to msg
Aha! That will be good to know for the future. Thanks for the help. Landon On Wed, May 14, 2008 at 3:34 PM, Robert Lipe <robertlipe+usa.net> wrote: > >> Thanks Robert. I saw that "cmt" was a String type when I looked at the >> schema documentation, I just didn't realize it represented a >> "comment". > > You're not the first to not immediately recognize that if you allow popups > and click on the question mark thingy at the end, you can get a short > description > of each element. > >
giorgio.ghisa+yahoo.co.in on Wed May 21 04:57:12 2008 (link)
Hello, This is my first message on this forum, so first I should introduce myself: my name is Giorgio Ghisalberti, and I'm a student at University of Bergamo (Italy). I am going to develop using GPX format my Master Thesis. I need to define some points on my GPX files and I use wptType. I want now if is possible define different colors for my wpt points? Is that possible in GPX? Or I will need to use an extension ? Can you make an example? Best regards, Giorgio Ghisalberti
dananderson2+yahoo.com on Wed May 21 07:44:06 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "giorgio.ghisa" <giorgio.ghisa+...> wrote: [snip] > I need to define some points on my GPX files and I use wptType. I want > now if is possible define different colors for my wpt points? > Is that possible in GPX? Or I will need to use an extension ? > Can you make an example? You would need an extension. GPX specifies the data but not how to display it. There is an extension for display information called GPX_Style. See: http://www.topografix.com/GPX/gpx_style/0/2/ It specifies a color type but is defined for lines, fills, and text. A waypoint is usually represented on the computer or GPS receiver screen by a symbol (which may be a dot). The name of the symbol is placed in the GPX file for the waypoint. This symbol can be any graphic that the device can handle. It's usually a small graphic (16x16 or 32x32 pixels, etc.) that might be color, greyscale, or black and white. That means it is not something that you would normally apply a color to. It is a graphic that might be drawn in many colors. A color attribute may be applied to the waypoint text and GPX Style may be used to define the color of the text. Some sample waypoint symbol names from a major manufacturer: Navaid, Green Navaid, Green/Red Navaid, Green/White Navaid, Orange Navaid, Red/Green Navaid, Red/White Navaid, Violet Navaid, White/Green
sunburned.surveyor+gmail.com on Wed May 21 12:49:45 2008 (link), replying to msg
Giorgio, You wrote: "I'm a student at University of Bergamo (Italy). I am going to develop using GPX format my Master Thesis." What programming language will you work in? I'm working on support for GPX in the GeoTools library, so we might be able to work together. Landon On Wed, May 21, 2008 at 9:58 AM, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > > On 21 May 2008, at 3:43pm, Dan Anderson wrote: > >> A waypoint is usually represented on the computer or GPS receiver >> screen by a symbol (which may be a dot). The name of the symbol is >> placed in the GPX file for the waypoint. This symbol can be any >> graphic that the device can handle. > > That's what I was thinking about. How many different colours do you > need ? Because the 'symbol' thing is part of GPX and you don't need > any extensions to use it: everything that handles GPX understands > symbols. If you only need only nine or so different colours, and > don't care about the precise RGB colour values then using symbols > would be a simple and 'cheap' way of doing it. > > Simon. > >
giorgio.ghisa+yahoo.co.in on Thu May 22 02:40:52 2008 (link), replying to msg
> You wrote: "I'm a student at > University of Bergamo (Italy). I am going to develop using GPX format > my Master Thesis." > > What programming language will you work in? I'm working on support for Hi, I'm working in Java. I know GeoTools Library, but I don't konw that there is GPX support. > If you only need only nine or so different colours, anddon't care > about the precise RGB colour values then using symbols > would be a simple and 'cheap' way of doing it. I want represent some waypoint on a single map whitah a gradation of a single colors. If this isn't possible I can use only nine colours... How can I do it? > It's usually a small graphic(16x16 or 32x32 pixels, etc.) that > might be color, greyscale, or black and white. That means it is not > something that you would normally apply a color to. It is a graphic > that might be drawn in many colors. I undestand, but can you make an example? Thanks at all, Giorgio
dananderson2+yahoo.com on Thu May 22 10:54:24 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "giorgio.ghisa" <giorgio.ghisa+...> wrote: > > It's usually a small graphic(16x16 or 32x32 pixels, etc.) that > > might be color, greyscale, or black and white. That means it is not > > something that you would normally apply a color to. It is a graphic > > that might be drawn in many colors. > I undestand, but can you make an example? There's a collection of custom symbols (Geocaching oriented) for Garmin receivers at: http://www.elsinga.net/custom-waypoint-symbols.html I provide some symbols for hiking trails and to replace some that Garmin removed from their current receivers. They are available at: http://www.westernmaps.net/WM_WaypointSymbols/CustomWaypointSymbols.html ExpertGPS puts symbols in a Windows font and is also adding support for custom symbols in PNG format files. There's a 30-day free trial if you wish to see what it looks like by using a graphic font. http://expertgps.com GPS Utility puts a collection of symbols in a BMP file. An index file provides the pixel coordinates of the location of the symbol in the file that corresponds to, for instance, "Shopping." http://www.gpsu.co.uk/
egroups+topografix.com on Thu May 22 14:07:29 2008 (link), replying to msg
Hello, Wednesday, May 21, 2008, 3:35:15 AM, giorgio.ghisa wrote: > I need to define some points on my GPX files and I use wptType. I want > now if is possible define different colors for my wpt points? > Is that possible in GPX? Or I will need to use an extension ? > Can you make an example? You'll need to use an extension. There is already an existing extension that several programs use to add color to tracks and routes. An example is below. The next version of ExpertGPS will allow you to specify a colored background for waypoint symbols - the symbol itself will be specified by <sym>, and the colored background will be in an extension schema. Example: see <color> tag <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="ExpertGPS 2.8.8" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.topografix.com/GPX/gpx_style/0/2 http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd http://www.topografix.com/GPX/gpx_overlay/0/3 http://www.topografix.com/GPX/gpx_overlay/0/3/gpx_overlay.xsd http://www.topografix.com/GPX/gpx_modified/0/1 http://www.topografix.com/GPX/gpx_modified/0/1/gpx_modified.xsd http://www.topografix.com/GPX/Private/TopoGrafix/0/4 http://www.topografix.com/GPX/Private/TopoGrafix/0/4/topografix.xsd"> <metadata> <bounds minlat="42.41224767" minlon="-71.53226082" maxlat="42.41965782" maxlon="-71.51356082"/> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2008-05-22T21:05:45.256Z</time> </extensions> </metadata> <trk> <type>Orange</type> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2008-05-22T21:05:45.256Z</time> <label xmlns="http://www.topografix.com/GPX/gpx_overlay/0/3"> <label_text>Orange Track</label_text> <text xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <font> <family generic="sans-serif"> <face>Arial</face> </family> </font> </text> </label> <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>ff6820</color> <opacity>1.00</opacity> <width>1.2500</width> <pattern>Solid</pattern> <extensions> <cased xmlns="http://www.topografix.com/GPX/Private/TopoGrafix/0/4">true</cased> </extensions> </line> </extensions> <trkseg> <trkpt lat="42.41965782" lon="-71.53226082"/> <trkpt lat="42.41321099" lon="-71.51356082"/> <trkpt lat="42.41276638" lon="-71.51506082"/> <trkpt lat="42.41224767" lon="-71.51606082"/> </trkseg> </trk> <extensions> </extensions> </gpx>
giorgio.ghisa+yahoo.co.in on Fri May 23 06:46:21 2008 (link), replying to msg
> You'll need to use an extension. There is already an existing > extension that several programs use to add color to tracks and > routes. An example is below. The next version of ExpertGPS will > allow you to specify a colored background for waypoint symbols - the > symbol itself will be specified by <sym>, and the colored background > will be in an extension schema. > > > Example: see <color> tag Thanks I undestand, the example is very simple. I think that I'll used this solution. Thanks very much, Giorgio
giorgio.ghisa+yahoo.co.in on Fri May 23 06:46:51 2008 (link), replying to msg
> http://www.elsinga.net/custom-waypoint-symbols.html > http://www.westernmaps.net/WM_WaypointSymbols/CustomWaypointSymbols.html > http://expertgps.com > http://www.gpsu.co.uk/ Theese links are very interesting, I think I'll see that. Thanks. If I'll have some more problems I'll tell in this forum, you'll be very thorough.
cadilegitimi+yahoo.com on Fri May 23 09:41:45 2008 (link)
Hello, I am new for GPS systems. I am going to build a web application with C#. I want to show our drivers current location and speed information on my web app map like google map. I do not know where i am going to start. Is there any GPS device that send its information and web services? then i can get that GPS device information via C#. or maybe you can recommend a phone and GPS system.. All I want to get is drivers info to my custom application Please recommend something for me . Thank you for your helps. [Non-text portions of this message have been removed]
egroups+topografix.com on Wed Jun 04 08:33:35 2008 (link), replying to msg
This is a forwarded message From: Solomon, Harry (GE Healthcare) <Harry.Solomon+med.ge.com> Date: Tuesday, June 3, 2008, 3:35:39 PM Subject: GPX as formal standard ===8<==============Original message text=============== There has been some recent discussion within the HL7 Standard organization (www.HL7.org <http://www.hl7.org/> ) about referencing a standard for GPS information. GPX has many of the desired qualities, but it is not a formal standard adopted by a formally constituted standards development organization. Has there been any consideration of submitting GPX as a standard through a formal body, such as OASIS (http://www.oasis-open.org <http://www.oasis-open.org/> ) ? - Harry Solomon Interoperability Architect GE Healthcare ===8<===========End of original message text=========== [Non-text portions of this message have been removed]
ek+imagepeaksystems.com on Fri Jun 27 17:37:20 2008 (link)
I'm new to the GPX format. I was looking for a standard for the symbology (symbols) and their naming convention? Is there such a thing and if so please help with link if available. Thanks; Gene in Colorado
dananderson2+yahoo.com on Fri Jun 27 17:48:20 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "eakcolorado" <ek+...> wrote: > > I'm new to the GPX format. I was looking for a standard for the > symbology (symbols) and their naming convention? Is there such a > thing and if so please help with link if available. There is no standard that I am aware of. I use Garmin names because they have a large number of defined symbols. Even Garmin doesn't exactly maintain a standard since for over a decade "Waypoint" was the default but now their color receiver models no longer support it. Dan A.
ek+imagepeaksystems.com on Sat Jun 28 08:10:38 2008 (link), replying to msg
Thanks Dan Gene in Colordo -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Dan Anderson Sent: Friday, June 27, 2008 6:48 PM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: Symbology --- In gpsxml+yahoogroups. <mailto:gpsxml%40yahoogroups.com> com, "eakcolorado" <ek+...> wrote: > > I'm new to the GPX format. I was looking for a standard for the > symbology (symbols) and their naming convention? Is there such a > thing and if so please help with link if available. There is no standard that I am aware of. I use Garmin names because they have a large number of defined symbols. Even Garmin doesn't exactly maintain a standard since for over a decade "Waypoint" was the default but now their color receiver models no longer support it. Dan A. [Non-text portions of this message have been removed]
zertam+hotmail.com on Sat Jun 28 11:38:08 2008 (link)
Hello, I only just recently learned about the points of interest (POI) feature my Garmin device has (it's the c340). So I've been playing around with it for the last week or so. I learned about the speed limit warning POIs (also known as "redlights") and sort of /just for fun/ I decided to start marking speed limit signs as I drive around. If I don't lose interest, I might adjust the locations of the POI's to between the signs, since you don't need a warning at the sign ? you can just see it ? but perhaps it could be useful in harsh weather, or for tourists that just don't know the area. I happen to live in a place that is near a summer tourist area, and also has many windy roads that don't always have well placed speed limit signs. But yeah, I have too much free time - but let's not go there. I don't know if this forum has any interest with Garmin's use of GPX format or not (I hope it does), and I don't really know if this is focused more on military use of the format, or if you guys care about consumer use of the format or not. There are a few things I'd like to be able to do - and I realize that even if the standard incorporates them in the future, it still won't help me, since my Garmin GPS device won't support it, but anyways... Ok, so I'm marking speed limit signs and converting them into POI's for my GPS device using the GPX format to allow me to set the proximity range for each 'sign'. Garmin defaults to something like a 45 second advanced warning, which would be dreadfully annoying, so I set it to a 5 second warning - (the time of the advanced warning is really calculated by my Garmin using the proximity range divided by the speed for the given alert). I'm sure any developer reading this probably knows this, so please forgive me. One issue I have is that it seems my device alerts me of the approaching POI (speed limit sign) if I'm close to the speed of the POI (seems to be �5 mph) ? that's ok, but it can become annoying if you pretty much know the speed limit, and are driving within �5 mph ? 5 mph over the speed limit is considered as an unwritten rule to be "acceptable" on most roads in good driving conditions and also if it's "driving with traffic." So I don't really want it to make a warning unless I'm going over the speed limit by more than 5 mph, but the only way I seem to be able to do that is to define the speed of the sign as +5 or +10 mph over what is really is. However, then my device will inform me that is what the "real" speed limit is ? but I want it to indicate the "real" speed limit but warn if I'm going +5 over it. Maybe there is a way I can define the displayed text that differs from the "speed setting", but it seems that the two are intertwined ? for example, to set a POI I write it as "[name]+ [speed]", but maybe there's another description tag I can use that my device will use in place of that ? I'll just have to toy around with it. So that's the first issue which there is a workaround for, but here's an issue that I don't believe there is a workaround for: creating POI's that only alert (are active) at a particular time of day ? say from 6am through 9am, and 1pm through 3pm. This is for school zone speed limits that are only in-affect at particular times. I don't know what the times are exactly; the signs usually have lights that blink when the reduced speed limit is in-affect. It would be useful to be able to define time constraints for particular waypoints or as I refer to them as POI's. Another thing I noticed is that speed limits can be different for different directions on the same road. I saw two signs on the same road within probably fifty feet of each other (on opposite sides of the road) ? one was 35mph, the other was 25mph. I suppose the GPX schema already supports a heading that could be used for a given POI, and it's just the Garmin device that doesn't support it. Well, that's it for now, and to summarize this inquiry: - Ability to define a speed limit warning threshold (probably something Garmin would have to implement, and the schema already supports such a thing ? since it also seems that a "speed" isn't really in the current schema already, and is just a custom one defined/created by Garmin. - Ability to define the times (time spans) when a waypoint is in-affect. - Ability to define the direction/heading for a waypoint to be in-affect. Sorry if this is the wrong forum for such discussions. -Zertam+hotmail.com
ek+imagepeaksystems.com on Sat Jun 28 11:38:55 2008 (link)
Thanks Dan and Simon: I complied a list from the garmin lists that you pointed me to. It comes up to about 150 icon names. Is there a place to go to fine even a minumun set of icons (bitmaps) to start building the image library? Thanks in advance... Gene in Colorado
sunburned.surveyor+gmail.com on Mon Jun 30 07:59:25 2008 (link), replying to msg
Would it be possible to define a standard as part of GPX? We could build on the existing list of symbol names. We could even link the names to a corresponding raster image or vector file, like SVG. I'd be interested in integrating that into my Java GPX library. The Sunburned Surveyor On Fri, Jun 27, 2008 at 7:11 PM, EK + Image Peak Systems <ek+imagepeaksystems.com> wrote: > Thanks Dan > > Gene in Colordo > > -----Original Message----- > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf > Of Dan Anderson > Sent: Friday, June 27, 2008 6:48 PM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Re: Symbology > > --- In gpsxml+yahoogroups. <mailto:gpsxml%40yahoogroups.com> com, > "eakcolorado" <ek+...> wrote: >> >> I'm new to the GPX format. I was looking for a standard for the >> symbology (symbols) and their naming convention? Is there such a >> thing and if so please help with link if available. > > There is no standard that I am aware of. I use Garmin names because > they have a large number of defined symbols. Even Garmin doesn't > exactly maintain a standard since for over a decade "Waypoint" was the > default but now their color receiver models no longer support it. > > Dan A. > > > [Non-text portions of this message have been removed] > >
dananderson2+yahoo.com on Mon Jun 30 10:38:15 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "eakcolorado" <ek+...> wrote: > I complied a list from the garmin lists that you pointed me to. > It comes up to about 150 icon names. Is there a place to go to fine > even a minumun set of icons (bitmaps) to start building the image > library? Garmin also has around 260 map poi symbols. If you download the cGPSmapper program, you will get a list of the mapping types. The US National Park Service makes their symbols available at: http://www.nps.gov/hfc/carto/map-symbols.htm I have a few at (and a few more that haven't been included yet): http://www.westernmaps.net/WM_WaypointSymbols/CustomWaypointSymbols.html These were intended primarily for hiking and to be used in Garmin receivers with custom waypoint symbols. A few symbols are intended to add back older Garmin symbols that aren't available in newer Garmin receivers. I wouldn't mind helping put together a symbol set freely available to everyone.
sunburned.surveyor+gmail.com on Mon Jun 30 10:38:58 2008 (link), replying to msg
Simon, I guess I wasn't thinking about using the standard on a mobile device, but of the opposite, using them on a Desktop. For example, I'd like to import a GPX file into OpenJUMP and display an appropriate symbol based on the information in the GPX file. I should have clarified my use case. The Sunburned Surveyor On Mon, Jun 30, 2008 at 10:01 AM, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > I await illumination and correction from the GPX experts here, but > until then ... > > On 30 Jun 2008, at 3:59pm, Sunburned Surveyor wrote: > >> Would it be possible to define a standard as part of GPX? > > You could define a set of strings that would be the minimum supported > symbols ... everything that supported GPX2 would have to, at least, > allow the use of those strings and have distinct icons for them. > >> We could >> build on the existing list of symbol names. > > You want more than 16 colours ? Let's say 256 colours (including > transparency) per icon. And icons should be at least 16 x 16 pixels. > So that's 8 bits per pixel making a byte. And 256 bytes per icon. So > you'll need 1K of memory for every four icons. You would have to have > had a good reason for adding new symbols back in the old days. > > Most devices that support GPX have to fit in a tiny little mobile > unit, drawing little power and using a slow processor. Some of them > even use 4-bit words. You don't add storage or processing load to > such a unit without good reason. > >> We could even link the >> names to a corresponding raster image or vector file, like SVG. I'd be >> interested in integrating that into my Java GPX library. > > You're thinking like a computer programmer: nice graphics, fast > display refresh, and lots of processing power and memory. It's > difficult to standardise images across manufacturers when they use > different icon sizes, and some have monochrome displays. Some of the > most popular GPS units around today are just minor improvements on old > designs. The Garmin GPSMap 60 had a four-level grayscale 160x240 > display and 24 Meg of memory. And that was introduced as a high end > model only four years ago, in 2004. The design and programming of all > units in that range still reflect that. > > The sort of thing you suggest would be fine for the current and future > generation of navigation devices -- probably expecting the features > that can be supplied by an automotive unit or a very high-tech unit > like an iPhone. You could define a new standard, and expect all units > designed in the future from the ground up to have at least 8-bit > memory access, 256 colours on the display, and the ability to position > icons down to pixel accuracy. And now wide busses and memory are > cheap you could rely on having a minimum set of, say, 128 symbols and > enough memory to hold icons for them all. > > Simon. > >
sunburned.surveyor+gmail.com on Mon Jun 30 10:40:21 2008 (link), replying to msg
Dan, I think this idea might catch fire at the OSGeo. Let me bounce an e-mail of the OSGeo group and I'll report back to this list. Landon On Mon, Jun 30, 2008 at 10:38 AM, Dan Anderson <dananderson2+yahoo.com> wrote: > --- In gpsxml+yahoogroups.com, "eakcolorado" <ek+...> wrote: >> I complied a list from the garmin lists that you pointed me to. >> It comes up to about 150 icon names. Is there a place to go to fine >> even a minumun set of icons (bitmaps) to start building the image >> library? > > Garmin also has around 260 map poi symbols. If you download the > cGPSmapper program, you will get a list of the mapping types. > > The US National Park Service makes their symbols available at: > http://www.nps.gov/hfc/carto/map-symbols.htm > > I have a few at (and a few more that haven't been included yet): > http://www.westernmaps.net/WM_WaypointSymbols/CustomWaypointSymbols.html > > These were intended primarily for hiking and to be used in Garmin > receivers with custom waypoint symbols. A few symbols are intended to > add back older Garmin symbols that aren't available in newer Garmin > receivers. > > I wouldn't mind helping put together a symbol set freely available to > everyone. > >
robertlipe+usa.net on Mon Jun 30 10:43:19 2008 (link)
> I await illumination and correction from the GPX experts here, but > until then ... Your answer is pretty close to what I'd have typed. I have the impression that formalizing this is an unwinnable battle unless it comes from the GPS vendors. Issues of installed base will make it hard to wag that dog. What I've done in GPSBabel - which tries to preserve icon names across products from different vendors - is to be liberal in what I accept on a read but try to write what came from the vendor. So when I write to a Garmin, for example, I'll accept a <sym> of "Residence" or "House". When I read from a Garmin, I use the Garmin name, "Residence". The Magellan modules also accept both when I'm writing to them, but on a read we prefer the Magellan spelling of "House". Yes, it requires lots of icky tables that are a pain to maintain.
robertlipe+usa.net on Wed Jul 02 21:29:50 2008 (link)
> What with the explosion of devices which can tell you your location, I > suspect that many internet messages will soon include longitude and > latitude information. This is fine but it would be convenient if all > these cites were in a standard format. That way software could Define "internet messages". (That's not a troll, Simon.) There are a variety of microformats. What's catching on in the GeoRSS world may not be appropriate for, say, Twitter-like substances. I'm not saying that's a great state, but I see it shaping up to take several different shapes depending on the niche.
ptomblin+gmail.com on Thu Jul 03 06:22:33 2008 (link), replying to msg
On Thu, 3 Jul 2008 10:25:11 +0100 "Simon Slavin" <slavins+hearsay.demon.co.uk> wrote: >People on another list told me that any format I invent had better be >able to deal with direction as well as position, so I expanded my >format to five parameters: > ><geoloc:latitude,longitude,altitude,direction,tilt> I would think <geoloc latitude="NN.NNN" longitude="NN.NNN"/> would be more XML-like, and would make the optional parameters clearer.
ajcartmell+fonant.com on Thu Jul 03 07:06:56 2008 (link), replying to msg
>> <geoloc:latitude,longitude,altitude,direction,tilt> > > I would think <geoloc latitude="NN.NNN" longitude="NN.NNN"/> would be > more > XML-like, and would make the optional parameters clearer. Or perhaps borrow from KML, now known as "OpenGIS� KML Encoding Standard" (OGC KML). It is now maintained by the Open Geospatial Consortium, Inc. (OGC) rather than Google. http://www.opengeospatial.org/standards/kml/ A KML Placemark can contain all sorts of useful information in a pretty flexible way. It also allows for areas (and lines) as well as discrete points, so might be useful for cities, states, etc. where a single point is less relevant. Anthony -- www.fonant.com - Quality web sites
ajcartmell+fonant.com on Thu Jul 03 12:22:54 2008 (link), replying to msg
> "I went to the new local Ford dealership <geoloc:154.123,0.1> and > asked about service." Ah, I see. Do you want that code displayed to the user as-is, or rendered somehow by the browser? If you just want a link, an http URL that returns a KML or GPX document would work, using whatever mapping software the user has installed? If you're looking for something that's embedded, perhaps the various geotagging formats described at Wikipedia might be worth looking into? http://en.wikipedia.org/wiki/Geotagging and the two markup templates used for geotagging Wikipedia articles: http://en.wikipedia.org/wiki/Template:Coor_title_dms http://en.wikipedia.org/wiki/Template:Coord http://en.wikipedia.org/w/index.php?title=Special:PrefixIndex&from=Geolinks&namespace=10 http://en.wikipedia.org/w/index.php?title=Special:PrefixIndex&from=Mapit&namespace=10 Sadly not everyone uses the same format in Wikipedia, as geonames.org has discovered. HTH, Anthony -- www.fonant.com - Quality web sites
yahoo.id+magnell.org on Sat Jul 05 05:22:23 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > So how does one get started defining such a thing ? Would the URL > format be appropriate: > > <geoloc:54.123,1.234> > > or is there something better ? There is already proposal (internet draft) within the IETF geopriv working group for a geolocation URI. "A Uniform Resource Identifier for Geographic Locations ('geo' URI)" It is very similar to what you are suggesting. The document may be found at: http://tools.ietf.org/id/draft-mayrhofer-geopriv-geo-uri-00.txt
andy+pigsonthewing.org.uk on Sat Jul 12 11:15:12 2008 (link)
In message <BA8CAEC1-AA91-4824-A011-A95E06050EC9+hearsay.demon.co.uk>, Simon Slavin <slavins+hearsay.demon.co.uk> writes >On 30 Jun 2008, at 6:38pm, Sunburned Surveyor wrote: > >> I guess I wasn't thinking about using the standard on a mobile device, >> but of the opposite, using them on a Desktop. For example, I'd like to >> import a GPX file into OpenJUMP and display an appropriate symbol >> based on the information in the GPX file. > >I understand entirely, your desire for a standardised set of names and >icons to use on computers. I can understand having a set of standard names; but not symbols - different nations use different symbols, not least on their paper maps and road signs. Here's a document (PDF. 338Kb) with the symbols used on UK Ordnance Survey maps: <http://www.ordnancesurvey.co.uk/education/pdf/25knewEGMlegend.pdf> They're not the same as those used on, say, French or Canadian maps. If a standard set of names existed, users, could choose their preferred set of symbols, for a hand-held device or a PC, just like adding a different "skin" to a browser or media player. -- Andy Mabbett Says "NO! to compulsory UK ID Cards": <http://www.no2id.net/> and: "Free Our Data": <http://www.freeourdata.org.uk> (both also on Facebook)
andy+pigsonthewing.org.uk on Sat Jul 12 11:15:14 2008 (link)
In message <5CF6D2BD-1071-493B-8952-66473D7C2B3A+hearsay.demon.co.uk>, Simon Slavin <slavins+hearsay.demon.co.uk> writes >>> I >>> suspect that many internet messages will soon include longitude and >>> latitude information. This is fine but it would be convenient if all >>> these cites were in a standard format. >> Define "internet messages". > >email messages, blog entries and comments, web pages, usenet messages, >Instant Messages. If possible, should be useful in SMS as well. It's unlikely that one "standard format" will suit all those media. >I have no idea what Twitter messages look like 140 characters, for example: <http://twitter.com/pigsonthewing/statuses/849487036> so (as with SMS) brevity is important. >but you can encode >URLs in most IM systems I've seen and the software can deal with them >in useful ways. Can someone who Twitters tell me if URLs work okay ? Yes, but they're usually converted to "TinyURLs": <http://tinyurl.com> for the above reason. >People on another list told me that any format I invent Don't invent; reuse. The Twitter post cited above: Wonder if anyone is parsing #geotagged posts like this: #geo:lat:52.478342 #geo:long:-1.895389 ( #birminghamuk #rotunda #geo #geotag) (where the hash prefix denotes tags) reuses the "Machine Tag" aka "Triple Tag" format: <http://en.wikipedia.org/wiki/Triple_tag> as used on Flickr: <http://flickr.com/photos/pigsonthewing/2360534419/> and elsewhere. >had better be >able to deal with direction as well as position, so I expanded my >format to five parameters: > ><geoloc:latitude,longitude,altitude,direction,tilt> Though you only need to encode all those attributes in some cases (The Rotunda doesn't move!), machine tags would cope with all of them. Machine tags can also be used on blogs, and in regular HTML pages: <a href="http://example.com.tags/geo:lat:52.479692" rel="tag"> geo:lat:52.479692 </a> as on: <http://pigsonthewing.wordpress.com/2007/11/23/oops/> Coordinates in HTML can also be marked up using the geo microformat: <http://microformats.org/wiki/geo> thus: <span class="geo"> <span class="latitude"> 52.479692 </span>, <span class="longitude"> -1.905848 </span> </span> Incidentally, there is a proposal for a URI syntax for coordinates: <http://tools.ietf.org/id/draft-mayrhofer-geopriv-geo-uri-00.txt> -- Andy Mabbett Says "NO! to compulsory UK ID Cards": <http://www.no2id.net/> and: "Free Our Data": <http://www.freeourdata.org.uk> (both also on Facebook)
andy+pigsonthewing.org.uk on Sun Jul 13 04:41:36 2008 (link), replying to msg
In message <FAA4D050-0516-4546-9516-57A4DEF5325D+hearsay.demon.co.uk>, Simon Slavin <slavins+hearsay.demon.co.uk> writes > >On 12 Jul 2008, at 7:14pm, Andy Mabbett wrote: > >> Don't invent; reuse. The Twitter post cited above: >> >> Wonder if anyone is parsing #geotagged posts like this: >> #geo:lat:52.478342 #geo:long:-1.895389 ( #birminghamuk #rotunda >> #geo #geotag) >> >> (where the hash prefix denotes tags) reuses the "Machine Tag" aka >> "Triple Tag" format: >> >> <http://en.wikipedia.org/wiki/Triple_tag> >Yes, I've seen that tagging format. Yes; you said you wanted to be able to "quote" geolocation... > Unfortunately, email and web software isn't already programmed to know >what to do when it encounters it. That's why I used a URI scheme. >If anyone wants to read my current specification of my idea, see > >http://www.hearsay.demon.co.uk/geoloc/index.html ...but now it seems that you want to link to some sort of representation of a geolocation. As I pointed out in my last post: there is a proposal for a URI syntax for coordinates: <http://tools.ietf.org/id/draft-mayrhofer-geopriv-geo-uri-00.txt> If you see some sort of problem with that, it would probably be more helpful for you to collaborate with its authors, than to propose an alternative scheme. Incidentally, there's an error in the example I gave; "#geo:long:-1.895389" should be "#geo:lon:-1.895389" ("lon" not "long"). -- Andy Mabbett Says "NO! to compulsory UK ID Cards": <http://www.no2id.net/> and: "Free Our Data": <http://www.freeourdata.org.uk> (both also on Facebook)
olopierpa+gmail.com on Sun Jul 13 18:12:29 2008 (link), replying to msg
On 7/3/08, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > On 3 Jul 2008, at 3:06pm, Anthony Cartmell wrote: > > >>> <geoloc:latitude,longitude,altitude,direction,tilt> > >> > >> I would think <geoloc latitude="NN.NNN" longitude="NN.NNN"/> would be > >> more > >> XML-like, and would make the optional parameters clearer. > > > > Or perhaps borrow from KML > > Or I could use GPX. But I've never seen any of these formats used for > specifying a location in the middle of a human-readable message. I'm > trying to devise something that people would use like this: > > "I went to the new local Ford dealership <geoloc:154.123,0.1> and > asked about service." > > In the much the same way as they would quote a URL: > > "I went to the new local Ford <http://www.ford.com> dealership and > asked about service." Why not http://en.wikipedia.org/wiki/Geohash ? Cheers P.
carlos.tejo+gmail.com on Mon Jul 14 04:01:18 2008 (link), replying to msg
Hej! > Machine tags can also be used on blogs, and in regular HTML pages: > > <a href="http://example.com.tags/geo:lat:52.479692" rel="tag"> > geo:lat:52.479692 </a> > > as on: <http://pigsonthewing.wordpress.com/2007/11/23/oops/> > > Coordinates in HTML can also be marked up using the geo microformat: > <http://microformats.org/wiki/geo> > thus: > <span class="geo"> > <span class="latitude">52.479692</span>, > <span class="longitude">-1.905848</span> > </span> > There is a "tutorial" from the people of RDFa (W3C) about "Adding Geolocation information to HTML" that maybe is useful in that point http://rdfa.info/wiki/Geo-tutorial Regards, Carlos Tejo
bobo111059+yahoo.com on Mon Jul 14 09:09:29 2008 (link)
I need to export route that are created in a application using MapInfo to GPX for use with the Garmin Nuvi 760. I was albe to generate KML the represents the route, but I am not understanding the all the GPX tag that are necessary to represent the route. Can some one point me to the specifications that explain the tags not just the schema for GPX? My biggest question is what the tags for the route extension value are. The attached code will not open in the Mapsource program. <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v1 " creator="nüvi 7 Series" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.garmin.com/xmlschemas/GpxExtensions/v3 http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd "> <metadata> <link href="http://www.garmin.com"> <text>Garmin International</text> </link> <time>2008-07-10T15:32:58Z</time> </metadata> <rte> <name>Transfinder Trip</name> <rtept lat="42.8199,0" lon="-73.9276"> <name>Transfinder</name> <extensions> <gpxx:RoutePointExtension> <gpxx:rpt lat="42.8201" lon="-73.92910000000001"/> <gpxx:rpt lat="42.8203" lon="-73.9302"/> <gpxx:rpt lat="42.8203" lon="-73.93089999999999"/> <gpxx:rpt lat="42.8206" lon="-73.9315"/> <gpxx:rpt lat="42.8206" lon="-73.9318"/> <gpxx:rpt lat="42.820601" lon="-73.932001"/> <gpxx:rpt lat="42.8193" lon="-73.93429999999999"/> <gpxx:rpt lat="42.819" lon="-73.9344"/> <gpxx:rpt lat="42.8187" lon="-73.9348"/> <gpxx:rpt lat="42.8171" lon="-73.9359"/> <gpxx:rpt lat="42.815742" lon="-73.936773"/> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.815742" lon="-73.936773"> <name>Stewart</name> <extensions> <gpxx:RoutePointExtension> <gpxx:rpt lat="42.8157" lon="-73.93680000000001"/> <gpxx:rpt lat="42.814" lon="-73.9371"/> <gpxx:rpt lat="42.8128" lon="-73.93859999999999"/> <gpxx:rpt lat="42.8121" lon="-73.93940000000001"/> <gpxx:rpt lat="42.8115" lon="-73.94029999999999"/> <gpxx:rpt lat="42.8111" lon="-73.93940000000001"/> <gpxx:rpt lat="42.8104" lon="-73.9391"/> <gpxx:rpt lat="42.8102" lon="-73.93940000000001"/> <gpxx:rpt lat="42.8096" lon="-73.9392"/> <gpxx:rpt lat="42.809" lon="-73.93859999999999"/> <gpxx:rpt lat="42.8083" lon="-73.9383"/> <gpxx:rpt lat="42.8075" lon="-73.9379"/> <gpxx:rpt lat="42.8068" lon="-73.93689999999999"/> <gpxx:rpt lat="42.8062" lon="-73.9362"/> <gpxx:rpt lat="42.8052" lon="-73.93680000000001"/> <gpxx:rpt lat="42.8043" lon="-73.9371"/> <gpxx:rpt lat="42.8041" lon="-73.9374"/> <gpxx:rpt lat="42.8035" lon="-73.9378"/> <gpxx:rpt lat="42.8026" lon="-73.9383"/> <gpxx:rpt lat="42.8019" lon="-73.93859999999999"/> <gpxx:rpt lat="42.8012" lon="-73.9391"/> <gpxx:rpt lat="42.8006" lon="-73.93940000000001"/> <gpxx:rpt lat="42.8004" lon="-73.93980000000001"/> <gpxx:rpt lat="42.7997" lon="-73.9413"/> <gpxx:rpt lat="42.7996" lon="-73.9421"/> <gpxx:rpt lat="42.7995" lon="-73.94240000000001"/> <gpxx:rpt lat="42.799" lon="-73.9423"/> <gpxx:rpt lat="42.7988" lon="-73.94199999999999"/> <gpxx:rpt lat="42.7984" lon="-73.94159999999999"/> <gpxx:rpt lat="42.798" lon="-73.94150000000001"/> <gpxx:rpt lat="42.7963" lon="-73.9409"/> </gpxx:RoutePointExtension> </extensions> </rtept> </rte> </gpx> Thanks, Bob Olsen
robertlipe+usa.net on Tue Jul 15 06:06:36 2008 (link)
------ Original Message ------ Received: Mon, 14 Jul 2008 11:09:33 AM CDT From: "bobo111059" <bobo111059+yahoo.com> To: gpsxml+yahoogroups.com Subject: [gpsxml] GPX route for Garmin Nuvi 760 > I need to export route that are created in a application using > MapInfo to GPX for use with the Garmin Nuvi 760. I was albe to > generate KML the represents the route, but I am not understanding > the all the GPX tag that are necessary to represent the route. Can > some one point me to the specifications that explain the tags not > just the schema for GPX? My biggest question is what the tags for > the route extension value are. The attached code will not open in > the Mapsource program. GPX itself is documented at http://www.topografix.com/GPX/1/1/ Yes, it's the schema, but has links that can be expanded for textual descriptions of each tag. See http://www.topografix.com/gpx_validation.asp for tools in finding problems in GPX files. What you have here is a GPX route with two points, a touch of metadata, and some housekeeping overhead. All the gpxx: stuff is a Garmin extension. See their doc at http://developer.garmin.com/web-device/garmin-mass-storage-mode-devices/ for the justification and description of that. RJL
bobo111059+yahoo.com on Thu Jul 17 13:39:42 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+...> wrote: > > > > ------ Original Message ------ > Received: Mon, 14 Jul 2008 11:09:33 AM CDT > From: "bobo111059" <bobo111059+...> > To: gpsxml+yahoogroups.com > Subject: [gpsxml] GPX route for Garmin Nuvi 760 > > > I need to export route that are created in a application using > > MapInfo to GPX for use with the Garmin Nuvi 760. I was albe to > > generate KML the represents the route, but I am not understanding > > the all the GPX tag that are necessary to represent the route. Can > > some one point me to the specifications that explain the tags not > > just the schema for GPX? My biggest question is what the tags for > > the route extension value are. The attached code will not open in > > the Mapsource program. > > GPX itself is documented at http://www.topografix.com/GPX/1/1/ Yes, it's > the schema, but has links that can be expanded for textual descriptions > of each tag. > > See http://www.topografix.com/gpx_validation.asp for tools in finding > problems > in GPX files. > > What you have here is a GPX route with two points, a touch of metadata, and > some housekeeping overhead. All the gpxx: stuff is a Garmin extension. See > their doc at > http://developer.garmin.com/web-device/garmin-mass-storage-mode- devices/ > for the justification and description of that. > > > > RJL > While all information was helpful I still don't understand the Garmin Route extensions. In particular the "gpxx:Subclass". All I can find is that it is a hex value. I need to create a route that will be used by school bus drivers. I have created a gpx file and loaded the file on the Garmin nuvi 760. The route looks ok but my stops do not show up. Each stop is an "rtept" and I used "gpxx:rpt" extensions to make sure that the bus follows the correct roads. I can not let the Garmin chose the route because school buses have safety rules the need to adhere to. Like kids can not cross 4 lane highway? Here is an example route. <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v1 " creator="nuvi 7 Series" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.garmin.com/xmlschemas/GpxExtensions/v3 http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd "> <rte> <name>102 BMS AM</name> <rtept lat="42.664379" lon="-73.754164"> <time>2008-07-16T17:48:13Z</time> <name>Lark Dr & Lark St & Manning Blvd N & N Manning Blvd</name> <cmt>Lark Dr & Lark St & Manning Blvd N & N Manning Blvd</cmt> <desc>Lark Dr & Lark St & Manning Blvd N & N Manning Blvd</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.755634" lat="42.663101"> <gpxx:Subclass>01000AA9B1FFD77942B6909800D25993960D</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.756407" lat="42.66243"> <gpxx:Subclass>01000314C0445E3B453DB7C14136CD6A50C6</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.66243" lon="-73.756407"> <time>2008-07-16T17:48:13Z</time> <name>Lark St & Livingston Ave</name> <cmt>Lark St & Livingston Ave</cmt> <desc>Lark St & Livingston Ave</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.757271" lat="42.661681"> <gpxx:Subclass>010011BF88BCEF7E4A96B11FC2612D0CCC6E</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.758012" lat="42.661038"> <gpxx:Subclass>0100436C0D021CE84267900E8D56B9A635A9</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.75866" lat="42.660476"> <gpxx:Subclass>01001908CB0338924D5293DC7DBA9DC46D0F</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.660476" lon="-73.75866"> <time>2008-07-16T17:48:13Z</time> <name>1st St & Lark St</name> <cmt>1st St & Lark St</cmt> <desc>1st St & Lark St</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.759437" lat="42.659802"> <gpxx:Subclass>0100F3A68FA0D44147AEA92F5A4205A2A30A</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.759753" lat="42.659989"> <gpxx:Subclass>0100E447952AF66E4AD7B5AC304A8CCC057E</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.760359" lat="42.65944"> <gpxx:Subclass>0100FC9F6C21CCEF45EE808BF4458ECF6125</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.76109" lat="42.658779"> <gpxx:Subclass>0100BDDC4000697E43DF844B548D06FB9531</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.761546" lat="42.658368"> <gpxx:Subclass>01004E69BB740E2544A2A36218F4A98ED75A</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.658368" lon="-73.761546"> <time>2008-07-16T17:48:13Z</time> <name>Lark St & Spruce St & United States Highway 9</name> <cmt>Lark St & Spruce St & United States Highway 9</cmt> <desc>Lark St & Spruce St & United States Highway 9</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.761759" lat="42.658176"> <gpxx:Subclass>0100794F2E9293A24925884CFA30C1A948B2</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.762266" lat="42.657717"> <gpxx:Subclass>010028C66EDC4C1A4CF180F336C77A936BA6</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.762758" lat="42.657272"> <gpxx:Subclass>01008E5F7071435B4EF5890F1393894F7923</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.763372" lat="42.656716"> <gpxx:Subclass>0100EDE03E23A6F44EAEB013ECBE0038C5D8</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.76385" lat="42.656284"> <gpxx:Subclass>0100BF2D5EDCB1A342DAAE8C3F5FC8175D9D</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.656284" lon="-73.76385"> <time>2008-07-16T17:48:13Z</time> <name>Lark St & Spring St & State Highway 443 & United States Highway</name> <cmt>Lark St & Spring St & State Highway 443 & United States Highway</cmt> <desc>Lark St & Spring St & State Highway 443 & United States Highway</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.764287" lat="42.655889"> <gpxx:Subclass>010015D6C99BE7DF4A57881775ADF35B9177</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.764857" lat="42.655374"> <gpxx:Subclass>0100DBC0B6E2D458426ABDC1422CA611719E</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.765351" lat="42.654927"> <gpxx:Subclass>010096F00FC7759C41EBABDF9BACCBC6BB3E</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.765921" lat="42.654412"> <gpxx:Subclass>010042165AD9B89D4078B58793BA05ED7348</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.654412" lon="-73.765921"> <time>2008-07-16T17:48:13Z</time> <name>Jay St & Lark St & State Highway 443 & United States Highway 9</name> <cmt>Jay St & Lark St & State Highway 443 & United States Highway 9</cmt> <desc>Jay St & Lark St & State Highway 443 & United States Highway 9</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.766478" lat="42.653908"> <gpxx:Subclass>010063EF34AB482C4DD08FA9488B3F4BA988</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.767065" lat="42.653379"> <gpxx:Subclass>01009E93DAECE4254E21AE0E3FCB59A035DB</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.653379" lon="-73.767065"> <time>2008-07-16T17:48:13Z</time> <name>Hamilton St & Lark St & State Highway 443 & United States Highwa</name> <cmt>Hamilton St & Lark St & State Highway 443 & United States Highwa</cmt> <desc>Hamilton St & Lark St & State Highway 443 & United States Highwa</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.767973" lat="42.652469"> <gpxx:Subclass>01007B49667130CD41B4BE3FF4BE6D8E6951</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.768107" lat="42.652073"> <gpxx:Subclass>0100659935BA272D46B7B8D8C760F07C88C8</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.768209" lat="42.651638"> <gpxx:Subclass>0100EC3D885A239B4FBF828B8106DDF4F9C7</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.76827" lat="42.651381"> <gpxx:Subclass>0100424BAF75A9EB4B78ACE0BF564F79DBC2</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.768365" lat="42.650979"> <gpxx:Subclass>01008FDBC21861384103B9ACA17418B3C106</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.650979" lon="-73.768365"> <time>2008-07-16T17:48:13Z</time> <name>Delaware Ave & Morris St & State Highway 443 & United States Hig</name> <cmt>Delaware Ave & Morris St & State Highway 443 & United States Hig</cmt> <desc>Delaware Ave & Morris St & State Highway 443 & United States Hig</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.76906" lat="42.65138"> <gpxx:Subclass>010013BEF866F7A9496A982AE34AED43C55D</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.771259" lat="42.652652"> <gpxx:Subclass>01009A5B67BC31E54BB8A009FF193143FA06</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.773396" lat="42.653887"> <gpxx:Subclass>0100BD2D5E4987294B078271E17AAD8729CC</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.653887" lon="-73.773396"> <time>2008-07-16T17:48:13Z</time> <name>Morris St & New Scotland Ave</name> <cmt>Morris St & New Scotland Ave</cmt> <desc>Morris St & New Scotland Ave</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.775564" lat="42.65514"> <gpxx:Subclass>01005C5834022E4E47779DAF028EC423BB01</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.778813" lat="42.657018"> <gpxx:Subclass>0100FD4DEEA216184330896773A5FC07E48F</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.781077" lat="42.658327"> <gpxx:Subclass>0100C605EF5FDB314676BF6824FBCD4B82E7</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.658327" lon="-73.781077"> <time>2008-07-16T17:48:13Z</time> <name>Morris St & Quail St</name> <cmt>Morris St & Quail St</cmt> <desc>Morris St & Quail St</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.781734" lat="42.657709"> <gpxx:Subclass>0100D68E90BB2D0446D6A8E63C91E8C1967D</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.784024" lat="42.659021"> <gpxx:Subclass>010021BC85B8AD1A4FCBA8F14133BBA13D67</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.785072" lat="42.659621"> <gpxx:Subclass>01005D5FD2C4D1B74CC286EEBE8848883D56</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.65962" lon="-73.78507"> <time>2008-07-16T17:48:13Z</time> <name>Bryan Elementary School</name> <cmt>Bryan Elementary School</cmt> <desc>Bryan Elementary School</desc> <sym>School</sym> </rtept> </rte> </gpx>
bobo111059+yahoo.com on Thu Jul 17 13:39:48 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Robert Lipe" <robertlipe+...> wrote: > > > > ------ Original Message ------ > Received: Mon, 14 Jul 2008 11:09:33 AM CDT > From: "bobo111059" <bobo111059+...> > To: gpsxml+yahoogroups.com > Subject: [gpsxml] GPX route for Garmin Nuvi 760 > > > I need to export route that are created in a application using > > MapInfo to GPX for use with the Garmin Nuvi 760. I was albe to > > generate KML the represents the route, but I am not understanding > > the all the GPX tag that are necessary to represent the route. Can > > some one point me to the specifications that explain the tags not > > just the schema for GPX? My biggest question is what the tags for > > the route extension value are. The attached code will not open in > > the Mapsource program. > > GPX itself is documented at http://www.topografix.com/GPX/1/1/ Yes, it's > the schema, but has links that can be expanded for textual descriptions > of each tag. > > See http://www.topografix.com/gpx_validation.asp for tools in finding > problems > in GPX files. > > What you have here is a GPX route with two points, a touch of metadata, and > some housekeeping overhead. All the gpxx: stuff is a Garmin extension. See > their doc at > http://developer.garmin.com/web-device/garmin-mass-storage-mode- devices/ > for the justification and description of that. > > > > RJL > While all above information was helpful I still don't understand the Garmin Route extensions. In particular the "gpxx:Subclass". All I can find is that it is a hex value. I need to create a route that will be used by school bus drivers. I have created a gpx file and loaded the file on the Garmin nuvi 760. The route looks ok but my stops do not show up. Each stop is an "rtept" and I used "gpxx:rpt" extensions to make sure that the bus follows the correct roads. I can not let the Garmin chose the route because school buses have safety rules the need to adhere to. Like kids can not cross 4 lane highway? Is there documentation that explains the "gpxx:Subclass". Thanks, Bob Olsen Here is an example route. <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v1 " creator="nuvi 7 Series" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.garmin.com/xmlschemas/GpxExtensions/v3 http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd "> <rte> <name>102 BMS AM</name> <rtept lat="42.664379" lon="-73.754164"> <time>2008-07-16T17:48:13Z</time> <name>Lark Dr & Lark St & Manning Blvd N & N Manning Blvd</name> <cmt>Lark Dr & Lark St & Manning Blvd N & N Manning Blvd</cmt> <desc>Lark Dr & Lark St & Manning Blvd N & N Manning Blvd</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.755634" lat="42.663101"> <gpxx:Subclass>01000AA9B1FFD77942B6909800D25993960D</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.756407" lat="42.66243"> <gpxx:Subclass>01000314C0445E3B453DB7C14136CD6A50C6</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.66243" lon="-73.756407"> <time>2008-07-16T17:48:13Z</time> <name>Lark St & Livingston Ave</name> <cmt>Lark St & Livingston Ave</cmt> <desc>Lark St & Livingston Ave</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.757271" lat="42.661681"> <gpxx:Subclass>010011BF88BCEF7E4A96B11FC2612D0CCC6E</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.758012" lat="42.661038"> <gpxx:Subclass>0100436C0D021CE84267900E8D56B9A635A9</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.75866" lat="42.660476"> <gpxx:Subclass>01001908CB0338924D5293DC7DBA9DC46D0F</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.660476" lon="-73.75866"> <time>2008-07-16T17:48:13Z</time> <name>1st St & Lark St</name> <cmt>1st St & Lark St</cmt> <desc>1st St & Lark St</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.759437" lat="42.659802"> <gpxx:Subclass>0100F3A68FA0D44147AEA92F5A4205A2A30A</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.759753" lat="42.659989"> <gpxx:Subclass>0100E447952AF66E4AD7B5AC304A8CCC057E</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.760359" lat="42.65944"> <gpxx:Subclass>0100FC9F6C21CCEF45EE808BF4458ECF6125</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.76109" lat="42.658779"> <gpxx:Subclass>0100BDDC4000697E43DF844B548D06FB9531</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.761546" lat="42.658368"> <gpxx:Subclass>01004E69BB740E2544A2A36218F4A98ED75A</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.658368" lon="-73.761546"> <time>2008-07-16T17:48:13Z</time> <name>Lark St & Spruce St & United States Highway 9</name> <cmt>Lark St & Spruce St & United States Highway 9</cmt> <desc>Lark St & Spruce St & United States Highway 9</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.761759" lat="42.658176"> <gpxx:Subclass>0100794F2E9293A24925884CFA30C1A948B2</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.762266" lat="42.657717"> <gpxx:Subclass>010028C66EDC4C1A4CF180F336C77A936BA6</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.762758" lat="42.657272"> <gpxx:Subclass>01008E5F7071435B4EF5890F1393894F7923</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.763372" lat="42.656716"> <gpxx:Subclass>0100EDE03E23A6F44EAEB013ECBE0038C5D8</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.76385" lat="42.656284"> <gpxx:Subclass>0100BF2D5EDCB1A342DAAE8C3F5FC8175D9D</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.656284" lon="-73.76385"> <time>2008-07-16T17:48:13Z</time> <name>Lark St & Spring St & State Highway 443 & United States Highway</name> <cmt>Lark St & Spring St & State Highway 443 & United States Highway</cmt> <desc>Lark St & Spring St & State Highway 443 & United States Highway</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.764287" lat="42.655889"> <gpxx:Subclass>010015D6C99BE7DF4A57881775ADF35B9177</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.764857" lat="42.655374"> <gpxx:Subclass>0100DBC0B6E2D458426ABDC1422CA611719E</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.765351" lat="42.654927"> <gpxx:Subclass>010096F00FC7759C41EBABDF9BACCBC6BB3E</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.765921" lat="42.654412"> <gpxx:Subclass>010042165AD9B89D4078B58793BA05ED7348</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.654412" lon="-73.765921"> <time>2008-07-16T17:48:13Z</time> <name>Jay St & Lark St & State Highway 443 & United States Highway 9</name> <cmt>Jay St & Lark St & State Highway 443 & United States Highway 9</cmt> <desc>Jay St & Lark St & State Highway 443 & United States Highway 9</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.766478" lat="42.653908"> <gpxx:Subclass>010063EF34AB482C4DD08FA9488B3F4BA988</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.767065" lat="42.653379"> <gpxx:Subclass>01009E93DAECE4254E21AE0E3FCB59A035DB</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.653379" lon="-73.767065"> <time>2008-07-16T17:48:13Z</time> <name>Hamilton St & Lark St & State Highway 443 & United States Highwa</name> <cmt>Hamilton St & Lark St & State Highway 443 & United States Highwa</cmt> <desc>Hamilton St & Lark St & State Highway 443 & United States Highwa</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.767973" lat="42.652469"> <gpxx:Subclass>01007B49667130CD41B4BE3FF4BE6D8E6951</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.768107" lat="42.652073"> <gpxx:Subclass>0100659935BA272D46B7B8D8C760F07C88C8</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.768209" lat="42.651638"> <gpxx:Subclass>0100EC3D885A239B4FBF828B8106DDF4F9C7</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.76827" lat="42.651381"> <gpxx:Subclass>0100424BAF75A9EB4B78ACE0BF564F79DBC2</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.768365" lat="42.650979"> <gpxx:Subclass>01008FDBC21861384103B9ACA17418B3C106</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.650979" lon="-73.768365"> <time>2008-07-16T17:48:13Z</time> <name>Delaware Ave & Morris St & State Highway 443 & United States Hig</name> <cmt>Delaware Ave & Morris St & State Highway 443 & United States Hig</cmt> <desc>Delaware Ave & Morris St & State Highway 443 & United States Hig</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.76906" lat="42.65138"> <gpxx:Subclass>010013BEF866F7A9496A982AE34AED43C55D</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.771259" lat="42.652652"> <gpxx:Subclass>01009A5B67BC31E54BB8A009FF193143FA06</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.773396" lat="42.653887"> <gpxx:Subclass>0100BD2D5E4987294B078271E17AAD8729CC</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.653887" lon="-73.773396"> <time>2008-07-16T17:48:13Z</time> <name>Morris St & New Scotland Ave</name> <cmt>Morris St & New Scotland Ave</cmt> <desc>Morris St & New Scotland Ave</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.775564" lat="42.65514"> <gpxx:Subclass>01005C5834022E4E47779DAF028EC423BB01</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.778813" lat="42.657018"> <gpxx:Subclass>0100FD4DEEA216184330896773A5FC07E48F</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.781077" lat="42.658327"> <gpxx:Subclass>0100C605EF5FDB314676BF6824FBCD4B82E7</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.658327" lon="-73.781077"> <time>2008-07-16T17:48:13Z</time> <name>Morris St & Quail St</name> <cmt>Morris St & Quail St</cmt> <desc>Morris St & Quail St</desc> <sym>School</sym> <extensions> <gpxx:RoutePointExtension> <gpxx:Subclass>000000000000ffffffff0000000000000000</gpxx:Subclass> <gpxx:rpt lon="-73.781734" lat="42.657709"> <gpxx:Subclass>0100D68E90BB2D0446D6A8E63C91E8C1967D</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.784024" lat="42.659021"> <gpxx:Subclass>010021BC85B8AD1A4FCBA8F14133BBA13D67</gpxx:Subclass> </gpxx:rpt> <gpxx:rpt lon="-73.785072" lat="42.659621"> <gpxx:Subclass>01005D5FD2C4D1B74CC286EEBE8848883D56</gpxx:Subclass> </gpxx:rpt> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="42.65962" lon="-73.78507"> <time>2008-07-16T17:48:13Z</time> <name>Bryan Elementary School</name> <cmt>Bryan Elementary School</cmt> <desc>Bryan Elementary School</desc> <sym>School</sym> </rtept> </rte> </gpx>
robertlipe+usa.net on Thu Jul 17 14:03:09 2008 (link)
> While all above information was helpful I still don't understand the > Garmin Route extensions. In particular the "gpxx:Subclass". All I Garmin's extensions aren't really well designed in that regard; many of their fields are just hex encodings of what their firmware uses internally and really aren't designed for interoperability like GPX itself is. I encourage you to seek more info about it on developer.garmin.com. RJL
Matt+mnorwood.com on Thu Jul 17 17:08:56 2008 (link)
I'm looking to add a custom element to the extensions type for waypoints. I see the xsd has spots all over it where you can add your own elements, but my question is how and where exactly? I haven't worked with XML all that much. Say I want to add an element called "temperature" and it is a type of "float" from a namespace called "tmp" So ultimately in my GPX file I end up with: <wpt lat="27.001" lon="-86.000004"> <time>2008-07-16T00:35:58Z</time> <name>Spot</name> <sym>Waypoint</sym> <extensions> <tmp:temperature>97.5</tmp:temperature> </extensions> </wpt> I've looked all over for examples, but keep coming up short. Any help would be greatly appreciated. Matt
Matt+mnorwood.com on Fri Jul 18 16:16:25 2008 (link), replying to msg
Anyone? Ultimately I want to create a class to use in vb.net using these extensions. I've found a few examples while searching through the yahoo groups site, but am having a difficult time getting the classes to work right after using xsd.exe Quoting Matt Norwood <Matt+mnorwood.com>: > I'm looking to add a custom element to the extensions type for waypoints. > > I see the xsd has spots all over it where you can add your own > elements, but my question is how and where exactly? I haven't worked > with XML all that much. > > Say I want to add an element called "temperature" and it is a type of > "float" from a namespace called "tmp" > So ultimately in my GPX file I end up with: > > <wpt lat="27.001" lon="-86.000004"> > <time>2008-07-16T00:35:58Z</time> > <name>Spot</name> > <sym>Waypoint</sym> > <extensions> > <tmp:temperature>97.5</tmp:temperature> > </extensions> > </wpt> > > I've looked all over for examples, but keep coming up short. > > Any help would be greatly appreciated. > Matt > > ------------------------------------ > > Yahoo! Groups Links > > > >
ptomblin+gmail.com on Fri Jul 18 17:58:26 2008 (link), replying to msg
Matt Norwood wrote: > > > I'm looking to add a custom element to the extensions type for waypoints. > > I see the xsd has spots all over it where you can add your own > elements, but my question is how and where exactly? I haven't worked > with XML all that much. > > Say I want to add an element called "temperature" and it is a type of > "float" from a namespace called "tmp" > So ultimately in my GPX file I end up with: > > <wpt lat="27.001" lon="-86.000004"> > <time>2008-07-16T00:35:58Z</time> > <name>Spot</name> > <sym>Waypoint</sym> > <extensions> > <tmp:temperature>97.5</tmp:temperature> > </extensions> > </wpt> > > I've looked all over for examples, but keep coming up short. What are you looking for, information on how to write a schema? How to write a file with an extended schema? If you want an example of a dataset with an extended schema, you could go to http://navaid.com/GPX/ and generate a small (say, one state's worth) file. You can find the extended schema at http://navaid.com/GPX/NAVAID/0/8 and if you look at the header of the generated file, you can see how I reference it. -- Paul Tomblin <ptomblin+xcski.com> http://blog.xcski.com/ "Integration by parts -- a very powerful technique." Teaching by intimidation -- also a very powerful technique. -- Logan Shaw, quoting Chuck Odle, his Calculus teacher
Matt+mnorwood.com on Fri Jul 18 18:06:44 2008 (link), replying to msg
Paul, I've actually been working with that exact example. I guess the main issue I'm having is generating the class for .net using xsd.exe Running xsd gpx.xsd navaid.xsd /c /l:vb generates the class I need, but it looks as if it leaves certain things out, like your simpleTypes and type specified elements. Thanks for the help. Quoting Paul Tomblin <ptomblin+gmail.com>: > Matt Norwood wrote: >> >> >> I'm looking to add a custom element to the extensions type for waypoints. >> >> I see the xsd has spots all over it where you can add your own >> elements, but my question is how and where exactly? I haven't worked >> with XML all that much. >> >> Say I want to add an element called "temperature" and it is a type of >> "float" from a namespace called "tmp" >> So ultimately in my GPX file I end up with: >> >> <wpt lat="27.001" lon="-86.000004"> >> <time>2008-07-16T00:35:58Z</time> >> <name>Spot</name> >> <sym>Waypoint</sym> >> <extensions> >> <tmp:temperature>97.5</tmp:temperature> >> </extensions> >> </wpt> >> >> I've looked all over for examples, but keep coming up short. > > What are you looking for, information on how to write a schema? How to write > a file with an extended schema? > > If you want an example of a dataset with an extended schema, you could go to > http://navaid.com/GPX/ and generate a small (say, one state's worth) file. > You can find the extended schema at http://navaid.com/GPX/NAVAID/0/8 and if > you look at the header of the generated file, you can see how I reference it. > > > > -- > Paul Tomblin <ptomblin+xcski.com> http://blog.xcski.com/ > "Integration by parts -- a very powerful technique." > Teaching by intimidation -- also a very powerful technique. > -- Logan Shaw, quoting Chuck Odle, his Calculus teacher > > ------------------------------------ > > Yahoo! Groups Links > > > >
ptomblin+gmail.com on Fri Jul 18 18:22:19 2008 (link), replying to msg
Matt Norwood wrote: > > > Paul, > I've actually been working with that exact example. > I guess the main issue I'm having is generating the class for .net > using xsd.exe > Running xsd gpx.xsd navaid.xsd /c /l:vb generates the class I need, > but it looks as if it leaves certain things out, like your simpleTypes > and type specified elements. Sorry, I have no experience with Windows tools. I wrote my GPX generators and parsers using Unix tools. -- Paul Tomblin <ptomblin+xcski.com> http://blog.xcski.com/ The biggest problem with democracy is that it is, in effect, the rule by the whim of the moment. -- Keith Glass
Matt+mnorwood.com on Fri Jul 18 20:01:07 2008 (link), replying to msg
If anybody has any experience with GPX and .Net, your assistance would be greatly appreciated. I can generate standard GPX files all day long using gpx.xsd and serialization. My issue is adding custom extension elements, and how to do it. Quoting Paul Tomblin <ptomblin+gmail.com>: > Matt Norwood wrote: >> >> >> Paul, >> I've actually been working with that exact example. >> I guess the main issue I'm having is generating the class for .net >> using xsd.exe >> Running xsd gpx.xsd navaid.xsd /c /l:vb generates the class I need, >> but it looks as if it leaves certain things out, like your simpleTypes >> and type specified elements. > > Sorry, I have no experience with Windows tools. I wrote my GPX > generators and > parsers using Unix tools. > > > -- > Paul Tomblin <ptomblin+xcski.com> http://blog.xcski.com/ > The biggest problem with democracy is that it is, in effect, the rule > by the whim of the moment. > -- Keith Glass > > ------------------------------------ > > Yahoo! Groups Links > > > >
Matt+mnorwood.com on Sat Jul 19 19:52:53 2008 (link), replying to msg
I ended up giving up on the fun .Net stuff and just writing the export as text as Simon suggested. Thanks, Matt Quoting Simon Slavin <slavins+hearsay.demon.co.uk>: > > On 19 Jul 2008, at 4:01am, Matt Norwood wrote: > >> If anybody has any experience with GPX and .Net, your assistance would >> be greatly appreciated. >> >> I can generate standard GPX files all day long using gpx.xsd and >> serialization. My issue is adding custom extension elements, and how >> to do it. > > Rather than use an XML toolbox you might find it simpler just to > generate the .gpx file as a text file. After all, that's all it is. > > Simon. > > ------------------------------------ > > Yahoo! Groups Links > > > >
sunburned.surveyor+gmail.com on Wed Jul 23 07:34:59 2008 (link), replying to msg
Good point Andy. I guess we would also have to deal with symbol names in different languages. The Sunburned Surveyor On Sat, Jul 12, 2008 at 11:14 AM, Andy Mabbett <andy+pigsonthewing.org.uk> wrote: > > > In message <BA8CAEC1-AA91-4824-A011-A95E06050EC9+hearsay.demon.co.uk>, > Simon Slavin <slavins+hearsay.demon.co.uk> writes > >>On 30 Jun 2008, at 6:38pm, Sunburned Surveyor wrote: >> >>> I guess I wasn't thinking about using the standard on a mobile device, >>> but of the opposite, using them on a Desktop. For example, I'd like to >>> import a GPX file into OpenJUMP and display an appropriate symbol >>> based on the information in the GPX file. >> >>I understand entirely, your desire for a standardised set of names and >>icons to use on computers. > > I can understand having a set of standard names; but not symbols - > different nations use different symbols, not least on their paper maps > and road signs. > > Here's a document (PDF. 338Kb) with the symbols used on UK Ordnance > Survey maps: > > <http://www.ordnancesurvey.co.uk/education/pdf/25knewEGMlegend.pdf> > > They're not the same as those used on, say, French or Canadian maps. > > If a standard set of names existed, users, could choose their preferred > set of symbols, for a hand-held device or a PC, just like adding a > different "skin" to a browser or media player. > > -- > Andy Mabbett > Says "NO! to compulsory UK ID Cards": <http://www.no2id.net/> > and: "Free Our Data": <http://www.freeourdata.org.uk> > (both also on Facebook) > >
andy+pigsonthewing.org.uk on Wed Jul 23 08:06:34 2008 (link), replying to msg
Not necessarily; we don't have non-English names for HTML elements like "blockquote"; or CSS properties like colour, er, color. After all, they're just labels. Users should never see them. On Wed, July 23, 2008 15:34, Sunburned Surveyor wrote: > Good point Andy. I guess we would also have to deal with symbol names > in different languages. > > The Sunburned Surveyor > > > On Sat, Jul 12, 2008 at 11:14 AM, Andy Mabbett > <andy+pigsonthewing.org.uk> wrote: > >> >> >> In message <BA8CAEC1-AA91-4824-A011-A95E06050EC9+hearsay.demon.co.uk>, >> Simon Slavin <slavins+hearsay.demon.co.uk> writes >> >> >>> On 30 Jun 2008, at 6:38pm, Sunburned Surveyor wrote: >>> >>> >>>> I guess I wasn't thinking about using the standard on a mobile >>>> device, but of the opposite, using them on a Desktop. For example, >>>> I'd like to >>>> import a GPX file into OpenJUMP and display an appropriate symbol >>>> based on the information in the GPX file. >>> >>> I understand entirely, your desire for a standardised set of names >>> and icons to use on computers. >> >> I can understand having a set of standard names; but not symbols - >> different nations use different symbols, not least on their paper maps >> and road signs. >> >> Here's a document (PDF. 338Kb) with the symbols used on UK Ordnance >> Survey maps: >> >> >> <http://www.ordnancesurvey.co.uk/education/pdf/25knewEGMlegend.pdf> >> >> >> They're not the same as those used on, say, French or Canadian maps. >> >> >> If a standard set of names existed, users, could choose their preferred >> set of symbols, for a hand-held device or a PC, just like adding a >> different "skin" to a browser or media player. >> >> -- >> Andy Mabbett
gps_maps+travelbygps.com on Mon Aug 11 08:10:18 2008 (link)
Hello GPXers, I'm writing an article that documents the history of exchanging GPS data. And I could use some help filling in significant events in the GPX timeline. So far I have... September 2001 ? GPXML forum established for developing common format for exchanging GPS data. December 2001 ? first GPX schema published ??/2004 ? Offroute launches GPXchange.com December 2004 - MapSource version 6.5 which features GPX file import. July 2005 - Google Earth application features support for GPX data. Please reply with what you feel are significant events in the proliferation of support for GPX in software applications, on-line tools and databases. The completed article will be posted here and on my web. Thanks, - Doug
salcedo+yahoo.com on Tue Aug 12 07:02:15 2008 (link), replying to msg
Hi Doug, On the Magellan side, the introduction of the eXplorist series in 2005 included GPX support in the form of their Geocache Manager. In 2006 they expanded their GPX support by releasing MapSend Lite Beta which supports GPX tracks, routes, and waypoints in addition to Groundspeak geocaches. For DeLorme, I know that Topo USA 6.0 (2006) supports GPX, but I'm not sure if that was their first product to do so or not. Other software apps that might be worth noting include GPSBabel http://www.gpsbabel.org/ and of course EasyGPS http://www.easygps.com/ And the article should probably also include when geocaching.com (Groundspeak) released their geocaching schema for gpx. -Ricardo
robertlipe+usa.net on Tue Aug 12 07:29:55 2008 (link)
> On the Magellan side, the introduction of the eXplorist series in 2005 Their VantagePoint supports GPX, too. > Other software apps that might be worth noting include GPSBabel > http://www.gpsbabel.org/ and of course EasyGPS http://www.easygps.com/ > > And the article should probably also include when geocaching.com > (Groundspeak) released their geocaching schema for gpx. Funny. I just sent Doug those details. I agree. :-) One of the things I meant to mention to Doug was that I think GPSBabel was the first open source program to support GPX. Having the implementation of a real GPX reader/writer examinable by other developers was probably a good thing.
gps_maps+travelbygps.com on Wed Aug 20 08:46:43 2008 (link), replying to msg
following up... Listed below is what I have to date. Corrections and suggested additions would be appreciated. - Doug September 2001 ? GPSXML forum established for developing common format for exchanging GPS data. December 2001 ? first GPX schema published December 2001 - GPSBabel, a popular program for converting GPS data, supports GPX file format. May 2002 - TravelByGPS.com publishing "Waypoints, Routes, and Tracks to Adventure" in GPX file format. September 2002 - Geocaching.com started distributing their geocache data to premium members in GPX file format. March 2004 - Backpacker.com offers downloadable GPX files for sale. December 2004 - Garmin added support for GPX in MapSource version 6.5 July 2005 - Google Earth launches with support for importing GPX data January 2006 - Garmin unveils nuvi series car navigation devices with native support for GPX January 2006 - National Geographic added GPX support to TOPO! version 4.2 March 2006 - Northport Systems added GPX support to Fugawi Version 4 April 2006 - DeLorme added GPX support to Topo USA Version 6.0 January 2008 - Garmin unveils the Colorado series handheld GPS units with native GPX support.
davep+confluence.org on Wed Aug 20 10:14:45 2008 (link), replying to msg
On 2008/08/20 8:46 AM, Doug Adomatis wrote: > following up... > > Listed below is what I have to date. Corrections and suggested > additions would be appreciated. December 2005 - OziExplorer supports GPX files http://www.oziexplorer3.com/eng/history.html Release Version 3.95.4j (December-2005) February 2006 - Degree Confluence Project search results available for download as an OziExplorer waypoint file, GPX waypoint file, or Google Earth placemarks file http://www.confluence.org/whatsnew.php Late 2007 - OGR adds support for GPX http://trac.osgeo.org/gdal/log/trunk/gdal/ogr/ogrsf_frmts/gpx -- Dave Patton CIS Canadian Information Systems Victoria, B.C. Degree Confluence Project: Canadian Coordinator Technical Coordinator http://www.confluence.org/ OSGeo FOSS4G2007 conference: Workshop Committee Chair Conference Committee member http://www.foss4g2007.org/ Personal website: Maps, GPS, etc. http://members.shaw.ca/davepatton/
andy+pigsonthewing.org.uk on Wed Aug 20 11:42:32 2008 (link), replying to msg
In message <g8he92+g08b+eGroups.com>, Doug Adomatis <gps_maps+travelbygps.com> writes >Listed below is what I have to date. Corrections and suggested >additions would be appreciated. That's an interesting list of events. I suggest adding it to Wikipedia, together with citations (e.g. links to relevant blog posts/ new pages, etc.) -- Andy Mabbett
egroups+topografix.com on Wed Aug 20 13:35:10 2008 (link), replying to msg
Hello Doug, Where are you publishing this? Who is the intended audience? What's your motivation for documenting GPX history? I don't think a timeline of press releases announcing GPX support in various programs is particularly interesting or useful, except to GPX history buffs or as a means of garnering links on wikipedia. I think you could write a much more interesting article by discussing the implications of each of these "milestone" events in GPX history. For example, the release of GPX 1.0 was significant because up until that time, every GPS or mapping program used its own (usually undocumented) file format. GPX was the first effort by multiple vendors to agree upon a universal format for exchanging data. Geocaching.com's support (and extension) of GPX was significant because it rapidly became the largest source of consumer GPS data on the Internet, and it was in an open format and could be used by a number of free programs right off the bat (EasyGPS, GPS Babel, GPX Spinner...) Compare and contrast with the proprietary .tpo format, which was probably the most used format for trail data at the time. Note how long it took for NG Topo! to embrace GPX due to their investment in .tpo and MapXchange. Google Earth's support for GPX was significant because it became the largest GPX application overnight, but also because it offered us KML, which, while it didn't solve the exact problem that GPX set out to solve, was close enough of a solution that it probably good enough for many people. You'd have a hard time convincing me that any program's support for GPX after Google Earth came out had any significance, other than that they finally realized they were getting left behind. You've mentioned nothing about mashups - the fact that GPX is XML and could be easily mashed up with Google Maps, Virtual Earth, and the rest of the Web APIs led to all sorts of uses for GPX from companies like MotionBased. August 9, 2004 - GPX 1.1 released. It's been over 4 years since any work has been done to extend GPX. Maybe you should be writing an obituary. -- Dan Foster
gps_maps+travelbygps.com on Wed Aug 20 20:03:59 2008 (link), replying to msg
--- Dan Foster wrote: > Where are you publishing this? Who is the intended audience? What's > your motivation for documenting GPX history? Thanks Dan for the thoughtful and detailed reply. I'm just trying to get my facts straight first, then I'll fill in the verbiage as necessary. As I wrote in my original post, the article is for publication on my web. When you see the article, I think my motivation will be a little more clear. - Doug
gps_maps+travelbygps.com on Mon Aug 25 11:54:12 2008 (link), replying to msg
--- "Doug Adomatis" wrote: > > The completed article will be posted here and on my web. As promised, here is the link to the complete article http://travelbygps.com/articles/2007.php The text of which is copied below. - Doug Title: The History of eXchanging GPs Data 25 August 2008 It seems like about once a year, something comes along that motivates me to write about the state of recreational GPS, where we've been, and where we're going. This year it was an article in Backpacker Magazine. A recent email I sent to the editor of Backpacker Magazine went like this: "I give BACKPACKER credit for the well written iHike Guide (June 2008) but I found myself giggling over all the hype about the sharing of location data being "new." Patrons of sites like TravelByGPS.com have been using for years what you report as "new tools" and "new rules" for the "digital revolution." Moreover, the 13-page guide gives scant few references to the standard that facilitates trip planning, documenting, and sharing - the GPs eXchange (GPX) file format - which has been proliferating for almost 7 years. When you sensationalize what is common practice, you look a little silly." Here is a look back at the practice of exchanging location information in the GPX data format and how it has been adopted by companies providing GPS hardware, software, and recreational data: September 2001 �?" GPSXML forum established for developing common format for exchanging GPS data. December 2001 �?" first GPX schema published. December 2001 - GPSBabel, a popular program for working with GPS data, supports GPX file format. May 2002 - TravelByGPS.com begins publishing "Waypoints, Routes, and Tracks to Adventure" in GPX format. September 2002 - Geocaching.com starts distributing their geocache data GPX file format. March 2004 - Backpacker.com offers downloadable GPX files for sale. August, 2004 - MotionBased.com enables users to upload and analyze GPX data. December 2004 - Garmin added support for GPX in MapSource version 6.5 January 2005 - Magellan announced Geocache Manager PC application with support for GPX.. June 2005 - Backpacker Magazine teams up with Trimble Outdoors to create trip sharing web site. July 2005 - Google Earth launches with support for importing GPX data January 2006 - Garmin unveils nuvi series car navigation devices with native support for GPX January 2006 - National Geographic added GPX support to TOPO! version 4.2 March 2006 - Northport Systems added GPX support to Fugawi Version 4 April 2006 - DeLorme added GPX support to Topo USA Version 6.0 January 2008 - Garmin unveils the Colorado series handheld GPS units with native GPX support. Clearly the digital revolution in trip sharing is not "new." But considering Backpacker Magazine's need to sell issues and bring attention to its own trip sharing web site, I can understand why the editors would pump up the rhetoric. What I do not understand is why Backpacker left out out significant GPX data wherehouses (pun intended) under the iHike guide's Plan-it section. [Graph Internet Rank of Popular Trip-sharing Websites] The Alexa graph at right shows Internet reach for the popular location information web sites. Backpacker listed Trails.com and Google Earth (bbs.Keyhole.com), but it did not list Geocaching.com. The cache pages and visitor logs at geocaching .com provide a wealth of trip data in GPX format. According to those who should know, the adoption of the GPX format at Geocaching.com was key in the acceptance of GPX as a common format for sharing GPS data. Geocaching.com's support of GPX was significant because it rapidly became the largest source of consumer GPS data on the Internet, and it was in an open format that could be used by a number of free programs right off the bat (EasyGPS, GPS Babel, GPX Spinner...). The proliferation of GPX file sharing surely influenced the likes of Garmin to include GPX support in their own GPS hardware and mapping software products. When Garmin acquired MotionBased.com, it purchased the fastest growing online mapping application for athletes and outdoor enthusiasts. Within it's first year, MotionBased signed up over 11,000 GPS users who uploaded approximately 140,000 individual outdoor activities. MotionBased.com was also not included on Backpacker's list of trip planning web sites, but perhaps it should have been. Currently, MotionBased has a similar Internet rank as compared to the two lowest ranking web sites listed - Backpacker.com and Topo.com. Arguably the most popular trip sharing web site is the Google Earth Community. When Google Earth launched it became the largest GPX application overnight. And soon after, most all the popular GPS and mapping programs fell in line supporting GPX. Google Earth allowed users to open GPX files, but they could only be saved in a new format - the Keyhole Markup Language (KML) or in compressed form (KMZ). The result is that users started sharing files in KML, but they still needed GPX to transfer the data to their GPS devices. Going back-and-forth between formats is a pain especially when some of the information gets lost in the translation. Trip sharing web sites would rather not have to maintain multiple formats. Most sites stick to one and point users to programs like GPS Babel for converting from the one to another. But now that we have two formats that are so prevalent, which one is the best for publishers? According to Jeremy Irish, founder of Geocaching.com, "GPX is an excellent format for exchanging GPS data, but the presentation capabilities of KML make it a better delivery mechanism for Geocaching and Waymarking data." Irish has no plans of updating the data format at geocaching.com but, "If and when we do, it is likely that we'll move to KML." I agree with Irish. Most of the downloads at TravelByGPS.com are in GPX format, but I like to show off the data with screenshots of Google Earth. It is a hassle to create a KML file and tweak it for display purposes, but Google Earth is hard to beat as a visualization tool. If Google ever gets serious about supporting devices, I'd be inclined to convert to KML too. And if that ever happens, the follow up to this article may well be the obituary for GPX. Maybe in the shadow of all the hype at Backpacker, the editors know a move from GPX to KML is underway. In the same issue as the iHike guide, a contest was announced, encouraging readers to submit trip reports with "the most ingenious uses of new technology" using mash-ups, visuals, narration, geotagged photos, slideshow tools... When I read this, I could not resist coming up with my own contest entry. Here is the result: Simulated Flight over Nantahala National Forest along 50-mile hiking route, looping the Appalachian and Bartram Trail with whitewater option ( http://travelbygps.com/premium/nantahala/wesser.php ) Enjoy! - Doug Owner, TravelByGPS.com
dancarr77+yahoo.co.uk on Mon Oct 20 13:12:58 2008 (link)
Hi, I'm currently developing an application that will accept a .gpx file as a file input and then convert the data contained inside and add it to a relational database (for further queries etc. at a later date). I would then like to convert this data back from the database back to a .gpx file to allow me to easily integrate the software with googlemaps as i know .gpx is a format their API accepts for tracks. That's the background bit done, I was wondering if anyone knew of any existing php scripts or another method of converting the .gpx file into a relational database (probably not too difficult), and then converting it back (slightly more difficult as will have to read the elements and create them with the precise gpx formatting). Any help or suggestions of how to approach this would be really appreciated. Thanks in advance, Daniel Carr
mhoegh+gmail.com on Mon Oct 20 13:59:59 2008 (link), replying to msg
Take a look at http://blog.toposhare.org/?p=92 The gpxtosql class parses a GPX feed into a PHP array or sql statements. All source code behind toposhare.org is available at http://sourceforge.net/projects/toposhare/ On Mon, Oct 20, 2008 at 9:39 PM, dancarr77 <dancarr77+yahoo.co.uk> wrote: > Hi, > > I'm currently developing an application that will accept a .gpx file > as a file input and then convert the data contained inside and add it > to a relational database (for further queries etc. at a later date). I > would then like to convert this data back from the database back to a > .gpx file to allow me to easily integrate the software with googlemaps > as i know .gpx is a format their API accepts for tracks. > > That's the background bit done, I was wondering if anyone knew of any > existing php scripts or another method of converting the .gpx file > into a relational database (probably not too difficult), and then > converting it back (slightly more difficult as will have to read the > elements and create them with the precise gpx formatting). > > Any help or suggestions of how to approach this would be really > appreciated. > > Thanks in advance, > > Daniel Carr > >
tomkralidis+hotmail.com on Tue Oct 21 11:29:19 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "dancarr77" <dancarr77+...> wrote: > > Hi, > > I'm currently developing an application that will accept a .gpx file > as a file input and then convert the data contained inside and add it > to a relational database (for further queries etc. at a later date). I > would then like to convert this data back from the database back to a > .gpx file to allow me to easily integrate the software with googlemaps > as i know .gpx is a format their API accepts for tracks. > > That's the background bit done, I was wondering if anyone knew of any > existing php scripts or another method of converting the .gpx file > into a relational database (probably not too difficult), and then > converting it back (slightly more difficult as will have to read the > elements and create them with the precise gpx formatting). > > Any help or suggestions of how to approach this would be really > appreciated. > > Thanks in advance, > > Daniel Carr > Check out OGR, which has read/write support for GPX. You can either use the ogr2ogr command line tool, or build against OGR proper (C API, or Perl/Python/etc. bindings). More info at: http://www.gdal.org/ogr/ and http://www.gdal.org/ogr/drv_gpx.html
nate-lists+calftrail.com on Sat Nov 01 18:23:42 2008 (link)
May I propose the following Uniform Type Identifier declaration, for import by OS X application developers? It declares that "com.topografix.gpx" refers to a type conforming to the "public.xml" type, with extension "gpx" and MIME type "application/gpx+xml". I did not declare an explicit pasteboard type, as it seems modern practice would prefer to just use the UTI itself when providing data. The human readable type description would be "GPS Exchange Format (GPX)", and this can be localized to be readable by humans who don't prefer English, if anyone would be kind enough to provide translations. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array> <dict> <key>UTTypeIdentifier</key> <string>com.topografix.gpx</string> <key>UTTypeReferenceURL</key> <string>http://www.topografix.com/GPX/1/1/</string> <key>UTTypeDescription</key> <string>GPS Exchange Format (GPX)</string> <key>UTTypeConformsTo</key> <array> <string>public.xml</string> </array> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <string>gpx</string> <key>public.mime-type</key> <string>application/gpx+xml</string> </dict> </dict> </array> </plist> (If you're curious, you can find more information on UTIs here: http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/ ) thanks, -natevw Calf Trail Software, LLC http://calftrail.com
gpxpoicom+yahoo.com on Thu Nov 06 04:09:28 2008 (link)
I created a GPX file generator: http://gpx-poi.com/ Please review and feel free to suggest improvements.
bazmcbride+hotmail.com on Fri Nov 07 06:44:24 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "gpxpoicom" <gpxpoicom+...> wrote: > > I created a GPX file generator: > > http://gpx-poi.com/ > > Please review and feel free to suggest improvements. > Sorry for my ignorance but have only just started to look at this mapping stuff. What exactly is gpx and what can you do with it?
robmaclean58+yahoo.com on Tue Nov 18 04:31:16 2008 (link)
Hi. I am really interested in whether: 1) You can send GPX files showing routes from a PC to remote devices (i.e. not connected to computer) 2) Can this be done to the 3G iPhone? If so, is this direct to the GPS component or via email or asking user to go online to download? 3) Is it possible to create GPX files using mapping software (i.e. not just GPS references), but specific routes along road that can be created on a PC? I hope this makes sense. I'm not very familiar with GPX etc., so sorry if my questions are naive?! rmacle.
robmaclean58+yahoo.com on Thu Nov 20 05:35:17 2008 (link), replying to msg
Thanks alot for your response Simon. Much appreciated. For the sake of context, as you've probably worked out a) I know very little! and b) what I'm looking into is providing route advice to tourists 'on-the-ground'. They rent a GPS device and as they travel you send them recommended routes depending upon their preferences, scenery, safety (I am based in South Africa!) in addition to other services. The iPhone looks to be the best device for the other services, which require email / internet access as well as some iPhone Apps. Do you know of any companies / individuals I can work with closely to start learning / out-sourcing (e.g. could write required programmes etc.)?! Thanks again for any help. rmacle --- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > On 18 Nov 2008, at 6:23am, robmaclean58 wrote: > > > 1) You can send GPX files showing routes from a PC to remote devices > > (i.e. not connected to computer) > > Each device has different capabilities: some can receive GPX files via > USB, some can download them from Flash memory cards, some can load > them from the web. You would have to ask that question about a > specific device. > > > 2) Can this be done to the 3G iPhone? If so, is this direct to the GPS > > component or via email or asking user to go online to download? > > You would need to write a program to do this: to receive the file and > then show its contents using a map as the background. As far as I > know the built-in 'Maps' program cannot show a route. However I > believe that the map images are available to other programs. > > > 3) Is it possible to create GPX files using mapping software (i.e. not > > just GPS references), but specific routes along road that can be > > created on a PC? > > There are many GPX file editors for the PC which will allow you to set > up a route of points. Some GPS manufacturers provide one with their > GPS unit or allow you to download one off the web. > > > I hope this makes sense. I'm not very familiar with GPX etc., so sorry > > if my questions are naive?! > > No problem. I see where you're going with this, but you may need to > learn quite a lot before you can do anything useful. > > Simon. >
davep+confluence.org on Thu Nov 20 06:04:19 2008 (link), replying to msg
On 2008/11/20 1:54 AM, robmaclean58 wrote: > Thanks alot for your response Simon. Much appreciated. > > For the sake of context, as you've probably worked out a) I know very > little! and b) what I'm looking into is providing route advice to > tourists 'on-the-ground'. They rent a GPS device and as they travel > you send them recommended routes depending upon their preferences, > scenery, safety (I am based in South Africa!) in addition to other > services. > > The iPhone looks to be the best device for the other services, which > require email / internet access as well as some iPhone Apps. > > Do you know of any companies / individuals I can work with closely to > start learning / out-sourcing (e.g. could write required programmes > etc.)?! This book may give you some info: http://oreilly.com/catalog/9780596529956/ And, as the FOSS4G 2008 conference was just recently held in Capetown, reviewing the people who gave Workshops, Labs, Presentations, etc. might give you some ideas of local(to you) resources: http://conference.osgeo.org/index.php/foss4g/2008 -- Dave Patton CIS Canadian Information Systems Victoria, B.C. Degree Confluence Project: Canadian Coordinator Technical Coordinator http://www.confluence.org/ OSGeo FOSS4G 2009 conference: Conference Committee member http://2009.foss4g.org/ Personal website: Maps, GPS, etc. http://members.shaw.ca/davepatton/
richard+jelbert.com on Thu Nov 20 06:14:04 2008 (link), replying to msg
Hello For web application and GIS related work, you could try: http://www.edendevelopment.co.uk/ I use them and I know they have i-phone and mapping experience. Richard -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of robmaclean58 Sent: 20 November 2008 09:54 To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: Sending GPX routes to remote GPS devices Thanks alot for your response Simon. Much appreciated. For the sake of context, as you've probably worked out a) I know very little! and b) what I'm looking into is providing route advice to tourists 'on-the-ground'. They rent a GPS device and as they travel you send them recommended routes depending upon their preferences, scenery, safety (I am based in South Africa!) in addition to other services. The iPhone looks to be the best device for the other services, which require email / internet access as well as some iPhone Apps. Do you know of any companies / individuals I can work with closely to start learning / out-sourcing (e.g. could write required programmes etc.)?! Thanks again for any help. rmacle --- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > On 18 Nov 2008, at 6:23am, robmaclean58 wrote: > > > 1) You can send GPX files showing routes from a PC to remote devices > > (i.e. not connected to computer) > > Each device has different capabilities: some can receive GPX files via > USB, some can download them from Flash memory cards, some can load > them from the web. You would have to ask that question about a > specific device. > > > 2) Can this be done to the 3G iPhone? If so, is this direct to the GPS > > component or via email or asking user to go online to download? > > You would need to write a program to do this: to receive the file and > then show its contents using a map as the background. As far as I > know the built-in 'Maps' program cannot show a route. However I > believe that the map images are available to other programs. > > > 3) Is it possible to create GPX files using mapping software (i.e. not > > just GPS references), but specific routes along road that can be > > created on a PC? > > There are many GPX file editors for the PC which will allow you to set > up a route of points. Some GPS manufacturers provide one with their > GPS unit or allow you to download one off the web. > > > I hope this makes sense. I'm not very familiar with GPX etc., so sorry > > if my questions are naive?! > > No problem. I see where you're going with this, but you may need to > learn quite a lot before you can do anything useful. > > Simon. > ------------------------------------ Yahoo! Groups Links
thomas.landspurg+gmail.com on Thu Nov 20 09:48:17 2008 (link), replying to msg
Hello, I also suggest to check our comapny, 8Motions ( http://www.8motions.com) One of our main focus is to create a mobile tourist guide, able to download guide other the air. There is still a loootttt to do (we are yet a small team) so we are now focused on creatin the technical bricks for this. This project has been a finalist in the Navteq LBSChallenger 2007. The "J2memap" library is a well know part of this effort ( http://j2memap.8motions.com ) with more than a thousands of register developers. We have some components for Midp phones (J2me) and a fairly advanced iphone version. These version can downloads KML, GPX, LOC , GeoRSS files and display them to the user other a map. So feel free to contact us On Thu, Nov 20, 2008 at 10:54 AM, robmaclean58 <robmaclean58+yahoo.com>wrote: > Thanks alot for your response Simon. Much appreciated. > > For the sake of context, as you've probably worked out a) I know very > little! and b) what I'm looking into is providing route advice to > tourists 'on-the-ground'. They rent a GPS device and as they travel > you send them recommended routes depending upon their preferences, > scenery, safety (I am based in South Africa!) in addition to other > services. > > The iPhone looks to be the best device for the other services, which > require email / internet access as well as some iPhone Apps. > > Do you know of any companies / individuals I can work with closely to > start learning / out-sourcing (e.g. could write required programmes > etc.)?! > > Thanks again for any help. > > rmacle > > > --- In gpsxml+yahoogroups.com <gpsxml%40yahoogroups.com>, Simon Slavin > <slavins+...> wrote: > > > > > > On 18 Nov 2008, at 6:23am, robmaclean58 wrote: > > > > > 1) You can send GPX files showing routes from a PC to remote > devices > > > (i.e. not connected to computer) > > > > Each device has different capabilities: some can receive GPX files > via > > USB, some can download them from Flash memory cards, some can load > > them from the web. You would have to ask that question about a > > specific device. > > > > > 2) Can this be done to the 3G iPhone? If so, is this direct to > the GPS > > > component or via email or asking user to go online to download? > > > > You would need to write a program to do this: to receive the file > and > > then show its contents using a map as the background. As far as I > > know the built-in 'Maps' program cannot show a route. However I > > believe that the map images are available to other programs. > > > > > 3) Is it possible to create GPX files using mapping software > (i.e. not > > > just GPS references), but specific routes along road that can be > > > created on a PC? > > > > There are many GPX file editors for the PC which will allow you to > set > > up a route of points. Some GPS manufacturers provide one with > their > > GPS unit or allow you to download one off the web. > > > > > I hope this makes sense. I'm not very familiar with GPX etc., so > sorry > > > if my questions are naive?! > > > > No problem. I see where you're going with this, but you may need > to > > learn quite a lot before you can do anything useful. > > > > Simon. > > > > > -- Thomas Landspurg http://blog.landspurg.net [Non-text portions of this message have been removed]
adit+compuserve.com on Fri Nov 21 01:16:15 2008 (link), replying to msg
Rob Hi If you ever consider the pocket pc (windows mobile) platform, we have already developed code modules that address the issues you raise. Our company information can be found at www.adit.co.uk, and examples of programs developed from the modules at www.wildknowledge.co.uk. As a brief example, users can create maps (see WildMap) with routes and points of interest. These are then available for download to a gps enabled pocket pc or smartphone. On the pocket pc, the user can follow trails and record their own information, as well as seeing pics/videos etc about each point of information. Let me know if you need further info. Cheers Paul --- In gpsxml+yahoogroups.com, "robmaclean58" <robmaclean58+...> wrote: > > Hi. I am really interested in whether: > > 1) You can send GPX files showing routes from a PC to remote devices > (i.e. not connected to computer) > 2) Can this be done to the 3G iPhone? If so, is this direct to the GPS > component or via email or asking user to go online to download? > 3) Is it possible to create GPX files using mapping software (i.e. not > just GPS references), but specific routes along road that can be > created on a PC? > > I hope this makes sense. I'm not very familiar with GPX etc., so sorry > if my questions are naive?! > > rmacle. >
pk+evc.net on Fri Nov 21 05:53:19 2008 (link)
Hello everybody, I just posted the new version of GPX Editor : http://www.knackes.com/blog/index.php?2008/11/20/193-gpx-editor-1070 With it you can - Load, display, modify and save GPX files - Change properties of metadatas, tracks, routes, and waypoints - edit tracks to remove unnecessary points, using Douglas-Peucker algorithm and a few others - Add waypoints into the gpx, by clicking on a google map - lots of other features It's Open Source (written in Delphi 7) and I tried to stick as much as I could to the GPX 1.1 documentation. The only limitation I am aware of so far is that it supports only 1 link by object when the documentation asks for an unlimited number. Any comments or suggestions are warmly welcome. Pixel_K
robmaclean+gmail.com on Sat Nov 22 05:15:30 2008 (link), replying to msg
Thanks to all for your responses. I've got a lot to learn, but it seems various people are thinking along similiar lines and developing solutions that I need to understand. I do believe the idea of being able to download relevant / personalised routes based on preferences whilst 'on the road' is a good opportunity. If you can be the 'trusted agent' for routes, you can move into 'normal' travel agency businesses (booking accomm etc.) which earn commission as well as charging flat fees for device rental and support. You can also sell rights to be on routes to attractions (e.g. tours, restuarants) similiar to normal advertising. Independent, 'experiential', authentic travel is the way people want to experience foreign countries today. The challenge is getting a format is user-friendly (for traveller, for agent) as well as being able to send routes remotely. I'll be in touch... Rob --- In gpsxml+yahoogroups.com, "aditboss" <adit+...> wrote: > > Rob > > Hi > > If you ever consider the pocket pc (windows mobile) platform, we have > already developed code modules that address the issues you raise. > > Our company information can be found at www.adit.co.uk, and examples > of programs developed from the modules at www.wildknowledge.co.uk. > > As a brief example, users can create maps (see WildMap) with routes > and points of interest. These are then available for download to a gps > enabled pocket pc or smartphone. On the pocket pc, the user can follow > trails and record their own information, as well as seeing pics/videos > etc about each point of information. > > Let me know if you need further info. > > Cheers > > Paul > > > --- In gpsxml+yahoogroups.com, "robmaclean58" <robmaclean58+> wrote: > > > > Hi. I am really interested in whether: > > > > 1) You can send GPX files showing routes from a PC to remote devices > > (i.e. not connected to computer) > > 2) Can this be done to the 3G iPhone? If so, is this direct to the GPS > > component or via email or asking user to go online to download? > > 3) Is it possible to create GPX files using mapping software (i.e. not > > just GPS references), but specific routes along road that can be > > created on a PC? > > > > I hope this makes sense. I'm not very familiar with GPX etc., so sorry > > if my questions are naive?! > > > > rmacle. > > >
paul+proxml.be on Wed Nov 26 05:36:11 2008 (link)
Hi, I saw the announcement of GPX Editor for Windows and I wondered if something similar exists for the Mac. I have been searching for a while now, but with no result yet. Paul
dananderson2+yahoo.com on Fri Nov 28 09:41:59 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "paul_hermans" <paul+...> wrote: > I saw the announcement of GPX Editor for Windows and I wondered if > something similar exists for the Mac. How about MacGPS Pro: http://www.macgpspro.com/
ptomblin+gmail.com on Sun Nov 30 08:39:58 2008 (link)
I was making some changes to my gpx extension schema and verifying it with SAXCount in xerces. I noticed a SAX2Count in the same directory, but my file failed terribly with it. Does anybody know what the difference is? ___ Sent with SnapperMail www.snappermail.com
ryan+ryanstewart.net on Wed Dec 24 09:04:27 2008 (link), replying to msg
--- In gpsxml+yahoogroups.com, "paul_hermans" <paul+...> wrote: > > Hi, > > I saw the announcement of GPX Editor for Windows and I wondered if > something similar exists for the Mac. > > I have been searching for a while now, but with no result yet. > > > Paul > This is a really old thread, but I'd be interested, if you have time, to see what you'd like in an interactive GPX editor. I work for Adobe and wrote a GPX library for Flash/ActionScript and am looking into creating an Adobe AIR (http://www.adobe.com/go/air) that would let you manipulate GPX files. =Ryan ryan+adobe.com http://blog.digitalbackcountry.com
lisah2u+gmail.com on Wed Dec 24 10:06:59 2008 (link), replying to msg
The best gpx editor I've ever used was topofusion (windows). Besides adding and deleting points, simplifying, merging and splitting -- it's incredibly handy to be able to select a bunch of points and hit the delete key. I also wish there were something else as good as topofusion on the mac. Even with the most recent version of parallels, I can't get topofusion graphics to work well on the mac. Lisa On Tue, Dec 23, 2008 at 11:04 PM, digitalbackcountry <ryan+ryanstewart.net> wrote: > --- In gpsxml+yahoogroups.com, "paul_hermans" <paul+...> wrote: >> >> Hi, >> >> I saw the announcement of GPX Editor for Windows and I wondered if >> something similar exists for the Mac. >> >> I have been searching for a while now, but with no result yet. >> >> >> Paul >> > > This is a really old thread, but I'd be interested, if you have time, > to see what you'd like in an interactive GPX editor. I work for Adobe > and wrote a GPX library for Flash/ActionScript and am looking into > creating an Adobe AIR (http://www.adobe.com/go/air) that would let you > manipulate GPX files. > > =Ryan > ryan+adobe.com > http://blog.digitalbackcountry.com > >
ryan+ryanstewart.net on Wed Dec 24 12:54:00 2008 (link), replying to msg
That's one of the reasons I want to build it on Adobe AIR. One, I can show it off as part of my day job for Adobe, but AIR also runs on Mac/Win/Linux. So I think it would be a fun project. Thanks for the note on Topofusion, Lisa. I'll check that out today. =Ryan --- In gpsxml+yahoogroups.com, "Michael A. Peters" <mpeters+...> wrote: > > Lisa Harper wrote: > > > > > > The best gpx editor I've ever used was topofusion (windows). Besides > > adding and deleting points, simplifying, merging and splitting -- it's > > incredibly handy to be able to select a bunch of points and hit the > > delete key. I also wish there were something else as good as > > topofusion on the mac. Even with the most recent version of parallels, > > I can't get topofusion graphics to work well on the mac. > > Just be thankful you aren't like me - even more limited as I use Linux > exclusively :D > > I'm working on a php solution that will be platform independent, but > will require use of a webserver with some kind of an SQL database. > Hopefully it will be able to properly input/output both proper gpx and kml. >
lisah2u+gmail.com on Sun Dec 28 19:13:34 2008 (link), replying to msg
... and hugely.... cutting a track and deleting a segment. I don't know how many times I've screwed up and left the GPS on recording a long car trip home.... Lisa On Fri, Dec 26, 2008 at 3:29 AM, paul <paul+proxml.be> wrote: > I haven't worked long enough with GPX Editor to say what I like or not. > I'm rather looking for following functionality. > > a) correcting a path > If I'm recording tracks sometimes the data are not completely correct. > So I want to edit/correct them before publishing. > I prefer to do this in a graphical way by dragging the path on a map. > > b) completing a path > When I pause the tracking due to a stop for eating/drinking, I > sometimes forget to restart the tracking device, resulting in a gap in > my track. > I want to connect these different disconnected paths also by drawing > on a map. > > So it comes down, as Lisa said, to adding and deleting points, > simplifying, merging and splitting paths, but using as much as > possible a drawing mode on a map. > > I look forward to test the AIR app. > > Regards, > > Paul > > [Non-text portions of this message have been removed] > > > [Non-text portions of this message have been removed]
inhk8357+yahoo.co.kr on Mon Dec 29 06:19:56 2008 (link)
Hi I can find that the frequency of recording track data is not constant It takes from 1sec to 40sec Please let me know the reason. thank you
yahoo+web.knobby.ws on Sun Jan 04 21:15:04 2009 (link), replying to msg
To take this one step further if you click (select) a point in the text version that point should be highlighted on the map, and visa versa. I'd also like to see speed, elevation, and slope plots. These would require smoothing options (something like least square fits over 3 to x points. Working with Google Earth would be nice. But GE is pretty hopeless in dealing with multiple saved items. To explain a bit: if I want to save a bunch of tracks as bike rides, but then want to later further subdivide them by region. I may or may not want the stored waypoints in each gpx file. Or I may want to see all from a certain time span. Think Smart Searches. Average tracks together. Maybe I've done something five times and want to combine the tracks into one averaged together track. I'd never heard of AIR, but it would have to respect the Mac Open Dialog. Java apps don't and it makes them hard to use. I use Default Folder and expect to be able to go back to the folder I was in, even if it's on another volume. In other words it should also work with Default Folder. Good luck. Looking forward to a good gpx app. --- In gpsxml+yahoogroups.com, paul <paul+...> wrote: > > I haven't worked long enough with GPX Editor to say what I like or not. > I'm rather looking for following functionality. > > a) correcting a path > If I'm recording tracks sometimes the data are not completely correct. > So I want to edit/correct them before publishing. > I prefer to do this in a graphical way by dragging the path on a map. > > b) completing a path > When I pause the tracking due to a stop for eating/drinking, I > sometimes forget to restart the tracking device, resulting in a gap in > my track. > I want to connect these different disconnected paths also by drawing > on a map. > > So it comes down, as Lisa said, to adding and deleting points, > simplifying, merging and splitting paths, but using as much as > possible a drawing mode on a map. > > I look forward to test the AIR app. > > > Regards, > > Paul > > [Non-text portions of this message have been removed] >
egroups+topografix.com on Mon Jan 05 10:08:23 2009 (link)
Hello, I have a need to create compressed GPX files, using the Zip compression/decompression algorithm. This would be identical to how the KML format has a compressed KMZ form, which is just a zipped KML file. What do you think I should use as a file extension? These are the options I've come up with: .gpz (analogous to .kmz) .gpxz (makes it clearer that this is zipped GPX) .gpx.zip (borrowing the UNIX convention of leaving the original extension intact and tacking on the compression scheme) Please note that I'm not asking for opinions as to whether compressed GPX is a good idea or not, I'm just asking what file extension you feel is most appropriate, and why. The two platforms I care most about are Web and Windows, if that matters. Thanks, and best wishes to you all in 2009! -- Dan Foster
martinp13+earthlink.net on Mon Jan 05 10:54:26 2009 (link), replying to msg
I'd vote .gpz to continue the .kml->.kmz format.� But either of the other two make sense too. --- On Mon, 1/5/09, Dan Foster <egroups+topografix.com> wrote: From: Dan Foster <egroups+topografix.com> Subject: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other? To: gpsxml+yahoogroups.com Date: Monday, January 5, 2009, 12:08 PM Hello, I have a need to create compressed GPX files, using the Zip compression/decompression algorithm. This would be identical to how the KML format has a compressed KMZ form, which is just a zipped KML file. What do you think I should use as a file extension? These are the options I've come up with: .gpz (analogous to .kmz) .gpxz (makes it clearer that this is zipped GPX) .gpx.zip (borrowing the UNIX convention of leaving the original extension intact and tacking on the compression scheme) Please note that I'm not asking for opinions as to whether compressed GPX is a good idea or not, I'm just asking what file extension you feel is most appropriate, and why. The two platforms I care most about are Web and Windows, if that matters. Thanks, and best wishes to you all in 2009! -- Dan Foster ------------------------------------ Yahoo! Groups Links [Non-text portions of this message have been removed]
robertlipe+usa.net on Mon Jan 05 11:21:25 2009 (link)
> I have a need to create compressed GPX files, using the Zip > compression/decompression algorithm. This would be identical to how > the KML format has a compressed KMZ form, which is just a zipped KML > file. What do you think I should use as a file extension? These are Not to distract, but KMZ is actually a bit more than that; it's an archive and thus can include icons, html and other data that can be referenced from the KML. > .gpz (analogous to .kmz) > .gpxz (makes it clearer that this is zipped GPX) > .gpx.zip (borrowing the UNIX convention of leaving the original There are still enough "8 dot 3" limits in the world that I'd lean to the first. But do give some thought to formally defining whether a ".gpz" is actually just one single .gpx file that's compressed, multiple files, can contain data referenced from the GPX, and so on. RJL
egroups+topografix.com on Mon Jan 05 12:04:36 2009 (link), replying to msg
Hello, Monday, January 5, 2009, 2:21:24 PM, Robert wrote: >> I have a need to create compressed GPX files, using the Zip >> compression/decompression algorithm. This would be identical to how >> the KML format has a compressed KMZ form, which is just a zipped KML >> file. > Not to distract, but KMZ is actually a bit more than that; it's an archive > and thus can include icons, html and other data that can be referenced from > the KML. > do give some thought to formally defining whether a ".gpz" is actually > just one > single .gpx file that's compressed, multiple files, can contain data > referenced from > the GPX, and so on. My implementation plan was to mimic KMZ as much as possible - the program that opened the compressed GPX archive would extract data from any and all GPX files contained therein. I wasn't planning to use other data in the archive (.jpg, etc) but would probably support it if others caught on to the idea of compressed GPX archives. -- Dan Foster
jeremy+groundspeak.com on Mon Jan 05 13:10:23 2009 (link), replying to msg
Here's another vote for GPZ. It isn't an overused file extension so it seems like a good candidate. It is also consistent to kmz as Dan mentioned already. We already zip GPX files before emailing them so it makes sense for Geocaching.com to adopt this standard. It would be good to see other applications using it too. Jeremy _____ From: Martin [mailto:martinp13+earthlink.net] To: gpsxml+yahoogroups.com Sent: Mon, 05 Jan 2009 10:54:24 -0800 Subject: Re: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other? I'd vote .gpz to continue the .kml->.kmz format. But either of the other two make sense too. --- On Mon, 1/5/09, Dan Foster <egroups+topografix.com> wrote: From: Dan Foster <egroups+topografix.com> Subject: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other? To: gpsxml+yahoogroups.com Date: Monday, January 5, 2009, 12:08 PM Hello, I have a need to create compressed GPX files, using the Zip compression/decompression algorithm. This would be identical to how the KML format has a compressed KMZ form, which is just a zipped KML file. What do you think I should use as a file extension? These are the options I've come up with: .gpz (analogous to .kmz) .gpxz (makes it clearer that this is zipped GPX) .gpx.zip (borrowing the UNIX convention of leaving the original extension intact and tacking on the compression scheme) Please note that I'm not asking for opinions as to whether compressed GPX is a good idea or not, I'm just asking what file extension you feel is most appropriate, and why. The two platforms I care most about are Web and Windows, if that matters. Thanks, and best wishes to you all in 2009! -- Dan Foster ------------------------------------ Yahoo! Groups Links [Non-text portions of this message have been removed] [Non-text portions of this message have been removed]
ptomblin+gmail.com on Mon Jan 05 13:47:03 2009 (link), replying to msg
On Mon, Jan 5, 2009 at 4:17 PM, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > In fact, hosting on a web server is probably your key question. You > need to decide what you want a web browser to do when someone clicks > on a link to one of your files: should it download the file intact, or > download the file and unzip it ? And then you need to decide what to > do to make that happen. And let's not forget that at least some versions of IE ignore the ContentType returned by the web server and guess the file type based on the file extension (which has caused any number of problems with extensions that have multiple meanings). Whether the coding decisions that made IE do this are a result of arrogance or incompetence is an open question. -- Parks sat so King could march. King marched so that Obama could run. Obama ran so we could fly.
simon_thwaites+yahoo.com on Wed Jan 07 06:27:13 2009 (link)
My vote is for gpx.compressionext mainly using gpx.gz .gz is meant for single file compression, not multiple file archives, also applications automatically recognise the .gz extention as a "compressed file". Whether any of these are using gpx is another matter, but still... the "standard" approach is .gz so thats how it should be in my oppinion. that and any compression format can be used, .gz .rar ________________________________ From: Michael A. Peters <mpeters+mac.com> To: gpsxml+yahoogroups.com Sent: Tuesday, 6 January, 2009 1:41:12 Subject: Re: [gpsxml] Which extension for zip-compressed GPX? .gpxz, .gpz, .gpx.zip, other? Jeremy Irish wrote: > > > Here's another vote for GPZ. It isn't an overused file extension so it > seems like a good candidate. It is also consistent to kmz as Dan > mentioned already. > > We already zip GPX files before emailing them so it makes sense for > Geocaching.com to adopt this standard. It would be good to see other > applications using it too. There are several different compression methods - zip, gzip, bzip2, plus several others. It really does not make sense to pick just one and make a new extension for it. The history of needing to change file extensions is from the old DOS 8.3 days when your filename could only have 12 characters - 8 for the name, a dot, and 3 letters for the extension. We don't need that anymore, just add the appropriate compression extension - foo.gpx.bz2 or foo.gpx.Z or foo.gpx.zip or foo.gpx.gz Google may have made a new extension for compressed kml files - but as has been pointed out, it is more than just a compression of a file, the archive can include other files in it as well. Furthermore, even though the file format is open it's designed for a specific proprietary application vendor. GPX is suppose to be an application neutral exchange format. There's no need to make numerous extensions for the numerous compression methods out there nor is there a need to encourage the use of one compression method over another, and if it did encourage the use of one - it shouldn't be zip as zip is not an open standard (even though many free utilities know how to deal with it). [Non-text portions of this message have been removed]
pk+evc.net on Wed Jan 07 06:27:15 2009 (link)
I thought until today that it was 1.1, as shown by http://www.topografix.com/gpx.asp But a user of my GPX editor program, just pointed me at http://www.topografix.com/GPX/1/2/gpx.xsd Is there any official info on that 1.2 version ?
egroups+topografix.com on Wed Jan 07 06:30:09 2009 (link), replying to msg
Hello, Wednesday, January 7, 2009, 6:51:05 AM, pixelk wrote: > I thought until today that it was 1.1, as shown by > http://www.topografix.com/gpx.asp > But a user of my GPX editor program, just pointed me at > http://www.topografix.com/GPX/1/2/gpx.xsd > Is there any official info on that 1.2 version ? It was put up there to hold the one or two changes that people had requested after 1.1 came out, so that they'd be included in any future 1.2 proposal. There is no GPX 1.2, and given the lack of interest on this mailing list in revising GPX, it's likely that GPX 1.1 will be the official GPX release for the foreseeable future. -- Dan Foster
ptomblin+gmail.com on Wed Jan 07 06:41:47 2009 (link), replying to msg
On Wed, Jan 7, 2009 at 9:29 AM, Dan Foster <egroups+topografix.com> wrote: > Hello, > > Wednesday, January 7, 2009, 6:51:05 AM, pixelk wrote: > >> I thought until today that it was 1.1, as shown by >> http://www.topografix.com/gpx.asp >> But a user of my GPX editor program, just pointed me at >> http://www.topografix.com/GPX/1/2/gpx.xsd > >> Is there any official info on that 1.2 version ? > > It was put up there to hold the one or two changes that people had > requested after 1.1 came out, so that they'd be included in any future > 1.2 proposal. There is no GPX 1.2, and given the lack of interest on > this mailing list in revising GPX, it's likely that GPX 1.1 will be > the official GPX release for the foreseeable future. Mostly I think you put it up because I wanted magnetic declination to be +/- 180 degrees instead of 0-360, since +/- 180 is the standard. -- Parks sat so King could march. King marched so that Obama could run. Obama ran so we could fly.
sunburned.surveyor+gmail.com on Wed Jan 07 07:15:38 2009 (link)
I've released a very simple Java library that allows the parsing of GPX files. I've used the library to add support for import and export of GPX entities in the open source Desktop GIS program OpenJUMP. The library can be used by client code to obtain Waypoint and Track objects from a GPX file. This current version of the library does not include support for all elements of the GPX schema. For example: Only the position, date and time collected, and name of waypoint elements are supported in this library. The library also includes code to convert waypoint and track objects obtained from a GPX file into Simple Feature objects. This would easily allow a programmer to use other code from OpenJUMP to do things like write a simple GPX to Shapefile converter. You can download the source code for my library at the SurveyOS SourceForge SVN: http://sourceforge.net/svn/?group_id=122820 http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/gpx/branches/20081114-Release/ You can download the executable code and dependencies here: http://www.redefinedhorizons.com/resources.html Landon (AKA - The Sunburned Surveyor)
h_zwakenberg+yahoo.com on Tue Jan 27 04:30:51 2009 (link)
Hi Group, currently I'm in a software project that would benefit from the GPX file format - or from one of its competing formats. I noticed there are multiple file formats that offer similar functionality. Is there a clear market leader in this field? Would that be GPX? thanks Hans __________________ http://ibis.experimentals.de
egroups+topografix.com on Tue Jan 27 04:53:26 2009 (link), replying to msg
Hello, Tuesday, January 27, 2009, 4:13:10 AM, h_zwakenberg wrote: > Hi Group, > currently I'm in a software project that would benefit from the GPX > file format - or from one of its competing formats. > I noticed there are multiple file formats that offer similar > functionality. > Is there a clear market leader in this field? Would that be GPX? To what formats would you like us to compare GPX? -- Dan Foster
mhoegh+gmail.com on Mon Feb 02 11:01:44 2009 (link)
Demo: http://wms.mapuse.net/demo/playground/phpgpx/ Source: https://sourceforge.net/project/showfiles.php?group_id=173721 The script will time code Flickr photos and output a GeoRSS feed. /martin
tomkralidis+hotmail.com on Thu Feb 05 07:00:56 2009 (link), replying to msg
--- In gpsxml+yahoogroups.com, "mhoeghgmailcom" <mhoegh+...> wrote: > > Demo: http://wms.mapuse.net/demo/playground/phpgpx/ > Source: https://sourceforge.net/project/showfiles.php?group_id=173721 > > The script will time code Flickr photos and output a GeoRSS feed. > > /martin > Nice! You might want to look at using OGR (http://www.gdal.org/ogr/) and related bindings for the various format translations. ..Tom
emmaddais+yahoo.co.uk on Sun Feb 08 08:06:53 2009 (link)
Hi to you all Am Emmanuel Owusu Addai, and am an MSc. Student trying to build a web service for Differential GPS in my final year project. And I want to know how GPX can help me in that. Basically, this is how the whole project is like. A trimble GPS antenna and receiver are connected in series to my office desktop PC. Base station data is uploaded onto my PC every hour. My assignment is to get these files uploaded automatically onto a website am yet to design. But the challenge i have is that, 1. Base station files are saved as .dat, and is compressed 2. The website would be hosted on a separate server where as the base station files are resident on my office PC. 3. My institution does not allow ftp on its system. Only HTTP Any help for me? Thanks.
egroups+topografix.com on Tue Feb 10 06:55:16 2009 (link), replying to msg
Hello, Tuesday, February 10, 2009, 9:31:36 AM, Michael wrote: > Howdy - > I'm looking to add custom tags to gpx file format to extend it to meet > my needs, but I don't want to duplicate efforts. > One area where I need to extend the format is climate - IE > sky conditions, precipitation, barometric pressure, air temperature, > surface temperature, water temperature, humidity > Obviously such extensions only make sense when the optional time tag is > used for the waypoint, but it always is in my implementation. > Anyway, is there already an extension to gpx for climate conditions? > -=- > Secondly - what I'm doing is wildlife records, so fields for things like > family, genus, species, subspecies, common name, age, sex, etc. are needed. > Is there already an extension to GPX for that? > -=- > Is there a public list of extensions to the GPX format that people have > made and felt like sharing? I'm not aware of extensions for weather or wildlife taxonomy. I'd be interested in providing feedback on any wildlife extensions you come up with. Two extensions I use: http://www.topografix.com/GPX/gpx_style/0/2/ http://www.topografix.com/GPX/gpx_overlay/0/2/ -- Dan Foster
comline+sbcglobal.net on Mon Feb 16 06:49:39 2009 (link)
I do some code, but I am trying to find some historical gpx files to view in google 5.0 any ideas? Thanx
me+slodge.com on Sat Mar 14 07:51:52 2009 (link)
Hi All I'm writing a fun GPS-centred website at the moment - http://www.runsaturday.com I'm currently integrating our database with the wonderful openstreetmap. I've discovered that OSM seems to prefer GPX 1.0 - and also it seems to insist on the GPX including timestamps for all trackpoints. Does anyone know why this is? Is GPX 1.0 with no time valid? Thanks Stuart (runsaturday)
robertlipe+usa.net on Sat Mar 14 07:55:40 2009 (link)
> I've discovered that OSM seems to prefer GPX 1.0 - and also it seems to insist on the GPX including timestamps for all trackpoints. > > Does anyone know why this is? The rationale for their preference would be best asked of them. We could speculate that they may be using it to infer locations of stops and average road speed, for example, but it would be guessing. > Is GPX 1.0 with no time valid? Yes, time is optional in all places in GPX.
mikes+ayeltd.biz on Sat Mar 14 10:17:46 2009 (link), replying to msg
At 03:49 PM 14/03/2009, runsaturday wrote: >Hi All > >I'm writing a fun GPS-centred website at the moment - http://www.runsaturday.com > >I'm currently integrating our database with the wonderful openstreetmap. > >I've discovered that OSM seems to prefer GPX 1.0 - and also it seems to insist on the GPX including timestamps for all trackpoints. > >Does anyone know why this is? Is GPX 1.0 with no time valid? I am a contributor of a very large number of tracks to OSM and always use GPX 1.1. There is a however a requirement for timestamps for all trackpoints. The rationale is that by having timestamps we have a reasonable demonstration that our maps are made from actually field observations rather than from digitisations of other potentially copyrighted sources. http://wiki.openstreetmap.org/wiki/FAQ#Why_didn.27t_my_GPX_file_upload_properly.3F And thanks for the plug! Mike Collinson OSM Foundation
jrepetto+free.fr on Tue Apr 07 05:56:59 2009 (link), replying to msg
--- In gpsxml+yahoogroups.com, "maschaffner" <maschaffner+...> wrote: > > The GPS 1.1 Documentation is unclear of the definition of the <ele> element. It says simply > "Elevation (in meters) of the point.", but does not tell wether the elevation is above sea level > (geoid) or above the WGS84 ellipsoid. > As longitude and latitude use WGS84, I assumed that <ele> is also above WGS84 ellipsoid, > but from web searches I get the impresssion that height above sea level is meant. > Could the standard be amended to clarify this? > Thanks, > Martin > Hello, I have the same problem. I am currently writing a GPS software that will generate GPX files, but I don't know if the <ele> files should contain the elevation above the geoid or above the ellipsoid. On the web, I have seen GPX files of both types. I think it is very important that this point is clarified quickly, for software interoperability. Thanks, Jean-Claude
egroups+topografix.com on Tue Apr 07 10:52:22 2009 (link), replying to msg
Hello, Tuesday, April 7, 2009, 8:27:14 AM, Jean-Claude wrote: > --- In gpsxml+yahoogroups.com, "maschaffner" <maschaffner+...> wrote: >> >> The GPS 1.1 Documentation is unclear of the definition of the <ele> element. It says simply >> "Elevation (in meters) of the point.", but does not tell wether the elevation is above sea level >> (geoid) or above the WGS84 ellipsoid. >> As longitude and latitude use WGS84, I assumed that <ele> is also above WGS84 ellipsoid, >> but from web searches I get the impresssion that height above sea level is meant. >> Could the standard be amended to clarify this? There was discussion of this around August 4, 2003 - you can use the Yahoo Groups web archive to read these old messages. Dan Foster wrote: [gpsxml] Re: explanation of <ele> is unclear Monday, August 4, 2003, 11:43:39 AM, Eino wrote: e> I want to check once more - actually I did also take a direct e> quotation from NMEA0183-GGA-message description and it was "Height of e> geoid (mean sea level) above WGS84 ellipsoid". Now our quotations of e> GGA disagree?! According to my interpretation h = ele + geoidheight e> (sum). I checked the quatation once more - could you pls do the same, e> but from NMEA source, not from Magellans ;-). I understood, that you e> anyway meant it to be the same as in GGA? We intended it to be the same as GGA. I went back to Kjeld's original request to include it. He defined it as you do: <geoidheight> Height of geoid (mean sea level) above WGS84 ellipsoid I checked the description in Magellan's manual. They write: Geoidal separation - difference between the WGS-84 earth ellipsoid and mean sea level (geoid), "-" = mean sea level below ellipsoid. That description matches your definition as well. I must have switched the two terms when writing the documentation. I'll change the documentation tomorrow, unless someone objects, to the following: <geoidheight> Height of geoid (mean sea level) above WGS84 ellipsoid As far as I know, Kjeld's CetusGPS is the only program out there using <geoidheight> now, and based on his original message, I assume he used the correct definition rather than my mistaken one. e> This "my new h" is not just another height - it is the one and only e> height used in coordinate calculations, e.g. when we convert 3D- e> rectangular coordinates (X,Y,Z) to geodetic coordinates (lat,lon,h). e> Therefore it is very important - actually mandatory in geodetic e> applications. My dream of a point element would then be e.g. e> <wpt lat="99.999" lon="99.999" height="9999.99"> e> <ele>999.999</ele> e> <geoidheight>9999.99</geoidheight> e> etc. e> This is because "my h" is _coordinate_ value as are lat and lon - e> other heights are _properties_ of the point (lat,lon,h). I realize that you need the height above the ellipsoid to do precise calculations. In instances where you have both <ele> and <geoidheight>, you can calculate this: h = height above WGS84 ellipsoid ele = height above mean sea level (geoid) geoidheight = Height of geoid (mean sea level) above WGS84 ellipsoid so, h = ele + geoidheight And if you have <ele> but not <geoidheight>, you're out of luck. You won't be able to do your calculations with the correct height data, unless you've got your own table of geoidheight values for the Earth. I did a quick search on the newsgroups for "garmin altitude geoid", and the results are troubling. Nobody has a clear answer to whether the altitude sent with Garmin waypoints is measured relative to the geoid, or to the WGS-84 ellipsoid. I've always assumed it was relative to the geoid (since end users think of altitude relative to mean sea level). I'd run outside and do a test, but it's pouring rain here...
jrepetto+free.fr on Tue Apr 07 12:55:35 2009 (link), replying to msg
Dan Foster wrote : > Hello, > Tuesday, April 7, 2009, 8:27:14 AM, Jean-Claude wrote: > >> --- In gpsxml+yahoogroups.com, "maschaffner" <maschaffner+...> wrote: >>> The GPS 1.1 Documentation is unclear of the definition of the <ele> element. It says simply >>> "Elevation (in meters) of the point.", but does not tell wether the elevation is above sea level >>> (geoid) or above the WGS84 ellipsoid. >>> As longitude and latitude use WGS84, I assumed that <ele> is also above WGS84 ellipsoid, >>> but from web searches I get the impresssion that height above sea level is meant. >>> Could the standard be amended to clarify this? > > There was discussion of this around August 4, 2003 - you can use the > Yahoo Groups web archive to read these old messages. > Hello Dan, Thanks for your answer. To summarize the result of the 2003 discussion : ele = height above mean sea level (geoid) h = height above WGS84 ellipsoid geoidheight = Height of geoid (mean sea level) above WGS84 ellipsoid h = ele + geoidheight Exemple, for my location (south of France) : geoidheight = 50 m ele = 250 m h = 300 m BTW, the current documentation on the GPX web site has not been updated. It is still saying "Elevation (in meters) of the point." Regards, Jean-Claude
ptomblin+gmail.com on Tue Apr 07 13:26:29 2009 (link), replying to msg
On Tue, Apr 7, 2009 at 4:16 PM, Michael A. Peters <mpeters+mac.com> wrote: > Elevation from a garmin is not to be trusted. I went kayaking on Lake Ontario on Saturday, and my Garmin Forerunner said that I'd climbed 83 feet and descended 81 feet. I don't think Lake Ontario falls 83 feet from Hamilton to Kingston. -- "You didn't need to. You sold ours." - Jon Stewart
bls+pathetique.com on Tue Apr 07 14:19:56 2009 (link), replying to msg
On Tue, Apr 07, 2009 at 04:26:01PM -0400, Paul Tomblin wrote: > I went kayaking on Lake Ontario on Saturday, and my Garmin Forerunner > said that I'd climbed 83 feet and descended 81 feet. I don't think > Lake Ontario falls 83 feet from Hamilton to Kingston. Holy crap, you paddled all the way from Hamilton to Kingston in a day?
ptomblin+gmail.com on Tue Apr 07 14:58:48 2009 (link), replying to msg
On Tue, Apr 7, 2009 at 5:19 PM, Brian Scearce <bls+pathetique.com> wrote: > On Tue, Apr 07, 2009 at 04:26:01PM -0400, Paul Tomblin wrote: >> I went kayaking on Lake Ontario on Saturday, and my Garmin Forerunner >> said that I'd climbed 83 feet and descended 81 feet. �I don't think >> Lake Ontario falls 83 feet from Hamilton to Kingston. > > Holy crap, you paddled all the way from Hamilton to Kingston in a > day? Not even close. I only did 5 miles out and back. That's why the 83 foot elevation change is so ridiculous. -- "You didn't need to. You sold ours." - Jon Stewart
ptomblin+gmail.com on Tue Apr 07 16:17:40 2009 (link), replying to msg
On Tue, Apr 7, 2009 at 7:04 PM, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > Yes. �In another place we had a discussion about this and reached > similar confusion. �In addition, this other place is mostly about > devices where height-above-ground is vastly more useful than either. I think I can state pretty confidently that 99% of GPS users care more about altitude MSL (above Mean Sea Level) than they do about the height above the geoid. And probably only a small percentage of them care about height above the ground (aka AGL). -- "You didn't need to. You sold ours." - Jon Stewart
TomBudlong+RoadRunner.com on Thu Apr 09 06:18:20 2009 (link), replying to msg
The geoid is bumpy and wrinkly all over. The ellipsoid is mathematically trivial, in absolute and as compared to the geoid. Could Garmin really have a model of the geoid in their firmware.? I doubt it. It is, though, a good question, and I would like to have a non-speculative answer if anyone can come up with it. . Tom Budlong From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Jean-Claude Repetto Sent: Tuesday, April 07, 2009 5:27 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: explanation of <ele> is unclear --- In gpsxml+yahoogroups.com <mailto:gpsxml%40yahoogroups.com> , "maschaffner" <maschaffner+...> wrote: > > The GPS 1.1 Documentation is unclear of the definition of the <ele> element. It says simply > "Elevation (in meters) of the point.", but does not tell wether the elevation is above sea level > (geoid) or above the WGS84 ellipsoid. > As longitude and latitude use WGS84, I assumed that <ele> is also above WGS84 ellipsoid, > but from web searches I get the impresssion that height above sea level is meant. > Could the standard be amended to clarify this? > Thanks, > Martin > Hello, I have the same problem. I am currently writing a GPS software that will generate GPX files, but I don't know if the <ele> files should contain the elevation above the geoid or above the ellipsoid. On the web, I have seen GPX files of both types. I think it is very important that this point is clarified quickly, for software interoperability. Thanks, Jean-Claude [Non-text portions of this message have been removed]
ablack+geoaviation.com on Thu Apr 09 09:07:38 2009 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Tom Budlong" <TomBudlong+...> wrote: > > The geoid is bumpy and wrinkly all over. The ellipsoid is mathematically > trivial, in absolute and as compared to the geoid. Could Garmin really have > a model of the geoid in their firmware.? I doubt it. > > > > It is, though, a good question, and I would like to have a non-speculative > answer if anyone can come up with it. > > > > . Tom Budlong > > > > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of > Jean-Claude Repetto > Sent: Tuesday, April 07, 2009 5:27 AM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Re: explanation of <ele> is unclear > > > > --- In gpsxml+yahoogroups.com <mailto:gpsxml%40yahoogroups.com> , > "maschaffner" maschaffner+ wrote: > > > > The GPS 1.1 Documentation is unclear of the definition of the <ele> > element. It says simply > > "Elevation (in meters) of the point.", but does not tell wether the > elevation is above sea level > > (geoid) or above the WGS84 ellipsoid. > > As longitude and latitude use WGS84, I assumed that <ele> is also above > WGS84 ellipsoid, > > but from web searches I get the impresssion that height above sea level is > meant. > > Could the standard be amended to clarify this? > > Thanks, > > Martin > > > > Hello, > > I have the same problem. I am currently writing a GPS software that will > generate GPX files, but I don't know if the <ele> files should contain the > elevation above the geoid or above the ellipsoid. > > On the web, I have seen GPX files of both types. I think it is very > important that this point is clarified quickly, for software > interoperability. > > Thanks, > Jean-Claude > > > > > > [Non-text portions of this message have been removed] >
dananderson2+yahoo.com on Fri Apr 10 09:19:24 2009 (link), replying to msg
Yes, Garmin has a model of the geoid in their firmware. Its resolution is another matter. The NMEA $GPGGA sentence gives the altitude above mean sea level and the height of the geoid (MSL) above the WGS84 ellipsoid. At my location, one of the GGA sentence from a Garmin GPSmap 76S has 1895 meters for the altitude above MSL and -21.7 meters for the height of geoid above the ellipsoid. A GGA sentence from a Garmin GPSmap 76Cx has 1882 meters for the altitude above MSL and -21.7 meters for the height of geoid above the ellipsoid. Most consumer receivers give the user the altitude above mean sea level, which is what I want for travel in the mountains. This is the value I would expect to see in the GPX "ele" field (and is in all of my files). Any other value (ellipsoid height, height of geoid above ellipsoid, etc.) should have been put in a field for it and defined in an extension. I would be in favor of specific definitions in the GPX specification so that it would be clear. --- In gpsxml+yahoogroups.com, "Tom Budlong" <TomBudlong+...> wrote: > > The geoid is bumpy and wrinkly all over. The ellipsoid is mathematically > trivial, in absolute and as compared to the geoid. Could Garmin really have > a model of the geoid in their firmware.? I doubt it. > > > > It is, though, a good question, and I would like to have a non-speculative > answer if anyone can come up with it. > > > > . Tom Budlong
dananderson2+yahoo.com on Fri Apr 10 09:19:24 2009 (link), replying to msg
Yes, Garmin has a model of the geoid in their firmware. Its resolution is another matter. The NMEA $GPGGA sentence gives the altitude above mean sea level and the height of the geoid (MSL) above the WGS84 ellipsoid. At my location, one of the GGA sentence from a Garmin GPSmap 76S has 1895 meters for the altitude above MSL and -21.7 meters for the height of geoid above the ellipsoid. A GGA sentence from a Garmin GPSmap 76Cx has 1882 meters for the altitude above MSL and -21.7 meters for the height of geoid above the ellipsoid. Most consumer receivers give the user the altitude above mean sea level, which is what I want for travel in the mountains. This is the value I would expect to see in the GPX "ele" field (and is in all of my files). Any other value (ellipsoid height, height of geoid above ellipsoid, etc.) should have been put in a field for it and defined in an extension. I would be in favor of specific definitions in the GPX specification so that it would be clear. --- In gpsxml+yahoogroups.com, "Tom Budlong" <TomBudlong+...> wrote: > > The geoid is bumpy and wrinkly all over. The ellipsoid is mathematically > trivial, in absolute and as compared to the geoid. Could Garmin really have > a model of the geoid in their firmware.? I doubt it. > > > > It is, though, a good question, and I would like to have a non-speculative > answer if anyone can come up with it. > > > > . Tom Budlong
dananderson2+yahoo.com on Fri Apr 10 14:50:27 2009 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > On 10 Apr 2009, at 5:19pm, Dan Anderson wrote: > > > Most consumer receivers give the user the altitude above mean sea > > level, which is what I want for travel in the mountains. This is the > > value I would expect to see in the GPX "ele" field (and is in all of > > my files). Any other value (ellipsoid height, height of geoid above > > ellipsoid, etc.) should have been put in a field for it and defined > > in an extension. I would be in favor of specific definitions in the > > GPX specification so that it would be clear. > > Can we test it empirically ? Find some place on earth where the > various (four ?) values of 'elevation' are clearly different, some GPS > units there, and see what gives what ? 1. The value in the GPGGA sentence is the altitude above mean sea level by the NMEA specification; otherwise, a company is in violation (I'm not saying that a company wouldn't do it incorrectly). 2. I am located at about 1890 meters above mean sea level. This is based on many GPS receiver readings from various Garmin receivers and the USGS topographic map. The values posted in my previous message were 1882 and 1895 meters. The offset from the ellipsoid was given as -21.7 meters by Garmin. Those values were single measurements - no averaging by me. At this time, I don't know the WGS84 ellipsoid value for my location. However, assuming the ellipsoid offset given by Garmin is close (see the value for the control point below), the values given by Garmin are closer to MSL than the ellipsoid value. 3. I have a few measurements for the NGS control point in Cheyenne Canyon. The NGS data is as follows: DATABASE = Sybase ,PROGRAM = datasheet, VERSION = 6.52 1 National Geodetic Survey, Retrieval Date = AUGUST 10, 2001 AE4292 *********************************************************************** AE4292 DESIGNATION - BROWN AE4292 PID - AE4292 AE4292 STATE/COUNTY- CO/EL PASO AE4292 USGS QUAD - MANITOU SPRINGS (1994) AE4292 AE4292 *CURRENT SURVEY CONTROL AE4292 ___________________________________________________________________ AE4292* NAD 83(1992)- 38 47 26.16654(N) 104 54 13.98288(W) ADJUSTED AE4292* NAVD 88 - 2289.1 (meters) 7510. (feet) GPS OBS AE4292 ___________________________________________________________________ AE4292 X - -1,280,769.158 (meters) COMP AE4292 Y - -4,812,171.500 (meters) COMP AE4292 Z - 3,975,648.783 (meters) COMP AE4292 LAPLACE CORR- -26.45 (seconds) DEFLEC99 AE4292 ELLIP HEIGHT- 2273.04 (meters) GPS OBS AE4292 GEOID HEIGHT- -16.13 (meters) GEOID99 AE4292 AE4292 HORZ ORDER - FIRST AE4292 ELLP ORDER - FOURTH CLASS I AE4292 AE4292.The horizontal coordinates were established by GPS observations AE4292.and adjusted by the National Geodetic Survey in October 1997. AE4292 AE4292.The orthometric height was determined by GPS observations and a AE4292.high-resolution geoid model. AE4292 AE4292.The X, Y, and Z were computed from the position and the ellipsoidal ht. AE4292 AE4292.The Laplace correction was computed from DEFLEC99 derived deflections. AE4292 AE4292.The ellipsoidal height was determined by GPS observations AE4292.and is referenced to NAD 83. AE4292 AE4292.The geoid height was determined by GEOID99. --------------------------------------------------- The second and third links under Cheyenne have elevation values. The 12XL didn't save the elevation because it was too inaccurate (and selective availability was ON when it was designed). So the first link doesn't have elevation values. See: http://www.gpsmap.net/BenchMarks.html 4. I don't compare the elevation on the topographic map (altitude above mean sea level and NAVD29, not NAVD88) vary often; however, there seems to be a tendency of Garmin receivers to give an elevation about 15 feet (4.6 meters) higher than the topographic map in the Colorado Rockies. The topographic maps are specified to have an accuracy of 1/2 the contour interval at well defined points. The contour interval is 40 feet so the accuracy is not better than 20 feet. (The 15 foot value comes from averaging something like 12 to 30 or more waypoints to 9020 feet at a trailhead that's at 9000 feet. A receiver in my hand is about 4 feet above the ground and the receiver connected to an external antenna is about 6 feet above the ground. So 20 feet - 5 feet = 15 feet above the topographic map.) According to the GPGGA sentence, the difference between the ellipsoid height and the geoid height at my location is -21.7 meters or -71 feet. Note that for the NGS control point it is -16.13 meters. So, in casual observations, the values are closer to geoid than ellipsoid. I also see 100 foot (30 meter) variations in GPS elevation readings at a given elevation so, with all the inaccuracies involved, I could be wrong.
ptomblin+gmail.com on Fri Apr 10 14:56:42 2009 (link), replying to msg
On Fri, Apr 10, 2009 at 2:58 PM, Simon Slavin <slavins+hearsay.demon.co.uk> wrote: > Can we test it empirically ? �Find some place on earth where the > various (four ?) values of 'elevation' are clearly different, some GPS > units there, and see what gives what ? It's too bad my WAAS-capable Garmin 296 got stolen. The elevation on a WAAS GPS is much more reliable than that of a non-WAAS GPS. I'd compare it with the WAAS-capable GPS in our club planes (Garmin 530) but I'm not sure if those are baro-corrected or not. -- "You didn't need to. You sold ours." - Jon Stewart
jrepetto+free.fr on Sat Apr 11 09:55:07 2009 (link), replying to msg
Dan Anderson wrote : > > 1. The value in the GPGGA sentence is the altitude above mean sea level by the NMEA specification; otherwise, a company is in violation (I'm not saying that a company wouldn't do it incorrectly). > But don't forget that the GPS system gives the height above the WGS84 ellipso? To be able to provide the height above MSL to the user, the GPS units must use a geoid model stored internally. The model can be based on the Erath Gravitational Model : http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/index.html Some GPS chipsets like the SiRF Star II or Global Locate don't include this model, and they can't deliver the height above MSL in the NMEA sentences.
craig.miller+spatialminds.com on Fri May 22 10:17:31 2009 (link)
In the schema, several items have a minOccurs=0 w/ no maxOccurs defined. Is maxOccurs to be interpreted as 1 or unbounded? We'd like to be able to define multiple symbols for one location so we can show that a particular spot has a restroom, boat launch, store, and water. Craig
craig.miller+spatialminds.com on Fri May 22 14:28:32 2009 (link), replying to msg
The schema element in question is: <xsd:element name="sym" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation> Text of GPS symbol name. For interchange with other programs, use the exact spelling of the symbol as displayed on the GPS. If the GPS abbreviates words, spell them out. </xsd:documentation> </xsd:annotation> </xsd:element> We'd like to list several <sym> elements in our GPX track. <wpt lat="38.9246500" lon="-120.7892200"> <name>002</name> <cmt>Campground</cmt> <desc>Campground</desc> <sym>Ranger Station</sym> <sym>Bathroom</sym> <sym>Store</sym> <sym>Boat Launch</sym> </wpt>If this is legal (validates against the schema), we'll do it. GPX despite it's aim to be a portable exchange format doesn't have portable symbols anyway. As long as it validates against the schema, I'll assume that other applications will at least gracefully fail. Since our symbol names aren't likely to be supported by other vendors anyway, there really is no point in trying to be compatible in the "symbol" element.For a version 1.2 GPX, I'd suggest that SVG be used for symbols. Since SVG is XML, the symbol description can be embedded into the GPX file. Craig From: Simon Slavin Sent: Friday, May 22, 2009 2:02 PM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] sym - minOccurs On 22 May 2009, at 4:53pm, nwoverlander wrote: > In the schema, several items have a minOccurs=0 w/ no maxOccurs > defined. Is maxOccurs to be interpreted as 1 or unbounded? Technically, this would indicate that you can have as many as you like. If you as suspicious about how this might apply to the item you're looking at, post and we'll discuss it. It's possible there's an error in the schema, or it's a feature that no manufacturer supports. > We'd like to be able to define multiple symbols for one location so > we can show that a particular spot has a restroom, boat launch, > store, and water. Lame as it is, this is usually done by defining several locations very close together, but I welcome reports by people who have seen otherwise. Simon. [Non-text portions of this message have been removed]
yahoo.id+magnell.org on Fri May 22 14:31:16 2009 (link), replying to msg
--- In gpsxml+yahoogroups.com, "nwoverlander" <craig.miller+...> wrote: > > In the schema, several items have a minOccurs=0 w/ no maxOccurs defined. Is maxOccurs to be interpreted as 1 or unbounded? 1 is the default if the minOccurs component is not explicitly defined. steve magnell
egroups+topografix.com on Fri May 22 15:15:40 2009 (link), replying to msg
Hello, Friday, May 22, 2009, 5:15:26 PM, Craig wrote: > The schema element in question is: > <xsd:element name="sym" type="xsd:string" minOccurs="0"> > We'd like to list several <sym> elements in our GPX track. > <wpt lat="38.9246500" lon="-120.7892200"> > <name>002</name> > <cmt>Campground</cmt> > <desc>Campground</desc> > <sym>Ranger Station</sym> <sym>Bathroom</sym> <sym>Store</sym> <sym>Boat Launch</sym> > </wpt>If this is legal (validates against the schema), we'll do it. http://www.topografix.com/GPX/1/1/gpx.xsd If you look at other element definitions in the GPX schema, you'll see that elements that can be repeated have maxOccurs explicitly defined as "unbounded". That suggests that elements that don't have maxOccurs defined are not unbounded. zero or more: <xsd:element name="wpt" type="wptType" minOccurs="0" maxOccurs="unbounded"> zero or one: <xsd:element name="sym" type="xsd:string" minOccurs="0"> Googling "maxOccurs default value" gives several references that the default value for maxOccurs is "1". What does SAXCount report when you attempt to validate such a file? (I'm not in front of my GPX development machine right now) -- Dan Foster
smithalan+bigpond.com on Sun May 24 04:47:05 2009 (link)
I'm getting an unexpected run-time error: "Unable to generate a temporary class (result=1). error CS0030: Cannot convert type 'demo3.gpxTrkTrksegTrkpt[]' to 'demo3.gpxTrkTrksegTrkpt' error CS0029: Cannot implicitly convert type 'demo3.gpxTrkTrksegTrkpt' to 'demo3.gpxTrkTrksegTrkpt[]'" on the "Dim..." line of my program which I have stripped bare to demonstrate the problem: Public Sub Main() Dim Myserializer As XmlSerializer = New XmlSerializer(GetType(gpx)) End Sub (demo3 is my project root namespace) It compiles OK which would confirm I have successfully instantiated the gpx object from the gpx.xsd file. This is my first tentative foray into XML (but not .NET programming) so it's all a bit overwhelming! It happens with both 1.0 and 1.1 versions of gpx.xsd. I'm not sure if this is a problem with gpx.xsd or .NET 2.0
craig.miller+spatialminds.com on Mon May 25 07:31:38 2009 (link), replying to msg
Thanks for the replies. My question was answered. The default if not specified is 1. Craig -------------------------------------------------- From: "Dan Foster" <egroups+topografix.com> Sent: Friday, May 22, 2009 3:11 PM To: "Craig Miller" <gpsxml+yahoogroups.com> Subject: Re[2]: [gpsxml] sym - minOccurs > Hello, > > Friday, May 22, 2009, 5:15:26 PM, Craig wrote: > >> The schema element in question is: > >> <xsd:element name="sym" type="xsd:string" minOccurs="0"> > >> We'd like to list several <sym> elements in our GPX track. >> <wpt lat="38.9246500" lon="-120.7892200"> >> <name>002</name> >> <cmt>Campground</cmt> >> <desc>Campground</desc> >> <sym>Ranger Station</sym> <sym>Bathroom</sym> <sym>Store</sym> <sym>Boat >> Launch</sym> >> </wpt>If this is legal (validates against the schema), we'll do it. > > http://www.topografix.com/GPX/1/1/gpx.xsd > > If you look at other element definitions in the GPX schema, you'll > see that elements that can be repeated have maxOccurs explicitly > defined as "unbounded". That suggests that elements that don't have > maxOccurs defined are not unbounded. > > zero or more: > <xsd:element name="wpt" type="wptType" minOccurs="0" > maxOccurs="unbounded"> > > zero or one: > <xsd:element name="sym" type="xsd:string" minOccurs="0"> > > Googling "maxOccurs default value" gives several references that the > default value for maxOccurs is "1". > > > What does SAXCount report when you attempt to validate such a file? > (I'm not in front of my GPX development machine right now) > > -- > Dan Foster > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
emmaddais+yahoo.co.uk on Mon May 25 07:32:44 2009 (link)
Hi to you all I am designing a website for DGPS online service to users. Actually, i want the (.dat) files to be automatically uploaded onto my webpage every hour, ie, after the data is received from the gps antenna logger into a folder called DAT on my personal pc in my office. I know that i have to write a web service or an application to ispect that folder to detect new files and also send it onto the school server. Please anybody to help me with that in vb.net or c#.net? Thanks
timurinan+yahoo.com on Mon Jun 01 14:54:27 2009 (link)
hi to everyone, i am working on a project about logging gps data, i have succeeded to store gps data on a mmc card but i dont know how to show position information on a map,how to send the stored data into a program that will show me the position information, waiting for your answers.
emmaddais+yahoo.co.uk on Tue Jun 02 16:51:26 2009 (link), replying to msg
Hi, am also interested in that and would be grateful if anyone would help us out.
smithalan+bigpond.com on Wed Jun 03 06:53:48 2009 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Emmanuel Owusu Addai" <emmaddais+...> wrote: > > Hi, > am also interested in that and would be grateful if anyone would help us out. > Come on guys, if you want help, you have to be much more specific in your questions. Like what platform- Windows, Unix, MAC? What GPS track type - GPX, NMEA ...? There are lots of good GPS to mapping systms freely available - EasyGPS, GPSVisualizer - just go Googling. My app, StarTrax (gpsanimator.com) takes GPS tracks and animates them through Google Earth. What help do you need?
dyrehult+yahoo.com on Thu Jun 04 05:48:49 2009 (link)
I am having some troubles with an application I'm developing with inconsistency of time tags added to the wpt tag. It seems like not all gpx files has this time-tag included in the wpt. Hence my question, what is the standard time interval a wpt tag is added to a gpx file by the sensor generating this data?
asifbasha_02501+yahoo.com on Thu Jun 04 06:53:31 2009 (link)
Hi Developers, I have to develope Windows Mobile Tracking Application(GPS) by using .NET Compact Framework 2.0. I written code in .net compact frmework 2.0 for extracting the latitude and longitudes but i am not understanding how to locate markers on the map, if any opensources are available please let me know, Thanks in advace and guide me regading this problem. Regards Asif
asifbasha_02501+yahoo.com on Thu Jun 04 06:55:05 2009 (link)
Hi Developers, ������� I am developing Windows Mobile Tracking Application(GPS) in .NET Compact Framework 2.0, i written code for extracting latitiude, longitudes but here i am not understanding how to display the position on the map(Google� Map or Yahoo Map or Virtual Earth or Flicker or Openstreet Map), Guide me regarding this. Thanks & Regards Asif [Non-text portions of this message have been removed]
robertlipe+usa.net on Thu Jun 04 10:30:17 2009 (link)
------ Original Message ------ Received: 07:48 AM CDT, 06/04/2009 From: "dyrehult" <dyrehult+yahoo.com> To: gpsxml+yahoogroups.com Subject: [gpsxml] What is the standard time interval a wpt tag is added to a gpx file? > I am having some troubles with an application I'm developing with inconsistency of time tags added to the wpt tag. It seems like not all gpx files has this time-tag included in the wpt. <time> is optional in GPX. >Hence my question, what is the standard time interval a wpt tag is added to a gpx file by the sensor generating this data? It's optional and it's not guaranteed to be added by a sensor at all. For example, I might create a GPX of buildings and use <time> to indicate when the building was built. If you're asking about logged GPX tracks, common frequencies are 1Hz, .5Hz, and 5Hz but that's up to the device and how any intervening software chooses to represent it in GPX. > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
jsalter1+comcast.net on Thu Jun 18 11:19:11 2009 (link)
Hello all, I have navigation software that exports routes to rfx but I need the file extention gpx to load into my chart reader....any ideas?
egroups+topografix.com on Tue Jun 23 08:53:49 2009 (link), replying to msg
This is a forwarded message From: Victor Pomortseff <victor.pomortseff+gmail.com> To: "support+expertgps.com" <support+expertgps.com> Date: Friday, June 19, 2009, 3:41:13 AM Subject: GPX 1.1 ===8<==============Original message text=============== At many forums on the standard GPX, discusses why the tags <speed> and <course>, present as an option in the standard GPX 1.0, disappeared from the standard GPX 1.1. For example, here: http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=106662 I have met here are saying: "speed isn't in GPX 1.1. Technically it isn't necessary since you can always recalculate speed using position and time." However, it is fundamentally wrong. That speed, which is contained in NMEA messages, the receiver is calculated directly based on the Doppler effect (it is a separate issue, which is covered in numerous articles). If you take the speed of the coordinates and time, especially in the case of small intervals between points, errors in determining coordinates (as they inevitably) lead to errors in calculating the speed of tens of percent. For example, here: http://nujournal.net/HighAccuracySpeed.pdf is a comparison between the speed measured by Doppler shift, and calculated by coordinates. Therefore, I do not think about the speed and direction of motion redundant. Moreover, I as a physicist-experimentalist (in the past - I graduated Physical-Technical Faculty of the Ural Polytechnic Institute and then spent several years at the Institute of Thermophysics, Ural Branch of Russian Academy of Sciences), believe that any information obtained from direct measurements should be be preserved to the maximum extent. So I absolutely not understand the fact of the disappearance of such parameters as speed and course from the standard GPX 1.1 (even more so that in the standard GPX 1.0 they attended). //Cheers, Victor
robertlipe+usa.net on Tue Jun 23 09:55:34 2009 (link)
Just to liven up my boring day, I'm going to argue all three sides of this: 1) We meant to do it. 2) We shouldn't do it. 3) We should do it and here's how. > At many forums on the standard GPX, discusses why the tags <speed> and <course>, present as an option in the standard GPX 1.0, disappeared from the standard GPX 1.1. In the previous times this has come up, we've agreed it was just a plain ole oversight to leave them out and not important enough to create 1.2 for, right? > "speed isn't in GPX 1.1. Technically it isn't necessary > since you can always recalculate speed using position and time." > > However, it is fundamentally wrong. That speed, which is contained in NMEA > messages, the receiver is calculated directly based on the Doppler Remember that the "X" in GPX is "eXchange". GPX doesn't strive to represent everything that every file format or GPX receiver may record. While there are GPS devices that record speed via Doppler, they're a minority. The number that expose it outside the receiver is even smaller. There are other systems that record speed in other means (wheel speed, radar, etc.) and try to merge that into GPS-ish formats but we're really slicing the pie into small pieces at that point. However, this comes up just often enough - and it's usually not controversial within the group that speed and course were intended to be present - that I wonder if this would be a good use of the <extensions> thing that we introduced in 1.1 Would an official GPX extension to 1.1 that added <extensions><speed> and <extensions><course> get any traction with fellow developers? Like most developers, I could probably add it to GPSBabel without a lot of fuss if we got together and worked out the official angle brackets. RJL
egroups+topografix.com on Tue Jun 23 12:37:31 2009 (link), replying to msg
Hello, Tuesday, June 23, 2009, 12:54:58 PM, Robert wrote: > Would an official GPX extension to 1.1 that added <extensions><speed> and > <extensions><course> get any traction with fellow developers? Like most > developers, I could probably add it to GPSBabel without a lot of fuss if we > got together and worked out the official angle brackets. I'd support an official extension schema. But my endorsement won't mean much, because my apps don't currently consider speed and course to be anything but calculated values (distance/time). So when I output GPX data, I'd skip these two new tags, since I'm not adding any new information that couldn't just be calculated by the program that parsed my GPX output. (That is, I think <gpx_ext_observed::speed> or whatever it is called should be reserved for actual observed data, not speed as calculated from distance divided by time.) There are at least four other observed values that, in my opinion, belong in an official extension schema. They are: temperature, depth, heart_rate, and cadence. (Recognize these, Garmin?) And then there are the POI extensions. <garmin::phone_number> or whatever we have now on the nuvis. Unfortunately, because there's been no interest in a GPX 1.2 spec, developers have been putting common data that ought to be shared between apps in an official schema into private namespace schemas, so we end up with <garmin:color> and <garmin:phone_number> rather than <gpx_style:color> and <gpx_poi:phone_number> Sorry to muddy the issue, but I think any discussion of what we do about course and speed has to keep in mind the other common bits of GPS info that are currently getting stuffed in private schemas. (And I'm not trying to pick on Garmin, merely using them as an example since most of us are familiar with their GPX output) -- Dan Foster
robertlipe+usa.net on Tue Jun 23 13:50:51 2009 (link)
Hi, Dan. I'm pretty much with you on most counts here. I just opened the discussion small. > mean much, because my apps don't currently > consider speed and course to be anything but calculated values > (distance/time). So when I output GPX data, I'd skip these two new > tags, since I'm not adding any new information that couldn't just be > calculated by the program that parsed my GPX output. (That is, I think As GPSBabel (and thus my head) is mostly in the conversion business, I'd rarely know if the values I'm pulling from anything were actually any more than haversine between positions anyway. I'd probably take the stance that if I was given speed or course, I'd put it in my GPX output. > There are at least four other observed values that, in my opinion, > belong in an official extension schema. They are: temperature, depth, > heart_rate, and cadence. (Recognize these, Garmin?) I wouldn't object to these. I was proposing something simple becuase it'd be unlikely to be controversial without opening a bunch of "me, too" requests. There are ambiguities in a couple of those that make them less than a slam-dunk. "Temperature" could mean ambient, outside the cockpit, or at the bottom end of a fish-finder. "Depth" means different things to a boater than to a pilot. Wheel cadence, crank cadence, or both? These are all answerable questions. It's just the kind of details we'd have to work through. If we're going to open Pandora's Box, there's a few more that we've seen on the list several times: Position - yaw, pitch, and roll. When we did the original GPX stuff, sensors that reported 3D orientation like tilt and compass were rare. Now that geotagging is common and many of the higher end cameras and even cell phones can record that information and there are programs that can use that information, a standardized way to represent it could be nice. Unique identifiers for all objects. While we have 'name' for most of our objects, it's not necessarily unique. So there's no way for an external entity to refer to "track FOO" or "waypoint BAR" within a given GPX collection. > And then there are the POI extensions. <garmin::phone_number> or > whatever we have now on the nuvis. I can't say I'm feeling the love for that one, though I wouldn't fight it. There is LOTS of data that *can* be associated with a location, but how many things other than a Nuvi (or a Nuvi mutant like CO, OR, etc.) support the concept of a phone number being associated with a location? Multiple phone numbers? Several of Garmin's extensions are really poorly thought out in terms of portability: <gpxx:Subclass>060033c04f00f2fd03001f020000cea94e00</gpxx:Subclass> Their trick of putting route points in gpxx:rpt wasn't funny, either. So while I see the Garmin extensions as a possibly interesting starting place, I don't think blessing their XSD wholescale is wise. (Which I"m sure isn't what you're proposing, Dan. I just wanted to say that for the others.) > Unfortunately, because there's been no interest in a GPX 1.2 spec, > developers have been putting common data that ought to be shared > between apps in an official schema into private namespace schemas, so > we end up with <garmin:color> and <garmin:phone_number> rather than > <gpx_style:color> and <gpx_poi:phone_number> We've gone in cycles on this. We've seen people pop in with what they're sure are Really Great Ideas that are, in reality, application-specific data that they'll push to be 1.2 and the flashbacks to the incompatibilities between 1.0 and 1.1 wash over us and we look at the installed base and we get clammy. It seems to me that the success of GPX 1.[01] should be measured by that extensibility. It was our hope (well, mine at least) during that development that people would develop extensions, work to get them supported in a few apps and then bring them to us to be formalized. For whatever reason, that's not happened. But there is a growing pile of things where we have enough industry practice to describe that we probably could formalize them in an extension, raise the usefulness of GPX, and not change the core spec itself in the process. Good luck creating an incompatible GPX 1.2 and getting Garmin to produce (and users to install!) upgrades for all of them. :-) It does strike me that above we have two different classes of data: one that's location or real-world temporal data measured by external sensors that's associated with a location, but not really GPS itself, and one that's just external data (phone numbers, etc.) that happens to be at a location. > Sorry to muddy the issue, but I think any discussion of what we do > about course and speed has to keep in mind the other common bits of > GPS info that are currently getting stuffed in private schemas. (And > I'm not trying to pick on Garmin, merely using them as an example > since most of us are familiar with their GPX output) I think that picking a common lingo is a great way to discuss this. I just don't want to follow Garmin off the same cliff. The cluetrust XSD isn't a bad one to discuss, either. Formalizing existing widespread practice in extensions seems like exactly the kind of thing we (the GPX guys) should do. The nice thing about doing it as an extension to GPX 1.1 is we don't break anybody's apps or data... As the big part of GPX 1.0 and GPX 1.1 fell on you, Dan, perhaps there's a bit of "broken back" syndrome here, which I totally understand. If the bulk of the spec and XSD implementation was done by others, would this be a reasonable starting place for a set of GPX extensions that we could agree to bless? Do we like the way this conversation just turned from "putting a few thing we forgot back in" to "formalize the most common requests we've accumulated in the 4 years since GPX 1.1 has been out"? :-) RJL
robertlipe+usa.net on Tue Jun 23 14:05:44 2009 (link)
> Course and speed measured at a point are instantaneous course and > speed. They can't be calculated using the previous and following > points, and the further apart the points are, the less accurate any > estimates would be. Of course. If you want high fidelity data, you need lots of sample points. > Nevertheless, course and speed aren't things a GPS chipset can sense. The article referenced in the OP disagrees and states that a chipset can compute speed more accurately via doppler shift recognition than via successive position points. And "course" may not be done by the GPS chipset, but - like orientation - increasingly it's done by an inexpensive part soldered next to the GPS chipset in an assembly that a consumer knows as "a GPS". Or a camera or a cell fone... > Similar to the above: nothing to do with GPS, but things that have > been sensed by GPS units which contained extra electronics. True. It depends on how strict you consider the definition of "GPS" part of "GPX" to be. If you care only about things hocked up by your favorite Sirf or MTK part (though even that set of data changes over time...) then obviously, we're already more than done. After all, it's not like the satellites have concepts of "waypoints" or "names", right? To be clear, I'm agreeing with your distinction. I'm trying to understand if you think "GPX" should really be only concerned with things that are strictly GPS. (And I'm already on record in this very thread as noting it's a slippery slope!) > So are we seeking a way forward ? If so, we shouldn't neglect two > growth areas for GPS-type information: mobile phones and digital > cameras. Both suggest information fields for consideration in any > future standard which, if neglected, will make manufacturers ignore > the new standard or squeeze data into fields inappropriately. We agree. Both of these markets were nearly non-existent when GPX was developed (well, in the geo-locationally aware sense - both existed, of course). We now have a better understanding of what those types of devices produce and what their associated programs require and we might be able to formalize that data.
egroups+topografix.com on Tue Jun 23 14:37:22 2009 (link), replying to msg
Hello, Tuesday, June 23, 2009, 5:05:11 PM, Robert wrote: > I'm trying to understand if you [meaning Simon] think "GPX" should > really be only concerned with things that are strictly GPS. (And I'm > already on record in this very thread as noting it's a slippery > slope!) My personal opinion is that we made a grave mistake by declaring that GPX was about "exchanging GPS info" when we should have said it was about "exchanging spatial info", or "exchanging everything and anything that someone could possibly attach to a real-world location". For better or for worse, the world doesn't want an XML schema for exchanging GPS waypoints. They want an XML schema for exchanging waypoints, POIs, geocaches, vector maps, flight plans, and a bunch of other things all based around the fact that they are tied to real-world points and lines. I'd really like to see us get back to extending GPX to provide a common solution for the data exchange problems that are flourishing again as GPS technology extends beyond the Garmin GPS 12 and Magellan 315 receivers that were our model when GPX 1.0 was written. Seriously, we just sat back and watched 20 different automotive GPS manufacturers create 20 different file formats for POIs. Would things have been different (better?) if GPX had offered a common extension schema for things like address and phone number? -- Dan Foster
ptomblin+gmail.com on Tue Jun 23 14:58:48 2009 (link), replying to msg
> > > From: Victor Pomortseff <victor.pomortseff+gmail.com> > > "speed isn't in GPX 1.1. Technically it isn't necessary > since you can always recalculate speed using position and time." > > However, it is fundamentally wrong. That speed, which is contained in NMEA > messages, the receiver is calculated directly based on the Doppler You know, this is something I've wondered about recently. I use a Garmin Forerunner 301 for kayak racing and training, and I've found that the speed graphs I get out of Garmin's own "Training Center" software are quite a bit different than those I get out of a third party software like Ascent. Ascent can also calculate split times at locations other than the pre-programmed ones in the GPS itself - I set it to record splits at 1 mile intervals, and I can get Ascent to calculate 1/2 mile splits, so I think it's doing some calculation based on location and time. I wonder if the difference in speed graphs is that the Garmin is giving speed to Training Center directly? -- http://www.linkedin.com/in/paultomblin [Non-text portions of this message have been removed]
ptomblin+gmail.com on Tue Jun 23 18:58:19 2009 (link), replying to msg
On Tue, Jun 23, 2009 at 9:16 PM, Simon Slavin<slavins+hearsay.demon.co.uk> wrote: > I think we should head for a GPX 2.0. �Not a big standard, but one > which manufacturers of all types of equipment will see as simple, easy > to implement, and useful. �But researching all the GPX-related domains > needed to design a good one is too much work for me alone to do. �Or > perhaps I'm just not sufficiently motivated. �As a group we could do > it -- we need a runner, a hiker, and climber, a mapmaker, a driver, a > sailor, a pilot, a photographer, etc. -- it we want to. Maybe the solution isn't a new GPX, but some sort of standard library of extensions. I have a pretty decent (in my opinion) GPX extension schema for aviation waypoint data, and I'd be really disappointed if somebody who needed similar but slightly different data would design their own extension schema instead of cooperating with me to extend mine. -- http://www.linkedin.com/in/paultomblin
robertlipe+usa.net on Wed Jun 24 12:42:05 2009 (link)
Simon: > But I want all the features in it I want (direction and tilt) and I > will deride features I don't care about (heartrate) as obvious bloat. Yes, that's been exactly the problem so far. :-) > I think we should head for a GPX 2.0. Not a big standard, but one > which manufacturers of all types of equipment will see as simple, easy > to implement, and useful. But researching all the GPX-related domains > needed to design a good one is too much work for me alone to do. Or > perhaps I'm just not sufficiently motivated. As a group we could do > it -- we need a runner, a hiker, and climber, a mapmaker, a driver, a > sailor, a pilot, a photographer, etc. -- it we want to. I'm reluctant to turn GPX into the kitchen sink. Ask a runner and a sailor what's important to each of them and they'll give opposite answers and then declare the other half as "obvious bloat", much as you just did. I'm liking the small core kernel of GPX, a blessed set of extensions for the things that are common now (direction and tilt, temperature, etc.), and the use of the <extensions> tag for domain-specific problems that can be integrated into "blessed" status once they get enough exposure to be proven to be workable and useful. Once those extensions have been implemented by enough programs to be proven useful, they can be frozen in future versions of GPX itself. It seems a pretty natural progression: experimental->one program->several programs->a proposed GPX extension->a holy GPX extension->official GPX. Victor: > Ok. In such a case, for example, will limit the information that is contained in > $ GPGLL and $ GPRMC of NMEA protocol sentensies? GPX can already capture most of that. I think GLL is covered. Speed and course in RMC were already mentioned as something we probably should care about. What specifically are you missing? >> While there are >> GPS devices that record speed via Doppler, they're a minority. The number >> that expose it outside the receiver is even smaller. > This, to put it mildly, not so. I only support a couple hundred models of GPS receivers and a few million users. Your experience in other markets may vary. The GPSMap 60 in your example does not present speed in any stored format and not even int he GPX it writes in its later firmware versions. The only references to speed in all of Garmin's non-realtime protocol specs are in reference to flightbook records or their workout devices or in their D800 PVT packets, which are never stored by the devices themselves. > If you only know the coordinates, it is not a simple task that requires some analysis [ ... ] the speed at this point is practically equal to zero Just to play devil's advocate, whether the distance is practically equal to zero or the speed is practically equal to zero doesn't really change things much for most programmers. While <speed> and <course> have excuses, I think we're all agreeing they have a place in a formal GPX extension. RJL
egroups+topografix.com on Wed Jun 24 14:24:40 2009 (link), replying to msg
Hello, [maybe it's time to start changing the subject line to better reflect what we're discussing] Wednesday, June 24, 2009, 4:11:12 PM, Simon wrote: > This would be great and it's how I always assumed GPX worked, but > since joining this list I've found it doesn't work. Because there is > no mechanism for performing some of the arrows like > a proposed GPX extension->a holy GPX extension > because nobody (here in this list or elsewhere) cares, or perhaps even > knows how to make it happen even if they do care. So if your > progression is to work, part of the 'rescue' job is to work out how to > trigger and effect each of the arrows. There are two "holy" GPX extension schemas, gpx_overlay and gpx_style. I proposed both of them back in 2004, and after some minimal input from members of this list, (even back then, not many people cared) they were blessed, given a "gpx_" prefix, and moved into the same folder hierarchy as the gpx 1.1 schema on http://www.topografix.com/gpx/ to indicated their holiness. I was hoping at the time that other extension schemas would follow. None did. I didn't have any urgent need for further compatibility with other programs after that, so the few changes I've made to my GPX output since then have gone in a private extension schema. As I recall, the "rules" we had in place for accepting an extension schema as holy went something like this: - you want it? you propose it, create and host a schema. feel free to use this mailing list to recruit others to help, but it's your project. - implement support for your schema in your app. - get a second person to implement support for your schema (proving that data can actually be exchanged between the two) - come back to this email list and ask for it to be made a standard gpx extension - respond to whatever feedback you get here, making changes to your schema if needed - after two weeks have passed with no new objections, your schema gets holy, gets a gpx_ prefix, and gets to live next to the main gpx schema. I really hate trying to find things in the GPSXML archives on Yahoo Groups, but here's one of the original posts on this topic: http://tech.groups.yahoo.com/group/gpsxml/message/463 Are these still the "rules" we want to play by? If not, how should we proceed? I'm ready to start collaborating on a handful of extension schemas related to map calibration, POIs, geotagging photos, and typed or untyped data (similar to http://code.google.com/apis/kml/documentation/extendeddata.html ) and I promise to comment on and contribute to any other proposed schemas that others take the lead on. -- Dan Foster
robmaclean+gmail.com on Wed Jul 01 07:05:32 2009 (link)
Hi All, I need to be able to send GPX files (locations, routes, via points etc.) to a remote Windows Mobile device with the Garmin XL (mobile) application on it, i.e. ideally would be sent directly to the Garmin application where user can 'accept' etc. or next-best can be sent via email / text to the email / phone function where it can be detached and accessed by the Garmin application. This will have a commercial application so all ideas very welcome. Regards, Rob
in4ster+yahoo.com on Sat Jul 11 08:36:34 2009 (link)
I am looking for ways to convert Loran C data to Lat Lon for my GPS. Any help greatly appreciated.
v.j.corr+gmail.com on Wed Jul 15 06:45:07 2009 (link)
Hello, Does anyone know a free software for converting gpx file into a 3d curve? Or another way to use the data to generate a curve? Like maybe convert it to AI or EPS formats, which would be understood by the 3d application as connected points, essentially a curve in 3d space. Thanks!
twhite139+sbcglobal.net on Sun Jul 26 16:43:57 2009 (link)
I am a auto repossessor. Many of my customers are asking for a system that tracks used cars for them. I am familiar with the components but can't find the software that runs the website. Most of the suppliers that will talk to me take all the profit out with their pricing. I need help to know where to look next.
brett.kinross+yahoo.com.au on Fri Jul 31 05:10:55 2009 (link)
Dear all I have a free camping (australia) site where people can upload their favourite camping spots and it is displayed on Google Maps. This is all stored in a MySQL database and uses PHP and XML to feed the Google map. What I was wondering if there was already a script/example of how to get info out of the MySQL database using PHP and display it in .gpx xml format? I can write this myself but why reinvent the wheel? Thanks Brett My site if anyone interested: http://www.ozcamps.net/index.php?option=com_wrapper&view=wrapper&Itemid=29
robertlipe+gmail.com on Fri Jul 31 21:35:47 2009 (link), replying to msg
> > KML generation is a bit more complicated because it involves generation > of styles to use with Placemarks and html fragments that I include with > the record (see the example kml file at A bit OT, but see http://code.google.com/p/libkml/ for easing the burden of generating and parsing KML. [Non-text portions of this message have been removed]
brett.kinross+yahoo.com.au on Sun Aug 02 04:54:20 2009 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Michael A. Peters" <mpeters+...> Thanks Michael Will give it a go. I only need to store Title, Lat, Long so should be fairly easy. Cheers
egroups+topografix.com on Wed Aug 12 08:47:17 2009 (link)
My software reports an error when a user tries to open a non-validating GPX file. I'm starting to see error reports for files with creator="Endura", which I assume were created by Lowrance' new Endura GPS receivers. Unfortunately, nobody has emailed me an actual file to test with, so the error message below is all I have: Invalid XML:...<endura:waypoint>...XML Error 0xC00CE01D on line 14, position 18 Reason: Reference to undeclared namespace prefix: 'endura'. Perhaps Robert Lipe or someone else in the group is seeing similar user reports? BTW, I'm also seeing damaged GPX files coming from Garmin nuvis, usually with garbage data in <rte><name>xxxxxxxx</name> where xx is 0x00 or other weird binary data. If you do have Waypoints.gpx from an Endura, I'd appreciate a copy emailed to me at support+expertgps.com I believe replies to this mailing list will have email attachments stripped out.
robertlipe+gmail.com on Wed Aug 12 09:14:46 2009 (link), replying to msg
On Wed, Aug 12, 2009 at 10:42 AM, Dan Foster <egroups+topografix.com> wrote: > My software reports an error when a user tries to open a > non-validating GPX file. I'm starting to see error reports for files > with creator="Endura", which I assume were created by Lowrance' new > Endura GPS receivers. Unfortunately, nobody has emailed me an actual > file to test with, so the error message below is all I have: > > Invalid XML:...<endura:waypoint>...XML Error 0xC00CE01D on line 14, > position 18 > Reason: Reference to undeclared namespace prefix: 'endura'. > > Perhaps Robert Lipe or someone else in the group is seeing similar > user reports? > I've not heard anything about them in GPSBabelsville. Though we support the .usr format, I don't hear a huge amount about Lowrance at all, actually. There is a user or two of the Endura line that have a thread running in the Groundspeak forums. As I know you hang out there sometime, I'd suggest posting a request on http://forums.groundspeak.com/GC/index.php?showtopic=227830 I have it on good authority that the forum moderator there would consider such a request for files or reasonable discussions of compatibility issues to be pertinent. :-) But what you're describing seems pretty straightforward. They're using a ns: prefix without a declaration of a xmlns= in the header, right? That's bad XML. > BTW, I'm also seeing damaged GPX files coming from Garmin nuvis, > usually with garbage data in <rte><name>xxxxxxxx</name> where xx is > 0x00 or other weird binary data. > I hear way more about Nuvi than I do Endura (heaven knows there are more of them) and I've not seen this one, but I've long suspected that my users tend to write more to Nuvis than read from them. I'd definitely send that (along with model number and firmware version) to Garmin support/engineering. FWIW, there was a high profile publisher of GPX files a year ago that kept publishing files with "naughty" characters in them like this. While that bug has been fixed, this snippet remains and explains how I reflected the pressure back to the publisher to fix it: if ( val < 32 ) { warning( MYNAME ": Ignoring illegal character %s;\n\tConsider emailing %s at <%s>\n\tabout illegal characters in their GPX files.\n", badchar, gpx_author?gpx_author:"(unknown author)", gpx_email?gpx_email:"(unknown email address)" ); memmove( badchar, semi+1, strlen(semi+1)+1 ); The "X" in "GPX" only works if we all write GPX that's actually well formed. It's great that GPS devices are supporting it "natively", but they have to play by the rules to get the benefits of interoperability. RJL [Non-text portions of this message have been removed]
david.hayes+spindriftpages.net on Tue Sep 15 07:21:48 2009 (link)
Hi, I want to record photo information in a GPX file probably as an extension to wptType. Primarily I want to record the lat/long of the photo but ideally I'd like to include * Comments/Description * Tilt of Camera * Direction of Camera * .. Is there an extension around I can reuse(I can't find one)? If not should there be one? Does anyone have any thoughts on what info should be captured? Thanks in advance for your input David Hayes PS: I'm building a cell phone application for recording a hike (for example) along with photos etc for exporting to a GPX or KML file
kirill.polishchuk+yahoo.com on Sat Sep 19 09:56:38 2009 (link)
During some time coordinates (lat, lon) aren't changed, ie object was stopped. What is the best way to write this data if I don't intend to write all the points but then reading gpx I can determine coordinate at every moment accurately? Thanks.
wally.wedel+gmail.com on Sun Sep 27 07:02:11 2009 (link)
I currently use Garmin RoadTrip or BaseCamp to capture waypoints and tracks from an Oregon 550t. In addition to the application identifier that Garmin includes in the GPX file, I would like to have the device providing the information identified. Does GPX support inclusion of that information? Would it be done through the extension mechanism in the metadata? If anyone can point me to existing extensions providing that information, I would be grateful. [Non-text portions of this message have been removed]
egroups+topografix.com on Tue Sep 29 09:48:59 2009 (link), replying to msg
Hello, Sunday, September 27, 2009, 9:58:32 AM, wallywedel wrote: > > I currently use Garmin RoadTrip or BaseCamp to capture waypoints and > tracks from an Oregon 550t. In addition to the application identifier > that Garmin includes in the GPX file, I would like to have the device > providing the information identified. > Does GPX support inclusion of that information? Would it be done through > the extension mechanism in the metadata? > If anyone can point me to existing extensions providing that > information, I would be grateful. There's nothing to stop you from changing the text in the creator attribute from "Garmin BaseCamp" to "Garmin BaseCamp Oregon 550t" or "Wally Wedel, using a Garmin Oregon 550t with cleanup in Garmin BaseCamp" -- Dan Foster
wally.wedel+gmail.com on Tue Sep 29 10:03:23 2009 (link), replying to msg
Right, I understand that. After further consideration and investigation, though, I am proceeding with inserting device information into extension elements in the gpx files. SInce Garmin has defined device extensions, it seems like using them is the way to go. --- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > > Hello, > > Sunday, September 27, 2009, 9:58:32 AM, wallywedel wrote: > > > > > I currently use Garmin RoadTrip or BaseCamp to capture waypoints and > > tracks from an Oregon 550t. In addition to the application identifier > > that Garmin includes in the GPX file, I would like to have the device > > providing the information identified. > > Does GPX support inclusion of that information? Would it be done through > > the extension mechanism in the metadata? > > If anyone can point me to existing extensions providing that > > information, I would be grateful. > > There's nothing to stop you from changing the text in the creator > attribute from "Garmin BaseCamp" to "Garmin BaseCamp Oregon 550t" or > "Wally Wedel, using a Garmin Oregon 550t with cleanup in Garmin > BaseCamp" > > > > -- > Dan Foster >
keyork+xtra.co.nz on Wed Oct 07 06:23:20 2009 (link)
Hi, I intend to use the GPX 1.1 standard for a project I'm doing in aid of my Master's Thesis. I see that the release date is August 9, 2004. Since it is the result of open development who or what should I credit as author/owner? My bibliography wants to know. Thanks Ken
wally.wedel+gmail.com on Wed Oct 07 06:34:46 2009 (link), replying to msg
Since the etrex is older, it may not support the same things that the Oregon series does. When the Oregon mounts on my system, I see 2 USB mass storage devices. One is labelled "Garmin" and the other "Garmin4G". Garmin4G is the SD card and only holds my additional maps. Garmin is the built-in device memory and that is where the configuration files appear. The Oregon when it mounts reports that it is generating these files. HTH --- In gpsxml+yahoogroups.com, "Philippe Bettler" <pbettler+...> wrote: > > I have an etrex vista HCX and was trying to do the same, but I can't > find any xml file on the micro SD card I have inserted in the device. > I do see my gpx files but nothing more. > Do you know if there is another way to identify the device without using > the serial interface from Garmin? > I have searched the web, but haven't found any information, > Many thanks in advance. > - Philippe > > ----- Original Message ----- > From: "Dan Foster" > To: wallywedel > Subject: Re: [gpsxml] Device information in GPX files > Date: Tue, 29 Sep 2009 12:47:42 -0400 > > > Hello, > > Sunday, September 27, 2009, 9:58:32 AM, wallywedel wrote: > > > > > I currently use Garmin RoadTrip or BaseCamp to capture waypoints > and > > tracks from an Oregon 550t. In addition to the application > identifier > > that Garmin includes in the GPX file, I would like to have the > device > > providing the information identified. > > Does GPX support inclusion of that information? Would it be done > through > > the extension mechanism in the metadata? > > If anyone can point me to existing extensions providing that > > information, I would be grateful. > > There's nothing to stop you from changing the text in the creator > attribute from "Garmin BaseCamp" to "Garmin BaseCamp Oregon 550t" or > "Wally Wedel, using a Garmin Oregon 550t with cleanup in Garmin > BaseCamp" > > > > -- > Dan Foster > > > > ------------------------------------ > > Yahoo! Groups Links > > > > > [Non-text portions of this message have been removed] >
robertlipe+gmail.com on Wed Oct 07 06:35:13 2009 (link), replying to msg
Garmin's USB protocol returns the unit ID and serial number of those devices over the USB or serial lines. There is no device.xml on the Garmins that don't really speak GPX natively/fluently such as the whole eTrex line and and the 60/76 families. On Tue, Sep 29, 2009 at 1:40 PM, Philippe Bettler <pbettler+iname.com>wrote: > I have an etrex vista HCX and was trying to do the same, but I can't > find any xml file on the micro SD card I have inserted in the device. > I do see my gpx files but nothing more. > Do you know if there is another way to identify the device without using > the serial interface from Garmin? > I have searched the web, but haven't found any information, > Many thanks in advance. > - Philippe > > ----- Original Message ----- > From: "Dan Foster" > To: wallywedel > Subject: Re: [gpsxml] Device information in GPX files > Date: Tue, 29 Sep 2009 12:47:42 -0400 > > > Hello, > > Sunday, September 27, 2009, 9:58:32 AM, wallywedel wrote: > > > > > I currently use Garmin RoadTrip or BaseCamp to capture waypoints > and > > tracks from an Oregon 550t. In addition to the application > identifier > > that Garmin includes in the GPX file, I would like to have the > device > > providing the information identified. > > Does GPX support inclusion of that information? Would it be done > through > > the extension mechanism in the metadata? > > If anyone can point me to existing extensions providing that > > information, I would be grateful. > > There's nothing to stop you from changing the text in the creator > attribute from "Garmin BaseCamp" to "Garmin BaseCamp Oregon 550t" or > "Wally Wedel, using a Garmin Oregon 550t with cleanup in Garmin > BaseCamp" > > > > -- > Dan Foster > > > > ------------------------------------ > > Yahoo! Groups Links > > > > > [Non-text portions of this message have been removed] > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
egroups+topografix.com on Wed Oct 07 08:33:27 2009 (link), replying to msg
Hello Ken, Wednesday, October 7, 2009, 12:50:38 AM, Keyork wrote: > I intend to use the GPX 1.1 standard for a project I'm doing in aid > of my Master's Thesis. I see that the release date is August 9, > 2004. Since it is the result of open development who or what should > I credit as author/owner? My bibliography wants to know. All contributions to the GPX standard were made through this discussion forum. My wife, an editor, suggests that you cite the author as GPX Developers Forum, or simply omit the author (ask your advisor what he wants to see). If you include a URL, I'd suggest http://www.topografix.com/gpx, since that leads to the best information about the GPX standard. Or link to the GPX 1.1 schema, at http://www.topografix.com/GPX/1/1/gpx.xsd. The direct link to the GPX Developers Forum is http://groups.yahoo.com/group/gpsxml -- Dan Foster
steffen.schilke+gmx.net on Sat Nov 14 22:47:21 2009 (link)
'Location-Based' Services in a mobile environment survey You are being invited to take part in a research study. The aim of this research is to investigate the extent to which users are aware of 'location-based' recommendation services and their perception of such services. The research will ultimately proceed to propose new methods that overcome (or at least reduce) identified problems. http://www.schilke.net/survey/ Keywords: mobile internet, location based services, recommendation, personalization Please disseminate this announcement to any relevant lists and among your colleagues/students.
sandeep_shrivastava+yahoo.com on Sun Nov 29 06:47:54 2009 (link)
Hi I am a newbie to GPS technology. I am developing an application that loads the image of a floor plan of a building. A laptop is connected to a GPS device and a measuring instrument. When the use clicks on "Capture" button in the software on laptop, it stores the measurement from the instrument and the coordinates from the GPS device and relates them together. The user then moves to another location and selects captures again. The user would be moving with the laptop, GPS Device and the measurement instrument. 1. Could you tell me if this is possible? 2. Can I get track the user movements on a two dimensional map (floor plan) and get the user's position? 3. Could you give me any forums where I can post my question? I am a bit lost. Any help would be greatly appreciated. Thank you
drummerdavee+hotmail.com on Sat Dec 05 16:28:48 2009 (link)
Hi, I am a newbie to this group. I would like to ask if anyone has source code for reading from and writing to gpx files in vb. I probably could have a go at writing my own but don't really want to reinvent the wheel if I don't have to.
drummerdavee+hotmail.com on Mon Dec 07 07:22:59 2009 (link)
Hi, I have already created the class using xsd tool and would like some source code for reading and writing to the gpx file. I have a sql server database and want to create gpx file from some of the entries in the database. They have OSGB grid refs and I am changing this into lat and long values and then want to write them to gpx file so that I can transfer to Garmin GPS 60.
smithalan+bigpond.com on Wed Dec 09 07:42:46 2009 (link), replying to msg
So where are you stuck? Here is some of code to read a gpx file that may help: Private Sub LoadGPXData() Dim MyFileStream As FileStream = New FileStream(openFileName, FileMode.Open) Dim i As Integer = 0 Dim Myserializer As XmlSerializer = New XmlSerializer(GetType(gpxType)) Dim mygpx As gpxType = New gpxType Try mygpx = CType(Myserializer.Deserialize(MyFileStream), gpxType) Catch ex As Exception MsgBox("Unable to convert the GPX file - ensure that it conforms to GPX 1.1 (http://www.topografix.com/GPX/1/1 and try again") Exit Sub End Try Dim Singletrk As trkType Dim SingletrkSeg As trksegType Dim SingletrkPt As wptType For Each Singletrk In mygpx.trk For Each SingletrkSeg In Singletrk.trkseg() For Each SingletrkPt In SingletrkSeg.trkpt() ReDim Preserve TrkPts(i) TrkPts(i) = New TrkPtClass With TrkPts(i) .lat = SingletrkPt.lat .lon = SingletrkPt.lon .lat = SingletrkPt.lat .reportedAlt = SingletrkPt.ele / feetToMetres ' GPX data ele is provided in metres .Time = SingletrkPt.time.ToOADate() End With i += 1 Next Next Next End Sub As you can see, it's pretty powerful stuff. Enjoy, --- In gpsxml+yahoogroups.com, drummerdavee+... wrote: > > Hi, I have already created the class using xsd tool and would like some source code for reading and writing to the gpx file. I have a sql server database and want to create gpx file from some of the entries in the database. They have OSGB grid refs and I am changing this into lat and long values and then want to write them to gpx file so that I can transfer to Garmin GPS 60. >
drummerdavee+hotmail.com on Mon Dec 14 05:01:24 2009 (link)
Does anyone have any code to read and access ROUTES from a gpx file please? Also help on writing a route to a gpx file would be most helpful. Thanks
robertlipe+gmail.com on Wed Dec 23 10:37:27 2009 (link)
Over time, we've collected a few commonly used extensions to GPX 1.1. There's been some interest in rolling these into one set of extensions that, if widely accepted and agreed are usable, standardizing for GPX 1.2. If you have interest in extending GPX 1.1, please review and comment upon this draft. *Please don't use this XSD for any purpose other than experimenting with the extension. Don't base software on it or release such data into the wild.* RJL * * *Extending GPX 1.1* *Status* Draft. Consuming focus isn't on angle brackets yet. *Summary* Publish an extention to GPX 1.1 to address perceived shortcomings with GPX as a storage for GPS and similar data. *Background* GPX http://www.topografix.com/gpx.asp is an XML file format focusing on a lightweight interchange of GPS data. It is produced or consumed by over a hundred applications http://www.topografix.com/gpx_resources.asp , making it a leading representation of GPS data. It has gained such widespread use that many Garmin and other receivers actually parse and generate GPX as their native file format. GPX 1.0 was published in in 2002 with an incremental bump to GPX 1.1 to add an <extensions> scheme and a few other enhancements in August of 2004. The specification is showing a bit of age. Many of the concepts in it are rooted in GPS receivers that were designed around the turn of the decade. Concepts like geotagging, cross-file linking, device sensors such as compass or accelerometers, and representation in 3D spinny globes were simply not widespread at the time. *Overview* The GPX 1.1 schema http://www.topografix.com/GPX/1/1/ defines an extensionsType http://www.topografix.com/gpx/1/1/#type_extensionsType that may be used to extend most data type by adding another schema. We will extend GPX to include current interesting sensor data such as compass data, select workout data, orientation (heading/tilt/roll), and similar data,, but while we have the XSD open, we'll capture some of the common requests of the GPX user base that don't complicate our implementation just in the name of having a single, comprehensive, extension. *Example of current art using extensions.* Garmin has successfully extended GPX 1.1. Here's an example of a single waypoint and a two point track: <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.garmin.com/xmlschemas/GpxExtensions/v3 http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd http://www.garmin.com/xmlschemas/TrackPointExtension/v1 http://www.garmin.com/xmlschemas/TrackPointExtension/v1/TrackPointExtensionv1.xsd "> <time>2009-07-10T15:52:58Z</time> <bounds minlat="25.061784000" minlon="-122.274499000" maxlat="50.982884000" maxlon="121.640268000"/> <wpt lat="35.825017000" lon="-86.847151000"> <ele>244.540000</ele> <time>2008-04-26T17:47:58Z</time> <name>HOME</name> <cmt>26-APR-08 12:46:58PM</cmt> <desc>26-APR-08 12:46:58PM</desc> <sym>Residence</sym> </wpt> <trk> <name>Current Track: 11 MAY 2008 12:46</name> <trkseg> <trkpt lat="35.825031000" lon="-86.847124000"> <ele>262.100000</ele> <time>2008-05-11T17:46:24Z</time> <extensions><gpxtpx:TrackPointExtension><gpxtpx:atemp>22.4</gpxtpx:atemp> </gpxtpx:TrackPointExtension> </extensions> </trkpt> <trkpt lat="35.825016000" lon="-86.847110000"> <ele>261.140000</ele> <time>2008-05-11T17:47:15Z</time> <extensions><gpxtpx:TrackPointExtension><gpxtpx:atemp>22.4</gpxtpx:atemp> </gpxtpx:TrackPointExtension> </extensions> </trkpt> </trkseg> </trk> </gpx> Cluetrust has also made an attempt at extending GPX specifically for the sporting markets. See http://www.cluetrust.com/Schemas/gpxdata10.xsd *Extensions* The extensions break down into four categories: sensor data, physical orientation, unique IDs, and human-recognizable addresses. Some of the items may not make immediate sense for each of the waypoint, track, route (what is the heart rate of a point?) but no attempt is made to separate them. If you want to use cadence for the average RPMs of a windmill or something similar, we don't go out of our way to stop you. Sensor Data <mSpeed> Measured Speed Speed as measured via an external source such as water transducer or via doppler calculation. Notably, this is NOT simply speed as computed via successive timestamped position fixes. Units: meters per second Extends: wptType, trkType, rteType Simple Type <mCourse> Measured Course Instantaneous direction of motion or facing direction as computed via a non-GPS source such as a compass. This is not course as computed via successive position fixes. Units: degrees, true Extends: wptTpe, trkType, rteType SimpleType <temp> Temperature Must include a source: ambient, water, outside air. Units: degrees Celsius Extends: wptTpe, trkType, rteType SimpleType <depth> Depth Depth, in meters, such as reported by sonar. Extends: wptType, trkType, rteType Simple Type <heartrate> Heart Rate Heart rate Units: beats per minute Extends: wptType, trkType, rteType SimpleType <cadence> Cadence Revolutions per minute of crank or wheel. TODO *Decide if a complex type with a source is better or worse than two simple types*. Units: revolutions per minute ComplexType ?? <here down gets sketchy> Physical orientation - <Orientation> Describes the rotation of an object in space, such as the orientation of a flux gate compass. ComplexType <heading> Rotation about the z axis (normal to the Earth's surface). A value of 0 (the default) equals North. A positive rotation is clockwise around the z axis. Units: degrees 0-360 SimpleType <tilt> Rotation about the x axis. A positive rotation is clockwise around the x axis Units: degrees 0-360 SimpleType <roll> Rotation about the y axis. A positive rotation is clockwise around the y axis. Units: degrees 0-360 SimpleType Unique IDs <guid> A GUID, uniquely identifying this object so that it may be referenced externally SimpleType Addresses <address> street, city, state, country, postal ComplexType <phone> Phone Simple May repeat. *Allow infinite? Try to separate H/W/Fax?* 10/15/09 Here's a snapshot of the XSD <?xml version="1.0"?> <xsd:schema targetNamespace="http://www.robertlipe.com/blahblah" elementFormDefault="qualified" xmlns="http://www.robertlipe.com/blahblah" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="GPXExtension" type="GPXExtension" /> <xsd:complexType name="GPXExtension"> <xsd:sequence> <!-- TODO: Tigthten up these types --> <xsd:element name="mSpeed" type="xsd:double" minOccurs="0" /> <xsd:element name="mCourse" type="degreesType" minOccurs="0" /> <xsd:element name="temperature" type="temperatureType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="depth" type="xsd:double" minOccurs="0" /> <xsd:element name="heartrate" type="xsd:double" minOccurs="0" /> <xsd:element name="cadence" type="xsd:double" minOccurs="0" /> <xsd:element name="Address" type="AddressType" minOccurs="0" /> <xsd:element name="Phone" type="PhoneType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="Orientation" type="OrientationType" minOccurs="0" /> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="tempSource"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="ambient"/> <xsd:enumeration value="water"/> <xsd:enumeration value="outer"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="temperatureType"> <xsd:simpleContent> <xsd:extension base="xsd:token"> <xsd:attribute name="source" type="tempSource" default="ambient" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <!-- From the GPX 1.1 XSD --> <xsd:simpleType name="degreesType"> <xsd:annotation> <xsd:documentation> Used for bearing, heading, course. Units are decimal degrees, true (not magnetic). </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:decimal"> <xsd:minInclusive value="0.0"/> <xsd:maxExclusive value="360.0"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="AddressType"> <xsd:sequence> <xsd:element maxOccurs="2" type="xsd:token" name="streetAddress" /> <xsd:element minOccurs="0" type="xsd:token" name="city" /> <xsd:element minOccurs="0" type="xsd:token" name="state" /> <!-- ISO 3166 ? --> <xsd:element minOccurs="0" type="xsd:token" name="country" /> <xsd:element minOccurs="0" type="xsd:token" name="postalCode" /> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="phoneType"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="home"/> <xsd:enumeration value="work"/> <xsd:enumeration value="fax"/> </xsd:restriction> </xsd:simpleType> <!-- Maybe phoneType is an arbitrary string. Maybe phone # should be stricter, but how well will that internationalize? --> <xsd:complexType name="PhoneType"> <xsd:simpleContent> <xsd:extension base="xsd:token"> <xsd:attribute name="category" type="phoneType" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:complexType name="OrientationType"> <xsd:sequence> <xsd:element name="heading" type="degreesType" minOccurs="0" /> <xsd:element name="tilt" type="degreesType" minOccurs="0" /> <xsd:element name="roll" type="degreesType" minOccurs="0" /> </xsd:sequence> </xsd:complexType> </xsd:schema> And here's a horror of a GPX file that shows what such a GPX might look like: <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.1" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxe="http://www.robertlipe.com/blahblah" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.robertlipe.com/blahblahgpxe.xsd"> <wpt lat="1.000000000" lon="1.000000000"> <name>WPT001</name> <cmt>WPT001</cmt> <desc>WPT001</desc> <extensions> <GPXExtension xmlns="http://www.robertlipe.com/blahblah"> <mSpeed>120</mSpeed> <mCourse>93.1</mCourse> <temperature source="water">23.1</temperature> <temperature> 35.1</temperature> <depth>1234</depth> <heartrate>56</heartrate> <cadence>78</cadence> <Address> <streetAddress>1600 Oak Street</streetAddress> <streetAddress>Building 1234</streetAddress> <city>Mountain View</city> <state>TN</state> <country>USA</country> <postalCode>37064</postalCode> </Address> <Phone category="home">615-123-4568</Phone> <Phone category="work">615-234-5678</Phone> <Phone category="fax">615-234-5678</Phone> <Orientation> <heading>12</heading> <tilt>34</tilt> <roll>56</roll> </Orientation> </GPXExtension> </extensions> </wpt> </gpx> [Non-text portions of this message have been removed]
ptomblin+gmail.com on Wed Dec 23 10:47:47 2009 (link), replying to msg
I hope somewhere along the way to 1.2 you include my pet peeve, the fact that magnetic variation (declination) is defined as being 0-360 when it's conventionally -180-180. -- http://www.linkedin.com/in/paultomblin http://careers.stackoverflow.com/ptomblin
robertlipe+gmail.com on Wed Dec 23 10:55:29 2009 (link), replying to msg
On Wed, Dec 23, 2009 at 12:47 PM, Paul Tomblin <ptomblin+gmail.com> wrote: > I hope somewhere along the way to 1.2 you include my pet peeve, the > fact that magnetic variation (declination) is defined as being 0-360 > when it's conventionally -180-180. > I don't forsee changing the existing tags in incompatible ways. It's not like GPX area really meant to be read by humans and subtracting/adding 180 isn't exactly hard. But if it's something widely supported, I'm not opposed to it. (I probably wouldn't personally vote for it.) RJL [Non-text portions of this message have been removed]
pbirch16+tesco.net on Wed Dec 23 14:54:55 2009 (link)
Hi Could anyone tell me how to translate the latitiude and logitude of each waypoint in the route to a description of the point as presented by the satnav when you are actually navigating. For example: "Turn right on to Main Street" etc. Thanks
keyork+xtra.co.nz on Wed Dec 23 14:56:33 2009 (link), replying to msg
Thank you Robert I am all for providing support for recording any data that is commonly supplied by current GPS based units. Measured speed and course are a definite yes, I'm surprised that they weren't in the original standard. However, I believe that the units for speed should be KPH to support the most common usage. Also names such as 'Current Speed' or 'Instant Speed' or even just 'Speed' could be considered. Having Measured Course as well as Heading maybe redundant. If Orientation were allowed to contain only Heading, then it could be used to store Measured Course (bearing) as well. It is true that a point can't have a heartbeat but neither can it have a speed or bearing; these terms are understood to refer to the device's or user's status at that point. The user's or device's status at a location and/or point in time is very much the sort of thing I would expect GPX to record. Cadence and Heartbeat seem to be much the same, I would use the more generic term cadence and set the units as 'rate per minute'. This way you could record RPM, Heart Rate and even Tempo, if you're feeling musical ;-). The application would know what was intended. One last comment; recording contact details such as address and phone seem to me to be outside the scope of GPX. Incorporating GUID's so that information in GPX files can be related to data in external XML or other sources may address the actual need here. GPX should be about providing a path or about relating external information to a specific location and/or time . There are already many schemas that can be used to provide contact lists; such data seems more PDA than GPS. Ken [Non-text portions of this message have been removed]
robertlipe+gmail.com on Wed Dec 23 15:18:04 2009 (link), replying to msg
On Wed, Dec 23, 2009 at 4:29 PM, Ken York <keyork+xtra.co.nz> wrote: > Thank you Robert > > I am all for providing support for recording any data that is commonly > supplied by current GPS based units. Measured speed and course are a > definite yes, I'm surprised that they weren't in the original standard. Very few commodity units support it now. Even fewer did when the original work was done. For extra credit, name a half dozen GPSes that record measured speed and course. (I'm not being argumentative; I'm really interested in seeing how real-world this is.) However, I believe that the units for speed should be KPH to support the > most common usage. Walkers and hikers would disagree. Numeric precision as it is, I think I'd rather have absurdly large numbers for, say, a plane's movement than "rounded to zero" numbers for a hiker. > Also names such as 'Current Speed' or 'Instant Speed' or even just 'Speed' > could be considered. Having Measured Course as well as Heading maybe > redundant. If Orientation were allowed to contain only Heading, then it > could be used to store Measured Course (bearing) as well. > > It is true that a point can't have a heartbeat but neither can it have a > speed or bearing; these terms are understood to refer to the device's or > user's status at that point. The user's or device's status at a location > and/or point in time is very much the sort of thing I would expect GPX to > record. Cadence and Heartbeat seem to be much the same, I would use the more > generic term cadence and set the units as 'rate per minute'. This way you > could record RPM, Heart Rate and even Tempo, if you're feeling musical ;-). > The application would know what was intended. > Workout geeks disagree. Heartrate, the speed their wheels are turning, and the speed their feet are turning are very different things to a cyclist. Units like the Garmin Edge definitely store and report these as independent fields. > One last comment; recording contact details such as address and phone seem > to me to be outside the scope of GPX. Incorporating GUID's so that > information in GPX files can be related to data in external XML or other > sources may address the actual need here. GPX should be about providing a > path or about relating external information to a specific location and/or > time . There are already many schemas that can be used to provide contact > lists; such data seems more PDA than GPS. We said that the first time around. (I probably argued against it myself - after all, if you have a lat/long, why do you need a street address?) It's come up in the list several times and software without access to geocoders could benefit from knowing this foto was taken in "Tempe, AZ" or the street address of the restaraunt that was geocoded is actually "123 Oak Street". Oh, and here's the fone number in case you want to call ahead for reservations. Routes could benefit from having the street addresses in them ("Turn left onto Old Hickory Boulevard") even when the application or reader doesn't have a street address. The feature set I picked here was very much influenced by things that have come up on this list multiple times. Many of them we originally considered and argued against. Dan Foster's frustration can be heard at http://tech.groups.yahoo.com/group/gpsxml/message/2002 I don't think we want to turn it into the kitchen sink (and I don't think Dan wants that either) but the landscape has changed since the original work is done. We have the benefit of looking at how people have extended GPX in real world ways for real world problems and it seems worthwhile to try to try to roll those things into a standardized way of spelling them. RJL [Non-text portions of this message have been removed]
robertlipe+gmail.com on Wed Dec 23 15:25:10 2009 (link), replying to msg
On Wed, Dec 23, 2009 at 3:04 PM, Simon Slavin <slavins+hearsay.demon.co.uk>wrote: > > On 23 Dec 2009, at 6:37pm, Robert Lipe wrote: > > > <mCourse> Measured Course > > > > Instantaneous direction of motion or facing direction as computed via a > > non-GPS source such as a compass. This is not course as computed via > > successive position fixes. > > Relative to what ? Due north ? Magnetic north ? Does it make sense for this to be anything other than Magnetic north? I agree we should specify. > > <depth> Depth > > > > Depth, in meters, such as reported by sonar. > > I assume this is purely for underwater ops. If not, then you need to know > relative to what ? Sea level ? Geoid ? Also, does this connect with > altitude ? > Depth-finders for boats is where this seems to come up, but the other place we see "depth" in the industry is in describing "columns" of airspace, such as no-fly zones around tall buildings that matter more to low flying craft than high-flyers. I get the sense that the use of the former dwarfs the latter, but I'm looking to this crowd to advise if casting this as marine-style use right. > > > Unique IDs > > > > <guid> A GUID, uniquely identifying this object so that it may be > referenced > > externally > > Good idea. Also, you might want a URL tag so internet-connected devices > can be programmed to go straight there without having to do any > interpretation. A worthwhile idea. > > SimpleType > > > > Addresses > > > > <address> street, city, state, country, postal > > Will not please users from other countries. I would recommend this is > split into two: one is a freeform text field which can have all the above > in. The other is a <postalcode> field which has just postcode/ZIPcode. > Units which include such information in map files could automatically > include that tag in saved points. > Actually, I just got lazy in the description. The actual XSD is closer to what I had in mind, though we probably dwo want two fields for street address More fields is better than fewer, IMO. <xsd:complexType name="Address_t"> <xsd:sequence> <xsd:element name="StreetAddress" type="xsd:token" minOccurs="0" maxOccurs="2"/> <xsd:element name="City" type="xsd:token" minOccurs="0"/> <xsd:element name="State" type="xsd:token" minOccurs="0"/> <xsd:element name="Country" type="xsd:token" minOccurs="0"/> <xsd:element name="PostalCode" type="xsd:token" minOccurs="0"/> <xsd:element name="Extensions" type="Extensions_t" minOccurs="0"/> </xsd:sequence> </xsd:complexType> > > <phone> Phone > > > > Simple May repeat. *Allow infinite? Try to separate H/W/Fax?* > > Yes, you're going to want to be able to put two or more numbers in there, > with each one tagged with what kind of number it is. Attributes, I assume. Agreed. Again, better described in the xsd than the textual description. I'll nail that down. RJL > Simon. > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
robertlipe+gmail.com on Wed Dec 23 15:29:10 2009 (link), replying to msg
On Mon, Dec 21, 2009 at 1:11 PM, pbirch16 <pbirch16+tesco.net> wrote: > Hi > Could anyone tell me how to translate the latitiude and logitude of each > waypoint in the route to a description of the point as presented by the > satnav when you are actually navigating. For example: "Turn right on to > Main Street" etc. > Is this really a question about the GPX format, or is it how to use the GPX data on your Nuvi? If you load a GPX route into your Nuvi, it will geocode the turn points so it can do the "turn left onto Main Street" thing. Once the unit stores the resulting GPX file, it writes the stree addresses into a Garmin GPX extension. RJL [Non-text portions of this message have been removed]
davep+confluence.org on Wed Dec 23 17:02:17 2009 (link), replying to msg
On 2009/12/23 3:25 PM, Robert Lipe wrote: > On Wed, Dec 23, 2009 at 3:04 PM, Simon Slavin > <slavins+hearsay.demon.co.uk>wrote: > >> On 23 Dec 2009, at 6:37pm, Robert Lipe wrote: >> >>> <mCourse> Measured Course >>> >>> Instantaneous direction of motion or facing direction as computed via a >>> non-GPS source such as a compass. This is not course as computed via >>> successive position fixes. >> Relative to what ? Due north ? Magnetic north ? > > > Does it make sense for this to be anything other than Magnetic north? I > agree we should specify. Magnetic North can vary over time, so would it make sense to have a GPX file with a value of "47 degrees West(magnetic)", when someone else might use that GPX data at another date in the future when the magnetic declination at that location is not the same as when the GPX data was recorded? -- Dave Patton CIS Canadian Information Systems Victoria, B.C. Degree Confluence Project: Canadian Coordinator Technical Coordinator http://www.confluence.org/ Personal website: Maps, GPS, etc. http://members.shaw.ca/davepatton/
robertlipe+gmail.com on Wed Dec 23 17:50:35 2009 (link), replying to msg
On Wed, Dec 23, 2009 at 7:02 PM, Dave Patton <davep+confluence.org> wrote: > On 2009/12/23 3:25 PM, Robert Lipe wrote: > > On Wed, Dec 23, 2009 at 3:04 PM, Simon Slavin > > <slavins+hearsay.demon.co.uk>wrote: > > > >> On 23 Dec 2009, at 6:37pm, Robert Lipe wrote: > >> > >>> <mCourse> Measured Course > >>> > >>> Instantaneous direction of motion or facing direction as computed via a > >>> non-GPS source such as a compass. This is not course as computed via > >>> successive position fixes. > >> Relative to what ? Due north ? Magnetic north ? > > > > > > Does it make sense for this to be anything other than Magnetic north? I > > agree we should specify. > > Magnetic North can vary over time, so would it make sense > to have a GPX file with a value of "47 degrees West(magnetic)", > when someone else might use that GPX data at another date in > the future when the magnetic declination at that location is > not the same as when the GPX data was recorded? > > -- > Dave Patton > CIS Canadian Information Systems > Victoria, B.C. > > Degree Confluence Project: > Canadian Coordinator > Technical Coordinator > http://www.confluence.org/ > > Personal website: > Maps, GPS, etc. > http://members.shaw.ca/davepatton/ > Good point and one I hadn't thought of. As a Canadian, that probably matters more to you than it does to me personally. :-) The 40km/year that it moves is noise to me in the 36'th parallel but obviously, the closer you are to the poles, the more important that becomes. (Yes, I get that declination changes everywhere over time, too.) My recommendation for it being magnetic north was because these fields were to be measured via non-GPS sources and magnetic compass such as the chips from Honeywell are the "obvious" source for this. Since the data is probably timestamped, is that enough for applications that care about such data over time to apply their own time-corrected declination tables? I don't really know. If you're an expert in such things or have access to such experts and have advice - even if that's "use true north" - this would be a great time to weigh in. That very expertise is what I'm hoping to use to make this as useful as possible. RJL [Non-text portions of this message have been removed]
krheinwald+web.de on Thu Dec 24 04:56:43 2009 (link), replying to msg
> Having Measured Course as well as Heading maybe redundant. Not at all: Heading gives the orientation of the vehicle while course is the direction of movement of the vehicle. Examples: Airplane flying with wind from its side, sailboat with wind or stream from its side, helicopter flying sideways, car driving backwards ;-)
egroups+topografix.com on Wed Dec 30 09:46:45 2009 (link), replying to msg
Hello, Wednesday, December 23, 2009, 6:18:03 PM, Robert wrote: [regarding non-handheld-GPS stuff in GPX extensions] > The feature set I picked here was very much influenced by things that have > come up on this list multiple times. Many of them we originally considered > and argued against. Dan Foster's frustration can be heard at > http://tech.groups.yahoo.com/group/gpsxml/message/2002 I don't think we > want to turn it into the kitchen sink (and I don't think Dan wants that > either) but the landscape has changed since the original work is done. We > have the benefit of looking at how people have extended GPX in real world > ways for real world problems and it seems worthwhile to try to try to roll > those things into a standardized way of spelling them. Sorry I've been late in joining this discussion - hope you had relaxing holidays. I'm encouraged that there's a new push to standardize additional, related elements into GPX extensions. Thanks to Robert for doing the difficult early work. I do hope we can avoid the mistakes of the past, where by failing to provide a common element, different vendors have gone out and done it privately, leaving us with <garmin_heartrate> and <timex_heartrate> and the like. A few thoughts: 1. We should stick to metric units (like meters/sec instead of MPH) 2. All complexType elements should end in <extensions> so they can be extended privately. (I believe <link> in GPX 1.1 needs this fix) 3. It would be helpful to have some of the HW vendors chime in that they are aware of this effort. Will Garmin eventually migrate from private extensions for common things like cadence, heartrate to a public GPX extension? Is what we're building what they need? Best wishes to you all in 2010! - Dan -- Dan Foster
azbithead+gmail.com on Wed Dec 30 13:18:19 2009 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > 3. It would be helpful to have some of the HW vendors chime in that > they are aware of this effort. Will Garmin eventually migrate from > private extensions for common things like cadence, heartrate to a > public GPX extension? Is what we're building what they need? I am the person at Garmin that will respond to this. Unfortunately, I just had surgery on Xmas eve and am now recuperating at home. I plan to be back at work starting next Monday. I was glad to see this development and look forward to working with the group to get the best result. Please bear with me until I get back to work next week when I will have further comments. Best regards, Steve Hales Garmin Software Manager Desktop Applications Group
robertlipe+gmail.com on Wed Dec 30 13:23:47 2009 (link), replying to msg
Speedy recovery. Fwiw I'm reading this on a fone on vacation .The feedback so far has been great and ill fold it in after the first. On Dec 30, 2009 4:18 PM, "azbithead" <azbithead+gmail.com> wrote: --- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > 3. It would be helpful to have so... I am the person at Garmin that will respond to this. Unfortunately, I just had surgery on Xmas eve and am now recuperating at home. I plan to be back at work starting next Monday. I was glad to see this development and look forward to working with the group to get the best result. Please bear with me until I get back to work next week when I will have further comments. Best regards, Steve Hales Garmin Software Manager Desktop Applications Group [Non-text portions of this message have been removed]
ajcartmell+fonant.com on Mon Jan 04 09:07:34 2010 (link), replying to msg
> And now the bad news: conventionally all four of these are measured 'per > minute'. Yet there's an argument to be made for keeping GPX to metric > standards. Minutes and hours are accepted as being usable with SI units :) Anthony -- www.fonant.com - Quality web sites Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex, BN11 1QR
ajcartmell+fonant.com on Mon Jan 04 09:11:45 2010 (link), replying to msg
> And now the bad news: conventionally all four of these are measured 'per > minute'. Yet there's an argument to be made for keeping GPX to metric > standards. If by "metric standards" you mean the scientific SI units system, then minutes, hours and days are acceptable as well as the base unit of time (seconds). http://www.bipm.org/en/si/si_brochure/chapter4/table6.html Presumably because we don't yet think in terms of kiloseconds... So cycles-per-minute would seem to be an acceptable SI unit of measurement of speed, as is kilometres-per-hour. HTH, Anthony -- www.fonant.com - Quality web sites Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex, BN11 1QR
robertlipe+gmail.com on Mon Jan 04 10:14:06 2010 (link), replying to msg
On Mon, Jan 4, 2010 at 7:51 AM, Simon Slavin <slavins+hearsay.demon.co.uk>wrote: > In conversation with some exercise friends of mine we came up with the > following work-out related data-types measured in units of 'cycles over > time': > > heartbeat > paces (foot hits the road) > strokes (pull of the oars when rowing) > revolutions (of the pedals when cycling) > heartrate and cadence (both wheel and crank) are already in the proposal. As this effort is kind of about "paving the cowpaths" more than spelling out anything that might be usefully associated with a timestamped position (I didn't include crankcase pressure, for example, though that might be vital to an auto performance group), pointers to existing art of the middle two would be helpful. I can imagine that paces and strokes would be useful, but is there any GPS-like substance that records it? Unlike the others, it's not something that comes to mind as requested a couple of times here. > I had another conversation about the new standard with a photography pro. > He said that there was no point in putting anything into GPX about > photography /per se/: no need for anything that already had a code in > top-level EXIM data. However, he did expect to find camera position and > orientation information in there, since this was consistent with what GPS > chipsets are good at detecting, and some way of marking which frame(s) were > taken at which track point. Whether filenames can be included in some > free-format text field, or need fieldnames of their own is, I think, a > question this list can usefully discuss. > Geotagging is an example of something that's huge now that really wasn't on my radar when we did the original. I'm sure it was out there, but it wasn't like the camera in your cell fone with GPS was ubiquitous. Input from geotagging experts is particularly welcome. I was trying to capture this with the <Orientation> tags which, admittedly, I didn't fully spell out. KML addresses this with the concept of an orientation of an object and the orientation of your view of that object, expressed as the camera. I don't *think* we want to get that ambitious with GPX; it's a concept that doesn't map very naturally to most of the programs using GPX. I suspect that associating the heading with a location ("I was facing NNW when I took this picture at these coords") is probably the most useful aspect of this. Is that enough? As for associating a filename with a {trk,rte,way}pt, I'd consider that already solved with the existing <link> tags. Is there something more to do here? RJL [Non-text portions of this message have been removed]
egroups+topografix.com on Mon Jan 04 10:42:16 2010 (link), replying to msg
Hello, Monday, January 4, 2010, 1:13:22 PM, Robert wrote: > Geotagging is an example of something that's huge now that really wasn't on > my radar when we did the original. I'm sure it was out there, but it wasn't > like the camera in your cell fone with GPS was ubiquitous. Input from > geotagging experts is particularly welcome. All of my apps read/write EXIF and IPTC geotagging info through a 3rd party library. I'm of two minds about including geotagging in a GPX extension. On the one hand, it's already in EXIF. On the other hand, inserting a few bytes (lat/lon) into each photo in a folder full of 21MB JPEG files is slow, and raises the possibility you'll mangle some unknown EXIF data section. If we did create an EXIF extension, I'd suggest that it mirror the EXIF spec as closely as possible. Same for IPTC. <link> does need some changes. It doesn't allow Windows relative file paths. I've been encoding everything as URLs, but if others are suggesting that we add more ways to link to external files, we should be explicit about how relative paths should be handled in GPX and zipped GPX files. This is how I'm currently encoding geotagged photos. All the camera info and keyword tags are stored in EXIF in the .jpg file. <image xmlns="http://www.topografix.com/GPX/gpx_overlay/0/3" lat="42.50813436" lon="-71.60196283"> <link xmlns="http://www.topografix.com/GPX/1/1" href="./Prospect%20Hill%20Originals/Mar%201/IMG_9922.JPG"> <text>Turkey tracks</text> <type>image/jpeg</type> </link> </image> -- Dan Foster
robertlipe+gmail.com on Mon Jan 04 10:54:01 2010 (link), replying to msg
On Mon, Jan 4, 2010 at 12:41 PM, Dan Foster <egroups+topografix.com> wrote: > <link> does need some changes. It doesn't allow Windows relative file > paths. I've been encoding everything as URLs, but if others are > It seems like it should once you get past the obvoius limitations that if you have a <link> to c:\my stuff\foo.jpg and send it to me, it's pretty useless. KML addressed with with the KMZ format that allowed you to "smuggle" image data in a zip file so you could bundle your icons or images or whatever with the XML that described them. > suggesting that we add more ways to link to external files, we should > be explicit about how relative paths should be handled in GPX and > zipped GPX files. > It's worth mentioning that during the process of formalizing KML for the OGC, there was a surprisingly large effort required to try to nail corner cases with relative paths and associated files. It's harder to do well than it sounds. > > > This is how I'm currently encoding geotagged photos. All the camera > info and keyword tags are stored in EXIF in the .jpg file. > > <image xmlns="http://www.topografix.com/GPX/gpx_overlay/0/3" > lat="42.50813436" lon="-71.60196283"> > <link xmlns="http://www.topografix.com/GPX/1/1" > href="./Prospect%20Hill%20Originals/Mar%201/IMG_9922.JPG"> > <text>Turkey tracks</text> > <type>image/jpeg</type> > </link> > </image> > Beyond adding "type", how is <image> different than, say, "wpt"? RJL [Non-text portions of this message have been removed]
dananderson2+yahoo.com on Mon Jan 04 18:16:45 2010 (link), replying to msg
--- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > In conversation with some exercise friends of mine we came up with the following work-out related data-types measured in units of 'cycles over time': > > heartbeat > paces (foot hits the road) > strokes (pull of the oars when rowing) > revolutions (of the pedals when cycling) > > We tried discussing it without looking anything up and it was not clear to us whether 'paces' meant one footfall or two (i.e. left foot to left foot, or left, right, left, right). All the others were for the obvious full cycle. In a standard, I would define paces in terms of one footfall. Dan Anderson
dananderson2+yahoo.com on Mon Jan 04 18:33:16 2010 (link), replying to msg
--- In gpsxml+yahoogroups.com, Dan Foster <egroups+...> wrote: > All of my apps read/write EXIF and IPTC geotagging info through a 3rd party > library. I'm of two minds about including geotagging in a GPX > extension. On the one hand, it's already in EXIF. On the other hand, > inserting a few bytes (lat/lon) into each photo in a folder full of > 21MB JPEG files is slow, and raises the possibility you'll mangle some > unknown EXIF data section. > > If we did create an EXIF extension, I'd suggest that it mirror the > EXIF spec as closely as possible. Same for IPTC. My initial reaction was to include just the basic location and direction (3D) information. Since it's easy with some graphic programs to lose the EXIF information (don't go into the file save options and set the "save EXIF information" bit), I think there's an argument to mirror the EXIF as Dan F. suggests. The redundancy of data could help keep it from being lost. I can also see intentionally deleting the EXIF data from the pictures and only maintaining it in the GPX file. Of course, separating the data from the object it goes with is a good way to get the data scrambled or lost. -- Dan Anderson
ptomblin+gmail.com on Tue Jan 05 05:51:50 2010 (link), replying to msg
On Mon, Jan 4, 2010 at 9:16 PM, dananderson2 <dananderson2+yahoo.com> wrote: > In a standard, I would define paces in terms of one footfall. In Orienteering, we used "pace" equal to the distance between two left foot falls. This is the same as the Roman legions (thus "mile" == "mille paceum"(probably spelt wrong) == "1000 paces"). -- http://www.linkedin.com/in/paultomblin http://careers.stackoverflow.com/ptomblin
dananderson2+yahoo.com on Tue Jan 05 08:14:12 2010 (link), replying to msg
--- In gpsxml+yahoogroups.com, Paul Tomblin <ptomblin+...> wrote: > > On Mon, Jan 4, 2010 at 9:16 PM, dananderson2 <dananderson2+...> wrote: > > In a standard, I would define paces in terms of one footfall. > > In Orienteering, we used "pace" equal to the distance between two left > foot falls. This is the same as the Roman legions (thus "mile" == > "mille paceum"(probably spelt wrong) == "1000 paces"). > Webster's definition of "pace": 1 a step in walking, running, etc.; stride 2 a unit of linear measure, equal to the length of a step or stride, variously estimated at from 30 in. to 40 in. the regulation military pace is 30 in., or 36 in. for double time: the Roman pace, measured from the heel of one foot to the heel of the same foot in the next stride, was 5 Roman ft., or 58.1 in., now known as a geometric pace, about 5 ft. 3 a) the rate of speed in walking, running, etc. b) Sports the speed of a ball, shuttlecock, etc. So apparently you use "geometric pace" in orienteering. As I recall, the mechanical pedometer I had a couple of decades ago counted the number of steps. So you set the length of your stride in inches while hiking to get the length of your hike in miles. I think "60 steps per minute" is more convenient and less confusing than "30 double steps per minute."
azbithead+gmail.com on Tue Jan 05 14:17:38 2010 (link), replying to msg
I apologize to the group for being somewhat slow to respond on this subject. In my defense, as a representative of a corporation, I feel compelled to be very careful about what I say here. In that same vein, I want to point out that I don't believe that the opinions that I express here should carry any more weight than anyone else. First, I would like to offer two existing schemas that we developed as a partial solution to the issues that Robert and this group are trying to address. The schemas can be found at http://www.garmin.com/xmlschemas/WaypointExtensionv1.xsd and http://www.garmin.com/xmlschemas/TrackPointExtensionv1.xsd. I am not claiming that these schemas are superior to Robert's proposal. However, they do already exist, are actively being used by many of our products and were designed expressly to extend GPX. Garmin offers these schemas for anyone to use with no license fees. They include many, but not all, of the fields that Robert has proposed. If it is agreed that these schemas are adequate, an additional schema would still be needed that includes the other fields (such as mSpeed and Orientation). Regarding the proposed fields not included in the above schemas, I only had a question about the guid field. Should that field be more tightly specified? In particular, should we try to specify that the field's content should follow the string representation in RFC 4122 at http://www.ietf.org/rfc/rfc4122.txt? Finally, I strongly recommend that any new schemas that come out of this effort should be fully self-documented through the liberal use of xsd:documentation and xsd:annotation tags. Nearly every element should include these tags. Doing so makes it possible to automatically generate very useful Web pages to document the schema. We at Garmin have not consistently done this for our schemas and I regret that very much. Best regards, Steve Hales Garmin Software Manager Desktop Applications Group
azbithead+gmail.com on Tue Jan 12 09:54:13 2010 (link), replying to msg
Sound of crickets chirping... It has gotten very quiet in here. Did I offend everyone with my last post or has everyone simultaneously gone on vacation? - Steve
robertlipe+gmail.com on Tue Jan 12 10:02:22 2010 (link), replying to msg
On Tue, Jan 12, 2010 at 11:54 AM, azbithead <azbithead+gmail.com> wrote: > > > Sound of crickets chirping... > > It has gotten very quiet in here. Did I offend everyone with my last post > or has everyone simultaneously gone on vacation? > Can't speak for the others. I pretty much agreed with your points and appreciated the offer to let us borrow liberally from the related Garmin extensions. I have a pile of input and my next step is to integrate that into a new draft. The ball is in my court and I hope to get a new draft out soon. Thanx to all that have commented. RJL > - Steve > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
robertlipe+gmail.com on Tue Jan 12 11:41:52 2010 (link), replying to msg
On Tue, Jan 12, 2010 at 12:33 PM, Simon Slavin <slavins+hearsay.demon.co.uk>wrote: > > On 12 Jan 2010, at 6:02pm, Robert Lipe wrote: > > > The ball is in my court and I hope to get a new draft out soon. > > Just before you get around to it, I have a question: > > Why is this GPX 1.1 extensions and not GPX 2 ? > I won't entrench on one side or the other, but 1.1 extensions feels more right here to me. We're not changing it in an incompatible way as we did with 1.1; we're extending it. There is a bit of a double-bump here if we decide to roll these into a GPX 2.0 (1.2?), though. While it's tempting to give something like this some air time from a few real-world implementations, it does means that apps may have to parse both. If we producers and consumers of GPX agree we'd rather rip at band-aids instead of tugging at them, I could recast this as GPX 1.2 or 2.0. I suspect that most of what we're addressing is important to a small corner of the GPX market and that valuing compatibility over XML cleanliness might be our best long-term win. RJL > Simon. > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
azbithead+gmail.com on Tue Jan 12 12:20:27 2010 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > I have a pile of input and my next step is to integrate that into a new > draft. I want to clarify my intent in my earlier post: I was offering our existing schemas to be used as is, as opposed to extracting portions from them and putting those in a new schema. However, if the group would rather do that, I am not opposed to it. - Steve
azbithead+gmail.com on Tue Jan 12 12:28:23 2010 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > I won't entrench on one side or the other, but 1.1 extensions feels more > right here to me. We're not changing it in an incompatible way as we did > with 1.1; we're extending it. > > There is a bit of a double-bump here if we decide to roll these into a GPX > 2.0 (1.2?), though. We could do both, i.e. create an extension schema for 1.1 and a new 1.2 or 2.0 main schema that directly incorporates the elements from the extension. Obviously that would be more work. Are there are benefits to doing so? - Steve
robertlipe+gmail.com on Tue Jan 12 13:13:23 2010 (link), replying to msg
On Tue, Jan 12, 2010 at 2:16 PM, azbithead <azbithead+gmail.com> wrote: > --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > I have a pile of input and my next step is to integrate that into a new > > draft. > > I want to clarify my intent in my earlier post: I was offering our existing > schemas to be used as is, as opposed to extracting portions from them and > putting those in a new schema. However, if the group would rather do that, I > am not opposed to it. > There's a large overlap, for sure. I didn't start with the Garmin extensions as they weren't on the table at the time (and thanx for offering them) because they didn't cover everything we wanted and extending extensions just seemed weird. Additionally, there are some fields that are apparently thing like hardware registers or such that are totally incomprehensible to other programs. (I don't see it in the schema now, but I remember seeing huge hex numbers in there that were definitely against the spirit of GPX.) On the 1.1 vs. 2.0 thing, I place a lot of value on your vote. You obviously have zillions of devices in the field now that read and write 1.1 successfully. While enthusiasts routinely upgrade firmware, many users will not. If Easy/ExpertGPS, GPSBabel (both represented in this list) or other software started throwing GPX 1.2 or 2.0 with new tags around, how much carnage would there be? I could also understand you ignoring it all as you already have this problem solved between your hardware and your software. (Please don't read this as me putting words into Garmin's mouth.) You might be looking at twice the work in figuring out whether to stay with your own or use a "GPX-blessed" scheme, too. Multiply that times the number of devices you have times the number of software programs you have that do GPX and I get that this whole discussion could easily get awkward for you. [Non-text portions of this message have been removed]
azbithead+gmail.com on Tue Jan 12 14:39:48 2010 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > There's a large overlap, for sure. I didn't start with the Garmin > extensions as they weren't on the table at the time (and thanx for offering > them) because they didn't cover everything we wanted and extending > extensions just seemed weird. Additionally, there are some fields that are > apparently thing like hardware registers or such that are totally > incomprehensible to other programs. (I don't see it in the schema now, but > I remember seeing huge hex numbers in there that were definitely against the > spirit of GPX.) The schemas I offered are our newest extension schemas and they don't have the Garmin-proprietary hex stuff you are remembering. > On the 1.1 vs. 2.0 thing, I place a lot of value on your vote. You > obviously have zillions of devices in the field now that read and write 1.1 > successfully. While enthusiasts routinely upgrade firmware, many users will > not. If Easy/ExpertGPS, GPSBabel (both represented in this list) or other > software started throwing GPX 1.2 or 2.0 with new tags around, how much > carnage would there be? > > I could also understand you ignoring it all as you already have this problem > solved between your hardware and your software. (Please don't read this as > me putting words into Garmin's mouth.) You might be looking at twice the > work in figuring out whether to stay with your own or use a "GPX-blessed" > scheme, too. Multiply that times the number of devices you have times the > number of software programs you have that do GPX and I get that this whole > discussion could easily get awkward for you. Every developer (including Garmin) has to weigh the benefits of supporting a new schema vs. the development costs of doing so. It is unlikely that we will update any currently shipping hardware to support a new schema (including our own new schemas!). We have so many products that it is prohibitive to do that. That is one reason why I proposed using our existing schemas. That is obviously very self-serving in that it doesn't help other developers who are not currently supporting our schemas. I honestly can't predict how quickly or even if we will support any new schemas developed by this group. There are many product development groups within Garmin and each group will independently weigh the pros and cons for supporting a schema in their product. That said, we do share code within Garmin and once a group has implemented support for a schema it becomes more likely that others will also. Perhaps that was my long-winded way of saying that less change is better. ;-) - Steve
larry_godin+yahoo.com on Wed Feb 10 06:00:11 2010 (link)
Hi all, I have some questions about waypoints. 1) In the GPX documentation I read that the <type> tag (an xsd:string) is the used for the "classification of the waypoint." But are there some standard types? I need to create a file that is compatible with most existing softwares (mainly Google Earth)... 2) Same question for the <sym> tag (an xsd:string). It is the "Text of GPS symbol name." But are there some standard symbol names? Google Earth recognize it? 3) I need to add some photos to some waypoints. What is the standard method? Can I use the <link> tag? But if I use it, Google Earth recognize it? Thank you very much. - Larry
robertlipe+gmail.com on Wed Feb 10 06:13:56 2010 (link), replying to msg
On Wed, Feb 10, 2010 at 6:44 AM, larry_godin <larry_godin+yahoo.com> wrote: > Hi all, > > I have some questions about waypoints. > > 1) In the GPX documentation I read that the <type> tag (an xsd:string) is > the used for the "classification of the waypoint." But are there some > standard types? I need to create a file that is compatible with most > existing softwares (mainly Google Earth)... > > 2) Same question for the <sym> tag (an xsd:string). It is the "Text of GPS > symbol name." But are there some standard symbol names? Google Earth > recognize it? > > 3) I need to add some photos to some waypoints. What is the standard > method? Can I use the <link> tag? But if I use it, Google Earth recognize > it? > I could answer in the abstract, but since your questions seem to pivot around Google Earth and I'm the author of Earth's GPX reader, I'll do specifics. 1) <type> is not used. 2) <sym> becomes an IconStyle in KML iff it looks like an URL, either file or web-based. 3) <link> will get brought in as clickable links inside the balloon. That's probably not as robust for geotagging as you'd want. If you're looking to deliver a robust multimedia experience and Earth is your primary target, GPX is probably a distraction. KML is also an open standard and reasonably easy to create. GPX really is about exchanging GPS-style data. That definition has evolved a bit over time, but if you're really wanting to have control over the artwork associated with a mark, camera angles, pictures, sounds, and movies, etc. and your primary target is Earth, I'd just go straight to KML. Google Earth reads GPX by using the open source GPSBabel to convert to KML. [Non-text portions of this message have been removed]
larry_godin+yahoo.com on Wed Feb 10 07:25:47 2010 (link), replying to msg
> I could answer in the abstract, but since your questions seem to > pivot around Google Earth and I'm the author of Earth's GPX > reader, I'll do specifics. > > 1) <type> is not used. > 2) <sym> becomes an IconStyle in KML iff it looks like an URL, either file > or web-based. > 3) <link> will get brought in as clickable links inside the balloon. > That's probably not as robust for geotagging as you'd want. > > If you're looking to deliver a robust multimedia experience > and Earth is your primary target, GPX is probably a distraction. > KML is also an open standard and reasonably easy to create. > GPX really is about exchanging GPS-style data. That definition > has evolved a bit over time, but if you're really wanting to > have control over the artwork associated with a mark, > camera angles, pictures, sounds, and movies, etc. and your primary > target is Earth, I'd just go straight to KML. > > Google Earth reads GPX by using the open source GPSBabel to > convert to KML. Dear Robert, thank you for your answer: it was a great help for me. In my project I cannot use KML, but only GPX, so I wrote to this group. However, I want to be sure that the exported files were readable by all users, even those less interested in GPS, and everyone has on their computer Google Earth :-) I tried what you told me you about the <sym> and <link> tags in Google Earth: they have worked perfectly, but only with remote URL, not filesystem paths. Instead, in my project the waypoint's photos are on the filesystem... Are there solutions? Said so, if you want to give me the "more abstract answers" I would be very happy, because I prefer to be GPX-compliant. Thank you very much! - Larry
robertlipe+gmail.com on Wed Feb 10 07:35:22 2010 (link), replying to msg
On Wed, Feb 10, 2010 at 9:18 AM, larry_godin <larry_godin+yahoo.com> wrote: > > In my project I cannot use KML, but only GPX, so I wrote to this group. > However, I want to be sure that the exported files were readable by all > users, even those less interested in GPS, and everyone has on their computer > Google Earth :-) > That's fine. It's just that over and over, you asked about Earth specifically. I tried what you told me you about the <sym> and <link> tags in Google > Earth: they have worked perfectly, but only with remote URL, not filesystem > paths. Instead, in my project the waypoint's photos are on the filesystem... > Are there solutions? > All urls should work. file://path/to/my/pic.jpg should work. Of course, distributing a gpx with references to your home directory isn't exactly going to to work very well for others. The more abstract answer to most of your questions is "it depends". In general, readers have a great latitude how they interpret fields and writers are encouraged to be conservative in what they put in the fields. The <sym> field is a pretty good example. <sym>Residence</sym> and <sym>House</sym> are both valid. If you're round-tripping from host software to one GPS, you'll probably only see one of those. If you're sending from a Garmin (which has one) to a Magellan (which has the other) you may be in for a bumpy ride. Earth, as an internet-connected entity, has a great deal of latitude on what it can display as an icon, so a URL to an image makes great sense there. But a URL makes no sense at all if you're sending that to a Garmin GPS 12 and getting software to figure out "that's a PNG of a house, I'll use the icon number for 'Residence'" remains a pipe dream. [Non-text portions of this message have been removed]
robertlipe+gmail.com on Wed Feb 10 10:35:00 2010 (link), replying to msg
On Wed, Feb 10, 2010 at 8:34 AM, Simon Slavin <slavins+hearsay.demon.co.uk>wrote: > > 2) Same question for the <sym> tag (an xsd:string). It is the "Text of > GPS symbol name." But are there some standard symbol names? Google Earth > recognize it? > > Here are two versions of an old standard from old Garmin models: > > http://www.gpsbabel.org/htmldoc-1.3.0/GarminIcons.html > http://www.gpsbabel.org/htmldoc-1.3.6/GarminIcons.html is newer and more representative of newer Garmins. http://www.gpsbabel.org/htmldoc-development/GarminIcons.html always points to the latest. (Yeah, the pages should link to other versions...) > http://home.online.no/~sigurdhu/12MAP_symbols.htm<http://home.online.no/%7Esigurdhu/12MAP_symbols.htm> > > There is no real standard, but many devices will understand a superset of > the text values seen on those pages. > Right. As some perspective how icky this situation is, I don't think there's a single Garmin device that handle every icon on that page. RJL [Non-text portions of this message have been removed]
chrabers+yahoo.de on Tue Mar 02 11:00:46 2010 (link)
Does anybody know whether there is a XSLT stylesheet freely available for transforming gpx 1.0 files into gpx 1.1 files? Christian
robertlipe+gmail.com on Tue Mar 02 11:10:47 2010 (link), replying to msg
On Tue, Mar 2, 2010 at 7:54 AM, chrabers <chrabers+yahoo.de> wrote: > Does anybody know whether there is a XSLT stylesheet freely available for > transforming gpx 1.0 files into gpx 1.1 files > Not a direct answer, but if the GPX 1.0 files don't use extensions, GPSBabel can rewrite them, recasting things like the tweaked spellings of URLs and such. If there are extensions in play, things are more complicated as you may have to change the extensions themselves. I'll venture that an automated tool for arbitrary extension is a difficult task. RJL [Non-text portions of this message have been removed]
ldeffenb+homeside.to on Tue Mar 02 12:27:17 2010 (link), replying to msg
I browsed through a few web sites, but does anyone know if there's a short list of the differences between 1.0 and 1.1 around anywhere? Lynn (D) - KJ4ERJ - Working on an Amateur Radio tracking program (APRSISCE, see the Yahoo Group) Robert Lipe wrote: > On Tue, Mar 2, 2010 at 7:54 AM, chrabers <chrabers+yahoo.de> wrote: > > >> Does anybody know whether there is a XSLT stylesheet freely available for >> transforming gpx 1.0 files into gpx 1.1 files >> >> > > Not a direct answer, but if the GPX 1.0 files don't use extensions, GPSBabel > can rewrite them, recasting things like the tweaked spellings of URLs and > such. > > If there are extensions in play, things are more complicated as you may > have to change the extensions themselves. I'll venture that an automated > tool for arbitrary extension is a difficult task. > > RJL > > > [Non-text portions of this message have been removed] > > > > ------------------------------------ > > Yahoo! Groups Links > > > > >
robertlipe+gmail.com on Tue Mar 02 12:34:20 2010 (link), replying to msg
On Tue, Mar 2, 2010 at 11:58 AM, Lynn W. Deffenbaugh (Mr) < ldeffenb+homeside.to> wrote: > I browsed through a few web sites, but does anyone know if there's a > short list of the differences between 1.0 and 1.1 around anywhere? > I don't think we published one in the group here. The authoratitive answer would be to compare the XSDs as they're the official word on what comprises each. > Lynn (D) - KJ4ERJ - Working on an Amateur Radio tracking program > (APRSISCE, see the Yahoo Group) > > Robert Lipe wrote: > > On Tue, Mar 2, 2010 at 7:54 AM, chrabers <chrabers+yahoo.de> wrote: > > > > > >> Does anybody know whether there is a XSLT stylesheet freely available > for > >> transforming gpx 1.0 files into gpx 1.1 files > >> > >> > > > > Not a direct answer, but if the GPX 1.0 files don't use extensions, > GPSBabel > > can rewrite them, recasting things like the tweaked spellings of URLs and > > such. > > > > If there are extensions in play, things are more complicated as you may > > have to change the extensions themselves. I'll venture that an > automated > > tool for arbitrary extension is a difficult task. > > > > RJL > > > > > > [Non-text portions of this message have been removed] > > > > > > > > ------------------------------------ > > > > Yahoo! Groups Links > > > > > > > > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
chrabers+yahoo.de on Tue Mar 02 19:27:29 2010 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > Not a direct answer, but if the GPX 1.0 files don't use extensions, GPSBabel > can rewrite them, recasting things like the tweaked spellings of URLs and > such. > > If there are extensions in play, things are more complicated as you may > have to change the extensions themselves. There are no extensions in my files but GPSBabel has more problems transforming gpx 1.0 to 1.1. Here is an example: <?xml version="1.0" encoding="iso-8859-1"?> <gpx version="1.0" creator="www.tourfinder.net" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <url>http://www.tourfinder.net/do/tour?action=show&part=overview&\ ;id=1172&categoryId=1</url> <urlname>Tour: Biotopo Marocce di Dro</urlname> will be transformed to this: <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.1" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd"> <metadata> <url>http://www.tourfinder.net/do/tour?action=show&part=overview&id=1172\ &categoryId=1</url> <urlname>Tour: Biotopo Marocce di Dro </urlname> 1) the schema location is that of 1.0 so that there is a mixup between 1.0 and 1.1 2) <url> and <urlname> are not transformed to <link> 3) & is transformed to & The result is a nonvalid gpx file. So GPSBabel is no solution. I also tryed Tourateq QV. It reads 1.0 files and writes valid 1.1 files but it does not transform <url> to <link> but deletes <url> and <urlname>. Any other idea? Christian [Non-text portions of this message have been removed]
robertlipe+gmail.com on Tue Mar 02 22:09:05 2010 (link), replying to msg
On Tue, Mar 2, 2010 at 2:19 PM, chrabers <chrabers+yahoo.de> wrote: > > --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > Not a direct answer, but if the GPX 1.0 files don't use extensions, > GPSBabel > > can rewrite them, recasting things like the tweaked spellings of URLs > and > > such. > > > > If there are extensions in play, things are more complicated as you > may > > have to change the extensions themselves. > > There are no extensions in my files but GPSBabel has more problems > transforming gpx 1.0 to 1.1. Here is an example: > Actually, that's part of an example, not a reproducible test case. > > <?xml version="1.0" encoding="iso-8859-1"?> > <gpx version="1.0" creator="www.tourfinder.net" > 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 > http://www.topografix.com/GPX/1/0/gpx.xsd"> > > <url>http://www.tourfinder.net/do/tour?action=show&part=overview&\ > ;id=1172&categoryId=1</url> > <urlname>Tour: Biotopo Marocce di Dro</urlname> > > will be transformed to this: > > <?xml version="1.0" encoding="UTF-8"?> > <gpx > version="1.1" > creator="GPSBabel - http://www.gpsbabel.org" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="http://www.topografix.com/GPX/1/1" > xsi:schemaLocation="http://www.topografix.com/GPX/1/0 > http://www.topografix.com/GPX/1/0/gpx.xsd"> > <metadata> > <url>http://www.tourfinder.net/do/tour?action=show&part=overview&id=1172\ > &categoryId=1</url> > <urlname>Tour: Biotopo Marocce di Dro </urlname> > > 1) the schema location is that of 1.0 so that there is a mixup between > 1.0 and 1.1 > 2) <url> and <urlname> are not transformed to <link> > 3) & is transformed to & > The result is a nonvalid gpx file. > > So GPSBabel is no solution. > #1 is indeed a bug that we introduced when trying to preserve headers. I don't see either #2 or #3. If you're interested in pursuing that, the gpsbabel mailing list is probably the place for that. $ cat blah10.gpx <?xml version="1.0" encoding="UTF-8"?> <gpx> <time>2010-03-03T03:06:31Z</time> <bounds minlat="35.972033333" minlon="-87.134700000" maxlat="36.112183333" maxlon="-86.620116667"/> <wpt lat="35.972033333" lon="-87.134700000"> <ele>0.000000</ele> <name>GCEBB</name> <cmt>Mountain Bike Heaven by susy1313</cmt> <desc>Mountain Bike Heaven by susy1313</desc> <url> http://www.tourfinder.net/do/tour?action=show&part=overview&id=1172&categoryId=1 </url> <urlname>Cache Details</urlname> <sym>geocache</sym> </wpt> </gpx> dhcp-172-19-0-174:gpsbabel robertlipe$ ./gpsbabel -i gpx -f blah10.gpx -o gpx,gpxver=1.1 -F - <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.1" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd"> <metadata> <time>2010-03-03T03:31:06Z</time> <bounds minlat="35.972033333" minlon="-87.134700000" maxlat="35.972033333" maxlon="-87.134700000"/> </metadata> <wpt lat="35.972033333" lon="-87.134700000"> <ele>0.000000</ele> <name>GCEBB</name> <cmt>Mountain Bike Heaven by susy1313</cmt> <desc>Mountain Bike Heaven by susy1313</desc> <link href=" http://www.tourfinder.net/do/tour?action=show&part=overview&id=1172&categoryId=1 "> <text>Cache Details</text> </link> <sym>geocache</sym> </wpt> </gpx> [Non-text portions of this message have been removed]
chrabers+yahoo.de on Wed Mar 03 14:40:21 2010 (link), replying to msg
> Actually, that's part of an example, not a reproducible test case. For getting the 3 bugs with GPSBabel 1.3.6 and 1.3.7-beta20100215 (WinXP) I used the following input: <?xml version="1.0" encoding="iso-8859-1"?> <gpx version="1.0" creator="www.tourfinder.net" 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 http://www.topografix.com/GPX/1/0/gpx.xsd"> <url>http://www.tourfinder.net/do/tour?action=show&part=overview&id=1172&categoryId=1</url> <urlname>Tour: Biotopo Marocce di Dro</urlname> <bounds minlat="45.919353" minlon="10.885391" maxlat="46.018574" maxlon="10.961266"/> <trk> <trkseg> <trkpt lat="45.924503" lon="10.896528"> <ele>290.0</ele> </trkpt> <trkpt lat="45.924503" lon="10.897515"> <ele>144.0</ele> </trkpt> </trkseg> </trk> </gpx> GPSBabelGUI for 1.3.6 produced the following command line: gpsbabel.exe -p "" -w -t -i gpx -f "C:\test\gpx-test-1.0.gpx" -o gpx,gpxver=1.1 -F "C:\test\gpx-test-1.1-by-1.3.6.gpx" and the GUI for the beta showed the following command: gpsbabel -w -r -t -i gpx -f C:/test/gpx-test-1.0.gpx -o gpx,gpxver=1.1 -F C:/test/gpx-test-1.1.gpx The result is exactly the same for both program versions - ignoring the generated timestamp: <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.1" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd"> <metadata> <url>http://www.tourfinder.net/do/tour?action=show&part=overview&id=1172&categoryId=1</url> <urlname>Tour: Biotopo Marocce di Dro </urlname> <time>2010-03-03T22:00:09Z</time> <bounds minlat="45.924503000" minlon="10.896528000" maxlat="45.924503000" maxlon="10.897515000"/> </metadata> <trk> <trkseg> <trkpt lat="45.924503000" lon="10.896528000"> <ele>290.000000</ele> </trkpt> <trkpt lat="45.924503000" lon="10.897515000"> <ele>144.000000</ele> </trkpt> </trkseg> </trk> </gpx>
robertlipe+gmail.com on Thu Mar 04 10:28:03 2010 (link), replying to msg
Ah, it's the top level metadata <url> that's getting mangled and not the one that's in wpt/trk/rte. That's why I wasn't seeing it. Thanx for the test case. On Wed, Mar 3, 2010 at 2:23 PM, chrabers <chrabers+yahoo.de> wrote: > > Actually, that's part of an example, not a reproducible test case. > > For getting the 3 bugs with GPSBabel 1.3.6 and 1.3.7-beta20100215 (WinXP) I > used the following input: > <?xml version="1.0" encoding="iso-8859-1"?> > <gpx version="1.0" creator="www.tourfinder.net" > 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 > http://www.topografix.com/GPX/1/0/gpx.xsd"> > <url> > http://www.tourfinder.net/do/tour?action=show&part=overview&id=1172&categoryId=1 > </url> > <urlname>Tour: Biotopo Marocce di Dro</urlname> > <bounds minlat="45.919353" minlon="10.885391" maxlat="46.018574" > maxlon="10.961266"/> > <trk> > <trkseg> > <trkpt lat="45.924503" lon="10.896528"> > <ele>290.0</ele> > </trkpt> > <trkpt lat="45.924503" lon="10.897515"> > <ele>144.0</ele> > </trkpt> > </trkseg> > </trk> > </gpx> > > GPSBabelGUI for 1.3.6 produced the following command line: > gpsbabel.exe -p "" -w -t -i gpx -f "C:\test\gpx-test-1.0.gpx" -o > gpx,gpxver=1.1 -F "C:\test\gpx-test-1.1-by-1.3.6.gpx" > > and the GUI for the beta showed the following command: > gpsbabel -w -r -t -i gpx -f C:/test/gpx-test-1.0.gpx -o gpx,gpxver=1.1 -F > C:/test/gpx-test-1.1.gpx > > The result is exactly the same for both program versions - ignoring the > generated timestamp: > <?xml version="1.0" encoding="UTF-8"?> > <gpx > version="1.1" > creator="GPSBabel - http://www.gpsbabel.org" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="http://www.topografix.com/GPX/1/1" > xsi:schemaLocation="http://www.topografix.com/GPX/1/0 > http://www.topografix.com/GPX/1/0/gpx.xsd"> > <metadata> > <url> > http://www.tourfinder.net/do/tour?action=show&part=overview&id=1172&categoryId=1 > </url> > <urlname>Tour: Biotopo Marocce di Dro </urlname> > <time>2010-03-03T22:00:09Z</time> > <bounds minlat="45.924503000" minlon="10.896528000" maxlat="45.924503000" > maxlon="10.897515000"/> > </metadata> > <trk> > <trkseg> > <trkpt lat="45.924503000" lon="10.896528000"> > <ele>290.000000</ele> > </trkpt> > <trkpt lat="45.924503000" lon="10.897515000"> > <ele>144.000000</ele> > </trkpt> > </trkseg> > </trk> > </gpx> > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
chris.ahrweiler+yahoo.de on Mon Mar 29 15:20:29 2010 (link)
GPXel is a new web tool to visualize navigation files such as GPX and TCX files. Upload your own file and get a one page summary of data including distance, altitude and slope. Topographic data will be retrieved automatically, if necessary. In addition the route/track will be shown on a map, accompanied by the elevation and slope profile. http://www.gpxel.com/index.php
fly+pifko.com on Tue Apr 20 16:50:46 2010 (link)
Hi guys, I hope you can help out here. We're stuck on one issue and could use the experience of people with more history in pushing around navigation data. We are exporting a route from a GPX and are trying to have it display with the driving directions/route correctly overlaid on Google Maps. Question: can we use a gpx file as input into Google Maps to show a driving route given several intermediate points? How? More fully: If I just call Google Maps with several route points, it displays the map correctly. http://maps.google.com/maps?saddr=34.210214,-118.200274&daddr=34.373063,-117.752172%20to:34.365936,-117.652859 (We've exported those coordinates from a gpx file). But when I try to construct a KML file and have Google Maps point at the KML file (e.g. http://maps.google.com/maps?q=http://myserver.com/blahblah.kml), the route shows up as a straight line between waypoints. I want the route to follow the road. What are we doing wrong? The path ends up looking like http://greatestroad.com/images/straightlines.jpg . The current kml file looks like this: <kml> <Document> <name>Paths</name> <description/> <Placemark> <name>Rosedale Valley Rd. to ice cream</name> <description>The long way...</description> <styleUrl>#roadStyle</styleUrl> <LineString> <extrude>1</extrude> <tessellate>1</tessellate> <altitudeMode>absolute</altitudeMode> <coordinates> -79.388924,43.675508,0 -79.388924,43.675508,0 -79.359655,43.670045,0 -79.359655,43.670045,0 -79.367809,43.67886,0 -79.367809,43.67886,0 -79.362831,43.682708,0 -79.362831,43.682708,0 -79.339845,43.695714,0 -79.339845,43.695714,0 -79.335547,43.700161,0 -79.335547,43.700161,0 -79.356973,43.683819,0 -79.356973,43.683819,0 </coordinates> </LineString> </Placemark> </Document> </kml> Thanks for your help, Daniel Pifko Greatest Road Software
clement.fouque+free.fr on Wed Apr 21 07:38:24 2010 (link), replying to msg
Hi, I'm not really used to kml files, but your path is declared as a multi-point line built from your waypoints. I think this is the core of your problem. Maybe you should use another kml data type to export your waypoints. But wich one, i can't tell. Daniel a ?it : > > > Hi guys, > > I hope you can help out here. We're stuck on one issue and could use the > experience of people with more history in pushing around navigation data. > > We are exporting a route from a GPX and are trying to have > it display with the driving directions/route correctly overlaid on > Google Maps. > > Question: can we use a gpx file as input into Google Maps to show a > driving route given several intermediate points? How? > > More fully: > > If I just call Google Maps with several route points, it displays the > map correctly. > > http://maps.google.com/maps?saddr=34.210214,-118.200274&daddr=34.373063,-117.752172%20to:34.365936,-117.652859 > <http://maps.google.com/maps?saddr=34.210214,-118.200274&daddr=34.373063,-117.752172%20to:34.365936,-117.652859> > > (We've exported those coordinates from a gpx file). > > But when I try to construct a KML file and have Google Maps point at > the KML file (e.g. > http://maps.google.com/maps?q=http://myserver.com/blahblah.kml > <http://maps.google.com/maps?q=http://myserver.com/blahblah.kml>), the > route shows up as a straight line between > waypoints. I want the route to follow the road. > > What are we doing wrong? > > The path ends up looking like > http://greatestroad.com/images/straightlines.jpg > <http://greatestroad.com/images/straightlines.jpg> > . The current kml file looks like this: > > <kml> > <Document> > <name>Paths</name> > <description/> > <Placemark> > <name>Rosedale Valley Rd. to ice cream</name> > <description>The long way...</description> > <styleUrl>#roadStyle</styleUrl> > <LineString> > <extrude>1</extrude> > <tessellate>1</tessellate> > <altitudeMode>absolute</altitudeMode> > <coordinates> > -79.388924,43.675508,0 > -79.388924,43.675508,0 > -79.359655,43.670045,0 > -79.359655,43.670045,0 > -79.367809,43.67886,0 > -79.367809,43.67886,0 > -79.362831,43.682708,0 > -79.362831,43.682708,0 > -79.339845,43.695714,0 > -79.339845,43.695714,0 > -79.335547,43.700161,0 > -79.335547,43.700161,0 > -79.356973,43.683819,0 > -79.356973,43.683819,0 > </coordinates> > </LineString> > </Placemark> > </Document> > </kml> > > Thanks for your help, > > Daniel Pifko > Greatest Road Software > >
tanelilaine+yahoo.com on Fri Apr 23 06:32:34 2010 (link)
I can't find <speed> in GPX1.1 schema but in the 1.0 manual it is listed. Does this mean that I should not use it if I develop an application that exports gpx files?
robertlipe+gmail.com on Fri Apr 23 09:21:15 2010 (link), replying to msg
On Fri, Apr 23, 2010 at 12:26 AM, tanelilaine <tanelilaine+yahoo.com> wrote: > I can't find <speed> in GPX1.1 schema but in the 1.0 manual it is listed. > Does this mean that I should not use it if I develop an application that > exports gpx files? > Speed was present in GPX 1.0 and was unintentionally omitted from 1.1. Since in most cases, speed was merely computed from successive timestamped positions, it's not a huge deal. But if you really do need to represent speed in a valid GPX file, use 1.0 or represent it as an extension in 1.1 [Non-text portions of this message have been removed]
christian.freisen+yahoo.de on Sun May 02 14:40:57 2010 (link)
Hi Folks, is there a "best way" for creating GPX-Files for adding Locations to photos? I tried with only adding waypoints to the file but most Photo-Taggers won't recognize theme correctly. Would hope for an fast answer Chris
egroups+topografix.com on Mon May 03 05:08:31 2010 (link), replying to msg
Hello, >> is there a "best way" for creating GPX-Files for adding Locations to photos? >> I tried with only adding waypoints to the file but most Photo-Taggers won't recognize theme You can look at how EasyGPS creates GPX 1.1 with geotagged photos. http://www.easygps.com/download.asp -- Dan Foster
christian.freisen+yahoo.de on Mon May 03 05:10:14 2010 (link), replying to msg
Thanks for the answer but I think I misspell my meaning: I don't want to tag photos by myself. I only wanna create the gpx-files so that the users can decide which application they use for tagging. I've tested this with waypoints only but most tagging-programs won't recognize them. --- In gpsxml+yahoogroups.com, Simon Slavin <slavins+...> wrote: > > > On 2 May 2010, at 6:49pm, christian.freisen wrote: > > > is there a "best way" for creating GPX-Files for adding Locations to photos? > > I tried with only adding waypoints to the file but most Photo-Taggers won't recognize theme > > The standard called 'EXIF' which is used for adding tags of all types to photos. It was originally invented for information to do with how the camera was set up: aparture, flush, etc. but it has been extended to hold many other types of information including location information. Photo-geotagging is almost always done by adding EXIF information. Take a look at > > http://en.wikipedia.org/wiki/Exchangeable_image_file_format#Geolocation > > http://en.wikipedia.org/wiki/Geotagging#JPEG_photos > > and perhaps EXIF 2.2 at > > http://www.exif.org/specifications.html > > There's probably a pre-made library and command-line program for your platform which can be used to add extra tags to an existing image file. You just call it and feed it parameters. > > Simon. >
craig.miller+spatialminds.com on Mon May 03 05:11:44 2010 (link), replying to msg
A track. On Sun, May 2, 2010 at 10:49 AM, christian.freisen < christian.freisen+yahoo.de> wrote: > > > Hi Folks, > > is there a "best way" for creating GPX-Files for adding Locations to > photos? > I tried with only adding waypoints to the file but most Photo-Taggers won't > recognize theme correctly. > > Would hope for an fast answer > > Chris > > > -- Craig Miller Geospatial Software Architect [Non-text portions of this message have been removed]
ptomblin+gmail.com on Mon May 17 16:10:45 2010 (link)
If I have 3 GPX files exported from Garmin Training Center or connect.garmin.com from three GPSes in the same race, is there any way to put them together to visualize where all three competitors were at each point of the race? I've seen them do this on TV with something like an ocean sailboat race or even for events like bicycle time trials or downhill ski runs where the competitors weren't on the course at the same time, but is there any free or cheap software to do it for yourself? -- http://www.linkedin.com/in/paultomblin http://careers.stackoverflow.com/ptomblin [Non-text portions of this message have been removed]
robertlipe+gmail.com on Mon May 17 16:31:22 2010 (link), replying to msg
The time control of google Earth will do that. Just set the throat to be for a single second then press play. On May 17, 2010 6:10 PM, "Paul Tomblin" <ptomblin+gmail.com> wrote: If I have 3 GPX files exported from Garmin Training Center or connect.garmin.com from three GPSes in the same race, is there any way to put them together to visualize where all three competitors were at each point of the race? I've seen them do this on TV with something like an ocean sailboat race or even for events like bicycle time trials or downhill ski runs where the competitors weren't on the course at the same time, but is there any free or cheap software to do it for yourself? -- http://www.linkedin.com/in/paultomblin http://careers.stackoverflow.com/ptomblin [Non-text portions of this message have been removed] ------------------------------------ Yahoo! Groups Links [Non-text portions of this message have been removed]
malik.imran110+yahoo.com on Wed May 19 10:29:08 2010 (link)
hi all i have to read values from .gpx files using vb.net or developer6i can any one help me.
robertlipe+gmail.com on Wed May 19 10:46:34 2010 (link), replying to msg
On Wed, May 19, 2010 at 12:22 PM, malik.imran110 <malik.imran110+yahoo.com>wrote: > hi all i have to read values from .gpx files using vb.net or developer6i > can any one help me. > Yes. (See how productive it is when you don't provide nearly enough information? :-) [Non-text portions of this message have been removed]
rich+dreamflying.com on Sat May 22 17:45:01 2010 (link), replying to msg
Maybe this will help you to better frame the question: http://www.cplusplus.com/articles/how_to_ask/ On Wed, May 19, 2010 at 10:46 AM, Robert Lipe <robertlipe+gmail.com> wrote: > > > On Wed, May 19, 2010 at 12:22 PM, malik.imran110 > <malik.imran110+yahoo.com <malik.imran110%40yahoo.com>>wrote: > > > > hi all i have to read values from .gpx files using vb.net or developer6i > > can any one help me. > > > > Yes. > > (See how productive it is when you don't provide nearly enough information? > :-) > > [Non-text portions of this message have been removed] > > > -- Rich Knox Mobile Application Developer http://www.bikemyway.com richknox+gmail.com | 206-257-9922 [Non-text portions of this message have been removed]
sunburned.surveyor+gmail.com on Tue May 25 12:18:09 2010 (link), replying to msg
Paul, You can also use OpenJUMP and my open source GPX plug-in to import and view GPX files. Let me know if you want help getting OpenJUMP set-up to do this. Landon On Mon, May 17, 2010 at 4:31 PM, Robert Lipe <robertlipe+gmail.com> wrote: > > > The time control of google Earth will do that. Just set the throat to be > for a single second then press play. > > > On May 17, 2010 6:10 PM, "Paul Tomblin" <ptomblin+gmail.com<ptomblin%40gmail.com>> > wrote: > > If I have 3 GPX files exported from Garmin Training Center or > connect.garmin.com from three GPSes in the same race, is there any way to > put them together to visualize where all three competitors were at each > point of the race? I've seen them do this on TV with something like an > ocean sailboat race or even for events like bicycle time trials or downhill > ski runs where the competitors weren't on the course at the same time, but > is there any free or cheap software to do it for yourself? > > -- > http://www.linkedin.com/in/paultomblin > http://careers.stackoverflow.com/ptomblin > > [Non-text portions of this message have been removed] > > ------------------------------------ > > Yahoo! Groups Links > > > [Non-text portions of this message have been removed] > > > [Non-text portions of this message have been removed]
deepak_8282+yahoo.co.in on Fri Jun 04 16:11:34 2010 (link)
i have a project where users uploads kml and gpx files and i have to validate there XML in c3.net (asp.net),there are tools which can validate files,but is it possible through module i can develop in asp.net using c#.am confused because aima trying it by making DTD file for gpx and kml file but numbers of tags/attributes are lots and aim not getting all tags.please provide me solution for this . Is is possible using coding or i have to buy tool/software for this. what iam trying is that it can be done throgh custom code in c#.net. regards Deepak verma
no1looser+yahoo.com on Mon Jun 07 13:48:31 2010 (link), replying to msg
--- In gpsxml+yahoogroups.com, "deepak_8282" <deepak_8282+...> wrote: > > i have a project where users uploads kml and gpx files and i have to validate there XML in c3.net (asp.net),there are tools which can validate files,but is it possible through module i can develop in asp.net using c#.am confused because aima trying it by making DTD file for gpx and kml file but numbers of tags/attributes are lots and aim not getting all tags.please provide me solution for this . > > Is is possible using coding or i have to buy tool/software for this. > what iam trying is that it can be done throgh custom code in c#.net. > > > regards > Deepak verma > I searched for some time on this until I read an article on Microsoft website. Simply take the schema for GPX or KML and using the Visual Studio creat a DLL from the schema. Then you can attempt to read the XML file and validate its contents. I created on for both GPX 1.0 and 1.1 formats and now working on a KML DLL. The code automatically generated will let you read and write these XML files with little code in your ASPX page.
the_magicien+yahoo.com on Wed Jun 23 08:49:37 2010 (link)
I would like to update the map in GPS devices such as Garmin 60CSX or Garmin Navigator.What is the file format & how to do that? Thanks
robertlipe+gmail.com on Wed Jun 23 09:21:01 2010 (link), replying to msg
On Tue, Jun 22, 2010 at 10:44 PM, the_magicien <the_magicien+yahoo.com>wrote: > I would like to update the map in GPS devices such as Garmin 60CSX or > Garmin Navigator.What is the file format & how to do that? > Not GPX. Garmin sells map updates. A few other groups make free maps. See http://www.gpsfaqs.org/faqs/garmin/xseries/g60csx/mapping.html#free_maps RJL [Non-text portions of this message have been removed]
speleoluc+gmail.com on Tue Jul 13 07:00:28 2010 (link)
Hi, I recently added a timestamp to my GPX export, only to learn it was rejected by MapSource, and also by the SaxCount.exe validator. My header goes like this <?xml version="1.0" encoding="Windows-1252" standalone="no" ?> <gpx version="1.1" xmlns="http://www.topografix.com/GPX/1/1" creator="Auriga 1.24a http://www.speleo.qc.ca/Auriga" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <time>2010-07-12T13:25:40Z</time> Oddly, if I switch to GPX 1.0, it works. Is <time> no longer supported in 1.1? Regards, -- Luc Le Blanc http://www.speleo.qc.ca/Auriga
robertlipe+gmail.com on Tue Jul 13 07:16:39 2010 (link), replying to msg
On Tue, Jul 13, 2010 at 4:50 AM, Luc Le Blanc <speleoluc+gmail.com> wrote: > Hi, > > I recently added a timestamp to my GPX export, only to learn it was > rejected by MapSource, and also by the SaxCount.exe validator. My > header goes like this > > <?xml version="1.0" encoding="Windows-1252" standalone="no" ?> > <gpx version="1.1" xmlns="http://www.topografix.com/GPX/1/1" > creator="Auriga 1.24a http://www.speleo.qc.ca/Auriga" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/1/1/gpx.xsd"> > <time>2010-07-12T13:25:40Z</time> > > Oddly, if I switch to GPX 1.0, it works. Is <time> no longer supported in > 1.1? Time is supported. Look in the XSD. Most likely, you have it out of order or have created a malformed time entry, but since you didn't include a full sample, we can't comment authoritatively. RJL [Non-text portions of this message have been removed]
speleoluc+gmail.com on Tue Jul 13 11:11:54 2010 (link), replying to msg
2010/7/13 Robert Lipe <robertlipe+gmail.com>: > On Tue, Jul 13, 2010 at 4:50 AM, Luc Le Blanc <speleoluc+gmail.com> wrote: > >> Hi, >> >> I recently added a timestamp to my GPX export, only to learn it was >> rejected by MapSource, and also by the SaxCount.exe validator. My >> header goes like this >> >> <?xml version="1.0" encoding="Windows-1252" standalone="no" ?> >> <gpx version="1.1" xmlns="http://www.topografix.com/GPX/1/1" >> creator="Auriga 1.24a http://www.speleo.qc.ca/Auriga" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://www.topografix.com/GPX/1/1 >> http://www.topografix.com/GPX/1/1/gpx.xsd"> >> <time>2010-07-12T13:25:40Z</time> >> >> Oddly, if I switch to GPX 1.0, it works. Is <time> no longer supported in >> 1.1? > > > Time is supported. �Look in the XSD. > > Most likely, you have it out of order or have created a malformed time > entry, but since you didn't include a full sample, we can't comment > authoritatively. > > > RJL Here are 2 files, one in GPX 1.0, the other in GPX 1.1. Note that just adding </gpx> at the end of the header above also produced a full sample, albeit empty. The 1.0 file is OK, not the 1.1. The only change is the GPX version. Regards, -- Luc Le Blanc http://www.speleo.qc.ca/Auriga [Non-text portions of this message have been removed]
egroups+topografix.com on Tue Jul 13 11:29:41 2010 (link), replying to msg
Hello, Tuesday, July 13, 2010, 5:50:13 AM, Luc wrote: > > Hi, > I recently added a timestamp to my GPX export, only to learn it was > rejected by MapSource, and also by the SaxCount.exe validator. My > header goes like this > <?xml version="1.0" encoding="Windows-1252" standalone="no" ?> > <gpx version="1.1" xmlns="http://www.topografix.com/GPX/1/1" > creator="Auriga 1.24a http://www.speleo.qc.ca/Auriga" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/1/1/gpx.xsd"> > <time>2010-07-12T13:25:40Z</time> > Oddly, if I switch to GPX 1.0, it works. Is <time> no longer supported in 1.1? <time> lives inside <metadata> in GPX 1.1 GPX documents contain a metadata header, followed by waypoints, routes, and tracks. You can add your own elements to the extensions section of the GPX document. -- Dan Foster
speleoluc+gmail.com on Tue Jul 13 11:44:55 2010 (link), replying to msg
2010/7/13 Dan Foster <egroups+topografix.com>: > Hello, > > Tuesday, July 13, 2010, 5:50:13 AM, Luc wrote: > >> >> Hi, > >> I recently added a timestamp to my GPX export, only to learn it was >> rejected by MapSource, and also by the SaxCount.exe validator. My >> header goes like this > >> <?xml version="1.0" encoding="Windows-1252" standalone="no" ?> >> <gpx version="1.1" xmlns="http://www.topografix.com/GPX/1/1" >> creator="Auriga 1.24a http://www.speleo.qc.ca/Auriga" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://www.topografix.com/GPX/1/1 >> http://www.topografix.com/GPX/1/1/gpx.xsd"> >> <time>2010-07-12T13:25:40Z</time> > >> Oddly, if I switch to GPX 1.0, it works. Is <time> no longer supported in 1.1? > > <time> lives inside <metadata> in GPX 1.1 > > GPX documents contain a metadata header, followed by waypoints, > routes, and tracks. You can add your own elements to the extensions section of the GPX document. > > > -- > Dan Foster You mean my <time>2010-07-12T13:25:40Z</time> line should be inside the <gps> tag, or I must use a time="" format inside the <gpx> tag? -- Luc Le Blanc http://www.speleo.qc.ca/Auriga
egroups+topografix.com on Tue Jul 20 15:15:50 2010 (link)
Are any of you seeing malformed GPX files coming from Garmin nuvi, Oregon, and Colorado GPS receivers? My Windows programs display an error message when they encounter malformed XML, and I'm getting a lot of customer support questions from Garmin users. The typical corruption I'm seeing is in the <name> tag of waypoints and routes, and usually displays as garbage characters or chinese characters in a text editor. The MSXML parser usually reports "An invalid character was found in text content". Here are a few recent examples: I:\Garmin\gpx\current\Current.gpx <rte><name>�??�??�??�??�??�??�??�??�??�??�??�??�??�??�??�??�?䁬�?�?��??�?灐</name> G:\Garmin\gpx\current\Current.gpx <desc>£�?�r�?£�?�£Ḵ£</desc> E:\GPX\Current.gpx <gpxx:PostalCode>�?�</gpxx:PostalCode>
robertlipe+gmail.com on Tue Jul 20 15:54:38 2010 (link), replying to msg
On Tue, Jul 20, 2010 at 3:13 PM, Dan Foster <egroups+topografix.com> wrote: > Are any of you seeing malformed GPX files coming from Garmin nuvi, > Oregon, and Colorado GPS receivers? My Windows programs display an > error message when they encounter malformed XML, and I'm getting a > lot of customer support questions from Garmin users. > I'm not seeing huge numbers, but I do see it. I had a report today from someone with route named control-A. Current.gpx sometimes doesn't get written. I've been sending users with affected files to Garmin's support as that's clearly invalid. RJL [Non-text portions of this message have been removed]
daveswarthout+gmail.com on Wed Aug 04 10:51:09 2010 (link)
Hi, I'm new to this group. I searched around recently looking for a way to display saved tracks from my travels in various parts of the world with the proper times, that is, the local time in the country (time zone) when the track was recorded. I'm a Garmin GPS Map60Cx user so the program I use to display my tracks, other than Google Earth, is Garmin's Mapsource. I can choose the way the time is displayed by changing the UTC offset in Mapsource's Preferences but then all other tracks I display will use that same "global" offset as well. Which leads to the reason I'm posting this in the GPX group: ignoring for the moment the issue of Daylight Saving, is there a way in the current implementation to include a UTC offset within a GPX file? If not, are there plans to include such capability in a newer version of the GPX format? That way tracks would always display with the actual time they were recorded. I understand that even if there was a way to include this information in the GPX file certain software programs like Mapsource would need to be changed to read and display the data properly, but that's beside the point of my question. Any information you can share would be appreciated, Thanks in advance, Dave
jrepetto+free.fr on Thu Aug 05 03:31:15 2010 (link), replying to msg
On 08/04/10 23:29, Alan wrote: > The crude but effective method I use is to add/subtract 1 hour to/from your > GPS track point time for each 15 degrees of longitude the point is > ease/west of the Greenwich meridian. > A better method should be to use a vectorial map of the time zones. Since the geographical coordinates are known, it will be easy to find the time zone. Jean-Claude
tt+smartcomsoftware.com on Thu Aug 05 07:49:52 2010 (link), replying to msg
This is actually quite a complex issue if you want times used in country, as opposed to maritime time zones. For countries which have just one time zone, then the boundaries are pretty straightforward and don't change too often. But quite a few countries have multiple time zones, and if you go anywhere out of the way then the boundaries between one zone and another are generally not well defined. Also, countries change the time zone and the application of daylight saving time much more frequently than one may think - typically a change somewhere in the world every few weeks. If you want more info on this, a good starting point is http://www.twinsun.com/tz/tz-link.htm. The tz database is used in most Linux distributions, and is better than that in Windows. As far as including this information in GPS XML is concerned, you could do an extension like Garmin do depth and other data in their extension. It could either be a time offset, which gives the most flexibility, or it could be a parameter. If a parameter this would need to cover both the tz data and support fro maritime time zones. The offset is simplest to implement, but the parameter tells data users a bit about why the offset is what it is. Tim Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Jean-Claude REPETTO Sent: 05 August 2010 07:22 To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] UTC Offset capability? On 08/04/10 23:29, Alan wrote: > The crude but effective method I use is to add/subtract 1 hour to/from your > GPS track point time for each 15 degrees of longitude the point is > ease/west of the Greenwich meridian. > A better method should be to use a vectorial map of the time zones. Since the geographical coordinates are known, it will be easy to find the time zone. Jean-Claude [Non-text portions of this message have been removed]
daveswarthout+gmail.com on Thu Aug 05 13:37:32 2010 (link), replying to msg
I can appreciate the complexity of the issue if one desired to make changes to the GPX file format. All I want to do is set an offset (in hours + or - UTM and ignoring Daylight Saving Time entirely) for a a particular saved GPX file so that the tracks I recorded in Fiji show the actual time the track was made, and a track I recorded in Paris shows the actual time, in Paris, when the track was made. I can do this on a file by file basis within Mapsource, as I mentioned, but that method is tedious. As is adding an offset to each and every trackpoint in the GPX XML code. But thanks for the feedback anyway. Perhaps there is no SIMPLE way to do what I want. --- In gpsxml+yahoogroups.com, "Tim Thornton" <tt+...> wrote: > > This is actually quite a complex issue if you want times used in country, as > opposed to maritime time zones. > > For countries which have just one time zone, then the boundaries are pretty > straightforward and don't change too often. > > But quite a few countries have multiple time zones, and if you go anywhere > out of the way then the boundaries between one zone and another are > generally not well defined. > > Also, countries change the time zone and the application of daylight saving > time much more frequently than one may think - typically a change somewhere > in the world every few weeks. > > If you want more info on this, a good starting point is > http://www.twinsun.com/tz/tz-link.htm. The tz database is used in most Linux > distributions, and is better than that in Windows. > > As far as including this information in GPS XML is concerned, you could do > an extension like Garmin do depth and other data in their extension. It > could either be a time offset, which gives the most flexibility, or it could > be a parameter. If a parameter this would need to cover both the tz data and > support fro maritime time zones. The offset is simplest to implement, but > the parameter tells data users a bit about why the offset is what it is. > > Tim > > > > Smartcom Software Ltd > > Portsmouth Technopole > > Kingston Crescent > > Portsmouth PO2 8FA > > United Kingdom > > > > www.smartcomsoftware.com > > > > Smartcom Software is a limited company registered in England and Wales, > registered number 05641521. > > > > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of > Jean-Claude REPETTO > Sent: 05 August 2010 07:22 > To: gpsxml+yahoogroups.com > Subject: Re: [gpsxml] UTC Offset capability? > > > > > > On 08/04/10 23:29, Alan wrote: > > The crude but effective method I use is to add/subtract 1 hour to/from > your > > GPS track point time for each 15 degrees of longitude the point is > > ease/west of the Greenwich meridian. > > > > A better method should be to use a vectorial map of the time zones. > Since the geographical coordinates are known, it will be easy to find > the time zone. > > Jean-Claude > > > > > > [Non-text portions of this message have been removed] >
robertlipe+gmail.com on Thu Aug 05 14:01:56 2010 (link), replying to msg
On Thu, Aug 5, 2010 at 3:37 PM, Dave <daveswarthout+gmail.com> wrote: > I can appreciate the complexity of the issue if one desired to make changes > to the GPX file format. This is the group that focuses on the file format itself. That's why most of the answers clustered around that. We get to think about things like "what if your track spans multiple time zones" and how to present that in the XML. > All I want to do is set an offset (in hours + or - UTM and ignoring > Daylight Saving Time entirely) for a a particular saved GPX file so that the > tracks I recorded in Fiji show the actual time the track was made, and a > track I recorded in Paris shows the actual time, in Paris, when the track > was made. > This really is up to the application displaying the time. The time inside a GPX file is always GMT. > I can do this on a file by file basis within Mapsource, as I mentioned, but > that method is tedious. As is adding an offset to each and every trackpoint > in the GPX XML code. > Doing that actually makes the file itself a lie, but I understand you just want it to "look right" in an application that doesn't allow what you're looking for. > But thanks for the feedback anyway. Perhaps there is no SIMPLE way to do > what I want. You can use the 'move' option of GPSBabel's track filter to do it in semi-automated way. It's still up to you to decide how many hours/minutes you want to shift the track. http://www.gpsbabel.org/htmldoc-1.4.0/filter_track.html RJL > > --- In gpsxml+yahoogroups.com, "Tim Thornton" <tt+...> wrote: > > > > This is actually quite a complex issue if you want times used in country, > as > > opposed to maritime time zones. > > > > For countries which have just one time zone, then the boundaries are > pretty > > straightforward and don't change too often. > > > > But quite a few countries have multiple time zones, and if you go > anywhere > > out of the way then the boundaries between one zone and another are > > generally not well defined. > > > > Also, countries change the time zone and the application of daylight > saving > > time much more frequently than one may think - typically a change > somewhere > > in the world every few weeks. > > > > If you want more info on this, a good starting point is > > http://www.twinsun.com/tz/tz-link.htm. The tz database is used in most > Linux > > distributions, and is better than that in Windows. > > > > As far as including this information in GPS XML is concerned, you could > do > > an extension like Garmin do depth and other data in their extension. It > > could either be a time offset, which gives the most flexibility, or it > could > > be a parameter. If a parameter this would need to cover both the tz data > and > > support fro maritime time zones. The offset is simplest to implement, but > > the parameter tells data users a bit about why the offset is what it is. > > > > Tim > > > > > > > > Smartcom Software Ltd > > > > Portsmouth Technopole > > > > Kingston Crescent > > > > Portsmouth PO2 8FA > > > > United Kingdom > > > > > > > > www.smartcomsoftware.com > > > > > > > > Smartcom Software is a limited company registered in England and Wales, > > registered number 05641521. > > > > > > > > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf > Of > > Jean-Claude REPETTO > > Sent: 05 August 2010 07:22 > > To: gpsxml+yahoogroups.com > > Subject: Re: [gpsxml] UTC Offset capability? > > > > > > > > > > > > On 08/04/10 23:29, Alan wrote: > > > The crude but effective method I use is to add/subtract 1 hour to/from > > your > > > GPS track point time for each 15 degrees of longitude the point is > > > ease/west of the Greenwich meridian. > > > > > > > A better method should be to use a vectorial map of the time zones. > > Since the geographical coordinates are known, it will be easy to find > > the time zone. > > > > Jean-Claude > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
markc+gps2cad.com on Wed Sep 01 18:05:33 2010 (link)
I'm a developer working in Visual Studio 2008 (VB) and i need to build a windows forms program that will: open a gpx file extract the waypoints, routes, and tracks make changes if necessary write the new data back to the gpx file, and save it to the gps unit. I'm working primarily with Garmin and Magellan, but Garmin first. I'm really having trouble finding out how to get started. I have stacks of books on XML, but nothing on how to apply the theory to .gpx files. What's the best way to get started? Are there any sample projects anywhere? There are xml and gpx specifications all over, but no info on how to work with it in a VB project. Can anyone help? thanks Mark c Phoenix
sunburned.surveyor+gmail.com on Thu Sep 02 07:32:04 2010 (link), replying to msg
Mark, I don't think there is an existing library for .Net to work with GPX files, at least not one that is open source. I built an open source library to parse GPX files, but it is written in Java. If it will help you to look at the source code, you can find it here: http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/gpx/branches/20081114-Release/ Take a look at the code, and then let me know if you need some more direction. The Sunburned Surveyor On Wed, Sep 1, 2010 at 5:20 PM, cmarkc2001 <markc+gps2cad.com> wrote: > > > I'm a developer working in Visual Studio 2008 (VB) and i need to build a > windows forms program that will: > > open a gpx file > extract the waypoints, routes, and tracks > make changes if necessary > write the new data back to the gpx file, and save it to the gps unit. > > I'm working primarily with Garmin and Magellan, but Garmin first. > > I'm really having trouble finding out how to get started. I have stacks of > books on XML, but nothing on how to apply the theory to .gpx files. What's > the best way to get started? Are there any sample projects anywhere? There > are xml and gpx specifications all over, but no info on how to work with it > in a VB project. > > Can anyone help? > > thanks > Mark c > Phoenix > > > [Non-text portions of this message have been removed]
kaz+okuda.ca on Thu Sep 02 08:35:14 2010 (link), replying to msg
GPX is pretty straight forward XML and there should be a few libraries built right in to VB to make it easy to parse them. I have an open source GeoTagger app that I've written (in C#) that parses out track points from a GPX file. It isn't VB, but it is .NET and a starting point (at least for reading). http://code.google.com/p/geotagger/source/browse/trunk/Geotagger/GPSTrack.cs I don't know much VB, but the .NET libraries should be similar, and this code uses an XmlTextReader to parse through the file (reads the file once and copies the data into another structure for faster access). I'm sure there is also a DOM based library (XmlDocument?) that you can use to query the contents of the file. Worst case, search for "VB XML" and I'm sure you will find lots of ways to parse a GPX/XML file. Saving it back to the GPS unit is a totally different problem. --- In gpsxml+yahoogroups.com, "cmarkc2001" <markc+...> wrote: > > I'm a developer working in Visual Studio 2008 (VB) and i need to build a windows forms program that will: > > open a gpx file > extract the waypoints, routes, and tracks > make changes if necessary > write the new data back to the gpx file, and save it to the gps unit. > > I'm working primarily with Garmin and Magellan, but Garmin first. > > I'm really having trouble finding out how to get started. I have stacks of books on XML, but nothing on how to apply the theory to .gpx files. What's the best way to get started? Are there any sample projects anywhere? There are xml and gpx specifications all over, but no info on how to work with it in a VB project. > > Can anyone help? > > thanks > Mark c > Phoenix >
markc+gps2cad.com on Fri Sep 03 09:53:53 2010 (link), replying to msg
Thanks for your response. I will have a look at It over the weekend. This forum has been most helpful, and I appreciate it. Mark c. -----Original Message----- From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Sunburned Surveyor Sent: Thursday, September 02, 2010 7:32 AM To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] getting started with GPX Mark, I don't think there is an existing library for .Net to work with GPX files, at least not one that is open source. I built an open source library to parse GPX files, but it is written in Java. If it will help you to look at the source code, you can find it here: http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/gpx/branches/200811 14-Release/ Take a look at the code, and then let me know if you need some more direction. The Sunburned Surveyor On Wed, Sep 1, 2010 at 5:20 PM, cmarkc2001 <markc+gps2cad.com> wrote: > > > I'm a developer working in Visual Studio 2008 (VB) and i need to build a > windows forms program that will: > > open a gpx file > extract the waypoints, routes, and tracks > make changes if necessary > write the new data back to the gpx file, and save it to the gps unit. > > I'm working primarily with Garmin and Magellan, but Garmin first. > > I'm really having trouble finding out how to get started. I have stacks of > books on XML, but nothing on how to apply the theory to .gpx files. What's > the best way to get started? Are there any sample projects anywhere? There > are xml and gpx specifications all over, but no info on how to work with it > in a VB project. > > Can anyone help? > > thanks > Mark c > Phoenix > > > [Non-text portions of this message have been removed] ------------------------------------ Yahoo! Groups Links
gps_dr+q.com on Thu Sep 09 17:47:54 2010 (link)
Visual studio 2008 includes a feature called LinQ. It allows you to process data via SQL like queries. You can suck in a GPX file in one statement and parse in whatever way you like. The Help function in Visual studio should show you videos etc on how to work with XML in an eaiser manner. I used it to read/write gpx files to allow me to translate waypoint symbols between vendors and model lines. Also wrote code to edit waypoints, process user settings etc. Also plan to write KML for better translation to Google earth, and maybe write spreadsheet data for documentation. Haven't touched visual Basic in a couple years, nor used it beyond class assignments. Good Luck [Non-text portions of this message have been removed]
markc+gps2cad.com on Thu Sep 09 17:48:25 2010 (link), replying to msg
can you help me out a bit more - i'm new to xml. Some of the code referes to a gpxtype: Dim Myserializer As XmlSerializer = New XmlSerializer(GetType(gpxType)) what is the gpxType, and where do i get it? thanks mark c. --- In gpsxml+yahoogroups.com, "Alan" <smithalan+...> wrote: > > I used xsd.exe to generate the attached class definition which allowed me to > use the XmlSerializer class to parse (deserialize) GPX (ver 1.1) files. > > That's fine for reading and writing, but it won't help you upload them to a > GPS device - you're on your own there. > > Cheers, > > > > _____ > > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of > kazokuda > Sent: Friday, 3 September 2010 1:35 AM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Re: getting started with GPX > > > > > > GPX is pretty straight forward XML and there should be a few libraries built > right in to VB to make it easy to parse them. > > I have an open source GeoTagger app that I've written (in C#) that parses > out track points from a GPX file. It isn't VB, but it is .NET and a starting > point (at least for reading). > > http://code.google.com/p/geotagger/source/browse/trunk/Geotagger/GPSTrack.cs > > I don't know much VB, but the .NET libraries should be similar, and this > code uses an XmlTextReader to parse through the file (reads the file once > and copies the data into another structure for faster access). I'm sure > there is also a DOM based library (XmlDocument?) that you can use to query > the contents of the file. > > Worst case, search for "VB XML" and I'm sure you will find lots of ways to > parse a GPX/XML file. > > Saving it back to the GPS unit is a totally different problem. > > --- In gpsxml+yahoogroups.com <mailto:gpsxml%40yahoogroups.com> , > "cmarkc2001" <markc+> wrote: > > > > I'm a developer working in Visual Studio 2008 (VB) and i need to build a > windows forms program that will: > > > > open a gpx file > > extract the waypoints, routes, and tracks > > make changes if necessary > > write the new data back to the gpx file, and save it to the gps unit. > > > > I'm working primarily with Garmin and Magellan, but Garmin first. > > > > I'm really having trouble finding out how to get started. I have stacks of > books on XML, but nothing on how to apply the theory to .gpx files. What's > the best way to get started? Are there any sample projects anywhere? There > are xml and gpx specifications all over, but no info on how to work with it > in a VB project. > > > > Can anyone help? > > > > thanks > > Mark c > > Phoenix > > > > > > > > [Non-text portions of this message have been removed] >
dananderson2+yahoo.com on Thu Sep 09 17:55:36 2010 (link), replying to msg
"gpxType" is the gpx data. I suggest you read through the schema documentation... http://www.topografix.com/GPX/1/1/ Dan --- In gpsxml+yahoogroups.com, "cmarkc2001" <markc+...> wrote: > > can you help me out a bit more - i'm new to xml. Some of the code referes to a gpxtype: > > Dim Myserializer As XmlSerializer = New XmlSerializer(GetType(gpxType)) > > what is the gpxType, and where do i get it? > > thanks > mark c.
kellybellis+gwi.net on Wed Oct 06 16:03:10 2010 (link)
Does anybody know it there is a little app that can read in a text file of coordinates and spit out a formatted GPX file? I'm a land surveyor and wish to take a bucket of coordinates and produce a GPX file from them. Thanks for any advice! Kind regards, Kelly
robertlipe+gmail.com on Wed Oct 06 16:07:33 2010 (link), replying to msg
On Tue, Oct 5, 2010 at 8:14 AM, vkbellis <kellybellis+gwi.net> wrote: > Does anybody know it there is a little app that can read in a text file of > coordinates and spit out a formatted GPX file? > > I'm a land surveyor and wish to take a bucket of coordinates and produce a > GPX file from them. > GPSBabel writes GPX, reads many text file formats, makes it easy to add news ones, and probably runs on your unstated operating system. [Non-text portions of this message have been removed]
egroups+topografix.com on Thu Nov 04 05:29:03 2010 (link), replying to msg
Hello, Thursday, November 4, 2010, 6:16:30 AM, Alan wrote: > > Hi GPX Forum > I'm wanting to analyse GPS track points with an accuracy higher than one > second. Obviously the validity of the data will depend on the GPS device, > but it seems that the xsd:dateTime does not allow for decimals. > Is this a subject already fully canvassed? GPX allows decimal seconds, as does ISO 8601, on which GPX' XML dateTime is based. Element: time Creation/modification timestamp for element. Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs. http://en.wikipedia.org/wiki/ISO_8601 Decimal fractions may also be added to any of the three time elements. A decimal point, either a comma or a dot (without any preference as stated most recently in resolution 10 of the 22nd General Conference CGPM in 2003), is used as a separator between the time element and its fraction. A fraction may only be added to the lowest order time element in the representation. To denote "14 hours, 30 and one half minutes", do not include a seconds figure. Represent it as "14:30,5", "1430,5", "14:30.5", or "1430.5". There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties. -- Dan Foster
mhoegh+gmail.com on Mon Dec 06 14:54:14 2010 (link)
Hello. I'm trying to create a gpx editor with VS2008 in C#. I made it to create a gpx class from gpx.xsd using Microsofts xsd.tool and I'm able to open, edit and save gpx files. However I now also want to edit Garmin gpx files and it seems that garmin has extended the gpx schema (see http://www8.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd). Having a look into gpx.xsd there are some locations around saying: 'You can add extend GPX by adding your own elements from another schema here' however I have no clue how to realize that. Is there a easy way to include the garmin xsd or is it necessary to include the extension elements defined by garmin into the extensionsType element? Regards...
tri+boscoso.com on Sun Feb 27 17:54:42 2011 (link)
Is there a standard algorithm for detecting pauses in GPX files? The use case is that RunKeeper (iPhone & Android app at runkeeper.com) doesn't pause users when they are stuck at a traffic light. Since RunKeeper lack that feature, I want to download the GPX for my run, detect the pauses, write another GPX with the pauses in place, and upload back to the RunKeeper site. Then I have a view of my total run time and a view of when I'm actually running. -- Bosco
fgdufoe3+yahoo.com on Sun Feb 27 17:55:31 2011 (link)
I've noticed what I believe to be a few errors in the documentation. Here are the changes I suggest: wptType: "wpt represents a waypoint, point of interest, or named feature on a map." should read "wpt represents waypoint - a location identified by latitude and longitude and named for easy reference." The documentation never defines a waypoint although it uses the word several times. A waypoint is nothing more (or less) than a saved location which (usually) is given a name for mnemonic convenience. The location of a point of interest or a named feature on a chart or map may be saved as a waypoint, but the waypoint is a separate entity. rteType: "rte represents route - an ordered list of waypoints representing a series of turn points leading to a destination." should read "rte represents route - an ordered list of locations representing a series of intermediate destinations leading to an ultimate destination." Route points are different from waypoints. While it is common for handheld GPS receivers with limited storage and awkward user interfaces to implement routes as a list of waypoints a PC-based chart or map program can implement routes with points chosen by the user clicking locations on the screen. Those points would be saved with the route but would not be saved separate from the route. Where hardware resources permit, waypoint locations should be copied to route points rather than being incorporated by reference. A route may follow a straight line, so the route points are not necessarily turn points. latitudeType: "The latitude of the point. Decimal degrees, WGS84 datum." should read "The latitude of the point. Decimal degrees, WGS84 datum. North latitude has a positive sign, south latitude has a negative sign." Most of us expect a positive latitude to be north but the documentation should make it explicit. longitudeType: "The longitude of the point. Decimal degrees, WGS84 datum." should read "The longitude of the point. Decimal degrees, WGS84 datum. East longitude has a positive sign, west longitude has a negative sign." Most map programs follow that convention, but the documentation should make it explicit." Fabbian
the_magicien+yahoo.com on Sun Feb 27 17:56:13 2011 (link)
Dear All, I want to create GPX file and upload to the my Garmin 60CSX gps device. Please advice me how I able to do that. Thanks
ragge+kth.se on Sun Feb 27 17:56:40 2011 (link)
Hello, Is there a recommended way to represent Accuracy or EPE (estimated position error) in distance (meters) in GPX? /ragge
robertlipe+gmail.com on Sun Feb 27 17:58:32 2011 (link), replying to msg
On Sat, Jan 22, 2011 at 12:14 PM, the_magicien <the_magicien+yahoo.com>wrote: > Dear All, > > I want to create GPX file and upload to the my Garmin 60CSX gps device. > > Please advice me how I able to do that. > This list really is more for the development of the GPX file format itself than about how to use any specific piece of software. There are a large number of programs that support GPX, including those at http://www.topografix.com/gpx_resources.asp Many of them will send to a 60CSx. [Non-text portions of this message have been removed]
robertlipe+gmail.com on Sun Feb 27 18:01:00 2011 (link), replying to msg
On Thu, Feb 24, 2011 at 2:13 PM, ragge0 <ragge+kth.se> wrote: > > Hello, > > Is there a recommended way to represent Accuracy or EPE (estimated position > error) in distance (meters) in GPX? > As GPX is about exchanging GPS data between vendors there is no standard representation of EPE in the industry (most vendors won't even document how it's computed, it's not meaningful to transfer, so it's not represented in GPX. If you wanted to encode it in an extension, knowing that it's useful relative only in a small domain, that's fine. Key word: "estimated". RJL [Non-text portions of this message have been removed]
robertlipe+gmail.com on Sun Feb 27 18:03:34 2011 (link), replying to msg
On Wed, Jan 5, 2011 at 7:31 PM, boscomonkey <tri+boscoso.com> wrote: > Is there a standard algorithm for detecting pauses in GPX files? > Lots of programs do this differently. You can denoise, look for low speed, look for clumps in proximity, etc. Filtering really depends ont he data you and vs. the data you want. Such filtering really is outside the scope of GPX. The use case is that RunKeeper (iPhone & Android app at runkeeper.com) > doesn't pause users when they are stuck at a traffic light. Since RunKeeper > lack that feature, I want to download the GPX for my run, detect the pauses, > write another GPX with the pauses in place, and upload back to the RunKeeper > site. > > Then I have a view of my total run time and a view of when I'm actually > running. > GPSBabel's track filter could bust them into separate tracks or track segments after you provide the threesholds, but it won't create multiple files of independent segments. RJL [Non-text portions of this message have been removed]
ajcartmell+fonant.com on Mon Feb 28 01:28:54 2011 (link), replying to msg
> latitudeType: > "The latitude of the point. Decimal degrees, WGS84 datum." should read > "The latitude of the point. Decimal degrees, WGS84 datum. North latitude > has a positive sign, south latitude has a negative sign." That's defined by the terms "longitude" and "latitude" to be honest, so no need to repeat it in the GPX definition. http://en.wikipedia.org/wiki/Longitude http://en.wikipedia.org/wiki/Latitude > Most of us expect a positive latitude to be north but the documentation > should make it explicit. A positive latitude *is* north. > Most map programs follow that convention, but the documentation should > make it explicit." All map programs follow that definition, otherwise they're not working with latitude and longitude. Cheers! Anthony -- www.fonant.com - Quality web sites Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex, BN11 1QR
tt+smartcomsoftware.com on Mon Feb 28 01:51:01 2011 (link), replying to msg
I think that this does need defining. I have come across some US centric mapping tools that use West as +ve, on the basis that all of the USA is West and things are simpler of there is no sign! Tim Thornton <http://www.twitter.com/smartcom_tim> Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Anthony Cartmell Sent: 28 February 2011 09:29 To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Proposed Revisions to GPX 1.1 Schema Documentation > latitudeType: > "The latitude of the point. Decimal degrees, WGS84 datum." should read > "The latitude of the point. Decimal degrees, WGS84 datum. North latitude > has a positive sign, south latitude has a negative sign." That's defined by the terms "longitude" and "latitude" to be honest, so no need to repeat it in the GPX definition. http://en.wikipedia.org/wiki/Longitude http://en.wikipedia.org/wiki/Latitude > Most of us expect a positive latitude to be north but the documentation > should make it explicit. A positive latitude *is* north. > Most map programs follow that convention, but the documentation should > make it explicit." All map programs follow that definition, otherwise they're not working with latitude and longitude. Cheers! Anthony -- www.fonant.com - Quality web sites Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex, BN11 1QR [Non-text portions of this message have been removed]
ajcartmell+fonant.com on Mon Feb 28 02:29:16 2011 (link), replying to msg
> I think that this does need defining. > > I have come across some US centric mapping tools that use West as +ve, > on the basis that all of the USA is West and things are simpler of there > is no sign! They're not using longitude then, and certainly not WGS84 coordinates, as used by most GPS systems. They must be using "negative longitude" instead :) Cheers! Anthony -- www.fonant.com - Quality web sites Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex, BN11 1QR
tt+smartcomsoftware.com on Mon Feb 28 02:54:05 2011 (link), replying to msg
I agree it isn�??t the normal convention, but NMEA0183 from GPS receivers explicitly uses N/S/E/W, and WGS84 defines Longitude as 0-180, +ve East. So to avoid confusion I think it is well worth a few words to state explicitly what convention is being used. Tim <http://www.twitter.com/smartcom_tim> Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Anthony Cartmell Sent: 28 February 2011 10:29 To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Proposed Revisions to GPX 1.1 Schema Documentation > I think that this does need defining. > > I have come across some US centric mapping tools that use West as +ve, > on the basis that all of the USA is West and things are simpler of there > is no sign! They're not using longitude then, and certainly not WGS84 coordinates, as used by most GPS systems. They must be using "negative longitude" instead :) Cheers! Anthony -- www.fonant.com - Quality web sites Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex, BN11 1QR [Non-text portions of this message have been removed]
ragge+kth.se on Mon Feb 28 03:11:21 2011 (link), replying to msg
--- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > On Thu, Feb 24, 2011 at 2:13 PM, ragge0 <ragge+...> wrote: > > > > > Hello, > > > > Is there a recommended way to represent Accuracy or EPE (estimated position > > error) in distance (meters) in GPX? > > > > As GPX is about exchanging GPS data between vendors there is no standard > representation of EPE in the industry (most vendors won't even document how > it's computed, it's not meaningful to transfer, so it's not represented in > GPX. I am not talking about the EPE value (some strange vendor specific 1-20 value, agreed), but the error in meters (or feet), which many vendors do provide. This value is just as much an approximation as the position, and gives the position much higher value since 95 % (or what is it?) of the positions actually are supposed to be within that radius and almost all of them should be at least pretty close, whereas the receiver almost never is at the given position that is stored in GPX today. In addition, there is no way today to even guess how large the error is. > If you wanted to encode it in an extension, knowing that it's useful > relative only in a small domain, that's fine. Ok, fine! > Key word: "estimated". Indeed! As is the position. /ragge
tt+smartcomsoftware.com on Mon Feb 28 03:18:47 2011 (link), replying to msg
Note that different receiver manufacturers use different figures, e.g. historically many have used 95%, but others user 67%, 50%... Also, the period of time that the position is measured over has a significant effect too. Tim <http://www.twitter.com/smartcom_tim> Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of ragge0 Sent: 28 February 2011 11:11 To: gpsxml+yahoogroups.com Subject: [gpsxml] Re: Accuracy/Estimated Position Error --- In gpsxml+yahoogroups.com <mailto:gpsxml%40yahoogroups.com> , Robert Lipe <robertlipe+...> wrote: > > On Thu, Feb 24, 2011 at 2:13 PM, ragge0 <ragge+...> wrote: > > > > > Hello, > > > > Is there a recommended way to represent Accuracy or EPE (estimated position > > error) in distance (meters) in GPX? > > > > As GPX is about exchanging GPS data between vendors there is no standard > representation of EPE in the industry (most vendors won't even document how > it's computed, it's not meaningful to transfer, so it's not represented in > GPX. I am not talking about the EPE value (some strange vendor specific 1-20 value, agreed), but the error in meters (or feet), which many vendors do provide. This value is just as much an approximation as the position, and gives the position much higher value since 95 % (or what is it?) of the positions actually are supposed to be within that radius and almost all of them should be at least pretty close, whereas the receiver almost never is at the given position that is stored in GPX today. In addition, there is no way today to even guess how large the error is. > If you wanted to encode it in an extension, knowing that it's useful > relative only in a small domain, that's fine. Ok, fine! > Key word: "estimated". Indeed! As is the position. /ragge [Non-text portions of this message have been removed]
ragge+kth.se on Mon Feb 28 12:49:08 2011 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Alan" <smithalan+...> wrote: > > Isn't this discussion's about HDOP (horizontal dilution of precision), which > is supported in GPX? Well, possibly; Is there a standard way to convert between error-in-distance (as meters or feet) and the xDOPs? (Is HDOP alone the same as the horizontal error, or is it only in combination with TDOP and maybe others that you could calculate an actual distance?) /ragge
Rozzin+geekspace.com on Wed Mar 02 19:52:02 2011 (link), replying to msg
"Alan" <smithalan+bigpond.com> writes: > ragge0 <...> writes: > > "Alan" <smithalan+...> wrote: > > > > > > Isn't this discussion's about HDOP (horizontal dilution of precision), > > > which is supported in GPX? > > > > Well, possibly; Is there a standard way to convert between > > error-in-distance (as meters or feet) and the xDOPs? > > I know my GPS reports horizontal accuracy in distance, which must be either > derived from HDOP or calculated at the same time as the HDOP. > Mathematically, the HDOP is a measure of the size of the "cocked hat" > position error, but how you convert to distance is beyond my ken. GPSd apparently includes code to do this, for the cases in which a GPS unit doesn't provide all of the numbers numbers itself--c.f.: http://git.berlios.de/cgi-bin/cgit.cgi/gpsd/tree/libgpsd_core.c ... which involves scaling each of XDOP and YDOP by one of these constants ("assumption about the base error of GPS fixes in different directions"): #define H_UERE_NO_DGPS 15.0 /* meters, 95% confidence */ #define H_UERE_WITH_DGPS 3.75 /* meters, 95% confidence */ ... to get absolute lengths of position uncertainty in each dimension (radius being computed from (x, y) in the usual manner). -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
ragge+kth.se on Wed Mar 02 22:25:48 2011 (link), replying to msg
--- In gpsxml+yahoogroups.com, Joshua Judson Rosen <Rozzin+...> wrote: > > "Alan" <smithalan+...> writes: > > ragge0 <...> writes: > > > "Alan" <smithalan+> wrote: > > > > > > > > Isn't this discussion's about HDOP (horizontal dilution of precision), > > > > which is supported in GPX? > > > > > > Well, possibly; Is there a standard way to convert between > > > error-in-distance (as meters or feet) and the xDOPs? > > > > I know my GPS reports horizontal accuracy in distance, which must be either > > derived from HDOP or calculated at the same time as the HDOP. > > Mathematically, the HDOP is a measure of the size of the "cocked hat" > > position error, but how you convert to distance is beyond my ken. > > GPSd apparently includes code to do this, for the cases in which > a GPS unit doesn't provide all of the numbers numbers itself--c.f.: > > http://git.berlios.de/cgi-bin/cgit.cgi/gpsd/tree/libgpsd_core.c > > ... which involves scaling each of XDOP and YDOP by one of these constants > ("assumption about the base error of GPS fixes in different directions"): > > #define H_UERE_NO_DGPS 15.0 /* meters, 95% confidence */ > #define H_UERE_WITH_DGPS 3.75 /* meters, 95% confidence */ > > ... to get absolute lengths of position uncertainty in each dimension > (radius being computed from (x, y) in the usual manner). Very interesting! Thanks for the pointer! It also says: "* The UERE constants are our assumption about the base error of * GPS fixes in different directions." which is probably true, sine they have constants that differ only depending on if it is DGPS or GPS, and neither technique have constant errors, it is all depending on the situation and the devices involved, especially since DGPS can mean a whole scale of things in itself. If the xDOPs really could be used for this, the xDOPs should have a standardized scale that everything uses in all receiving situations, or at least different standardized scales that are used for different specified receiving situations, and that doesn't seem to be the case. The comments say more interesting things, such as the following conclusion after some interesting text (from a well known dude at SiRF): "So we cannot exactly duplicate what SiRF does internally. We'll leave HDOP alone and use our computed values for VDOP and PDOP. Note, this may have to change in the future if this code is used by a non-SiRF driver." I believe that starting to convert between the different xDOPs and errors in distance without knowing the internal workings of the receiver is really dangerous business. I believe that the only reasonable thing to do is to record whatever the receiver has calculated, and not start to calculate any new numbers from that at all in the recording process. This makes me believe that GPX really should have standardized fields for errors in distance, so that if that is what the receiver gives you, you can both record it and read it. Sure it is an estimate - but so is the position itself, as well as the xDOPs, and the error estimate is part of the solution when calculating the position, you can't really have one without the other. (Or - you could, but then only for applications that don't care about the real position but only about an estimated position as a point, pretty much like there there are applications that don't use the altitude.) /ragge
wbporter455+bellsouth.net on Wed May 04 09:23:10 2011 (link)
I am trying to start with an existing GPX file and removing waypoints which are outside an area of interest. When I write the edited file back out, neither Google Earth or Garmin MapSource can read it. Other than change or add the newline character after any grouping is closed (</etc>), I am doing nothing to the file. Are there any suggestions to help insure the file validates? Thanks in advance.
eric+myscenicdrives.com on Wed May 04 09:24:16 2011 (link)
Hi-- I've noticed that the GPX files generated by Streets and Trips uses the rtept for encoding their waypoints verses what Garmin uses is a a trk. From the documentation, these appear quite similar. While a document can have both and validate, are there things to be concerned about if I were to encode both in a single file? Thanks. Eric
markc+gps2cad.com on Wed May 04 09:25:23 2011 (link)
I am trying to build a test project that writes a .gpx file from new gps data. I've got the .gpx schema from Topografix, and i've built a "GPXType" with an xsd utility. But i can't figure out how to read / write data to the GPXtype. So i've began working with regular XML, using the topografix schema, and still am unable to build a document and populate it with gps data. My development environment is Visual Studio 2008, Visual Basic. No doubt it's due to my limited experience with this, so i'm hoping there may be some sample code or projects available. Can anyone help? thanks mark c.
tonykin+eircom.net on Wed May 04 09:45:17 2011 (link), replying to msg
You might like to try the validation procedure on http://www.topografix.com/gpx_validation.asp From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of WARREN Sent: 05 April 2011 15:38 To: gpsxml+yahoogroups.com Subject: [gpsxml] Validating existing GPX file after removing waypoints. I am trying to start with an existing GPX file and removing waypoints which are outside an area of interest. When I write the edited file back out, neither Google Earth or Garmin MapSource can read it. Other than change or add the newline character after any grouping is closed (</etc>), I am doing nothing to the file. Are there any suggestions to help insure the file validates? Thanks in advance. [Non-text portions of this message have been removed]
ajcartmell+fonant.com on Wed May 04 10:01:50 2011 (link), replying to msg
> I've noticed that the GPX files generated by Streets and Trips uses the > rtept for encoding their waypoints verses what Garmin uses is a a trk. > From the documentation, these appear quite similar. While a document can > have both and validate, are there things to be concerned about if I were > to encode both in a single file? Thanks. A route point is generally understood to be a pre-planned location along a route. A set of route points typically draws a set of straight lines from junction to junction along the planned route. A track point is generally understood to be a point actually visited while proceeding along a route. A set of track points typically draws a detailed trace of where the route actually goes, following every twist and turn. It's perfectly acceptable to have both in the same GPX file. How they are used or interpreted depends on the software or device that's reading the file. Anthony -- www.fonant.com - Quality web sites Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Amelia House, Crescent Road, Worthing, West Sussex, BN11 1QR
smithalan+bigpond.com on Wed May 04 13:58:45 2011 (link), replying to msg
It's often a problem with the text editor you're using inserting non-printing characters - Notepad is a big offender here. Try changing test editor - I use Vim (on UX and W7) _____ From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of WARREN Sent: Wednesday, 6 April 2011 12:38 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Validating existing GPX file after removing waypoints. I am trying to start with an existing GPX file and removing waypoints which are outside an area of interest. When I write the edited file back out, neither Google Earth or Garmin MapSource can read it. Other than change or add the newline character after any grouping is closed (</etc>), I am doing nothing to the file. Are there any suggestions to help insure the file validates? Thanks in advance. [Non-text portions of this message have been removed]
smithalan+bigpond.com on Wed May 04 14:08:37 2011 (link), replying to msg
You need to get your head around XML serialization. Here's some VB that I use to read GPX - I hope it helps. Public Sub LoadGPXData(ByVal fileName As String) 'Dim MyFileStream As FileStream = New FileStream(fileName, FileMode.Open) ' overcomes read-only prevention Dim MyFileStream As StreamReader = New StreamReader(fileName) Dim i As Integer = 0 'Dim dupTrack As Boolean 'For i = 0 To currentTrack - 1 ' dupTrack = (tracks(i).fileName = tracks(currentTrack).fileName) 'Next Dim timedTrack As Boolean = False ' for un-timed tracks - need start time and route speed Dim startTime As Double Dim routeSpeed As Double ' Dim Myserializer As XmlSerializer = New XmlSerializer(GetType(gpxType)) Dim mygpx As gpxType = New gpxType Try mygpx = CType(Myserializer.Deserialize(MyFileStream), gpxType) MyFileStream.Close() Catch ex As Exception MsgBox("Unable to convert the GPX file - ensure that it conforms to GPX 1.1 (http://www.topografix.com/GPX/1/1 and try again") Exit Sub End Try Dim Singletrk As trkType Dim SingletrkSeg As trksegType Dim SingletrkPt As wptType ' how many tracks? Dim trkCount As Integer = 0 Dim IGCTrkCount As Integer = 0 Dim availableTrackNames() As String Dim selectedTrackName As String = "" ReDim availableTrackNames(mygpx.trk.GetLength(0)) ' should be length-1 but found that comboBox.DataSource likes a null at the end??? For Each Singletrk In mygpx.trk If Not Singletrk.name Is Nothing Then 'GpsBabel generates multiple, un-named tracks from Plt files... so availableTrackNames(trkCount) = Singletrk.name trkCount += 1 If Singletrk.name = "PRESALTTRK" Or Singletrk.name = "GNSSALTTRK" Then IGCTrkCount += 1 End If End If _____ From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of cmarkc2001 Sent: Wednesday, 27 April 2011 8:32 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Working with .gpx files I am trying to build a test project that writes a .gpx file from new gps data. I've got the .gpx schema from Topografix, and i've built a "GPXType" with an xsd utility. But i can't figure out how to read / write data to the GPXtype. So i've began working with regular XML, using the topografix schema, and still am unable to build a document and populate it with gps data. My development environment is Visual Studio 2008, Visual Basic. No doubt it's due to my limited experience with this, so i'm hoping there may be some sample code or projects available. Can anyone help? thanks mark c. [Non-text portions of this message have been removed]
markc+gps2cad.com on Mon May 16 18:38:43 2011 (link), replying to msg
Thanks for your help on this. I was able to run and adapt the code and it worked well. What i need help with now is this: creating a blank gpx file from the topografix schema (or gpxType) and adding waypoints, routes, and tracks to it, then writing it out as a .gpx file. Do you have any help with that? thanks mark c. Phoenix --- In gpsxml+yahoogroups.com, "Alan" <smithalan+...> wrote: > > You need to get your head around XML serialization. > > Here's some VB that I use to read GPX - I hope it helps. > > > > Public Sub LoadGPXData(ByVal fileName As String) > > 'Dim MyFileStream As FileStream = New FileStream(fileName, > FileMode.Open) > > ' overcomes read-only prevention > > Dim MyFileStream As StreamReader = New StreamReader(fileName) > > Dim i As Integer = 0 > > 'Dim dupTrack As Boolean > > 'For i = 0 To currentTrack - 1 > > ' dupTrack = (tracks(i).fileName = tracks(currentTrack).fileName) > > 'Next > > Dim timedTrack As Boolean = False > > ' for un-timed tracks - need start time and route speed > > Dim startTime As Double > > Dim routeSpeed As Double > > ' > > Dim Myserializer As XmlSerializer = New > XmlSerializer(GetType(gpxType)) > > Dim mygpx As gpxType = New gpxType > > Try > > mygpx = CType(Myserializer.Deserialize(MyFileStream), gpxType) > > MyFileStream.Close() > > Catch ex As Exception > > MsgBox("Unable to convert the GPX file - ensure that it conforms > to GPX 1.1 (http://www.topografix.com/GPX/1/1 and try again") > > Exit Sub > > End Try > > Dim Singletrk As trkType > > Dim SingletrkSeg As trksegType > > Dim SingletrkPt As wptType > > ' how many tracks? > > Dim trkCount As Integer = 0 > > Dim IGCTrkCount As Integer = 0 > > Dim availableTrackNames() As String > > Dim selectedTrackName As String = "" > > ReDim availableTrackNames(mygpx.trk.GetLength(0)) ' should be > length-1 but found that comboBox.DataSource likes a null at the end??? > > For Each Singletrk In mygpx.trk > > If Not Singletrk.name Is Nothing Then 'GpsBabel generates > multiple, un-named tracks from Plt files... so > > availableTrackNames(trkCount) = Singletrk.name > > trkCount += 1 > > If Singletrk.name = "PRESALTTRK" Or Singletrk.name = > "GNSSALTTRK" Then > > IGCTrkCount += 1 > > End If > > End If > > > > _____ > > From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of > cmarkc2001 > Sent: Wednesday, 27 April 2011 8:32 AM > To: gpsxml+yahoogroups.com > Subject: [gpsxml] Working with .gpx files > > > > > > > > I am trying to build a test project that writes a .gpx file from new gps > data. I've got the .gpx schema from Topografix, and i've built a "GPXType" > with an xsd utility. But i can't figure out how to read / write data to the > GPXtype. > > So i've began working with regular XML, using the topografix schema, and > still am unable to build a document and populate it with gps data. > > My development environment is Visual Studio 2008, Visual Basic. > > No doubt it's due to my limited experience with this, so i'm hoping there > may be some sample code or projects available. Can anyone help? > > thanks > > mark c. > > > > > > [Non-text portions of this message have been removed] >
jackb+sunflower.com on Sat May 28 07:08:10 2011 (link), replying to msg
Sir If you want to send me the file I will check first to see if it is a good GPX file. I can remove the waypoints you don't want and send the file back if you like. Jack Baker USA jackb+sunflower.com From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of WARREN Sent: Tuesday, April 05, 2011 9:38 AM To: gpsxml+yahoogroups.com Subject: [gpsxml] Validating existing GPX file after removing waypoints. I am trying to start with an existing GPX file and removing waypoints which are outside an area of interest. When I write the edited file back out, neither Google Earth or Garmin MapSource can read it. Other than change or add the newline character after any grouping is closed (</etc>), I am doing nothing to the file. Are there any suggestions to help insure the file validates? Thanks in advance. [Non-text portions of this message have been removed]
eric+myscenicdrives.com on Sat May 28 07:08:24 2011 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Anthony Cartmell" <ajcartmell+...> wrote: > A route point is generally understood to be a pre-planned location along a > route. A set of route points typically draws a set of straight lines from > junction to junction along the planned route. > > A track point is generally understood to be a point actually visited while > proceeding along a route. A set of track points typically draws a detailed > trace of where the route actually goes, following every twist and turn. > > It's perfectly acceptable to have both in the same GPX file. How they are > used or interpreted depends on the software or device that's reading the > file. Thanks for clarifying! That's what I had thought, but I just wanted to be sure I wasn't overlooking anything. Eric
cizekjc+gmail.com on Tue Jun 14 09:14:07 2011 (link)
Hi everyone, I have a GPX file that currently has a track defined by waypoints (I believe somewhere in the neighborhood of 1400 of them) and that is all. I'd like to add some POI data to the file, but want to do it by distance. For example, I'd like to declare the first waypoint the beginning, and then add a POI, say... 20 miles from the beginning of the track. And another at maybe 35 miles up the track, etc,etc... I have had no problem adding POI using various GPX editors out there, but I can't find a way to add the distance up by measuring the distance between each waypoint and setting the POI based on that (well, without manually calculating the distance between each lat/long by hand and adding it!). Can anyone help me out with any ideas? Many thanks!! -James
a76574z+yahoo.com on Tue Oct 04 10:45:36 2011 (link)
Hi, is there a possibility to make the gpx namespace offline available?
mariano.calandra+gmail.com on Sat Oct 29 14:59:03 2011 (link)
The question is simple: What is the use of the segment? Why trkpt tag can't be stored directly inside track supertag? What is the concept that make useful collect a set of points inside a segment? Best regards Mariano
craig.miller+spatialminds.com on Sat Oct 29 18:02:19 2011 (link), replying to msg
Other scenarios might be because different segments need to be displayed differently, or have other distinguishing attributes. On Sat, Oct 29, 2011 at 7:45 AM, marianocal84 <mariano.calandra+gmail.com>wrote: > ** > > > The question is simple: What is the use of the segment? Why trkpt tag > can't be stored directly inside track supertag? What is the concept that > make useful collect a set of points inside a segment? > > Best regards > Mariano > > > -- Craig Miller Geospatial Software Architect SpatialMinds.com [Non-text portions of this message have been removed]
craig.miller+spatialminds.com on Sat Oct 29 18:02:23 2011 (link), replying to msg
Your taking a trip and the first segment of your route goes from your house to the bus-stop. The second segment goes from the bus-stop to downtown. Or, the first segment goes from the trailhead where you'll have lunch. The second segment goes from the lunch spot to an overlook. The third segment takes you back to the trailhead. or... Craig On Sat, Oct 29, 2011 at 7:45 AM, marianocal84 <mariano.calandra+gmail.com>wrote: > ** > > > The question is simple: What is the use of the segment? Why trkpt tag > can't be stored directly inside track supertag? What is the concept that > make useful collect a set of points inside a segment? > > Best regards > Mariano > > > -- Craig Miller Geospatial Software Architect SpatialMinds.com [Non-text portions of this message have been removed]
mariano.calandra+gmail.com on Sun Oct 30 01:59:13 2011 (link), replying to msg
In this way, who decide to close actual segment and start a new one? Who understand when I change transportation mode? I haven't seen tracker with this possibility, so previous operation will be done automatically but what is the algorithm? One of my idea was: I'm travelling, then I take a tunnel, signal is lost, so segment is closed. When I will be out of the tunnel and a new fix will happen new point will be stored inside new segment. Is a right idea? --- In gpsxml+yahoogroups.com, "Miller, Craig" <craig.miller+...> wrote: > > Your taking a trip and the first segment of your route goes from your house > to the bus-stop. The second segment goes from the bus-stop to downtown. > Craig > > > On Sat, Oct 29, 2011 at 7:45 AM, marianocal84 <mariano.calandra+...>wrote: > > > ** > > > > > > The question is simple: What is the use of the segment? Why trkpt tag > > can't be stored directly inside track supertag? What is the concept that > > make useful collect a set of points inside a segment? > > > > Best regards > > Mariano > > > > > > > > > > -- > Craig Miller > Geospatial Software Architect > SpatialMinds.com > > > [Non-text portions of this message have been removed] >
craig.miller+spatialminds.com on Sun Oct 30 02:04:45 2011 (link), replying to msg
Those are all implementation/app specific details that assume a very simple "tracker". GPX can be created by a routing engine, manually with a mouse, or with more complex data collection software. Anyway, you asked *why* and I gave you several use-cases that demonstrate where segments are a useful addition to the specification. Craig On Sun, Oct 30, 2011 at 1:59 AM, marianocal84 <mariano.calandra+gmail.com>wrote: > ** > > > In this way, who decide to close actual segment and start a new one? Who > understand when I change transportation mode? I haven't seen tracker with > this possibility, so previous operation will be done automatically but what > is the algorithm? > > One of my idea was: I'm travelling, then I take a tunnel, signal is lost, > so segment is closed. When I will be out of the tunnel and a new fix will > happen new point will be stored inside new segment. Is a right idea? > > > --- In gpsxml+yahoogroups.com, "Miller, Craig" <craig.miller+...> wrote: > > > > Your taking a trip and the first segment of your route goes from your > house > > to the bus-stop. The second segment goes from the bus-stop to downtown. > > > Craig > > > > > > On Sat, Oct 29, 2011 at 7:45 AM, marianocal84 <mariano.calandra+ > ...>wrote: > > > > > ** > > > > > > > > > > The question is simple: What is the use of the segment? Why trkpt tag > > > can't be stored directly inside track supertag? What is the concept > that > > > make useful collect a set of points inside a segment? > > > > > > Best regards > > > Mariano > > > > > > > > > > > > > > > > > -- > > Craig Miller > > Geospatial Software Architect > > SpatialMinds.com > > > > > > [Non-text portions of this message have been removed] > > > > > -- Craig Miller Geospatial Software Architect SpatialMinds.com [Non-text portions of this message have been removed]
oileanach+gmail.com on Sun Oct 30 08:06:26 2011 (link)
There is at least one tracking tool with this capability. I read recently of a university project somewhere in California (searching left as an exercise for the reader) which uses the smartphone's accelerometer to detect vibration patterns unique to the mode. Apparently you can distinguish among bus, cycling, walking, rail and so on fairly well. I can't recall but it may also have used sound to aid in this detection of mode. At any rate you are correct of course that GPS is lost in a subway for instance, but through the mode detection you can separate out wait time from riding time and so on, and you can get the entry/exit stop locations from the loss/gain of GPS. On Sun, Oct 30, 2011 at 1:59 AM, marianocal84 <mariano.calandra+gmail.com> wrote: > In this way, who decide to close actual segment and start a new one? Who > understand when I change transportation mode? I haven't seen tracker with > this possibility, so previous operation will be done automatically but what > is the algorithm? > > One of my idea was: I'm travelling, then I take a tunnel, signal is lost, > so segment is closed. When I will be out of the tunnel and a new fix will > happen new point will be stored inside new segment. Is a right idea? -- "Give a man a piece of working code and you solve his problem. Teach a man to write code and you give him a lifetime of new problems." - Timothy J. Luoma [Non-text portions of this message have been removed]
egroups+topografix.com on Mon Oct 31 13:43:22 2011 (link), replying to msg
Hello, Sunday, October 30, 2011, 4:59:12 AM, marianocal84 wrote: > One of my idea was: I'm travelling, then I take a tunnel, signal is > lost, so segment is closed. When I will be out of the tunnel and a > new fix will happen new point will be stored inside new segment. Is a right idea? That was the original reason that <trkseg> was included in GPX. Garmin GPS tracklogs had a flag that signified that signal was lost and regained, so that would trigger a new segment in GPX. Many GPX implementations don't draw a line between the end of a segment and the start of the next. Thanks to Craig Miller for pointing out other uses, and the fact that all of this is implementation-specific. -- Dan Foster
pauleyc+yahoo.com on Fri Nov 04 06:25:51 2011 (link)
Hi gpsxml yahoo group, I was working on a project using gpx data stored in a mysql database and I thought I'd share. http://www.gpxdb.org/ I built a java middle tier and have exposed many of the CRUD functionality in a webapp for it, which I intend to share as well, probly' in a git project once its clean enough to put my name on it. I've been trolling for a PHP developer to put a project together (hopefully w/Zend framework), but haven't had any serious takers yet. BuildItWithMe http://builditwith.me/idea/qLIL Cheers, Chris
tacman+gmail.com on Mon Nov 07 15:51:27 2011 (link)
I'm working on the software for a geo-enabled panoramic camera system and would like to use GPX as our internal format for all the obvious reasons. Have pitch, tilt and heading been accepted into the GPX 1.1 standard? I'm reading through old messages like the thread here: http://tech.groups.yahoo.com/group/gpsxml/message/2049 and wondering what the status is. If so, is the proper way to add that data like this: <trkpt lat="49.992008258092" lon="8.6638164208806"><ele>186.8248622</ele> <time>2011-04-18T10:43:42Z</time> <pitch>-9</pitch> <tilt>0</tilt> <heading>186</heading> </trkpt> If the solution is to use custom extensions, can someone point me to an example of how to add it? Thanks! Tac
sylmarino+gmail.com on Thu Nov 10 10:21:11 2011 (link)
I'm having an issue with our site upload for GPX files over 3MB. I only have a few of these files. Any thoughts on how / where I can get some GPX files that are over 3MB to test with?
robertlipe+gmail.com on Thu Nov 10 10:24:38 2011 (link), replying to msg
No, they are not part of GPX 1.1. Interest in 1.2 fizzled. You'll have to do it as an extension. You can see the output of GPX writers by Topografix (ExpertGPS) or Garmin to see how to do extensions. On Mon, Nov 7, 2011 at 5:47 PM, tacman1123 <tacman+gmail.com> wrote: > I'm working on the software for a geo-enabled panoramic camera system and > would like to use GPX as our internal format for all the obvious reasons. > > Have pitch, tilt and heading been accepted into the GPX 1.1 standard? I'm > reading through old messages like the thread here: > > http://tech.groups.yahoo.com/group/gpsxml/message/2049 > > and wondering what the status is. If so, is the proper way to add that > data like this: > > <trkpt lat="49.992008258092" lon="8.6638164208806"><ele>186.8248622</ele> > <time>2011-04-18T10:43:42Z</time> > <pitch>-9</pitch> > <tilt>0</tilt> > <heading>186</heading> > </trkpt> > > If the solution is to use custom extensions, can someone point me to an > example of how to add it? > > Thanks! > > Tac > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
robertlipe+gmail.com on Thu Nov 10 10:28:42 2011 (link), replying to msg
If you're having problems with file upload, it's unlikely that the contents of the file have anything to do with it. Since you don't care about the validity, you can fill it with nonsense or just duplicate the inside of any GPX repeatedly. GPSBabel can generate random points. gpsbabel -i random,points=100000 -f ignored -o gpx -F blah.gpx comes in around 18MB, for example. On Thu, Nov 10, 2011 at 9:34 AM, sylmarinobia123 <sylmarino+gmail.com>wrote: > I'm having an issue with our site upload for GPX files over 3MB. I only > have a few of these files. Any thoughts on how / where I can get some GPX > files that are over 3MB to test with? > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
focareta+yahoo.it on Tue Nov 22 09:42:25 2011 (link)
Hello, I'm new to the forum! I wanted to know if there is a library or example in actionscript 3 to create a gpx file. Can you help me please? Thanks Michele
rubbish+dark-reality.de on Mon Nov 28 08:48:20 2011 (link)
Hey all, I'm currently working on "yet another navigation app" and I'm trying to get a hold on how to export (and import) navigation data to and from other, and my own, application. Basically the docs and examples for GPX are pretty clear, which means that I can use <rte> for the routes, <rtept> for turn points, and <wpt> for waypoints. I don't think I should use <trk> when creating navigational data. So far, so good. But now it get's confusing: People usually define a route by setting up "waypoints" (start, end, visit in between). Any application than calculates: - a set of "turn points" - a pre-calculated, detailed track following the roads between those turn points So what we get is: - user defined waypoints (start, end, visit in between) - calculated turn points - calculated "route" points (junctions with less than 3 roads, so no "turn" is necessary) I guess the waypoints could be stored as <wpt> in the file. This leads to some questions, and I'd like to clarify if there's something "in the format" to handle this, or if everybody just uses "workarounds" (what seems to be what MapSource is doing): 1. if waypoints are stored in the "top level" of the file, how to assign the waypoints to the routes within the same file? - idea: if there are 3 routes in the file, there should be 4 waypoints, so the routes describe what's going on between the waypoints? I have some Garmin files that are exactly the opposite, 3 waypoints, 4 routes. They obviously do something different. Also it's easy to see that Garmin/MapSource handles this completely different, they use <rtept> as waypoints. No idea what the <wpt> exactly represent. 2. there's always a level "below" the turn points, which is the more detailed track BETWEEN the turn points. Garmin seems to use extensions to add a point list to each <rtept>, describing those pre-calculated "track" to display without recalculation. - is there any more "standard" way in gpx 1.1 to do this? I'm pretty much puzzled because MapSource is doing this all non-standard and I'm trying to figure out if they are just trying to be special, or if there really is no way to fit this use case perfectly into GPX. I'd like to try to make my application "talkative" to other applications. Thanks in advance :) - Lars
menjaraz+yahoo.fr on Mon Nov 28 08:48:32 2011 (link)
Hello every body, I've created then new Delphi folder for any delphi source code related to gpx. Thanx.
robertlipe+gmail.com on Mon Nov 28 09:29:26 2011 (link), replying to msg
> > 1. if waypoints are stored in the "top level" of the file, how to assign > the waypoints to the routes within the same file? - idea: if there are 3 routes in the file, there should be 4 waypoints, so > the routes describe what's going on There's no reason that start, stop, and "scheduled lunchbreak" can't all be routepoints. It's a perfectly reasonable way to express what you're describing. > between the waypoints? I have some Garmin files that are exactly the > opposite, 3 waypoints, 4 routes. They obviously do something different. > Also it's easy to see that Garmin/MapSource handles this completely > different, they use <rtept> as waypoints. No idea what the <wpt> exactly > represent. > Routes and Waypoints can be completely independent in GPX. You may want a waypoint for "home" and you may want a routepoint in a route for "home", but you don't _have_ to have a waypoint for every routepoint. > 2. there's always a level "below" the turn points, which is the more > detailed track BETWEEN the turn points. Garmin seems to use extensions to > add a point list to each <rtept>, describing those pre-calculated "track" > to display without recalculation. > - is there any more "standard" way in gpx 1.1 to do this? > As a rule: A route is where you want to go. A track is a record of where you've been. If you want to store turnpoints, a rtept is the place to do it. > I'm pretty much puzzled because MapSource is doing this all non-standard > and I'm trying to figure out if they are just trying to be special, or if > there really is no way to fit this use case perfectly into GPX. > I haven't looked at their GPX in a long time. I remember being puzzled at several of their extensions. RJL [Non-text portions of this message have been removed]
rubbish+dark-reality.de on Mon Nov 28 10:15:17 2011 (link), replying to msg
Robert, thanks for your reply; I understand your point and it makes sense. So, in a nutshell, I should stick to <rte> and <rtept>. But I'd like to somehow differentiate between the user-defined points ("I want to be here while travelling") and the calculated turns ("you need to be here/turn here to reach your target"), plus the "turns" that are not even turns for the driver, but just turns of the road (non-junctions). Those are at least three different types. Is there a standard to handle this? Garmin's extensions solve this like below (abbreviated). They add an extension that stores the "detailed" road to each rtept, while the rtept itself only refers to the "waypoints" that have been defined manually by the user. Turns vs. Junctions seem to be coded in the extension types. Kind of puzzling, but a solution to exactly my question... I just don't like to follow proprietary enhancements. - Lars ********* example ************ <rte> <name>XX 1</name> <rtept lat="60.216792086139321" lon="24.974595559760928"> <extensions> <gpxx:RoutePointExtension xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3"> <gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass> <gpxx:rpt lat="60.216836929321289" lon="24.974713325500488"/> <gpxx:rpt lat="60.217609405517578" lon="24.975700378417969"/> <gpxx:rpt lat="60.218081474304199" lon="24.97642993927002"/> </gpxx:RoutePointExtension> </extensions> </rtept> <rtept lat="60.222029685974121" lon="24.984884262084961"> <name>7923</name> --- In gpsxml+yahoogroups.com, Robert Lipe <robertlipe+...> wrote: > > > > > 1. if waypoints are stored in the "top level" of the file, how to assign > > the waypoints to the routes within the same file? > > - idea: if there are 3 routes in the file, there should be 4 waypoints, so > > the routes describe what's going on > > > There's no reason that start, stop, and "scheduled lunchbreak" can't all be > routepoints. It's a perfectly reasonable way to express what you're > describing. > > > > between the waypoints? I have some Garmin files that are exactly the > > opposite, 3 waypoints, 4 routes. They obviously do something different. > > Also it's easy to see that Garmin/MapSource handles this completely > > different, they use <rtept> as waypoints. No idea what the <wpt> exactly > > represent. > > > > Routes and Waypoints can be completely independent in GPX. You may want a > waypoint for "home" and you may want a routepoint in a route for "home", > but you don't _have_ to have a waypoint for every routepoint. > > > > 2. there's always a level "below" the turn points, which is the more > > detailed track BETWEEN the turn points. Garmin seems to use extensions to > > add a point list to each <rtept>, describing those pre-calculated "track" > > to display without recalculation. > > - is there any more "standard" way in gpx 1.1 to do this? > > > > As a rule: A route is where you want to go. A track is a record of where > you've been. > > If you want to store turnpoints, a rtept is the place to do it. > > > > I'm pretty much puzzled because MapSource is doing this all non-standard > > and I'm trying to figure out if they are just trying to be special, or if > > there really is no way to fit this use case perfectly into GPX. > > > > I haven't looked at their GPX in a long time. I remember being puzzled at > several of their extensions. > > RJL > > > [Non-text portions of this message have been removed] >
robertlipe+gmail.com on Mon Nov 28 10:48:39 2011 (link), replying to msg
On Mon, Nov 28, 2011 at 12:15 PM, largegreenwood <rubbish+dark-reality.de>wrote: > Robert, > > thanks for your reply; I understand your point and it makes sense. So, in > a nutshell, I should stick to <rte> and <rtept>. > > But I'd like to somehow differentiate between the user-defined points ("I > want to be here while travelling") and the calculated turns ("you need to > be here/turn here to reach your target"), plus the "turns" that are not > even turns for the driver, but just turns of the road (non-junctions). > Those are at least three different types. Is there a standard to handle > this? > If the first is part of a route, it's just another routepoint. If it's just a place, it's a waypoint. Most GPS-like substances don't really distinguish between your last two. So when, say, a road changes names they'll announce "continue straight onto Foo road" or whatever. You can differentiate them by name, by icon type, etc. and still keep it standard. As an aside, It's pretty rare to street-navigate on a device that doesn't have the road network and that's capable of doing dynamic route recalculation. So storing every turn in a route really is vanishing in usefulness. Sure, there will be things like motorcycle rallies or things that require special navigation, but be sure that your use case really is one of these. <gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass> > Yeah, that's just not funny. > <gpxx:rpt lat="60.216836929321289" lon="24.974713325500488"/> > The sub-millimeter "precision" is a nice touch, too. FWIW, I've had a few requests to add Garmin's route extensions to GPSBabel and have not done so. The "portable" part of their GPX encoding is enough for most people. RJL [Non-text portions of this message have been removed]
rubbish+dark-reality.de on Mon Nov 28 12:04:42 2011 (link), replying to msg
Robert, > Most GPS-like substances don't really distinguish between your last two. > So when, say, a road changes names they'll announce "continue straight onto > Foo road" or whatever. Well, if the road turns, it does not mean that it actually changes in any way, so this "point" might mostly necessary only to draw the route on a map. You could speak of this part of the dataset as kind of a "drawing path" between the actual route points (targets and junctions). May be something to add for GPX 1.2... *sigh* > > As an aside, It's pretty rare to street-navigate on a device that doesn't > have the road network and that's capable of doing dynamic route > recalculation. So storing every turn in a route really is vanishing in > usefulness. Sure, there will be things like motorcycle rallies or things > that require special navigation, but be sure that your use case really is > one of these. Well, as the application is all about pre-journey route planning, the main focus is pre-calculating exactly what way to drive, sharing this information even with people that don't share the same road network data and enable them to see were to drive. In a way, MapSource is used exactly for this by countless motorbike drivers all over the world. Obviously the route might be dynamically re-calculated when actually used in the field, or during the planning process, but in the planning stage it's necessary to transmit the "detail" data to other people that use different routing tools. I think the best solution will be sticking to the standard GPX capabilities, using type/icon to distinguish my points, and fine-tuning the export (what detail level should the rtept records be), and possibly add an exporter to MapSource (I'm not sure what Garmin thinks about that bit, though...). I guess this will give most flexibility for different use cases such as only export the target points, the turns, or all details. This should also make it work with Google Earth pretty well... > <gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass> > > > > Yeah, that's just not funny. It's a complete mess. Or, well it kind of makes sense, but without documentation it's just crazy. It took me a whole day to understand why I don't see the tracks I want to see when importing and/or exporting this. Best is, for MapSource to accept these "subroutes" the last point has to carry this, and exactly this, subclass - nothing else is of importance (doctype, creator, other extensions in the file): <gpxx:rpt lat="60.222029685974121" lon="24.984884262084961"> <gpxx:Subclass>01000F387F00A60F05002117000000000000</gpxx:Subclass> </gpxx:rpt> I'll have to figure out how to deal with this "exchange with Mapsource" thing later, I fear legal issues here... > FWIW, I've had a few requests to add Garmin's route extensions to GPSBabel > and have not done so. The "portable" part of their GPX encoding is enough > for most people. Yeah, I'd second that. thanks so much for your input, appreciate it! - Lars > > RJL > > > [Non-text portions of this message have been removed] >
egroups+topografix.com on Tue Jan 03 14:20:28 2012 (link)
If there are any Garmin developers or employees still on the GPX mailing list, can you identify yourselves? It seems every new GPS that Garmin releases references the Garmin extension schemas in a different way. Additionally, the newer models seem to modify files in-place without adjusting the schema and namespace declarations at the top of the GPX file. This leads to invalid GPX files that make reference to a schema that hasn't been declared in the file. If anyone in Garmin-land is listening, can we talk about this? Here's just one example: two different models use gpxx: to refer to two completely different schemas. etrex 10: xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:wptx1="http://www.garmin.com/xmlschemas/WaypointExtension/v1" Oregon 550: xmlns:gpxx="http://www.garmin.com/xmlschemas/WaypointExtension/v1" xmlns:gpxtrx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v1"
smithalan+bigpond.com on Thu Jan 05 19:17:34 2012 (link), replying to msg
I'm looking for an Android app for logging my aircraft's attitude (heading, pitch, roll from its gyro sensors) and position (lat lon, alt from its GPS), storing and exporting the data (format preferably in gpx or NMEA but not critical). Ultimately I want to analyse the data on my PC. Does anyone know of such a one - there are thousands of navigation apps, and scouring each is doing my head in! Cheers
jhedmonton+hotmail.com on Thu Jan 05 21:05:57 2012 (link)
Hi Alan, don't know an Android app, but we just released HeliGPS, Windows based software for aerial applications. I will store most of what you are asking for. Pitch and roll could easily be added... Regards, Johannes www.heligps.com ----- Original Message ----- From: Alan To: gpsxml+yahoogroups.com Sent: Thursday, January 05, 2012 8:17 PM Subject: [gpsxml] Android aircraft data logging app. I'm looking for an Android app for logging my aircraft's attitude (heading, pitch, roll from its gyro sensors) and position (lat lon, alt from its GPS), storing and exporting the data (format preferably in gpx or NMEA but not critical). Ultimately I want to analyse the data on my PC. Does anyone know of such a one - there are thousands of navigation apps, and scouring each is doing my head in! Cheers [Non-text portions of this message have been removed]
falk+efalk.org on Mon Jan 09 15:01:32 2012 (link), replying to msg
--- In gpsxml+yahoogroups.com, "Alan" <smithalan+...> wrote: > > > I'm looking for an Android app for logging my aircraft's attitude (heading, > pitch, roll from its gyro sensors) and position (lat lon, alt from its GPS), Interested pilots should contact me via direct message; I could use a couple of alpha testers for a project that does what you want. -ed falk
sailinxtc+hotmail.com on Sun Jan 22 17:42:56 2012 (link)
how to read a garmin gpx Track without and existing program like google earth, base camp etc... I have an application I developed in MS Access and can display .jpeg, .bmp .gif etc...but would like to read the .gpx file directly without converting it to a .jpg etc... Any direction would be great
gpxsearch+fahrradspass.de on Mon Jan 23 14:53:02 2012 (link)
Hello sailinxtc, I have written an online editor which is able to display GPX file contents: http://www.fahrradspass.de/Editor/ Not sure what you are looking for. But maybe it helps. Kind regards Bernd
wbporter455+bellsouth.net on Tue Jan 24 12:23:43 2012 (link)
I can't handle a raw gpx file, but if it has been read into something like MapSource and formatted with new line characters, it can be read into my web page via the clipboard.� It will then highlight the points closest to a given set of coordinates. http://home.comcast.net/~wporter211/realsite/neargpx.htm That may not be what you are looking for, but you will need something to display the file and glean the information you need. [Non-text portions of this message have been removed]
redroosterfarm+yahoo.com on Wed Jan 25 14:03:15 2012 (link)
My new Windows Phone app which does GPS tracking and waypoint routing needs some beta testers. One of its features is importing and export GPX files. If you enjoy your Windows Phone and are interested, send an email to support+walk-run-bike-drive.com Regards, Rick
michaelfantonial2+yahoo.com on Thu Feb 16 07:09:08 2012 (link)
Hi, can you please give me or teach me the steps on how to input/load gpx file onto the google earth.. rply asap please!!!
robertlipe+gmail.com on Thu Feb 16 07:27:57 2012 (link), replying to msg
Drag and drop into Earth. Done. Or you can choose a GPX from from File->Open if that whole draggy droppy thing isn't for you. It should work for any (valid) GPX file. If you have wildly expressive GPX content like multimedia in balloons, you'll get better results from crafting your own KML but for the huge majority of the cases it works great. It even knows about the Geocaching extensions to GPX and handles those specially. RJL (The author of the code that does the work described above.) On Sat, Feb 11, 2012 at 5:20 PM, Michael <michaelfantonial2+yahoo.com>wrote: > Hi, can you please give me or teach me the steps on how to input/load gpx > file onto the google earth.. > > rply asap please!!! > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
alanb+barasch.com on Wed Mar 07 09:19:16 2012 (link)
My brother has an extensive customer list. I was thinking of writing him an application in MS Access to track them and export GPX files. Has anyone already done this? I don't want to reinvent the wheel. My expertise is in Access and Excel VBA.
andrew.murphy+btinternet.com on Fri Mar 09 03:37:43 2012 (link)
Hi All I think the <SYM> tag needs to have its contents defined. For example, Garmin and Satmap (GPS device makes) both have a list of symbols they use, with very little overlap, so its not possible to make a single GPX file for use by both of them If the GPX spec could have a list of symbols, then everyone would know which symbols to support. Basically, a list of icon names is needed, covering each use of GPS info (walking sailing flying surveying sailing geocaching etc.) In my own case, I'd like to use numbers, e.g. <sym>Point 2</sym>, but to do this, I need to know that "Point 2" is supported by device makers. Andrew
craig.miller+spatialminds.com on Fri Mar 09 06:33:26 2012 (link), replying to msg
I've observed the same thing in my app. The only thing I'd add is that custom symbols could be allowed by supporting SVG in the same GPX file. As long as the symbol is defined as a standard, or inside the same GPX file, it would work. Craig On Fri, Mar 9, 2012 at 2:30 AM, andrew.murphy+btinternet.com < andrew.murphy+btinternet.com> wrote: > ** > > > Hi All > > I think the <SYM> tag needs to have its contents defined. > > For example, Garmin and Satmap (GPS device makes) both have a list of > symbols they use, with very little overlap, so its not possible to make a > single GPX file for use by both of them > > If the GPX spec could have a list of symbols, then everyone would know > which symbols to support. > > Basically, a list of icon names is needed, covering each use of GPS info > (walking sailing flying surveying sailing geocaching etc.) > > In my own case, I'd like to use numbers, e.g. <sym>Point 2</sym>, but to > do this, I need to know that "Point 2" is supported by device makers. > > Andrew > > > -- Craig Miller Geospatial Software Architect http://spatialminds.com [Non-text portions of this message have been removed]
robertlipe+gmail.com on Fri Mar 09 07:09:34 2012 (link), replying to msg
This was debated a lot during the formation of the spec. It's a really hard problem to solve in the general case. A Garmin GPS might have "House" while a Magellan might have "Residence". They might be represented on the devices themselves as numbers. You really do have to rely on software to know enough about the target device to customize it. Representing an icon as a bitmap or SVG or PDF or whatever is really problematic as it reduces interoperability to near zero. Yes, if you know you're rendering that GPX into a web browser that might be convenient but if you're copying it to a handset or expecting, say, GPSBabel or EasyGPS to know "Hey, that's a picture of a house - let me convert that that the word 'house'" when I send it to that device, that's pretty optimistic. Now that we have GPSes that take GPX natively, if you're looking to take advantage of specific features of specific devices, you really do have to know about the devices and that includes the icon names, waypoint name lengths, etc. RJL On Fri, Mar 9, 2012 at 8:33 AM, Miller, Craig <craig.miller+spatialminds.com > wrote: > I've observed the same thing in my app. The only thing I'd add is that > custom symbols could be allowed by supporting SVG in the same GPX file. As > long as the symbol is defined as a standard, or inside the same GPX file, > it would work. > > Craig > > On Fri, Mar 9, 2012 at 2:30 AM, andrew.murphy+btinternet.com < > andrew.murphy+btinternet.com> wrote: > > > ** > > > > > > Hi All > > > > I think the <SYM> tag needs to have its contents defined. > > > > For example, Garmin and Satmap (GPS device makes) both have a list of > > symbols they use, with very little overlap, so its not possible to make a > > single GPX file for use by both of them > > > > If the GPX spec could have a list of symbols, then everyone would know > > which symbols to support. > > > > Basically, a list of icon names is needed, covering each use of GPS info > > (walking sailing flying surveying sailing geocaching etc.) > > > > In my own case, I'd like to use numbers, e.g. <sym>Point 2</sym>, but to > > do this, I need to know that "Point 2" is supported by device makers. > > > > Andrew > > > > > > > > > > -- > Craig Miller > Geospatial Software Architect > http://spatialminds.com > > > [Non-text portions of this message have been removed] > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
craig.miller+spatialminds.com on Fri Mar 09 08:00:36 2012 (link), replying to msg
SVG is XML. In a next generation specification, embedding an SVG file into the GPX is a very simple way to solve the cross device interoperability problem that exists in the current specification. It would optionally require new devices to support rendering SVG. Optionally because the symbols would still have a "name" field, allowing for backward compatibility with existing devices. The beauty of this approach is that everything needed to render the GPX file is included inside. This is the same approach that SVG itself uses. You can either name a typeface, or you can embed the geometry of the text into the SVG (if the typeface in use might not be on the destination platform). It works well. Craig On Fri, Mar 9, 2012 at 7:09 AM, Robert Lipe <robertlipe+gmail.com> wrote: > ** > > > This was debated a lot during the formation of the spec. It's a really > hard problem to solve in the general case. > > A Garmin GPS might have "House" while a Magellan might have "Residence". > They might be represented on the devices themselves as numbers. You > really do have to rely on software to know enough about the target device > to customize it. > > Representing an icon as a bitmap or SVG or PDF or whatever is really > problematic as it reduces interoperability to near zero. Yes, if you know > you're rendering that GPX into a web browser that might be convenient but > if you're copying it to a handset or expecting, say, GPSBabel or EasyGPS to > know "Hey, that's a picture of a house - let me convert that that the word > 'house'" when I send it to that device, that's pretty optimistic. > > Now that we have GPSes that take GPX natively, if you're looking to take > advantage of specific features of specific devices, you really do have to > know about the devices and that includes the icon names, waypoint name > lengths, etc. > > RJL > > > On Fri, Mar 9, 2012 at 8:33 AM, Miller, Craig < > craig.miller+spatialminds.com > > wrote: > > > I've observed the same thing in my app. The only thing I'd add is that > > custom symbols could be allowed by supporting SVG in the same GPX file. > As > > long as the symbol is defined as a standard, or inside the same GPX file, > > it would work. > > > > Craig > > > > On Fri, Mar 9, 2012 at 2:30 AM, andrew.murphy+btinternet.com < > > andrew.murphy+btinternet.com> wrote: > > > > > ** > > > > > > > > > > Hi All > > > > > > I think the <SYM> tag needs to have its contents defined. > > > > > > For example, Garmin and Satmap (GPS device makes) both have a list of > > > symbols they use, with very little overlap, so its not possible to > make a > > > single GPX file for use by both of them > > > > > > If the GPX spec could have a list of symbols, then everyone would know > > > which symbols to support. > > > > > > Basically, a list of icon names is needed, covering each use of GPS > info > > > (walking sailing flying surveying sailing geocaching etc.) > > > > > > In my own case, I'd like to use numbers, e.g. <sym>Point 2</sym>, but > to > > > do this, I need to know that "Point 2" is supported by device makers. > > > > > > Andrew > > > > > > > > > > > > > > > > > -- > > Craig Miller > > Geospatial Software Architect > > http://spatialminds.com > > > > > > [Non-text portions of this message have been removed] > > > > > > > > ------------------------------------ > > > > Yahoo! Groups Links > > > > > > > > > > [Non-text portions of this message have been removed] > > > -- Craig Miller Geospatial Software Architect http://spatialminds.com [Non-text portions of this message have been removed]
sipendra7+yahoo.co.in on Tue Mar 13 07:16:20 2012 (link)
I have an idea of synching the time-stamps of the GPX waypoints (being created with GPS reciever) and the video captured by the digital camera a device (having both GPS receiver and digital camera). In this way video trails can be created which would show the exact video footage corresponding to the GPS coordinates. To achieve this creation of a application for the device which binds the flow of GPS data with the video being captured at that time. Playing should be easy.When the video (having GPX data synched with it) is played then the corresponding location,altitude could be displayed as an overlay to 2D map services (like google maps,openstreetmaps,bing etc) or 3D visualization services (like NASA worldwind,google earth). Please give your suggestion on this idea its not implemented anywhere till now.It would be one step ahead of Geo-tagging.
robertlipe+gmail.com on Tue Mar 13 08:52:34 2012 (link), replying to msg
On Tue, Mar 13, 2012 at 3:08 AM, sipendra7 <sipendra7+yahoo.co.in> wrote: > I have an idea of synching the time-stamps of the GPX waypoints (being > created with GPS reciever) and the video captured by the digital camera a > device (having both GPS receiver and digital camera). > [ ... ] > Please give your suggestion on this idea its not implemented anywhere till > now.It would be one step ahead of Geo-tagging. > It's been done. http://www.gpsbabel.org/htmldoc-development/fmt_subrip.html [Non-text portions of this message have been removed]
fjrbird+gmail.com on Tue Mar 13 09:16:00 2012 (link)
Hello, I'm already working in this way and the software and the my betatester are already busy http://youtu.be/TpUoiyLFhDY Just an example to give you an idea of the possibilitys. The general idea is indeed to sync the video with the gpx data and after every X frames to check if there is a gpx trackpoint with the same timestamp. An other aproach is to implement the gps data stream directly into the video recording like videotext as the video is recorded. In thsi way you dont have to sync both data streams. With regards WIm
wolfhall+yahoo.com on Tue Apr 10 22:31:36 2012 (link)
I am curious if anyone has seen a push for standardization of the many real-time protocols to get GPS data from in-vehicle receivers to a server. I only have seen proprietary protocols such as TAIP, RAP, PVT, etc. It seems to me that there are as many protocols as device manufacturers. Customers frequently ask what standard protocols they should look for in AVL devices. Since GPX does not include server addressing and has a larger bandwidth need than some of the binary protocols I don't have a good answer for them. Does anybody have seen any standardization or something that may be worth promoting? Wolfgang
robertlipe+gmail.com on Tue Apr 10 22:41:22 2012 (link), replying to msg
Binary XML is easy if that's a problem you need to solve. I can't say it's been a topi of much discussion on this list. Garmin has PVT, but I've never even heard of the others you cite. RJL On Wed, Apr 11, 2012 at 12:12 AM, wolfhall <wolfhall+yahoo.com> wrote: > I am curious if anyone has seen a push for standardization of the many > real-time protocols to get GPS data from in-vehicle receivers to a server. > I only have seen proprietary protocols such as TAIP, RAP, PVT, etc. It > seems to me that there are as many protocols as device manufacturers. > > Customers frequently ask what standard protocols they should look for in > AVL devices. Since GPX does not include server addressing and has a larger > bandwidth need than some of the binary protocols I don't have a good answer > for them. Does anybody have seen any standardization or something that may > be worth promoting? > > Wolfgang > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
cbyh+yahoo.com on Wed May 16 06:30:38 2012 (link)
I am a bit confused about the use of <course> in GPX files. I am producing a GPS file using the 1.0 schema containing a track - here is a small part of it: <trk> <trkseg> <trkpt lat="10.311063" lon="-84.813530"> <ele>1401.10</ele> <speed>3.33</speed> <course>334.3</course> <time>2012-05-04T21:00:38Z</time> </trkpt> <trkpt lat="10.311522" lon="-84.813217"> <ele>1434.90</ele> <speed>8.64</speed> <course>46.0</course> <time>2012-05-04T21:00:48Z</time> </trkpt> As recommended I have run it through SaxCount using the command: SaxCount.exe -v=always -n -s -f myfile.gpx and it gives lots of errors like this: Error at file myfile.gpx, line 1653, char 15 Message: element 'course' is not allowed for content model '(ele?,time?,course ?,speed?,magvar?,geoidheight?,name?,cmt?,desc?,src?,url?,urlname?,sym?,type?,fix ?,sat?,hdop?,vdop?,pdop?,ageofdgpsdata?,dgpsid?,)' which seems to be saying that "course" is not an allowed element. But the schema at http://www.topografix.com/GPX/1/0/gpx.xsd contains: <xsd:element name="trkpt" minOccurs="0" maxOccurs="unbounded"><xsd:complexType><xsd:sequence><!-- elements must appear in this order --><!-- Position info --><xsd:element name="ele" type="xsd:decimal" minOccurs="0"/><xsd:element name="time" type="xsd:dateTime" minOccurs="0"/><xsd:element name="course" type="gpx:degreesType" minOccurs="0"/><xsd:element name="speed" type="xsd:decimal" minOccurs="0"/><xsd:element name="magvar" type="gpx:degreesType" minOccurs="0"/><xsd:element name="geoidheight" type="xsd:decimal" minOccurs="0"/> which definitely shows that course IS an allowed element. I can't imagine that course would be disallowed in a trkpt. Does anyone know what is wrong here?
robertlipe+gmail.com on Wed May 16 06:45:21 2012 (link), replying to msg
> > <trk> > <trkseg> > <trkpt lat="10.311063" lon="-84.813530"> > <ele>1401.10</ele> > <speed>3.33</speed> > <course>334.3</course> > <time>2012-05-04T21:00:38Z</time> > </trkpt> > [ ... ] > and it gives lots of errors like this: > > Error at file myfile.gpx, line 1653, char 15 > Message: element 'course' is not allowed for content model > '(ele?,time?,course > > ?,speed?,magvar?,geoidheight?,name?,cmt?,desc?,src?,url?,urlname?,sym?,type?,fix > ?,sat?,hdop?,vdop?,pdop?,ageofdgpsdata?,dgpsid?,)' > > which seems to be saying that "course" is not an allowed element. That's not quite what it says. It says it's not allowed where you have it. > But the schema at http://www.topografix.com/GPX/1/0/gpx.xsd contains: > > <xsd:element name="trkpt" minOccurs="0" > maxOccurs="unbounded"><xsd:complexType><xsd:sequence><!-- elements must > appear in this order --><!-- Position info --><xsd:element name="ele" > type="xsd:decimal" minOccurs="0"/><xsd:element name="time" > type="xsd:dateTime" minOccurs="0"/><xsd:element name="course" > type="gpx:degreesType" minOccurs="0"/><xsd:element name="speed" > type="xsd:decimal" minOccurs="0"/><xsd:element name="magvar" > type="gpx:degreesType" minOccurs="0"/><xsd:element name="geoidheight" > type="xsd:decimal" minOccurs="0"/> > > which definitely shows that course IS an allowed element. > See highlighted bit above. Order counts. > > I can't imagine that course would be disallowed in a trkpt. It's worth mentioning that if you're computing course from successive GPS fixes instead of measuring course, it's probably not worth putting in the GPX at all and that course is not present in 1.1 RJL [Non-text portions of this message have been removed]
ldeffenb+homeside.to on Wed May 16 06:46:15 2012 (link), replying to msg
Maybe the comment that says "elements must appear in this order" in conjunction with the fact that <course> is listed before <speed> in the schema but the opposite order in your snippet? Just guessing here, but that's what my eye caught. If that's the case, then <time> must also be before <course>, but you're good with <ele> coming first by my reading. Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32 On 5/16/2012 7:42 AM, cbyh wrote: > I am a bit confused about the use of<course> in GPX files. > > I am producing a GPS file using the 1.0 schema containing a track - here is a small part of it: > > <trk> > <trkseg> > <trkpt lat="10.311063" lon="-84.813530"> > <ele>1401.10</ele> > <speed>3.33</speed> > <course>334.3</course> > <time>2012-05-04T21:00:38Z</time> > </trkpt> > <trkpt lat="10.311522" lon="-84.813217"> > <ele>1434.90</ele> > <speed>8.64</speed> > <course>46.0</course> > <time>2012-05-04T21:00:48Z</time> > </trkpt> > > As recommended I have run it through SaxCount using the command: > > SaxCount.exe -v=always -n -s -f myfile.gpx > > and it gives lots of errors like this: > > Error at file myfile.gpx, line 1653, char 15 > Message: element 'course' is not allowed for content model '(ele?,time?,course > ?,speed?,magvar?,geoidheight?,name?,cmt?,desc?,src?,url?,urlname?,sym?,type?,fix > ?,sat?,hdop?,vdop?,pdop?,ageofdgpsdata?,dgpsid?,)' > > which seems to be saying that "course" is not an allowed element. But the schema at http://www.topografix.com/GPX/1/0/gpx.xsd contains: > > <xsd:element name="trkpt" minOccurs="0" maxOccurs="unbounded"><xsd:complexType><xsd:sequence><!-- elements must appear in this order --><!-- Position info --><xsd:element name="ele" type="xsd:decimal" minOccurs="0"/><xsd:element name="time" type="xsd:dateTime" minOccurs="0"/><xsd:element name="course" type="gpx:degreesType" minOccurs="0"/><xsd:element name="speed" type="xsd:decimal" minOccurs="0"/><xsd:element name="magvar" type="gpx:degreesType" minOccurs="0"/><xsd:element name="geoidheight" type="xsd:decimal" minOccurs="0"/> > > which definitely shows that course IS an allowed element. > > I can't imagine that course would be disallowed in a trkpt. > > Does anyone know what is wrong here? > > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
cbyh+yahoo.com on Wed May 16 08:32:23 2012 (link), replying to msg
Thanks. I should have noticed the "<!-- elements must appear in this order -->". I'll give it another try using the correct order. > course is not present in 1.1 I just checked and you are right - course and speed are missing from the 1.1 schema. That seems strange. Why have they been taken out?
robertlipe+gmail.com on Wed May 16 08:33:45 2012 (link), replying to msg
> > course is not present in 1.1 > > I just checked and you are right - course and speed are missing from the > 1.1 schema. That seems strange. > > Why have they been taken out? They were removed by mistake. By the time it was noticed, GPX was entrenched in so many devices and programs that changing it became problematic. Various proposals for standarized extensions and a GPX 1.2 haven't really gotten any traction. See the previous discussions on this: http://tech.groups.yahoo.com/group/gpsxml/message/650 http://tech.groups.yahoo.com/group/gpsxml/message/746 http://tech.groups.yahoo.com/group/gpsxml/message/984 http://tech.groups.yahoo.com/group/gpsxml/message/1139 http://tech.groups.yahoo.com/group/gpsxml/message/1996 GPX is a victim of its own success. RJL [Non-text portions of this message have been removed]
cbyh+yahoo.com on Wed May 16 08:46:31 2012 (link), replying to msg
> They were removed by mistake. Wow! Thanks for the links to the other threads. So I guess if I want to use speed and course then I will have to stick with the 1.0 schema. Is there a brief description somewhere of the differences and added features of 1.1 compared to 1.0 ?
robertlipe+gmail.com on Wed May 16 08:53:03 2012 (link), replying to msg
> > So I guess if I want to use speed and course then I will have to stick > with the 1.0 schema. If you actually need them (many don't) your options are 1.0 or to create/use an extension as cited. > Is there a brief description somewhere of the differences and added > features of 1.1 compared to 1.0 ? There is probably discussion in the archives from when we created 1.1. The schemas are authoritative, but from the top of my head, <metadata> moved, <link> was changed to allow multiple links and introduce an incompatible syntax, and <extension> was added throughout. [Non-text portions of this message have been removed]
cbyh+yahoo.com on Wed May 16 09:19:19 2012 (link), replying to msg
Thanks. So for fairly simple use, probably better to stick with 1.0.
occidental+gmx.net on Wed May 16 14:49:37 2012 (link)
Hi I am new in your group and need probably only two really little information. INFORMATION no. 1 required: I will describe a complex travelling course on bike in more than 1 segment (part of course on the continent, part of course on a first island, part of course on the next island, rest of course on the continent). I can easily make the planing of my course in a completely usual routing application, for example http://bikeroutetoaster.com/Course.aspx as it gives me the possibility to interchange the view under 6 different land maps / land photography systems and have 2 way WAY 1 : I make my planing separately for my 4 land courses and try after that to merge them WAY 2 : I consider the course is only one course and draw a line at the place where the two boot passages happens and erase after that the two lines. how to realize the 2 mode (merging or erasing) manually to get a unique gpx file so that above application (or an other ...) can interpret my intentions correctly, draw the right course without water passages and calculate the right distance? INFORMATION no. 2 required: I will describe all courses of a biking week (5 day + 1 ) on a map. each day a course from a central point in the same country (as the spokes of a wheel) and a round road around this point. I will process a first set of gpx files using above application and merge them all into a big gpx file if possible so that if I reintroduce the merged file the application produces for me an overview of the 6 courses. I did try it with 2 gpx test file. I did copy manually the content of the second into the first after at the end of the file just before the commands < / t r k > < / g p x > I did use from the second file only the content from < t r k s e g > etc ... to < / t r k s e g > It works but the application draw a line between the 2 end / start points of each segment and calculate the wrong distance including this line. How to avoid it? Thank you for each help! (PS: as you see my English is bad, please don't use typical slangs in your answer ;-) . it would make the comprehension very more difficult!) kind regards
Rozzin+geekspace.com on Sat May 19 15:31:08 2012 (link), replying to msg
"cbyh" <cbyh+yahoo.com> writes: > > Thanks. So for fairly simple use, probably better to stick with 1.0. We use GPX 1.1 + Garmin's TrackPointExtensionv2 schema in FoxtrotGPS, which gets us support for speed, course, and a number of other useful parameters too: http://www8.garmin.com/xmlschemas/TrackPointExtensionv2.xsd -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
Yahoo+hornby.me.uk on Sun May 20 08:49:16 2012 (link), replying to msg
--- In gpsxml+yahoogroups.com, "cbyh" <cbyh+...> wrote: > I am producing a GPS file using the 1.0 schema containing a track - here is a small part of it: > > <trkpt lat="10.311063" lon="-84.813530"> > <ele>1401.10</ele> > <speed>3.33</speed> > <course>334.3</course> > <time>2012-05-04T21:00:38Z</time> > </trkpt> ... But the schema at http://www.topografix.com/GPX/1/0/gpx.xsd contains: > <xsd:sequence><!-- elements must appear in this order --><!-- Position info --><xsd:element name="ele" type="xsd:decimal" minOccurs="0"/><xsd:element name="time" type="xsd:dateTime" minOccurs="0"/><xsd:element name="course" type="gpx:degreesType" minOccurs="0"/><xsd:element name="speed" type="xsd:decimal" minOccurs="0"/><xsd:element name="magvar" type="gpx:degreesType" minOccurs="0"/><xsd:element name="geoidheight" type="xsd:decimal" minOccurs="0"/> > You've got <ele><speed><course><time>... when you need <ele><time><course><speed> [Non-text portions of this message have been removed]
procarrie+yahoo.com on Wed Jun 06 06:16:55 2012 (link)
Hi all. I have a problem about GPX schema. I want to use "link" tag and "extensions" tag. But when I tried to create GPX file including link tag on Altova XMLSpy, error message was appeared "This file is not valid! If you save the file in its current state, other XML processors may have a problem opening the file". I checked gpx.xsd supported by XMLSpy, there's no link tag. It has only ele/time/magvar/geoidheight/name/cmt/desc/src/url/urlname/sym/type/fix/sat/hdop/vdop/pdop/ageofdgpsdata/dgpsid. GPX schema version is 1.1 released 2004. So is it too old? Please answer me. Thanks in advanced. Best Regards. Kevin Lee.
salcedo+yahoo.com on Thu Jun 07 06:55:16 2012 (link), replying to msg
Looks like your tool is referencing v1.0 of the schema instead of v1.1. You can take a look at both versions of the schema online http://www.topografix.com/gpx/1/0/gpx.xsd http://www.topografix.com/gpx/1/1/gpx.xsd Assuming you're talking about the wpt element, v1.1 includes a "link" element, while v1.0 includes "url". --- In gpsxml+yahoogroups.com, "procarrie" <procarrie+...> wrote: > > Hi all. > I have a problem about GPX schema. > > I want to use "link" tag and "extensions" tag. > But when I tried to create GPX file including link tag on Altova XMLSpy, > error message was appeared "This file is not valid! If you save the file in its current state, other XML processors may have a problem opening the file". > > I checked gpx.xsd supported by XMLSpy, there's no link tag. > It has only ele/time/magvar/geoidheight/name/cmt/desc/src/url/urlname/sym/type/fix/sat/hdop/vdop/pdop/ageofdgpsdata/dgpsid. > > GPX schema version is 1.1 released 2004. So is it too old? > Please answer me. > > Thanks in advanced. > Best Regards. > > Kevin Lee. >
d_mcgahey+yahoo.com on Fri Jun 08 07:50:24 2012 (link), replying to msg
Hi Kevin- Take a look at the Altova blog post on GPX from last March at: http://blog.altova.com/2012/03/global-positioning-of-xml.html The first two screen shots of XML snippets illustrate how Garmin implements the <link> tag on line 6 and the <extensions> tag on line 83736 in the second shot. The Garmin extensions are defined in the Garmin extensions schema referenced in line 2. You can open the extensions schema directly from: http://www.garmin.com/xmlschemas/GpxExtensionsv3.xsd I hope this helps with your project. Best regards, David McGahey Product Marketing Manager Altova, Inc. --- In gpsxml+yahoogroups.com, "procarrie" <procarrie+...> wrote: > > Hi all. > I have a problem about GPX schema. > > I want to use "link" tag and "extensions" tag. > But when I tried to create GPX file including link tag on Altova XMLSpy, > error message was appeared "This file is not valid! If you save the file in its current state, other XML processors may have a problem opening the file". > > I checked gpx.xsd supported by XMLSpy, there's no link tag. > It has only ele/time/magvar/geoidheight/name/cmt/desc/src/url/urlname/sym/type/fix/sat/hdop/vdop/pdop/ageofdgpsdata/dgpsid. > > GPX schema version is 1.1 released 2004. So is it too old? > Please answer me. > > Thanks in advanced. > Best Regards. > > Kevin Lee. >
nomad9+btinternet.com on Wed Jun 27 08:15:29 2012 (link)
Hi, I am completely new to this format and I'm trying to establish if there is a limit or advisable size (number of characters)for the name, cmt and desc elements for a waypoint entry? Any guidance would be appreciated. Cheers
robertlipe+gmail.com on Wed Jun 27 08:40:15 2012 (link), replying to msg
On Fri, Jun 15, 2012 at 5:14 AM, nomad9+btinternet.com < nomad9+btinternet.com> wrote: > Hi, > I am completely new to this format and I'm trying to establish if there is > a limit or advisable size (number of characters)for the name, cmt and desc > elements for a waypoint entry? Any guidance would be appreciated. There is not a prescribed limit in the spec as different devices have different limitations. For example, if you want to maximize your support traffic, ensure that all waypoint names are at least 4096 characters long, are not unique, and use as much of the Unicode space as possible. It really is up to the other end (the end that isn't GPX) to know about and enforce things like "number of routepoints in a route" or "must be uppercase letters and digits only". [Non-text portions of this message have been removed]
Rozzin+geekspace.com on Sun Aug 05 15:46:30 2012 (link), replying to msg
Leslie Elieff <lesliee+rogers.com> writes: > > I am a newbie web developer of 5 months. I'm still in school and > trying to figure out a final project. > > I wanted to make a website that people could go to and punch in their > location and see what stores and business where close to where they > lived. Sort of like "hey, whats around the corner? OK, so you want to make a web UI that basically hooks into a database (e.g.: a table storing name, type, lat, lon), does a simple query, and either lists or plots the results? That sounds like a pretty straight-forward project. But...: > So I'm thinking I would filter and stream the data from an GPSXML > file, and then design an interface, link up all the data and hey, I > like that idea. I'm not sure where GPX fits into this project. Are you thinking of using a GPX file (containing waypoints?) as your *database*? I guess you could do that, but it seems a little silly--from your description, it sounds like you'd probably be better off using a SQL database like PostgreSQL, MySQL, or SQLite. Unless you have a requirement that your project must involve parsing XML, even a plain text-file might actually be a better choice for a `database'--at least, it would be easier to parse. -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
simbateman+gmail.com on Fri Aug 10 12:36:38 2012 (link), replying to msg
Well there are a couple tricks to making that work. Are people really going to type in their gps coords or are they more likely to put in an address. If you are a web developer you can use the new browsers api to ask for their location, or do it as a mobile application and use the device location. The second problem is that you have to actually have a list of places near somewhere. Luckily there are services that will do that for you. But I am sure that as part of your project you are supposed to be building a database and all that jazz, not just using foursquares venues api. But what you are suggesting is a couple hour project with the right tools. At least to get to a basic prototype. Lots of time can be spent refining features and the UI. But to get a list of stuff near your location is super simple. sim --- In gpsxml+yahoogroups.com, Leslie Elieff <lesliee+...> wrote: > > Hello, > > I am a newbie web developer of 5 months. I'm still in school and > trying to figure out a final project. > > I wanted to make a website that people could go to and punch in their > location and see what stores and business where close to where they > lived. Sort of like "hey, whats around the corner? > > So I'm thinking I would filter and stream the data from an GPSXML > file, and then design an interface, link up all the data and hey, I > like that idea. > > Does anyone think this is possible to do? Never mind the only have 3 > weeks to do it, but yes, this is my query... > > Cheers > Leslie >
wbporter455+bellsouth.net on Fri Aug 10 12:36:49 2012 (link)
This might give you some ideas if you are required to read a gpx file for your data. My webpage reads a formatted gpx file (pasted from the clipboard) into a text area (created by MapSource, i.e.) and locates the closest TRACK points to the designated coordinates. By formatted, be sure the (/.....) fields (really lt & gt symbols) are followed by a line feed. Of course you will be looking at waypoints instead of trackpoints and will have to store information about each one. Regular expressions are used to identify necessary information. http://home.comcast.net/~wporter211/realsite/neargpx.htm
lesliee+rogers.com on Mon Aug 13 08:52:03 2012 (link), replying to msg
Dear Group, Thank you for all who replied, I didn't think I would get responses. lol I am onto another project now, the latter discarded. This project is much simpler within my grasp using classes with AS3. Thanks again for your answers. L --- In gpsxml+yahoogroups.com, WARREN PORTER <wbporter455+...> wrote: > > This might give you some ideas if you are required to read a gpx file for your data. My webpage reads a formatted gpx file (pasted from the clipboard) into a text area (created by MapSource, i.e.) and locates the closest TRACK points to the designated coordinates. By formatted, be sure the (/.....) fields (really lt & gt symbols) are followed by a line feed. > > Of course you will be looking at waypoints instead of trackpoints and will have to store information about each one. Regular expressions are used to identify necessary information. > > http://home.comcast.net/~wporter211/realsite/neargpx.htm >
redroosterfarm+yahoo.com on Fri Oct 05 15:31:14 2012 (link)
Hi, While not a total newbie to GPX, I am having trouble understanding custom extensions. I'm a mobile software developer and would like to write a GPX file that contains additional data elements and still be a valid GPX. Could someone point me to an example GPX file that has some custom extensions to see how it is implemented? Thanks, Richard
occidental+gmx.net on Mon Oct 08 01:06:59 2012 (link), replying to msg
Hi, In this context it would be very helpfull to get the possibility to break the gpx route (like the turtle function "hidden" does) at one or more points and begin again THE SAME course at other points to continue a route for example at a different point at the other river of the water etc. in case of using gpx files to plan routes where water, aircraft or railway transfer etc. have to be used during the performance! Regards François > > -------- Original-Nachricht -------- > Datum: Thu, 04 Oct 2012 18:15:04 -0000 > Von: "routeplannerwp" <redroosterfarm+yahoo.com> > An: gpsxml+yahoogroups.com > Betreff: [gpsxml] Example of adding a custom extension? > > > Hi, > While not a total newbie to GPX, I am having trouble understanding > custom extensions. I'm a mobile software developer and would like to > write a GPX file that contains additional data elements and still be a > valid GPX. > Could someone point me to an example GPX file that has some custom > extensions to see how it is implemented? > > Thanks, > Richard > > [Non-text portions of this message have been removed]
redroosterfarm+yahoo.com on Fri Oct 12 05:00:39 2012 (link), replying to msg
For example, I thought one could add tags like this: <extension> <MyTag> <mydata>this is the extra specific data</mydata> </MyTag> </extension> But this throws errors in the verification app SaxCount. Suggestions? Thanks, Rick --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+...> wrote: > > Hi, > While not a total newbie to GPX, I am having trouble understanding custom extensions. I'm a mobile software developer and would like to write a GPX file that contains additional data elements and still be a valid GPX. > Could someone point me to an example GPX file that has some custom extensions to see how it is implemented? > > Thanks, > Richard >
Rozzin+geekspace.com on Fri Oct 12 06:41:24 2012 (link), replying to msg
"routeplannerwp" <redroosterfarm+yahoo.com> writes: > > For example, I thought one could add tags like this: > <extension> > <MyTag> > <mydata>this is the extra specific data</mydata> > </MyTag> > </extension> > > But this throws errors in the verification app SaxCount. > Suggestions? If you want your XML to validate, then I think you need to define and use a namespace for the extension elements; there is a half-useful example of this in Wikipedia: https://en.wikipedia.org/wiki/GPS_eXchange_Format We use Garmin's TrackPointExtension in FoxtrotGPS, with an XML heading that looks like this: <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.1" creator="FoxtrotGPS 1.1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v2" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.garmin.com/xmlschemas/TrackPointExtension/v2 http://www8.garmin.com/xmlschemas/TrackPointExtensionv2.xsd"> ... and then we write the extension elements (inside trkpt elements) like this: <extensions> <gpxtpx:hr>90</gpxtpx:hr> </extensions> (note that it's "extensions"--plural; not "extension") -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))." > --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+...> wrote: > > > > Hi, > > While not a total newbie to GPX, I am having trouble understanding custom extensions. I'm a mobile software developer and would like to write a GPX file that contains additional data elements and still be a valid GPX. > > Could someone point me to an example GPX file that has some custom extensions to see how it is implemented? > > > > Thanks, > > Richard
earpmel+gmail.com on Sat Oct 13 08:41:05 2012 (link), replying to msg
I have done this successfully: <extensions> <mynamespace:mytag1>stuff</mynamespace:mytag1> <mynamespace:mytag2>more stuff</mynamespace:mytag2> </extensions> --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+...> wrote: > > For example, I thought one could add tags like this: > <extension> > <MyTag> > <mydata>this is the extra specific data</mydata> > </MyTag> > </extension> > > But this throws errors in the verification app SaxCount. > Suggestions? > Thanks, > Rick > > --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+> wrote: > > > > Hi, > > While not a total newbie to GPX, I am having trouble understanding custom extensions. I'm a mobile software developer and would like to write a GPX file that contains additional data elements and still be a valid GPX. > > Could someone point me to an example GPX file that has some custom extensions to see how it is implemented? > > > > Thanks, > > Richard > > >
redroosterfarm+yahoo.com on Mon Oct 15 11:34:09 2012 (link), replying to msg
Thank you for the suggestions. It appears I need to study how to make an .XSD?! I tried simply adding a namespace. Here is the beginning of my test GPX file. <gpx version="1.0" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0"> <name><![CDATA[Testing]]></name> <desc><![CDATA[]]></desc> <time>2012-10-10T01:11:04Z</time> <extension> <RP8:mytag1> <RP8:mydata>this is the extra program specific data</RP8:mydata> </RP8:mytag1> </extension> <wpt lat="43.102326" lon="-84.153889"> ... Running it through SAXcount gives this error: Message: no declaration found for element 'extension' Fatal Error at file C:\GPXextension/testextension.gpx, line 6, char 15 Message: prefix 'RP8' can not be resolved to namespace URI ------------- So, I still need an XSD, right? Does version "1.0" or "1.1" matter? Is that why there is a problem with element 'extension'? Thanks, Rick --- In gpsxml+yahoogroups.com, "mel_earp" <earpmel+...> wrote: > > I have done this successfully: > > <extensions> > <mynamespace:mytag1>stuff</mynamespace:mytag1> > <mynamespace:mytag2>more stuff</mynamespace:mytag2> > </extensions> > > > > --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+> wrote: > > > > For example, I thought one could add tags like this: > > <extension> > > <MyTag> > > <mydata>this is the extra specific data</mydata> > > </MyTag> > > </extension> > > > > But this throws errors in the verification app SaxCount. > > Suggestions? > > Thanks, > > Rick > > > > --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+> wrote: > > > > > > Hi, > > > While not a total newbie to GPX, I am having trouble understanding custom extensions. I'm a mobile software developer and would like to write a GPX file that contains additional data elements and still be a valid GPX. > > > Could someone point me to an example GPX file that has some custom extensions to see how it is implemented? > > > > > > Thanks, > > > Richard > > > > > >
ldeffenb+homeside.to on Mon Oct 15 12:08:20 2012 (link), replying to msg
I'm not an expert here, but someone had posted a note to make sure you noticed that it was <extensions> PLURAL. Lynn (D) - KJ4ERJ On 10/14/2012 2:59 PM, routeplannerwp wrote: > Thank you for the suggestions. It appears I need to study how to make an .XSD?! > > I tried simply adding a namespace. Here is the beginning of my test GPX file. > > <gpx version="1.0" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0"> > <name><![CDATA[Testing]]></name> > <desc><![CDATA[]]></desc> > <time>2012-10-10T01:11:04Z</time> > <extension> > <RP8:mytag1> > <RP8:mydata>this is the extra program specific data</RP8:mydata> > </RP8:mytag1> > </extension> > <wpt lat="43.102326" lon="-84.153889"> > ... > > Running it through SAXcount gives this error: > > Message: no declaration found for element 'extension' > Fatal Error at file C:\GPXextension/testextension.gpx, line 6, char 15 > Message: prefix 'RP8' can not be resolved to namespace URI > ------------- > So, I still need an XSD, right? Does version "1.0" or "1.1" matter? > Is that why there is a problem with element 'extension'? > > Thanks, > Rick > > > --- In gpsxml+yahoogroups.com, "mel_earp" <earpmel+...> wrote: >> I have done this successfully: >> >> <extensions> >> <mynamespace:mytag1>stuff</mynamespace:mytag1> >> <mynamespace:mytag2>more stuff</mynamespace:mytag2> >> </extensions> >> >> >> >> --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+> wrote: >>> For example, I thought one could add tags like this: >>> <extension> >>> <MyTag> >>> <mydata>this is the extra specific data</mydata> >>> </MyTag> >>> </extension> >>> >>> But this throws errors in the verification app SaxCount. >>> Suggestions? >>> Thanks, >>> Rick >>> >>> --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+> wrote: >>>> Hi, >>>> While not a total newbie to GPX, I am having trouble understanding custom extensions. I'm a mobile software developer and would like to write a GPX file that contains additional data elements and still be a valid GPX. >>>> Could someone point me to an example GPX file that has some custom extensions to see how it is implemented? >>>> >>>> Thanks, >>>> Richard >>>> > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
Rozzin+geekspace.com on Tue Oct 16 17:12:54 2012 (link), replying to msg
"routeplannerwp" <redroosterfarm+yahoo.com> writes: > > Thank you for the suggestions. It appears I need to study how to make an .XSD?! > > I tried simply adding a namespace. Well, not necessarily a `.xsd', but you need *some* sort of schema defined for whatever parts of the data you want to be able to validate. By definition, `validation' requires a schema--otherwise..., well, how would you determine whether your XML was valid? Unless you actually mean that you want to check for *well-formedness* rather than *validity*? Wikipedia's article on XML is a pretty good starting-point--including explanations of what both "validation" and "well-formedness" mean, as well as ways that you can define schemas if you do want XML that uses your elements to be validatable: https://en.wikipedia.org/wiki/XML Also, note that GPX element you want is "extensions" (plural), not "extension".... > Here is the beginning of my test GPX file. > > <gpx version="1.0" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0"> > <name><![CDATA[Testing]]></name> > <desc><![CDATA[]]></desc> > <time>2012-10-10T01:11:04Z</time> > <extension> > <RP8:mytag1> > <RP8:mydata>this is the extra program specific data</RP8:mydata> > </RP8:mytag1> > </extension> > <wpt lat="43.102326" lon="-84.153889"> > ... > > Running it through SAXcount gives this error: > > Message: no declaration found for element 'extension' > Fatal Error at file C:\GPXextension/testextension.gpx, line 6, char 15 > Message: prefix 'RP8' can not be resolved to namespace URI > ------------- > So, I still need an XSD, right? Does version "1.0" or "1.1" matter? > Is that why there is a problem with element 'extension'? > > Thanks, > Rick > > > --- In gpsxml+yahoogroups.com, "mel_earp" <earpmel+...> wrote: > > > > I have done this successfully: > > > > <extensions> > > <mynamespace:mytag1>stuff</mynamespace:mytag1> > > <mynamespace:mytag2>more stuff</mynamespace:mytag2> > > </extensions> > > > > > > > > --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+> wrote: > > > > > > For example, I thought one could add tags like this: > > > <extension> > > > <MyTag> > > > <mydata>this is the extra specific data</mydata> > > > </MyTag> > > > </extension> > > > > > > But this throws errors in the verification app SaxCount. > > > Suggestions? > > > Thanks, > > > Rick > > > > > > --- In gpsxml+yahoogroups.com, "routeplannerwp" <redroosterfarm+> wrote: > > > > > > > > Hi, > > > > While not a total newbie to GPX, I am having trouble understanding custom extensions. I'm a mobile software developer and would like to write a GPX file that contains additional data elements and still be a valid GPX. > > > > Could someone point me to an example GPX file that has some custom extensions to see how it is implemented? > > > > > > > > Thanks, > > > > Richard > > > > > > > > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
the.one.eleven+gmail.com on Sun Jan 13 10:13:23 2013 (link)
I was just going through the GPX 1.1 spec for the first time. It says this for rtept: <xsd:element name="rtept" type="wptType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation> A list of route points. </xsd:documentation> </xsd:annotation> </xsd:element> Isn't a rtept a *single* point, as opposed to a *list* of points? For example, the trkpt defines itself as follows: "A Track Point holds the coordinates, elevation, timestamp, and metadata for a single point in a track." That seems much more logical. I apologize if this has been brought up before. I searched the list of previous messages and found nothing. [Non-text portions of this message have been removed]
robertlipe+gmail.com on Sun Jan 13 10:16:34 2013 (link), replying to msg
Yes, that's probably effectively a typo. The "obvious" definition applies. A route is an array of routepoints, just like a track is an array of trackpoints. (Well, a track is an array of trksegs which are arrays of trackpoints...) On Sun, Jan 13, 2013 at 5:32 AM, Matt Hoover <the.one.eleven+gmail.com>wrote: > I was just going through the GPX 1.1 spec for the first time. > > It says this for rtept: > > <xsd:element name="rtept" type="wptType" minOccurs="0" > maxOccurs="unbounded"> > <xsd:annotation> > <xsd:documentation> > A list of route points. > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > Isn't a rtept a *single* point, as opposed to a *list* of points? > > For example, the trkpt defines itself as follows: > > "A Track Point holds the coordinates, elevation, timestamp, and metadata > for a single point in a track." > > That seems much more logical. > > I apologize if this has been brought up before. I searched the list of > previous messages and found nothing. > > > [Non-text portions of this message have been removed] > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
jrepetto+free.fr on Mon Jan 14 13:50:42 2013 (link)
Hello, I want to validate some GPX files. I have read the procedure on http://www.topografix.com/gpx_validation.asp . I have not found SaxCount on my system , but SAX2Count. They seem to be equivalent (but maybe I am wrong). SAX2Count -v=always -n -s -f fells_loop.gpx gives an error at each line : Error at file /tmp/fells_loop.gpx, line 2, char 5 Message: no declaration found for element 'gpx' Error at file /tmp/fells_loop.gpx, line 3, char 10 Message: attribute 'version' is not declared for element 'gpx' Error at file /tmp/fells_loop.gpx, line 4, char 10 Message: attribute 'creator' is not declared for element 'gpx' Error at file /tmp/fells_loop.gpx, line 5, char 12 Message: attribute 'xmlns:xsi' is not declared for element 'gpx' Error at file /tmp/fells_loop.gpx, line 6, char 8 Message: attribute 'xmlns' is not declared for element 'gpx' Error at file /tmp/fells_loop.gpx, line 7, char 21 Message: attribute 'xsi:schemaLocation' is not declared for element 'gpx' Error at file /tmp/fells_loop.gpx, line 8, char 6 Message: no declaration found for element 'time' Error at file /tmp/fells_loop.gpx, line 9, char 8 Message: no declaration found for element 'bounds' Error at file /tmp/fells_loop.gpx, line 9, char 16 Message: attribute 'minlat' is not declared for element 'bounds' Error at file /tmp/fells_loop.gpx, line 9, char 35 Message: attribute 'minlon' is not declared for element 'bounds' Error at file /tmp/fells_loop.gpx, line 9, char 55 Message: attribute 'maxlat' is not declared for element 'bounds' Error at file /tmp/fells_loop.gpx, line 9, char 74 Message: attribute 'maxlon' is not declared for element 'bounds' Error at file /tmp/fells_loop.gpx, line 10, char 5 Message: no declaration found for element 'wpt' Error at file /tmp/fells_loop.gpx, line 10, char 10 Message: attribute 'lat' is not declared for element 'wpt' What's wrong ? Thanks for your help, Jean-Claude
robertlipe+gmail.com on Mon Jan 14 15:35:47 2013 (link), replying to msg
On Mon, Jan 14, 2013 at 3:50 PM, Jean-Claude Repetto <jrepetto+free.fr>wrote: > http://www.topografix.com/gpx_validation.asp SAXCount uses -n -s -f to turn namespace, schema, and full validation ON. SAX2Count uses those same flags to turn it OFF. It's a bit of a needless headscrew from the Apache Xerces group, but there you go. http://xerces.apache.org/xerces-c/saxcount-3.html http://xerces.apache.org/xerces-c/sax2count-3.html Drop those three flags and you'll be validating correctly with SAX2Count. I've always used SAX2Count. I dont' really know why... [Non-text portions of this message have been removed]
phopfgartner+yahoo.com on Tue Feb 12 04:23:54 2013 (link)
I need to export all feature attributes in a GPX file. Is there a canonical way to do this and is there an accepted XSD Schema to use from within the extensions element? I could adapt the relevant parts of the KML 2.2 schema, see https://developers.google.com/kml/documentation/extendeddata, but for the sake of interoperability, I'd like to know if something in that direction already exists. Reagrds, Peter
Rozzin+geekspace.com on Thu Feb 14 10:36:31 2013 (link), replying to msg
"phopfgartner" <phopfgartner+yahoo.com> writes: > > I need to export all feature attributes in a GPX file. All feature attributes of *what*? It's hard to recommend a schema for encoding some set of attributes without having any idea what those attributes *are*.... > Is there a canonical way to do this and is there an accepted XSD > Schema to use from within the extensions element? > > I could adapt the relevant parts of the KML 2.2 schema, see https://developers.google.com/kml/documentation/extendeddata, but for the sake of interoperability, I'd like to know if something in that direction already exists. > > Reagrds, > > Peter > > > > ------------------------------------ > > Yahoo! Groups Links > > > -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
phopfgartner+yahoo.com on Tue Feb 19 08:49:11 2013 (link), replying to msg
--- In gpsxml+yahoogroups.com, Joshua Judson Rosen <Rozzin+...> wrote: > > "phopfgartner" <phopfgartner+...> writes: > > > > I need to export all feature attributes in a GPX file. > > All feature attributes of *what*? > > It's hard to recommend a schema for encoding some set of attributes > without having any idea what those attributes *are*.... > > > Is there a canonical way to do this and is there an accepted XSD > > Schema to use from within the extensions element? > > > > I could adapt the relevant parts of the KML 2.2 schema, see https://developers.google.com/kml/documentation/extendeddata, but for the sake of interoperability, I'd like to know if something in that direction already exists. > > This is the exactly the point of the ExtendedData element in KML. As an example: <ExtendedData> <Data name="GEMEINDE"> <value>MERAN</value> </Data> <Data name="COMUNE"> <value>MERANO</value> </Data> <Data name="STRASSE"> <value>REICHSTRASSE</value> </Data> <Data name="STRADA"> <value>VIA NAZIONALE</value> </Data> <Data name="HAUSNUMMER"> <value>103</value> </Data> <Data name="STR_KODEX"> <value>412</value> </Data> <Data name="GEM_KODEX"> <value>21051</value> </Data> </ExtendedData> Basically, this allows to attach any kinf of attributes to a geometry. Obviously, I could easily extractpart of the KML schema. Anyway, if something similar does already exists, I would prefer, for the sake of compatibility, prefer to use existsing schemas. Regards, Peter > > Reagrds, > > > > Peter > > > > > > > > ------------------------------------ > > > > Yahoo! Groups Links > > > > > > > > -- > "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))." >
bmar8190+bigpond.net.au on Wed Jun 05 12:53:48 2013 (link)
Hi Guys, I understand GPX has no absolute official mime type for use in emails. Is this correct? .. and if not should there not be an official one? The concern relates specifically to implementing gpx file format with iOS, where received email file attachments uses this info to determine what files will be handed to it from the email application, and what the email application can do with it. If I specify that the email attachment is ".xml" mimetype, which I think is invalid (the correct one being "xml", and send that file from one iOS device to another, iOS email app does nothing but provide the option to email the received file. If on the other hand, I specify the mimetype "text/plain", the email app with provide the option to preview it as raw text, but the file with be given the same icon as a text file. There are probably iPhone apps out there that support gpx, but can't retrieve gpx files from each others emails. Another thing that came to mind is that a track segment is invalid if it only has one track point. Some software opens a gpx file with a single track point with no error, but show nothing on the screen because you can't draw a line with one point. But users who first test a gps program could potentially produce a track log with only a single point, and try to do something with it. Cheers, Art.
robertlipe+gmail.com on Wed Jun 05 13:40:11 2013 (link), replying to msg
On Tue, Jun 4, 2013 at 9:24 PM, xaxrxtx <bmar8190+bigpond.net.au> wrote: > Hi Guys, > I understand GPX has no absolute official mime type for use in emails. > Is this correct? .. and if not should there not be an official one? > This has come up before (dig around in the archives) but I recall the prevailing answer was evenly split between "application/gpx+xml" and "using email to transfer XML data to client apps is _soooo_ 1980's" As it sounds like you control both ends of this communication, consider having the client request the GPX from your server and don't terrorize your users with file size limits, spam control, poor compression, unschedules syncs destroying battery life, etc. In short, email is a terrible medium for file transfer in current times. Another thing that came to mind is that a track segment is invalid > if it only has one track point. Some software opens a gpx file with > a single track point with no error, but show nothing on the screen > because you can't draw a line with one point. > A "line" with one point is called a point and it's a perfectly reasonable thing to try to represent. I'm not digging through the XSD right now to confirm, but don't believe the GPX spec considers that invalid. I'm pretty sure my own software will read and write trkseg with a single trkpt, but I'm equally sure in some cases it does dumb things like computing a speed or orientation of zero. > But users who first test a gps program could potentially produce a > track log with only a single point, and try to do something with it. > Which sounds reasonable. Does the XSD actually disallow this? [Non-text portions of this message have been removed]
robertlipe+gmail.com on Wed Jun 05 18:12:43 2013 (link), replying to msg
The spec generally doesn't try to compensate for bad programming. What if there is a name tag that's empty and you try to print that? That could cause a nullptr deref which evokes implementation defined behaviour - potentially including a program crash. On Jun 5, 2013 7:37 PM, "Brek" <bmar8190+bigpond.net.au> wrote: > ** > I don't know that it's explicitly disallowed, > but that I think it will cause an exception in most software for lack of > forethought. > I suspect that GPSMapedit (for example) tries to draw a line from the > valid point, > to an invalid one, and in the end, displays nothing. > > Same with iOS. No matter what the width of the line is set to, > it will display nothing, and throw an exception. > I simply disallowed it in my program. > > > [Non-text portions of this message have been removed]
yahoo+web.knobby.ws on Mon Jun 24 13:01:11 2013 (link)
Hi Background: I have used the command line with gpsbabel in the past but have not done this recently and it is not working. Now mostly working with GUI version I got a refurbished Garmin 60CSx when my died and want to put all my US waypoints into the unit. From BaseCamp I could only figure out how to output all points (file is gpx). Then went to GPSBabel to filter. Could not see how to do it in GUI version, so now to command line. cd to /Applications/GPS_Software/GPSBabelFE.app/Contents/MacOS/ ls shows a gpsbabel file Problem if you want to skip to here But running line below on the command line says "-bash: gpsbabel: command not found" gpsbabel -i gpx -f "/Users/gscar/Documents/GPS-Maps-docs/Waypoints to import to 60CSx US only 2013.06.24.z.gpx" -x polygon,file="/Users/gscar/Documents/GPS-Maps-docs/GPSBabel Filters/US-CA filter.txt" -o gpx -F "/Users/gscar/Documents/GPS-Maps-docs/WayPoints USonly.y.gpx" I have done little with the command line so many errors are possible. Also maybe there is an all together better way to do this. Thank you for any suggestions. Greg [Non-text portions of this message have been removed]
robertlipe+gmail.com on Mon Jun 24 14:07:24 2013 (link), replying to msg
/Applications/... isn't in your PATH. Either add it, or tell your shell to run it in place if that's your current directory by giving an absolute or full path, e.g. ./gpsbabel ... And what you're describing is probably easy in the GUI. I would show you how easy, but the command you are trying to run is definitely not reading or writing a Garmin device, so I can't tell you the buttons to push. This really should be on the GPSBabel or general support list, not here. On Mon, Jun 24, 2013 at 3:01 PM, gregmtnbike <yahoo+web.knobby.ws> wrote: > Hi > Background: > I have used the command line with gpsbabel in the past but have not done > this recently and it is not working. Now mostly working with GUI version > I got a refurbished Garmin 60CSx when my died and want to put all my US > waypoints into the unit. From BaseCamp I could only figure out how to > output all points (file is gpx). Then went to GPSBabel to filter. Could > not see how to do it in GUI version, so now to command line. > cd to /Applications/GPS_Software/GPSBabelFE.app/Contents/MacOS/ > ls shows a gpsbabel file > Problem if you want to skip to here > But running line below on the command line says "-bash: gpsbabel: > command not found" > gpsbabel -i gpx -f "/Users/gscar/Documents/GPS-Maps-docs/Waypoints to > import to 60CSx US only 2013.06.24.z.gpx" -x > polygon,file="/Users/gscar/Documents/GPS-Maps-docs/GPSBabel > Filters/US-CA filter.txt" -o gpx -F > "/Users/gscar/Documents/GPS-Maps-docs/WayPoints USonly.y.gpx" > I have done little with the command line so many errors are possible. > Also maybe there is an all together better way to do this. > Thank you for any suggestions. > Greg > > > [Non-text portions of this message have been removed] > > > > ------------------------------------ > > Yahoo! Groups Links > > > > [Non-text portions of this message have been removed]
hop+mrhop.com on Wed Sep 18 10:55:17 2013 (link)
What is the best way to logically determine one over the other? I know RTEPT is just another WPT. I'm trying to figure out the best way to logically store both in MySQL. Thanks for your help.
robertlipe+gmail.com on Wed Sep 18 11:48:14 2013 (link), replying to msg
A rtept is similar to a wpt, but they're not the same. A route is an ordered sequence of locations called routepts; it loses most meaning outside of the context of a route. A wpt is "just" a location and makes sense in isolation. Your question about MySQL isn't really appropriate for the GPX group. On Wed Sep 18 2013 at 12:55:20 PM, Hop <hop+mrhop.com> wrote: > What is the best way to logically determine one over the other? I know > RTEPT is just another WPT. I'm trying to figure out the best way to > logically store both in MySQL. Thanks for your help. > > > > > ------------------------------**------ > > Yahoo! Groups Links > > > > --089e0122ee322d257804e6ace14c
pauleyc+yahoo.com on Fri Sep 20 05:06:16 2013 (link), replying to msg
I used the same table structure for rtept as the wpt. I created separate tables for each, with different parent tables/FK's. Works for me. Haverseine queries against your wpt/rtept/trkpt data in the rows made it all worthwhile. Good luck.
--- In gpsxml+yahoogroups.com, <gpsxml+yahoogroups.com> wrote:What is the best way to logically determine one over the other? I know RTEPT is just another WPT. I'm trying to figure out the best way to logically store both in MySQL. Thanks for your help.
robertlipe+gmail.com on Fri Sep 20 10:44:28 2013 (link), replying to msg
Sequence matters in a route. It doesn't in a waypoint. A GPX file can contain zero or more routes, each rte can contain zero or more rtepts. So you at least need additional FKs/fields to tie ordered routepoints to routes. On Fri Sep 20 2013 at 7:06:20 AM, <pauleyc+yahoo.com> wrote: > > > I used the same table structure for rtept as the wpt. I created separate > tables for each, with different parent tables/FK's. Works for me. > Haverseine queries against your wpt/rtept/trkpt data in the rows made it > all worthwhile. Good luck. > > > --- In gpsxml+yahoogroups.com, <gpsxml+yahoogroups.com> wrote: > > What is the best way to logically determine one over the other? I know > RTEPT is just another WPT. I'm trying to figure out the best way to > logically store both in MySQL. Thanks for your help. > > > > --089e01229f86d98c1a04e6d4383c
robertlipe+gmail.com on Fri Sep 20 11:05:36 2013 (link)
Sorry, I mishandled this approval in the new (increasingly sucky) Yahoo moderator panel. On Fri Sep 20 2013 at 8:30:30 AM, Yahoo! Groups Notification < gpsxml-accept-tm4myukmlcnnnnel2v3kmodwznja+yahoogroups.com> wrote: > Thanks for the replies. Sorry for not being clear, what is the best way > to logically identify one over the other? Just looping through my sample > gpx file with: > > > > For Each wp as wptType in mygpx.wpt > > This picks up everything, both wpt and rtept > > > > How do I separate one from the other so I can logically save points to > database as either wpt or rtept? > XML tags have names and a hierarchy for a reason. rtepts are children of a rte. waypts are not. A wpt is not an rtept. Look at an actual GPX file, such as those at http://www.topografix.com/gpx_sample_files.asp and you'll see this. > --- In gpsxml+yahoogroups.com, <pauleyc+...> wrote: > > I used the same table structure for rtept as the wpt. I created separate > tables for each, with different parent tables/FK's. Works for me. > Haverseine queries against your wpt/rtept/trkpt data in the rows made it > all worthwhile. Good luck. > > > --- In gpsxml+yahoogroups.com, <gpsxml+yahoogroups.com> wrote: > > What is the best way to logically determine one over the other? I know > RTEPT is just another WPT. I'm trying to figure out the best way to > logically store both in MySQL. Thanks for your help. > > --089e0122a8127130bc04e6d484f7
hop+mrhop.com on Fri Sep 20 12:02:56 2013 (link), replying to msg
Dim Myserializer As XmlSerializer = New XmlSerializer(GetType(gpxType))
Dim mygpx As gpxType = New gpxType
mygpx = CType(Myserializer.Deserialize("test.gpx"), gpxType)
For Each wp As wptType In mygpx.wpt
With wp
LabelTest.Text += wp.name & wp.lat & wp.lon & wp.time & vbnewline
End With
Next
The above grabs even rtept waypoints. Is there away to just grab none rtept waypoints?
albert.mikolaj+yahoo.com on Tue Feb 11 11:37:20 2014 (link)
Hi, I am a total newbie in GPX. I would like to know if it is possible to add sensor information such as roll and tilt onto the gpx file. Do I need to use an extension? How is it possible to achieve? I tried to find relevant information on topografix.com but failed to find my answer. Thanks in advance. Albert
ralph+arising.com.au on Tue Feb 11 11:37:25 2014 (link)
I employ a I highly extensible xml-like format for real-time geo-data; tens of thousands of position reports are processed per second and these xml fragments (not complete documents) are user-extensible and displayed as real-time layers within my GIS product www.arising.com.au/ir-gis. Each position-report has the following types of data associated with it: . time-stamp (seconds since Unix epoch - mandatory) . latitude (degrees WGS84 - optional on events/report, mandatory of a position) . longitude (degrees WGS84 - optional on events/report, mandatory on a position) . altitude (optional) . other attribute value (optional) . which are user extensible I was thinking of saving these real-time layers as GPX (having already done KML, XML and CSV and other formats) for use in other tools and databases, but Looking at the gpx format I can't easily see how to represent my extra-attribute values in the gpx data? By way of example here is some KML generated from some simulated data where that data contains attribute names (some of which I made up to provide the idea): . date . fid - feature id . ci.csn - channel sequence number . ts - timestamp . ci.sc - source . ci.sid - source id . ci.iff - iff . la - latitude . lo - longitude . al - altitude . s - speed . h - heading . e - error term . r - range . b - bearing . q - quality factor . ci.sacc - SACC . ci.v - version . ci.cn . hp - partition . hid - partition index . ix - position index . ci.xix - extended index . ci.whos - owner . ci.car-type - type of car Converting the input data to KML: <?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2"> <Document> <name>ir-gis mapview 2014-02-11T09:36:35.74Z</name> <Snippet>Created 2014-02-11T09:36:35.74Z</Snippet> <!-- Normal track style --> <LookAt><gx:TimeSpan><begin>2014-02-11T09:36:35.74Z</begin><end>2014-02-11T0 9:36:47.36Z</end></gx:TimeSpan> <longitude>149.188850</longitude><latitude>-35.308030</latitude><altitude>10 0000.0</altitude><range>130000.000000</range> </LookAt> <Style id="cff808080_n"> <IconStyle><scale>.5</scale><Icon><href>http://earth.google.com/images/kml-i cons/track-directional/track-none.png <http://earth.google.com/images/kml-icons/track-directional/track-none.png%3 c/href%3e%3c/Icon%3e%3c/IconStyle> </href></Icon></IconStyle> <LabelStyle><scale>0</scale></LabelStyle> <LineStyle><color>ff808080</color><width>6</width></LineStyle> </Style> <Style id="cff808080_h"> <IconStyle><scale>1.2</scale><Icon><href>http://earth.google.com/images/kml- icons/track-directional/track-none.png <http://earth.google.com/images/kml-icons/track-directional/track-none.png%3 c/href%3e%3c/Icon%3e%3c/IconStyle> </href></Icon></IconStyle> <LineStyle><color>ff808080</color><width>9</width></LineStyle> </Style> <StyleMap id="cff808080"> <Pair><key>normal</key><styleUrl>#cff808080_n</styleUrl></Pair> <Pair><key>highlight</key><styleUrl>#cff808080_h</styleUrl></Pair> </StyleMap> <Schema id="schema"> <gx:SimpleArrayField name="date" type="string"><displayName>date</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="fid" type="string"><displayName>null</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.csn" type="string"><displayName>Case Notation</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ts" type="string"><displayName>timestamp</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.sc" type="string"><displayName>Source</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.sid" type="string"><displayName>Source ID</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.iff" type="string"><displayName>IFF</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="la" type="double"><displayName>latitude</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="lo" type="double"><displayName>longitude</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="al" type="double"><displayName>altitude</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="s" type="float"><displayName>Speed</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="h" type="string"><displayName>Heading</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="e" type="float"><displayName>est error</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="r" type="float"><displayName>Range</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="b" type="string"><displayName>Bearing</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="q" type="float"><displayName>quality</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.sacc" type="string"><displayName>SACC</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.v" type="string"><displayName>version</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.cn" type="string"><displayName>ci.cn</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="hp" type="string"><displayName>hp</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="hid" type="string"><displayName>hid</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ix" type="string"><displayName>ix</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.xix" type="string"><displayName>ci.xix</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.whos" type="string"><displayName>ci.whos</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.car-type" type="string"><displayName>ci.car-type</displayName></gx:SimpleArrayField> </Schema> <Folder> <name>ATC-LAYER-1</name> <Placemark><name>1392111395741.54</name><description>1392111395741.54</descr iption><styleUrl>#cff808080</styleUrl> <gx:Track><altitudeMode>absolute</altitudeMode> <when>2014-02-11T09:36:34.36Z</when> <when>2014-02-11T09:36:35.36Z</when> <gx:coord>149.185959 -35.303387 536.752800</gx:coord> <gx:coord>149.185944 -35.303410 536.752800</gx:coord> <ExtendedData><SchemaData schemaUrl="#schema"> <gx:SimpleArrayData name="date"> <gx:value>2014-02-11T09:36:34.36Z</gx:value> <gx:value>2014-02-11T09:36:35.36Z</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="fid"> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.csn"> <gx:value>RI</gx:value> <gx:value>RI</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ts"> <gx:value>1392111394362</gx:value> <gx:value>1392111395362</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.sc"> <gx:value>RAD1</gx:value> <gx:value>RAD1</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.sid"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.iff"> <gx:value>1200</gx:value> <gx:value>1200</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="la"> <gx:value>-35.303387</gx:value> <gx:value>-35.30341</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="lo"> <gx:value>149.185959</gx:value> <gx:value>149.185944</gx:value> <</gx:SimpleArrayData> <gx:SimpleArrayData name="al"> <gx:value>1761.0</gx:value> <gx:value>1761.0</gx:value> <</gx:SimpleArrayData> <gx:SimpleArrayData name="s"> <gx:value>6.1</gx:value> <gx:value>5.3</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="h"> <gx:value>209</gx:value> <gx:value>213</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="e"> <gx:value>0.0</gx:value> <gx:value>0.0</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="r"> <gx:value>0.0</gx:value> <gx:value>0.0</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="b"> <gx:value>360</gx:value> <gx:value>360</gx:value> <</gx:SimpleArrayData> <gx:SimpleArrayData name="q"> <gx:value>0.0</gx:value> <gx:value>0.0</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.sacc"> <gx:value>U000</gx:value> <gx:value>U000</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.v"> <gx:value>1</gx:value> <gx:value>1</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.cn"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="hp"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="hid"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ix"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.xix"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.whos"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.car-type"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> </SchemaData></ExtendedData> </gx:Track> </Placemark> <Placemark><name>1392111395751.56</name><description>1392111395751.56</descr iption><styleUrl>#cff808080</styleUrl> <gx:Track><altitudeMode>absolute</altitudeMode> <when>2014-02-11T09:36:34.36Z</when> <when>2014-02-11T09:36:35.36Z</when> ... SNIP </Folder></Document></kml> Which yields very wieldy files compared to the original very compact source data and so far I can't see how to put it into the more sensible gpx format. This gets worse as the user adds more attributes to the real-time messages. By attribute think of them as name-value pairs of something about each position report and depending on the types of data (i.e. the source schema) there will be different attributes required - thus an extensible message format is required. The above example was snipped from the attached KML file to cut it down a little. The things you are looking at are some of my aircraft's tracks being annotated with attributes to fill out my test data and to give it some realism when being parsed and display in my systems. My real-time format is very suitable for displaying and tracking anything and I have sucked in the entire days worth (24 hours) of AIS data (65,725 ships) and once imported it displays the whole world view in less than 360 mS. I am interested in whether gpx can be extended to cope with the types of data I can parse and if so I may consider supporting it as an output format. As an input it is already possible to parse the gpx format and extract the limited attributes that it already provides - it is export that presents a problem because I basically only support formats that can be used for the complete round-trip within my product. If you can export it it needs to be importable and it needs to be convertible from one format to the next i.e. each format export must be semantically equivalent it each other format export and it must be able to be imported back into the product without any data loss; data is not permitted to be lost in the round-trip or between conversions. I am after semantic equivalence, syntax being sugar for parser and compiler developers. Regards, Ralph [Non-text portions of this message have been removed]
robertlipe+gmail.com on Tue Feb 11 11:48:16 2014 (link)
If you care only about your own program, you can make up whatever you want in the extension tags. You certainly can't expect arbitrary data to be round-tripped through other programs. http://www.topografix.com/gpx.asp BTW, self closing tags in KML make the empty data case a little less wordy: <gx:value /> On Tue Feb 11 2014 at 1:37:27 PM, Ralph B Holland <ralph+arising.com.au> wrote: > I employ a I highly extensible xml-like format for real-time geo-data; tens > of thousands of position reports are processed per second and these xml > fragments (not complete documents) are user-extensible and displayed as > real-time layers within my GIS product www.arising.com.au/ir-gis. > > > > Each position-report has the following types of data associated with it: > > . time-stamp (seconds since Unix epoch - mandatory) > > . latitude (degrees WGS84 - optional on events/report, mandatory of > a position) > > . longitude (degrees WGS84 - optional on events/report, mandatory > on > a position) > > . altitude (optional) > > . other attribute value (optional) . which are user extensible > > > > I was thinking of saving these real-time layers as GPX (having already done > KML, XML and CSV and other formats) for use in other tools and databases, > but Looking at the gpx format I can't easily see how to represent my > extra-attribute values in the gpx data? > > > > By way of example here is some KML generated from some simulated data where > that data contains attribute names (some of which I made up to provide the > idea): > > . date > > . fid - feature id > > . ci.csn - channel sequence number > > . ts - timestamp > > . ci.sc - source > > . ci.sid - source id > > . ci.iff - iff > > . la - latitude > > . lo - longitude > > . al - altitude > > . s - speed > > . h - heading > > . e - error term > > . r - range > > . b - bearing > > . q - quality factor > > . ci.sacc - SACC > > . ci.v - version > > . ci.cn > > . hp - partition > > . hid - partition index > > . ix - position index > > . ci.xix - extended index > > . ci.whos - owner > > . ci.car-type - type of car > > > > Converting the input data to KML: > > > > <?xml version="1.0" encoding="UTF-8"?> > > <kml xmlns="http://www.opengis.net/kml/2.2" > xmlns:gx="http://www.google.com/kml/ext/2.2"> > > <Document> > > <name>ir-gis mapview 2014-02-11T09:36:35.74Z</name> > > <Snippet>Created 2014-02-11T09:36:35.74Z</Snippet> > > <!-- Normal track style --> > > > <LookAt><gx:TimeSpan><begin>2014-02-11T09:36:35.74Z</ > begin><end>2014-02-11T0 > 9:36:47.36Z</end></gx:TimeSpan> > > > <longitude>149.188850</longitude><latitude>-35. > 308030</latitude><altitude>10 > 0000.0</altitude><range>130000.000000</range> > > </LookAt> > > <Style id="cff808080_n"> > > > <IconStyle><scale>.5</scale><Icon><href>http://earth. > google.com/images/kml-i > cons/track-directional/track-none.png<http://earth.google.com/images/kml-icons/track-directional/track-none.png> > <http://earth.google.com/images/kml-icons/track- > directional/track-none.png%3 > c/href%3e%3c/Icon%3e%3c/IconStyle<http://earth.google.com/images/kml-icons/track-directional/track-none.png%3c/href%3e%3c/Icon%3e%3c/IconStyle>> > </href></Icon></IconStyle> > > <LabelStyle><scale>0</scale></LabelStyle> > > <LineStyle><color>ff808080</color><width>6</width></LineStyle> > > </Style> > > <Style id="cff808080_h"> > > > <IconStyle><scale>1.2</scale><Icon><href>http://earth. > google.com/images/kml- > icons/track-directional/track-none.png<http://earth.google.com/images/kml-icons/track-directional/track-none.png> > <http://earth.google.com/images/kml-icons/track- > directional/track-none.png%3 > c/href%3e%3c/Icon%3e%3c/IconStyle<http://earth.google.com/images/kml-icons/track-directional/track-none.png%3c/href%3e%3c/Icon%3e%3c/IconStyle>> > </href></Icon></IconStyle> > > <LineStyle><color>ff808080</color><width>9</width></LineStyle> > > </Style> > > <StyleMap id="cff808080"> > > <Pair><key>normal</key><styleUrl>#cff808080_n</styleUrl></Pair> > > <Pair><key>highlight</key><styleUrl>#cff808080_h</styleUrl></Pair> > > </StyleMap> > > > > <Schema id="schema"> > > <gx:SimpleArrayField name="date" > type="string"><displayName>date</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="fid" > type="string"><displayName>null</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.csn" type="string"><displayName>Case > Notation</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ts" > type="string"><displayName>timestamp</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.sc" > type="string"><displayName>Source</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.sid" type="string"><displayName>Source > ID</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.iff" > type="string"><displayName>IFF</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="la" > type="double"><displayName>latitude</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="lo" > type="double"><displayName>longitude</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="al" > type="double"><displayName>altitude</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="s" > type="float"><displayName>Speed</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="h" > type="string"><displayName>Heading</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="e" type="float"><displayName>est > error</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="r" > type="float"><displayName>Range</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="b" > type="string"><displayName>Bearing</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="q" > type="float"><displayName>quality</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.sacc" > type="string"><displayName>SACC</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.v" > type="string"><displayName>version</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.cn" > type="string"><displayName>ci.cn</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="hp" > type="string"><displayName>hp</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="hid" > type="string"><displayName>hid</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ix" > type="string"><displayName>ix</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.xix" > type="string"><displayName>ci.xix</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.whos" > type="string"><displayName>ci.whos</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.car-type" > type="string"><displayName>ci.car-type</displayName></gx:SimpleArrayField> > > </Schema> > > <Folder> > > <name>ATC-LAYER-1</name> > > <Placemark><name>1392111395741.54</name><description>1392111395741.54</ > descr > iption><styleUrl>#cff808080</styleUrl> > > <gx:Track><altitudeMode>absolute</altitudeMode> > > <when>2014-02-11T09:36:34.36Z</when> > > <when>2014-02-11T09:36:35.36Z</when> > > <gx:coord>149.185959 -35.303387 536.752800</gx:coord> > > <gx:coord>149.185944 -35.303410 536.752800</gx:coord> > > <ExtendedData><SchemaData schemaUrl="#schema"> > > <gx:SimpleArrayData name="date"> > > <gx:value>2014-02-11T09:36:34.36Z</gx:value> > > <gx:value>2014-02-11T09:36:35.36Z</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="fid"> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.csn"> > > <gx:value>RI</gx:value> > > <gx:value>RI</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ts"> > > <gx:value>1392111394362</gx:value> > > <gx:value>1392111395362</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.sc"> > > <gx:value>RAD1</gx:value> > > <gx:value>RAD1</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.sid"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.iff"> > > <gx:value>1200</gx:value> > > <gx:value>1200</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="la"> > > <gx:value>-35.303387</gx:value> > > <gx:value>-35.30341</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="lo"> > > <gx:value>149.185959</gx:value> > > <gx:value>149.185944</gx:value> > > <</gx:SimpleArrayData> > > <gx:SimpleArrayData name="al"> > > <gx:value>1761.0</gx:value> > > <gx:value>1761.0</gx:value> > > <</gx:SimpleArrayData> > > <gx:SimpleArrayData name="s"> > > <gx:value>6.1</gx:value> > > <gx:value>5.3</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="h"> > > <gx:value>209</gx:value> > > <gx:value>213</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="e"> > > <gx:value>0.0</gx:value> > > <gx:value>0.0</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="r"> > > <gx:value>0.0</gx:value> > > <gx:value>0.0</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="b"> > > <gx:value>360</gx:value> > > <gx:value>360</gx:value> > > <</gx:SimpleArrayData> > > <gx:SimpleArrayData name="q"> > > <gx:value>0.0</gx:value> > > <gx:value>0.0</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.sacc"> > > <gx:value>U000</gx:value> > > <gx:value>U000</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.v"> > > <gx:value>1</gx:value> > > <gx:value>1</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.cn"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="hp"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="hid"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ix"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.xix"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.whos"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.car-type"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > </SchemaData></ExtendedData> > > </gx:Track> > > </Placemark> > > <Placemark><name>1392111395751.56</name><description>1392111395751.56</ > descr > iption><styleUrl>#cff808080</styleUrl> > > <gx:Track><altitudeMode>absolute</altitudeMode> > > <when>2014-02-11T09:36:34.36Z</when> > > <when>2014-02-11T09:36:35.36Z</when> > > ... SNIP > > </Folder></Document></kml> > > > > Which yields very wieldy files compared to the original very compact source > data and so far I can't see how to put it into the more sensible gpx > format. > This gets worse as the user adds more attributes to the real-time messages. > By attribute think of them as name-value pairs of something about each > position report and depending on the types of data (i.e. the source schema) > there will be different attributes required - thus an extensible message > format is required. > > > > The above example was snipped from the attached KML file to cut it down a > little. The things you are looking at are some of my aircraft's tracks > being > annotated with attributes to fill out my test data and to give it some > realism when being parsed and display in my systems. > > > > My real-time format is very suitable for displaying and tracking anything > and I have sucked in the entire days worth (24 hours) of AIS data (65,725 > ships) and once imported it displays the whole world view in less than 360 > mS. I am interested in whether gpx can be extended to cope with the types > of > data I can parse and if so I may consider supporting it as an output > format. > > > > > As an input it is already possible to parse the gpx format and extract the > limited attributes that it already provides - it is export that presents a > problem because I basically only support formats that can be used for the > complete round-trip within my product. If you can export it it needs to be > importable and it needs to be convertible from one format to the next i.e. > each format export must be semantically equivalent it each other format > export and it must be able to be imported back into the product without any > data loss; data is not permitted to be lost in the round-trip or between > conversions. I am after semantic equivalence, syntax being sugar for parser > and compiler developers. > > > > Regards, > > > Ralph > > > > > > [Non-text portions of this message have been removed] > > > > ------------------------------------ > > Yahoo Groups Links > > > > --089e011604f6b218b604f226bc4b
robertlipe+gmail.com on Tue Feb 11 11:53:50 2014 (link)
The schema is at http://www.topografix.com/gpx.asp Examples on that site, as well as others such as http://sourceforge.net/apps/mediawiki/qlandkartegt/index.php?title=GPX_track_extensionscan provide inspiration on you writing your own extensions. There isn't a formal extension for roll and tilt; you'll have to make your own. On Tue Feb 11 2014 at 1:37:22 PM, <albert.mikolaj+yahoo.com> wrote: > > > Hi, > > > I am a total newbie in GPX. I would like to know if it is possible to add > sensor information such as roll and tilt onto the gpx file. Do I need to > use an extension? How is it possible to achieve? I tried to find relevant > information on topografix.com but failed to find my answer. > > Thanks in advance. > > Albert > > > > --001a1134425098ee3604f226d0b1
ralph+arising.com.au on Wed Feb 12 08:05:45 2014 (link)
I see that my problem of arbitrary attributes is partially addressed by QLandKarte GT via mediawiki <http://sourceforge.net/apps/mediawiki/qlandkartegt/index.php?title=GPX_trac k_extensions> http://sourceforge.net/apps/mediawiki/qlandkartegt/index.php?title=GPX_track _extensions and that it may be possible to round-trip data between the two products using gpx (thought that is not my goal here). The extensions of GIS data formats with arbitrary attributes is a big issue for my type of real-time data. Well not so arbitrary, each of my problem sets (or data sources) would have their own set of schema - but such schema needs to be user extensible and suited to the user's problem and not the developer's view of the world. i.e. the user needs to be able to supply their own schema for each data source - and this is what they do in my product - but it is not XML schema they supply - it is the attribute names instead. I guess I need to look at XSD or XML schema to see if there is a way to express the arbitrary extensions that I speak of? You have probably gathered by now that I am not very familiar with XML validation and its schema definitions and that I am running a non-validating XML parser for my XML real-time message fragments. Regards, Ralph From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Robert Lipe Sent: Wednesday, 12 February 2014 06:54 To: gpsxml+yahoogroups.com Subject: [gpsxml] Adding sensor data to .gpx The schema is at http://www.topografix.com/gpx.asp Examples on that site, as well as others such as http://sourceforge.net/apps/mediawiki/qlandkartegt/index.php?title=GPX_track _extensions can provide inspiration on you writing your own extensions. There isn't a formal extension for roll and tilt; you'll have to make your own. On Tue Feb 11 2014 at 1:37:22 PM, <albert.mikolaj+yahoo.com> wrote: Hi, I am a total newbie in GPX. I would like to know if it is possible to add sensor information such as roll and tilt onto the gpx file. Do I need to use an extension? How is it possible to achieve? I tried to find relevant information on topografix.com but failed to find my answer. Thanks in advance. Albert _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3697/7081 - Release Date: 02/10/14 ------=_NextPart_000_006F_01CF27D6.5F272800
tstonick+gmail.com on Sat Feb 15 16:39:28 2014 (link), replying to msg
Are you trying to read/write or just read, GPX files? InApril I did a project convertinng CSV and a couple of other proprietary formats..It sounds like you want to insert an addidional point. Since GPX is not a legitimate XML document it is a little tough. I' mnot sure how we did it, but I have a copy of the code I can take a look at tomorrow. Please let me know if youve figure dit out before I can give you an answer. I do think er found a way to use an XMLDOC and then you can add children to your xml nodes and with XML elements If you go here http://www.topografix.com/gpx.asp and read the schema and use the validator tool, You should be able to verify what you are doing is applicable. On Tue, Feb 11, 2014 at 2:53 AM, Ralph B Holland <ralph+arising.com.au>wrote: > > > I employ a I highly extensible xml-like format for real-time geo-data; tens > of thousands of position reports are processed per second and these xml > fragments (not complete documents) are user-extensible and displayed as > real-time layers within my GIS product www.arising.com.au/ir-gis. > > Each position-report has the following types of data associated with it: > > . time-stamp (seconds since Unix epoch - mandatory) > > . latitude (degrees WGS84 - optional on events/report, mandatory of > a position) > > . longitude (degrees WGS84 - optional on events/report, mandatory on > a position) > > . altitude (optional) > > . other attribute value (optional) . which are user extensible > > I was thinking of saving these real-time layers as GPX (having already done > KML, XML and CSV and other formats) for use in other tools and databases, > but Looking at the gpx format I can't easily see how to represent my > extra-attribute values in the gpx data? > > By way of example here is some KML generated from some simulated data where > that data contains attribute names (some of which I made up to provide the > idea): > > . date > > . fid - feature id > > . ci.csn - channel sequence number > > . ts - timestamp > > . ci.sc - source > > . ci.sid - source id > > . ci.iff - iff > > . la - latitude > > . lo - longitude > > . al - altitude > > . s - speed > > . h - heading > > . e - error term > > . r - range > > . b - bearing > > . q - quality factor > > . ci.sacc - SACC > > . ci.v - version > > . ci.cn > > . hp - partition > > . hid - partition index > > . ix - position index > > . ci.xix - extended index > > . ci.whos - owner > > . ci.car-type - type of car > > Converting the input data to KML: > > <?xml version="1.0" encoding="UTF-8"?> > > <kml xmlns="http://www.opengis.net/kml/2.2" > xmlns:gx="http://www.google.com/kml/ext/2.2"> > > <Document> > > <name>ir-gis mapview 2014-02-11T09:36:35.74Z</name> > > <Snippet>Created 2014-02-11T09:36:35.74Z</Snippet> > > <!-- Normal track style --> > > > <LookAt><gx:TimeSpan><begin>2014-02-11T09:36:35.74Z</begin><end>2014-02-11T0 > 9:36:47.36Z</end></gx:TimeSpan> > > > <longitude>149.188850</longitude><latitude>-35.308030</latitude><altitude>10 > 0000.0</altitude><range>130000.000000</range> > > </LookAt> > > <Style id="cff808080_n"> > > <IconStyle><scale>.5</scale><Icon><href> > http://earth.google.com/images/kml-i > cons/track-directional/track-none.png > < > http://earth.google.com/images/kml-icons/track-directional/track-none.png%3 > c/href%3e%3c/Icon%3e%3c/IconStyle> </href></Icon></IconStyle> > > <LabelStyle><scale>0</scale></LabelStyle> > > <LineStyle><color>ff808080</color><width>6</width></LineStyle> > > </Style> > > <Style id="cff808080_h"> > > <IconStyle><scale>1.2</scale><Icon><href> > http://earth.google.com/images/kml- > icons/track-directional/track-none.png > < > http://earth.google.com/images/kml-icons/track-directional/track-none.png%3 > c/href%3e%3c/Icon%3e%3c/IconStyle> </href></Icon></IconStyle> > > <LineStyle><color>ff808080</color><width>9</width></LineStyle> > > </Style> > > <StyleMap id="cff808080"> > > <Pair><key>normal</key><styleUrl>#cff808080_n</styleUrl></Pair> > > <Pair><key>highlight</key><styleUrl>#cff808080_h</styleUrl></Pair> > > </StyleMap> > > <Schema id="schema"> > > <gx:SimpleArrayField name="date" > type="string"><displayName>date</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="fid" > type="string"><displayName>null</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.csn" type="string"><displayName>Case > Notation</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ts" > type="string"><displayName>timestamp</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.sc" > type="string"><displayName>Source</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.sid" type="string"><displayName>Source > ID</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.iff" > type="string"><displayName>IFF</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="la" > type="double"><displayName>latitude</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="lo" > type="double"><displayName>longitude</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="al" > type="double"><displayName>altitude</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="s" > type="float"><displayName>Speed</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="h" > type="string"><displayName>Heading</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="e" type="float"><displayName>est > error</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="r" > type="float"><displayName>Range</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="b" > type="string"><displayName>Bearing</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="q" > type="float"><displayName>quality</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.sacc" > type="string"><displayName>SACC</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.v" > type="string"><displayName>version</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.cn" > type="string"><displayName>ci.cn</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="hp" > type="string"><displayName>hp</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="hid" > type="string"><displayName>hid</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ix" > type="string"><displayName>ix</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.xix" > type="string"><displayName>ci.xix</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.whos" > type="string"><displayName>ci.whos</displayName></gx:SimpleArrayField> > > <gx:SimpleArrayField name="ci.car-type" > type="string"><displayName>ci.car-type</displayName></gx:SimpleArrayField> > > </Schema> > > <Folder> > > <name>ATC-LAYER-1</name> > > > <Placemark><name>1392111395741.54</name><description>1392111395741.54</descr > iption><styleUrl>#cff808080</styleUrl> > > <gx:Track><altitudeMode>absolute</altitudeMode> > > <when>2014-02-11T09:36:34.36Z</when> > > <when>2014-02-11T09:36:35.36Z</when> > > <gx:coord>149.185959 -35.303387 536.752800</gx:coord> > > <gx:coord>149.185944 -35.303410 536.752800</gx:coord> > > <ExtendedData><SchemaData schemaUrl="#schema"> > > <gx:SimpleArrayData name="date"> > > <gx:value>2014-02-11T09:36:34.36Z</gx:value> > > <gx:value>2014-02-11T09:36:35.36Z</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="fid"> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.csn"> > > <gx:value>RI</gx:value> > > <gx:value>RI</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ts"> > > <gx:value>1392111394362</gx:value> > > <gx:value>1392111395362</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.sc"> > > <gx:value>RAD1</gx:value> > > <gx:value>RAD1</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.sid"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.iff"> > > <gx:value>1200</gx:value> > > <gx:value>1200</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="la"> > > <gx:value>-35.303387</gx:value> > > <gx:value>-35.30341</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="lo"> > > <gx:value>149.185959</gx:value> > > <gx:value>149.185944</gx:value> > > <</gx:SimpleArrayData> > > <gx:SimpleArrayData name="al"> > > <gx:value>1761.0</gx:value> > > <gx:value>1761.0</gx:value> > > <</gx:SimpleArrayData> > > <gx:SimpleArrayData name="s"> > > <gx:value>6.1</gx:value> > > <gx:value>5.3</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="h"> > > <gx:value>209</gx:value> > > <gx:value>213</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="e"> > > <gx:value>0.0</gx:value> > > <gx:value>0.0</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="r"> > > <gx:value>0.0</gx:value> > > <gx:value>0.0</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="b"> > > <gx:value>360</gx:value> > > <gx:value>360</gx:value> > > <</gx:SimpleArrayData> > > <gx:SimpleArrayData name="q"> > > <gx:value>0.0</gx:value> > > <gx:value>0.0</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.sacc"> > > <gx:value>U000</gx:value> > > <gx:value>U000</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.v"> > > <gx:value>1</gx:value> > > <gx:value>1</gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.cn"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="hp"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="hid"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ix"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.xix"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.whos"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > <gx:SimpleArrayData name="ci.car-type"> > > <gx:value></gx:value> > > <gx:value></gx:value> > > </gx:SimpleArrayData> > > </SchemaData></ExtendedData> > > </gx:Track> > > </Placemark> > > > <Placemark><name>1392111395751.56</name><description>1392111395751.56</descr > iption><styleUrl>#cff808080</styleUrl> > > <gx:Track><altitudeMode>absolute</altitudeMode> > > <when>2014-02-11T09:36:34.36Z</when> > > <when>2014-02-11T09:36:35.36Z</when> > > ... SNIP > > </Folder></Document></kml> > > Which yields very wieldy files compared to the original very compact source > data and so far I can't see how to put it into the more sensible gpx > format. > This gets worse as the user adds more attributes to the real-time messages. > By attribute think of them as name-value pairs of something about each > position report and depending on the types of data (i.e. the source schema) > there will be different attributes required - thus an extensible message > format is required. > > The above example was snipped from the attached KML file to cut it down a > little. The things you are looking at are some of my aircraft's tracks > being > annotated with attributes to fill out my test data and to give it some > realism when being parsed and display in my systems. > > My real-time format is very suitable for displaying and tracking anything > and I have sucked in the entire days worth (24 hours) of AIS data (65,725 > ships) and once imported it displays the whole world view in less than 360 > mS. I am interested in whether gpx can be extended to cope with the types > of > data I can parse and if so I may consider supporting it as an output > format. > > As an input it is already possible to parse the gpx format and extract the > limited attributes that it already provides - it is export that presents a > problem because I basically only support formats that can be used for the > complete round-trip within my product. If you can export it it needs to be > importable and it needs to be convertible from one format to the next i.e. > each format export must be semantically equivalent it each other format > export and it must be able to be imported back into the product without any > data loss; data is not permitted to be lost in the round-trip or between > conversions. I am after semantic equivalence, syntax being sugar for parser > and compiler developers. > > Regards, > > Ralph > > [Non-text portions of this message have been removed] > > > -- It all comes down to physics. --047d7b471be20ac38e04f2705736
ralph+arising.com.au on Tue Feb 18 08:04:03 2014 (link), replying to msg
Hi Tim, No need to trouble yourself with looking up any code. I am trying to round-trip GPX through my product at <http://www.arising.com.au/ir-gis> www.arising.com.au/ir-gis which already supports round-trip (import and export) of several formats - I just wanted to add gpx as another candidate to increase the product utility. Each data source has a different scheme (let's call it that as against XML schema); depending on what attributes are present there needs to be extra attributes added to the gpx document fragment for each position (in a similar fashion as elevation is just an attribute so too are all the user-extensible attributes to which I refer). I am not too fussed as I do not need to do it just yet and I am just exploring possibilities since I support KML which is so clunky; other priorities are at the top of my development backlog at the moment, such as making some changes to my concurrent query engine. I think I will just implement a name-space for my extensions and see if I can plug them in using the gpx extension schema facility. I can probably get away with elements containing name value attributes and by having three types of elements; it will work though not be as optimal space-wise as my proprietary format. It is a shame none of the GIS formats are really suitable for my system data - which is why I have my own format. Maybe one day I will place that format in the public domain, once I feel secure in the product offering. I don't need to use any of the XMLDOM framework, parsers included, because I have my own frameworks/parsers for handling all sorts of formatted GIS data; if I need anything special I can easily write it; all I am exploring at this stage is the means of doing the extension of gpx; and I would happily publish my extensions back to the gpsxml group once done so others can use it. Regards, Ralph From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] On Behalf Of Tim Stonick Sent: Saturday, 15 February 2014 22:37 To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] FW: Can I represent multiple attribute value pairs with gpx Are you trying to read/write or just read, GPX files? InApril I did a project convertinng CSV and a couple of other proprietary formats..It sounds like you want to insert an addidional point. Since GPX is not a legitimate XML document it is a little tough. I' mnot sure how we did it, but I have a copy of the code I can take a look at tomorrow. Please let me know if youve figure dit out before I can give you an answer. I do think er found a way to use an XMLDOC and then you can add children to your xml nodes and with XML elements If you go here http://www.topografix.com/gpx.asp and read the schema and use the validator tool, You should be able to verify what you are doing is applicable. On Tue, Feb 11, 2014 at 2:53 AM, Ralph B Holland <ralph+arising.com.au> wrote: I employ a I highly extensible xml-like format for real-time geo-data; tens of thousands of position reports are processed per second and these xml fragments (not complete documents) are user-extensible and displayed as real-time layers within my GIS product www.arising.com.au/ir-gis. Each position-report has the following types of data associated with it: . time-stamp (seconds since Unix epoch - mandatory) . latitude (degrees WGS84 - optional on events/report, mandatory of a position) . longitude (degrees WGS84 - optional on events/report, mandatory on a position) . altitude (optional) . other attribute value (optional) . which are user extensible I was thinking of saving these real-time layers as GPX (having already done KML, XML and CSV and other formats) for use in other tools and databases, but Looking at the gpx format I can't easily see how to represent my extra-attribute values in the gpx data? By way of example here is some KML generated from some simulated data where that data contains attribute names (some of which I made up to provide the idea): . date . fid - feature id . ci.csn - channel sequence number . ts - timestamp . ci.sc - source . ci.sid - source id . ci.iff - iff . la - latitude . lo - longitude . al - altitude . s - speed . h - heading . e - error term . r - range . b - bearing . q - quality factor . ci.sacc - SACC . ci.v - version . ci.cn . hp - partition . hid - partition index . ix - position index . ci.xix - extended index . ci.whos - owner . ci.car-type - type of car Converting the input data to KML: <?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2"> <Document> <name>ir-gis mapview 2014-02-11T09:36:35.74Z</name> <Snippet>Created 2014-02-11T09:36:35.74Z</Snippet> <!-- Normal track style --> <LookAt><gx:TimeSpan><begin>2014-02-11T09:36:35.74Z</begin><end>2014-02-11T0 9:36:47.36Z</end></gx:TimeSpan> <longitude>149.188850</longitude><latitude>-35.308030</latitude><altitude>10 0000.0</altitude><range>130000.000000</range> </LookAt> <Style id="cff808080_n"> <IconStyle><scale>.5</scale><Icon><href>http://earth.google.com/images/kml-i cons/track-directional/track-none.png <http://earth.google.com/images/kml-icons/track-directional/track-none.png%3 <http://earth.google.com/images/kml-icons/track-directional/track-none.png%2 53> c/href%3e%3c/Icon%3e%3c/IconStyle> </href></Icon></IconStyle> <LabelStyle><scale>0</scale></LabelStyle> <LineStyle><color>ff808080</color><width>6</width></LineStyle> </Style> <Style id="cff808080_h"> <IconStyle><scale>1.2</scale><Icon><href>http://earth.google.com/images/kml- icons/track-directional/track-none.png <http://earth.google.com/images/kml-icons/track-directional/track-none.png%3 <http://earth.google.com/images/kml-icons/track-directional/track-none.png%2 53> c/href%3e%3c/Icon%3e%3c/IconStyle> </href></Icon></IconStyle> <LineStyle><color>ff808080</color><width>9</width></LineStyle> </Style> <StyleMap id="cff808080"> <Pair><key>normal</key><styleUrl>#cff808080_n</styleUrl></Pair> <Pair><key>highlight</key><styleUrl>#cff808080_h</styleUrl></Pair> </StyleMap> <Schema id="schema"> <gx:SimpleArrayField name="date" type="string"><displayName>date</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="fid" type="string"><displayName>null</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.csn" type="string"><displayName>Case Notation</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ts" type="string"><displayName>timestamp</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.sc" type="string"><displayName>Source</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.sid" type="string"><displayName>Source ID</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.iff" type="string"><displayName>IFF</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="la" type="double"><displayName>latitude</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="lo" type="double"><displayName>longitude</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="al" type="double"><displayName>altitude</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="s" type="float"><displayName>Speed</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="h" type="string"><displayName>Heading</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="e" type="float"><displayName>est error</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="r" type="float"><displayName>Range</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="b" type="string"><displayName>Bearing</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="q" type="float"><displayName>quality</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.sacc" type="string"><displayName>SACC</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.v" type="string"><displayName>version</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.cn" type="string"><displayName>ci.cn</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="hp" type="string"><displayName>hp</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="hid" type="string"><displayName>hid</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ix" type="string"><displayName>ix</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.xix" type="string"><displayName>ci.xix</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.whos" type="string"><displayName>ci.whos</displayName></gx:SimpleArrayField> <gx:SimpleArrayField name="ci.car-type" type="string"><displayName>ci.car-type</displayName></gx:SimpleArrayField> </Schema> <Folder> <name>ATC-LAYER-1</name> <Placemark><name>1392111395741.54</name><description>1392111395741.54</descr iption><styleUrl>#cff808080</styleUrl> <gx:Track><altitudeMode>absolute</altitudeMode> <when>2014-02-11T09:36:34.36Z</when> <when>2014-02-11T09:36:35.36Z</when> <gx:coord>149.185959 -35.303387 536.752800</gx:coord> <gx:coord>149.185944 -35.303410 536.752800</gx:coord> <ExtendedData><SchemaData schemaUrl="#schema"> <gx:SimpleArrayData name="date"> <gx:value>2014-02-11T09:36:34.36Z</gx:value> <gx:value>2014-02-11T09:36:35.36Z</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="fid"> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.csn"> <gx:value>RI</gx:value> <gx:value>RI</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ts"> <gx:value>1392111394362</gx:value> <gx:value>1392111395362</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.sc"> <gx:value>RAD1</gx:value> <gx:value>RAD1</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.sid"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.iff"> <gx:value>1200</gx:value> <gx:value>1200</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="la"> <gx:value>-35.303387</gx:value> <gx:value>-35.30341</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="lo"> <gx:value>149.185959</gx:value> <gx:value>149.185944</gx:value> <</gx:SimpleArrayData> <gx:SimpleArrayData name="al"> <gx:value>1761.0</gx:value> <gx:value>1761.0</gx:value> <</gx:SimpleArrayData> <gx:SimpleArrayData name="s"> <gx:value>6.1</gx:value> <gx:value>5.3</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="h"> <gx:value>209</gx:value> <gx:value>213</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="e"> <gx:value>0.0</gx:value> <gx:value>0.0</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="r"> <gx:value>0.0</gx:value> <gx:value>0.0</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="b"> <gx:value>360</gx:value> <gx:value>360</gx:value> <</gx:SimpleArrayData> <gx:SimpleArrayData name="q"> <gx:value>0.0</gx:value> <gx:value>0.0</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.sacc"> <gx:value>U000</gx:value> <gx:value>U000</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.v"> <gx:value>1</gx:value> <gx:value>1</gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.cn"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="hp"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="hid"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ix"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.xix"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.whos"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> <gx:SimpleArrayData name="ci.car-type"> <gx:value></gx:value> <gx:value></gx:value> </gx:SimpleArrayData> </SchemaData></ExtendedData> </gx:Track> </Placemark> <Placemark><name>1392111395751.56</name><description>1392111395751.56</descr iption><styleUrl>#cff808080</styleUrl> <gx:Track><altitudeMode>absolute</altitudeMode> <when>2014-02-11T09:36:34.36Z</when> <when>2014-02-11T09:36:35.36Z</when> ... SNIP </Folder></Document></kml> Which yields very wieldy files compared to the original very compact source data and so far I can't see how to put it into the more sensible gpx format. This gets worse as the user adds more attributes to the real-time messages. By attribute think of them as name-value pairs of something about each position report and depending on the types of data (i.e. the source schema) there will be different attributes required - thus an extensible message format is required. The above example was snipped from the attached KML file to cut it down a little. The things you are looking at are some of my aircraft's tracks being annotated with attributes to fill out my test data and to give it some realism when being parsed and display in my systems. My real-time format is very suitable for displaying and tracking anything and I have sucked in the entire days worth (24 hours) of AIS data (65,725 ships) and once imported it displays the whole world view in less than 360 mS. I am interested in whether gpx can be extended to cope with the types of data I can parse and if so I may consider supporting it as an output format. As an input it is already possible to parse the gpx format and extract the limited attributes that it already provides - it is export that presents a problem because I basically only support formats that can be used for the complete round-trip within my product. If you can export it it needs to be importable and it needs to be convertible from one format to the next i.e. each format export must be semantically equivalent it each other format export and it must be able to be imported back into the product without any data loss; data is not permitted to be lost in the round-trip or between conversions. I am after semantic equivalence, syntax being sugar for parser and compiler developers. Regards, Ralph [Non-text portions of this message have been removed] -- It all comes down to physics. _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3697/7090 - Release Date: 02/13/14 ------=_NextPart_000_02EB_01CF2CE7.1ADAFB20
gtheo91+yahoo.gr on Fri Mar 21 09:25:20 2014 (link)
Hello, I am working on my thesis and i would like to find some accurate (more accurate than those of google maps) gpx files of greece, especially Patras. My problem is that i want to display the motion of a car on the road, in order to do that for example in a straight line road i only have the first and the last point and i need some more points between them. Can anyone help ?
robertlipe+gmail.com on Fri Mar 21 09:48:19 2014 (link)
GPX doesn't really do maps in the sense people typically think about them. GPSBabel's interpolate filter can add points based on time or diastance. http://www.gpsbabel.org/htmldoc-development/filter_interpolate.html On Fri Mar 21 2014 at 9:25:22 AM, <gtheo91+yahoo.gr> wrote: > > > Hello, > I am working on my thesis and i would like to find some accurate (more > accurate than those of google maps) gpx files of greece, especially Patras. > My problem is that i want to display the motion of a car on the road, in > order to do that for example in a straight line road i only have the first > and the last point and i need some more points between them. Can anyone > help ? > > > > --f46d043892131d450c04f520a73e
yahoo+web.knobby.ws on Fri Mar 21 10:01:11 2014 (link), replying to msg
Check out http://www.openstreetmap.org http://www.openstreetmap.org. Someone there may be able to help. PS. Why can't I reply using Safari?
tim.brickle+yahoo.com.au on Tue Apr 08 14:01:03 2014 (link)
Hi Everyone, Apologies if this isn't the right kind of post for this forum but I thought someone here maybe able to help. I run a site that is currently in BETA (www.exploco.com) and we're looking for a developer to help us import the GPX/TCX files from GPS devices into our site and to display the map route and key session data with a users profile. Tim
rob+rubylynx.com on Mon Apr 14 04:21:12 2014 (link), replying to msg
Hi Tim, Saw your post a couple of days ago in the group and wrote a reply, but that didn't appear, so I'm trying again. I develop and maintain the SOTA Mapping Project http://sotamaps.wsstvc.org http://sotamaps.wsstvc.org, which has a page http://sotamaps.wsstvc.org/tracks.php http://sotamaps.wsstvc.org/tracks.php where the users, radio amateurs who transmit from hill/mountain tops, can upload GPX files (in most cases from their GPS devices) and store the track/route to db, and then display that track - or any other uploaded by a user - on a Google map, together with a height profile window. So, I have upload, parse, store and display functionality for GPX files already running. The site uses PHP and MySQL as the backend, with HTML/CSS/Javascript/JSON/Ajax on the front end. Maybe I can help? Rob
rob+rubylynx.com on Thu Apr 24 08:59:46 2014 (link), replying to msg
There's not really a lot to the importing unless the formats you are receiving are from a variety of different devices with a potential to mangle them or handle data in non-proprietary ways. There are a number of pre-existing APIs out there and I've built a few of my own in various languages without a lot of fuss. The more complex part depends upon what you mean by 'display' and 'user profiles'. Keep in mind, also, that some other apis out there have tools that can be used to do some of the work (such as the google maps api or the yahoo maps api, etc.) SW On 04/07/2014 10:00 PM, tim.brickle+yahoo.com.au wrote: > > Hi Everyone, > > > Apologies if this isn't the right kind of post for this forum but I > thought someone here maybe able to help. I run a site that is > currently in BETA (www.exploco.com) and we're looking for a developer > to help us import the GPX/TCX files from GPS devices into our site and > to display the map route and key session data with a users profile. > > Tim > --------------060301020606020404060704
rob+rubylynx.com on Thu May 22 05:55:54 2014 (link), replying to msg
Scott, it's nice of you point the way to this or that API - it would seem, however, that Tim was looking for somebody who was familiar with actually USING them all - in concert with GPX parse. However, we'll probably never know, since he hasn't bothered to reply to our responses. I've also come to the conclusion that this gpsxml group is a complete dead end, so I'm cancelling my membership and moving on. Good luck to anybody still stuck in the shadows here... Rob
Rozzin+geekspace.com on Sun May 25 10:05:28 2014 (link), replying to msg
I wonder if the silence on the list--and apparent non-responsiveness of some members--might actually have something to do with the recent Yahoo/DMARC fiasco.... -- Sent from my Android device with K-9 Mail. Please excuse my brevity. On May 22, 2014 7:40:06 AM EDT, "rob+rubylynx.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: >Scott, it's nice of you point the way to this or that API - it would >seem, however, that Tim was looking for somebody who was familiar with >actually USING them all - in concert with GPX parse. > >However, we'll probably never know, since he hasn't bothered to reply >to our responses. I've also come to the conclusion that this gpsxml >group is a complete dead end, so I'm cancelling my membership and >moving on. Good luck to anybody still stuck in the shadows here... > >Rob ------F3AB5DFGLXCEG2LQAIVYFN8G2F3DMJ
robertlipe+gmail.com on Sun May 25 15:07:48 2014 (link), replying to msg
...or that some members remember that this isn't a 'help wanted' group or that those that do choose to not reply back to the list with "I'm awesome, you should hire me..." There are definitely GPX developers here. On Sun, May 25, 2014 at 12:05 PM, Joshua Judson Rosen Rozzin+geekspace.com[gpsxml] <gpsxml+yahoogroups.com> wrote: > > > I wonder if the silence on the list--and apparent non-responsiveness of > some members--might actually have something to do with the recent > Yahoo/DMARC fiasco.... > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > On May 22, 2014 7:40:06 AM EDT, "rob+rubylynx.com [gpsxml]" < > gpsxml+yahoogroups.com> wrote: >> >> Scott, it's nice of you point the way to this or that API - it would >> seem, however, that Tim was looking for somebody who was familiar with >> actually USING them all - in concert with GPX parse. >> >> However, we'll probably never know, since he hasn't bothered to reply to >> our responses. I've also come to the conclusion that this gpsxml group is a >> complete dead end, so I'm cancelling my membership and moving on. Good luck >> to anybody still stuck in the shadows here... >> >> Rob >> > > > > --089e014946026277d104fa40b14d
jcapron+capron.com on Sun May 25 16:34:25 2014 (link), replying to msg
I am a silent member here. Silent because I am not a programmer or developer. But a member because I am on a working party for an international sports organization that is tasked with standardizing tracking data transfer between the tracking companies and the race officials. GPX has been proposed as the basis of the XML schema for our data transfer. Unfortunately, we probably cannot use the GPX as is, but we are learning from you. Just because I do not actively contribute does not mean I find the discussions uninteresting. Our races sometimes involve 50 to 100 trackers, each recording position fixes at 1 to 5 second intervals, and the races could last up to an hour or two. Can GPX reasonably handle that amount of data? Jim Sent from my iPhone +1 301 728 9500 jcapron+capron.com > On May 25, 2014, at 18:07, "Robert Lipe robertlipe+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: > > ...or that some members remember that this isn't a 'help wanted' group or that those that do choose to not reply back to the list with "I'm awesome, you should hire me..." > > There are definitely GPX developers here. > > >> On Sun, May 25, 2014 at 12:05 PM, Joshua Judson Rosen Rozzin+geekspace.com [gpsxml] <gpsxml+yahoogroups.com> wrote: >> >> >> I wonder if the silence on the list--and apparent non-responsiveness of some members--might actually have something to do with the recent Yahoo/DMARC fiasco.... >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> >> >>> On May 22, 2014 7:40:06 AM EDT, "rob+rubylynx.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: >>> Scott, it's nice of you point the way to this or that API - it would seem, however, that Tim was looking for somebody who was familiar with actually USING them all - in concert with GPX parse. >>> >>> However, we'll probably never know, since he hasn't bothered to reply to our responses. I've also come to the conclusion that this gpsxml group is a complete dead end, so I'm cancelling my membership and moving on. Good luck to anybody still stuck in the shadows here... >>> >>> Rob > > --Apple-Mail-2269BF64-612D-4CA0-AE35-3FA744E960D1
Rozzin+geekspace.com on Mon May 26 08:35:33 2014 (link)
It looks like someone has somehow defaced the GPX website with some spam links (textual, at the top under the menubar and in the upper right corner). I'm not sure if anything else on the site has been altered.... -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------WDEURCYFV8Q9KTYWTY9BTKU6OW9FCG
Rozzin+geekspace.com on Mon May 26 09:17:48 2014 (link), replying to msg
I don't know. I do notice that Yahoo has just recently started rewriting the From field in all of the messages passing through this list so that the listserv claims to be the author, which makes it a bit of a pain for me to even see who actually wrote the messages, and a fairly major pain to reply directly (off-list) to the author of a post. I'd guess that means that, going forward, if people aren't replying on-list, then they probably aren't replying. That's frustrating; I've liked being on this list, but I'm not sure I can handle the new list behaviour. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. On May 25, 2014 6:07:47 PM EDT, "Robert Lipe robertlipe+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: >...or that some members remember that this isn't a 'help wanted' group >or >that those that do choose to not reply back to the list with "I'm >awesome, >you should hire me..." > >There are definitely GPX developers here. > > >On Sun, May 25, 2014 at 12:05 PM, Joshua Judson Rosen >Rozzin+geekspace.com[gpsxml] ><gpsxml+yahoogroups.com> wrote: > >> >> >> I wonder if the silence on the list--and apparent non-responsiveness >of >> some members--might actually have something to do with the recent >> Yahoo/DMARC fiasco.... >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> >> >> On May 22, 2014 7:40:06 AM EDT, "rob+rubylynx.com [gpsxml]" < >> gpsxml+yahoogroups.com> wrote: >>> >>> Scott, it's nice of you point the way to this or that API - it would >>> seem, however, that Tim was looking for somebody who was familiar >with >>> actually USING them all - in concert with GPX parse. >>> >>> However, we'll probably never know, since he hasn't bothered to >reply to >>> our responses. I've also come to the conclusion that this gpsxml >group is a >>> complete dead end, so I'm cancelling my membership and moving on. >Good luck >>> to anybody still stuck in the shadows here... >>> >>> Rob >>> >> >> >> >> ------AU2HX28VZI7WVY6BKV8JUWC9SE7XS1
tt+smartcomsoftware.com on Tue May 27 01:14:10 2014 (link), replying to msg
Jim, GPX would be a good basis for your schema. The number of trackers isn�??t an issue. In my sector (marine) some equipment manufacturers (e,g, Garmin) use an extended version of GPX for exporting tracks of boats, with additions for parameters such as depth that aren�??t in the core GPX spec. If your tracking is over areas where there is always good 3G/4G mobile coverage, or you are using a radio link, then data volume isn�??t an issue, but in the offshore marine sector this isn�??t the case so they use commercial satellite systems such as Iridium. These are relatively expensive, so it is better not to use any XML for the actual tracking message, as it is pretty verbose, and just convert the received message to XML. Tim From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] Sent: 26 May 2014 00:01 To: gpsxml+yahoogroups.com Subject: Re: [gpsxml] Developer Wanted I am a silent member here. Silent because I am not a programmer or developer. But a member because I am on a working party for an international sports organization that is tasked with standardizing tracking data transfer between the tracking companies and the race officials. GPX has been proposed as the basis of the XML schema for our data transfer. Unfortunately, we probably cannot use the GPX as is, but we are learning from you. Just because I do not actively contribute does not mean I find the discussions uninteresting. Our races sometimes involve 50 to 100 trackers, each recording position fixes at 1 to 5 second intervals, and the races could last up to an hour or two. Can GPX reasonably handle that amount of data? Jim Sent from my iPhone +1 301 728 9500 jcapron+capron.com <mailto:jcapron+capron.com> On May 25, 2014, at 18:07, "Robert Lipe robertlipe+gmail.com <mailto:robertlipe+gmail.com> [gpsxml]" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: ...or that some members remember that this isn't a 'help wanted' group or that those that do choose to not reply back to the list with "I'm awesome, you should hire me..." There are definitely GPX developers here. On Sun, May 25, 2014 at 12:05 PM, Joshua Judson Rosen Rozzin+geekspace.com <mailto:Rozzin+geekspace.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: I wonder if the silence on the list--and apparent non-responsiveness of some members--might actually have something to do with the recent Yahoo/DMARC fiasco.... -- Sent from my Android device with K-9 Mail. Please excuse my brevity. On May 22, 2014 7:40:06 AM EDT, "rob+rubylynx.com <mailto:rob+rubylynx.com> [gpsxml]" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: Scott, it's nice of you point the way to this or that API - it would seem, however, that Tim was looking for somebody who was familiar with actually USING them all - in concert with GPX parse. However, we'll probably never know, since he hasn't bothered to reply to our responses. I've also come to the conclusion that this gpsxml group is a complete dead end, so I'm cancelling my membership and moving on. Good luck to anybody still stuck in the shadows here... Rob [Non-text portions of this message have been removed]
heltonbiker+gmail.com on Tue May 27 04:11:36 2014 (link)
Jim Capron said: "Unfortunately, we probably cannot use the GPX as is" Could you elaborate further WHY GPX could not be used as is? From your description, it looks like it could perfectly be used without a problem. (By the way, I am an enthusiast cyclist and programmer, and I have already coded some event analysis scripts for cycling activities, and GPX is of course my preferred way to have each athlete's data. One of our athletes has some tracks with 1000km of length (more than 60 hours of continuous tracking) with a sampling rate of one trackpoint per second, and the resulting GPX file is quite manageable.) Helton --001a11c20ed6ceff0a04fa4d7ea6
jcapron+capron.com on Tue May 27 10:23:26 2014 (link), replying to msg
Yes, and probably dangerous. All the links on the GPX website point to a zip file and they are all the same. --=_alternative 0056116C85257CE4_=
egroups+topografix.com on Tue May 27 10:27:07 2014 (link), replying to msg
Hello, Monday, May 26, 2014, 11:35:32 AM, Joshua wrote: > It looks like someone has somehow defaced the GPX website with some > spam links (textual, at the top under the menubar and in the upper right corner). > > I'm not sure if anything else on the site has been altered.... It is cleaned up now. If anyone has concerns or finds anything else broken, you can reach me directly at support+expertgps.com -- Dan Foster
rajesh_bankar80+yahoo.com on Thu Jun 05 07:47:14 2014 (link)
Hi am developing bus routes for school. I want to show routes on google map. I have gathered .gpx files from garmin device. Now which google map interface should i use and how? I want detailed map.
wbporter455+bellsouth.net on Fri Jun 06 06:14:53 2014 (link), replying to msg
Google Earth can read your favorite points and tracks from your GPS and display them. When reading from the GPS, delete the favorites (waypoints?) from all batches except the last to prevent duplicates. This is my own effort to read the .gpx file, it highlights the track points closest to a given point. The file has to be formatted with something like the MapSource program. Near gpx point On Friday, June 6, 2014 4:39 AM, "gpsxml+yahoogroups.com" <gpsxml+yahoogroups.com> wrote: GPX Developers Forum GPX Developers Forum Group 1 Message Digest #891 1 New User of .gpx, How to use .gpx to Google Map on our own website by rajesh_bankar80 Message 1 New User of .gpx, How to use .gpx to Google Map on our own website Thu Jun 5, 2014 7:47 am (PDT) . Posted by: rajesh_bankar80 Hi am developing bus routes for school. I want to show routes on google map. I have gathered .gpx files from garmin device. Now which google map interface should i use and how? I want detailed map. Reply to sender . Reply to group . Reply via Web Post . All Messages (1) . Top ^ Visit Your Group * New Members 2 �?� Privacy �?� Unsubscribe �?� Terms of Use --664784067-543679581-1402058347?7557
koreth+gmail.com on Fri Aug 29 08:54:35 2014 (link)
The element allows child elementsand but the schema doesn't have anything to say about what they're for. Should the content of be a MIME type? A protocol name? A freeform human-readable description of the link? If it's a freeform text field, then what's the difference between and ? If this is described in some documentation somewhere, I'd love a pointer to it; the only detailed documentation other than the XML schema I found on topografix.com was for GPX 1.0, and is new in 1.1. Background: I'm writing code to convert the data from a travel logging smartphone app to a GPX file, and the app (Rove) incorporates photos you take while out and about. It seems like is the appropriate way to include those in the GPX file and I want to make sure I'm generating it correctly.
egroups+topografix.com on Fri Aug 29 09:02:39 2014 (link), replying to msg
Hello, Friday, August 29, 2014, 11:33:13 AM, koreth+gmail.com wrote: > The <link> element allows child elements <text> and <type> but the > schema doesn't have anything to say about what they're for. Should > the content of <type> be a MIME type? A protocol name? A freeform > human-readable description of the link? If it's a freeform text > field, then what's the difference between <type> and <text>? ExpertGPS stores "image/jpeg" in <type> for photos. -- Dan Foster
koreth+gmail.com on Fri Aug 29 11:14:09 2014 (link), replying to msg
Thanks! And does it use <text> for anything? My assumption was that, for images, that'd be a caption or other human-readable description. -Steve > Dan Foster egroups+topografix.com [gpsxml] <mailto:gpsxml+yahoogroups.com> > August 29, 2014 at 9:01 AM > > Hello, > > Friday, August 29, 2014, 11:33:13 AM, koreth+gmail.com wrote: > > > The <link> element allows child elements <text> and <type> but the > > schema doesn't have anything to say about what they're for. Should > > the content of <type> be a MIME type? A protocol name? A freeform > > human-readable description of the link? If it's a freeform text > > field, then what's the difference between <type> and <text>? > > ExpertGPS stores "image/jpeg" in <type> for photos. > > -- > Dan Foster > > > koreth+gmail.com [gpsxml] <mailto:gpsxml+yahoogroups.com> > August 29, 2014 at 8:33 AM > > The <link> element allows child elements <text> and <type> but the > schema doesn't have anything to say about what they're for. Should the > content of <type> be a MIME type? A protocol name? A freeform > human-readable description of the link? If it's a freeform text field, > then what's the difference between <type> and <text>? > > > If this is described in some documentation somewhere, I'd love a > pointer to it; the only detailed documentation other than the XML > schema I found on topografix.com was for GPX 1.0, and <link> is new in > 1.1. > > Background: I'm writing code to convert the data from a travel logging > smartphone app to a GPX file, and the app (Rove) incorporates photos > you take while out and about. It seems like <link> is the appropriate > way to include those in the GPX file and I want to make sure I'm > generating it correctly. > --------------090004020708020104090904
egroups+topografix.com on Fri Aug 29 11:23:15 2014 (link), replying to msg
Hello, Friday, August 29, 2014, 12:05:59 PM, Steven wrote: > Thanks! And does it use <text> for anything? My assumption was > that, for images, that'd be a caption or other human-readable description. That's how I use it, yes. Since the URL in <link> doesn't always tell you what's on the other end, you can use <type> to indicate the media or mime type, and <text> to give a human-readable title or description. <link href="http://youtu.be/dQw4w9WgXcQ"> <type>video/mp4</type> <text>Rick explains GPX format for developers</text> </link> -- Dan Foster
egroups+topografix.com on Fri Aug 29 11:35:17 2014 (link), replying to msg
Hello, Just noticed that my sample would fail validation because the child elements were in the wrong order, according to: http://www.topografix.com/GPX/1/1/#type_linkType It should have been: <link href="http://youtu.be/dQw4w9WgXcQ"> <text>Rick explains GPX format for developers</text> <type>video/mp4</type> </link> p.s. If you click on the ? in the GPX 1.1 documentation for linkType, it does say "mime type of content (image/jpeg)", which answers your original question. http://www.topografix.com/GPX/1/1/#type_linkType also in http://www.topografix.com/GPX/1/1/gpx.xsd: <xsd:complexType name="linkType"><xsd:annotation><xsd:documentation> A link to an external resource (Web page, digital photo, video clip, etc) with additional information. </xsd:documentation></xsd:annotation><xsd:sequence><!-- elements must appear in this order --><xsd:element name="text" type="xsd:string" minOccurs="0"><xsd:annotation><xsd:documentation> Text of hyperlink. </xsd:documentation></xsd:annotation></xsd:element><xsd:element name="type" type="xsd:string" minOccurs="0"><xsd:annotation><xsd:documentation> Mime type of content (image/jpeg) </xsd:documentation></xsd:annotation></xsd:element></xsd:sequence><xsd:attribute name="href" type="xsd:anyURI" use="required"><xsd:annotation><xsd:documentation> URL of hyperlink. </xsd:documentation></xsd:annotation></xsd:attribute></xsd:complexType> -- Dan Foster
speleoluc+gmail.com on Sat Oct 18 08:13:43 2014 (link)
Hi, I develop a cave surveying freeware. A user who just purchased a Garmin Monterra Android GPS tells me some of the GPX files my app produces cannot be directly opened by his device, but he can open them with CompeGPS, OruxMaps and other software running on his device. My GPX files contain a single (trk) track made of various (trkseg) segments. These segments may be a single line or a series of continuous line segments, depending on how the cave was surveyed. When exporting a network of nearby caves, some track segments may be isolated from others if caves don't touch. I also tried exporting each cave as a distinct (trk) track within a single GPX file, but this too seems to cause a problem, even though it's valid GPX data. What's wrong with my GPX files? I put samples at: http://auriga.speleo.pl/GPX/ -- Luc Le Blanc http://www.speleo.qc.ca/Auriga
tom+tomarneson.com on Sun Oct 19 07:57:42 2014 (link), replying to msg
Luc, I was able to open your GPX file with ExpertGPS. Has he tried to directly open any other GPX files with the Monterra? Aside from having many zero length segments, I see nothing wrong with the GPX file. Tom Arneson
speleoluc+gmail.com on Sun Oct 19 08:01:07 2014 (link), replying to msg
Tom, Yes, his Monterra can open various GPX files, some of my app too, but not all. The zero-length segments must be due to some survey shots too short to make a coordinate difference - I could filter these out. 2014-10-19 10:57 GMT-04:00 tom+tomarneson.com [gpsxml] < gpsxml+yahoogroups.com>: > > > Luc, > > > > I was able to open your GPX file with ExpertGPS. Has he tried to directly > open any other GPX files with the Monterra? Aside from having many zero > length segments, I see nothing wrong with the GPX file. > > > > Tom Arneson > > > > -- Luc Le Blanc http://www.speleo.qc.ca/Auriga --001a113ecb6e1f70310505c7dee8
the.one.eleven+gmail.com on Tue Oct 21 13:56:56 2014 (link)
Just thinking out loud here, if this is obvious then ignore it. I also develop a free GPX related software (gpxcreator.com) though I have not been active in that development for over a year. If I was faced with this problem and wanted to get to the bottom of it quickly, here is what I would do, assuming that I could get a copy of Monterra easily. 1) Take a "bad" file that won't open in Monterra 2) Make two copies of it and cut the track in each copy in half 3) One or both of the halves should be "bad" too, now you can start the process over with a smaller bad file 4) Rinse, repeat, and binary search until you have small enough bad file that it is simple to figure out what the problem is Or you can just compare a "good" and "bad" file outright and see if the different is easy to spot without all the hacking described above. --047d7bacbbdcff42bd0505e670e9
the.one.eleven+gmail.com on Tue Oct 21 13:57:04 2014 (link), replying to msg
Looking at your "ok" and "faulty" files there is only a single line diff between the, and it is the <time> element in the metadata.
the.one.eleven+gmail.com on Tue Oct 21 13:57:13 2014 (link), replying to msg
Look into XML validation against XSD, it would have detected this problem right away. On Mon, Oct 20, 2014 at 8:36 PM, Matt Hoover <the.one.eleven+gmail.com> wrote: > Looking at your "ok" and "faulty" files there is only a single line diff > between the, and it is the <time> element in the metadata. > > From "ok": <time>2014-10-16T6:06:26Z</time> > From "faulty": <time>2014-10-15T21:07:45Z</time> > > Are you sure you don't have "ok" and "faulty" mixed up? Quick search of > dateTime XSD suggests that hour should be two digits. In your "ok" file > (which I suspect may actually be the faulty one) you only have one digit > for hour. > > On Mon, Oct 20, 2014 at 8:29 PM, Matt Hoover <the.one.eleven+gmail.com> > wrote: > >> Just thinking out loud here, if this is obvious then ignore it. I also >> develop a free GPX related software (gpxcreator.com) though I have not >> been active in that development for over a year. If I was faced with this >> problem and wanted to get to the bottom of it quickly, here is what I would >> do, assuming that I could get a copy of Monterra easily. >> >> 1) Take a "bad" file that won't open in Monterra >> 2) Make two copies of it and cut the track in each copy in half >> 3) One or both of the halves should be "bad" too, now you can start the >> process over with a smaller bad file >> 4) Rinse, repeat, and binary search until you have small enough bad file >> that it is simple to figure out what the problem is >> >> Or you can just compare a "good" and "bad" file outright and see if the >> different is easy to spot without all the hacking described above. >> > > --001a11365af6f1ccb80505e6b2db
speleoluc+gmail.com on Tue Oct 21 19:36:37 2014 (link), replying to msg
Matt, Actually, I don't have that Monterra. I send tentative files to a user who replies once or twice a week after submitting the problem. Based on what he told me, I determined the OK and the Faulty file. Alas, publishing a freeware does not justify purchasing a 700$ device just for testing... I'll fix that hour problem and send him the same files. Thanks for the tip! 2014-10-20 23:48 GMT-04:00 Matt Hoover the.one.eleven+gmail.com [gpsxml] < gpsxml+yahoogroups.com>: > > > Look into XML validation against XSD, it would have detected this problem > right away. > > On Mon, Oct 20, 2014 at 8:36 PM, Matt Hoover <the.one.eleven+gmail.com> > wrote: > >> Looking at your "ok" and "faulty" files there is only a single line diff >> between the, and it is the <time> element in the metadata. >> >> From "ok": <time>2014-10-16T6:06:26Z</time> >> From "faulty": <time>2014-10-15T21:07:45Z</time> >> >> Are you sure you don't have "ok" and "faulty" mixed up? Quick search of >> dateTime XSD suggests that hour should be two digits. In your "ok" file >> (which I suspect may actually be the faulty one) you only have one digit >> for hour. >> >> On Mon, Oct 20, 2014 at 8:29 PM, Matt Hoover <the.one.eleven+gmail.com> >> wrote: >> >>> Just thinking out loud here, if this is obvious then ignore it. I also >>> develop a free GPX related software (gpxcreator.com) though I have not >>> been active in that development for over a year. If I was faced with this >>> problem and wanted to get to the bottom of it quickly, here is what I would >>> do, assuming that I could get a copy of Monterra easily. >>> >>> 1) Take a "bad" file that won't open in Monterra >>> 2) Make two copies of it and cut the track in each copy in half >>> 3) One or both of the halves should be "bad" too, now you can start the >>> process over with a smaller bad file >>> 4) Rinse, repeat, and binary search until you have small enough bad file >>> that it is simple to figure out what the problem is >>> >>> Or you can just compare a "good" and "bad" file outright and see if the >>> different is easy to spot without all the hacking described above. >>> >> >> > > > > -- Luc Le Blanc http://www.speleo.qc.ca/Auriga --20cf3003bb040c48220505f9d10f
kylekai+me.com on Mon Oct 27 06:43:48 2014 (link), replying to msg
Six years later, and there's now a GPX Editor for the Mac: https://itunes.apple.com/us/app/gpx-editor/id924782627?mt=12 https://itunes.apple.com/us/app/gpx-editor/id924782627?mt=12 I'm the developer of the app, so if anyone has used this product please let me know what you think. It's at version 1.2 now, but v1.3 will be posted within a day or so. I'm always looking for ways to make it better. Thanks. Bill
egroups+topografix.com on Wed Dec 03 11:40:26 2014 (link), replying to msg
Hello, Wednesday, December 3, 2014, 2:00:06 PM, Bruce wrote: > Below is a sample I have made to show you of a GPX file containing only one entry. > > <?xml version="1.0" encoding="Windows-1252" standalone="no" ?> > <gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx = > "http://www.garmin.com/xmlschemas/GpxExtensions/v3" > creator="Poigraves" version="1.0" xmlns:xsi = > "http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/1/1/gpx.xsd > http://www.garmin.com/xmlschemas/GpxExtensions/v3 > http://www8.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd"> > <metadata><To be filled in later> > </metadata> > <wpt lat="51.55722" lon="-0.16914"> > <name>2 Willow Road</name> > <extensions> > <gpxx:WaypointExtension> > <gpxx:DisplayMode>SymbolAndName</gpxx:DisplayMode> > <gpxx:PhoneNumber > Category="Phone">+442074356166</gpxx:PhoneNumber> > </gpxx:WaypointExtension> > </extensions> > </wpt> > </gpx> > > My questions are > 1 Can I minimise this file by removing the SymbolAndName line and if not what are they for? > > 2 Is the indenting actually required other than for readability? > > 3 Is it OK for me to remove the > symbol in front of the phone number? > > 4 Is anything else required in this file eg <cmt> ? 1. Yes, you can remove any GPX element and still have a valid GPX file. Elements always have <brackets> around them. You cannot remove attributes, like lat="51.33722". Anything with an equals sign is mandatory, at least in the base GPX spec. 2. No, you can remove all whitespace and formatting. GPX is XML, so whitespace doesn't matter. 3. No, that wouldn't be valid XML. 4. <cmt> is a GPX element, so it's not required. See answer #1. If you're concerned about size, zip the GPX file. Zip compression loves verbose XML like GPX files! -- Dan Foster
robertlipe+gmail.com on Wed Dec 03 15:17:21 2014 (link), replying to msg
What Dan said, but with additional Fly-bys: Please Say No to encoding="Windows-1252" UTF-8, please. Most Garmin devices will choke on a single GPX with 2400 files; heck, many of them choke above 500. Most of the better ones cap a device total of 10K, so you really need to think about restructuring your data. Some Garmin devices have better ways of encoding large data, but it involves their proprietary binary POI files which are quite frail. See the GPX spec for more info. http://www.topografix.com/gpx.asp on what's legal, good practice, and how to validate your files. On Wed, Dec 3, 2014 at 1:40 PM, Dan Foster egroups+topografix.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > Hello, > > Wednesday, December 3, 2014, 2:00:06 PM, Bruce wrote: > > > Below is a sample I have made to show you of a GPX file containing only > one entry. > > > > <?xml version="1.0" encoding="Windows-1252" standalone="no" ?> > > <gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx = > > "http://www.garmin.com/xmlschemas/GpxExtensions/v3" > > creator="Poigraves" version="1.0" xmlns:xsi = > > "http://www.w3.org/2001/XMLSchema-instance" > > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > > http://www.topografix.com/GPX/1/1/gpx.xsd > > http://www.garmin.com/xmlschemas/GpxExtensions/v3 > > http://www8.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd"> > > <metadata><To be filled in later> > > </metadata> > > <wpt lat="51.55722" lon="-0.16914"> > > <name>2 Willow Road</name> > > <extensions> > > <gpxx:WaypointExtension> > > <gpxx:DisplayMode>SymbolAndName</gpxx:DisplayMode> > > <gpxx:PhoneNumber > > Category="Phone">+442074356166</gpxx:PhoneNumber> > > </gpxx:WaypointExtension> > > </extensions> > > </wpt> > > </gpx> > > > > My questions are > > 1 Can I minimise this file by removing the SymbolAndName line and if > not what are they for? > > > > 2 Is the indenting actually required other than for readability? > > > > 3 Is it OK for me to remove the > symbol in front of the phone number? > > > > 4 Is anything else required in this file eg <cmt> ? > > 1. Yes, you can remove any GPX element and still have a valid GPX > file. Elements always have <brackets> around them. You cannot remove > attributes, like lat="51.33722". Anything with an equals sign is > mandatory, at least in the base GPX spec. > > 2. No, you can remove all whitespace and formatting. GPX is XML, so > whitespace doesn't matter. > > 3. No, that wouldn't be valid XML. > > 4. <cmt> is a GPX element, so it's not required. See answer #1. > > > If you're concerned about size, zip the GPX file. Zip compression > loves verbose XML like GPX files! > > > > -- > Dan Foster > > > > ------------------------------------ > Posted by: Dan Foster <egroups+topografix.com> > ------------------------------------ > > > ------------------------------------ > > Yahoo Groups Links > > > > --bcaec520e783a696080509580b7b
robertlipe+gmail.com on Wed Dec 03 16:15:39 2014 (link), replying to msg
Ah, so you're actually interested not in what GPX can do or even what GPX on Garmin receivers can do, but instead in what Garmin's POI Loader can read specifically or in making those files useful to any other readers of GPX. Those rules are indeed different and that's their proprietary POI format that I mentioned. BTW, I turned off your 'requires moderation' flag as you're not a spammer. On Wed, Dec 3, 2014 at 6:02 PM, Bruce Caldwell caldwellkb+aol.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > Hi Robert, > > It's 24000 not 2400. > The Garmin seems to manage 24000 installed using a csv file and POILoader. > I've had no complaints in several years. > I'm hoping they can install the GPX file in much the same way ie via > POILoader. > I believe POILoader (from Garmin) converts both types of file to a GPI > file on the satnav. I'm told that if I use a GPX file to start with in the > installation process then the user will be able to dial direct from his > satnav by tapping the number on the screen. Actually the file with 24000 > entries will have a message instead of a phone number because the locations > are cemeteries but the other files have phone numbers. > > I will change the first line to <?xml version="1.0" encoding="UTF-8"?> as > you suggest. I constructed that test file from a programme called GeePeeEx > Editor and that came with the generated test file. The programme claims to > optimise the data for Garmin satnavs. > > > Bruce Caldwell > > > > -----Original Message----- > From: Robert Lipe robertlipe+gmail.com [gpsxml] <gpsxml+yahoogroups.com> > To: gpsxml <gpsxml+yahoogroups.com> > Sent: Wed, 3 Dec 2014 23:17 > Subject: Re: [gpsxml] GPX file format > > > What Dan said, but with additional Fly-bys: > > Please Say No to encoding="Windows-1252" UTF-8, please. > Most Garmin devices will choke on a single GPX with 2400 files; heck, many > of them choke above 500. Most of the better ones cap a device total of > 10K, so you really need to think about restructuring your data. Some > Garmin devices have better ways of encoding large data, but it involves > their proprietary binary POI files which are quite frail. > > See the GPX spec for more info. http://www.topografix.com/gpx.asp on > what's legal, good practice, and how to validate your files. > > > > > On Wed, Dec 3, 2014 at 1:40 PM, Dan Foster egroups+topografix.com > [gpsxml] <gpsxml+yahoogroups.com> wrote: > >> Hello, >> >> Wednesday, December 3, 2014, 2:00:06 PM, Bruce wrote: >> >> > Below is a sample I have made to show you of a GPX file containing >> only one entry. >> > >> > <?xml version="1.0" encoding="Windows-1252" standalone="no" ?> >> > <gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx = >> > "http://www.garmin.com/xmlschemas/GpxExtensions/v3" >> > creator="Poigraves" version="1.0" xmlns:xsi = >> > "http://www.w3.org/2001/XMLSchema-instance" >> > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 >> > http://www.topografix.com/GPX/1/1/gpx.xsd >> > http://www.garmin.com/xmlschemas/GpxExtensions/v3 >> > http://www8.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd >> "> >> > <metadata><To be filled in later> >> > </metadata> >> > <wpt lat="51.55722" lon="-0.16914"> >> > <name>2 Willow Road</name> >> > <extensions> >> > <gpxx:WaypointExtension> >> > <gpxx:DisplayMode>SymbolAndName</gpxx:DisplayMode> >> > <gpxx:PhoneNumber >> > Category="Phone">+442074356166</gpxx:PhoneNumber> >> > </gpxx:WaypointExtension> >> > </extensions> >> > </wpt> >> > </gpx> >> > >> > My questions are >> > 1 Can I minimise this file by removing the SymbolAndName line and if >> not what are they for? >> > >> > 2 Is the indenting actually required other than for readability? >> > >> > 3 Is it OK for me to remove the > symbol in front of the phone number? >> > >> > 4 Is anything else required in this file eg <cmt> ? >> >> 1. Yes, you can remove any GPX element and still have a valid GPX >> file. Elements always have <brackets> around them. You cannot remove >> attributes, like lat="51.33722". Anything with an equals sign is >> mandatory, at least in the base GPX spec. >> >> 2. No, you can remove all whitespace and formatting. GPX is XML, so >> whitespace doesn't matter. >> >> 3. No, that wouldn't be valid XML. >> >> 4. <cmt> is a GPX element, so it's not required. See answer #1. >> >> >> If you're concerned about size, zip the GPX file. Zip compression >> loves verbose XML like GPX files! >> >> >> >> -- >> Dan Foster >> >> >> >> ------------------------------------ >> Posted by: Dan Foster <egroups+topografix.com> >> ------------------------------------ >> >> >> ------------------------------------ >> >> Yahoo Groups Links >> >> >> >> > > > > --001a11363d0c201ef1050958dc7e
eldar.khaitov+yahoo.com on Tue Dec 09 13:42:06 2014 (link)
First I'll give some preamble. I am a beginner in software engineering and I write a gpx handler tool. I use third-party class for serialization/deserialization. In this class I have GeomertyType property which I suggest responds to "type" in gps schema. In gps schema the annotation is "Type (classification) of the waypoint." and is string. (Note: currently I work with waypoints) In the class property GeometryType can have only 3 values: Track, Route and Waypoint. My waypoits get only "Waypoint" value Is it normal that string type in schema can get only 3 values or I misunderstand something? I don't see other properties that could match "type" field
egroups+topografix.com on Tue Dec 09 13:46:32 2014 (link), replying to msg
Hello, Type is a free-form string field, which allows you to further categorize the waypoint or track data in the GPX file. For example, you might have waypoints with these types: airport parking lot restaurant You might have tracks with these types: road stream hiking trail railway line Most GPS receivers do not use <type>. Some Garmin GPS receivers have a category field, which you might map to <type>. But <type> is intended for use by mapping software or POI software to give meaningful categories to groups of waypoints and tracks. -- Dan Foster
eldar.khaitov+yahoo.com on Fri Jan 02 15:38:14 2015 (link)
Hi. I need some classification information about Extensions. My Garmin device writes this header:http://www.garmin.com/xmlschemas/TrackPointExtensionv1.xsd%22> Only "Creator" and "Version" fields are required. I suggest that all links in the header reference to some extensions. But where does all these extensions come from? Can I get exhaustive information about gpx extensions?
bigjimslade07054+yahoo.com on Mon Jan 05 11:54:59 2015 (link), replying to msg
I would like to generalize this original poster's question. Is there any documentation on the semantics of the GPX format? Thttp://www.topografix.com/gpx.asp Describes the structure but there is effectively nothing on the meaning.
robertlipe+gmail.com on Mon Jan 05 14:07:25 2015 (link), replying to msg
IMO, we did a better job explaining this in the 1.0 doc. http://www.topografix.com/gpx_manual.asp - obviously, some things changed for 1.1, but that doc has more words about the how and the why and less machine-generated dialogs obscuring the content. On Mon, Jan 5, 2015 at 1:20 PM, bigjimslade07054+yahoo.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > I would like to generalize this original poster's question. > > Is there any documentation on the semantics of the GPX format? > > Thttp://www.topografix.com/gpx.asp > > Describes the structure but there is effectively nothing on the meaning. > > > > > --e89a8f83941f4f2721050beeeac9
awayteamsoftware+yahoo.com on Tue Jan 27 11:02:57 2015 (link), replying to msg
Hi, I realise that this is an old topic, but 18 months later it still seems relevant to me. >> Hi Guys, >> I understand GPX has no absolute official mime type for use in emails. >> Is this correct? .. and if not should there not be an official one? >> > >This has come up before (dig around in the archives) but I recall the >prevailing answer was evenly split between "application/gpx+xml" and >"using email to transfer XML data to client apps is _soooo_ 1980's" I'm interested in resolving the issue. MIME media types were originally designed for email attachments, but are now widely used for internet media content everywhere, from websites to mobile phones. As GPX is designed for 'exchanging' GPS data, and Google have already had the good sense to register their (similar) KML format, registering this format as 'application/gpx+xml' seems like a very sensible idea. However, as this has not yet been done, there may be a good reason I'm unaware of, and this forum seems like a sensible place to ask why. Are there technical reasons, costs associated, significant effort required or something other blocker? It currently appears to be a missed opportunity. I await constructive feedback with interest. Rob Away Team ---In gpsxml+yahoogroups.com,wrote : The spec generally doesn't try to compensate for bad programming. What if there is a name tag that's empty and you try to print that? That could cause a nullptr deref which evokes implementation defined behaviour - potentially including a program crash. On Jun 5, 2013 7:37 PM, "Brek" wrote: > ** > I don't know that it's explicitly disallowed, > but that I think it will cause an exception in most software for lack of > forethought. > I suspect that GPSMapedit (for example) tries to draw a line from the > valid point, > to an invalid one, and in the end, displays nothing. > > Same with iOS. No matter what the width of the line is set to, > it will display nothing, and throw an exception. > I simply disallowed it in my program. > > > [Non-text portions of this message have been removed]
heltonbiker+gmail.com on Wed Jan 28 06:30:27 2015 (link), replying to msg
I could not agree more. It bothers me a lot to see GPX being more and more the "de facto" standard for everything GPS related, and yet being sort of "unofficial", regarding MIME type for example. BUT I feel I have to comment on the "(similar) KML type" part. It is right that both are XML based. And it is right that a lot of applications allow for saving the same dataset as both KML or GPX, and allow for conversion from on format to the other. But what is not enough stressed is that they ARE MADE TO STORE COMPLETELY DIFFERENT TYPES OF INFORMATION! It took me a while (and some lost information) to figure out this subtle but fundamental difference. In short, KML should be used to store information about the (rather static) environment, while GPX should be used to store information about (rather dynamic) MOVING OBJECTS, which are NOT part of the environment at all. For example, if you were to use a mapping application to represent a bicycle race, you could have a KML layer with the route and reference points, for example, and one (or more) GPX layer(s) representing the runner's trajectory (which contain time information). I know Google has already invented some time-oriented KML elements (namely gx:Track, gx:MultiTrack, gx:TimeSpan and gx:TimeStamp, but the representation is verbose and smells hackish). (I apologize for the caps-lock parts, it's not my intention to be rude at all, but only to stress the parts of this message I find deserve to be stressed). Sincerely Helton Moraes ---In gpsxml+yahoogroups.com,wrote : Hi, I realise that this is an old topic, but 18 months later it still seems relevant to me. >> Hi Guys, >> I understand GPX has no absolute official mime type for use in emails. >> Is this correct? .. and if not should there not be an official one? >> > >This has come up before (dig around in the archives) but I recall the >prevailing answer was evenly split between "application/gpx+xml" and >"using email to transfer XML data to client apps is _soooo_ 1980's" I'm interested in resolving the issue. MIME media types were originally designed for email attachments, but are now widely used for internet media content everywhere, from websites to mobile phones. As GPX is designed for 'exchanging' GPS data, and Google have already had the good sense to register their (similar) KML format, registering this format as 'application/gpx+xml' seems like a very sensible idea. However, as this has not yet been done, there may be a good reason I'm unaware of, and this forum seems like a sensible place to ask why. Are there technical reasons, costs associated, significant effort required or something other blocker? It currently appears to be a missed opportunity. I await constructive feedback with interest. Rob Away Team ---In gpsxml+yahoogroups.com, wrote : The spec generally doesn't try to compensate for bad programming. What if there is a name tag that's empty and you try to print that? That could cause a nullptr deref which evokes implementation defined behaviour - potentially including a program crash. On Jun 5, 2013 7:37 PM, "Brek" wrote: > ** > I don't know that it's explicitly disallowed, > but that I think it will cause an exception in most software for lack of > forethought. > I suspect that GPSMapedit (for example) tries to draw a line from the > valid point, > to an invalid one, and in the end, displays nothing. > > Same with iOS. No matter what the width of the line is set to, > it will display nothing, and throw an exception. > I simply disallowed it in my program. > > > [Non-text portions of this message have been removed]
egroups+topografix.com on Wed Jan 28 07:31:11 2015 (link), replying to msg
Hello, For those of you who would like to see an official mimetype for GPX: What do you feel is being missed by not having an official mimetype? If, tomorrow, the IETF said " 'application/gpx+xml' is the official mimetype for GPX", what would change? What would you do differently? What would IE/Firefox/Chrome do differently? What would your Web server do differently? I ask these questions because I honestly don't know the answers. -- Dan Foster
awayteamsoftware+yahoo.com on Wed Jan 28 09:05:19 2015 (link), replying to msg
Hello, Wednesday, January 28, 2015, 11:01:46 AM, Brek wrote: > What I feel is being missed by not having an official mime type is > best order, as pedantic as it might sound. > So no-one has to worry about the right mime type at the time when > there�s enough to think about busy programming > a bunch of hierarchy search, especially if it�s the first shot at > it. With enough time over a lot of people it�s a real saving. I have no problem updating the documentation to suggest a mime type for GPX developers to use. And a first step towards official registration of a mime type would be agreeing upon which mime type to use. Perhaps those with vested interest in this or that are already serving up GPX could reply and tell us what media type they've chosen for GPX files, and explain their decision. I'll get the ball rolling: URL: http://data.expertgps.com/data/ma/ma-churches.gpx content-type: "application/octet-stream" why: not sure if I selected this, or it's just the server's default, but it triggers a Save As dialog which is what I want. For anyone who wants to look at how other proposed content-types would behave, here are two files on an Amazon S3 server with their content types set as follows: URL: http://data.expertgps.com/data/ak/ak-airports.gpx content-type: "application/gpx+xml" URL: http://data.expertgps.com/data/ak/ak-camps.gpx content-type: "vnd.topografix.gpx+xml" p.s. Messages on this email list are moderated now (due to spammers in the past) so if you don't see your replies, wait a bit for one of the moderators to approve it. -- Dan Foster
awayteamsoftware+yahoo.com on Wed Jan 28 09:30:55 2015 (link), replying to msg
Thanks for the great feedback so far. +Dan: I can answer your question in a single word: 'communication'. MIME is a standard method for describing file content, on everything from websites to mobile phones, and adding GPX to that list would allow and encourage developers to handle location data files as easily as JPEGs or MP3s are handled today. As GPS receivers are becoming as common in smartphones as cameras, I believe the time has come to make that 'missing link'. I'm honestly amazed that it has not already been done. Which brings me back to my original question: why? Is there something blocking MIME registration? And if so, what is the issue? I'm happy to make the running on this, but wanted to establish whether there is a pitfall I should be aware of first. Rob Away Team
robertlipe+gmail.com on Wed Jan 28 09:47:52 2015 (link), replying to msg
I'd be behind a split recommendation. If you're a web site just offering up data to be used in an arbitrary program, application/octet-stream is almost surely what you want. Sometimes, I want GPX in Earth. Approximately never do I want it in Mapsource. Almost always, I want it as a plain pile of bytes on my system that I can look at in a text editor, validate, feed to GPSBabel, or whatever. If you're controlling both ends of the connection, application/gpx+xml is fine. Your Javascript thingy can use that as a hint that you're reading GPX from the web app you control. I don't want to disambiguate which of the multiple GPX consumers in my life. Perhaps something like: "For services offering a custom MIME type , we recommend application/gpx+xml. For the common case of raw file delivery, we recommend application/octet-stream." Every service I've ever built where I've controlled only one end has used application/octet-stream successfully and nobody's fussed. In cases where I'm doing webapp-type things, I've used application/gpx+xml and a custom reader and the browser knows not to offer a "save as" dialogue. On Wed, Jan 28, 2015 at 10:37 AM, awayteamsoftware+yahoo.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > Thanks for the great feedback so far. > > +Dan: I can answer your question in a single word: 'communication'. > > MIME is a standard method for describing file content, on everything from > websites to mobile phones, and adding GPX to that list would allow and > encourage developers to handle location data files as easily as JPEGs or > MP3s are handled today. > > As GPS receivers are becoming as common in smartphones as cameras, I > believe the time has come to make that 'missing link'. I'm honestly amazed > that it has not already been done. > > Which brings me back to my original question: why? Is there something > blocking MIME registration? And if so, what is the issue? > > I'm happy to make the running on this, but wanted to establish whether > there is a pitfall I should be aware of first. > > Rob > Away Team > > > > --001a11c3bcbc5da6a8050db9f8a7
awayteamsoftware+yahoo.com on Thu Jan 29 03:29:46 2015 (link), replying to msg
+Dan: I agree. I think the key steps are: 1. Agree a name for the GPX MIME type. 2. Register it with IANA. 3. See the registration through to completion. 4. Start using the new type and encourage others to follow suit. This should not be an onerous task. As I previously mentioned, I am happy to make the running here. However, it would be even better if Topografix made this move themselves, which would be a clear statement of their continued support for it, and I'd be happy to help where I can. To answer Dan's question: One of GPX's strengths is that promotes interoperability, without tying users or developers to a specific corporation, and is an existing lightweight standard for recording location data used by many companies, not just Topografix. Away Team's preference is 'application/gpx+xml' for the simple reason that it is a *generic* standard, and more likely to be universally accepted. The alternative 'vnd.topografix.gpx+xml' sounds more like a proprietary format, and may actually discourage developers from using it due to its nomenclature. I think there are two other relevant points worth mentioning here: a. It is interesting that the ubiquitous PDF MIME type is 'application/pdf', rather than 'vnd.adobe.pdf'. I think we would be wise to take a similar approach. b. To my surprise, my copy of Firefox (v35.0.1) is already aware of 'Document(application/gpx+xml)', which implies that this name is already in general use unofficially. Please check Preferences->Applications in your own copy to confirm. Rob Away Team
awayteamsoftware+yahoo.com on Thu Jan 29 03:32:00 2015 (link), replying to msg
+Robert: The MIME type only describes the file content - is it GPX: yes or no. It really is that simple. It does *not* describe any associated actions. In your web browser example, it is the browser which performs the actions based on the MIME type presented to it. For instance, Firefox allows three possible actions - use a specific app, save the file or ask the user. It sounds as though your preference is 'always ask' for GPX, but that does not affect the contents of the file. Labelling the file with a GPX MIME type allows everyone to make an informed decision: you can configure your browser appropriately, and other users can make their choices independently. Ironically, 'always ask' probably involves the browser asking the OS which apps can handle this MIME type, so that it can construct a list of possible apps for the user to choose from, e.g. Google Earth, Mapsource, text editor, etc. So MIME actually has *two* uses in your example. And that raises a good point, we should bear in mind that MIME types have many uses in many diverse environments, and should avoid getting too fixated on a single case. Rob Away Team
awayteamsoftware+yahoo.com on Wed Feb 04 04:45:56 2015 (link), replying to msg
Dan, I've seen no further comments over the past week, and am keen to keep this moving. Hopefully, there has been some internal discussion of this issue at Topografix in the interim. I would be interested to know the current state of play, and look forward to hearing from you soon. Rob Away Team
bigjimslade07054+yahoo.com on Thu Feb 05 02:44:58 2015 (link)
The current GPX specification gives no semantic information whatsoever. Asking about that previous, I was referred to the V1.0 docs. In V1.0 thetag includes TIME, SPEED COURSE These are not present in the current GPX version. What are the corresponding elements now?
robertlipe+gmail.com on Mon Feb 09 12:34:19 2015 (link), replying to msg
Speed and course were erroneously omitted from 1.1. Some argue that they're not necessary as they can usually be computed from other data (if you have time and location of two successive points, you have speed, but some arguments with specialized sensors and around cases like high speed switchbacks - In one second, I travelled 100m due north and then 75m south - some uses really want to report 175m/sec and not 25... In practice, it's pretty rare. Similar edge cases exist for course. The three answers that come up every time are: 1) Use GPX 1.0 2) Use one of the GPX extensions, like Garmins, that adds these. 3) Just Write Them, creating technically invalid GPX that won't validate, but in the knowledge that sane XML readers ignore tags they don't understand. 2 and 3 aren't great because you then have to get all your readers to handle the same extension for case 2 or the hyperactive readers that get all flipped out about what the "X" in "XML" means and throw errors for case 3. See previous discussion - with links to many previous discussion - at https://groups.yahoo.com/neo/groups/gpsxml/conversations/topics/2221 The links in my answer no longer works (thanx, Yahoo, for breaking the internet...) but fiddling with the URL in "obvious" ways On Wed, Feb 4, 2015 at 10:37 PM, bigjimslade07054+yahoo.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > The current GPX specification gives no semantic information whatsoever. > Asking about that previous, I was referred to the V1.0 docs. > > > In V1.0 the <WPT> tag includes > > > TIME, SPEED COURSE > > > These are not present in the current GPX version. What are the > corresponding elements now? > > > > --001a113f19e6c06693050eadb1f8
awayteamsoftware+yahoo.com on Wed Feb 11 08:22:31 2015 (link), replying to msg
Two weeks have now passed since I raised my issue so, in the absence of any further responses, I will proceed as planned. Thank you all for your feedback. Rob Away Team
kylekai+me.com on Wed Mar 18 17:55:01 2015 (link)
When I look at the documentation for bounds http://www.topografix.com/GPX/1/1/#type_boundsType http://www.topografix.com/GPX/1/1/#type_boundsType it shows the example:boundsType http://www.topografix.com/GPX/1/1/#type_boundsType but when I use that format, Garmin Basecamp won't import it. For example:Basecamp won't accept it. But if I use this format instead: Basecamp imports the file. Is this a Basecamp quirk? Or is the documentation wrong? Or ?? Thanks.
egroups+topografix.com on Wed Mar 18 17:57:47 2015 (link), replying to msg
Hello, Wednesday, March 18, 2015, 6:23:34 PM, kylekai+me.com wrote: > > > > > > When I look at the documentation for bounds > http://www.topografix.com/GPX/1/1/#type_boundsType > it shows the example: <bounds> boundsType </bounds> > but when I use that format, Garmin Basecamp won't import it. > For example: > <bounds minlat="32.9604745" minlon="-116.5476687" > maxlat="33.3037576" maxlon="-116.0965581"></bounds> > Basecamp won't accept it. But if I use this format instead: > <bounds minlat="32.9604745" minlon="-116.5476687" > maxlat="33.3037576" maxlon="-116.0965581"/> > Basecamp imports the file. > Is this a Basecamp quirk? Or is the documentation wrong? Or ?? > Thanks. I don't see the example you gave anywhere in the documentation. This is correct: <bounds minlat="32.9604745" minlon="-116.5476687" maxlat="33.3037576" maxlon="-116.0965581"/> -- Dan Foster
kylekai+me.com on Thu Mar 19 11:00:23 2015 (link), replying to msg
Dan, It's there -- see the image from this link: https://dl.dropboxusercontent.com/u/5872971/temp/GPX/GPXBounds.png https://dl.dropboxusercontent.com/u/5872971/temp/GPX/GPXBounds.png Thanks! Bill
chris.f.stephenson+gmail.com on Thu Mar 19 11:28:37 2015 (link), replying to msg
Hey Bill, Both of the supplied XML tags are technically correct. <bounds minlat="32.9604745" minlon="-116.5476687" maxlat="33.3037576" maxlon="-116.0965581"></bounds> <bounds minlat="32.9604745" minlon="-116.5476687" maxlat="33.3037576" maxlon="-116.0965581"/> I'd be willing to bet this is a peculiar behavior with Basecamp. On Thu, Mar 19, 2015 at 11:40 AM, kylekai+me.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > Dan, > > It's there -- see the image from this link: > > https://dl.dropboxusercontent.com/u/5872971/temp/GPX/GPXBounds.png > > Thanks! > Bill > > > -- Chris Stephenson "Your next action could change the world, so make it a good one." --001a11470798e436880511a8247c
robertlipe+gmail.com on Thu Mar 19 12:36:19 2015 (link), replying to msg
Self-closing tags are part of the XML spec. If Basecamp doesn't tread these two lines the same (assuming proper context, asbsence of non-obvious hidden characters that were committed from copy-paste into email and other "trick questions"), Basecamp is wrong, IMO. Any GPX reader that throws an error (recognizing all the content is different...) an GPX file that validates is being a bad citizen. Validation of GPX is the formal line in the sand between readers and writers. On Thu, Mar 19, 2015 at 1:12 PM, Chris Stephenson chris.f.stephenson+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > Hey Bill, > > Both of the supplied XML tags are technically correct. > > <bounds minlat="32.9604745" minlon="-116.5476687" maxlat="33.3037576" > maxlon="-116.0965581"></bounds> > <bounds minlat="32.9604745" minlon="-116.5476687" maxlat="33.3037576" > maxlon="-116.0965581"/> > > I'd be willing to bet this is a peculiar behavior with Basecamp. > > On Thu, Mar 19, 2015 at 11:40 AM, kylekai+me.com [gpsxml] < > gpsxml+yahoogroups.com> wrote: > >> >> >> Dan, >> >> It's there -- see the image from this link: >> >> https://dl.dropboxusercontent.com/u/5872971/temp/GPX/GPXBounds.png >> >> Thanks! >> Bill >> >> > > > -- > Chris Stephenson > "Your next action could change the world, so make it a good one." > > > > --001a113a304e55b98f0511a950fe
kylekai+me.com on Thu Mar 19 13:23:21 2015 (link), replying to msg
If I use your first example, Basecamp won't import the file; gives an error. If I replace it with your 2nd example, Basecamp imports the file. It's particularly bothersome to me because I developed a GPX Editor app, and it uses the first example for the bounds. When people use my app, then rate it poorly because Basecamp won't import the files it saves. So I had to change the source just to accommodate Basecamp. Thanks for the replies. Hopefully I've fixed the Basecamp issue.
robertlipe+gmail.com on Thu Mar 19 13:35:49 2015 (link), replying to msg
You've merely made it the problem of OTHER gpx writers. If your output validates and Basecamp won't read it, that should be escalated to Garmin and you should be able to point your customers to the bugreport until it's fixed in their reader. The whole point of GPX is for GPX writers to not have to customize our output to deal with multiple readers. On Thu, Mar 19, 2015 at 3:23 PM, kylekai+me.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > If I use your first example, Basecamp won't import the file; gives an > error. If I replace it with your 2nd example, Basecamp imports the file. > > It's particularly bothersome to me because I developed a GPX Editor app, > and it uses the first example for the bounds. When people use my app, then > rate it poorly because Basecamp won't import the files it saves. So I had > to change the source just to accommodate Basecamp. > > Thanks for the replies. Hopefully I've fixed the Basecamp issue. > > > > --001a11c150b61adceb0511aa255b
kylekai+me.com on Thu Mar 19 14:14:15 2015 (link), replying to msg
It doesn't matter what I point out to my customers; it's like telling them to read the manual (they won't). Customers don't want excuses, they want results (which leads to more sales). But if either format is technically correct, I might as well use the format that is accepted by Basecamp. My code can read either format, and I suspect most other GPX readers can as well. I will contact Garmin as you suggested. There are some other problems with their reader as well. Thanks, Bill
kylekai+me.com on Fri Mar 20 11:45:35 2015 (link), replying to msg
I sent an email to Garmin. If they reply I'll post what they say, although I don't expect much. Last time I asked them a question their reply included this: "There is no exact standard for "GPX" files."
chris.f.stephenson+gmail.com on Fri Mar 20 11:52:42 2015 (link), replying to msg
There is, however, a standard for XML files. And <bounds /> and <bounds></bounds> are both acceptable. On Fri, Mar 20, 2015 at 2:45 PM, kylekai+me.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > I sent an email to Garmin <Product.Support+garmin.com>. If they reply > I'll post what they say, although I don't expect much. Last time I asked > them a question their reply included this: "There is no exact standard for > "GPX" files." > > -- Chris Stephenson "Your next action could change the world, so make it a good one." --001a11473a7cbab8350511bcbbe1
robertlipe+gmail.com on Fri Mar 20 12:12:16 2015 (link), replying to msg
What Chris said. There is an "exact standard" - http://www.topografix.com/gpx.asp At some level (probably not at the phone-answering 800 number level) Garmin knows this as they used to have members on this very list. On Fri, Mar 20, 2015 at 1:46 PM, Chris Stephenson chris.f.stephenson+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > There is, however, a standard for XML files. And <bounds /> and > <bounds></bounds> are both acceptable. > > On Fri, Mar 20, 2015 at 2:45 PM, kylekai+me.com [gpsxml] < > gpsxml+yahoogroups.com> wrote: > >> >> >> I sent an email to Garmin <Product.Support+garmin.com>. If they reply >> I'll post what they say, although I don't expect much. Last time I asked >> them a question their reply included this: "There is no exact standard for >> "GPX" files." >> > > > > -- > Chris Stephenson > "Your next action could change the world, so make it a good one." > > > > --001a113ad64826ca640511bd1862
pauleyc+yahoo.com on Fri Mar 20 14:47:43 2015 (link), replying to msg
Hi Chris,Your claim that <bounds></bounds> and <bounds><bounds/> are both acceptable is not true. <bounds><bounds/> is invalid xml according to http://www.w3schools.com/xml/xml_validator.asp All the best,Chris Pauley On Friday, March 20, 2015 2:52 PM, "Chris Stephenson chris.f.stephenson+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: There is, however, a standard for XML files. And <bounds /> and <bounds></bounds> are both acceptable. On Fri, Mar 20, 2015 at 2:45 PM, kylekai+me.com [gpsxml] <gpsxml+yahoogroups.com> wrote: I sent an email to Garmin <Product.Support+garmin.com>. If they reply I'll post what they say, although I don't expect much. Last time I asked them a question their reply included this: "There is no exact standard for "GPX" files." -- Chris Stephenson "Your next action could change the world, so make it a good one." #yiv3451487307 #yiv3451487307 -- #yiv3451487307ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3451487307 #yiv3451487307ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3451487307 #yiv3451487307ygrp-mkp #yiv3451487307hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv3451487307 #yiv3451487307ygrp-mkp #yiv3451487307ads {margin-bottom:10px;}#yiv3451487307 #yiv3451487307ygrp-mkp .yiv3451487307ad {padding:0 0;}#yiv3451487307 #yiv3451487307ygrp-mkp .yiv3451487307ad p {margin:0;}#yiv3451487307 #yiv3451487307ygrp-mkp .yiv3451487307ad a {color:#0000ff;text-decoration:none;}#yiv3451487307 #yiv3451487307ygrp-sponsor #yiv3451487307ygrp-lc {font-family:Arial;}#yiv3451487307 #yiv3451487307ygrp-sponsor #yiv3451487307ygrp-lc #yiv3451487307hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3451487307 #yiv3451487307ygrp-sponsor #yiv3451487307ygrp-lc .yiv3451487307ad {margin-bottom:10px;padding:0 0;}#yiv3451487307 #yiv3451487307actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3451487307 #yiv3451487307activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3451487307 #yiv3451487307activity span {font-weight:700;}#yiv3451487307 #yiv3451487307activity span:first-child {text-transform:uppercase;}#yiv3451487307 #yiv3451487307activity span a {color:#5085b6;text-decoration:none;}#yiv3451487307 #yiv3451487307activity span span {color:#ff7900;}#yiv3451487307 #yiv3451487307activity span .yiv3451487307underline {text-decoration:underline;}#yiv3451487307 .yiv3451487307attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv3451487307 .yiv3451487307attach div a {text-decoration:none;}#yiv3451487307 .yiv3451487307attach img {border:none;padding-right:5px;}#yiv3451487307 .yiv3451487307attach label {display:block;margin-bottom:5px;}#yiv3451487307 .yiv3451487307attach label a {text-decoration:none;}#yiv3451487307 blockquote {margin:0 0 0 4px;}#yiv3451487307 .yiv3451487307bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv3451487307 .yiv3451487307bold a {text-decoration:none;}#yiv3451487307 dd.yiv3451487307last p a {font-family:Verdana;font-weight:700;}#yiv3451487307 dd.yiv3451487307last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3451487307 dd.yiv3451487307last p span.yiv3451487307yshortcuts {margin-right:0;}#yiv3451487307 div.yiv3451487307attach-table div div a {text-decoration:none;}#yiv3451487307 div.yiv3451487307attach-table {width:400px;}#yiv3451487307 div.yiv3451487307file-title a, #yiv3451487307 div.yiv3451487307file-title a:active, #yiv3451487307 div.yiv3451487307file-title a:hover, #yiv3451487307 div.yiv3451487307file-title a:visited {text-decoration:none;}#yiv3451487307 div.yiv3451487307photo-title a, #yiv3451487307 div.yiv3451487307photo-title a:active, #yiv3451487307 div.yiv3451487307photo-title a:hover, #yiv3451487307 div.yiv3451487307photo-title a:visited {text-decoration:none;}#yiv3451487307 div#yiv3451487307ygrp-mlmsg #yiv3451487307ygrp-msg p a span.yiv3451487307yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3451487307 .yiv3451487307green {color:#628c2a;}#yiv3451487307 .yiv3451487307MsoNormal {margin:0 0 0 0;}#yiv3451487307 o {font-size:0;}#yiv3451487307 #yiv3451487307photos div {float:left;width:72px;}#yiv3451487307 #yiv3451487307photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv3451487307 #yiv3451487307photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3451487307 #yiv3451487307reco-category {font-size:77%;}#yiv3451487307 #yiv3451487307reco-desc {font-size:77%;}#yiv3451487307 .yiv3451487307replbq {margin:4px;}#yiv3451487307 #yiv3451487307ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv3451487307 #yiv3451487307ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3451487307 #yiv3451487307ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3451487307 #yiv3451487307ygrp-mlmsg select, #yiv3451487307 input, #yiv3451487307 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv3451487307 #yiv3451487307ygrp-mlmsg pre, #yiv3451487307 code {font:115% monospace;}#yiv3451487307 #yiv3451487307ygrp-mlmsg * {line-height:1.22em;}#yiv3451487307 #yiv3451487307ygrp-mlmsg #yiv3451487307logo {padding-bottom:10px;}#yiv3451487307 #yiv3451487307ygrp-msg p a {font-family:Verdana;}#yiv3451487307 #yiv3451487307ygrp-msg p#yiv3451487307attach-count span {color:#1E66AE;font-weight:700;}#yiv3451487307 #yiv3451487307ygrp-reco #yiv3451487307reco-head {color:#ff7900;font-weight:700;}#yiv3451487307 #yiv3451487307ygrp-reco {margin-bottom:20px;padding:0px;}#yiv3451487307 #yiv3451487307ygrp-sponsor #yiv3451487307ov li a {font-size:130%;text-decoration:none;}#yiv3451487307 #yiv3451487307ygrp-sponsor #yiv3451487307ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv3451487307 #yiv3451487307ygrp-sponsor #yiv3451487307ov ul {margin:0;padding:0 0 0 8px;}#yiv3451487307 #yiv3451487307ygrp-text {font-family:Georgia;}#yiv3451487307 #yiv3451487307ygrp-text p {margin:0 0 1em 0;}#yiv3451487307 #yiv3451487307ygrp-text tt {font-size:120%;}#yiv3451487307 #yiv3451487307ygrp-vital ul li:last-child {border-right:none !important;}#yiv3451487307 ------?art_1610700_1851029272.1426888060240
ldeffenb+homeside.to on Fri Mar 20 14:54:50 2015 (link), replying to msg
Read more closely and don't move characters around. <bounds /> is the same as <bounds></bounds>. You moved the slash in the closing tag making it not the same thing. Although <bounds><bounds/></bounds> would be acceptable, but rather nonsensical and not GPX file compliant. Lynn (D) - Author of APRSISCE for Windows Mobile and Win32 On 3/20/2015 5:47 PM, Chris Pauley pauleyc+yahoo.com [gpsxml] wrote: > > > Hi Chris, > Your claim that <bounds></bounds> and <bounds><bounds/> are both > acceptable is not true. > <bounds><bounds/> is invalid xml according to > http://www.w3schools.com/xml/xml_validator.asp > > All the best, > Chris Pauley > > > > > > > On Friday, March 20, 2015 2:52 PM, "Chris Stephenson > chris.f.stephenson+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: > > > There is, however, a standard for XML files. And <bounds /> and > <bounds></bounds> are both acceptable. > > On Fri, Mar 20, 2015 at 2:45 PM, kylekai+me.com > <mailto:kylekai+me.com> [gpsxml] <gpsxml+yahoogroups.com > <mailto:gpsxml+yahoogroups.com>> wrote: > > I sent an email to Garmin <Product.Support+garmin.com > <mailto:Product.Support+garmin.com>>. If they reply I'll post what > they say, although I don't expect much. Last time I asked them a > question their reply included this: "There is no exact standard > for "GPX" files." > > > > > -- > Chris Stephenson > "Your next action could change the world, so make it a good one." > > > > > --------------020008040007010607020704
robertlipe+gmail.com on Fri Mar 20 14:56:09 2015 (link), replying to msg
Pasting the fragment below and clicking validate says "no errors found" for both GPX 1.0 and 1.1. (Obviously, I deleted the actual wpts below...) <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" xmlns=" http://www.topografix.com/GPX/1/0"> <time>2015-03-20T21:51:36.370Z</time> <bounds minlat="35.972033333" minlon="-87.134700000" maxlat="36.112183333" maxlon="-86.620116667"/> </gpx> <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.1" creator="GPSBabel - http://www.gpsbabel.org" xmlns=" http://www.topografix.com/GPX/1/1"> <metadata> <time>2015-03-20T21:53:51.663Z</time> <bounds minlat="35.972033333" minlon="-87.134700000" maxlat="36.112183333" maxlon="-86.620116667"/> </metadata> </gpx> Self closing tags are compliant XML and thus GPX. On Fri, Mar 20, 2015 at 4:47 PM, Chris Pauley pauleyc+yahoo.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > Hi Chris, > Your claim that <bounds></bounds> and <bounds><bounds/> are both > acceptable is not true. > <bounds><bounds/> is invalid xml according to > http://www.w3schools.com/xml/xml_validator.asp > > All the best, > Chris Pauley > > > > > > > > On Friday, March 20, 2015 2:52 PM, "Chris Stephenson > chris.f.stephenson+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: > > > > There is, however, a standard for XML files. And <bounds /> and > <bounds></bounds> are both acceptable. > > On Fri, Mar 20, 2015 at 2:45 PM, kylekai+me.com [gpsxml] < > gpsxml+yahoogroups.com> wrote: > > > I sent an email to Garmin <Product.Support+garmin.com>. If they reply > I'll post what they say, although I don't expect much. Last time I asked > them a question their reply included this: "There is no exact standard for > "GPX" files." > > > > > -- > Chris Stephenson > "Your next action could change the world, so make it a good one." > > > > > > --001a11c150b64d53910511bf62a5
chris.f.stephenson+gmail.com on Fri Mar 20 15:23:55 2015 (link), replying to msg
Hi Chris, Thanks for that, but if you read over the thread again, you'll notice that I never said <bounds><bounds/> (two tags), but instead just <bounds/> (one tag). What you see in the one-tag example is the empty-element tag, a well-documented W3C specification which you can find here: http://www.w3.org/TR/xml/#sec-starttags An element with no content is said to be empty. The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag. Using the validator you provided, both of the following validate as expected: <bounds></bounds> and <bounds /> Regards, Chris Stephenson On Fri, Mar 20, 2015 at 5:47 PM, Chris Pauley pauleyc+yahoo.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > Hi Chris, > Your claim that <bounds></bounds> and <bounds><bounds/> are both > acceptable is not true. > <bounds><bounds/> is invalid xml according to > http://www.w3schools.com/xml/xml_validator.asp > > All the best, > Chris Pauley > > > > > > > > On Friday, March 20, 2015 2:52 PM, "Chris Stephenson > chris.f.stephenson+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: > > > > There is, however, a standard for XML files. And <bounds /> and > <bounds></bounds> are both acceptable. > > On Fri, Mar 20, 2015 at 2:45 PM, kylekai+me.com [gpsxml] < > gpsxml+yahoogroups.com> wrote: > > > I sent an email to Garmin <Product.Support+garmin.com>. If they reply > I'll post what they say, although I don't expect much. Last time I asked > them a question their reply included this: "There is no exact standard for > "GPX" files." > > > > > -- > Chris Stephenson > "Your next action could change the world, so make it a good one." > > > > -- Chris Stephenson "Your next action could change the world, so make it a good one." --001a114591fc9738620511bf5875
pauleyc+yahoo.com on Fri Mar 20 15:52:09 2015 (link), replying to msg
Hi Chris,Sorry for my misunderstanding. I see the point you made. I'm disappointed for kylekai's issue with Garmen Basecamp. Fortunately, the work around produces valid xml.Garmen is a pretty big gorilla in the room in this space. It'd be nice if they cared enough to fix their app. -Chris Pauley On Friday, March 20, 2015 6:24 PM, "Chris Stephenson chris.f.stephenson+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: Hi Chris, Thanks for that, but if you read over the thread again, you'll notice that I never said <bounds><bounds/> (two tags), but instead just <bounds/> (one tag). What you see in the one-tag example is the empty-element tag, a well-documented W3C specification which you can find here: http://www.w3.org/TR/xml/#sec-starttags An element with no content is said to be empty. The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag. Using the validator you provided, both of the following validate as expected: <bounds></bounds>and<bounds /> Regards,Chris Stephenson On Fri, Mar 20, 2015 at 5:47 PM, Chris Pauley pauleyc+yahoo.com [gpsxml] <gpsxml+yahoogroups.com> wrote: Hi Chris,Your claim that <bounds></bounds> and <bounds><bounds/> are both acceptable is not true. <bounds><bounds/> is invalid xml according to http://www.w3schools.com/xml/xml_validator.asp All the best,Chris Pauley On Friday, March 20, 2015 2:52 PM, "Chris Stephenson chris.f.stephenson+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: There is, however, a standard for XML files. And <bounds /> and <bounds></bounds> are both acceptable. On Fri, Mar 20, 2015 at 2:45 PM, kylekai+me.com [gpsxml] <gpsxml+yahoogroups.com> wrote: I sent an email to Garmin <Product.Support+garmin.com>. If they reply I'll post what they say, although I don't expect much. Last time I asked them a question their reply included this: "There is no exact standard for "GPX" files." -- Chris Stephenson "Your next action could change the world, so make it a good one." -- Chris Stephenson "Your next action could change the world, so make it a good one." #yiv1069642204 #yiv1069642204 -- #yiv1069642204ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1069642204 #yiv1069642204ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1069642204 #yiv1069642204ygrp-mkp #yiv1069642204hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv1069642204 #yiv1069642204ygrp-mkp #yiv1069642204ads {margin-bottom:10px;}#yiv1069642204 #yiv1069642204ygrp-mkp .yiv1069642204ad {padding:0 0;}#yiv1069642204 #yiv1069642204ygrp-mkp .yiv1069642204ad p {margin:0;}#yiv1069642204 #yiv1069642204ygrp-mkp .yiv1069642204ad a {color:#0000ff;text-decoration:none;}#yiv1069642204 #yiv1069642204ygrp-sponsor #yiv1069642204ygrp-lc {font-family:Arial;}#yiv1069642204 #yiv1069642204ygrp-sponsor #yiv1069642204ygrp-lc #yiv1069642204hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1069642204 #yiv1069642204ygrp-sponsor #yiv1069642204ygrp-lc .yiv1069642204ad {margin-bottom:10px;padding:0 0;}#yiv1069642204 #yiv1069642204actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1069642204 #yiv1069642204activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1069642204 #yiv1069642204activity span {font-weight:700;}#yiv1069642204 #yiv1069642204activity span:first-child {text-transform:uppercase;}#yiv1069642204 #yiv1069642204activity span a {color:#5085b6;text-decoration:none;}#yiv1069642204 #yiv1069642204activity span span {color:#ff7900;}#yiv1069642204 #yiv1069642204activity span .yiv1069642204underline {text-decoration:underline;}#yiv1069642204 .yiv1069642204attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv1069642204 .yiv1069642204attach div a {text-decoration:none;}#yiv1069642204 .yiv1069642204attach img {border:none;padding-right:5px;}#yiv1069642204 .yiv1069642204attach label {display:block;margin-bottom:5px;}#yiv1069642204 .yiv1069642204attach label a {text-decoration:none;}#yiv1069642204 blockquote {margin:0 0 0 4px;}#yiv1069642204 .yiv1069642204bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv1069642204 .yiv1069642204bold a {text-decoration:none;}#yiv1069642204 dd.yiv1069642204last p a {font-family:Verdana;font-weight:700;}#yiv1069642204 dd.yiv1069642204last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv1069642204 dd.yiv1069642204last p span.yiv1069642204yshortcuts {margin-right:0;}#yiv1069642204 div.yiv1069642204attach-table div div a {text-decoration:none;}#yiv1069642204 div.yiv1069642204attach-table {width:400px;}#yiv1069642204 div.yiv1069642204file-title a, #yiv1069642204 div.yiv1069642204file-title a:active, #yiv1069642204 div.yiv1069642204file-title a:hover, #yiv1069642204 div.yiv1069642204file-title a:visited {text-decoration:none;}#yiv1069642204 div.yiv1069642204photo-title a, #yiv1069642204 div.yiv1069642204photo-title a:active, #yiv1069642204 div.yiv1069642204photo-title a:hover, #yiv1069642204 div.yiv1069642204photo-title a:visited {text-decoration:none;}#yiv1069642204 div#yiv1069642204ygrp-mlmsg #yiv1069642204ygrp-msg p a span.yiv1069642204yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv1069642204 .yiv1069642204green {color:#628c2a;}#yiv1069642204 .yiv1069642204MsoNormal {margin:0 0 0 0;}#yiv1069642204 o {font-size:0;}#yiv1069642204 #yiv1069642204photos div {float:left;width:72px;}#yiv1069642204 #yiv1069642204photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv1069642204 #yiv1069642204photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv1069642204 #yiv1069642204reco-category {font-size:77%;}#yiv1069642204 #yiv1069642204reco-desc {font-size:77%;}#yiv1069642204 .yiv1069642204replbq {margin:4px;}#yiv1069642204 #yiv1069642204ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv1069642204 #yiv1069642204ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv1069642204 #yiv1069642204ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv1069642204 #yiv1069642204ygrp-mlmsg select, #yiv1069642204 input, #yiv1069642204 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv1069642204 #yiv1069642204ygrp-mlmsg pre, #yiv1069642204 code {font:115% monospace;}#yiv1069642204 #yiv1069642204ygrp-mlmsg * {line-height:1.22em;}#yiv1069642204 #yiv1069642204ygrp-mlmsg #yiv1069642204logo {padding-bottom:10px;}#yiv1069642204 #yiv1069642204ygrp-msg p a {font-family:Verdana;}#yiv1069642204 #yiv1069642204ygrp-msg p#yiv1069642204attach-count span {color:#1E66AE;font-weight:700;}#yiv1069642204 #yiv1069642204ygrp-reco #yiv1069642204reco-head {color:#ff7900;font-weight:700;}#yiv1069642204 #yiv1069642204ygrp-reco {margin-bottom:20px;padding:0px;}#yiv1069642204 #yiv1069642204ygrp-sponsor #yiv1069642204ov li a {font-size:130%;text-decoration:none;}#yiv1069642204 #yiv1069642204ygrp-sponsor #yiv1069642204ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv1069642204 #yiv1069642204ygrp-sponsor #yiv1069642204ov ul {margin:0;padding:0 0 0 8px;}#yiv1069642204 #yiv1069642204ygrp-text {font-family:Georgia;}#yiv1069642204 #yiv1069642204ygrp-text p {margin:0 0 1em 0;}#yiv1069642204 #yiv1069642204ygrp-text tt {font-size:120%;}#yiv1069642204 #yiv1069642204ygrp-vital ul li:last-child {border-right:none !important;}#yiv1069642204 ------?art_1707846_1092838620.1426891926514
john.daues+yahoo.com on Tue Mar 24 12:18:46 2015 (link)
I am writing data out to a GPX file (with Python code). A waypoint looks like so:I open the file in OSMAnd and can see the waypoints and the name of each. Each waypoint has a symbol that is a red circle with a black star in it. I've tried playing with the value of Some Project Flag, Blue but the symbol is always the same. How do I have it display a different symbol?
robertlipe+gmail.com on Tue Mar 24 12:45:07 2015 (link), replying to msg
Your question seems to be "What values of <sym> are recognized by OSMAnd?" and that's probably best asked of them. My general technique for learning what apps will read is to create icons of every imaginible type in the app and then saving them as GPX; *usually*, they'll read back their own output.
italolme+yahoo.fr on Tue Aug 02 04:47:00 2016 (link)
Hello, How to change the color and thickness of these traces ?Thank you Patrick Orly
jrepetto+free.fr on Tue Aug 02 05:20:08 2016 (link), replying to msg
Le 01/08/2016 � 09:29, italolme+yahoo.fr [gpsxml] a �crit : > > > Hello, > > How to change the color and thickness of these traces ? > Hi, You have to read the documentation of the software you are using to display them.
egroups+topografix.com on Tue Aug 02 05:46:03 2016 (link), replying to msg
Hello, Monday, August 1, 2016, 3:29:13 AM, italolme+yahoo.fr wrote: > How to change the color and thickness of these traces ? Take a look at the GPX extension schemas referenced in the GPX file below, specifically: http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="ExpertGPS 5.78 using Magellan Meridian Gold" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.topografix.com/GPX/gpx_style/0/2 http://www.topografix.com/GPX/gpx_style/0/2/gpx_style.xsd http://www.topografix.com/GPX/gpx_overlay/0/3 http://www.topografix.com/GPX/gpx_overlay/0/3/gpx_overlay.xsd http://www.topografix.com/GPX/gpx_modified/0/1 http://www.topografix.com/GPX/gpx_modified/0/1/gpx_modified.xsd"> <metadata> <bounds minlat="11.06902574" minlon="77.00431800" maxlat="11.06907973" maxlon="77.00437533"/> <extensions> <time xmlns="http://www.topografix.com/GPX/gpx_modified/0/1">2016-08-02T12:42:19.316Z</time> </extensions> </metadata> <trk> <desc>Dashed Green Trail</desc> <type>Green Trail</type> <extensions> <label xmlns="http://www.topografix.com/GPX/gpx_overlay/0/3"> </label> <line xmlns="http://www.topografix.com/GPX/gpx_style/0/2"> <color>00ff00</color> <opacity>1.00</opacity> <width>0.7917</width> <pattern>Trail</pattern> <dasharray> <dash mark="7.143" space="2.857"/> </dasharray> </line> </extensions> <trkseg> <trkpt lat="11.06907973" lon="77.00431800"/> <trkpt lat="11.06906532" lon="77.00435706"/> <trkpt lat="11.06902574" lon="77.00437533"/> </trkseg> </trk> <extensions> </extensions> </gpx>
hedley.finger+gmail.com on Thu Aug 04 20:43:07 2016 (link), replying to msg
Can anyone suggest an editor that can read and edit the latest iteration of KML or KMZ files and also convert them to GPX? Currently Viking just shows the start and end points joined by a straight line and fails to recognise the intervening waypoints. I have recorded a number of tracks while cycling and want to clean them up and convert them to routes. Conversion back to KMZ would be good because then I can share them with friends to navigate with Google Maps. Regards, Hedley 1 / 17 Glyndon Road, Camberwell VIC 3124, Australia hedley.finger+gmail.com Tel. +61 3 9836 4635 Cell +61 412 461 558 Typed laboriously on Samsung Galaxy Note 3 --001a11407318d482a00539311e03
egroups+topografix.com on Fri Aug 05 05:01:58 2016 (link), replying to msg
Hello, Wednesday, August 3, 2016, 5:00:16 PM, Hedley wrote: > Can anyone suggest an editor that can read and edit the latest iteration of KML or KMZ files and also convert them to GPX? Currently Viking just shows the start and end points joined by a straight line and fails to recognise the intervening waypoints. > > I have recorded a number of tracks while cycling and want to clean them up and convert them to routes. > > Conversion back to KMZ would be good because then I can share them with friends to navigate with Google Maps. http://www.expertgps.com/ can convert KML and KMZ to and from GPX, and can clean up your tracks and convert them to routes. -- Dan Foster
robertlipe+gmail.com on Fri Aug 05 16:53:25 2016 (link), replying to msg
GPSBabel has converted between KML and GPX for years. The kinds of files that have to be KMZ (resources for icons, pictures, etc.) tend to not make for very good GPX. Obviously, things like multimedia, camera poses, etc. don't map mechanically. It can convert tracks to routes, reduce number of turnpoints, etc. If I need disclosure, I created GPSBabel, but totally accept that other programs may be more awesome for your specific use case. This question isn't about the GPX file format itself, though, so is gpsxml really the right place for it. RJL On Wed, Aug 3, 2016 at 4:00 PM, Hedley Finger hedley.finger+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > Can anyone suggest an editor that can read and edit the latest iteration > of KML or KMZ files and also convert them to GPX? Currently Viking just > shows the start and end points joined by a straight line and fails to > recognise the intervening waypoints. > > I have recorded a number of tracks while cycling and want to clean them up > and convert them to routes. > > Conversion back to KMZ would be good because then I can share them with > friends to navigate with Google Maps. > > Regards, > Hedley > > 1 / 17 Glyndon Road, Camberwell VIC 3124, Australia > hedley.finger+gmail.com > Tel. +61 3 9836 4635 > Cell +61 412 461 558 > Typed laboriously on Samsung Galaxy Note 3 > > > > --94eb2c035aee83d8f105394c5067
gps_dr+q.com on Sat Aug 06 15:29:07 2016 (link)
Have you tried GPSbabel on your files? I normally use it to convert Google Earth paths to tracklogs to upload to GPS for riding/hiking. Going the other way I use my own software. It works with Garmin/DeLorme/Magellan/Lowrance .gpx files and auto translates symbols, track colors etc with setable widths/transparencies. -- GPS_Dr ------=_Part_1042935_1908488350.1470458272129
heltonbiker+gmail.com on Sun Aug 07 08:28:06 2016 (link)
Please note that KML and GPX are intended for totally different data-types: KML aims for static data (points, geometries), while GPX aims for Tracks (dynamic, timestamped trackpoint sequences). There is no direct mapping between them, and conversion in either direction usually implies loss of at least part of the information. Lately, KML has incorporated extensions (gx: namespace), with Track data, but its format is quite different. I would try GpsBabel to perform this conversion, instead of Viking. --001a113f80b4983169053955eef4
scbldmophahigrml5egqzwnaacg4b3utahmt2hp2+yahoo.com on Wed Aug 10 16:52:41 2016 (link)
I am looking for a discussion about the merits of using the GPS reported COG for heading. My app http://raceqs.com/smart-watchis related to yacht racing which is strictly a 2-Dimensional activity and is very interested in the yacht's heading from second to second to detect manoeuvres such as tacking and gybing where the rate of turn is also very important. It uses the GPS receiver in an Android phone or iPhone. My analysis of many tracks from many devices leads me to believe that, at the typical speeds of around 10 Kph (6 knots), the raw COG value provide a far more accurate and less "noisy" representation of a yacht's track than the heading deduced with trigonometry from successive lat/lon values. The same appears to be true from speed, but that's of less concern to me at the moment. My understanding is that GPS receivers can deduce speed and heading as a fundamental value (from doppler?) which is independent of the position values. When I look at the gpx schema, I observe that COG and SOG are not catered for in the wptType http://www.topografix.com/gpx/1/1/#type_wptType, which is typically used to record points in a. So my discussion points are about the degree with which this direct assessment of COG is actually included in GPS receivers in mobile phones and the best way to include GOG (and SOG) in a gpx track.
pollockk+gmail.com on Mon Feb 27 20:30:24 2017 (link)
I am NOT a developer but am working with a developer to put up a website that allows our members to download .gpx files. When I try to download from the site, i get the following error message "This XML file does not appear to have any style information associated with it. The document tree is shown below." followed by the XML code - here are the first two lines:I can download this file and other .gpx files from other websites with no problem so i know it is not my computer but the new website that we are developing. can someone help me with the code that needs to be inserted on our new site to enable one click .gpx (and .gdb?) downloads? i can download .pdf files and image files with no problems. i am running Chrome on Win10 if that makes a difference. thanks for the help! Kim
robertlipe+gmail.com on Mon Feb 27 22:13:37 2017 (link), replying to msg
The words your developer needs to hear is: set the Content-type (MIME) to "application/gpx+xml". This will force the download and potential launch of an application to handle it. This is published https://en.wikipedia.org/wiki/GPS_Exchange_Format and you can see examples of others making this discovery in places like https://trac.openstreetmap.org/ticket/4768 Configuring your app or web server to handle this is beyond the scope of this group and can vary widely in languages and web servers used. On Mon, Feb 27, 2017 at 12:01 PM, pollockk+gmail.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > I am NOT a developer but am working with a developer to put up a website > that allows our members to download .gpx files. When I try to download > from the site, i get the following error message > > > "This XML file does not appear to have any style information associated > with it. The document tree is shown below." > > > followed by the XML code - here are the first two lines: > > > <gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:xsi=" > http://www.w3.org/2001/XMLSchema-instance" creator="MapSource 6.16.3" > version="1.1"xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/1/1/gpx.xsd"> > > > I can download this file and other .gpx files from other websites with no > problem so i know it is not my computer but the new website that we are > developing. > > > can someone help me with the code that needs to be inserted on our new > site to enable one click .gpx (and .gdb?) downloads? i can download .pdf > files and image files with no problems. > > > i am running Chrome on Win10 if that makes a difference. > > > thanks for the help! > > > Kim > > > > > > --001a114e6c00ffc2e705498a635e
wesblake+gmail.com on Fri Nov 03 18:11:55 2017 (link), replying to msg
I too am looking for a good example on extensions, the docs and examples found have either not been too clear or the example is now missing (page not found). What I'm trying to do might be of interest as well to Topografix and considered something to support officially in gpx in the future. I think I can do it with extensions but the market for the tags is over 8 million (2003 data so probably much higher now) https://www.fs.fed.us/recreation/programs/ohv/IrisRec1rpt.pdf https://www.fs.fed.us/recreation/programs/ohv/IrisRec1rpt.pdf I will simply link since I've already laid out a description of what it is I'm trying to do: https://help.gaiagps.com/hc/en-us/community/posts/115009410788-Enduro-Support https://help.gaiagps.com/hc/en-us/community/posts/115009410788-Enduro-Support If someone could please at least point me to a working example of extensions to start with, it would be much appreciated!
robertlipe+gmail.com on Fri Nov 03 18:25:44 2017 (link), replying to msg
Hi, and welcome. The example syntax earlier in this thread should be enough. Garmin and TopoGrafix have numerous examples. (Some of Garmin's are better examples of design to be interoperable than others.) However, not to be dismissive, but the data you're describing (remaining distance, geometry of the next turn, and a textual description ("hard right", "take the third exit in the roundabout") is already computed in the GPS unit for hundreds (thousands?) of different models that already have the map data. The advantage of having the road network in the receiver is so it can handle changes on the fly; if construction or an accident changes so you enter the roundabout at a different point, it'll do the right thing because it knows the road network, knows about Z-axis connection networks, knows about lane restrictions (no left turn, one-ways, etc.) and much more. So while I won't discourage you from tackling this if it solves some problem for you, I'll say that commodity GPS receivers have been doing this for almost twenty years (and doing it well for over 10) and even phone apps have this right for a long time. That said, Joshua's answer above is a perfectly reasonable starting example of extending GPX. Good luck, RJL On Fri, Nov 3, 2017 at 12:04 PM, wesblake+gmail.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > I too am looking for a good example on extensions, the docs and examples > found have either not been too clear or the example is now missing (page > not found). > What I'm trying to do might be of interest as well to Topografix and > considered something to support officially in gpx in the future. I think I > can do it with extensions but the market for the tags is over 8 million > (2003 data so probably much higher now) > https://www.fs.fed.us/recreation/programs/ohv/IrisRec1rpt.pdf > > I will simply link since I've already laid out a description of what it is > I'm trying to do: > > https://help.gaiagps.com/hc/en-us/community/posts/ > 115009410788-Enduro-Support > > If someone could please at least point me to a working example of > extensions to start with, it would be much appreciated! > > > > > --94eb2c0d28f8805f58055d183bb7
egroups+topografix.com on Fri Nov 17 07:10:11 2017 (link)
I just came across a GPX file that failed to work in my software, because it referenced XML 1.1 instead of XML 1.0 in the first line of the file: <?xml version="1.1" encoding="UTF-8" ?> <gpx version="1.1" creator="redacted" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> Some web searching shows that all versions of the MSXML parser that I use are incompatible with XML 1.1. There are probably other XML parsers in widespread use that will fail to parse XML 1.1 as well. Given that XML 1.1 adds very little that is relevant to GPS data exchange (mainly support for some ancient languages, from what I can tell), can we agree to stick with XML 1.0 when creating GPX files for now, to maximize compatibility with existing XML parsers?
wesblake+gmail.com on Fri Nov 17 07:31:31 2017 (link), replying to msg
Thanks. Perhaps we mis-understand each other. I know they've been doing this for routes on street maps. This is trail riding, the turns can be quite different and the maps don't necessarily have the info needed. I know distance can be computed but I think we (riders) are still looking for the "roll chart" symbols and info. I'll look further into what's existing though. The example given does what I mentioned, if I click on the link to the definition of the extensions (e.g. http://www.garmin.com/xmlschemas/TrackPointExtension/v2 http://www.garmin.com/xmlschemas/TrackPointExtension/v2) they all give "We're sorry" pages. They no longer exist. For an example of a roll chart, check these out: http://i.imgur.com/v7abKew.jpg?1 http://i.imgur.com/v7abKew.jpg?1 http://i.imgur.com/v7abKew.jpg?1 http://i.imgur.com/v7abKew.jpg?1 http://i.imgur.com/v7abKew.jpg?1 View on i.imgur.com http://i.imgur.com/v7abKew.jpg?1 Preview by Yahoo http://thumbs3.ebaystatic.com/d/l225/m/meUyJgSNurEG6E7RgBMREeg.jpg http://thumbs3.ebaystatic.com/d/l225/m/meUyJgSNurEG6E7RgBMREeg.jpg http://thumbs3.ebaystatic.com/d/l225/m/meUyJgSNurEG6E7RgBMREeg.jpg http://thumbs3.ebaystatic.com/d/l225/m/meUyJgSNurEG6E7Rg... http://thumbs3.ebaystatic.com/d/l225/m/meUyJgSNurEG6E7RgBMREeg.jpg View on thumbs3.ebaystatic.com http://thumbs3.ebaystatic.com/d/l225/m/meUyJgSNurEG6E7RgBMREeg.jpg Preview by Yahoo Of course they can be more complex, like a 5 way fork in the trail. It's my understanding a "route" has the info you mentioned for streets, but we're not riding those. The promotor creates a "track" by recording, comes back and cleans it up, then when we do a ride or race we're given the cleaned up "track". I could provide and example of a gpx file for a ride if it helps. If this info is already supported can you please point me to any docs on it? We have many many riders using $800 GPS units for years now and none of them currently show this info, thus the current fallback to the roll charts. Thanks!
pauleyc+yahoo.com on Sat Nov 18 15:56:34 2017 (link)
Yes! I vote for keeping with the xml 1.0. Here is a comment that defines the new abilities with v1.1https://bytes.com/topic/net/answers/563625-well-formed-xml-1-0-1-1-differences This could be a breaking change for the gpx standard. Thanks for asking,Chris Pauley ------?art_690912_1247042441.1511020588213
robertlipe+gmail.com on Sun Nov 19 01:21:28 2017 (link), replying to msg
on6vd+yahoo.co.uk on Fri Dec 08 14:17:48 2017 (link), replying to msg
Hi, and welcome. One a poster has convinced the human moderators that they're not spammers, they have the correct GPX <http://dirtcheapaudio.blogspot.com/2014/10/thrift-store-find-vintage-gpx-stereo.html>, they're here to discuss the GPX spec and not apps that use GPX, mods can flip a bit for contributors that turns off the moderation queue for that poster. Sometimes, the mods all get busy or distracted and the delays get longer. For example, I won't be moderating much more this month as I'm leaving tomorrow for the first of two spinal surgeries this month. Yahoo, the host of these discussions, has well documented security problems and has terrible tools for detecting and blocking spammers. The human moderators have the readers (over a thousand) by trying to keep the riff-raff out. There is thus a bit of a bumpy entrance for new visitors that incur a delay for their first few posts. But we usually manage to keep the evil spammers at bay. It's not always super awesome, but that's the way the system works here. Sorry you got sucked into a couple of delays. On Fri, Dec 8, 2017 at 2:28 AM, on6vd+yahoo.co.uk [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > Ach so... new contributions are published only after (so delayed) admin > approval ? > > > --f403045f890833fd6c05600aed68
on6vd+yahoo.co.uk on Mon Dec 11 07:37:02 2017 (link), replying to msg
Thank you. To get some perspective on the wild west of Yahoo Groups, we've banned about 1/5 of our membership as spammers (if that first post is spam, you're toast and never get approved) and probably 1/3 of our membership never makes a post once applying. There seems to be a large scale migration of lists like this from yahoogroups to groups.io because of years of neglect (and incompetence) in Yahoo Groups. Remember, we've been here since 2001 or so - well before even Google Groups - and Yahoo Groups kind of peaked about that time. We get so little traffic over time that this moderator (along with being distracted about being cut open twice...) sees no burning desire to move platforms until the deck of the ship is a little more wet. Even our history in the group is pretty free of spam - because we hand-pick it - so if you have the misfortune of needing to use Yahoo's group search, you'll probably not be exposed to scary things. And that, dear reader, is how GPX development landed on the Yahoo Groups and is moderated...and is generally spam free because it's lovingly hand-vetted by a couple of moderators. Also, credit where it's due, while I've been here *almost* forever, I suppose those actual decisions were executed by Dan Foster of Topografix before I joined in 2001. On Mon, Dec 11, 2017 at 1:32 AM, Willy Van Driessche on6vd+yahoo.co.uk [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > Hi Robert, > > No problem, and tnks for that very helpfull excellent document gpx 1.0 > In context of experimental specific gpx usage, I do point to (any) > supporting apps. > I hope it encourages other users to have their own tests and share a > result. > > Robert, take good care of yourself in the next days in the Hospital. > > > > On Monday, 11 December 2017, 7:48, "Robert Lipe robertlipe+gmail.com > [gpsxml]" <gpsxml+yahoogroups.com> wrote: > > > > Hi, and welcome. > > One a poster has convinced the human moderators that they're not spammers, > they have the correct GPX > <http://dirtcheapaudio.blogspot.com/2014/10/thrift-store-find-vintage-gpx-stereo.html>, > they're here to discuss the GPX spec and not apps that use GPX, mods can > flip a bit for contributors that turns off the moderation queue for that > poster. > > Sometimes, the mods all get busy or distracted and the delays get longer. > For example, I won't be moderating much more this month as I'm leaving > tomorrow for the first of two spinal surgeries this month. > > Yahoo, the host of these discussions, has well documented security > problems and has terrible tools for detecting and blocking spammers. The > human moderators have the readers (over a thousand) by trying to keep the > riff-raff out. There is thus a bit of a bumpy entrance for new visitors > that incur a delay for their first few posts. But we usually manage to keep > the evil spammers at bay. > > It's not always super awesome, but that's the way the system works here. > Sorry you got sucked into a couple of delays. > > > > On Fri, Dec 8, 2017 at 2:28 AM, on6vd+yahoo.co.uk [gpsxml] < > gpsxml+yahoogroups.com> wrote: > > > > Ach so... new contributions are published only after (so delayed) admin > approval ? > > > > > > > > --f403045ec63e71c6030560133cac
BKrell+swarchitects.com on Mon Dec 11 19:57:49 2017 (link), replying to msg
I, for one, appreciate all the effort by the moderators to keep the group from becoming corrupted. Don't think the problem is yahoo incompetence. The reason that Yahoo neglects this stuff is that they provide this as a FREE service. Since no one pays, they can't devote the resources and manpower to handling all of these issues. That's why yahoo e-mails and groups are the most hacked. Zero resources into upgrades for security. This same e-mail system and groups system has been around since the 1990s without any upgrade work by Yahoo. You can't blame them for this. They still lose money because they have to supply servers and disk farms for the growing number of users, e-mail accounts, and growing storage requirements for e-mail and groups. This costs a lot of money but they are stuck. So, it's unfair and unrealistic to expect them to devote any resources to bringing this software up to date. As users, we are stuck with what we have. We are investing our time to use their free resources. I am not a fan of yahoo or its free services. But, I understand why the system is the way it is. Again, thanks to the moderators for donating their valuable time to help us all. Bruce Krell From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] Sent: Monday, December 11, 2017 8:44 AM To: gpsxml Subject: Re: [gpsxml] Re: Routes vs. Tracks in GPX Thank you. To get some perspective on the wild west of Yahoo Groups, we've banned about 1/5 of our membership as spammers (if that first post is spam, you're toast and never get approved) and probably 1/3 of our membership never makes a post once applying. There seems to be a large scale migration of lists like this from yahoogroups to groups.io because of years of neglect (and incompetence) in Yahoo Groups. Remember, we've been here since 2001 or so - well before even Google Groups - and Yahoo Groups kind of peaked about that time. We get so little traffic over time that this moderator (along with being distracted about being cut open twice...) sees no burning desire to move platforms until the deck of the ship is a little more wet. Even our history in the group is pretty free of spam - because we hand-pick it - so if you have the misfortune of needing to use Yahoo's group search, you'll probably not be exposed to scary things. And that, dear reader, is how GPX development landed on the Yahoo Groups and is moderated...and is generally spam free because it's lovingly hand-vetted by a couple of moderators. Also, credit where it's due, while I've been here almost forever, I suppose those actual decisions were executed by Dan Foster of Topografix before I joined in 2001. On Mon, Dec 11, 2017 at 1:32 AM, Willy Van Driessche on6vd+yahoo.co.uk [gpsxml] <gpsxml+yahoogroups.com> wrote: Hi Robert, No problem, and tnks for that very helpfull excellent document gpx 1.0 In context of experimental specific gpx usage, I do point to (any) supporting apps. I hope it encourages other users to have their own tests and share a result. Robert, take good care of yourself in the next days in the Hospital. On Monday, 11 December 2017, 7:48, "Robert Lipe robertlipe+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> wrote: Hi, and welcome. One a poster has convinced the human moderators that they're not spammers, they have the correct GPX <http://dirtcheapaudio.blogspot.com/2014/10/thrift-store-find-vintage-gpx-stereo.html> , they're here to discuss the GPX spec and not apps that use GPX, mods can flip a bit for contributors that turns off the moderation queue for that poster. Sometimes, the mods all get busy or distracted and the delays get longer. For example, I won't be moderating much more this month as I'm leaving tomorrow for the first of two spinal surgeries this month. Yahoo, the host of these discussions, has well documented security problems and has terrible tools for detecting and blocking spammers. The human moderators have the readers (over a thousand) by trying to keep the riff-raff out. There is thus a bit of a bumpy entrance for new visitors that incur a delay for their first few posts. But we usually manage to keep the evil spammers at bay. It's not always super awesome, but that's the way the system works here. Sorry you got sucked into a couple of delays. On Fri, Dec 8, 2017 at 2:28 AM, on6vd+yahoo.co.uk [gpsxml] <gpsxml+yahoogroups.com> wrote: Ach so... new contributions are published only after (so delayed) admin approval ? [Non-text portions of this message have been removed]
acebrianjuan+gmail.com on Tue Feb 13 21:00:51 2018 (link)
Hi everyone, I have no prior experience with the GPS Exchange Format (GPX) and the eXtensible Markup Language (XML). I am trying to learn the GPX schema, so that I can develop a feature to generate valid GPX files. I have found very valuable information about GPX at http://www.topografix.com/gpx.asp, in particular, the GPX 1.1 Documentation <http://www.topografix.com/GPX/1/1/> which I am trying to assimilate. This is what I have understood so far: - A GPX file is an XML file that contains a set of data tags for describing GPS and geographic data. - The first line on a GPX file must be an XML declaration, for example: <?xml version="1.0" encoding="UTF-8" standalone="no" ?> - The GPX file must have this structure: <gpx version="1.1 [1]" creator="xsd <http://www.topografix.com/gpx/1/1/#ns_xsd>:string [1]"> <metadata> metadataType <http://www.topografix.com/gpx/1/1/#type_metadataType> </metadata> [0..1] <wpt> wptType <http://www.topografix.com/gpx/1/1/#type_wptType> </wpt> [0..*] <rte> rteType <http://www.topografix.com/gpx/1/1/#type_rteType> </rte> [0..*] <trk> trkType <http://www.topografix.com/gpx/1/1/#type_trkType> </trk> [0..*] <extensions> extensionsType <http://www.topografix.com/gpx/1/1/#type_extensionsType> </extensions> [0..1] </gpx> - From the previous structure, only the *version* and *creator* fields are mandatory. - All the remaining fields like *metadata*, *wpt*, *rte*, *trk* and *extensions* are optional. Based on these assumptions I have composed the following file which should be the minimal example of a valid GPX file: <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <gpx version="1.1" creator="ACME"> </gpx> But when I try to validate the file as explained in the documentation <http://www.topografix.com/gpx_validation.asp>, SAXCount throws the following errors: star+galaxy:~$ SAXCount -v=always -n -s -f minimal.gpx Error at file /home/star/minimal.gpx, line 2, char 35 Message: no declaration found for element 'gpx' Error at file /home/star/minimal.gpx, line 2, char 35 Message: attribute 'version' is not declared for element 'gpx' Error at file /home/star/minimal.gpx, line 2, char 35 Message: attribute 'creator' is not declared for element 'gpx' These errors mean that the *minimal.gpx* file that I composed didn't parse correctly and therefore is not a valid GPX file. Therefore I seek for help here in the GPX Developers Forum. I would be grateful if someone could show me an example of the minimal valid GPX file. Did I miss anything in the file header? Why didn't my file validate? Best Regards, Álvaro --001a114119322f818d05651e1a47
yahoo.id+magnell.org on Tue Feb 13 21:49:37 2018 (link), replying to msg
You asked SAXcount to validate the the xml and do full schema checking and processing, but you did not specify the schema or its location. Theelement should look something like this: http://www.topografix.com/GPX/1/1/gpx.xsd%22> The SAXcount arguments are explained here: https://xerces.apache.org/xerces-c/saxcount-3.html https://xerces.apache.org/xerces-c/saxcount-3.html steve magnell
robertlipe+gmail.com on Tue Feb 13 21:53:16 2018 (link), replying to msg
Good answer, Steve. OP, you should see the full developer doc, which includes sample files, at http://www.topografix.com/gpx.asp There are hundreds of programs that read/write GPX at this point and surely millions of them on the web. Not all of them are technically correct, but they should serve as examples to get you going. On Tue, Feb 13, 2018 at 3:21 PM, yahoo.id+magnell.org [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > You asked SAXcount to validate the the xml and do full schema checking and > processing, but you did not specify the schema or its location. > > The <gpx> element should look something like this: > > <gpx xmlns="http://www.topografix.com/GPX/1/1" creator="BaseCamp 3.2.0.7 > Beta" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/1/1/gpx.xsd"> > > The SAXcount arguments are explained here: > > https://xerces.apache.org/xerces-c/saxcount-3.html > > steve magnell > > > > --f4030436f20667bccc05651f05f1
acebrianjuan+gmail.com on Wed Feb 14 01:47:59 2018 (link), replying to msg
Hi Steve and Robert, First of all, thank you very much for your responses, they are helping me a lot. I have replaced the <gpx> element by the one provided by Steve. Now the file validates correctly: star+galaxy:~$ SAXCount -v=always -n -s -f minimal.gpx minimal.gpx: 796 ms (1 elems, 5 attrs, 2 spaces, 0 chars) I have already explored several GPX files that I found on the internet. Some of them were successfully validated by SAXCount, while others failed. If I have to be honest with you, I don't understand the purpose/meaning of the attributes *xmlns*, *creator*, *version*, *xmlns:xsi* and *xsi:schemaLocation* inside the <gpx> element. In the GPX 1.1 Documentation <http://www.topografix.com/GPX/1/1/> only *creator* and *version* are documented, the other attributes are not mentioned. I would be delighted if you could shed some light on the purpose/meaning of each of the aforementioned attributes. If this information is documented somewhere, please let me know. Thank you. Best Regards, Álvaro 2018-02-13 22:53 GMT+01:00 Robert Lipe robertlipe+gmail.com [gpsxml] < gpsxml+yahoogroups.com>: > > > Good answer, Steve. > > OP, you should see the full developer doc, which includes sample files, at > http://www.topografix.com/gpx.asp There are hundreds of programs that > read/write GPX at this point and surely millions of them on the web. Not > all of them are technically correct, but they should serve as examples to > get you going. > > On Tue, Feb 13, 2018 at 3:21 PM, yahoo.id+magnell.org [gpsxml] < > gpsxml+yahoogroups.com> wrote: > >> >> >> You asked SAXcount to validate the the xml and do full schema checking >> and processing, but you did not specify the schema or its location. >> >> The <gpx> element should look something like this: >> >> <gpx xmlns="http://www.topografix.com/GPX/1/1" creator="BaseCamp 3.2.0.7 >> Beta" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://www.topografix.com/GPX/1/1 >> http://www.topografix.com/GPX/1/1/gpx.xsd"> >> >> The SAXcount arguments are explained here: >> >> https://xerces.apache.org/xerces-c/saxcount-3.html >> >> steve magnell >> >> >> > > --001a1142b6385c8e4e05651fcf01
robertlipe+gmail.com on Wed Feb 14 01:59:42 2018 (link), replying to msg
The GPX spec assumes familiarity with XML and doesn't call out all the basic XML things. The formal spec is https://www.w3.org/TR/xmlschema11-1/, but there are more accessible/understandable introductions to XML in bookstores and on the web. You can do most of the geo/gps actions in GPX by following examples and trusting the tools of whatever language/environment you're using to handle the hundreds of pages of the details of entity encoding, xsd vs. xsi, alternative namespaces, and such. Oh, there's a core GPX truth in that above sentence that may not be obvious: use tools to read and write XML and thus, GPX. If you think you're going to handle arbitrary data with whatever your language calls "read string" and "write string", you're going to have a bad time. As a sidebar, I really hate the Yahoo moderator tools that removed "approve this message and remove this poster from manual moderation" as a checkbox. It's pretty easy to tell on the first post if you're a spammer or not and I hate jumping through hoops to onboard new members. I've taken care of Steve and Alvaro. RJL On Tue, Feb 13, 2018 at 4:49 PM, Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > Hi Steve and Robert, > > First of all, thank you very much for your responses, they are helping me > a lot. > > I have replaced the <gpx> element by the one provided by Steve. Now the > file validates correctly: > > star+galaxy:~$ SAXCount -v=always -n -s -f minimal.gpx > minimal.gpx: 796 ms (1 elems, 5 attrs, 2 spaces, 0 chars) > > I have already explored several GPX files that I found on the internet. > Some of them were successfully validated by SAXCount, while others failed. > > If I have to be honest with you, I don't understand the purpose/meaning of > the attributes *xmlns*, *creator*, *version*, *xmlns:xsi* and > *xsi:schemaLocation* inside the <gpx> element. In the GPX 1.1 > Documentation <http://www.topografix.com/GPX/1/1/> only *creator* and > *version* are documented, the other attributes are not mentioned. > > I would be delighted if you could shed some light on the purpose/meaning > of each of the aforementioned attributes. If this information is documented > somewhere, please let me know. > > Thank you. > > Best Regards, > > Álvaro > > > 2018-02-13 22:53 GMT+01:00 Robert Lipe robertlipe+gmail.com [gpsxml] < > gpsxml+yahoogroups.com>: > >> >> >> Good answer, Steve. >> >> OP, you should see the full developer doc, which includes sample files, >> at http://www.topografix..com/gpx.asp <http://www.topografix.com/gpx.asp> >> There are hundreds of programs that read/write GPX at this point and surely >> millions of them on the web. Not all of them are technically correct, but >> they should serve as examples to get you going. >> >> On Tue, Feb 13, 2018 at 3:21 PM, yahoo.id+magnell.org [gpsxml] < >> gpsxml+yahoogroups.com> wrote: >> >>> >>> >>> You asked SAXcount to validate the the xml and do full schema checking >>> and processing, but you did not specify the schema or its location. >>> >>> The <gpx> element should look something like this: >>> >>> <gpx xmlns="http://www.topografix.com/GPX/1/1" creator="BaseCamp >>> 3.2.0.7 Beta" version="1.1" xmlns:xsi="http://www.w3.org/2 >>> 001/XMLSchema-instance" xsi:schemaLocation="http://www >>> .topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> >>> >>> The SAXcount arguments are explained here: >>> >>> https://xerces.apache.org/xerces-c/saxcount-3.html >>> >>> steve magnell >>> >>> >>> >> > > > > --001a11401b7ed60427056522762d
speleoluc+gmail.com on Mon Mar 05 17:48:24 2018 (link)
Hi, My cave survey freeware exports GPX files, but a user reports Garmin Basecamp cannot open them. Trying to validate my GPX files, I downloaded SAXCount.exe from the Xerces package. But I realize any GPX file, mines or anything I find on the web fails validation right at the first line. Has something changed in the schema? With a GPX that starts like this: <?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" creator="Geovative Solutions GeoTours" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <metadata> <link href="http://www.speleo.qc.ca/Auriga"> <text>Auriga</text> </link> <time>2018-03-05T17:06:28Z</time> </metadata> SAXCount reports: Error at file C:\Download/St-Leonard.gpx, line 2, char 5 Message: Unknown element 'gpx' Error at file C:\Download/St-Leonard.gpx, line 2, char 12 Message: Attribute 'xmlns' is not declared for element 'gpx' Error at file C:\Download/St-Leonard.gpx, line 2, char 56 Message: Attribute 'creator' is not declared for element 'gpx' Error at file C:\Download/St-Leonard.gpx, line 2, char 95 Message: Attribute 'version' is not declared for element 'gpx' Error at file C:\Download/St-Leonard.gpx, line 2, char 111 Message: Attribute 'xmlns:xsi' is not declared for element 'gpx' Error at file C:\Download/St-Leonard.gpx, line 2, char 174 Message: Attribute 'xsi:schemaLocation' is not declared for element 'gpx' Error at file C:\Download/St-Leonard.gpx, line 3, char 12 Message: Unknown element 'metadata' Error at file C:\Download/St-Leonard.gpx, line 4, char 12 Message: Unknown element 'link' -- Luc Le Blanc http://www.speleo.qc.ca/Auriga
on6vd+yahoo.co.uk on Wed Apr 04 11:15:35 2018 (link)
The current GPX version (1.1) has been released a long time ago in 2004. However several features (like speed, heartbeat, etc.) are missing from the current specification in my opinion. Additional features can be easily added to GPX by using extensions, like the Garmin TrackPointExtension. However this leads to non uniformity, and unnecessary long gpx files. I think the time has come to update the current GPX specification. Are people interested in starting a discussion that will lead to an updated GPX specification? To illustrate, I have some suggestions of information that can be included. Probably you can think of more things, so please shoot. TrackPoint:speed, heartbeat, horizontalAccuracy, verticalAccuracy, speedAccuracy, course, bearing, ambient temperature, air pressure Waypoint: uniform possibility to add media types like images and videos, style information Track: style information, track type information (i.e. cycling track, pedestrian track, flight track) Harmen Warringa developer Topo GPS https://www.topo-gps.com
yahoo+web.knobby.ws on Mon Apr 23 23:41:37 2018 (link), replying to msg
If I remember correctly v1.1 wasn't even formally adopted. Your suggestion seems like a good idea, but it will be an uphill battle. Seems like you need the big players like Garmin buying in and Garmin has always done things their way. But maybe their new owners will change that. You'd have to show them backward compatibility and good reason to change. Can this be driven from the bottom up without the Googles and Garmins? Good luck
pauleyc+yahoo.com on Tue Apr 24 00:13:20 2018 (link), replying to msg
Hi Can you load it into a XMLDomNode? -Chris Pauley
robertlipe+gmail.com on Tue Apr 24 00:46:03 2018 (link), replying to msg
See the Dec 2009 (yes, really) thread "Draft of proposed GPX 1.1 extensions" �?? for a starting place. I'm down and out right now recovering from spinal surgery. I can cheerlead someone wanting to take it over. What doesn't appear in that public thread was several vendors contacting me privately explaining they were perfectly happy with their proprietary and incompatible extension and really weren't interested in changing from them, so that deflated my sails substantially. As someone said above, even GPX 1.1 never really got traction. OGC got behind KML, but it's quite heavy for a lot of GPS-class work. �?? On Mon, Apr 23, 2018 at 6:40 PM, yahoo+web.knobby.ws [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > If I remember correctly v1.1 wasn't even formally adopted. > > Your suggestion seems like a good idea, but it will be an uphill battle. > Seems like you need the big players like Garmin buying in and Garmin has > always done things their way. But maybe their new owners will change that. > You'd have to show them backward compatibility and good reason to change. > > Can this be driven from the bottom up without the Googles and Garmins? > > Good luck > > > > --000000000000a5d095056a8d62bd
harmen.warringa+gmail.com on Wed Apr 25 13:00:03 2018 (link), replying to msg
Thanks for the comments. If I may summarize the discussion of 2009. Back then the discussion was whether to define and updated GPX spefication or to define standard extensions. People seem to favour standard extensions, to ensure interoperatability. Robert proposed such an extension, but it never was made into an official extension. Most people started to use the Garmin extensions. This was almost 10 years ago and many things have happened since then, like the increase of smartphone and smartwatch usage. I think therefore it would be good if we now start a process of defining an updated GPX specification. GPX 2 should be as much backwards compatible with GPX 1 and I think it should be defined as a formal standard by a standardization organization. OGC is not very suitable for that since membership is very expensive and so the discussion and decision making would not be open for all. I would propose to try to make GPX 2 an official IETF (https://www.ietf.org) standard. The mission of IETF is also developing open standards through open processes. As an example GeoJSON (https://www.geojson.org) became an IETF standard in 2015. I never to part in such an standardization discussion, but I think that IETF can help us a lot in streamlining the process of adopting a formal standard. What do you think?
egroups+topografix.com on Wed Apr 25 13:07:31 2018 (link), replying to msg
Another issue we should discuss is moving the GPX schema endpoints to https, and what to do about the existing http endpoints for GPX 1.0 and GPX 1.1
harmen.warringa+gmail.com on Wed Apr 25 18:00:30 2018 (link), replying to msg
Agree, I think this makes gpx validation much more secure, since it will probably prevent a man-the-middle attack. One other thing it to ensure that these schema url will remain indefinitely. Right now, we are not certain whether the topografix website will remain accessible forever. The same problem with the Garmin extensions.
robertlipe+gmail.com on Wed Apr 25 19:07:01 2018 (link), replying to msg
I started with the approach of proposing an extension first so it could be implemented in real world software, shaken down, and changed if need be with a relatively lightweight process. It was my plan all along to propose it to be eventually streamlined into the mainline, whether that was 1.2 or 2.0. (Since 1.1 was incompatible with 1.0 we'd already blown semantic version numbering.) The proposal in that thread was the result of reading this list and studying all the extensions I'd been asked to support in GPSBabel at that time. I'm not sure it's changed a whole lot, but I still think that thread is a very reasonable starting place as it included input from marine, aviation, and fitness markets. I'm still a bit warmer to extension->stable approach, but the person(s) doing the work gets a very large say in the matter. "Forever" on the web is a slippery thing. So far, Topografix has, to my knowledge, single-handedly footed the bill for domain registration, hosting, and most incidentals around GPX. (Thank you, Dan!) If you want to seriously consider that Topografix or Garmin will go away, it probably has to pick up the weight of becoming a legal entity that can own and enforce a copyright, a domain, etc. We should have similar concerns about the permanence of yahoogroups as a listserv. That probably means the weight of a 501c3, funding, and all that or partnering with someone else that can. The IETF would be a lovely choice, IMO, as they have this infrastructure. Someone with experience navigating that process and willing to spearhead it would be welcome. GeoJSON is a bit of an Elephant In The Room and we should probably fence that pretty early on. If you just respelled GPX as JSON, you'd end up with a subset of GeoJSON, but with a different accent. GPX was influenced by GPS receivers and software around the turn of the century. GPSes at that time were Dragonball-class devices and probably programmed in assembly. We've certainly moved past that. GeoJSON follows the smell of GIS-class software like ArcGIS, Earth, and PostGIS. I usually use the distinction that one is for maps (this is a geometry collection representing the boundaries of the lake, including the island in the middle) and one is for things you put on a map (this was our hike to the boat dock and our canoe trip to the island). We could probably make a nearly 1:1 spelling of GPX in JSON that would be valid GeoJSON, but I don't think the opposite is true. (Even if you could draw dotted lines representing them, it would lost the relative meanings...) I don't think we should become GeoJSON, but perhaps an official spelling of GPX as (Geo)JSON would be helpful. I created and lead what was the first cross-platform, open source GPX reader and writer, GPSBabel. I'd be willing to help implementers manage branches, pull requests, reference files, etc. in "my" GitHub project so we can argue in code. Not all of us speak C++, but our XML and GeoJSON readers and writers would be pretty mechanical for anyone speaking DOM/SAX-style code. That way we can argue in code instead of hand-waving about what's smaller, faster, easier, whatever. Since it is primarily a converter, it's super easy to read, say, a Garmin GPX with fitness extensions (or a FIT file or whatever) and write it as a GPX with those formats inlined. It already has infrastructure to validate output via SAXCount and such. Oh, and thank you for using an actual name. Moderating an address that looks like a cat walked across a keyboard was always tough. I've approved this address for immediate posting. So, are you willing to pick the ball up and lead it through the IETF process? I'm willing to help, but I may be doing it from a bed and/or highly medicated and thus, not really as a full-time job. RJL On Wed, Apr 25, 2018 at 12:18 PM, harmen.warringa+gmail.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > Agree, I think this makes gpx validation much more secure, since it will > probably prevent a man-the-middle attack. One other thing it to ensure that > these schema url will remain indefinitely. Right now, we are not certain > whether the topografix website will remain accessible forever. The same > problem with the Garmin extensions. > > > --f4f5e80f1608a525ea056ab0f9b5
egroups+topografix.com on Wed Apr 25 20:01:04 2018 (link), replying to msg
I'm the owner of the topografix.com domain where the GPX schemas have been hosted since day one. There are no financial or other reasons for the topografix domain to become inaccessible, but I'm not opposed to transferring future schemas (or making the canonical home of the existing schemas) somewhere else, especially if some standards organization gets involved. One recurring problem with Garmin's extension schemas has been the non-permanence of the schema locations on Garmin's Web site when they do a site redesign.
harmen.warringa+gmail.com on Wed Apr 25 21:18:34 2018 (link), replying to msg
Another suggestion would be a W3C standard: https://www.w3.org/standards/about.html https://www.w3.org/standards/about.html W3C has also a nice way of organizing the standardization process and, it seems to me that they provide also a possibility of hosting thinks like schemes (see e.g. https://www.w3.org/Math/ https://www.w3.org/Math/). And since W3C also published the XML standard, it might suit GPX better. Of course GPX should not copy GeoJSON, I only mentioned it to indicate how GeoJSON became standardized. I am in favor of updating the GPX specification instead of defining official extensions. I also think it would be nice to define an official way of compressing gpx data (this was also mentioned in the discussion) of gpx, like with kml and kmz. Harmen
on6vd+yahoo.co.uk on Thu Apr 26 09:47:56 2018 (link), replying to msg
Harmen, I agree. GPX is an excellent lightweight format which deserves more attention, and I’d also like to see the additions you mentioned. I’ve believe W3C is a good place to co-ordinate your efforts, as I’m currently developing the new WebVMT format (http://w3c.github.io/sdw/proposals/geotagging/webvmt/ http://w3c.github.io/sdw/proposals/geotagging/webvmt/) and have found them very supportive. You'll have to do the work, but they'll be able to offer guidance and expertise to help steer you in the right direction for official standardisation. I suggest you contact Francois at the Spatial Data on the Web Interest Group (SDW IG): https://www.w3.org/2017/sdwig/ https://www.w3.org/2017/sdwig/ to discuss the best way to proceed. Good luck. Rob Smith Away Team www.awayteam.co.uk http://www.awayteam.co.uk/
on6vd+yahoo.co.uk on Thu Apr 26 11:13:17 2018 (link), replying to msg
There was a meeting of SDW IG last week, so I raised the GPX v2 issue: https://www.w3.org/2018/06/06-sdw-minutes.html#x14 https://www.w3.org/2018/06/06-sdw-minutes.html#x14 and it got a friendly reception. If you're serious about progressing this idea, I suggest you contact Francois via the SDW IG home page at https://www.w3.org/2017/sdwig/ https://www.w3.org/2017/sdwig/ Good luck. Rob Smith Away Team www.awayteam.co.uk http://www.awayteam.co.uk/
pauleyc+yahoo.com on Fri Jun 15 19:25:09 2018 (link), replying to msg
I'm interested in contributing too! I think the IETF with a github repo would be a solid approach. Chris Pauley gpxdb.com On Friday, June 15, 2018, 9:55:54 AM EDT, awayteamsoftware+yahoo.com [gpsxml] <gpsxml+yahoogroups.com> wrote: There was a meeting of SDW IG last week, so I raised the GPX v2 issue: https://www.w3.org/2018/06/06-sdw-minutes.html#x14 and it got a friendly reception. If you're serious about progressing this idea, I suggest you contact Francois via the SDW IG home page at https://www.w3.org/2017/sdwig/ Good luck. Rob Smith Away Teamwww.awayteam.co.uk #yiv6985906402 #yiv6985906402 -- #yiv6985906402ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6985906402 #yiv6985906402ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6985906402 #yiv6985906402ygrp-mkp #yiv6985906402hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv6985906402 #yiv6985906402ygrp-mkp #yiv6985906402ads {margin-bottom:10px;}#yiv6985906402 #yiv6985906402ygrp-mkp .yiv6985906402ad {padding:0 0;}#yiv6985906402 #yiv6985906402ygrp-mkp .yiv6985906402ad p {margin:0;}#yiv6985906402 #yiv6985906402ygrp-mkp .yiv6985906402ad a {color:#0000ff;text-decoration:none;}#yiv6985906402 #yiv6985906402ygrp-sponsor #yiv6985906402ygrp-lc {font-family:Arial;}#yiv6985906402 #yiv6985906402ygrp-sponsor #yiv6985906402ygrp-lc #yiv6985906402hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6985906402 #yiv6985906402ygrp-sponsor #yiv6985906402ygrp-lc .yiv6985906402ad {margin-bottom:10px;padding:0 0;}#yiv6985906402 #yiv6985906402actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6985906402 #yiv6985906402activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6985906402 #yiv6985906402activity span {font-weight:700;}#yiv6985906402 #yiv6985906402activity span:first-child {text-transform:uppercase;}#yiv6985906402 #yiv6985906402activity span a {color:#5085b6;text-decoration:none;}#yiv6985906402 #yiv6985906402activity span span {color:#ff7900;}#yiv6985906402 #yiv6985906402activity span .yiv6985906402underline {text-decoration:underline;}#yiv6985906402 .yiv6985906402attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv6985906402 .yiv6985906402attach div a {text-decoration:none;}#yiv6985906402 .yiv6985906402attach img {border:none;padding-right:5px;}#yiv6985906402 .yiv6985906402attach label {display:block;margin-bottom:5px;}#yiv6985906402 .yiv6985906402attach label a {text-decoration:none;}#yiv6985906402 blockquote {margin:0 0 0 4px;}#yiv6985906402 .yiv6985906402bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv6985906402 .yiv6985906402bold a {text-decoration:none;}#yiv6985906402 dd.yiv6985906402last p a {font-family:Verdana;font-weight:700;}#yiv6985906402 dd.yiv6985906402last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv6985906402 dd.yiv6985906402last p span.yiv6985906402yshortcuts {margin-right:0;}#yiv6985906402 div.yiv6985906402attach-table div div a {text-decoration:none;}#yiv6985906402 div.yiv6985906402attach-table {width:400px;}#yiv6985906402 div.yiv6985906402file-title a, #yiv6985906402 div.yiv6985906402file-title a:active, #yiv6985906402 div.yiv6985906402file-title a:hover, #yiv6985906402 div.yiv6985906402file-title a:visited {text-decoration:none;}#yiv6985906402 div.yiv6985906402photo-title a, #yiv6985906402 div.yiv6985906402photo-title a:active, #yiv6985906402 div.yiv6985906402photo-title a:hover, #yiv6985906402 div.yiv6985906402photo-title a:visited {text-decoration:none;}#yiv6985906402 div#yiv6985906402ygrp-mlmsg #yiv6985906402ygrp-msg p a span.yiv6985906402yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv6985906402 .yiv6985906402green {color:#628c2a;}#yiv6985906402 .yiv6985906402MsoNormal {margin:0 0 0 0;}#yiv6985906402 o {font-size:0;}#yiv6985906402 #yiv6985906402photos div {float:left;width:72px;}#yiv6985906402 #yiv6985906402photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv6985906402 #yiv6985906402photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv6985906402 #yiv6985906402reco-category {font-size:77%;}#yiv6985906402 #yiv6985906402reco-desc {font-size:77%;}#yiv6985906402 .yiv6985906402replbq {margin:4px;}#yiv6985906402 #yiv6985906402ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv6985906402 #yiv6985906402ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv6985906402 #yiv6985906402ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv6985906402 #yiv6985906402ygrp-mlmsg select, #yiv6985906402 input, #yiv6985906402 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv6985906402 #yiv6985906402ygrp-mlmsg pre, #yiv6985906402 code {font:115% monospace;}#yiv6985906402 #yiv6985906402ygrp-mlmsg * {line-height:1.22em;}#yiv6985906402 #yiv6985906402ygrp-mlmsg #yiv6985906402logo {padding-bottom:10px;}#yiv6985906402 #yiv6985906402ygrp-msg p a {font-family:Verdana;}#yiv6985906402 #yiv6985906402ygrp-msg p#yiv6985906402attach-count span {color:#1E66AE;font-weight:700;}#yiv6985906402 #yiv6985906402ygrp-reco #yiv6985906402reco-head {color:#ff7900;font-weight:700;}#yiv6985906402 #yiv6985906402ygrp-reco {margin-bottom:20px;padding:0px;}#yiv6985906402 #yiv6985906402ygrp-sponsor #yiv6985906402ov li a {font-size:130%;text-decoration:none;}#yiv6985906402 #yiv6985906402ygrp-sponsor #yiv6985906402ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv6985906402 #yiv6985906402ygrp-sponsor #yiv6985906402ov ul {margin:0;padding:0 0 0 8px;}#yiv6985906402 #yiv6985906402ygrp-text {font-family:Georgia;}#yiv6985906402 #yiv6985906402ygrp-text p {margin:0 0 1em 0;}#yiv6985906402 #yiv6985906402ygrp-text tt {font-size:120%;}#yiv6985906402 #yiv6985906402ygrp-vital ul li:last-child {border-right:none !important;}#yiv6985906402 ------?art_1079810_1261868222.1529090707178
acebrianjuan+gmail.com on Wed Oct 24 08:03:59 2018 (link)
Dear GPX community, I have been asked to add velocity information to my GPX files and I was wondering if there is a standard XML tag for this purpose. I have done some research online and I have inspected several sample GPX files <https://developer.garmin.com/garmin-connect-api/sample-data/>, but I did not find any containing velocity information. How do we report the velocity in GPX? Thank you. Álvaro --000000000000a3d5d20578facbd1
acebrianjuan+gmail.com on Wed Oct 24 11:18:41 2018 (link), replying to msg
It turns out that this was in fact documented here: https://www.topografix .com/gpx_manual.asp The GPX website has improved a lot since the last time I visited it. Álvaro El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (< acebrianjuan+gmail.com>) escribió: > Dear GPX community, > > I have been asked to add velocity information to my GPX files and I was > wondering if there is a standard XML tag for this purpose. > I have done some research online and I have inspected several sample GPX > files <https://developer.garmin.com/garmin-connect-api/sample-data/>, but > I did not find any containing velocity information. > > How do we report the velocity in GPX? > > Thank you. > > Álvaro > --000000000000f109ec0578fd8319
robertlipe+gmail.com on Wed Oct 24 13:37:39 2018 (link), replying to msg
We have this conversation about once a year on the list. <speed> was in GPX 1.0, but not 1.1 Most of the civilian/consumer uses of GPS (and thus, GPX) really only collects successive timestamped positions and, from that, can derive a concept of speed. There are a few cases where an additional sensor is added where another concept of speed is useful. Marine use sometimes has hull sensors and it's useful to make distinct concept of a boats position as determined via GPS relative to the relative speed of the water moving under the boat. What we have seen in practice is that people were using the instantaneous difference in locations a few seconds apart, where the GPS location error may exceed the amount of actual motion, and creating silly <speed> tags. No, your bike ride was never 43 miles per hour at the starting line. MOST of the actual users of the data were recomomputing the speed from the location and time anyway, so it was a bit redundant. However, we didn't explain this very well (and honestly, I don't think it was a conscious decision as much as a mistake) and we did leave open the cases like marine with transducer or bikes with wheel sensors (different than cadence sensors) that actually did something useful with speed. If you do choose to write speed in GPX 1.1, I'd recommend following Garmin's extensions. They seem to be the most widely recognized ones in the industry. Please don't just add them from the computed fix, though. RJL On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > It turns out that this was in fact documented here: https://www.topografix > .com/gpx_manual.asp > The GPX website has improved a lot since the last time I visited it. > > Álvaro > > El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (< > acebrianjuan+gmail.com>) escribió: > >> Dear GPX community, >> >> I have been asked to add velocity information to my GPX files and I was >> wondering if there is a standard XML tag for this purpose. >> I have done some research online and I have inspected several sample GPX >> files <https://developer.garmin.com/garmin-connect-api/sample-data/>, >> but I did not find any containing velocity information. >> >> How do we report the velocity in GPX? >> >> Thank you. >> >> Álvaro >> > > > > --00000000000048119c0578ff2dbd
smithalan+bigpond.com on Wed Oct 24 19:38:58 2018 (link), replying to msg
Just as an aside, I have determined that many GPS interfaces report speed (SOG) and course (COG) containing values that are reported to be derived independently of the position and time coordinates. There are some sources that indicate that they may be derived using a doppler measurement. In any case, these SOG and COG values provide a smoother result than that derived from position and time, and for that reason they are a valuable resource. I have chosen to record them in my GPX files as <extensions> . ------ Original Message ------ From: "Robert Lipe robertlipe+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> To: "gpsxml" <gpsxml+yahoogroups.com> Sent: Thursday, 25 Oct, 2018 At 7:17 AM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? We have this conversation about once a year on the list. <speed> was in GPX 1.0, but not 1.1 Most of the civilian/consumer uses of GPS (and thus, GPX) really only collects successive timestamped positions and, from that, can derive a concept of speed. There are a few cases where an additional sensor is added where another concept of speed is useful. Marine use sometimes has hull sensors and it's useful to make distinct concept of a boats position as determined via GPS relative to the relative speed of the water moving under the boat. What we have seen in practice is that people were using the instantaneous difference in locations a few seconds apart, where the GPS location error may exceed the amount of actual motion, and creating silly <speed> tags. No, your bike ride was never 43 miles per hour at the starting line. MOST of the actual users of the data were recomomputing the speed from the location and time anyway, so it was a bit redundant. However, we didn't explain this very well (and honestly, I don't think it was a conscious decision as much as a mistake) and we did leave open the cases like marine with transducer or bikes with wheel sensors (different than cadence sensors) that actually did something useful with speed. If you do choose to write speed in GPX 1.1, I'd recommend following Garmin's extensions. They seem to be the most widely recognized ones in the industry. Please don't just add them from the computed fix, though. RJL On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: It turns out that this was in fact documented here: https://www.topografix.com/gpx_manual.asp <https://www.topografix.com/gpx_manual.asp> The GPX website has improved a lot since the last time I visited it. Álvaro El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (<acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> >) escribió: Dear GPX community, I have been asked to add velocity information to my GPX files and I was wondering if there is a standard XML tag for this purpose. I have done some research online and I have inspected several sample GPX files <https://developer.garmin.com/garmin-connect-api/sample-data/> , but I did not find any containing velocity information. How do we report the velocity in GPX? Thank you. Álvaro ------?art_3822023_1541434238.1540435131340
acebrianjuan+gmail.com on Thu Oct 25 04:07:55 2018 (link), replying to msg
Thank you Robert and smithalan for your replies. I understand and agree with your point that GPX is "position oriented". We infer the ground speed using a number of algorithms and transformations, so it will add useful information to the file. I am definitely going to use Garmin extensions as you suggested, but I need to do some research and look into them. By any chance, do you guys happen to have a sample GPX file that makes use of Garmin extensions for recording speed, so that I can take a look? Thank you. Álvaro El jue., 25 oct. 2018 a las 4:39, smithalan smithalan smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com>) escribió: > > > Just as an aside, I have determined that many GPS interfaces report speed > (SOG) and course (COG) containing values that are reported to be derived > independently of the position and time coordinates. There are some sources > that indicate that they may be derived using a doppler measurement. > In any case, these SOG and COG values provide a smoother result than that > derived from position and time, and for that reason they are a valuable > resource. I have chosen to record them in my GPX files as <extensions> . > > > > > > ------ Original Message ------ > From: "Robert Lipe robertlipe+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> > To: "gpsxml" <gpsxml+yahoogroups.com> > Sent: Thursday, 25 Oct, 2018 At 7:17 AM > Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? > > > > > > > We have this conversation about once a year on the list. > > <speed> was in GPX 1.0, but not 1.1 > Most of the civilian/consumer uses of GPS (and thus, GPX) really only > collects successive timestamped positions and, from that, can derive a > concept of speed. There are a few cases where an additional sensor is > added where another concept of speed is useful. Marine use sometimes has > hull sensors and it's useful to make distinct concept of a boats position > as determined via GPS relative to the relative speed of the water moving > under the boat. > > What we have seen in practice is that people were using the instantaneous > difference in locations a few seconds apart, where the GPS location error > may exceed the amount of actual motion, and creating silly <speed> tags. > No, your bike ride was never 43 miles per hour at the starting line. MOST > of the actual users of the data were recomomputing the speed from the > location and time anyway, so it was a bit redundant. > > However, we didn't explain this very well (and honestly, I don't think it > was a conscious decision as much as a mistake) and we did leave open the > cases like marine with transducer or bikes with wheel sensors (different > than cadence sensors) that actually did something useful with speed. > > If you do choose to write speed in GPX 1.1, I'd recommend following > Garmin's extensions. They seem to be the most widely recognized ones in the > industry. Please don't just add them from the computed fix, though. > > RJL > > On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan acebrianjuan+gmail.com > [gpsxml] <gpsxml+yahoogroups.com> wrote: > >> >> >> >> >> It turns out that this was in fact documented here: https://www. >> topografix.com/gpx_manual.asp >> The GPX website has improved a lot since the last time I visited it. >> >> Álvaro >> >> El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (< >> acebrianjuan+gmail.com>) escribió: >> >>> Dear GPX community, >>> >>> I have been asked to add velocity information to my GPX files and I was >>> wondering if there is a standard XML tag for this purpose. >>> I have done some research online and I have inspected several sample GPX >>> files <https://developer.garmin.com/garmin-connect-api/sample-data/>, >>> but I did not find any containing velocity information. >>> >>> How do we report the velocity in GPX? >>> >>> Thank you. >>> >>> Álvaro >>> >> >> >> >> >> > > > > > > --0000000000002b907a05790b9d5e
smithalan+bigpond.com on Thu Oct 25 14:12:17 2018 (link), replying to msg
Sure, here's one I baked earlier: gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx ------ Original Message ------ From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> To: gpsxml+yahoogroups.com Sent: Thursday, 25 Oct, 2018 At 10:07 PM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? Thank you Robert and smithalan for your replies. I understand and agree with your point that GPX is "position oriented". We infer the ground speed using a number of algorithms and transformations, so it will add useful information to the file. I am definitely going to use Garmin extensions as you suggested, but I need to do some research and look into them. By any chance, do you guys happen to have a sample GPX file that makes use of Garmin extensions for recording speed, so that I can take a look? Thank you. Álvaro El jue., 25 oct. 2018 a las 4:39, smithalan smithalan smithalan+bigpond.com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> >) escribió: Just as an aside, I have determined that many GPS interfaces report speed (SOG) and course (COG) containing values that are reported to be derived independently of the position and time coordinates. There are some sources that indicate that they may be derived using a doppler measurement. In any case, these SOG and COG values provide a smoother result than that derived from position and time, and for that reason they are a valuable resource. I have chosen to record them in my GPX files as <extensions> . ------ Original Message ------ From: "Robert Lipe robertlipe+gmail.com <mailto:robertlipe+gmail.com> [gpsxml]" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > To: "gpsxml" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > Sent: Thursday, 25 Oct, 2018 At 7:17 AM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? We have this conversation about once a year on the list. <speed> was in GPX 1.0, but not 1.1 Most of the civilian/consumer uses of GPS (and thus, GPX) really only collects successive timestamped positions and, from that, can derive a concept of speed. There are a few cases where an additional sensor is added where another concept of speed is useful. Marine use sometimes has hull sensors and it's useful to make distinct concept of a boats position as determined via GPS relative to the relative speed of the water moving under the boat. What we have seen in practice is that people were using the instantaneous difference in locations a few seconds apart, where the GPS location error may exceed the amount of actual motion, and creating silly <speed> tags. No, your bike ride was never 43 miles per hour at the starting line. MOST of the actual users of the data were recomomputing the speed from the location and time anyway, so it was a bit redundant. However, we didn't explain this very well (and honestly, I don't think it was a conscious decision as much as a mistake) and we did leave open the cases like marine with transducer or bikes with wheel sensors (different than cadence sensors) that actually did something useful with speed. If you do choose to write speed in GPX 1.1, I'd recommend following Garmin's extensions. They seem to be the most widely recognized ones in the industry. Please don't just add them from the computed fix, though. RJL On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: It turns out that this was in fact documented here: https://www.topografix.com/gpx_manual.asp <https://www.topografix.com/gpx_manual..asp> The GPX website has improved a lot since the last time I visited it. Álvaro El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (<acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> >) escribió: Dear GPX community, I have been asked to add velocity information to my GPX files and I was wondering if there is a standard XML tag for this purpose. I have done some research online and I have inspected several sample GPX files <https://developer.garmin.com/garmin-connect-api/sample-data/> , but I did not find any containing velocity information. How do we report the velocity in GPX? Thank you. Álvaro ------?art_3899880_1285962982.1540501930446
acebrianjuan+gmail.com on Fri Oct 26 02:24:12 2018 (link), replying to msg
Thank you smithalan for sharing your GPX file. It is strange though, that your file has no schema namespaces in the <gpx> tag. I am really interested in learning how to write a proper file header to create valid GPX files that use Garmin extensions. Unfortunately, information on-line is really scarce. Álvaro El jue., 25 oct. 2018 a las 23:15, smithalan smithalan smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com>) escribió: > > > Sure, here's one I baked earlier: > gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx > > > > ------ Original Message ------ > From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" < > gpsxml+yahoogroups.com> > To: gpsxml+yahoogroups.com > Sent: Thursday, 25 Oct, 2018 At 10:07 PM > Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? > > > > > > > Thank you Robert and smithalan for your replies. > > I understand and agree with your point that GPX is "position oriented". > We infer the ground speed using a number of algorithms and transformations, > so it will add useful information to the file. > I am definitely going to use Garmin extensions as you suggested, but I > need to do some research and look into them. > By any chance, do you guys happen to have a sample GPX file that makes > use of Garmin extensions for recording speed, so that I can take a look? > > Thank you. > > Álvaro > > El jue., 25 oct. 2018 a las 4:39, smithalan smithalan > smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com>) escribió: > >> >> >> >> >> >> >> Just as an aside, I have determined that many GPS interfaces report >> speed (SOG) and course (COG) containing values that are reported to be >> derived independently of the position and time coordinates. There are some >> sources that indicate that they may be derived using a doppler measurement. >> In any case, these SOG and COG values provide a smoother result than that >> derived from position and time, and for that reason they are a valuable >> resource. I have chosen to record them in my GPX files as <extensions> . >> >> >> >> >> >> ------ Original Message ------ >> From: "Robert Lipe robertlipe+gmail.com [gpsxml]" <gpsxml+yahoogroups.com >> > >> To: "gpsxml" <gpsxml+yahoogroups.com> >> Sent: Thursday, 25 Oct, 2018 At 7:17 AM >> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >> >> >> >> >> >> >> We have this conversation about once a year on the list. >> >> <speed> was in GPX 1.0, but not 1.1 >> Most of the civilian/consumer uses of GPS (and thus, GPX) really only >> collects successive timestamped positions and, from that, can derive a >> concept of speed. There are a few cases where an additional sensor is >> added where another concept of speed is useful. Marine use sometimes has >> hull sensors and it's useful to make distinct concept of a boats position >> as determined via GPS relative to the relative speed of the water moving >> under the boat. >> >> What we have seen in practice is that people were using the instantaneous >> difference in locations a few seconds apart, where the GPS location error >> may exceed the amount of actual motion, and creating silly <speed> tags. >> No, your bike ride was never 43 miles per hour at the starting line. MOST >> of the actual users of the data were recomomputing the speed from the >> location and time anyway, so it was a bit redundant. >> >> However, we didn't explain this very well (and honestly, I don't think it >> was a conscious decision as much as a mistake) and we did leave open the >> cases like marine with transducer or bikes with wheel sensors (different >> than cadence sensors) that actually did something useful with speed. >> >> If you do choose to write speed in GPX 1.1, I'd recommend following >> Garmin's extensions. They seem to be the most widely recognized ones in the >> industry. Please don't just add them from the computed fix, though. >> >> RJL >> >> On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan >> acebrianjuan+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: >> >>> >>> >>> >>> >>> It turns out that this was in fact documented here: https://www. >>> topografix.com/gpx_manual.asp >>> <https://www.topografix.com/gpx_manual..asp> >>> The GPX website has improved a lot since the last time I visited it. >>> >>> Álvaro >>> >>> El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (< >>> acebrianjuan+gmail.com>) escribió: >>> >>>> Dear GPX community, >>>> >>>> I have been asked to add velocity information to my GPX files and I >>>> was wondering if there is a standard XML tag for this purpose. >>>> I have done some research online and I have inspected several sample >>>> GPX files >>>> <https://developer.garmin.com/garmin-connect-api/sample-data/>, but I >>>> did not find any containing velocity information. >>>> >>>> How do we report the velocity in GPX? >>>> >>>> Thank you. >>>> >>>> Álvaro >>>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> >> >> > > > > > > --0000000000001bc90905791e48f6
acebrianjuan+gmail.com on Fri Oct 26 03:56:21 2018 (link), replying to msg
Alan, I really appreciate your comments. I am pretty new to GPX and I am trying to do my best to stick to the best practices. I would say though, that your statement: "*[...] have never found a use for schematic namespaces in gpx files*" seems to go against what the GPX official web page is trying to encourage: "*It is your responsibility to ensure that any GPX files you create validate successfully against the GPX schema.*" Álvaro El vie., 26 oct. 2018 a las 11:57, Alan smithalan+bigpond.com [gpsxml] (< gpsxml+yahoogroups.com>) escribió: > > > I have been happily working with gpx for 10 years and have never found a > use for schematic namespaces in gpx files. > > Sent from my iPhone > > On 26 Oct 2018, at 8:23 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com > [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > > Thank you smithalan for sharing your GPX file. > > It is strange though, that your file has no schema namespaces in the <gpx> > tag. > I am really interested in learning how to write a proper file header to > create valid GPX files that use Garmin extensions. > > Unfortunately, information on-line is really scarce. > > Álvaro > > > El jue.., 25 oct. 2018 a las 23:15, smithalan smithalan > smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com>) escribió: > >> >> >> Sure, here's one I baked earlier: >> gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx >> >> >> >> ------ Original Message ------ >> From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" < >> gpsxml+yahoogroups.com> >> To: gpsxml+yahoogroups.com >> Sent: Thursday, 25 Oct, 2018 At 10:07 PM >> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >> >> >> >> >> >> >> Thank you Robert and smithalan for your replies. >> >> I understand and agree with your point that GPX is "position oriented". >> We infer the ground speed using a number of algorithms and transformations, >> so it will add useful information to the file. >> I am definitely going to use Garmin extensions as you suggested, but I >> need to do some research and look into them. >> By any chance, do you guys happen to have a sample GPX file that makes >> use of Garmin extensions for recording speed, so that I can take a look? >> >> Thank you. >> >> Álvaro >> >> El jue., 25 oct. 2018 a las 4:39, smithalan smithalan >> smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com>) escribió: >> >>> >>> >>> >>> >>> >>> >>> Just as an aside, I have determined that many GPS interfaces report >>> speed (SOG) and course (COG) containing values that are reported to be >>> derived independently of the position and time coordinates. There are some >>> sources that indicate that they may be derived using a doppler measurement. >>> In any case, these SOG and COG values provide a smoother result than >>> that derived from position and time, and for that reason they are a >>> valuable resource. I have chosen to record them in my GPX files as >>> <extensions> . >>> >>> >>> >>> >>> >>> ------ Original Message ------ >>> From: "Robert Lipe robertlipe+gmail.com [gpsxml]" < >>> gpsxml+yahoogroups.com> >>> To: "gpsxml" <gpsxml+yahoogroups.com> >>> Sent: Thursday, 25 Oct, 2018 At 7:17 AM >>> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >>> >>> >>> >>> >>> >>> >>> We have this conversation about once a year on the list. >>> >>> <speed> was in GPX 1.0, but not 1.1 >>> Most of the civilian/consumer uses of GPS (and thus, GPX) really only >>> collects successive timestamped positions and, from that, can derive a >>> concept of speed. There are a few cases where an additional sensor is >>> added where another concept of speed is useful. Marine use sometimes has >>> hull sensors and it's useful to make distinct concept of a boats position >>> as determined via GPS relative to the relative speed of the water moving >>> under the boat. >>> >>> What we have seen in practice is that people were using the >>> instantaneous difference in locations a few seconds apart, where the GPS >>> location error may exceed the amount of actual motion, and creating silly >>> <speed> tags. No, your bike ride was never 43 miles per hour at the >>> starting line. MOST of the actual users of the data were recomomputing the >>> speed from the location and time anyway, so it was a bit redundant. >>> >>> However, we didn't explain this very well (and honestly, I don't think >>> it was a conscious decision as much as a mistake) and we did leave open the >>> cases like marine with transducer or bikes with wheel sensors (different >>> than cadence sensors) that actually did something useful with speed. >>> >>> If you do choose to write speed in GPX 1..1, I'd recommend following >>> Garmin's extensions. They seem to be the most widely recognized ones in the >>> industry. Please don't just add them from the computed fix, though. >>> >>> RJL >>> >>> On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan >>> acebrianjuan+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: >>> >>>> >>>> >>>> >>>> >>>> It turns out that this was in fact documented here: https://www. >>>> topografix.com/gpx_manual.asp >>>> <https://www.topografix.com/gpx_manual....asp> >>>> The GPX website has improved a lot since the last time I visited it. >>>> >>>> Álvaro >>>> >>>> El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (< >>>> acebrianjuan+gmail.com>) escribió: >>>> >>>>> Dear GPX community, >>>>> >>>>> I have been asked to add velocity information to my GPX files and I >>>>> was wondering if there is a standard XML tag for this purpose. >>>>> I have done some research online and I have inspected several sample >>>>> GPX files >>>>> <https://developer.garmin.com/garmin-connect-api/sample-data/>, but I >>>>> did not find any containing velocity information. >>>>> >>>>> How do we report the velocity in GPX? >>>>> >>>>> Thank you. >>>>> >>>>> Álvaro >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > --000000000000afd6ab05791f91c9
acebrianjuan+gmail.com on Fri Oct 26 04:31:33 2018 (link), replying to msg
Alan, I see your point, but how can you tell "*[..] if it�??s valid gpx, then that�??s all that matters*" without using an actual schema? I am curious about how do you approach the validation of your files. Álvaro El vie., 26 oct. 2018 a las 13:19, Alan smithalan+bigpond.com [gpsxml] (< gpsxml+yahoogroups.com>) escribió: > > > I think that�??s all a bit contrived. As far as I can tell, if it�??s valid > gpx, then that�??s all that matters. I don�??t think there is any further �??best > practice �??. > > Sent from my iPhone > > On 26 Oct 2018, at 9:55 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com > [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > > Alan, > > I really appreciate your comments. > I am pretty new to GPX and I am trying to do my best to stick to the best > practices. > I would say though, that your statement: "*[...] have never found a use > for schematic namespaces in gpx files*" seems to go against what the GPX > official web page is trying to encourage: "*It is your responsibility to > ensure that any GPX files you create validate successfully against the GPX > schema.*" > > Álvaro > > El vie., 26 oct. 2018 a las 11:57, Alan smithalan+bigpond.com [gpsxml] (< > gpsxml+yahoogroups.com>) escribió: > >> >> >> I have been happily working with gpx for 10 years and have never found a >> use for schematic namespaces in gpx files. >> >> Sent from my iPhone >> >> On 26 Oct 2018, at 8:23 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com >> [gpsxml] <gpsxml+yahoogroups.com> wrote: >> >> >> >> Thank you smithalan for sharing your GPX file. >> >> It is strange though, that your file has no schema namespaces in the <gpx> >> tag. >> I am really interested in learning how to write a proper file header to >> create valid GPX files that use Garmin extensions. >> >> Unfortunately, information on-line is really scarce. >> >> Álvaro >> >> >> El jue.., 25 oct. 2018 a las 23:15, smithalan smithalan >> smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com>) escribió: >> >>> >>> >>> Sure, here's one I baked earlier: >>> gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx >>> >>> >>> >>> ------ Original Message ------ >>> From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" < >>> gpsxml+yahoogroups.com> >>> To: gpsxml+yahoogroups.com >>> Sent: Thursday, 25 Oct, 2018 At 10:07 PM >>> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >>> >>> >>> >>> >>> >>> >>> Thank you Robert and smithalan for your replies. >>> >>> I understand and agree with your point that GPX is "position oriented". >>> We infer the ground speed using a number of algorithms and transformations, >>> so it will add useful information to the file. >>> I am definitely going to use Garmin extensions as you suggested, but I >>> need to do some research and look into them. >>> By any chance, do you guys happen to have a sample GPX file that makes >>> use of Garmin extensions for recording speed, so that I can take a look? >>> >>> Thank you. >>> >>> Álvaro >>> >>> El jue., 25 oct. 2018 a las 4:39, smithalan smithalan >>> smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com >>> <gpsxml+yahoogroups..com>>) escribió: >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Just as an aside, I have determined that many GPS interfaces report >>>> speed (SOG) and course (COG) containing values that are reported to be >>>> derived independently of the position and time coordinates. There are some >>>> sources that indicate that they may be derived using a doppler measurement. >>>> In any case, these SOG and COG values provide a smoother result than >>>> that derived from position and time, and for that reason they are a >>>> valuable resource. I have chosen to record them in my GPX files as >>>> <extensions> . >>>> >>>> >>>> >>>> >>>> >>>> ------ Original Message ------ >>>> From: "Robert Lipe robertlipe+gmail.com [gpsxml]" < >>>> gpsxml+yahoogroups.com> >>>> To: "gpsxml" <gpsxml+yahoogroups.com> >>>> Sent: Thursday, 25 Oct, 2018 At 7:17 AM >>>> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >>>> >>>> >>>> >>>> >>>> >>>> >>>> We have this conversation about once a year on the list. >>>> >>>> <speed> was in GPX 1.0, but not 1.1 >>>> Most of the civilian/consumer uses of GPS (and thus, GPX) really only >>>> collects successive timestamped positions and, from that, can derive a >>>> concept of speed. There are a few cases where an additional sensor is >>>> added where another concept of speed is useful. Marine use sometimes has >>>> hull sensors and it's useful to make distinct concept of a boats position >>>> as determined via GPS relative to the relative speed of the water moving >>>> under the boat. >>>> >>>> What we have seen in practice is that people were using the >>>> instantaneous difference in locations a few seconds apart, where the GPS >>>> location error may exceed the amount of actual motion, and creating silly >>>> <speed> tags. No, your bike ride was never 43 miles per hour at the >>>> starting line. MOST of the actual users of the data were recomomputing the >>>> speed from the location and time anyway, so it was a bit redundant. >>>> >>>> However, we didn't explain this very well (and honestly, I don't think >>>> it was a conscious decision as much as a mistake) and we did leave open the >>>> cases like marine with transducer or bikes with wheel sensors (different >>>> than cadence sensors) that actually did something useful with speed. >>>> >>>> If you do choose to write speed in GPX 1..1, I'd recommend following >>>> Garmin's extensions. They seem to be the most widely recognized ones in the >>>> industry. Please don't just add them from the computed fix, though. >>>> >>>> RJL >>>> >>>> On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan >>>> acebrianjuan+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> >>>>> It turns out that this was in fact documented here: https://www. >>>>> topografix.com/gpx_manual.asp >>>>> <https://www.topografix.com/gpx_manual....asp> >>>>> The GPX website has improved a lot since the last time I visited it. >>>>> >>>>> Álvaro >>>>> >>>>> El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (< >>>>> acebrianjuan+gmail.com>) escribió: >>>>> >>>>>> Dear GPX community, >>>>>> >>>>>> I have been asked to add velocity information to my GPX files and I >>>>>> was wondering if there is a standard XML tag for this purpose. >>>>>> I have done some research online and I have inspected several sample >>>>>> GPX files >>>>>> <https://developer.garmin.com/garmin-connect-api/sample-data/>, but >>>>>> I did not find any containing velocity information. >>>>>> >>>>>> How do we report the velocity in GPX? >>>>>> >>>>>> Thank you.. >>>>>> >>>>>> Álvaro >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> > --0000000000006f069f0579200f02
acebrianjuan+gmail.com on Fri Oct 26 09:49:47 2018 (link), replying to msg
On another note, I would like to know if there are any copyright issues I should be aware of if we use Garmin extensions in our GPX files. Thank you. Álvaro El vie., 26 oct. 2018 a las 13:30, Álvaro Cebrián Juan (< acebrianjuan+gmail.com>) escribió: > Alan, > > I see your point, but how can you tell "*[..] if it�??s valid gpx, then > that�??s all that matters*" without using an actual schema? > I am curious about how do you approach the validation of your files. > > Álvaro > > El vie., 26 oct. 2018 a las 13:19, Alan smithalan+bigpond.com [gpsxml] (< > gpsxml+yahoogroups.com>) escribió: > >> >> >> I think that�??s all a bit contrived. As far as I can tell, if it�??s valid >> gpx, then that�??s all that matters. I don�??t think there is any further �??best >> practice �??. >> >> Sent from my iPhone >> >> On 26 Oct 2018, at 9:55 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com >> [gpsxml] <gpsxml+yahoogroups.com> wrote: >> >> >> >> Alan, >> >> I really appreciate your comments. >> I am pretty new to GPX and I am trying to do my best to stick to the >> best practices. >> I would say though, that your statement: "*[...] have never found a use >> for schematic namespaces in gpx files*" seems to go against what the GPX >> official web page is trying to encourage: "*It is your responsibility to >> ensure that any GPX files you create validate successfully against the GPX >> schema.*" >> >> Álvaro >> >> El vie., 26 oct. 2018 a las 11:57, Alan smithalan+bigpond.com [gpsxml] (< >> gpsxml+yahoogroups.com>) escribió: >> >>> >>> >>> I have been happily working with gpx for 10 years and have never found a >>> use for schematic namespaces in gpx files. >>> >>> Sent from my iPhone >>> >>> On 26 Oct 2018, at 8:23 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com >>> [gpsxml] <gpsxml+yahoogroups.com> wrote: >>> >>> >>> >>> Thank you smithalan for sharing your GPX file. >>> >>> It is strange though, that your file has no schema namespaces in the < >>> gpx> tag. >>> I am really interested in learning how to write a proper file header to >>> create valid GPX files that use Garmin extensions. >>> >>> Unfortunately, information on-line is really scarce. >>> >>> Álvaro >>> >>> >>> El jue.., 25 oct. 2018 a las 23:15, smithalan smithalan >>> smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com>) escribió: >>> >>>> >>>> >>>> Sure, here's one I baked earlier: >>>> gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx >>>> >>>> >>>> >>>> ------ Original Message ------ >>>> From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" < >>>> gpsxml+yahoogroups.com> >>>> To: gpsxml+yahoogroups.com >>>> Sent: Thursday, 25 Oct, 2018 At 10:07 PM >>>> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thank you Robert and smithalan for your replies. >>>> >>>> I understand and agree with your point that GPX is "position >>>> oriented". We infer the ground speed using a number of algorithms and >>>> transformations, so it will add useful information to the file. >>>> I am definitely going to use Garmin extensions as you suggested, but I >>>> need to do some research and look into them. >>>> By any chance, do you guys happen to have a sample GPX file that makes >>>> use of Garmin extensions for recording speed, so that I can take a >>>> look? >>>> >>>> Thank you. >>>> >>>> Álvaro >>>> >>>> El jue., 25 oct. 2018 a las 4:39, smithalan smithalan >>>> smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com >>>> <gpsxml+yahoogroups..com>>) escribió: >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Just as an aside, I have determined that many GPS interfaces report >>>>> speed (SOG) and course (COG) containing values that are reported to be >>>>> derived independently of the position and time coordinates. There are some >>>>> sources that indicate that they may be derived using a doppler measurement. >>>>> In any case, these SOG and COG values provide a smoother result than >>>>> that derived from position and time, and for that reason they are a >>>>> valuable resource. I have chosen to record them in my GPX files as >>>>> <extensions> . >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------ Original Message ------ >>>>> From: "Robert Lipe robertlipe+gmail.com [gpsxml]" < >>>>> gpsxml+yahoogroups.com> >>>>> To: "gpsxml" <gpsxml+yahoogroups.com> >>>>> Sent: Thursday, 25 Oct, 2018 At 7:17 AM >>>>> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We have this conversation about once a year on the list. >>>>> >>>>> <speed> was in GPX 1.0, but not 1.1 >>>>> Most of the civilian/consumer uses of GPS (and thus, GPX) really only >>>>> collects successive timestamped positions and, from that, can derive a >>>>> concept of speed. There are a few cases where an additional sensor is >>>>> added where another concept of speed is useful. Marine use sometimes has >>>>> hull sensors and it's useful to make distinct concept of a boats position >>>>> as determined via GPS relative to the relative speed of the water moving >>>>> under the boat. >>>>> >>>>> What we have seen in practice is that people were using the >>>>> instantaneous difference in locations a few seconds apart, where the GPS >>>>> location error may exceed the amount of actual motion, and creating silly >>>>> <speed> tags. No, your bike ride was never 43 miles per hour at the >>>>> starting line. MOST of the actual users of the data were recomomputing the >>>>> speed from the location and time anyway, so it was a bit redundant. >>>>> >>>>> However, we didn't explain this very well (and honestly, I don't think >>>>> it was a conscious decision as much as a mistake) and we did leave open the >>>>> cases like marine with transducer or bikes with wheel sensors (different >>>>> than cadence sensors) that actually did something useful with speed. >>>>> >>>>> If you do choose to write speed in GPX 1..1, I'd recommend following >>>>> Garmin's extensions. They seem to be the most widely recognized ones in the >>>>> industry. Please don't just add them from the computed fix, though. >>>>> >>>>> RJL >>>>> >>>>> On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan >>>>> acebrianjuan+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It turns out that this was in fact documented here: https://www. >>>>>> topografix.com/gpx_manual.asp >>>>>> <https://www.topografix.com/gpx_manual....asp> >>>>>> The GPX website has improved a lot since the last time I visited it. >>>>>> >>>>>> Álvaro >>>>>> >>>>>> El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (< >>>>>> acebrianjuan+gmail.com>) escribió: >>>>>> >>>>>>> Dear GPX community, >>>>>>> >>>>>>> I have been asked to add velocity information to my GPX files and I >>>>>>> was wondering if there is a standard XML tag for this purpose. >>>>>>> I have done some research online and I have inspected several sample >>>>>>> GPX files >>>>>>> <https://developer.garmin.com/garmin-connect-api/sample-data/>, but >>>>>>> I did not find any containing velocity information. >>>>>>> >>>>>>> How do we report the velocity in GPX? >>>>>>> >>>>>>> Thank you.. >>>>>>> >>>>>>> Álvaro >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >> > --000000000000faf87505792439f1
smithalan+bigpond.com on Fri Oct 26 12:28:41 2018 (link), replying to msg
It's valid GPS if it conforms to the syntax defined here <https://www.topografix.com/GPX/1/1/> There are some helpful tips on that site as well. I validate my GPX by pushing it through 3rd party GPX-aware apps: on Windows I used easyGPS, on Mac I use good ol'Google Earth (pity easyGps isn't on Mac) ------ Original Message ------ From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> To: gpsxml+yahoogroups.com Sent: Friday, 26 Oct, 2018 At 10:30 PM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? Alan, I see your point, but how can you tell "[..] if it�??s valid gpx, then that�??s all that matters" without using an actual schema? I am curious about how do you approach the validation of your files. Álvaro El vie., 26 oct. 2018 a las 13:19, Alan smithalan+bigpond.com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> >) escribió: I think that�??s all a bit contrived. As far as I can tell, if it�??s valid gpx, then that�??s all that matters. I don�??t think there is any further �??best practice �??. Sent from my iPhone On 26 Oct 2018, at 9:55 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: Alan, I really appreciate your comments. I am pretty new to GPX and I am trying to do my best to stick to the best practices. I would say though, that your statement: "[...] have never found a use for schematic namespaces in gpx files" seems to go against what the GPX official web page is trying to encourage: "It is your responsibility to ensure that any GPX files you create validate successfully against the GPX schema." Álvaro El vie., 26 oct. 2018 a las 11:57, Alan smithalan+bigpond.com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> >) escribió: I have been happily working with gpx for 10 years and have never found a use for schematic namespaces in gpx files. Sent from my iPhone On 26 Oct 2018, at 8:23 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: Thank you smithalan for sharing your GPX file. It is strange though, that your file has no schema namespaces in the <gpx> tag. I am really interested in learning how to write a proper file header to create valid GPX files that use Garmin extensions. Unfortunately, information on-line is really scarce. Álvaro El jue.., 25 oct. 2018 a las 23:15, smithalan smithalan smithalan+bigpond.com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups..com <mailto:gpsxml+yahoogroups.com> >) escribió: Sure, here's one I baked earlier: gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx <http://gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx> ------ Original Message ------ From: "Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml]" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > To: gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> Sent: Thursday, 25 Oct, 2018 At 10:07 PM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? Thank you Robert and smithalan for your replies. I understand and agree with your point that GPX is "position oriented". We infer the ground speed using a number of algorithms and transformations, so it will add useful information to the file. I am definitely going to use Garmin extensions as you suggested, but I need to do some research and look into them. By any chance, do you guys happen to have a sample GPX file that makes use of Garmin extensions for recording speed, so that I can take a look? Thank you. Álvaro El jue., 25 oct. 2018 a las 4:39, smithalan smithalan smithalan+bigpond.com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups..com> >) escribió: Just as an aside, I have determined that many GPS interfaces report speed (SOG) and course (COG) containing values that are reported to be derived independently of the position and time coordinates. There are some sources that indicate that they may be derived using a doppler measurement. In any case, these SOG and COG values provide a smoother result than that derived from position and time, and for that reason they are a valuable resource. I have chosen to record them in my GPX files as <extensions> . ------ Original Message ------ From: "Robert Lipe robertlipe+gmail.com <mailto:robertlipe+gmail.com> [gpsxml]" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > To: "gpsxml" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > Sent: Thursday, 25 Oct, 2018 At 7:17 AM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? We have this conversation about once a year on the list. <speed> was in GPX 1.0, but not 1.1 Most of the civilian/consumer uses of GPS (and thus, GPX) really only collects successive timestamped positions and, from that, can derive a concept of speed. There are a few cases where an additional sensor is added where another concept of speed is useful. Marine use sometimes has hull sensors and it's useful to make distinct concept of a boats position as determined via GPS relative to the relative speed of the water moving under the boat. What we have seen in practice is that people were using the instantaneous difference in locations a few seconds apart, where the GPS location error may exceed the amount of actual motion, and creating silly <speed> tags. No, your bike ride was never 43 miles per hour at the starting line. MOST of the actual users of the data were recomomputing the speed from the location and time anyway, so it was a bit redundant. However, we didn't explain this very well (and honestly, I don't think it was a conscious decision as much as a mistake) and we did leave open the cases like marine with transducer or bikes with wheel sensors (different than cadence sensors) that actually did something useful with speed. If you do choose to write speed in GPX 1..1, I'd recommend following Garmin's extensions. They seem to be the most widely recognized ones in the industry. Please don't just add them from the computed fix, though. RJL On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: It turns out that this was in fact documented here: https://www.topografix.com/gpx_manual.asp <https://www.topografix.com/gpx_manual....asp> The GPX website has improved a lot since the last time I visited it. Álvaro El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (<acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> >) escribió: Dear GPX community, I have been asked to add velocity information to my GPX files and I was wondering if there is a standard XML tag for this purpose. I have done some research online and I have inspected several sample GPX files <https://developer.garmin.com/garmin-connect-api/sample-data/> , but I did not find any containing velocity information. How do we report the velocity in GPX? Thank you.. Álvaro ------?art_4748780_1547531931.1540582113801
smithalan+bigpond.com on Fri Oct 26 12:29:35 2018 (link), replying to msg
Can't help you there, but I shouldn't think it's an issue. ------ Original Message ------ From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" <gpsxml+yahoogroups.com> To: gpsxml+yahoogroups.com Sent: Saturday, 27 Oct, 2018 At 3:29 AM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? On another note, I would like to know if there are any copyright issues I should be aware of if we use Garmin extensions in our GPX files. Thank you. Álvaro El vie., 26 oct. 2018 a las 13:30, Álvaro Cebrián Juan (<acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> >) escribió: Alan, I see your point, but how can you tell "[..] if it�??s valid gpx, then that�??s all that matters" without using an actual schema? I am curious about how do you approach the validation of your files. Álvaro El vie., 26 oct. 2018 a las 13:19, Alan smithalan+bigpond..com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> >) escribió: I think that�??s all a bit contrived. As far as I can tell, if it�??s valid gpx, then that�??s all that matters. I don�??t think there is any further �??best practice �??. Sent from my iPhone On 26 Oct 2018, at 9:55 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: Alan, I really appreciate your comments. I am pretty new to GPX and I am trying to do my best to stick to the best practices. I would say though, that your statement: "[...] have never found a use for schematic namespaces in gpx files" seems to go against what the GPX official web page is trying to encourage: "It is your responsibility to ensure that any GPX files you create validate successfully against the GPX schema." Álvaro El vie., 26 oct. 2018 a las 11:57, Alan smithalan+bigpond.com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> >) escribió: I have been happily working with gpx for 10 years and have never found a use for schematic namespaces in gpx files. Sent from my iPhone On 26 Oct 2018, at 8:23 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: Thank you smithalan for sharing your GPX file. It is strange though, that your file has no schema namespaces in the <gpx> tag. I am really interested in learning how to write a proper file header to create valid GPX files that use Garmin extensions. Unfortunately, information on-line is really scarce. Álvaro El jue.., 25 oct. 2018 a las 23:15, smithalan smithalan smithalan+bigpond.com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> >) escribió: Sure, here's one I baked earlier: gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx <http://gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx> ------ Original Message ------ From: "Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml]" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > To: gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> Sent: Thursday, 25 Oct, 2018 At 10:07 PM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? Thank you Robert and smithalan for your replies. I understand and agree with your point that GPX is "position oriented".. We infer the ground speed using a number of algorithms and transformations, so it will add useful information to the file. I am definitely going to use Garmin extensions as you suggested, but I need to do some research and look into them. By any chance, do you guys happen to have a sample GPX file that makes use of Garmin extensions for recording speed, so that I can take a look? Thank you. Álvaro El jue., 25 oct. 2018 a las 4:39, smithalan smithalan smithalan+bigpond.com <mailto:smithalan+bigpond.com> [gpsxml] (<gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups..com> >) escribió: Just as an aside, I have determined that many GPS interfaces report speed (SOG) and course (COG) containing values that are reported to be derived independently of the position and time coordinates. There are some sources that indicate that they may be derived using a doppler measurement. In any case, these SOG and COG values provide a smoother result than that derived from position and time, and for that reason they are a valuable resource. I have chosen to record them in my GPX files as <extensions> . ------ Original Message ------ From: "Robert Lipe robertlipe+gmail.com <mailto:robertlipe+gmail.com> [gpsxml]" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups..com> > To: "gpsxml" <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > Sent: Thursday, 25 Oct, 2018 At 7:17 AM Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? We have this conversation about once a year on the list. <speed> was in GPX 1.0, but not 1.1 Most of the civilian/consumer uses of GPS (and thus, GPX) really only collects successive timestamped positions and, from that, can derive a concept of speed. There are a few cases where an additional sensor is added where another concept of speed is useful. Marine use sometimes has hull sensors and it's useful to make distinct concept of a boats position as determined via GPS relative to the relative speed of the water moving under the boat. What we have seen in practice is that people were using the instantaneous difference in locations a few seconds apart, where the GPS location error may exceed the amount of actual motion, and creating silly <speed> tags. No, your bike ride was never 43 miles per hour at the starting line. MOST of the actual users of the data were recomomputing the speed from the location and time anyway, so it was a bit redundant. However, we didn't explain this very well (and honestly, I don't think it was a conscious decision as much as a mistake) and we did leave open the cases like marine with transducer or bikes with wheel sensors (different than cadence sensors) that actually did something useful with speed. If you do choose to write speed in GPX 1..1, I'd recommend following Garmin's extensions. They seem to be the most widely recognized ones in the industry. Please don't just add them from the computed fix, though. RJL On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: It turns out that this was in fact documented here: https://www.topografix.com/gpx_manual.asp <https://www.topografix.com/gpx_manual....asp> The GPX website has improved a lot since the last time I visited it. Álvaro El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (<acebrianjuan+gmail.com <mailto:acebrianjuan+gmail.com> >) escribió: Dear GPX community, I have been asked to add velocity information to my GPX files and I was wondering if there is a standard XML tag for this purpose. I have done some research online and I have inspected several sample GPX files <https://developer.garmin.com/garmin-connect-api/sample-data/> , but I did not find any containing velocity information. How do we report the velocity in GPX? Thank you.. Álvaro ------?art_4748815_630057650.1540582168235
robertlipe+gmail.com on Fri Oct 26 16:10:35 2018 (link), replying to msg
If you ever need to see what's going on with gpx in Earth, it calls out to the open source GPSBabel , which is my creation. It's on GitHub. On Fri, Oct 26, 2018, 2:32 PM smithalan smithalan smithalan+bigpond.com [gpsxml] <gpsxml+yahoogroups.com> wrote: > > > It's valid GPS if it conforms to the syntax defined here > <https://www.topografix.com/GPX/1/1/> > There are some helpful tips on that site as well. > I validate my GPX by pushing it through 3rd party GPX-aware apps: on > Windows I used easyGPS, on Mac I use good ol'Google Earth (pity easyGps > isn't on Mac) > > > > ------ Original Message ------ > From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" < > gpsxml+yahoogroups.com> > To: gpsxml+yahoogroups.com > Sent: Friday, 26 Oct, 2018 At 10:30 PM > Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? > > > > > > > Alan, > > I see your point, but how can you tell "*[..] if it�??s valid gpx, then > that�??s all that matters*" without using an actual schema? > I am curious about how do you approach the validation of your files. > > Álvaro > > El vie., 26 oct. 2018 a las 13:19, Alan smithalan+bigpond.com [gpsxml] (< > gpsxml+yahoogroups.com>) escribió: > >> >> >> >> >> >> >> I think that�??s all a bit contrived. As far as I can tell, if it�??s valid >> gpx, then that�??s all that matters. I don�??t think there is any further �??best >> practice �??. >> >> Sent from my iPhone >> >> On 26 Oct 2018, at 9:55 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com >> [gpsxml] <gpsxml+yahoogroups.com> wrote: >> >> >> >> >> Alan, >> >> I really appreciate your comments. >> I am pretty new to GPX and I am trying to do my best to stick to the >> best practices. >> I would say though, that your statement: "*[...] have never found a use >> for schematic namespaces in gpx files*" seems to go against what the GPX >> official web page is trying to encourage: "*It is your responsibility to >> ensure that any GPX files you create validate successfully against the GPX >> schema.*" >> >> Álvaro >> >> El vie., 26 oct. 2018 a las 11:57, Alan smithalan+bigpond.com [gpsxml] (< >> gpsxml+yahoogroups.com>) escribió: >> >>> >>> >>> >>> >>> >>> >>> I have been happily working with gpx for 10 years and have never found a >>> use for schematic namespaces in gpx files. >>> >>> Sent from my iPhone >>> >>> On 26 Oct 2018, at 8:23 pm, Álvaro Cebrián Juan acebrianjuan+gmail.com >>> [gpsxml] <gpsxml+yahoogroups.com> wrote: >>> >>> >>> >>> >>> Thank you smithalan for sharing your GPX file. >>> >>> It is strange though, that your file has no schema namespaces in the < >>> gpx> tag. >>> I am really interested in learning how to write a proper file header to >>> create valid GPX files that use Garmin extensions. >>> >>> Unfortunately, information on-line is really scarce. >>> >>> Álvaro >>> >>> >>> El jue.., 25 oct. 2018 a las 23:15, smithalan smithalan >>> smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups..com >>> <gpsxml+yahoogroups.com>>) escribió: >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Sure, here's one I baked earlier: >>>> gpsanimator.com/raceQs/logs2/U-1020991/2018-10-03T10:53:50.gpx >>>> >>>> >>>> >>>> ------ Original Message ------ >>>> From: "Álvaro Cebrián Juan acebrianjuan+gmail.com [gpsxml]" < >>>> gpsxml+yahoogroups.com> >>>> To: gpsxml+yahoogroups.com >>>> Sent: Thursday, 25 Oct, 2018 At 10:07 PM >>>> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thank you Robert and smithalan for your replies. >>>> >>>> I understand and agree with your point that GPX is "position >>>> oriented". We infer the ground speed using a number of algorithms and >>>> transformations, so it will add useful information to the file. >>>> I am definitely going to use Garmin extensions as you suggested, but I >>>> need to do some research and look into them. >>>> By any chance, do you guys happen to have a sample GPX file that makes >>>> use of Garmin extensions for recording speed, so that I can take a >>>> look? >>>> >>>> Thank you. >>>> >>>> Álvaro >>>> >>>> El jue., 25 oct. 2018 a las 4:39, smithalan smithalan >>>> smithalan+bigpond.com [gpsxml] (<gpsxml+yahoogroups.com >>>> <gpsxml+yahoogroups..com>>) escribió: >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Just as an aside, I have determined that many GPS interfaces report >>>>> speed (SOG) and course (COG) containing values that are reported to be >>>>> derived independently of the position and time coordinates. There are some >>>>> sources that indicate that they may be derived using a doppler measurement. >>>>> In any case, these SOG and COG values provide a smoother result than >>>>> that derived from position and time, and for that reason they are a >>>>> valuable resource. I have chosen to record them in my GPX files as >>>>> <extensions> . >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------ Original Message ------ >>>>> From: "Robert Lipe robertlipe+gmail.com [gpsxml]" < >>>>> gpsxml+yahoogroups.com> >>>>> To: "gpsxml" <gpsxml+yahoogroups.com> >>>>> Sent: Thursday, 25 Oct, 2018 At 7:17 AM >>>>> Subject: Re: [gpsxml] Re: Is there a standard GPX tag for velocity? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We have this conversation about once a year on the list. >>>>> >>>>> <speed> was in GPX 1.0, but not 1.1 >>>>> Most of the civilian/consumer uses of GPS (and thus, GPX) really only >>>>> collects successive timestamped positions and, from that, can derive a >>>>> concept of speed. There are a few cases where an additional sensor is >>>>> added where another concept of speed is useful. Marine use sometimes has >>>>> hull sensors and it's useful to make distinct concept of a boats position >>>>> as determined via GPS relative to the relative speed of the water moving >>>>> under the boat. >>>>> >>>>> What we have seen in practice is that people were using the >>>>> instantaneous difference in locations a few seconds apart, where the GPS >>>>> location error may exceed the amount of actual motion, and creating silly >>>>> <speed> tags. No, your bike ride was never 43 miles per hour at the >>>>> starting line. MOST of the actual users of the data were recomomputing the >>>>> speed from the location and time anyway, so it was a bit redundant. >>>>> >>>>> However, we didn't explain this very well (and honestly, I don't think >>>>> it was a conscious decision as much as a mistake) and we did leave open the >>>>> cases like marine with transducer or bikes with wheel sensors (different >>>>> than cadence sensors) that actually did something useful with speed. >>>>> >>>>> If you do choose to write speed in GPX 1..1, I'd recommend following >>>>> Garmin's extensions. They seem to be the most widely recognized ones in the >>>>> industry. Please don't just add them from the computed fix, though. >>>>> >>>>> RJL >>>>> >>>>> On Wed, Oct 24, 2018 at 1:18 PM Álvaro Cebrián Juan >>>>> acebrianjuan+gmail.com [gpsxml] <gpsxml+yahoogroups.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It turns out that this was in fact documented here: https://www. >>>>>> topografix.com/gpx_manual.asp >>>>>> <https://www.topografix..com/gpx_manual....asp> >>>>>> The GPX website has improved a lot since the last time I visited it. >>>>>> >>>>>> Álvaro >>>>>> >>>>>> El mié., 24 oct. 2018 a las 17:03, Álvaro Cebrián Juan (< >>>>>> acebrianjuan+gmail.com>) escribió: >>>>>> >>>>>>> Dear GPX community, >>>>>>> >>>>>>> I have been asked to add velocity information to my GPX files and I >>>>>>> was wondering if there is a standard XML tag for this purpose. >>>>>>> I have done some research online and I have inspected several sample >>>>>>> GPX files >>>>>>> <https://developer.garmin.com/garmin-connect-api/sample-data/>, but >>>>>>> I did not find any containing velocity information. >>>>>>> >>>>>>> How do we report the velocity in GPX? >>>>>>> >>>>>>> Thank you.. >>>>>>> >>>>>>> Álvaro >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> >> > > > > > > > > --00000000000086cdcf057929d34c
awayteamsoftware+yahoo.com on Sun Oct 28 12:00:26 2018 (link), replying to msg
Álvaro, Topografix provides a validation guide [1], including details of a test to determine whether a GPX file is valid or not. This test both confirms compliance and helps to diagnose any problems. GPX is an XML-based format, as the GPX schema clearly states [2] and which requires suitable schemas as you rightly say. Away Team published a simple GPX extension [3], including speed, to expose the components of Java Specification Request Location API (JSR 179) and to address some of the issues you’ve raised. I hope this helps. Rob Smith Away Team [1] https://www.topografix.com/gpx_validation.asp https://www.topografix.com/gpx_validation.asp [2] https://www.topografix.com/gpx/1/1/ https://www.topografix.com/gpx/1/1/ [3] http://www.awayteam.co.uk/Gpx11GpsLocationExtension/v2 http://www.awayteam.co.uk/Gpx11GpsLocationExtension/v2
acebrianjuan+gmail.com on Tue Oct 30 09:54:50 2018 (link), replying to msg
Thank you all for your inputs. Cheers, Álvaro El dom., 28 oct. 2018 a las 20:01, awayteamsoftware+yahoo.com [gpsxml] (< gpsxml+yahoogroups.com>) escribió: > > > Álvaro, > > Topografix provides a validation guide [1], including details of a test to > determine whether a GPX file is valid or not. This test both confirms > compliance and helps to diagnose any problems. > > GPX is an XML-based format, as the GPX schema clearly states [2] and which > requires suitable schemas as you rightly say. Away Team published a simple > GPX extension [3], including speed, to expose the components of Java > Specification Request Location API (JSR 179) and to address some of the > issues you�??ve raised. > > I hope this helps. > > Rob Smith > Away Team > > [1] https://www.topografix.com/gpx_validation.asp > [2] https://www.topografix.com/gpx/1/1/ > [3] http://www.awayteam.co.uk/Gpx11GpsLocationExtension/v2 > > --00000000000010f8fb0579750b2c
jfriedl+yahoo.com on Sat Nov 10 17:15:46 2018 (link)
I often come across apps that produce tracks with repeated timestamps, and I'd like to report them to the app developer as in error, but I can't seem to find something in the standard that indicates that repeated timestamps, or even out-of-order timestamps, are invalid. I've always assumed that timestamps, if they exist, must be monotonically increasing, but perhaps the mistake is mine....
smithalan+bigpond.com on Sat Nov 10 18:00:14 2018 (link), replying to msg
No, you are correct. If you find apps with out-of-order timestamps, you should contact the developer. ------ Original Message ------ From: "jfriedl+yahoo.com [gpsxml]" <gpsxml+yahoogroups.com> To: gpsxml+yahoogroups.com Sent: Wednesday, 31 Oct, 2018 At 5:04 PM Subject: [gpsxml] Are repeated timestamps against the standard? I often come across apps that produce tracks with repeated timestamps, and I'd like to report them to the app developer as in error, but I can't seem to find something in the standard that indicates that repeated timestamps, or even out-of-order timestamps, are invalid. I've always assumed that timestamps, if they exist, must be monotonically increasing, but perhaps the mistake is mine.... ------?art_1312105_1627405870.1541901529770
robertlipe+gmail.com on Sat Nov 10 18:40:10 2018 (link), replying to msg
You didn't include an example and your language is imprecise enough that it's going to be difficult to get a formal ruling. If you have multiple <time> tags within a single <trkpt>, that's pretty weird. Having multiple <trkpt> with the same <time> value seems fair game; perhaps the device was configured for a low resolution time but the device was able to detect enough motion (perhaps a vertex in a track that was important to keep from smoothing) and dropped multiple times. Having out of order points is something that GPSBabel considers an error for many cases. It happens a lot in loggers that have been powered off and are relying in their crappy internal clock to tell time. They'll stupidly log.points with the last known position and the RTC time. Sometimes they're marked.invalid.but lots of software loses that data. Then the GPS gets an actual.valid fix and the time snaps backward. We don't consider this fatal for all conversations, but if you're trying to do mathy stuff with time and it goes backwards sometimes, we just can't cope So,. depending on the exact nature of your gpx file, it could range from ok to distasteful, even if not formally forbidden. (It might be - I'm on a fone and working from memory.) Not everything that validates is good taste. On Sat, Nov 10, 2018 at 7:15 PM jfriedl+yahoo.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > I often come across apps that produce tracks with repeated timestamps, and > I'd like to report them to the app developer as in error, but I can't seem > to find something in the standard that indicates that repeated timestamps, > or even out-of-order timestamps, are invalid. > > > I've always assumed that timestamps, if they exist, must be monotonically > increasing, but perhaps the mistake is mine.... > > > > --000000000000a8543d057a5a7e77
tt+smartcomsoftware.com on Sun Nov 11 02:53:58 2018 (link), replying to msg
It�??s not just loggers that get time wrong. At the midnight crossover, many GPS receivers will continue to output a number of time stamps with the right time and the previous day�??s date, until they update the date. Tim Smartcom Software Ltd | Garlogs, Nether Wallop, Stockbridge SO20 8DP, United Kingdom T: (0)7985 927376 | <http://www.smartcomsoftware.co.uk/> smartcomsoftware.co.uk This email may contain confidential or otherwise proprietary material and is for use only by the intended recipients. If you received this message in error, please notify us and remove it from your system. Smartcom Software Ltd is a company registered in England and Wales. Registered number 05641521 From: gpsxml+yahoogroups.com [mailto:gpsxml+yahoogroups.com] Sent: 11 November 2018 02:39 To: gpsxml <gpsxml+yahoogroups.com> Subject: Re: [gpsxml] Are repeated timestamps against the standard? You didn't include an example and your language is imprecise enough that it's going to be difficult to get a formal ruling. If you have multiple <time> tags within a single <trkpt>, that's pretty weird. Having multiple <trkpt> with the same <time> value seems fair game; perhaps the device was configured for a low resolution time but the device was able to detect enough motion (perhaps a vertex in a track that was important to keep from smoothing) and dropped multiple times. Having out of order points is something that GPSBabel considers an error for many cases. It happens a lot in loggers that have been powered off and are relying in their crappy internal clock to tell time. They'll stupidly log.points with the last known position and the RTC time. Sometimes they're marked.invalid.but lots of software loses that data. Then the GPS gets an actual.valid fix and the time snaps backward. We don't consider this fatal for all conversations, but if you're trying to do mathy stuff with time and it goes backwards sometimes, we just can't cope So,. depending on the exact nature of your gpx file, it could range from ok to distasteful, even if not formally forbidden.. (It might be - I'm on a fone and working from memory.) Not everything that validates is good taste. On Sat, Nov 10, 2018 at 7:15 PM jfriedl+yahoo.com <mailto:jfriedl+yahoo.com> [gpsxml] <gpsxml+yahoogroups.com <mailto:gpsxml+yahoogroups.com> > wrote: I often come across apps that produce tracks with repeated timestamps, and I'd like to report them to the app developer as in error, but I can't seem to find something in the standard that indicates that repeated timestamps, or even out-of-order timestamps, are invalid. I've always assumed that timestamps, if they exist, must be monotonically increasing, but perhaps the mistake is mine.... ------?extPart_000_09F5_01D479AC.C22B2410
jfriedl+yahoo.com on Mon Dec 17 08:29:23 2018 (link), replying to msg
Sorry, I meant multiplewith the exact same
egroups+topografix.com on Mon Dec 17 09:56:29 2018 (link), replying to msg
Hello jfriedl+yahoo.com, Sunday, December 2, 2018, 11:38:32 AM, you wrote: > Sorry, I meant multiple <trkpt> with the exact same <time>. > I'm not asking about what might be in good taste... I'm looking > for a pointer to the official standard that speaks to this. I > couldn't find it, so perhaps it doesn't exist? There was never any discussion of this until now. There's nothing in the standard forbidding this, or tracks with timestamps that go backwards in time or jump around. I don't see anything "in bad taste" about the following: Alice, Bob, and Charlie are recording data for a new stretch of the Appalachian Trail. Alice and Bob hike northbound from two separate points, and Charlie hikes southbound. Between the three of them, they've completely covered the new stretch of trail, and have recorded three valid GPX files, A, B, and C. Alice and Bob concatenate their trail segments, resulting in A+B.gpx, which now has multiple trackpoints with the same time, since Alice and Bob were in different locations on the same day. Charlie reverses his track to make it northbound, and now time goes backwards in ReverseC.gpx. They concatenate that file to create A+B+ReverseC.gpx, covering the entire trail segment from south to north, but with some weird time behaviors in the file. I believe that's a valid GPX file, and my GPX-enabled software will happily let you create it. We defined an automated test to determine GPX validity based on schema validation. If you believe A+B+ReverseC.gpx is not a valid GPX file, how would you define the GPX schema to disallow it? -- Dan Foster
Boston.Uri.Kai+mac.com on Fri Dec 28 15:50:46 2018 (link)
Hi all! New here, not a developer, yet exploring the facts about GPX files, being a Geocacher. I have been having 'issues' with Emoji characters within the GPX file, and was wondering if the GPX 1.1 schema in compatible with Emoji characters. If I load a GPX file which contains an Emoji character, onto my Garmin GPS device, the Emoji is not displayed properly, just a blank character instead. Is this an issue of the GPS receiver, or the GPX file, or both? Would love to view Emojis and any new characters on a GPS receiver as they are meant to be. Thanks!
olopierpa+gmail.com on Fri Dec 28 16:41:20 2018 (link), replying to msg
On Sat, Dec 29, 2018 at 12:50 AM Boston.Uri.Kai+mac.com [gpsxml] < gpsxml+yahoogroups.com> wrote: > > > If I load a GPX file which contains an Emoji character, onto my Garmin GPS > device, the Emoji is not displayed properly, just a blank character > instead. Is this an issue of the GPS receiver, or the GPX file, or both? > A GPS device can't be expected to support all of the 137,000 characters currently in Unicode, and the 146 scripts. Supporting all of Unicode requires a massive bulk of code and data which is not yet supportable on a small handheld device running on tiny batteries. Maybe a few years in the future it will be. If you only want a few emojis related to geocaching, then the best course of action would be to let Garmin know about your desire, IMO Cheers --000000000000173fc3057e1e703e
jfriedl+yahoo.com on Fri Jan 04 04:56:13 2019 (link), replying to msg
> If you believe A+B+ReverseC.gpx is not a valid GPX file, how would you define the GPX schema to disallow it? Thanks for the thoughtful response, Dan. My original question is to whether that would be valid; I'm not claiming that it is not valid. (Based on my general idea of tracklogs, I wish it _would not_ be valid, but I can find nothing in the standard to support that general opinion, and hence the question.) My idea of a tracklog is that if timestamps are included, it represents a single thread of movement. I have extensive, broad, and deep experience with tracklogs, both as a user and a developer, and in every case a tracklog with timestamps as been exactly what I describe, and any repeated or non-linear timestamps have represented errors in the creating software. If your A+B+ReverseC.gpx example is indeed allowed by the standard, as it seems, then my bug reports to the developers about the errors are less impactful. They're still bugs, but "your software is producing non-standard files" perhaps gets more attention.... Jeffrey
stephane.peneau+wanadoo.fr on Tue May 28 13:47:00 2019 (link), replying to msg
Hi! Is there something new about GPX v2 ? I use a dual frequency gnss receiver with centimeter accuracy, and I'd like to store each point accuracy before uploading the file in the OpenStreetMap gpx database. Best,
robertlipe+gmail.com on Sun Nov 10 14:00:32 2019 (link)
TL;DR: Carry on. Yahoo has decided that they no longer want to be in the Groups biz and next month this group, like all others, will become "just" a mailing list, with files and all group history permanently removed from Yahoo's servers. This is the reality of relying on free services in modern times. When this group started, running a public mail list with archives was really hard. (Spam ensures that it still is...) Google groups and Groups.io both have migration and hosting issues, too. I have made an archive of this group, so nothing will be lost. I think. $ ls ~/gps/yahoo/yahoo-group-archiver/groups/gpsxml about calendar files photos databases links polls attachments email members Yahoo will continue as a mail server though our archives will disappear. Since I have copies and I've long been annoyed that our groups aren't publicly searchable (that's just the reality of yahoogroups) I may make a copy of these archives publicly available - and hopefully searchable in your favorite search engine - in the future. I'll post details if/when that comes to fruition. [[[ Tear Here ]]] Since this post may start a flurry of "whatabout v2" post, I'll speak to my perception of the elephant in the room. GPX has been successful in its goals of promoting independence of GPS data. The world around us has also changed. Early in this century GPS file diversity was a huge problem for our industry. (I've had a side gig solving that problem for 18 years next month...) Web apps and services are a thing now. The handheld GPS market has only one real survivor. That survivor uses GPX in their handheld and PND devices natively. (Yay!) Copying points between two such devices these days is literally a drag and a drop in a way we only dreamed of in the era of serially connected units. Niche markets like fitness, marine, and aviation all have additional lockin issues and GPX hasn't been as successful on those devices natively. XML is now seen as a bit old school (whither XHTML) and JSON and GeoJSON specifically have moved into some of the spaces for IPC and microservices where GPX would have been used. Maybe we could have helped in that space with GPXJSON or a protobuf respelling of GPX, but we've not had a lot of howling for that. We also have the blessing/curse of the installed base. There are millions of hardware devices that speak GPX 1.0 or 1.1 and they're simply not likely to change. This probably shouldn't paralyze us. For most of us, speaking a slightly different dialect of GPX shouldn't be THAT hard as long as we continue to provide good validation and conversion tools. At a comparison that'll bristle some of you, I think of us like the C standard: C89 (GPX 1.0) was rock solid and C99 (GPX 1.1) was a lovely minor revision that's so widespread that many C programmers didn't even know - or care - there was a C11. If we marched through versions quickly, I think we'd lose our audience. I also said before that I'd like to make a 1.2 or 2.0 happen. I still would, I've just been blindsided by real life in the last few years. Sometime in Q1, I should be clearing up to devote some more time to this. There are several extensions (fitness, temperature, etc.) that are well proven and that could be collapsed into our core without much fuss if we all follow the normal "ignore tags you don't understand" guidelines in our readers. We'll need a few more contributors to really get behind such work to make it happen. Followups, if any, about GPX.next in a different thread than this one about the future of our releationship with yahoogroups, please. RJL Disclaimer: I don't own this group or the GPX spec. I'm "merely" a mod (that's been here since 2001). I only speak from a position of authority if Dan doesn't. :-) --000000000000c0ed7205970524b4
yahoo+web.knobby.ws on Sun Nov 10 15:08:13 2019 (link)
"The handheld GPS market has only one real survivor." Maybe. I wonder how many tracks are being generated on smartphones? I assume most of those are GPX (at least that's what I see). Is there a movement away from GPX to GeoJSON? https://wiki.openstreetmap.org/wiki/GeoJSON https://wiki.openstreetmap.org/wiki/GeoJSON
robertlipe+gmail.com on Sun Nov 10 16:02:13 2019 (link), replying to msg
On Sun, Nov 10, 2019 at 5:08 PM yahoo+web.knobby.ws [gpsxml] < gpsxml+yahoogroups.com> wrote: > "The handheld GPS market has only one real survivor." Maybe. I wonder how > many tracks are being generated on smartphones? I assume most of those are > GPX (at least that's what I see). > Fair point. I was thinking of actual dedicated hardware. Phones have certainly contributed to the downfall of both PNDs and dedicated outdoor units. In very few cases do I think we're talking about GPX files on the device themselves. Usually for that kind of app, data is uploaded to some dedicated service in the cloud and then available for export as GPX or KML or whatever. > Is there a movement away from GPX to GeoJSON? > https://wiki.openstreetmap.org/wiki/GeoJSON > As I mentioned, there's certainly some overlap. GeoJSON is more oriented toward traditional GIS parlance. A GPS (of the variety at the turn of the century) may generate one or more track segments that is part of a track. GeoJSON - like the ubiquitous shapefiles are more for describing map features. This is a polygon for a county outline. The starting and ending point is the same. This is a multipoygon - it describes two distinctive areas that comprise a zip code and has a "hole" in it because the center of that zip code is so dense that the post office gave those nine blocks a zip code of their own. There is understandably some overlap. All of us will look at the example at https://geojson.org/ and recognize that as a <wpt> without all the xmlns:xsd gunk at the top. You can shoehorn most things between formats because everything is kind of a point or a sequence of points as described on the earth. If you use a hammer that's large enough, you can make a trk represent or the coast of (all the islands of) Hawaii or an area with enclaves or exclaves <https://en.wikipedia.org/wiki/List_of_enclaves_and_exclaves> but it's not really a GPS track. I don't think I've seen time represented in a GeoJSON property for a geometry and it would be really awkward to represent unit timestamps for multiple feature locations in a geometry set. They really are two different formats solving different problems. It's entirely possible that GeoJSON is a superset of GPX's functionality, but I (or someone...) needs to look at the state of the JSON and GeoJSON world just to be sure we at least have the needed concepts covered. RJL --000000000000eb653b059706d7d5
egroups+topografix.com on Thu Dec 19 13:22:32 2019 (link), replying to msg
Hello Robert, I would be interested in discussing a preferred mapping of GPX to GeoJSON. Not as a replacement for GPX, but just to standardize things a bit if people start doing GPX->JSON conversions. p.s. This is the first message to the group after the Yahoo Groups "shutdown" - would appreciate a reply just to see if messages are still being delivered. Sunday, November 10, 2019, 7:02:00 PM, you wrote: > On Sun, Nov 10, 2019 at 5:08 PM yahoo+web.knobby.ws [gpsxml] < > gpsxml+yahoogroups.com> wrote: >> "The handheld GPS market has only one real survivor." Maybe. I wonder how >> many tracks are being generated on smartphones? I assume most of those are >> GPX (at least that's what I see). >> > Fair point. I was thinking of actual dedicated hardware. Phones have > certainly contributed to the downfall of both PNDs and dedicated outdoor > units. In very few cases do I think we're talking about GPX files on the > device themselves. Usually for that kind of app, data is uploaded to some > dedicated service in the cloud and then available for export as GPX or KML > or whatever. >> Is there a movement away from GPX to GeoJSON? >> https://wiki.openstreetmap.org/wiki/GeoJSON >> > As I mentioned, there's certainly some overlap. GeoJSON is more oriented > toward traditional GIS parlance. A GPS (of the variety at the turn of the > century) may generate one or more track segments that is part of a track. > GeoJSON - like the ubiquitous shapefiles are more for describing map > features. This is a polygon for a county outline. The starting and ending > point is the same. This is a multipoygon - it describes two distinctive > areas that comprise a zip code and has a "hole" in it because the center of > that zip code is so dense that the post office gave those nine blocks a zip > code of their own. > There is understandably some overlap. All of us will look at the example at > https://geojson.org/ and recognize that as a <wpt> without all > the xmlns:xsd gunk at the top. You can shoehorn most things between formats > because everything is kind of a point or a sequence of points as described > on the earth. If you use a hammer that's large enough, you can make a trk > represent or the coast of (all the islands of) Hawaii or an area with enclaves > or exclaves > <https://en.wikipedia.org/wiki/List_of_enclaves_and_exclaves> > but it's not really a GPS track. I don't think I've seen time represented > in a GeoJSON property for a geometry and it would be really awkward to > represent unit timestamps for multiple feature locations in a geometry set. > They really are two different formats solving different problems. It's > entirely possible that GeoJSON is a superset of GPX's functionality, but I > (or someone...) needs to look at the state of the JSON and GeoJSON world > just to be sure we at least have the needed concepts covered. > RJL -- Dan Foster