Observation lists in OAL ?

[Wim De Meester]

Hi all,

I was wondering if there are plans to extend the oal scheme to include observation list? In DeepskyLog, the user has the possibility to make some observations lists (which is in fact a name and a list of objects). I think Eye&Telescope also defines observation lists. This way, we can also exchange our observation lists between different applications.

Cheers,

Wim

--

Wim De Meester

Katholieke Universiteit Leuven

Instituut voor sterrenkunde tel: +32 (0)16 327914

Celestijnenlaan 200 D fax: +32 (0)16 327999

B - 3001 Leuven email: wim.de...@ster.kuleuven.be

Belgium http://www.ster.kuleuven.be/~wim

[Tom]

Hi Wim,

I prefer the term "target list" for a document that contains data of
objects to be observed. An "observation list" describes observations
that have already been made. Based on the element names in our schema,
a "target list" is a document that contains primarily target data.

You can use our schema to convey a target list. In order to be a valid
OAL document, the "containers" for the master data have to be defined,
but they can stay empty. This means that the <observers>, <sites>,
<sessions>, <scopes>, <lenses>, <filters>, <imagers> (have I forgotten
something?) have to be in place. But only the <targets> are populated
with the actual payload <target> elements.

This is just what Eye&Telescope does when exporting a filter result,
observation project/plan or starmap as XML. You can also import an XML
file containing observations to a planning document: only the <target>
elements are used. Only upon import in the logbook the full
information is used.

There are a number of XSLTs to produce "target lists", too.

So I'd prefer to take this approach - no need for a special "target
list" schema. The overhead of using the observation schema is
neglectable.

I'm proceeding with the implementation of OAL 2.0. I hope that I'll be
able to provide sample files in 2.0 format soon.

Best wishes,
Tom

[Wim De Meester]

That's indeed a good solution for target lists. I'll put this on the todo list for the export of 'target lists' in DeepskyLog.

Cheers,

Wim

>

--

[Akarsh Simha]

Hi Tom

Sorry if I missed an earlier mail regarding this, but could you point
me to some examples of target lists?

We're on our way implementing it in KStars, so it would be really
useful to have some examples.

Thanks.

Regards
Akarsh

[Tom]

Hi Akarsh,

A target list is just a valid OAL document that contains no
observations, but only targets. The sites, optics, sessions
(everything normally referenced in an observation) can be omitted,
too.

As our schema defines some key constraints, the "container" elements
like <observers>, <sites>, <sessions>, <scopes>, ... must be present.
Otherwise the parser would find a schema violation.

If you implement a target list import, you parse a "regular" OAL file,
but you only have to process the <target> elements containted in the
<targets> parent element. It is importnat to avoid multiple persistent
storage of the same target when an import is repeated for several
times. This means that you somehow have to find out whether the target
from the import is already stored in the application's database (or
data files). Eye&Telescope uses a SQL database. During import, I build
a SELECT statement with WHERE clauses filled from the contents of the
imported target. This SELECT is then executed to find out whether the
object is already in the app's persistent storage. So a target from
the import can be skipped if it's already here. This makes you safe
for multiple runs of the import.

When importing observations, the import routine has to resolve the
references an observation makes. The idea is (just as with targets) to
find out whether an object is already persisted (= in the app's data
storage) or not. If not, it is stored and the resulting persistent ID
is used instead of the ID from the import file. In Eye&Telescope, a
"translation map" for IDs from the import file to IDs in the database
is built when importing all master data before the actual observations
are processed. When it comes to importing observations, all referneced
objects are already in the database and the "translation map" can be
used to build INSERT statements for observations with valid foreign
keys.

Meanwhile Wim has provided a test installation of deepskylog.org. The
export of observations already works fine. So you can use it to
generate XML files. This are no "target lists", but a "target list
import" had to be able to process them without trouble.

I have cretaed a "pure" target list with Eye&Telescope, just to
illustrate how such a file had to look for if you would also implement
an export in KStars. It's named "OAL20_target_list_sample.xml" and to
be found in the files section.

What's missing is a *converter* that transforms object data from
several sources into a "target list" style OAL file. I hope that we
will find a volunteer to build such a converter one day.

Best wishes,
Tom