What kinds of registries would be useful to have?

[dret]

it might make sense to have registries for various concepts, so that on the one hand consensus can evolve around well-known concepts, whereas on the other hand the format can evolve by allowing new concepts if there is demand and consensus. here's an initial list of ideas:

• activity types (such as run/bike/swim) might be useful. the problem with these is that they often are not very well-defined, and potentially overlapping (bike could be useful, but "road bike" and "mountain bike" might be even more useful for some). maybe have a sub-field for detailed/additional info?
• measurement types might be useful, such as measurements for heart rate, temperature, and various others. once again, setting the scope can be tricky, for example there are datasets out there that have measurements both for water and air temperature.

[dret]

https://github.com/dret/JTT/tree/master/activity-types is a starting point, listing a couple of existing APIs and the various activity types that they support.

[dret]

a third kind of registry might be useful for "aggregate measurements". the "measurement types" proposed above would be individual data points, such as elevation or heart rate. however, for the whole activity, there might be aggregate metadata such as "average heart rate" or "maximum heart rate". these fields probably are sufficiently different to be treated differently from the individual measurement types.

[gfhuertac]

What about driving as an activity? We store the gps tracks of cars and that is not an activity on the lists provided.

[dret]

On Aug 19, 2016, at 08:48, Gonzalo Huerta-Canepa notifications@github.com wrote:

What about driving as an activity? We store the gps tracks of cars and that is not an activity on the lists provided.

the currently provided lists are definitely biased towards wearables and sports/outdoors activities. the main goal would be to be open and extensible, and not so much complete. there are just too many domains to try to cover them all.

[jimmykane]

How about converting to Activity Type instead of Sport?
I am also trying to implement a consistent GPS and not only (since there are activities without GPS) cross-over combining gpx, tcx (more complete/structured format) and .fit.
The domains are not many and google fit tries to address this with stacked up points if I remember correctly.
It would be great for a nice proposal on this containing 'Activity' driven schemas.

[dret]

On 2017-05-15 21:36, Dimitrios Kanellopoulos wrote: How about converting to Activity Type instead of Sport?

converting what to activity type?

I am also trying to implement a consistent GPS and not only (since there are activities without GPS) cross-over combining |gpx|, |tcx| (more complete/structured format) and |.fit|.

it's tough to cover all of these things in their entirety. the current approach definitely has a focus on geolocated data. focusing on pure sports performance data probably would be quite a different focus.

The domains are not many and google fit tries to address this with stacked up points if I remember correctly.

what do you mean by stacked up points?

It would be great for a nice proposal on this containing 'Activity' driven schemas.

if anything, JTT was an attempt to get past the proprietary vocabularies of individual companies, but in the end, of course you suffer the fate of standardization: if you have x vocabularies and dislike that variety, and then you create a new one, you have x+1 and the world will not suddenly start using only your vocabulary. having said that: it would be good to have some community around these activity types, so that people wouldn't need to solve the same problem over and over again. but the space is evolving quickly and frankly, the examples i have collected are a bit dated by now and just updating them already would take a bit of time and effort.

[jimmykane]

having said that: it would be good to have some community around these
activity types, so that people wouldn't need to solve the same problem
over and over again. but the space is evolving quickly and frankly, the
examples i have collected are a bit dated by now and just updating them
already would take a bit of time and effort.

This is the reason I commented. This domain is really hard to model.

converting what to activity type?

Well an activity according to TCX can have a sport. However (playing with words here), sport could have been named type since for example, driving can be both sport and not.

what do you mean by stacked up points?

For example, an activity at second 1 can have geolocation points, health data points and much more.
So it decouples the geolocation with the other data.

[dret]

On 2017-05-17 17:24, Dimitrios Kanellopoulos wrote: having said that: it would be good to have some community around these activity types, so that people wouldn't need to solve the same problem over and over again. but the space is evolving quickly and frankly, the examples i have collected are a bit dated by now and just updating them already would take a bit of time and effort. This is the reason I commented. This domain is really hard to model.

that's the philosophical question: do you want to create a new model, or just (or at least as a starting point) look at how existing models can be aligned? both approaches have their drawbacks. https://github.com/dret/JTT/blob/master/activity-types/overview.md is something i created a while ago and does not even attempt to do either; it simply captures the state of vendor models at that time. https://github.com/dret/JTT/blob/master/data-types/overview.md does something similar but for data associated with activities.

Well an activity according to TCX can have a sport. However (playing with words here), |sport| could have been named |type| since for example, driving can be both sport and not.

yes. TCX and GPX have a little different roots and thus have different designs and capabilities. neither of them is perfect. but at least they are readable and open, which cannot be said of FIT.

For example, an activity at second 1 can have geolocation points, health data points and much more. So it decouples the geolocation with the other data.

well, it couples them, actually, at least for GPX, because GPX first and foremost is a geolocation format. so in GPX you must have geolocation data, which as you say is not really true for all activity/sports data. that's a bit different for TCX, and i am sure FIT has an even different design.

[tobixen]

I'm having other use-case scenarios for position tracking than training.

Here are some measurements I'd like to throw into the feed:

• Relative wind speed and heading.
• Water temperature
• Air temperature
• Tilt
• Sea depth
• speed in the water
• background noise
• photo URLs
• would also like to try to deduct something on the size of the waves based on motion/acceleration/gyroscope sensors.

[tobixen]

Ref the geo URI scheme, "uncertainty of the location in meters" is also something one may want to add to the mix.

The geo URI scheme also have the option to pass a different coordinate reference system - which may seem a bit moot, since WGS-84 is the standard nowadays. The Wikipedia page specifies that this field can be used for non-terrestrial coordinates. A good, future-proof tracking standard should be usable on other bodies except earth :-)

[dret]

On 2021-06-22 10:38, Tobias Brox wrote: I'm having other use-case scenarios for position tracking than training. Here are some measurements I'd like to throw into the feed: * Relative wind speed and heading. * Water temperature * Air temperature * Tilt * Sea depth * speed in the water * background noise * photo URLs * would also like to try to deduct something on the size of the waves based on motion/acceleration/gyroscope sensors.

this is an interesting list. GPX has good extensibility, and if you want to use a supported format where you can throw your own data in, maybe check out GPX. it's XML, but at least it's well-defined and supported in many tools.