Custom features

[JimHokanson]

How are we imagining that custom features that are specified on a per frame basis will be supported? In the spec document we have a reference to "feature_values" and "feature_order". Presumably a custom reader would be able to know that these arrays belong together.

{
  "units":{
      "t":"s", "x":"mm", "y":"mm",
      "speed":"mm/s",
      "curvature":"1/mm",
      "width":"mm",
      "density":"1/mm^2",
      "aggregate number":"1"
  },
  "@OMG": {
      "feature_order":["speed", "curvature", "width"],
      "plate_features":{
        "density":0.035,
        "aggregate number":8
      }
   },
  "data":[
      { "id":1,
        "t":1.3,
        "x":[12.11, 11.87],
        "y":[5.72, 5.01],
        "@OMG":{ "feature_values":[0.34, 1.5, 0.873] }
      }
  ]
}

It is then suggested that units in custom tags are converted, but without understanding of this feature_order/feature_values relationship, knowing how to handle the units seems not feasible.

So at the end of the day, what I'm really saying is that it seems like with this example we're basically leaving everyone to themselves on something that seems really relevant.

I would have thought the following structure would have been more appropriate:

  "data":[
      { "id":1,
        "t":1.3,
        "x":[12.11, 11.87],
        "y":[5.72, 5.01],
        "@OMG":{ "speed":0.34, "curvature":1.5, "width": 0.873}
      }
  ]   

Thoughts?

[Ichoran]

I think this is a very good point. Actually, I think that we should give both kinds of examples! If you have something that has readily understandable units, you should refer to it by name. If you have something weird, using a header plus data array is actually better because it's less likely that people will think they can extract something of value without your software.

For what it's worth, my software does / is going to use the format that you describe. (Mostly with arrays of times per animal and corresponding arrays of values, though, so that mentioning the header names doesn't take too much space.)

[JimHokanson]

@Ichoran Well said. The spec document should be changed appropriately. I think allowing custom formats is great but it seems best to encourage commonality where possible.

Anyone else have any differing thoughts? Any volunteers to change the spec document?

[Ichoran]

Resolved by #102, hopefully

[MichaelCurrie]

I'm going to be bold and close this. Jim feel free to reopen and add more comments if you think more needs to be done.