... You mean actually use the X in XML? ;) That sounds like the proper way to do things to me. officially sanctioned extensions to GPX. That way GPX itselfMessage 1 of 16 , Jun 23, 2009View SourcePaul Tomblin wrote:
>You mean actually use the X in XML? ;)
> On Tue, Jun 23, 2009 at 9:16 PM, Simon
> <mailto:slavins%40hearsay.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
That sounds like the proper way to do things to me.
'officially' sanctioned extensions to GPX.
That way GPX itself can be kept small and to the point, and the
extensions can be updated as needed without needing to update GPX itself.
Kind of like how MathML can be updated w/o needing to update XHTML - and
the MathML extension can be used with far more than just XHTML.
I could see the extensions being useful to other formats (IE kml) if
they are kept separate from GPX - which would make life easier when
converting from one xml format to another.
... Yes, that s been exactly the problem so far. :-) ... I m reluctant to turn GPX into the kitchen sink. Ask a runner and a sailor what s important to eachMessage 2 of 16 , Jun 24, 2009View SourceSimon:
> But I want all the features in it I want (direction and tilt) and IYes, that's been exactly the problem so far. :-)
> will deride features I don't care about (heartrate) as obvious bloat.
> I think we should head for a GPX 2.0. Not a big standard, but oneI'm reluctant to turn GPX into the kitchen sink. Ask a runner and a sailor
> 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.
important to each of them and they'll give opposite answers and then declare
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
are common now (direction and tilt, temperature, etc.), and the use of the
tag for domain-specific problems that can be integrated into "blessed" status
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.
> Ok. In such a case, for example, will limit the information that iscontained 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 areI only support a couple hundred models of GPS receivers and a few million
>> 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.
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 someanalysis [ ... ] 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.
... 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 forMessage 3 of 16 , Jun 24, 2009View SourceOn 24 Jun 2009, at 8:41pm, Robert Lipe wrote:
> It seems a pretty natural progression: experimental->one program-This would be great and it's how I always assumed GPX worked, but
> programs->a proposed GPX extension->a holy GPX extension->official
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.
Hello, [maybe it s time to start changing the subject line to better reflect what we re discussing] ... There are two holy GPX extension schemas, gpx_overlayMessage 4 of 16 , Jun 24, 2009View SourceHello,
[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, butThere are two "holy" GPX extension schemas, gpx_overlay and gpx_style.
> 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.
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
- 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
- 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
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:
Are these still the "rules" we want to play by? If not, how should we
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.