Support for date and time in target lists
9 views
Skip to first unread message
Prakash Mohan
Jun 21, 2009, 6:37:05 AM6/21/09
to openastr...@googlegroups.com, Akarsh Simha
Hey,
We're implementing the COMAST schema to store user's observation logs
as well as the target lists in KStars.
However I'm stuck with a small problem here :
1. I want to store a time of observation "scheduled time" ( The time
at which the user would like to observe that object
2. I also would like to store a common location and date for a
session. The current implementation of using the "id"s will be
redundant for the target lists
Also, would it be a good idea to add a few more elements to the
observing site like "Conuntry" , "State", "Province" ? This will make it easier
for someone reading the logs to understand the location well, instead of
figuring it out from just the latitude and longitude.
And, how are DST rules handled in OAL?
Regards,
Prakash
--
Prakash
Undergraduate Student
Department of Aerospace Engineering
Indian Institute Of Technology Madras
We're implementing the COMAST schema to store user's observation logs
as well as the target lists in KStars.
However I'm stuck with a small problem here :
1. I want to store a time of observation "scheduled time" ( The time
at which the user would like to observe that object
2. I also would like to store a common location and date for a
session. The current implementation of using the "id"s will be
redundant for the target lists
Also, would it be a good idea to add a few more elements to the
observing site like "Conuntry" , "State", "Province" ? This will make it easier
for someone reading the logs to understand the location well, instead of
figuring it out from just the latitude and longitude.
And, how are DST rules handled in OAL?
Regards,
Prakash
--
Prakash
Undergraduate Student
Department of Aerospace Engineering
Indian Institute Of Technology Madras
Tom
Jun 22, 2009, 4:15:36 AM6/22/09
to openastronomylog
Hi Prakash,
OAL is intended to be a format for the exchange of observations.
Your suggestions addresses the task of observation planning. The core
task of observation planning (at least as I undersatnd it) is to
compile a set of objects to observe and find a schedule, taking local
circumstances and personal preferences into account. While my
selection of objects can be very interesting for you, my timetable
hardly will be. A timetable depends on the local horizon, the time you
want to take for every object, and the time you want to begin and/or
end your observations. So I'm pretty sure that handing over "complete"
plans (with times, eyepiece suggestions, finder charts, ...) in the
general case just does not make sense. But a list of interesting
objects will help. I have to decide whether I want to give this or
that object a try, then schedule it (taking personal preferences /
circumstances) into account and make MY plan.
For observation planning, I created my commercial Windows software
called "Eye&Telescope". It has a German *and* English user interface
and documentation, but currently it's not distributed outside of
Europe. You can download a demo (restricted to Messier objects) from
www.eyeandtelescope (go to Download, Demoversion).
I have already thought of persisting an observation plan in XML, but
not for exchange as a primary objective, but for flexible formatting
using XSLT. Because of the effort required, I have discarded this
again. There is HTML export of plans and it works great - so it can
remain as is.
From my standpoint, an XML format for observation plans would have to
be something decoupled from OAL. It could (and should, of course)
reuse our structures as far as possible. But right now, I want to
concentrate on finishing OAL 2.0. We want to launch deepskylog.org
together with some OAL2.0 compatible apps. As all of this is done in
the "free time" of all contributors, I'm not inclined to extend the
scope of OAL to more than observation reports. Planning is a totally
different construction site. If you go deeper into planning, you will
find that there is much more than a scheduled time!
>> 2. I also would like to store a common location and date for a
session. The current implementation of using the "id"s will be
redundant for the target lists
The session references a site and a time interval. IDs are used to
avoid redundancy. You're right: an observation plan refers to a site,
and either you plan for an interval of time when to observe or you
have a scheduled time. But if we stay with logging, not planning, this
discussion is not necessary.
Daylight savings time: we intentionally left this out as there is no
natural definition of daylight savings time. DST is regulated by
national law. Rules can be set up or declined arbitrarily and vary
from cpuntry to country. In Germany there is even on year shortly
after World War 2 where there are no clear records whether the DST
offset used these days was one or two hours! People obviously had more
vital things in mind than DST...
Including DST in the OAL schema would require complete historical
tracking of the rules, at best for every country or province in the
world where DST was, is and will be used. We decided to leave
Pandora's box closed ;-)
Regards,
Tom
OAL is intended to be a format for the exchange of observations.
Your suggestions addresses the task of observation planning. The core
task of observation planning (at least as I undersatnd it) is to
compile a set of objects to observe and find a schedule, taking local
circumstances and personal preferences into account. While my
selection of objects can be very interesting for you, my timetable
hardly will be. A timetable depends on the local horizon, the time you
want to take for every object, and the time you want to begin and/or
end your observations. So I'm pretty sure that handing over "complete"
plans (with times, eyepiece suggestions, finder charts, ...) in the
general case just does not make sense. But a list of interesting
objects will help. I have to decide whether I want to give this or
that object a try, then schedule it (taking personal preferences /
circumstances) into account and make MY plan.
For observation planning, I created my commercial Windows software
called "Eye&Telescope". It has a German *and* English user interface
and documentation, but currently it's not distributed outside of
Europe. You can download a demo (restricted to Messier objects) from
www.eyeandtelescope (go to Download, Demoversion).
I have already thought of persisting an observation plan in XML, but
not for exchange as a primary objective, but for flexible formatting
using XSLT. Because of the effort required, I have discarded this
again. There is HTML export of plans and it works great - so it can
remain as is.
From my standpoint, an XML format for observation plans would have to
be something decoupled from OAL. It could (and should, of course)
reuse our structures as far as possible. But right now, I want to
concentrate on finishing OAL 2.0. We want to launch deepskylog.org
together with some OAL2.0 compatible apps. As all of this is done in
the "free time" of all contributors, I'm not inclined to extend the
scope of OAL to more than observation reports. Planning is a totally
different construction site. If you go deeper into planning, you will
find that there is much more than a scheduled time!
>> 2. I also would like to store a common location and date for a
session. The current implementation of using the "id"s will be
redundant for the target lists
avoid redundancy. You're right: an observation plan refers to a site,
and either you plan for an interval of time when to observe or you
have a scheduled time. But if we stay with logging, not planning, this
discussion is not necessary.
Daylight savings time: we intentionally left this out as there is no
natural definition of daylight savings time. DST is regulated by
national law. Rules can be set up or declined arbitrarily and vary
from cpuntry to country. In Germany there is even on year shortly
after World War 2 where there are no clear records whether the DST
offset used these days was one or two hours! People obviously had more
vital things in mind than DST...
Including DST in the OAL schema would require complete historical
tracking of the rules, at best for every country or province in the
world where DST was, is and will be used. We decided to leave
Pandora's box closed ;-)
Regards,
Tom
Phyllis
Jun 22, 2009, 7:14:08 AM6/22/09
to openastronomylog
Hi Prakash,
I agree with Tom that OAL 2.0 isn't perfectly suited to holding
observing plans. I developed a different schema to hold that type of
information before I realized anyone was storing plans in OAL 2.0. I
think you have identified a few good reasons to go outside OAL 2.0 for
your plan document storage.
@All - Perhaps there should be some wording in the compliance
guidelines that states that OAL 2.0 *can* be used to contain an
observation target list but this use is not necessary for compliance.
Please comment!
- Phyllis
I agree with Tom that OAL 2.0 isn't perfectly suited to holding
observing plans. I developed a different schema to hold that type of
information before I realized anyone was storing plans in OAL 2.0. I
think you have identified a few good reasons to go outside OAL 2.0 for
your plan document storage.
@All - Perhaps there should be some wording in the compliance
guidelines that states that OAL 2.0 *can* be used to contain an
observation target list but this use is not necessary for compliance.
Please comment!
- Phyllis
Prakash Mohan
Jun 22, 2009, 7:25:20 AM6/22/09
to openastr...@googlegroups.com
Thanks a lot Tom for the response, what you say makes sense indeed.
But there might be occasions like a star party where we would want to
exchange the lists, but if OAL was intended for logging and not
planning then I guess we'd provide some compliance with COMAST by
providing functionality for exporting a session list in XML format.
But there might be occasions like a star party where we would want to
exchange the lists, but if OAL was intended for logging and not
planning then I guess we'd provide some compliance with COMAST by
providing functionality for exporting a session list in XML format.
Cheers,
Prakash Mohan
Jun 22, 2009, 7:53:03 AM6/22/09
to openastr...@googlegroups.com
2009/6/22 Phyllis <unsp...@knightware.biz>:
>
> Hi Prakash,
>
> I agree with Tom that OAL 2.0 isn't perfectly suited to holding
> observing plans. I developed a different schema to hold that type of
> information before I realized anyone was storing plans in OAL 2.0. I
> think you have identified a few good reasons to go outside OAL 2.0 for
> your plan document storage.
>
> Hi Prakash,
>
> I agree with Tom that OAL 2.0 isn't perfectly suited to holding
> observing plans. I developed a different schema to hold that type of
> information before I realized anyone was storing plans in OAL 2.0. I
> think you have identified a few good reasons to go outside OAL 2.0 for
> your plan document storage.
Yes Phyllis, I guess we'll support dual forms of logs, one in the
native KStars format, the other to open a view the logs stored in
compilance with the OAL 2.0
> @All - Perhaps there should be some wording in the compliance
> guidelines that states that OAL 2.0 *can* be used to contain an
> observation target list but this use is not necessary for compliance.
>
> Please comment!
Yeah, that would be better. This will make it easier for us to store
dual formats of logs and plans.
Cheers,
Tom
Jun 22, 2009, 10:17:31 AM6/22/09
to openastronomylog
Hi Prakash, hi all
> But there might be occasions like a star party where we would want to
> exchange the lists, but if OAL was intended for logging and not
> planning then I guess we'd provide some compliance with COMAST by
> providing functionality for exporting a session list in XML format.
>
I think that it is a very useful feature if an application is able to
export objects held in a list or rendered on a map in an XML "target
list style" format. This makes it possible to give away object lists
to other applications for import. If you only export name lists, the
receiving application might fail to retrieve the object's data from
its own data storage. But the XML "target list" allows for
transporting type, position and other data. This information can then
be stored for later use.
I came across this point as users of "Eye&Telescope" began to exchange
the app's observing list files. To avoid redundancy, these files do
not contain the objetcs' data, they just reference the objects using
the database's primary key. This means that such a file is only valid
for your own installation. To overcome this, you can export/import in
XML and all information is conveyed properly.
@Phyllis: good point, we really should document this.
Regards,
Tom
> But there might be occasions like a star party where we would want to
> exchange the lists, but if OAL was intended for logging and not
> planning then I guess we'd provide some compliance with COMAST by
> providing functionality for exporting a session list in XML format.
>
export objects held in a list or rendered on a map in an XML "target
list style" format. This makes it possible to give away object lists
to other applications for import. If you only export name lists, the
receiving application might fail to retrieve the object's data from
its own data storage. But the XML "target list" allows for
transporting type, position and other data. This information can then
be stored for later use.
I came across this point as users of "Eye&Telescope" began to exchange
the app's observing list files. To avoid redundancy, these files do
not contain the objetcs' data, they just reference the objects using
the database's primary key. This means that such a file is only valid
for your own installation. To overcome this, you can export/import in
XML and all information is conveyed properly.
@Phyllis: good point, we really should document this.
Regards,
Tom
Akarsh Simha
Jun 22, 2009, 11:31:26 AM6/22/09
to openastr...@googlegroups.com
Hi
I'm an XML newbie. Wanted to know if we could add something like a
<time></time> within the <target> container in an observing plan file
written by KStars, without affecting how other software would read it
(i.e. they should skip the <time> tag without reading it).
Will such software-specific extensions hamper compatibility?
Regards
Akarsh
Tom
Jun 22, 2009, 12:55:54 PM6/22/09
to openastronomylog
Hi Akarsh,
no, you might not add something inside the <target> if it is not
allowed by the schema.
Background: our XML Schema is a "grammar definition" for what must be
(mandatory) or can be (optional) inside a valid OAL XML file. If there
are optional elements, the schema expresses this with a minOccurs=0
statement. So if there was a <time> element not declared in the
schema, the parser would complain about it.
But apart from this, the time you plan a target to be observed does
not belong to a target. It should go into a (new!) structure in your
schema used to express an intended observation. What belongs to this?
Well, at least the target (reference), the time, maybe the site, maybe
optics to be used. This all depends on *what* you want to convey with
an XML based observation list/plan/schedule. In other words: it only
depends on your needs!
So you could invent an "intended observation" (instead of our
conducted observations covered by OAL), packing together everything
that's relevant for planning. If KStars could export this information,
you could also have an XSL transform to convert this into an OAL
"target list" by just leaving out what is not known in the OAL schema.
Best wishes,
Tom
no, you might not add something inside the <target> if it is not
allowed by the schema.
Background: our XML Schema is a "grammar definition" for what must be
(mandatory) or can be (optional) inside a valid OAL XML file. If there
are optional elements, the schema expresses this with a minOccurs=0
statement. So if there was a <time> element not declared in the
schema, the parser would complain about it.
But apart from this, the time you plan a target to be observed does
not belong to a target. It should go into a (new!) structure in your
schema used to express an intended observation. What belongs to this?
Well, at least the target (reference), the time, maybe the site, maybe
optics to be used. This all depends on *what* you want to convey with
an XML based observation list/plan/schedule. In other words: it only
depends on your needs!
So you could invent an "intended observation" (instead of our
conducted observations covered by OAL), packing together everything
that's relevant for planning. If KStars could export this information,
you could also have an XSL transform to convert this into an OAL
"target list" by just leaving out what is not known in the OAL schema.
Best wishes,
Tom
Akarsh Simha
Jun 23, 2009, 10:46:55 AM6/23/09
to openastr...@googlegroups.com, Prakash Mohan
> Hi Akarsh,
>
> no, you might not add something inside the <target> if it is not
> allowed by the schema.
>
> Background: our XML Schema is a "grammar definition" for what must be
> (mandatory) or can be (optional) inside a valid OAL XML file. If there
> are optional elements, the schema expresses this with a minOccurs=0
> statement. So if there was a <time> element not declared in the
> schema, the parser would complain about it.
>
> no, you might not add something inside the <target> if it is not
> allowed by the schema.
>
> Background: our XML Schema is a "grammar definition" for what must be
> (mandatory) or can be (optional) inside a valid OAL XML file. If there
> are optional elements, the schema expresses this with a minOccurs=0
> statement. So if there was a <time> element not declared in the
> schema, the parser would complain about it.
Okay, thanks! That clarifies.
> But apart from this, the time you plan a target to be observed does
> not belong to a target. It should go into a (new!) structure in your
> schema used to express an intended observation. What belongs to this?
> Well, at least the target (reference), the time, maybe the site, maybe
> optics to be used. This all depends on *what* you want to convey with
> an XML based observation list/plan/schedule. In other words: it only
> depends on your needs!
>
> So you could invent an "intended observation" (instead of our
> conducted observations covered by OAL), packing together everything
> that's relevant for planning. If KStars could export this information,
> you could also have an XSL transform to convert this into an OAL
> "target list" by just leaving out what is not known in the OAL schema.
Hmm... that sounds good. Thanks!
Regards
Akarsh
Reply all
Reply to author
Forward
0 new messages