Okay, I'm a dumb sh--!  Trying to submit a star, but seem to have
gotten everything right except the position.  Whoever's reviewing
submissions, when you see one from me called VSX J080212.0-372917,
it's wrong, trash, garbage, just delete it outright and I'll get the
right star put in.

Sorry for the hassle....

Jim

---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

No hassle at all, Jim.  You should have gotten an automated
notification from the system on the "rejection".

-Chris

On 11/8/06, James Bedient <jbedient@...> wrote:
> Okay, I'm a dumb sh--!  Trying to submit a star, but seem to have
> gotten everything right except the position.  Whoever's reviewing
> submissions, when you see one from me called VSX J080212.0-372917,
> it's wrong, trash, garbage, just delete it outright and I'll get the
> right star put in.
>
> Sorry for the hassle....
>
> Jim
>
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

Thanks Christopher!  I'm glad it wasn't too much of a problem.

Jim

On 11/8/06, Christopher Watson <skygeex@...> wrote:
> No hassle at all, Jim.  You should have gotten an automated
> notification from the system on the "rejection".
>
> -Chris
>
> On 11/8/06, James Bedient <jbedient@...> wrote:
> > Okay, I'm a dumb sh--!  Trying to submit a star, but seem to have
> > gotten everything right except the position.  Whoever's reviewing
> > submissions, when you see one from me called VSX J080212.0-372917,
> > it's wrong, trash, garbage, just delete it outright and I'll get the
> > right star put in.
> >
> > Sorry for the hassle....
> >
> > Jim
> >
> > ---------------------------------------------
> > Jim Bedient
> > jbedient@...
> > www.bedient.us
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
>
> Yahoo! Groups Links
>
>
>
>
>


--
---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

Hi all,

Just noticed one SDSS CV that I'll be working on next week is not in
VSX.  It's from this year's SDSS CV paper.  Should I put it in, or is
someone going to work on those?  Or is someone needed to do those?

Jim

---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

I know the first couple of SDSS papers were included in Downes et al., so
you should check to see what was the last paper that made it into that
catalog before it froze.  Then add any more recent ones.  Paper V is out;
paper VI is in the works.
Arne

On 11/12/06, James Bedient <jbedient@...> wrote:
> Hi all,
>
> Just noticed one SDSS CV that I'll be working on next week is not in
> VSX.  It's from this year's SDSS CV paper.  Should I put it in, or is
> someone going to work on those?  Or is someone needed to do those?
>
> Jim
>
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

Jim, could you point me to the paper, please.  Thanks.

-Chris

On 11/12/06, James Bedient <jbedient@...> wrote:
> Hi all,
>
> Just noticed one SDSS CV that I'll be working on next week is not in
> VSX.  It's from this year's SDSS CV paper.  Should I put it in, or is
> someone going to work on those?  Or is someone needed to do those?
>
> Jim
>
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

Szkody et al.
2006AJ....131..973S
Astron. J., 131, 973-983 (2006)
Cataclysmic variables from Sloan Digital Sky Survey. V. The fifth year (2004).

On 11/12/06, Christopher Watson <skygeex@...> wrote:
> Jim, could you point me to the paper, please.  Thanks.
>
> -Chris
>
> On 11/12/06, James Bedient <jbedient@...> wrote:
> > Hi all,
> >
> > Just noticed one SDSS CV that I'll be working on next week is not in
> > VSX.  It's from this year's SDSS CV paper.  Should I put it in, or is
> > someone going to work on those?  Or is someone needed to do those?
> >
> > Jim
> >
> > ---------------------------------------------
> > Jim Bedient
> > jbedient@...
> > www.bedient.us

James Bedient wrote:
> Szkody et al.
> 2006AJ....131..973S
> Astron. J., 131, 973-983 (2006)
> Cataclysmic variables from Sloan Digital Sky Survey. V. The fifth year (2004).
>
> On 11/12/06, Christopher Watson <skygeex@...> wrote:
>
>>Jim, could you point me to the paper, please.  Thanks.
>>
The easy way to find all of the papers in the series is to go to
ADS and select Szkody AND Henden.  I think astro-ph copies of all
papers exist; if not, let me know and I can send you a copy.
Arne

Granted Var CON yy is tredious and pathetic, but

it already has a name, SDSS Jwhateverthecoordsare

or the USNO B1.0 or GSC2.3 identities

You see, it isn't found by aavso, it's found by a bunch of folk at
Arizona University who are near earth lumps of rock searchers and have
probably never heard of VSX, so likely wouldn't take kindly to such
usurping.

After all, even AAVSO hasn't heard of VSX, as it is conspicously
absent in the list of resources noted in their alert within which this
object was checked for.

It's noted by the discoverers as having a highly reasonable blue 20th
magnitude progenitor in the SDSS, so that can be its designation,
although admittedly the position is ostensibly about half an arcsec
off, though the amplitude range matches well too.

Is there a way to merge or link two entries that are the same star?
ASAS 201608-5051.6 and NSV 12938 are one and the same.  Should I just
revise them both to the same position (a good one from NOMAD1 in this
case) or what's the protocol?

Jim

---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

Jim,

Linking two entries and then "hiding" one of them, is a functionality that
is only available to moderators at this moment.  In this case the two
entries are already linked.  This can be seen because the name of the
other entry appears in bold in the "Other names" section.  By clicking it,
you can see the detail sheet of this other entry.
The best way to proceed is to update one entry (I suggest NSV 12938 in
this case) with all the recent info, and we will then make sure the other
entry is "hidden".  This means that the entry will no longer appear in a
coordinate search, but can still be reached from the "Other names" section
of the "main" entry.

Patrick

--- James Bedient <jbedient@...> wrote:

> Is there a way to merge or link two entries that are the same star?
> ASAS 201608-5051.6 and NSV 12938 are one and the same.  Should I just
> revise them both to the same position (a good one from NOMAD1 in this
> case) or what's the protocol?
>
> Jim
>
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>




________________________________________________________________________________\
____
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

--- In vsx-dis@yahoogroups.com, "James Bedient" <jbedient@...> wrote:

> ASAS 201608-5051.6 and NSV 12938 are one and the same.  Should I just
> revise them both to the same position (a good one from NOMAD1 in this
> case)

Let us get this sorted straight off...

...there are no such thing as NOMAD1 positions, no moreso nor
nomoreless than there are VizieR positions.

This position is an UCAC2 position.

It is even flagged as an UCAC2 position in NOMAD.

As soon as NOMAD got included in VizieR I new this bad habit would start.

There is no reprocessing in NOMAD, nor any criticial assessment, it
merely has a Tycho2->UCAC2->USNO B1.0 hierarchy, with 2MASS thrown in
if the object is not in any of the above.

EXCEPT for one exception.  The YB6 data that is flagged in NOMAD
appears in NOMAD only, and as such is tantamount to being "published"
in NOMAD.

The YB6 data is USNO astrometry group's inhouse digitization and
astrometric reduction of Yale proper motion survey plates.  Commonly
the user will find that most of these objects uniquely attributed to
this catalogue as their reference source within NOMAD are in fact
close to other, often brighter, stars, and therefore were missed due
to resolution/proximity issues in UCAC2 reduction and/or USNO B1.0
overexposed source stars hid them (Yale stuff is not quite as deep as
POSS).

However, the YB6 data has _not_ been formally published, no paper
trail exists for it, and although it can be assumed that the same team
that did USNO An.0 and B1.0 was also capable of making a good job of
YB6, no independent large scale source of it exists (just happenstance
smatterings returned from any NOMAD search via either NOFS or VizieR)
and unlike UCAC2 and USNO B1.0 there have consequently been no
attempts to use it exclusively in astrometric reductions in order to
assess its quality.

Further, and significantly, the lack of a formal published paper on it
(it may well be mentioned in passing in the NOMAD announce paper, if
such latter exists, but that ain't the same thing), means it has no
bibliographic referenceable peer reviewed literature backup.  In terms
of VSX this would mean astrometry would be adopted that was in
scientific terms tantamount to hearsay.  No matter how good it may in
the end be shown to be, it is not at present either tested or
published, in other words.

Summary, there are no NOMAD positions.  Use the source Jim, it's
astrometry, but not as we know it.

Incidentally, any errors or problems inherent to Tycho2, UCAC2 and/or
USNO B1.0 are, of course, also retained within NOMAD, which is a
working acronym not dissimilar in wordage to SIMBAD, which itself is
well known to suffer being apocryphal from time to time.

All this, of course, assumes VSX actually deigns to note the
astrometric source of its quality positions, I can't remember whether
it does or not, over and above the imported inference via GCVS
astrometric referencing.

John

PS When more VO stuff comes in folk are going to have to keep their
brain ready for stuff like this.  It's not a new distinction,
catalogue and data users have had to be aware of it for years, but
ostensibly it's more "hidden" in this case.  Simply think "is this a
catalogue or a VizieR like lookup table?".  Now the damn thing's in
VizieR people are using it more (it's been around several years), not
realising they are just looking at Tycho2, UCAC2 or USNO B1.0 data
_third hand_!  Worst still, if NOMAD is accessed via a general VizieR
coordinate search then said source Tcyho2, UCAC2 and USNO B1.0 entries
are also going to appear in the same VizieR output, along with
attendant discriminatory flags and astrometric errors for
intercomparison of these sources, yet folk ignore them and quote NOMAD
as if it was somehow better just because it was newer!!!
(Professionals and amateurs alike, it ain't just in this instance...
...interesting Jim's in the company of his "old pals" the GCVS in this
instance with respect to this recent practice).

Accreditation causes more trouble than enough, usually coz it is
cocked up.  If folk think about it in terms of audit trail, or
remember how annoyed they get trying to look up references they've
found in the literature that _do not_ lead to primary sources, they
might get the gist of the matter.

VSX does not want to be a source of meaningless fundamental reference
material.  NOMAD is not an primary source astrometric catalogue in
terms of quotability, being merely a compilation.  It contains such
information but is not a result of generating said.  Granted it flags
the true primary source and generating catalogue within it, well, if
that's the case, quote said primary source!

Incidentally, there appears to be no critical assessment with respect
to the source they chose for any particular object, such that a faint
limit Tycho2 star may well be chosen in their general merging of
databases whereas the UCAC2 position, nested in the middle of the
dynamic photometric range, may well be more accurate in terms of both
position and certainly proper motion.  This particular object is
flagged in NOMAD as also being in YB6 and 2MASS... ...yet the UCAC2
position was chosen.  Quite frankly, as it is a quite red object it
will be overexposed in 2MASS.  It's neither overexposed nor near the
faint limit in UCAC2 so that is likely the best source in this
instance, yet a tighter, crisper image is still most likely to occur
in the YB6 blue plate.  But as I say, this latter is unpublished and
really shouldn't be used unless there is no alternative whatsoever, so
UCAC2 still works as the best case in this instance.


What VSX does want to have are IBVS variables included, and further,
AAVSO does want to mention VSX everytime it announces an alert about a
new variable not being in various catalogues, as VSX contains more
variables than the resources AAVSO usually mentions... ...this is over
and above the connection between VSX and AAVSO: AAVSO staff should
look in VSX on such occasions even if the damn thing was totally
unrelated.

I'm not impressed yet.  And contrary to popular belief I can be
impressed, and it even don't take much to impress me.

flying.visit wrote:
> --- In vsx-dis@yahoogroups.com, "James Bedient" <jbedient@...> wrote:
>
>
>>ASAS 201608-5051.6 and NSV 12938 are one and the same.  Should I just
>>revise them both to the same position (a good one from NOMAD1 in this
>>case)
>
>
> Let us get this sorted straight off...
>
> ...there are no such thing as NOMAD1 positions, no moreso nor
> nomoreless than there are VizieR positions.
>
See below.
>
> The YB6 data is USNO astrometry group's inhouse digitization and
> astrometric reduction of Yale proper motion survey plates.  Commonly
> the user will find that most of these objects uniquely attributed to
> this catalogue as their reference source within NOMAD are in fact
> close to other, often brighter, stars, and therefore were missed due
> to resolution/proximity issues in UCAC2 reduction and/or USNO B1.0
> overexposed source stars hid them (Yale stuff is not quite as deep as
> POSS).
>
perhaps for B1.0, but rarely for UCAC2.  UCAC2 is CCD-based, with a
small telescope and decent sampling.  It does a good job of picking
up faint stars near bright ones.

> However, the YB6 data has _not_ been formally published, no paper
> trail exists for it, and although it can be assumed that the same team
> that did USNO An.0 and B1.0 was also capable of making a good job of
> YB6, no independent large scale source of it exists (just happenstance
> smatterings returned from any NOMAD search via either NOFS or VizieR)
> and unlike UCAC2 and USNO B1.0 there have consequently been no
> attempts to use it exclusively in astrometric reductions in order to
> assess its quality.
>
YB6 is semi-published, in that it is a combination of NPM and SPM, where
SPM is published.  NPM is in the process of publication.


> All this, of course, assumes VSX actually deigns to note the
> astrometric source of its quality positions, I can't remember whether
> it does or not, over and above the imported inference via GCVS
> astrometric referencing.
>
> VSX does not want to be a source of meaningless fundamental reference
> material.  NOMAD is not an primary source astrometric catalogue in
> terms of quotability, being merely a compilation.  It contains such
> information but is not a result of generating said.  Granted it flags
> the true primary source and generating catalogue within it, well, if
> that's the case, quote said primary source!
>
It keeps getting more difficult to do this.  For example, if you
go to VizieR and get the UCAC2 position for an object, that is *not*
the UCAC2 position, but one that is propogated with proper motion
from the original epoch to 2000.0.  I don't consider VSX to be
a great source for astrometric information and so have not pushed
hard on getting the most precise position.

> Incidentally, there appears to be no critical assessment with respect
> to the source they chose for any particular object, such that a faint
> limit Tycho2 star may well be chosen in their general merging of
> databases whereas the UCAC2 position, nested in the middle of the
> dynamic photometric range, may well be more accurate in terms of both
> position and certainly proper motion.  This particular object is
> flagged in NOMAD as also being in YB6 and 2MASS... ...yet the UCAC2
> position was chosen.  Quite frankly, as it is a quite red object it
> will be overexposed in 2MASS.  It's neither overexposed nor near the
> faint limit in UCAC2 so that is likely the best source in this
> instance, yet a tighter, crisper image is still most likely to occur
> in the YB6 blue plate.  But as I say, this latter is unpublished and
> really shouldn't be used unless there is no alternative whatsoever, so
> UCAC2 still works as the best case in this instance.
>
YB6 is photographic, so has the typical 200mas/measurement error.
UCAC2 is much better, so the right choice of astrometric catalog was
chosen.  Primarily, YB6 is used for photometry (B&V) and proper motion;
few NOMAD astrometric positions are derived from this catalog.

>
> What VSX does want to have are IBVS variables included, and further,
> AAVSO does want to mention VSX everytime it announces an alert about a
> new variable not being in various catalogues, as VSX contains more
> variables than the resources AAVSO usually mentions... ...this is over
> and above the connection between VSX and AAVSO: AAVSO staff should
> look in VSX on such occasions even if the damn thing was totally
> unrelated.
>
point taken.  I've tried to make sure all staff refer to VSX when
publishing.  In this particular case, the other catalogs (NSVS, ASAS)
were mentioned in that no star appeared in either catalog at the
VarLeo06 position, not that we referenced the variability
products from those surveys.
Arne

--- In vsx-dis@yahoogroups.com, arne <arne@...> wrote:

> perhaps for B1.0, but rarely for UCAC2.  UCAC2 is CCD-based, with a
> small telescope and decent sampling.  It does a good job of picking
> up faint stars near bright ones.

nothing closer than six arcseconds apart, unless special hand inputted
cases from known classical catalogues, are included in UCAC2, ie
anything that close together was not normally reduced in the analysis.

this is one of the big differences to be undertaken in UCAC3, along
with other considerations.

> YB6 is semi-published, in that it is a combination of NPM and SPM, where
> SPM is published.  NPM is in the process of publication.

I'd have to look that up.  In my understanding the Yale analysis was
the Yale analysis, already published as you note for SPM and for NPM2,
which are on the same system as I remember, but the YB6 was an
independent reduction by USNO from the digitized data they provided to
Yale.  The YB6 may even cover regions which SPM3.3 and NPM2
deliberately avoid in the reduction but may well have been imaged...
...I've never been sure if these places were just avoided in the
reduction or never imaged initially.

> It keeps getting more difficult to do this.  For example, if you
> go to VizieR and get the UCAC2 position for an object, that is *not*
> the UCAC2 position, but one that is propogated with proper motion
> from the original epoch to 2000.0.

Wrong.

VizieR will include what you mention if you want it to, it may even
default include it if those options aren't unticked, but the original
source catalogue values are still included.  For this object you will
note that ucac2 and nomad1 entries say the same thing, the source
ucac2 catalog decimal degrees position.

VizieR often includes extras but keeps the original source data too.
The only place offhand that I can remember where they don't do this is
for the cos(dec) correction to ra proper motion in Tycho2, UCAC2 and
possibly USNO B1.0.

> I don't consider VSX to be
> a great source for astrometric information and so have not pushed
> hard on getting the most precise position.

Fair enough.

> YB6 is photographic, so has the typical 200mas/measurement error.
> UCAC2 is much better, so the right choice of astrometric catalog was
> chosen.  Primarily, YB6 is used for photometry (B&V) and proper motion;
> few NOMAD astrometric positions are derived from this catalog.

When you go looking for double stars you find where all the ones used
are, they're often near brighter stars on the whole missed from the
other catalogues because of this, but also UCAC2 doesn't always go too
faint (YB6 will go down to 17 or 18 or so, UCAC2 can often stop at
around 14 or so, albeit sometimes much fainter) and again, UCAC2 has
this six arcsecond thing, which can come into play more than expected.

Incidentally, I've noted to this to some before, YB6 colours are
noncontemporaneous, and therefore useless for variable objects.

John

OK, in that I have a wife, two daughters, three cats, three cars, a
house, a real job, etc., I haven't spent my life studying astrometric
catalogs.  When NOMAD1 popped up on VizieR, I read the "read me" and
figured when it said "For each unique star the "best" astrometric and
photometric data are chosen from the source catalogs and merged into a
single dataset." that they meant it.

As long as the source of a piece of data is identified, I don't think
it matters a hoot where it's from, GSC or UCAC or USNO or whatever.
It's traceable back.

VSX appears to be down - Sunday 09:47 UT

the whole aavso.org site is down - problems with the internet
provider, i'd guess

On 12/2/06, martin_piers_nicholson <martin_piers_nicholson@...> wrote:
> VSX appears to be down - Sunday 09:47 UT
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

I came across a paper containing spectral classifications for a bunch
of variables: IBVS 4612.

The few I checked in VSX didn't have spectral types in the database.
What's the best way to get this information incorporated in VSX?  I
can plug them in one by one via the revision process if that's how to
do it, or whatever other method might work.

Jim

---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

That IBVS report does indeed have a lot of spectral types in it.  Over
300.  That'd be a pain to enter one-by-one.  Maybe, if someone could
get that into a tab-delimited or fixed-width ASCII file, I could put
it onto the list of lists to get into VSX.  However, I can't guarantee
when they would get in.

-Chris

On 12/3/06, James Bedient <jbedient@...> wrote:
> I came across a paper containing spectral classifications for a bunch
> of variables: IBVS 4612.
>
> The few I checked in VSX didn't have spectral types in the database.
> What's the best way to get this information incorporated in VSX?  I
> can plug them in one by one via the revision process if that's how to
> do it, or whatever other method might work.
>
> Jim
>
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>
>
>
> Yahoo! Groups Links
>
>
>
>

An excellent source for spectral types for a lot of non-GCVS variables
(ASAS3, NSVS, ...) is Brian Skiff's "live" mktypes.dat list here:
ftp://ftp.lowell.edu/pub/bas/starcats/.

Patrick

--- Christopher Watson <skygeex@...> wrote:

> That IBVS report does indeed have a lot of spectral types in it.  Over
> 300.  That'd be a pain to enter one-by-one.  Maybe, if someone could
> get that into a tab-delimited or fixed-width ASCII file, I could put
> it onto the list of lists to get into VSX.  However, I can't guarantee
> when they would get in.
>
> -Chris
>
> On 12/3/06, James Bedient <jbedient@...> wrote:
> > I came across a paper containing spectral classifications for a bunch
> > of variables: IBVS 4612.
> >
> > The few I checked in VSX didn't have spectral types in the database.
> > What's the best way to get this information incorporated in VSX?  I
> > can plug them in one by one via the revision process if that's how to
> > do it, or whatever other method might work.
> >
> > Jim
> >
> > ---------------------------------------------
> > Jim Bedient
> > jbedient@...
> > www.bedient.us
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Chistopher,

Just a list, tab-separated, like so?

Var.          Spec. Type
XX YYY   M9
AA VVV  M2e

I can get that to you - won't take long.  Ain't no rush to get it in, though.

Jim

On 12/3/06, Christopher Watson <skygeex@...> wrote:
> That IBVS report does indeed have a lot of spectral types in it.  Over
> 300.  That'd be a pain to enter one-by-one.  Maybe, if someone could
> get that into a tab-delimited or fixed-width ASCII file, I could put
> it onto the list of lists to get into VSX.  However, I can't guarantee
> when they would get in.
>
> -Chris
>
> On 12/3/06, James Bedient <jbedient@...> wrote:
> > I came across a paper containing spectral classifications for a bunch
> > of variables: IBVS 4612.
> >
> > The few I checked in VSX didn't have spectral types in the database.
> > What's the best way to get this information incorporated in VSX?  I
> > can plug them in one by one via the revision process if that's how to
> > do it, or whatever other method might work.
> >
> > Jim
> >
> > ---------------------------------------------
> > Jim Bedient
> > jbedient@...
> > www.bedient.us
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

Parts of Vizier appear to be down - routine searches in 2MASS and
NOMAD do not seem to work.

That'd be perfect.  Thanks.

-Chris

On 12/3/06, James Bedient <jbedient@...> wrote:
> Chistopher,
>
> Just a list, tab-separated, like so?
>
> Var.          Spec. Type
> XX YYY   M9
> AA VVV  M2e
>
> I can get that to you - won't take long.  Ain't no rush to get it in, though.
>
> Jim
>
> On 12/3/06, Christopher Watson <skygeex@...> wrote:
> > That IBVS report does indeed have a lot of spectral types in it.  Over
> > 300.  That'd be a pain to enter one-by-one.  Maybe, if someone could
> > get that into a tab-delimited or fixed-width ASCII file, I could put
> > it onto the list of lists to get into VSX.  However, I can't guarantee
> > when they would get in.
> >
> > -Chris
> >
> > On 12/3/06, James Bedient <jbedient@...> wrote:
> > > I came across a paper containing spectral classifications for a bunch
> > > of variables: IBVS 4612.
> > >
> > > The few I checked in VSX didn't have spectral types in the database.
> > > What's the best way to get this information incorporated in VSX?  I
> > > can plug them in one by one via the revision process if that's how to
> > > do it, or whatever other method might work.
> > >
> > > Jim
> > >
> > > ---------------------------------------------
> > > Jim Bedient
> > > jbedient@...
> > > www.bedient.us
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
> --
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>
>
>
> Yahoo! Groups Links
>
>
>
>

NP.  In fact, I have it already.  If there's an uncertainty flag on
the spectral type, does that need to be broken out in a separate
field?

Jim

On 12/3/06, Christopher Watson <skygeex@...> wrote:
> That'd be perfect.  Thanks.
>
> -Chris
>
> On 12/3/06, James Bedient <jbedient@...> wrote:
> > Chistopher,
> >
> > Just a list, tab-separated, like so?
> >
> > Var.          Spec. Type
> > XX YYY   M9
> > AA VVV  M2e
> >
> > I can get that to you - won't take long.  Ain't no rush to get it in,
though.
> >
> > Jim
> >
> > On 12/3/06, Christopher Watson <skygeex@...> wrote:
> > > That IBVS report does indeed have a lot of spectral types in it.  Over
> > > 300.  That'd be a pain to enter one-by-one.  Maybe, if someone could
> > > get that into a tab-delimited or fixed-width ASCII file, I could put
> > > it onto the list of lists to get into VSX.  However, I can't guarantee
> > > when they would get in.
> > >
> > > -Chris
> > >
> > > On 12/3/06, James Bedient <jbedient@...> wrote:
> > > > I came across a paper containing spectral classifications for a bunch
> > > > of variables: IBVS 4612.
> > > >
> > > > The few I checked in VSX didn't have spectral types in the database.
> > > > What's the best way to get this information incorporated in VSX?  I
> > > > can plug them in one by one via the revision process if that's how to
> > > > do it, or whatever other method might work.
> > > >
> > > > Jim
> > > >
> > > > ---------------------------------------------
> > > > Jim Bedient
> > > > jbedient@...
> > > > www.bedient.us
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> > --
> > ---------------------------------------------
> > Jim Bedient
> > jbedient@...
> > www.bedient.us
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

You must be using the UK mirror, it seems to be acting up, but
Strasbourg, http://vizier.u-strasbg.fr/viz-bin/VizieR, is working
fine.

Jim

On 12/3/06, martin_piers_nicholson <martin_piers_nicholson@...> wrote:
> Parts of Vizier appear to be down - routine searches in 2MASS and
> NOMAD do not seem to work.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

No.  Uncertainy colons hang onto the end of the spec type.  Separate
column not needed.

-Chris

On 12/4/06, James Bedient <jbedient@...> wrote:
> NP.  In fact, I have it already.  If there's an uncertainty flag on
> the spectral type, does that need to be broken out in a separate
> field?
>
> Jim
>
> On 12/3/06, Christopher Watson <skygeex@...> wrote:
> > That'd be perfect.  Thanks.
> >
> > -Chris
> >
> > On 12/3/06, James Bedient <jbedient@...> wrote:
> > > Chistopher,
> > >
> > > Just a list, tab-separated, like so?
> > >
> > > Var.          Spec. Type
> > > XX YYY   M9
> > > AA VVV  M2e
> > >
> > > I can get that to you - won't take long.  Ain't no rush to get it in,
though.
> > >
> > > Jim
> > >
> > > On 12/3/06, Christopher Watson <skygeex@...> wrote:
> > > > That IBVS report does indeed have a lot of spectral types in it.  Over
> > > > 300.  That'd be a pain to enter one-by-one.  Maybe, if someone could
> > > > get that into a tab-delimited or fixed-width ASCII file, I could put
> > > > it onto the list of lists to get into VSX.  However, I can't guarantee
> > > > when they would get in.
> > > >
> > > > -Chris
> > > >
> > > > On 12/3/06, James Bedient <jbedient@...> wrote:
> > > > > I came across a paper containing spectral classifications for a bunch
> > > > > of variables: IBVS 4612.
> > > > >
> > > > > The few I checked in VSX didn't have spectral types in the database.
> > > > > What's the best way to get this information incorporated in VSX?  I
> > > > > can plug them in one by one via the revision process if that's how to
> > > > > do it, or whatever other method might work.
> > > > >
> > > > > Jim
> > > > >
> > > > > ---------------------------------------------
> > > > > Jim Bedient
> > > > > jbedient@...
> > > > > www.bedient.us
> > > > >
> > > > >
> > > > >
> > > > > Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > ---------------------------------------------
> > > Jim Bedient
> > > jbedient@...
> > > www.bedient.us
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
> --
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>
>
>
> Yahoo! Groups Links
>
>
>
>

I found another IBVS article containing spectral types - just 15 of
them, so I entered them via the revision process.  Most of them need
ASAS & NSVS entries merged, too.

Fun times.

Jim

---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

You da man, Jim!  Thanks.

-Chris

On 12/5/06, James Bedient <jbedient@...> wrote:
> I found another IBVS article containing spectral types - just 15 of
> them, so I entered them via the revision process.  Most of them need
> ASAS & NSVS entries merged, too.
>
> Fun times.
>
> Jim
>
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>
>
>
> Yahoo! Groups Links
>
>
>
>

Well, the right star, just the wrong entry.

I added a spectral type to ASAS 170633+2008.1 by mistake, intending to
revise V455 Her, which is the same star.  Moderators, can you please
fix?

Thank you,

Jim

---------------------------------------------
Jim Bedient
jbedient@...
www.bedient.us

The revision to ASAS 170633+2008.1 has been rejected.  Go ahead and
commit your revision to V455 Her, Jim.  Thanks.

-Christopher

On 12/9/06, James Bedient <jbedient@...> wrote:
> Well, the right star, just the wrong entry.
>
> I added a spectral type to ASAS 170633+2008.1 by mistake, intending to
> revise V455 Her, which is the same star.  Moderators, can you please
> fix?
>
> Thank you,
>
> Jim
>
> ---------------------------------------------
> Jim Bedient
> jbedient@...
> www.bedient.us
>
>
>
> Yahoo! Groups Links
>
>
>
>