I think that what Ted is proposing could be one of the greatest things that ever happened to this pursuit of ours. In essence, we are talking about Project Moonwatch redux, with fifty years of sensing, computing, telecommunications and robotics advances to leverage in dramatically reducing the costs and increasing the capabilities of such a system. > > There was a burst of software development in the mid to late 1980's, as > reasonably powerful PCs became affordable for home use, but we > have not fully > exploited the enormous power of present day PCs. > One thing that stands in the way of moving this proposal forward is the lack of open source implementations of orbit determination and observation reduction software for individuals to learn from, modify and enhance. We are largely dependent on the handful of excellent but black-box programs in common use by the community today. Losing OIG is one thing, but imagine the impact if the implementers we have took their programs offline for whatever reasons, like Dave Cappellucci did several years ago. To get started in this area, one has to engineer an implementation from scratch using resources like the algorithms in Escobar and similar print resources, or reverse-engineer the Fortran code from the Spacewatch technical report. Not a good basis on which to mount a call to arms of this nature. This community has a globally recognized commitment to the responsible but free and open dissemination of data in the form of orbital elements. For Ted's project to get off the ground, I believe the same stance must be taken towards the code that uses and produces the data. One or more existing implementations could presumably be contributed to a code repository to act as gold standards, and the work of reengineering these into the system Ted envisions could begin with a group of contributors potentially an order of magnitude larger than the core of experts that we rely on today. Further, our community needs an online resource that provides a framework for informing a new generation of developers about the many subtle issues involved in implementing this class of application in languages more suited to collaborative development and Web-based deployment. The tools to do this are in hand and in common use today: weblogs and Wikis for requirements and design discussions, source control repositories such as Sourgeforge for code management and dissemination, etc. This class of collaborative software also provides the communication framework for the massively distributed, loosely coupled observational effort being proposed. Another issue that is less serious but an impediment nonetheless to moving development in this area forward is the collection of data interchange formats in common use. TLEs date from the punched card era; the various observational reporting formats in use by the community have similarly compressed and brittle syntax. In an online environment where standards such as RSS and Atom are being rapidly deployed and evolved by small groups of dedicated specialists, we can do much better at representing this data in a humanly-readable, far more parsable fashion using an XML format. Backwards compatibility with the existing formats need not be sacrificed. There's a lot more to be discussed. I wonder if a more appropriate venue might be the rarely-utilized Satobs-SW list, whose time perhaps has now arrived. - BPA ----------------------------------------------------------------- To unsubscribe from SeeSat-L, send a message with 'unsubscribe' in the SUBJECT to SeeSat-L-request@satobs.org List archived at http://www.satobs.org/seesat/seesatindex.html
This archive was generated by hypermail 2b29 : Sat Dec 20 2003 - 13:03:10 EST