From Noel.Winstanley at manchester.ac.uk  Thu Nov  9 05:34:29 2006
From: Noel.Winstanley at manchester.ac.uk (Noel Winstanley)
Date: Thu, 9 Nov 2006 13:34:29 +0000
Subject: Announce: Astro Runtime Mailing Lists.
Message-ID: <F673CCA1-9E12-4179-92A8-95D733C79BEC@jb.man.ac.uk>

Hi,
I'd like to announce 2 new mailing lists for Astro Runtime (An API  
for the Virtual Observatory -  http://www2.astrogrid.org/desktop/ 
astro-runtime )

* Astro Runtime Users - for people using the Astro Runtime in their  
own science,  scripts or applications.
   http://lists.astrogrid.org/mailman/listinfo/astro-runtime-users

* Astro Runtime Developers - for people developing the Astro Runtime.
   http://lists.astrogrid.org/mailman/listinfo/astro-runtime-devs

Mailing list info is summarized at
  http://www2.astrogrid.org/desktop/astro-runtime/mailing-lists

Many Thanks
Noel Winstanley

---
http://wiki.astrogrid.org/bin/view/Main/NoelWinstanley
Senior Developer, AstroGrid Project.
Jodrell Bank Observatory, University of Manchester
Workbench - http://www.astrogrid.org/desktop | Astro Runtime -   
http://www.astrogrid.org/desktop/astro-runtime



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 <TABLE  
> name="whatever"> looks to work
>        ii.- utype in x and y coordinates in FIELD must be specified
>
>       c.2) VOSpec needs two (non-standard) <PARAM...> 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 <TABLE  
> name="whatever"> looks to work
>        ii.- utype in x and y coordinates in FIELD must be specified
>
>       c.2) VOSpec needs two (non-standard) <PARAM...> 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: <E0D9D22D-A535-4297-AF69-EC089BDB3417@iaa.es>

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:

<?xml version='1.0'?>
<VOTABLE version="1.1"
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">
<RESOURCE>
<TABLE name="hola2">
<FIELD datatype="float" name="WAVE" unit="0.1nm"  
utype="sed:Segment.Points.SpectralCoord.Value"/>
<FIELD datatype="float" name="FLUX" unit="erg/s/0.1nm/cm2"  
utype="sed:Segment.Points.Flux.Value"/>
<DATA>
<TABLEDATA>
.....


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 <TABLE>  
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: <E0D9D22D-A535-4297-AF69-EC089BDB3417@iaa.es>

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:

<?xml version='1.0'?>
<VOTABLE version="1.1"
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">
<RESOURCE>
<TABLE name="hola2">
<FIELD datatype="float" name="WAVE" unit="0.1nm"  
utype="sed:Segment.Points.SpectralCoord.Value"/>
<FIELD datatype="float" name="FLUX" unit="erg/s/0.1nm/cm2"  
utype="sed:Segment.Points.Flux.Value"/>
<DATA>
<TABLEDATA>
.....


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 <TABLE>  
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> <E0D9D22D-A535-4297-AF69-EC089BDB3417@iaa.es>
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:
> 
> <?xml version='1.0'?>
> <VOTABLE version="1.1"
> 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">
> <RESOURCE>
> <TABLE name="hola2">
> <FIELD datatype="float" name="WAVE" unit="0.1nm"  
> utype="sed:Segment.Points.SpectralCoord.Value"/>
> <FIELD datatype="float" name="FLUX" unit="erg/s/0.1nm/cm2"  
> utype="sed:Segment.Points.Flux.Value"/>
> <DATA>
> <TABLEDATA>
> .....
> 
> 
> 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 <TABLE>  
> 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> <E0D9D22D-A535-4297-AF69-EC089BDB3417@iaa.es>
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:
> 
> <?xml version='1.0'?>
> <VOTABLE version="1.1"
> 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">
> <RESOURCE>
> <TABLE name="hola2">
> <FIELD datatype="float" name="WAVE" unit="0.1nm"  
> utype="sed:Segment.Points.SpectralCoord.Value"/>
> <FIELD datatype="float" name="FLUX" unit="erg/s/0.1nm/cm2"  
> utype="sed:Segment.Points.Flux.Value"/>
> <DATA>
> <TABLEDATA>
> .....
> 
> 
> 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 <TABLE>  
> 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:

<PARAM unit="deg" datatype="float" name="TargetPos" ucd="pos.eq;src" utype="sed:Target.pos" value="55.2396480555556" arraysize="2"/>

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:

<PARAM unit="deg" datatype="float" name="TargetPos" ucd="pos.eq;src" utype="sed:Target.pos" value="55.2396480555556" arraysize="2"/>

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: <E1286B37-D4E3-4C6B-890B-A9FB6506FAFA@iaa.es>

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: <E1286B37-D4E3-4C6B-890B-A9FB6506FAFA@iaa.es>

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 <mcs at iaa.es>  
>Subject: Re: tehoretical SEDs in VO applications  
>To: Miguel Cervi?o <mcs at iaa.es>
>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 <mcs at iaa.es>  
>Subject: Re: tehoretical SEDs in VO applications  
>To: Miguel Cervi?o <mcs at iaa.es>
>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
>>
>