Default skeleton attributes cannot be turned off and interfere with manual attributes

[ceesem]

Skeletons have two default attribute values that are hard-coded: radius and vertex_types. If you initialize a skeleton with either of those values set to None, these attributes are created and set to default values. However, if you then try to add an attribute with the same name, for example radius, through add_vertex_attributes it will silently fail because of

osteoid/osteoid/skeleton.py

Line 152 in 2669671

if not hasattr(self, name):

This is causing a problem where we are trying to write generic code to add attributes to skeleton files. Our code had previously started with a skeleton with vertices and edges but no attributes, then adds attributes from a dictionary via add_vertex_attributes. In this case, one of the attributes happened to be called "radius". This radius data then failed to be added, even though the existing data was null and we had not intended to create this attribute previously. This creates a situation where it is awkward to use "radius" (or "vertex_types") in any situation other than where you are using exactly default attributes.

I guess one potential solution could be to include a default_attributes boolean parameter that could turn off these values for full control, but it seems more natural to simply not generate properties that are not asked for explicitly in such low-level code.

As an aside, the parameter name radii is a bit funky considering the attribute gets called radius.

[william-silversmith]

Makes sense. This originally was designed to match precomputed extremely closely, and maybe I'm mistaken, but at the time skeletons didn't have info files so there were standard attributes and info attributes were added later.

It would be good to clean this behavior up... just worried about breaking existing code. "radii" came from wanting all extra attributes to be pluralized for consistency, but that was a misstep.

[ceesem]

Yeah, it's sort of frustrating that there's no API versioning for neuroglancer. It often feels like chasing a moving target with no clear way to validate that a feature is going to be available.

[ceesem]

I can see two options that seem like they would be non-interfering, but I'm sure that's not everything:

1. Allow the user to opt-in to not using default attributes on object creation.
2. Delay the creation of the default attributes until the call to_precomputed() if no other attributes were added.

All things considered, I think the first option is the cleanest for a transition. It may be a bit clunky, but makes the new behavior purely opt-in. It would also allow you to introduce an appropriate deprecation warning for when you decide to change things.

[william-silversmith]

Yea, Option 1 is less likely to break things.

[william-silversmith]

Ah yes, I think the driving force for these standard extra attributes is the SWC format. SWCs require a radius and vertex type field.

https://web.archive.org/web/20180423163403/http://research.mssm.edu/cnic/swc.html