Unified Data Format for new object model

[bdm]

Slightly off-thread, but I want to share some details of how I've been able to extend the Celestia ssc format to include data that is currently not included with Celestia. Here is a sample:

Code: Select all

"Proxima 1" "Proxima"
{
    #$Info "This world is home to the scientific outpost of Proxima Base."
    #$Info "This outpost is dedicated to astronomical research and is located on the night side of this world."
    #$Density 3.695
    #$AxialTilt 0.011607
    #$Pressure 0.0
    Texture "proxima1.*"
    Radius     1949.60
...etc...
}


In the above sample, #$Info is a description (can occur more than once), #$Density is the density of the body in g/cm3, #$AxialTilt is the axial tilt in degrees, and #$Pressure is the atmospheric pressure in bars (zero here).

The relevance here is that I use a database to manage some of my addons, and these extensions to the ssc format help to provide information that cannot be represented in the ssc format. I have a php script that reads ssc files and imports the information into a database, and the extended fields are used for information that needs to be in the database but that cannot be represented using the ssc format.

Celestia handles these extra fields properly because it interprets them as comments. On the other hand, the php script can understand these fields and handles them correctly.

[RocketMan@JSC]

Here's my impressions after reading the whole thread.

I think the concept is good and as long as the guid and numerical relationship values are kept internal, then all is ok. I especially like the extensiblity of the data formats. XML is good, well known, and many tools exist for using it. I too don't like the way it looks but it is human readable.

IMHO the best way to manage the addons is thru a GUI interface that maintains a local database of relationships. People can then create or download addons, import thru a GUI, and not have to make sure the guid numbers are exactly the same. The distribution can be supplied with a default database. Then the addons could be stored in something like the extras dir. Even the data in the addons could be managed and edited thru a GUI.

I'm also big fan of using existing data formats when at all possible--as long as they are good and do the job correctly. That's why I advocate using the JPL spice formats for ephermis data of spacecraft. This toolkit also has many other features that could be used for all sorts of things: frame conversions, time conversions, planet relative calcs, the list goes on and on.

I don't like not being able to import objects or trajectory data after startup. A GUI interface and some coding could solve that. Unfortunately we are dragging aroung 3 or 4 interfaces so the job is compounded.

I also think the developers should be looking to minimize reconfiguration as much as possible. Perhaps it would be possible to use SWIG to generate the Lua bindings and then use wxLua to generate the GUI components. I'm doing the same thing with Python and wxPython to automatically reconfigure interfaces to C++. I'd also look at dropping one or two front-ends, heck maybe even go for one if possible. SWIG could also be used to generate Lua bindings to the SPICE tool kit--not a bad idea.

Oh and BTW Paolo, your English is excellent.

Best Regards,

Scott

[Paolo]

In the last period I was making some experimentations with some kind of object persistency systems for simple Object databases. The objects that are encapsulating the data are saved and loaded from text file similar to css. The record IDs or keys used for relationships are strings. In memory those objects are STL maps of records (std::map<std::string, object*>). By now the system is a prototype but it is already possible to execute simple queries. The performance are quite good indeed. So i think that one of the first issues of this thread can be changed. For the GUIDS instead than complex bynary formats, strings should be conveniently used perhaps simpilfiyng the problem of the assignment and of the human readability.

Don't know. I still have some doubts.

Kind regards