Do you mind to add the Python binding ? or if you dont' have time just open an issue.

Just some small nits, but LGTM

Has the issue with COM being different from the geometric center been addressed?

Not sure, @scpeters any particular thoughts?

apologies, I was working on it and then decided I wanted to implement gz sdf --print --expand-auto-inertials in #1422 instead of manually computing a bunch of inertial values

I see two options for defining the origin of the cone shape for purposes of object placement in SDFormat (a different origin may be assumed in other parts of our API, but this is just focusing on SDFormat):

1. Shape origin at the center of the cone's bounding box (or bounding cylinder). In this case, placing a cone with length L with base down on a ground plane at Z=0 can be done by setting the initial Z pose of the cone to L/2. This would allow the cone to be placed in the same way as a cylinder. (Example world file placing multiple unit shapes with the same initial Z poses in scpeters@3ad5655).

2. Shape origin at the centroid of a cone with uniform density. For a uniform-density cone with length L, the centroid is L/4 above the base, or L/4 towards the base from the center of the bounding cylinder.

I prefer option 1 for the following reasons:

• I think option 1 is more intuitive for placing geometry since it allows similar placement of a cone and cylinder with the same poses (it will place the base of a cone in the same location as a cylinder base).

• While option 2 does not require specifying an //inertial/pose value when the code has uniform density, I think is not worth the trade-off for making geometry placement less intuitive by not following the pattern used by the cylinder, the most similar shape to a cone. This has little value for static shapes (which have no inertial properties) and for objects with non-uniform density (which will need the //inertial/pose to be specified anyway).

sorry I missed updating one test