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.
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. This would presumably mean that they should be measured 'per second'
or even an average number of seconds taken for one cycle, depending on how
strict you are about your units. So the question someone raised upthread about
the units to use has no obvious answer.
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.
Simon.
> 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
> 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
On 4 Jan 2010, at 5:11pm, Anthony Cartmell wrote:
> 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...
I do. I started thinking in kiloseconds a millicentury ago.
> So cycles-per-minute would seem to be an acceptable SI unit of measurement
> of speed, as is kilometres-per-hour.
Well, that's good. Okay, if we accept that, then we have at least four
different things that can be measured in cycles per minute. So how do we encode
them ? It seems a waste to define four specific tags. Should we instead have
some sort of 'rate' or 'exercise' tag with an attribute ?
Simon.
As a semi-pro photographer, I would like to voice my support for placing
photography related GPS information in the GPX file. I note that the Garmin
Oregon 550t software in its latest incarnation provides such information both in
the EXIF information in the JPEG image and in the GPX file as a Waypoint. I find
that to be quite convenient to know that at a certain Waypoint a photograph was
captured.
Extending this notion to video clips would be especially useful as there is no
current widely accepted way to attach such information to video clips.
For the early adopters of the Garmin Oregon 550t on this list, I would note that
early versions of the Garmin software did not produce "normalized" GPS
coordinates in the EXIF. The GPX encoded Waypoints were properly normalized.
Early adopters of the GO550t using both Windows and Mac OS X complained that OS
vendor supplied software did not show photo locations in their proper position
on Google and other mapping software. The waypoint did however show up
correctly.
--
Wally Wedel
On Mon, Jan 4, 2010 at 7:51 AM, 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)
>
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]
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
I would certainly vote for inclusion of the camera orientation. eg. the photo
was taken at these coordinates facing NNW and pointing up (+) or down (-) so
many degrees. An increasing number of applications use this type of
information. (Automatic geo labeling, photogrammetry..)
Andy Black
On Mon, Jan 4, 2010 at 12:41 PM, Dan Foster <egroups@...> 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]
On 4 Jan 2010, at 6:13pm, Robert Lipe wrote:
> 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.
The Nike iPod thing records paces with places. I know two people who hacked
together pedal-speed loggers. If we made it easy I bet any number of cycle
makers would produce equipment that logged that information. I don't know any
boaters who have done it but I bet they would use the facilities if we provided
them. I think the problem is not so much to provide that specific thing, but to
make the format flexible enough that it can be included without having to define
an extension to the extension.
On 4 Jan 2010, at 6:40pm, Andy Black wrote:
> I would certainly vote for inclusion of the camera orientation. eg. the photo
was taken at these coordinates facing NNW and pointing up (+) or down (-) so
many degrees. An increasing number of applications use this type of
information. (Automatic geo labeling, photogrammetry..)
Yes, we need both direction and tilt. These are two things I think vital in any
revision to GPX.
Simon.
--- 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
--- 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
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").
--
http://www.linkedin.com/in/paultomblinhttp://careers.stackoverflow.com/ptomblin
--- 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."
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
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
On Tue, Jan 12, 2010 at 11:54 AM, azbithead <azbithead@...> 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]
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 ?
Simon.
On Tue, Jan 12, 2010 at 12:33 PM, Simon Slavin
<slavins@...>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]
--- 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
--- 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
On Tue, Jan 12, 2010 at 2:16 PM, azbithead <azbithead@...> 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]
Sorry to chip in late.
I am a newby to the group but I am a frequent user of the standard - very
helpful.
We track boat races with GPS and have a need to automate the collection of
tracks from user GPSes.
Doing a couple by hand is fine, but matching boats with GPS units becomes very
painful as the number of users gets higher.
GPX has everything we require except the originating unique device ID
(manufacturer and model would help too). This is the missing link for
automation.
ALthough Garmin and others provide SDK and APIs to access their devices, it is
costly to develop specific interfaces for each while we already have to decode
the GPX file.
Some questions pop up:
- does the originating device ID need to be added to the improvement you are
working on or can this be already done with the current one?
- if it can be done with the current standard, can you point me to the
properties I need to look for?
Thank you!
- Philippe
-----Original Message-----
From: Robert Lipe <robertlipe@...>
To: gpsxml <gpsxml@yahoogroups.com>
Sent: Tue, Jan 12, 2010 12:02 pm
Subject: Re: [gpsxml] Re: Draft of proposed GPX 1.1 extensions
On Tue, Jan 12, 2010 at 11:54 AM, azbithead <azbithead@...> 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]
[Non-text portions of this message have been removed]
--- 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
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
On Wed, Feb 10, 2010 at 6:44 AM, larry_godin <larry_godin@...> 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]
> 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
On Wed, Feb 10, 2010 at 9:18 AM, larry_godin <larry_godin@...> 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]
On 10 Feb 2010, at 12:44pm, larry_godin wrote:
> 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)...
There is no standardisation of the 'type' tag at all. My recommendation is not
to include it. Some packages use it for internal purposes.
> 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.htmlhttp://home.online.no/~sigurdhu/12MAP_symbols.htm
There is no real standard, but many devices will understand a superset of the
text values seen on those pages.
> 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?
There is no standard way to associate an image with a waypoint. Some packages
have their own way of designating an image, either by including all the image
bits in an encoded form, or by including a URL or filename. But there's no one
standard that all GPX-using software understands. If you are worried
specifically about Google Earth, consult the documentation for Google Earth's
handing of GPX.
Simon.
Send Email
