Hi,

First, an introduction, from the docs:

SVO: What's that?
It's an archive system for heterogenous-non-standarized astronomical images made simple! It's aim is to be simple, but flexible.
What SVO stands for?
SVO is the acronym for Simple Virtual Observatory.
What is its purpose?
Having a simple astronomical images archive system with a nice interface.
What features does it has?
Configurable
It's fully configurable to meet your needs. You decide which fields refer to which attributes, where to store the data, where the data come from, where is the database, where to store the log info, etc.
Pluggable
You can write plugins to filter the FITS files, so that you can handle heterogenous FITS files very easily, or get the information for an attribute from where you wish.
Platform independent
It's thought to be platform independent, but there could be issues, must be tested on more platforms, and do some fixes if needed.
Supports multiple DB backends
It's DBMS independent, so you can choose which DBMS fits best to your needs. There is provided some schemas for different DBMS, take a look at the schemas directory.
Storage media backup scheduling
A scheduling facility is included, so you can write your own backup program to store your data offline.
Includes a general data adquisition program
There is a general data adquisition program for the archive, all you need to do is change the configuration, things like: where the data will be stored, where you put the new files to be included, where is the DB, etc...
Includes a program for mastering to a jukebox
This program is thought to be used with the RImage series jukeboxes, and the way they get/write data. If you don't have a jukebox from RImage, nothing matter, all the essential stuff you need is provided, so you can do something that fit your requirements very easily.
Webapp for searching and editing
A general webapp will be provided to interact with the SVO, fully customizable, and in a near future also webservices to talk with other VOs.

It could be seen as a toolkit or API to develop an image archive system, but on the same time it's a final solution (apps provided), that can be easily extended to fit particular needs (doing more apps using the API).

This is a project I was doing the last months in my spare time, I'm thinking on releasing it (CPAN? - Small project webpage with Trac?) so that other people can use it, test it, and improve it (hope).

At this time I had no time to start to write the web app., I have an idea how it should be... also with RPC calls between different SVO systems. I want also to add a wrapper to support the UCD format in use by other Virtual Observatories projects.

The target users of this would be small telescopes that don't have the time + money to implement one. Development groups of new instruments that need an archive system to analyze the data produced. Amateur astronomers who want to have a local archive and webinterface to it. Etc...

It would be cool if there would be a little community around, to improve the system (design, coding, etc) and extend it. And of course it's not neccesary to be an astronomer, I'm not one ;-)

What I mean, is that it would be cool if people contribute to the code (programmer), people to the requirements (astronomer, programmer), people with experience in user interfaces and usability (web designer, programmer), documentation (anybody). There is place for everybody!.

What do you think about?

Willing to contribute?

Regards,

fmerges at irc.freenode.net

Replies are listed 'Best First'.
Re: SVO - Simple Virtual Observatory
by jhourcle (Prior) on Sep 13, 2006 at 18:44 UTC

    I think I have the majority of the code that you'd need to set up a virtual observatory.

    I'm working with some others on the Virtual Solar Observatory, and so far, all of our central architecture is Perl, as it was a common language between all of the project's programmers.

    Our architecture uses the following components:

    Registry
    Contains information about all of the data providers in the system
    Core
    Acts as a 'switchboard', takes requests and sends them to the necessary data providers, and then assembles the responses from them.
    Data Provider
    Takes the given request, talks to a given archive (database, ftp server, etc.), and determines what observations may be of interest, and returns metadata about those observations.
    User Interface
    Anything that knows how to talk to the Core -- we currently have a few other VOs talking to us, a command line perl interface, a couple web-based interfaces, a command line IDL interface, etc.

    I've been meaning to clean up the documentation and put everything into CPAN, but there hasn't been interest for it, other than as we get in new Data Providers (and they only need a small subset) who have to install the packages and deal with dependancies (SOAP::Lite, etc.)

    (Some of our current work is in making the system more generic, to allow us to easily add new query / returned parameters, but it'd also allow you to replace all of the parameters with ones that were relevent for your field).

[reply]

      Hi,

      Cool I don't knew about this VSO

      I have a system running that at the time has processed more than 130000 images without problems, also dumped data to DVD media. I'm refactoring and improving stuff but the "core" is working without problems, but, it's time to write the User Interface... ;-)

      Update: 145474 on 2006-10-17 :-)

      A year ago or so, I bought a domain: optecon.org. I wanted to create a collab. website for different projects related to astronomy and software, for this the name: OPenTElescopeCONtrol. I think it's time to refresh that idea and make it a reality.

      Regards,

      fmerges at irc.freenode.net
[reply]
Re: SVO - Simple Virtual Observatory
by andyford (Curate) on Sep 13, 2006 at 15:57 UTC
    What similar or partial systems are already out there?

    andyford
    or non-Perl: Andy Ford

[reply]

      Hi,

      I don't found nothing like this, because:

      Normally all telescopes have some kind of archive system, could be from a workstation with a big hard drive to a archive system on an cluster with a db and tied to a telescope control system. But the solutions made are normally close related to a telescope and the instruments installed.

      On the other side, the FITS images contain metadata (header) about the image and telemetry information from the telescope and the instrument used for this image and there is no standarization, because they are plain text fields and values. You can even find images from the same telescope with different keywords for the same attribute because the development of the instruments were done by different groups.

      So there're not standard solutions out there (as far as I know).

      The difference with other systems, is that this is not tied to any telescope or set of instruments, so that it can handle images from different instruments as also different telescopes in one single archive.

      Regards,

      fmerges at irc.freenode.net
[reply]

Back to Meditations