Re: [gpsxml] Draft of proposed GPX 1.1 extensions
- 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':
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.
- --- In email@example.com, Robert Lipe <robertlipe@...> wrote:
> There's a large overlap, for sure. I didn't start with the GarminThe schemas I offered are our newest extension schemas and they don't have the Garmin-proprietary hex stuff you are remembering.
> 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. YouEvery 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.
> 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.
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. ;-)