From Alberto.Micol at eso.org Wed Nov 15 13:17:29 2006
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 15 Nov 2006 22:17:29 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Dear Miguel,
I found your comparison an incredibly useful and interesting exercise.
I think there should be a specific VO body to thoroughly perform
this kind of investigations and comparison, including applications,
protocol,
data model or registry compliancy, etc. because the lessons that can
be learned
should be considered of paramount importance in the development of
the VO.
But that is already known.
So, let me ask you just a question regarding your point (c.1):
you mention 3 specview requirements, but then only 2 points (i and
ii) are given
(unless you count c1 ii as two requirements, one for x and one for y).
I found any lesson learned so valuable that I prefer to ask what is
maybe obvious.
Was (ii) to be counted twice or (iii) was left in your fingertips?
Thanks,
Alberto
On May 4, 2006, at 14:42, Miguel Cervi?o wrote:
> Dear all,
>
> I just send this comments that may be discussed in the next meeting.
> It is just a comparison about how different VO applications manage
> a SED building following the SED data model requirements.
> [...]
> c) Columns to be plotted:
>
> c.1) specview needs 3 requirements to plot a VOTable:
>
> i.- the Table must have a name (only VOTables with
name="whatever"> looks to work
> ii.- utype in x and y coordinates in FIELD must be specified
>
> c.2) VOSpec needs two (non-standard) lines to
> specify the columns and only
> two columns can be plotted (i.e. do not include for
> example a column with errors that would be
> useful for both observations and theoretical data.
> [...]
> I hope that this comments would help to improve the applications
> and for the theory group
>
> best regards
>
> Miguel Cervi?o
>
>
From Alberto.Micol at eso.org Wed Nov 15 13:17:29 2006
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 15 Nov 2006 22:17:29 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Dear Miguel,
I found your comparison an incredibly useful and interesting exercise.
I think there should be a specific VO body to thoroughly perform
this kind of investigations and comparison, including applications,
protocol,
data model or registry compliancy, etc. because the lessons that can
be learned
should be considered of paramount importance in the development of
the VO.
But that is already known.
So, let me ask you just a question regarding your point (c.1):
you mention 3 specview requirements, but then only 2 points (i and
ii) are given
(unless you count c1 ii as two requirements, one for x and one for y).
I found any lesson learned so valuable that I prefer to ask what is
maybe obvious.
Was (ii) to be counted twice or (iii) was left in your fingertips?
Thanks,
Alberto
On May 4, 2006, at 14:42, Miguel Cervi?o wrote:
> Dear all,
>
> I just send this comments that may be discussed in the next meeting.
> It is just a comparison about how different VO applications manage
> a SED building following the SED data model requirements.
> [...]
> c) Columns to be plotted:
>
> c.1) specview needs 3 requirements to plot a VOTable:
>
> i.- the Table must have a name (only VOTables with name="whatever"> looks to work
> ii.- utype in x and y coordinates in FIELD must be specified
>
> c.2) VOSpec needs two (non-standard) lines to
> specify the columns and only
> two columns can be plotted (i.e. do not include for
> example a column with errors that would be
> useful for both observations and theoretical data.
> [...]
> I hope that this comments would help to improve the applications
> and for the theory group
>
> best regards
>
> Miguel Cervi?o
>
>
From mcs at iaa.es Thu Nov 16 03:19:14 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 16 Nov 2006 12:19:14 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es> <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Message-ID:
Dear Alberto and all,
I just tested with specview (2.12.2) to answer the question by Alberto.
(I didn?t remeber if I had lost something in item (iii)
The answer is about specview:
i) it is needed a "name" in the table tag (or maybe in any other place)
ii) it is needed the utype in X
iii) it is needed the utype in Y
so
> Was (ii) to be counted twice or (iii) was left in your fingertips?
The minimal VOTable it manage is:
.....
Surprisely I had found that specview is not able to manage the
VOTables generated by itself at least in ascii!!
At leats for the table i had donwload (first HTS data from I zw 18),
the VOTable that is obtained when it is saved produce two
elements, and specview only manage the first one with observational
metadata. I had need to load the table in TopCat and save it again
with topcat to obtain a VOTable that spceview reads.
Any case I will try to repeat the exercise again in some weeks ...
cheers
Miguel
From mcs at iaa.es Thu Nov 16 03:19:14 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 16 Nov 2006 12:19:14 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es> <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Message-ID:
Dear Alberto and all,
I just tested with specview (2.12.2) to answer the question by Alberto.
(I didn?t remeber if I had lost something in item (iii)
The answer is about specview:
i) it is needed a "name" in the table tag (or maybe in any other place)
ii) it is needed the utype in X
iii) it is needed the utype in Y
so
> Was (ii) to be counted twice or (iii) was left in your fingertips?
The minimal VOTable it manage is:
.....
Surprisely I had found that specview is not able to manage the
VOTables generated by itself at least in ascii!!
At leats for the table i had donwload (first HTS data from I zw 18),
the VOTable that is obtained when it is saved produce two
elements, and specview only manage the first one with observational
metadata. I had need to load the table in TopCat and save it again
with topcat to obtain a VOTable that spceview reads.
Any case I will try to repeat the exercise again in some weeks ...
cheers
Miguel
From busko at stsci.edu Thu Nov 16 05:35:09 2006
From: busko at stsci.edu (Ivo Busko)
Date: Thu, 16 Nov 2006 08:35:09 -0500
Subject: tehoretical SEDs in VO applications
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es> <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Message-ID: <455C690D.3070501@stsci.edu>
Hi, Miguel and all
As the specview developer, I would like to add my 0.02 cents to the
discussion. In fact, I would like to warn about the use of specview to
generate "valid" VO-compliant files.
The "Save as" and "Save" options write data in xml files (no FITS
support yet) following the standards set by the Spectrum Data Model in
its 0.92 incarnation. But the code is still incomplete as far as
metadata goes. Not all valid metadata described in 0.92 is actually
passed thru and ends up in the output xml file. Other errors and
inconsistencies may exiist as well. My poiny is, don't take specview's
output as a well rounded, finished example of a VO-compliant file. It's
work in progress.
Besides, there were significant developments in the Data Model model
since 0.92, and none of these are implemented in specview yet.
Miguel, could you please provide me with a copy of the HTS data from I
zw 18? I would like to see what is going on. In the examples I have, the
entire file generated by specview is read back, even when multiple
tables are present. And, what exactly do you mean by "at least in
ascii"? Specview supports a simple ascii table format, but that has
nothing to do with the VO xml format.
Cheers,
-Ivo
*********************************************************************
* Ivo C. Busko, PhD e-mail: busko at stsci.edu *
* Senior Systems Software Engineer Voice: (410)338-4472 *
* Astronomy Tools and Applications FAX: (410)338-4767 *
* Engineering and Software Services Division *
* Space Telescope Science Institute http://www.stsci.edu *
* 3700 San Martin Drive *
* Baltimore MD 21218-2410 USA *
*********************************************************************
Miguel Cervi?o wrote:
> Dear Alberto and all,
>
> I just tested with specview (2.12.2) to answer the question by Alberto.
> (I didn?t remeber if I had lost something in item (iii)
> The answer is about specview:
>
> i) it is needed a "name" in the table tag (or maybe in any other place)
> ii) it is needed the utype in X
> iii) it is needed the utype in Y
>
> so
>
>> Was (ii) to be counted twice or (iii) was left in your fingertips?
>
>
> The minimal VOTable it manage is:
>
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.1 http://
> www.ivoa.net/xml/VOTable/v1.1"
> xmlns="http://www.ivoa.net/xml/VOTable/v1.1">
>
>
> utype="sed:Segment.Points.SpectralCoord.Value"/>
> utype="sed:Segment.Points.Flux.Value"/>
>
>
> .....
>
>
> Surprisely I had found that specview is not able to manage the VOTables
> generated by itself at least in ascii!!
> At leats for the table i had donwload (first HTS data from I zw 18),
> the VOTable that is obtained when it is saved produce two
> elements, and specview only manage the first one with observational
> metadata. I had need to load the table in TopCat and save it again with
> topcat to obtain a VOTable that spceview reads.
>
>
> Any case I will try to repeat the exercise again in some weeks ...
>
> cheers
>
> Miguel
>
>
From busko at stsci.edu Thu Nov 16 05:35:09 2006
From: busko at stsci.edu (Ivo Busko)
Date: Thu, 16 Nov 2006 08:35:09 -0500
Subject: tehoretical SEDs in VO applications
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es> <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Message-ID: <455C690D.3070501@stsci.edu>
Hi, Miguel and all
As the specview developer, I would like to add my 0.02 cents to the
discussion. In fact, I would like to warn about the use of specview to
generate "valid" VO-compliant files.
The "Save as" and "Save" options write data in xml files (no FITS
support yet) following the standards set by the Spectrum Data Model in
its 0.92 incarnation. But the code is still incomplete as far as
metadata goes. Not all valid metadata described in 0.92 is actually
passed thru and ends up in the output xml file. Other errors and
inconsistencies may exiist as well. My poiny is, don't take specview's
output as a well rounded, finished example of a VO-compliant file. It's
work in progress.
Besides, there were significant developments in the Data Model model
since 0.92, and none of these are implemented in specview yet.
Miguel, could you please provide me with a copy of the HTS data from I
zw 18? I would like to see what is going on. In the examples I have, the
entire file generated by specview is read back, even when multiple
tables are present. And, what exactly do you mean by "at least in
ascii"? Specview supports a simple ascii table format, but that has
nothing to do with the VO xml format.
Cheers,
-Ivo
*********************************************************************
* Ivo C. Busko, PhD e-mail: busko at stsci.edu *
* Senior Systems Software Engineer Voice: (410)338-4472 *
* Astronomy Tools and Applications FAX: (410)338-4767 *
* Engineering and Software Services Division *
* Space Telescope Science Institute http://www.stsci.edu *
* 3700 San Martin Drive *
* Baltimore MD 21218-2410 USA *
*********************************************************************
Miguel Cervi?o wrote:
> Dear Alberto and all,
>
> I just tested with specview (2.12.2) to answer the question by Alberto.
> (I didn?t remeber if I had lost something in item (iii)
> The answer is about specview:
>
> i) it is needed a "name" in the table tag (or maybe in any other place)
> ii) it is needed the utype in X
> iii) it is needed the utype in Y
>
> so
>
>> Was (ii) to be counted twice or (iii) was left in your fingertips?
>
>
> The minimal VOTable it manage is:
>
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.1 http://
> www.ivoa.net/xml/VOTable/v1.1"
> xmlns="http://www.ivoa.net/xml/VOTable/v1.1">
>
>
> utype="sed:Segment.Points.SpectralCoord.Value"/>
> utype="sed:Segment.Points.Flux.Value"/>
>
>
> .....
>
>
> Surprisely I had found that specview is not able to manage the VOTables
> generated by itself at least in ascii!!
> At leats for the table i had donwload (first HTS data from I zw 18),
> the VOTable that is obtained when it is saved produce two
> elements, and specview only manage the first one with observational
> metadata. I had need to load the table in TopCat and save it again with
> topcat to obtain a VOTable that spceview reads.
>
>
> Any case I will try to repeat the exercise again in some weeks ...
>
> cheers
>
> Miguel
>
>
From busko at stsci.edu Fri Nov 17 07:28:52 2006
From: busko at stsci.edu (Ivo Busko)
Date: Fri, 17 Nov 2006 10:28:52 -0500 (EST)
Subject: tehoretical SEDs in VO applications
Message-ID: <20061117102852.CMI06997@comet.stsci.edu>
Hi Miguel
The ArrayIndexOutOfBoundsException error in specview is
caused by a misspelled attribute in the input VOTable
file. The target position must be specified as two values,
for RA and DEC, and in the file you sent me there is only
one value, like this:
The "value" and "arraysize" attributes are inconsistent, thus
the error.
Now, I don't understand how this is possible, since the FITS
header doesn't have any positional information from where
the TargetPos field could be composed from. I run specview
using FOS data retrieved from the STScI archive, which have
an almost identical FITS header with the 1zw18 header, and
the generated VOTable does not have any TargetPos field, as
it should be.
So I wonder if the original file you used as specview input
is any different from STScI archive files, or if you edited
the file, or something on those lines.
Cheers,
-Ivo
From busko at stsci.edu Fri Nov 17 07:28:52 2006
From: busko at stsci.edu (Ivo Busko)
Date: Fri, 17 Nov 2006 10:28:52 -0500 (EST)
Subject: tehoretical SEDs in VO applications
Message-ID: <20061117102852.CMI06997@comet.stsci.edu>
Hi Miguel
The ArrayIndexOutOfBoundsException error in specview is
caused by a misspelled attribute in the input VOTable
file. The target position must be specified as two values,
for RA and DEC, and in the file you sent me there is only
one value, like this:
The "value" and "arraysize" attributes are inconsistent, thus
the error.
Now, I don't understand how this is possible, since the FITS
header doesn't have any positional information from where
the TargetPos field could be composed from. I run specview
using FOS data retrieved from the STScI archive, which have
an almost identical FITS header with the 1zw18 header, and
the generated VOTable does not have any TargetPos field, as
it should be.
So I wonder if the original file you used as specview input
is any different from STScI archive files, or if you edited
the file, or something on those lines.
Cheers,
-Ivo
From mcs at iaa.es Fri Nov 17 08:27:49 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 17 Nov 2006 17:27:49 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <20061117102852.CMI06997@comet.stsci.edu>
References: <20061117102852.CMI06997@comet.stsci.edu>
Message-ID: <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
uhmm,
I had not modified the file... I just make the proof again ... and I
obtain the same result
I reported.
The procces I use is:
a) resolve I zw 18 coordinates with NED using the form in specview
b) performe the search once the position is resolved
Here is the data of the image I obtain: (it was "HST spectra" in the
app, not "HST/FOS/SSAP")
HST Spectra
YES z0wp0104m MAST.HST.GHRS 143.50845833333 55.240944444444 http://
archive.stsci.edu/pub/vospectra/ghrs/z0wp0104m_vo.fits IZW18 1000
48734.779 48734.721 1992-04-22 17:17:00 1992-04-23 05:06:00 spectrum/
fits FK5 2000.000 G160M n n 1285.330 1321.280 WAVELENGTH FLUX SIGMA
L ML-1T-3 ML-1T-3 1E-10 1E+7 1E+7 ANGSTROMS ERGS/CM^2/S/A ERGS/CM^2/S/
A IZW18
I found 3 possible alternatives:
a) I am running spectview incorectly (I am ussing java -jar
spectview.jar instead the distribution script)
b) The different services that provide the spectra are different or
provide different information in the FITS header, and specview manage
it in a different way:
In case (b) it shoud needed to answer if
1.- it would be an issue related to the application
2.- It would be an issue related with the service... (I can try
to obtain the data from the same server with other applications and
see what happens... but during next week)
Cheers and nice weekend
Miguel
From mcs at iaa.es Fri Nov 17 08:27:49 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 17 Nov 2006 17:27:49 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <20061117102852.CMI06997@comet.stsci.edu>
References: <20061117102852.CMI06997@comet.stsci.edu>
Message-ID: <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
uhmm,
I had not modified the file... I just make the proof again ... and I
obtain the same result
I reported.
The procces I use is:
a) resolve I zw 18 coordinates with NED using the form in specview
b) performe the search once the position is resolved
Here is the data of the image I obtain: (it was "HST spectra" in the
app, not "HST/FOS/SSAP")
HST Spectra
YES z0wp0104m MAST.HST.GHRS 143.50845833333 55.240944444444 http://
archive.stsci.edu/pub/vospectra/ghrs/z0wp0104m_vo.fits IZW18 1000
48734.779 48734.721 1992-04-22 17:17:00 1992-04-23 05:06:00 spectrum/
fits FK5 2000.000 G160M n n 1285.330 1321.280 WAVELENGTH FLUX SIGMA
L ML-1T-3 ML-1T-3 1E-10 1E+7 1E+7 ANGSTROMS ERGS/CM^2/S/A ERGS/CM^2/S/
A IZW18
I found 3 possible alternatives:
a) I am running spectview incorectly (I am ussing java -jar
spectview.jar instead the distribution script)
b) The different services that provide the spectra are different or
provide different information in the FITS header, and specview manage
it in a different way:
In case (b) it shoud needed to answer if
1.- it would be an issue related to the application
2.- It would be an issue related with the service... (I can try
to obtain the data from the same server with other applications and
see what happens... but during next week)
Cheers and nice weekend
Miguel
From mcs at iaa.es Fri Nov 17 09:19:51 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 17 Nov 2006 18:19:51 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
References: <20061117102852.CMI06997@comet.stsci.edu> <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
Message-ID:
sorry,
To avoid misunderstandings:
3 possible alternatives:
a) I am running spectview incorrectly
b) There is a problem in specview (when retrieve from "HST spectra"
or write the VOTable)
c) There is a problem with the service that provide the "HST spectra"
sorry for my typing errors
miguel
> I found 3 possible alternatives:
>
> a) I am running spectview incorectly (I am ussing java -jar
> spectview.jar instead the distribution script)
> b) The different services that provide the spectra are different or
> provide different information in the FITS header, and specview
> manage it in a different way:
>
> In case (b) it shoud needed to answer if
> 1.- it would be an issue related to the application
> 2.- It would be an issue related with the service... (I can try
> to obtain the data from the same server with other applications and
> see what happens... but during next week)
>
>
> Cheers and nice weekend
>
> Miguel
>
From mcs at iaa.es Fri Nov 17 09:19:51 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 17 Nov 2006 18:19:51 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
References: <20061117102852.CMI06997@comet.stsci.edu> <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
Message-ID:
sorry,
To avoid misunderstandings:
3 possible alternatives:
a) I am running spectview incorrectly
b) There is a problem in specview (when retrieve from "HST spectra"
or write the VOTable)
c) There is a problem with the service that provide the "HST spectra"
sorry for my typing errors
miguel
> I found 3 possible alternatives:
>
> a) I am running spectview incorectly (I am ussing java -jar
> spectview.jar instead the distribution script)
> b) The different services that provide the spectra are different or
> provide different information in the FITS header, and specview
> manage it in a different way:
>
> In case (b) it shoud needed to answer if
> 1.- it would be an issue related to the application
> 2.- It would be an issue related with the service... (I can try
> to obtain the data from the same server with other applications and
> see what happens... but during next week)
>
>
> Cheers and nice weekend
>
> Miguel
>
From busko at stsci.edu Fri Nov 17 10:08:46 2006
From: busko at stsci.edu (Ivo Busko)
Date: Fri, 17 Nov 2006 13:08:46 -0500 (EST)
Subject: tehoretical SEDs in VO applications
Message-ID: <20061117130846.CMI15037@comet.stsci.edu>
Hi, Miguel
Ah, you are reading directly from a SSAP service...
OK, so it is a bug in specview after all. A good example
of how the code is not yet propely tested. I fixed this
particular bug, but other bugs are sure to surface sooner
or later.
The bug fix should be available on the next release.
And thanks for providing the test case!
-Ivo
---- Original message ----
>Date: Fri, 17 Nov 2006 18:19:51 +0100
>From: Miguel Cervi?o
>Subject: Re: tehoretical SEDs in VO applications
>To: Miguel Cervi?o
>Cc: busko at stsci.edu, theory at ivoa.net, apps at ivoa.net
>
>sorry,
>
>To avoid misunderstandings:
>
>3 possible alternatives:
>
>a) I am running spectview incorrectly
>b) There is a problem in specview (when retrieve from "HST spectra"
>or write the VOTable)
>c) There is a problem with the service that provide the "HST spectra"
>
>sorry for my typing errors
>
>miguel
>
>> I found 3 possible alternatives:
>>
>> a) I am running spectview incorectly (I am ussing java -jar
>> spectview.jar instead the distribution script)
>> b) The different services that provide the spectra are different or
>> provide different information in the FITS header, and specview
>> manage it in a different way:
>>
>> In case (b) it shoud needed to answer if
>> 1.- it would be an issue related to the application
>> 2.- It would be an issue related with the service... (I can try
>> to obtain the data from the same server with other applications and
>> see what happens... but during next week)
>>
>>
>> Cheers and nice weekend
>>
>> Miguel
>>
>
From busko at stsci.edu Fri Nov 17 10:08:46 2006
From: busko at stsci.edu (Ivo Busko)
Date: Fri, 17 Nov 2006 13:08:46 -0500 (EST)
Subject: tehoretical SEDs in VO applications
Message-ID: <20061117130846.CMI15037@comet.stsci.edu>
Hi, Miguel
Ah, you are reading directly from a SSAP service...
OK, so it is a bug in specview after all. A good example
of how the code is not yet propely tested. I fixed this
particular bug, but other bugs are sure to surface sooner
or later.
The bug fix should be available on the next release.
And thanks for providing the test case!
-Ivo
---- Original message ----
>Date: Fri, 17 Nov 2006 18:19:51 +0100
>From: Miguel Cervi?o
>Subject: Re: tehoretical SEDs in VO applications
>To: Miguel Cervi?o
>Cc: busko at stsci.edu, theory at ivoa.net, apps at ivoa.net
>
>sorry,
>
>To avoid misunderstandings:
>
>3 possible alternatives:
>
>a) I am running spectview incorrectly
>b) There is a problem in specview (when retrieve from "HST spectra"
>or write the VOTable)
>c) There is a problem with the service that provide the "HST spectra"
>
>sorry for my typing errors
>
>miguel
>
>> I found 3 possible alternatives:
>>
>> a) I am running spectview incorectly (I am ussing java -jar
>> spectview.jar instead the distribution script)
>> b) The different services that provide the spectra are different or
>> provide different information in the FITS header, and specview
>> manage it in a different way:
>>
>> In case (b) it shoud needed to answer if
>> 1.- it would be an issue related to the application
>> 2.- It would be an issue related with the service... (I can try
>> to obtain the data from the same server with other applications and
>> see what happens... but during next week)
>>
>>
>> Cheers and nice weekend
>>
>> Miguel
>>
>
From Alberto.Micol at eso.org Wed Nov 15 13:17:29 2006
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 15 Nov 2006 22:17:29 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Dear Miguel,
I found your comparison an incredibly useful and interesting exercise.
I think there should be a specific VO body to thoroughly perform
this kind of investigations and comparison, including applications,
protocol,
data model or registry compliancy, etc. because the lessons that can
be learned
should be considered of paramount importance in the development of
the VO.
But that is already known.
So, let me ask you just a question regarding your point (c.1):
you mention 3 specview requirements, but then only 2 points (i and
ii) are given
(unless you count c1 ii as two requirements, one for x and one for y).
I found any lesson learned so valuable that I prefer to ask what is
maybe obvious.
Was (ii) to be counted twice or (iii) was left in your fingertips?
Thanks,
Alberto
On May 4, 2006, at 14:42, Miguel Cervi?o wrote:
> Dear all,
>
> I just send this comments that may be discussed in the next meeting.
> It is just a comparison about how different VO applications manage
> a SED building following the SED data model requirements.
> [...]
> c) Columns to be plotted:
>
> c.1) specview needs 3 requirements to plot a VOTable:
>
> i.- the Table must have a name (only VOTables with name="whatever"> looks to work
> ii.- utype in x and y coordinates in FIELD must be specified
>
> c.2) VOSpec needs two (non-standard) lines to
> specify the columns and only
> two columns can be plotted (i.e. do not include for
> example a column with errors that would be
> useful for both observations and theoretical data.
> [...]
> I hope that this comments would help to improve the applications
> and for the theory group
>
> best regards
>
> Miguel Cervi?o
>
>
From Alberto.Micol at eso.org Wed Nov 15 13:17:29 2006
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 15 Nov 2006 22:17:29 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es>
Message-ID: <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Dear Miguel,
I found your comparison an incredibly useful and interesting exercise.
I think there should be a specific VO body to thoroughly perform
this kind of investigations and comparison, including applications,
protocol,
data model or registry compliancy, etc. because the lessons that can
be learned
should be considered of paramount importance in the development of
the VO.
But that is already known.
So, let me ask you just a question regarding your point (c.1):
you mention 3 specview requirements, but then only 2 points (i and
ii) are given
(unless you count c1 ii as two requirements, one for x and one for y).
I found any lesson learned so valuable that I prefer to ask what is
maybe obvious.
Was (ii) to be counted twice or (iii) was left in your fingertips?
Thanks,
Alberto
On May 4, 2006, at 14:42, Miguel Cervi?o wrote:
> Dear all,
>
> I just send this comments that may be discussed in the next meeting.
> It is just a comparison about how different VO applications manage
> a SED building following the SED data model requirements.
> [...]
> c) Columns to be plotted:
>
> c.1) specview needs 3 requirements to plot a VOTable:
>
> i.- the Table must have a name (only VOTables with name="whatever"> looks to work
> ii.- utype in x and y coordinates in FIELD must be specified
>
> c.2) VOSpec needs two (non-standard) lines to
> specify the columns and only
> two columns can be plotted (i.e. do not include for
> example a column with errors that would be
> useful for both observations and theoretical data.
> [...]
> I hope that this comments would help to improve the applications
> and for the theory group
>
> best regards
>
> Miguel Cervi?o
>
>
From mcs at iaa.es Thu Nov 16 03:19:14 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 16 Nov 2006 12:19:14 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es> <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Message-ID:
Dear Alberto and all,
I just tested with specview (2.12.2) to answer the question by Alberto.
(I didn?t remeber if I had lost something in item (iii)
The answer is about specview:
i) it is needed a "name" in the table tag (or maybe in any other place)
ii) it is needed the utype in X
iii) it is needed the utype in Y
so
> Was (ii) to be counted twice or (iii) was left in your fingertips?
The minimal VOTable it manage is:
.....
Surprisely I had found that specview is not able to manage the
VOTables generated by itself at least in ascii!!
At leats for the table i had donwload (first HTS data from I zw 18),
the VOTable that is obtained when it is saved produce two
elements, and specview only manage the first one with observational
metadata. I had need to load the table in TopCat and save it again
with topcat to obtain a VOTable that spceview reads.
Any case I will try to repeat the exercise again in some weeks ...
cheers
Miguel
From mcs at iaa.es Thu Nov 16 03:19:14 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 16 Nov 2006 12:19:14 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es> <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Message-ID:
Dear Alberto and all,
I just tested with specview (2.12.2) to answer the question by Alberto.
(I didn?t remeber if I had lost something in item (iii)
The answer is about specview:
i) it is needed a "name" in the table tag (or maybe in any other place)
ii) it is needed the utype in X
iii) it is needed the utype in Y
so
> Was (ii) to be counted twice or (iii) was left in your fingertips?
The minimal VOTable it manage is:
.....
Surprisely I had found that specview is not able to manage the
VOTables generated by itself at least in ascii!!
At leats for the table i had donwload (first HTS data from I zw 18),
the VOTable that is obtained when it is saved produce two
elements, and specview only manage the first one with observational
metadata. I had need to load the table in TopCat and save it again
with topcat to obtain a VOTable that spceview reads.
Any case I will try to repeat the exercise again in some weeks ...
cheers
Miguel
From busko at stsci.edu Thu Nov 16 05:35:09 2006
From: busko at stsci.edu (Ivo Busko)
Date: Thu, 16 Nov 2006 08:35:09 -0500
Subject: tehoretical SEDs in VO applications
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es> <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Message-ID: <455C690D.3070501@stsci.edu>
Hi, Miguel and all
As the specview developer, I would like to add my 0.02 cents to the
discussion. In fact, I would like to warn about the use of specview to
generate "valid" VO-compliant files.
The "Save as" and "Save" options write data in xml files (no FITS
support yet) following the standards set by the Spectrum Data Model in
its 0.92 incarnation. But the code is still incomplete as far as
metadata goes. Not all valid metadata described in 0.92 is actually
passed thru and ends up in the output xml file. Other errors and
inconsistencies may exiist as well. My poiny is, don't take specview's
output as a well rounded, finished example of a VO-compliant file. It's
work in progress.
Besides, there were significant developments in the Data Model model
since 0.92, and none of these are implemented in specview yet.
Miguel, could you please provide me with a copy of the HTS data from I
zw 18? I would like to see what is going on. In the examples I have, the
entire file generated by specview is read back, even when multiple
tables are present. And, what exactly do you mean by "at least in
ascii"? Specview supports a simple ascii table format, but that has
nothing to do with the VO xml format.
Cheers,
-Ivo
*********************************************************************
* Ivo C. Busko, PhD e-mail: busko at stsci.edu *
* Senior Systems Software Engineer Voice: (410)338-4472 *
* Astronomy Tools and Applications FAX: (410)338-4767 *
* Engineering and Software Services Division *
* Space Telescope Science Institute http://www.stsci.edu *
* 3700 San Martin Drive *
* Baltimore MD 21218-2410 USA *
*********************************************************************
Miguel Cervi?o wrote:
> Dear Alberto and all,
>
> I just tested with specview (2.12.2) to answer the question by Alberto.
> (I didn?t remeber if I had lost something in item (iii)
> The answer is about specview:
>
> i) it is needed a "name" in the table tag (or maybe in any other place)
> ii) it is needed the utype in X
> iii) it is needed the utype in Y
>
> so
>
>> Was (ii) to be counted twice or (iii) was left in your fingertips?
>
>
> The minimal VOTable it manage is:
>
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.1 http://
> www.ivoa.net/xml/VOTable/v1.1"
> xmlns="http://www.ivoa.net/xml/VOTable/v1.1">
>
>
> utype="sed:Segment.Points.SpectralCoord.Value"/>
> utype="sed:Segment.Points.Flux.Value"/>
>
>
> .....
>
>
> Surprisely I had found that specview is not able to manage the VOTables
> generated by itself at least in ascii!!
> At leats for the table i had donwload (first HTS data from I zw 18),
> the VOTable that is obtained when it is saved produce two
> elements, and specview only manage the first one with observational
> metadata. I had need to load the table in TopCat and save it again with
> topcat to obtain a VOTable that spceview reads.
>
>
> Any case I will try to repeat the exercise again in some weeks ...
>
> cheers
>
> Miguel
>
>
From busko at stsci.edu Thu Nov 16 05:35:09 2006
From: busko at stsci.edu (Ivo Busko)
Date: Thu, 16 Nov 2006 08:35:09 -0500
Subject: tehoretical SEDs in VO applications
References: <83BB6883-226C-40EC-B266-280310C48E3D@iaa.es> <5BB3D771-5E22-4182-859C-33ECF41990CE@eso.org>
Message-ID: <455C690D.3070501@stsci.edu>
Hi, Miguel and all
As the specview developer, I would like to add my 0.02 cents to the
discussion. In fact, I would like to warn about the use of specview to
generate "valid" VO-compliant files.
The "Save as" and "Save" options write data in xml files (no FITS
support yet) following the standards set by the Spectrum Data Model in
its 0.92 incarnation. But the code is still incomplete as far as
metadata goes. Not all valid metadata described in 0.92 is actually
passed thru and ends up in the output xml file. Other errors and
inconsistencies may exiist as well. My poiny is, don't take specview's
output as a well rounded, finished example of a VO-compliant file. It's
work in progress.
Besides, there were significant developments in the Data Model model
since 0.92, and none of these are implemented in specview yet.
Miguel, could you please provide me with a copy of the HTS data from I
zw 18? I would like to see what is going on. In the examples I have, the
entire file generated by specview is read back, even when multiple
tables are present. And, what exactly do you mean by "at least in
ascii"? Specview supports a simple ascii table format, but that has
nothing to do with the VO xml format.
Cheers,
-Ivo
*********************************************************************
* Ivo C. Busko, PhD e-mail: busko at stsci.edu *
* Senior Systems Software Engineer Voice: (410)338-4472 *
* Astronomy Tools and Applications FAX: (410)338-4767 *
* Engineering and Software Services Division *
* Space Telescope Science Institute http://www.stsci.edu *
* 3700 San Martin Drive *
* Baltimore MD 21218-2410 USA *
*********************************************************************
Miguel Cervi?o wrote:
> Dear Alberto and all,
>
> I just tested with specview (2.12.2) to answer the question by Alberto.
> (I didn?t remeber if I had lost something in item (iii)
> The answer is about specview:
>
> i) it is needed a "name" in the table tag (or maybe in any other place)
> ii) it is needed the utype in X
> iii) it is needed the utype in Y
>
> so
>
>> Was (ii) to be counted twice or (iii) was left in your fingertips?
>
>
> The minimal VOTable it manage is:
>
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.1 http://
> www.ivoa.net/xml/VOTable/v1.1"
> xmlns="http://www.ivoa.net/xml/VOTable/v1.1">
>
>
> utype="sed:Segment.Points.SpectralCoord.Value"/>
> utype="sed:Segment.Points.Flux.Value"/>
>
>
> .....
>
>
> Surprisely I had found that specview is not able to manage the VOTables
> generated by itself at least in ascii!!
> At leats for the table i had donwload (first HTS data from I zw 18),
> the VOTable that is obtained when it is saved produce two
> elements, and specview only manage the first one with observational
> metadata. I had need to load the table in TopCat and save it again with
> topcat to obtain a VOTable that spceview reads.
>
>
> Any case I will try to repeat the exercise again in some weeks ...
>
> cheers
>
> Miguel
>
>
From busko at stsci.edu Fri Nov 17 07:28:52 2006
From: busko at stsci.edu (Ivo Busko)
Date: Fri, 17 Nov 2006 10:28:52 -0500 (EST)
Subject: tehoretical SEDs in VO applications
Message-ID: <20061117102852.CMI06997@comet.stsci.edu>
Hi Miguel
The ArrayIndexOutOfBoundsException error in specview is
caused by a misspelled attribute in the input VOTable
file. The target position must be specified as two values,
for RA and DEC, and in the file you sent me there is only
one value, like this:
The "value" and "arraysize" attributes are inconsistent, thus
the error.
Now, I don't understand how this is possible, since the FITS
header doesn't have any positional information from where
the TargetPos field could be composed from. I run specview
using FOS data retrieved from the STScI archive, which have
an almost identical FITS header with the 1zw18 header, and
the generated VOTable does not have any TargetPos field, as
it should be.
So I wonder if the original file you used as specview input
is any different from STScI archive files, or if you edited
the file, or something on those lines.
Cheers,
-Ivo
From busko at stsci.edu Fri Nov 17 07:28:52 2006
From: busko at stsci.edu (Ivo Busko)
Date: Fri, 17 Nov 2006 10:28:52 -0500 (EST)
Subject: tehoretical SEDs in VO applications
Message-ID: <20061117102852.CMI06997@comet.stsci.edu>
Hi Miguel
The ArrayIndexOutOfBoundsException error in specview is
caused by a misspelled attribute in the input VOTable
file. The target position must be specified as two values,
for RA and DEC, and in the file you sent me there is only
one value, like this:
The "value" and "arraysize" attributes are inconsistent, thus
the error.
Now, I don't understand how this is possible, since the FITS
header doesn't have any positional information from where
the TargetPos field could be composed from. I run specview
using FOS data retrieved from the STScI archive, which have
an almost identical FITS header with the 1zw18 header, and
the generated VOTable does not have any TargetPos field, as
it should be.
So I wonder if the original file you used as specview input
is any different from STScI archive files, or if you edited
the file, or something on those lines.
Cheers,
-Ivo
From mcs at iaa.es Fri Nov 17 08:27:49 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 17 Nov 2006 17:27:49 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <20061117102852.CMI06997@comet.stsci.edu>
References: <20061117102852.CMI06997@comet.stsci.edu>
Message-ID: <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
uhmm,
I had not modified the file... I just make the proof again ... and I
obtain the same result
I reported.
The procces I use is:
a) resolve I zw 18 coordinates with NED using the form in specview
b) performe the search once the position is resolved
Here is the data of the image I obtain: (it was "HST spectra" in the
app, not "HST/FOS/SSAP")
HST Spectra
YES z0wp0104m MAST.HST.GHRS 143.50845833333 55.240944444444 http://
archive.stsci.edu/pub/vospectra/ghrs/z0wp0104m_vo.fits IZW18 1000
48734.779 48734.721 1992-04-22 17:17:00 1992-04-23 05:06:00 spectrum/
fits FK5 2000.000 G160M n n 1285.330 1321.280 WAVELENGTH FLUX SIGMA
L ML-1T-3 ML-1T-3 1E-10 1E+7 1E+7 ANGSTROMS ERGS/CM^2/S/A ERGS/CM^2/S/
A IZW18
I found 3 possible alternatives:
a) I am running spectview incorectly (I am ussing java -jar
spectview.jar instead the distribution script)
b) The different services that provide the spectra are different or
provide different information in the FITS header, and specview manage
it in a different way:
In case (b) it shoud needed to answer if
1.- it would be an issue related to the application
2.- It would be an issue related with the service... (I can try
to obtain the data from the same server with other applications and
see what happens... but during next week)
Cheers and nice weekend
Miguel
From mcs at iaa.es Fri Nov 17 08:27:49 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 17 Nov 2006 17:27:49 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <20061117102852.CMI06997@comet.stsci.edu>
References: <20061117102852.CMI06997@comet.stsci.edu>
Message-ID: <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
uhmm,
I had not modified the file... I just make the proof again ... and I
obtain the same result
I reported.
The procces I use is:
a) resolve I zw 18 coordinates with NED using the form in specview
b) performe the search once the position is resolved
Here is the data of the image I obtain: (it was "HST spectra" in the
app, not "HST/FOS/SSAP")
HST Spectra
YES z0wp0104m MAST.HST.GHRS 143.50845833333 55.240944444444 http://
archive.stsci.edu/pub/vospectra/ghrs/z0wp0104m_vo.fits IZW18 1000
48734.779 48734.721 1992-04-22 17:17:00 1992-04-23 05:06:00 spectrum/
fits FK5 2000.000 G160M n n 1285.330 1321.280 WAVELENGTH FLUX SIGMA
L ML-1T-3 ML-1T-3 1E-10 1E+7 1E+7 ANGSTROMS ERGS/CM^2/S/A ERGS/CM^2/S/
A IZW18
I found 3 possible alternatives:
a) I am running spectview incorectly (I am ussing java -jar
spectview.jar instead the distribution script)
b) The different services that provide the spectra are different or
provide different information in the FITS header, and specview manage
it in a different way:
In case (b) it shoud needed to answer if
1.- it would be an issue related to the application
2.- It would be an issue related with the service... (I can try
to obtain the data from the same server with other applications and
see what happens... but during next week)
Cheers and nice weekend
Miguel
From mcs at iaa.es Fri Nov 17 09:19:51 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 17 Nov 2006 18:19:51 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
References: <20061117102852.CMI06997@comet.stsci.edu> <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
Message-ID:
sorry,
To avoid misunderstandings:
3 possible alternatives:
a) I am running spectview incorrectly
b) There is a problem in specview (when retrieve from "HST spectra"
or write the VOTable)
c) There is a problem with the service that provide the "HST spectra"
sorry for my typing errors
miguel
> I found 3 possible alternatives:
>
> a) I am running spectview incorectly (I am ussing java -jar
> spectview.jar instead the distribution script)
> b) The different services that provide the spectra are different or
> provide different information in the FITS header, and specview
> manage it in a different way:
>
> In case (b) it shoud needed to answer if
> 1.- it would be an issue related to the application
> 2.- It would be an issue related with the service... (I can try
> to obtain the data from the same server with other applications and
> see what happens... but during next week)
>
>
> Cheers and nice weekend
>
> Miguel
>
From mcs at iaa.es Fri Nov 17 09:19:51 2006
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 17 Nov 2006 18:19:51 +0100
Subject: tehoretical SEDs in VO applications
In-Reply-To: <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
References: <20061117102852.CMI06997@comet.stsci.edu> <838B256F-CA78-4616-BBAA-C370AF80F4EF@iaa.es>
Message-ID:
sorry,
To avoid misunderstandings:
3 possible alternatives:
a) I am running spectview incorrectly
b) There is a problem in specview (when retrieve from "HST spectra"
or write the VOTable)
c) There is a problem with the service that provide the "HST spectra"
sorry for my typing errors
miguel
> I found 3 possible alternatives:
>
> a) I am running spectview incorectly (I am ussing java -jar
> spectview.jar instead the distribution script)
> b) The different services that provide the spectra are different or
> provide different information in the FITS header, and specview
> manage it in a different way:
>
> In case (b) it shoud needed to answer if
> 1.- it would be an issue related to the application
> 2.- It would be an issue related with the service... (I can try
> to obtain the data from the same server with other applications and
> see what happens... but during next week)
>
>
> Cheers and nice weekend
>
> Miguel
>
From busko at stsci.edu Fri Nov 17 10:08:46 2006
From: busko at stsci.edu (Ivo Busko)
Date: Fri, 17 Nov 2006 13:08:46 -0500 (EST)
Subject: tehoretical SEDs in VO applications
Message-ID: <20061117130846.CMI15037@comet.stsci.edu>
Hi, Miguel
Ah, you are reading directly from a SSAP service...
OK, so it is a bug in specview after all. A good example
of how the code is not yet propely tested. I fixed this
particular bug, but other bugs are sure to surface sooner
or later.
The bug fix should be available on the next release.
And thanks for providing the test case!
-Ivo
---- Original message ----
>Date: Fri, 17 Nov 2006 18:19:51 +0100
>From: Miguel Cervi?o
>Subject: Re: tehoretical SEDs in VO applications
>To: Miguel Cervi?o
>Cc: busko at stsci.edu, theory at ivoa.net, apps at ivoa.net
>
>sorry,
>
>To avoid misunderstandings:
>
>3 possible alternatives:
>
>a) I am running spectview incorrectly
>b) There is a problem in specview (when retrieve from "HST spectra"
>or write the VOTable)
>c) There is a problem with the service that provide the "HST spectra"
>
>sorry for my typing errors
>
>miguel
>
>> I found 3 possible alternatives:
>>
>> a) I am running spectview incorectly (I am ussing java -jar
>> spectview.jar instead the distribution script)
>> b) The different services that provide the spectra are different or
>> provide different information in the FITS header, and specview
>> manage it in a different way:
>>
>> In case (b) it shoud needed to answer if
>> 1.- it would be an issue related to the application
>> 2.- It would be an issue related with the service... (I can try
>> to obtain the data from the same server with other applications and
>> see what happens... but during next week)
>>
>>
>> Cheers and nice weekend
>>
>> Miguel
>>
>
From busko at stsci.edu Fri Nov 17 10:08:46 2006
From: busko at stsci.edu (Ivo Busko)
Date: Fri, 17 Nov 2006 13:08:46 -0500 (EST)
Subject: tehoretical SEDs in VO applications
Message-ID: <20061117130846.CMI15037@comet.stsci.edu>
Hi, Miguel
Ah, you are reading directly from a SSAP service...
OK, so it is a bug in specview after all. A good example
of how the code is not yet propely tested. I fixed this
particular bug, but other bugs are sure to surface sooner
or later.
The bug fix should be available on the next release.
And thanks for providing the test case!
-Ivo
---- Original message ----
>Date: Fri, 17 Nov 2006 18:19:51 +0100
>From: Miguel Cervi?o
>Subject: Re: tehoretical SEDs in VO applications
>To: Miguel Cervi?o
>Cc: busko at stsci.edu, theory at ivoa.net, apps at ivoa.net
>
>sorry,
>
>To avoid misunderstandings:
>
>3 possible alternatives:
>
>a) I am running spectview incorrectly
>b) There is a problem in specview (when retrieve from "HST spectra"
>or write the VOTable)
>c) There is a problem with the service that provide the "HST spectra"
>
>sorry for my typing errors
>
>miguel
>
>> I found 3 possible alternatives:
>>
>> a) I am running spectview incorectly (I am ussing java -jar
>> spectview.jar instead the distribution script)
>> b) The different services that provide the spectra are different or
>> provide different information in the FITS header, and specview
>> manage it in a different way:
>>
>> In case (b) it shoud needed to answer if
>> 1.- it would be an issue related to the application
>> 2.- It would be an issue related with the service... (I can try
>> to obtain the data from the same server with other applications and
>> see what happens... but during next week)
>>
>>
>> Cheers and nice weekend
>>
>> Miguel
>>
>