This is defined in the readme as "longitude of periastron", but is apparently being used to represent the angle ω, which is the argument of periastron. The longitude of periastron is represented by ϖ and is related to the argument of periastron by ϖ=ω+Ω, where Ω is the longitude of the ascending node. The longitude of periastron has the advantage that it is not affected by the degeneracy in orientation of a visual binary when radial information is unknown. By contrast, RV, timing and transit detections are insensitive to Ω, so it is impossible for them to find a value for the longitude of periastron, though they can determine ω. I would therefore suggest that the README should be amended to state that this tag corresponds to the argument of periastron.
Secondly, there are two conventions for the argument of periastron: spectroscopic binaries (including RV exoplanets) typically give the value for the primary (reflex) orbit, while visual binaries typically use the value for the secondary. The latter is relevant for stellar orbits of exoplanet host binaries/multiple systems, and also for directly-imaged exoplanets, e.g. the orbits given for Fomalhaut b in Kalas et al. (2013 and Beust et al. (2014). Also Goździewski & Migaszewski (2014) give orbital solutions for HR 8799 that use the visual binary convention (note that the orbital solutions in that paper quote the longitude of periastron ϖ not the argument of periastron ω).
Given the second point, either the README should state that periastron always refers to the primary (reflex) orbit or it would be useful to add a component attribute to specify whether the primary or secondary orbit is being used. My personal preference is to do the latter because it would make adding visual binary orbits somewhat easier, and it should not be too difficult to do a bulk update of the existing values.
Some issues with the
<periastron>
tag:This is defined in the readme as "longitude of periastron", but is apparently being used to represent the angle ω, which is the argument of periastron. The longitude of periastron is represented by ϖ and is related to the argument of periastron by ϖ=ω+Ω, where Ω is the longitude of the ascending node. The longitude of periastron has the advantage that it is not affected by the degeneracy in orientation of a visual binary when radial information is unknown. By contrast, RV, timing and transit detections are insensitive to Ω, so it is impossible for them to find a value for the longitude of periastron, though they can determine ω. I would therefore suggest that the README should be amended to state that this tag corresponds to the argument of periastron.
Secondly, there are two conventions for the argument of periastron: spectroscopic binaries (including RV exoplanets) typically give the value for the primary (reflex) orbit, while visual binaries typically use the value for the secondary. The latter is relevant for stellar orbits of exoplanet host binaries/multiple systems, and also for directly-imaged exoplanets, e.g. the orbits given for Fomalhaut b in Kalas et al. (2013 and Beust et al. (2014). Also Goździewski & Migaszewski (2014) give orbital solutions for HR 8799 that use the visual binary convention (note that the orbital solutions in that paper quote the longitude of periastron ϖ not the argument of periastron ω).
Given the second point, either the README should state that periastron always refers to the primary (reflex) orbit or it would be useful to add a
component
attribute to specify whether the primary or secondary orbit is being used. My personal preference is to do the latter because it would make adding visual binary orbits somewhat easier, and it should not be too difficult to do a bulk update of the existing values.