Export Regions as JSON

[ks07]

Need to be able to save the highlighted regions using the API, and then load them back into the annotator at a later visit.

[lavelle]

Proposed format:

"annotations" {
  "wings": {
    "shapes": [
      {
        "type": "rect",
        "pos": {
          "x": 123,
          "y": 456
        },
        "size": {
          "height": 321,
          "width:": 999
        }
      },
      {
        "type": "poly",
        "points": [
          {
            "x": 1,
            "y": 2,
          },
          {
            "x": 4,
            "y": 5,
          },
          {
            "x": 7,
            "y": 8,
          },
          ...
        ]
      },
      ...
    ]
  },
  "legs": {
    ...
  }
}

[ks07]

Would it not be simpler to make all features be lists of shapes, and remove the shapes property completely? Also, it would make parsing of this data much simpler if polys and rectangles (and other shapes/lines if they were to be added) were simply represented as lists of points, allowing the same code to be reused.

The type parameter would stay, as I imagine that's useful for loading back into the annotator, but is also obviously useful for verifying enough points are provided.

Relating to my comment #21, it's up to you whether a points list should end in the same as the first. Duplicating it that way has the benefit of making a chain of line segments simple to represent coherently. On the other hand, the type parameter would give the same information.

"annotations" {
  "wings": [
    {
      "type": "rect",
      "points": [
        {
          "x": 123,
          "y": 456
        },
        {
          "x": 444,
          "y": 456
        },
        {
          "x": 444,
          "y": 1455
        },
        {
          "x": 123,
          "y": 1455
        }
      ]
    },
    {
      "type": "poly",
      "points": [
        {
          "x": 1,
          "y": 2
        },
        {
          "x": 4,
          "y": 5
        },
        {
          "x": 7,
          "y": 8
        },
          ...
      ]
    },
      ...
  ]
  "legs": [
      ...
  ]
}

[lavelle]

I vote to keep things as they are. It's not much work to implement custom parsing logic, and then if the researcher needs specific properties of a geometric shape like width, radius etc. they don't have to calculate them from the point data.

If we want circles in future it'll be much more efficient to have centreX, centreY, radius than a list of 1000 x,y points defining some polygonal approximation of it.

[sawhney]

well..

"wings": [
    {
      "type": "circle",
      "centre": {
          "x": 1,
          "y": 2
        },
      "radius":3
  }
]

solves that issue..

[lavelle]

Yep, that's what I'm proposing. If we adopted George's solution that wouldn't be possible.

[sawhney]

No I still agree with george in that the "shapes" is a bit redundant. "type" will be sufficient. that way "rec", "poly" and "line" etc are always followed by points while "circle" is followed by "centre" and "radius".

[lavelle]

It's redundant now but it allows us to add additional properties in future. We might need to store other per-feature data, like max/min number of shapes, order of annotation, UUID or anything else.

Bytes aren't exactly expensive, does one extra level of nesting hurt?

[AliShug]

Yeah, I'm with Giles on this. Features will likely need to carry additional information, and using this approach means backwards-compatibility when that sorta thing gets added.