Tue, 03/07/2023 - 20:56
Hello All,
I'd like to inform you that the long anticipated re-write of VSP is now live on the site. We tried to make the front end as similar as possible to the former VSP, but there are some minor differences. You can find a summary of these differences here:
We have tried to test the application as much as we can, but there will inevitably be a few bugs we didn't catch. If you run into any issues or think there might be a bug, please let us know, either by posting in this forum or by sending an email to webmaster@aavso.org. A big thank you to Matt Craig who volunteered a significant chunk of time to take on this re-write. It would not have been possible without him.
Thanks,
Bert Pablo
Staff Astronomer , AAVSO
Consider wide-field (900 arcmin) chart X28581AJ with BV(RI)c. About 40% of the chart is blank.
Also, there is a long-standing problem with the magnitude limit input. Initiating a scroll while in this field cases the limit to change. So if you set a limit, then scroll to print the chart, the limit will become very different. Apparently it was thought helpful to allow adjusting the magnitude by a scroll action, but that is not expected behavior. Also, if you use the back button to return to VSP from printing a chart, the magnitude limit often changes.
Hi Tom,
thanks for pointing our attention to this issue.
We are looking into it.
Cheers,
Sebastian
I'm also having trouble re-generating charts X22904BCV and X22904BCK: "Oops - looks like something went wrong"
Hi Tom,
Do you happen to recall the RA/Dec for either of those charts? I believe I've fixed the underlying issue but want to confirm that.
Thanks,
Matt Craig
Thanks for reporting these and please let us know if you find any other problem charts.
I posted a new forum topic under software, but mention it here too.
J2000.0 is still the IAU standard epoch as far as I know. All my software, telescope, solar system, etc. inputs are J2000.0 not J1015.5.
The photometry table doesn't even print what epoch the coordinates are for.
I still want J2000.0 for the VSP chart epoch and photometry tables please.
Jim DeYoung (DEY)
The positions at least are for _equinox_ J2000, but they seem to have adopted the GAIA _epoch_ of 2015.5 (i.e. where the stars are for that date). Since the proper motions are explicit in GAIA, there is no reason not to continue with both epoch and equinox 2000 --- the CDS VizieR output includes that position as part of the default output. I agree however that the non-standard epoch (which will change as further GAIA data releases appear) is not good for just about everything downstream of the data-taking. The coords, where necessary, ought simply to include the motion (milliarcsec/year is sufficient precision). Some lower limit like 150 mas/year will take care of stars with significant motion.
\Brian
The AAVSO comparison star environment is a walled garden - our star identifiers have no connection with real-world catalogs. It was evidently assumed that observers could live wholly within the VSP ecosystem without reference to externally-sourced data. I have found this not to be the case.
The only way to link a catalog ID to a AAVSO ID is through the coordinates. SIMBAD coordinates are for J2000 and they used to exactly match VSP. Now they don't.
The information in the photometry tables hasn't been changed. Positions you will find are for J2000.0. Since some of the sequences are based on APASS data and its coordinates are not very accurate, you will find some offsets and probably the difference between J2000.0 and 2015.5 won't be really significant.
But the change was meant to allow observers to see a more realistic view of the sky, since 23 years is a lot for stars with large proper motions.
We even had some red dwarf campaigns when using AAVSO charts became a nightmare due to this.
I think having stars plotted at epoch 2015.5 is much better. Maybe the header should show both J2000.0 and 2015.5 to avoid confusion.
But again: no change has been made to the comparison star J2000.0 coordinates.
Cheers,
Sebastian
Sebastian,
I can live with both epoch coordinates printed on the charts. A better solution perhaps would be to always print the current J2000.0 standard epoch position and/or allow a user specified epoch to be output in addition depending on entry of a second epoch in a new input field on the VSP chart query page. Means you would need to have that new software engineer add the coordinate transformation to the requested epoch and some reasonable data check limits.
Best regards,
Jim DeYoung (DEY)
Stars in the chart, including the variable when possible, are being displayed at J2015.5 but the coordinates displayed at the top of the chart are J2000.
I use the VSP API Http get json to load a excel spreadsheet with details of a variable star and its comparison stars - the sort order of these comparison stars has changed. The original order was in increasing magnitude value (decreasing brightness!) but now appears to make this table a random set of values based on the comparison star names in alphabetical order (I am guessing here!). Could this sort order be detemined by the same method which is documented for VSX API i.e. an additional parameter &order=n where n is 6 for what I would like to achieve. In experiments the &order is currently ignored in the VSP API?
Regards
George
Can you please post an example URL in which the order is incorrect? While the intent was only to change the chart itself, there were other parts of the code we had to touch to resolve some significant performance issues in larger fields.
Thanks,
Matt
I do not believe you can control the sort order of json and xml objects, so a user of these objects must not count on a preferred order.
I made a post a while ago in the thread https://www.aavso.org/new-vsp-api discussing how to parse xml with awareness that order in items can not be counted on.
George
I have noticed that the VSP photometry table shows the same problem so this is an example
https://app.aavso.org/vsp/photometry/?star=U+Ori&scale=E&orientation=ccd&type=photometry&fov=30.0&maglimit=16.5&resolution=150&north=up&east=left&lines=True
The magnitudes are all over the place as in appears to be in AUID order
As an experiment try with the addition &order=6
https://app.aavso.org/vsp/photometry/?star=U+Ori&scale=E&orientation=ccd&type=photometry&fov=30.0&maglimit=16.5&resolution=150&north=up&east=left&lines=True&order=6
which is supposed to put them magnitude order (according to VSP/VSX documentation?) nothing happens - the original magnitude order is just what is required in both API and online in my opinion.
For the API get request I have been using very sucessfully for years which requests the same star and shows, up to very recently, in magnitude order but now is in AUID order
https://app.aavso.org/vsp/api/chart/?format=json&fov=60&maglimit=16.5&star=U+Ori&&north=up&east=left
Regards
George
Hello
In the photometry tables generated from VSP, the color index ( B-V value) of the sequence stars is missing. In the VSP front page the following note stills remains at the lower end of the page "V and (B-V) magnitudes are always displayed.", but not longer true for (B-V). The (B-V) value was really a useful feature since it allowed to select appropiate comparision stars at a first glance based on their color index.
Hi,
We are working on fixing that, it was an unintentional change.
Matt
In looking over the code that changed, it looks like the old sort order was by label, which is not quite the same as magnitude. Image a case where the labels are 105, 101, 95, and 86.
Sorting by magnitude (call this option A) gives the order 85, 95, 101, 105.
Sorting by label, which is what I think the old code did (call this option B) gives the order 101, 105, 85, 95
I can make either of these happen -- which is the preferred option?
Thanks,
Matt
Matt:
The current (new VSP) photometry sort order is actually AUID not magnitude or label? That is a really poor choice IMO?
I vote for magnitude order (brightest to faintest) in the Photometry Table. I think it is most logical. However, are you referring to magnitude, as a number with or without the decimal point? Will this get confusing?
Therefore, I wonder if the Label order (ASCII code) is best because of historical use and because some individuals have already set up an API query/call that still looks for the Label name? I wonder what GeorgeF thinks?
(Note - Label order was sorted by ASCII code (alphanumeric) which put label numbers smaller than 100 at the bottom of the list. VPhot does this label sort and it is something I always need to explain in the VPhot course.)
Can you actually sort by magnitude without the decimal point by ignoring ASCII code and using a simple numeric sort (e.g., -10 - 250?? representing -1.0 mag to 25.0 mag)? This gets more complicated/messy than I expected! ;-)
Ken
Turns out I could just sort on the label as a number fairly easily.
Based on my limited experience, I personally think that ordering by magnitude is the most logical choice, since it would alow the user to select the most appropiate comp and check stars at a first glance, saving some effort in making our brains to process an otherwise dispersed magnitude values.
Ordering by Magnitude 8.5,9.5,10.5,11.9 etc etc is the most useful if this possible - with UK weather conditions the night sky can be hazy with high cloud and you then need the brighter comparison stars and finding these is a lot easier if they are group together at the top of the table! The really bad part about AUID order is that you could be looking through 20 or 30+ comparison stars to find the ones which suit your requirements. Of course we are talking about the V mags and there will be slight(?) variations for other filters but we need a sort order which we all find useful and up to now the everyone was using the magnitude order (even 85,95,105,119 !). Perhaps they did not realise it and how easy this logic it was making our observations.
Regards
George
I too definitely prefer ordering by magnitude.
Regards,
Damien
Just my two cents...
Ordered by magnitude gets my vote. And please bring the B-V info as well.
Clear skies,
Dennis.
Thanks to everyone who reported the issue with sort order and the missing B-V. Both changes were an inadvertent result of rewriting a particularly slow database query. It looks like the API query is returning in the same order now too.
Matt:
1. J2000 of target reported on Chart with a note about chart plotted in J2015. Works for me.
2. Photometry Table Label sorted properly by mag without decimal point. Works for me.
3. B-V column shown but not populated in three Photometry Tables I generated. Still a problem??
Ken
When I choose a D chart the dots of the stars are too big compared to each other. The faintest star is still a big dot compared to the brightest star. The lay-out of the former VSP was much better for visual observers.
Hubert:
It is disappointing that you find the charts less helpful. The objective of the revision was to make the charts cleaner, easier to interpret and more visually representative of the stars. IMHO, it is not easy to simultaneously meet all of these criteria on all of our charts. During testing, these issues were discussed at length and it was hoped that the final relative star size selection was reasonable. A lot of effort did go into the coding of the selection algorithms and the final decision.
Could you indicate the specific D Chart(s) (Target Name and Chart ID) that did not meet your needs and perhaps give some specific examples of how it did not meet them? Do other chart scales have the same problem for your visual observations? Does the addition of a DSS image overlay on the chart help your star identification at all?
Your comments are appreciated.
Ken
Hi Ken, in the new VSP the faintest stars are bigger dots than used in the previous version. If this is used in a crowed field like in Cygnus, it will give problemens. I have no problems finding the variable. It's just that I now find that the faintest stars are too big compared to the other stars. I would show it but how can I upload two charts to compare?
Just to make sure, is this an example of a new one that has faint dots that are too large: https://app.aavso.org/vsp/chart/?star=R+Del&scale=D&orientation=visual&type=chart&fov=60.0&maglimit=14.5&resolution=150&north=down&east=right&lines=True
Hi Hubert,
Thanks for the feedback -- like Ken said, an example chart would be helpful but I think I know the kind of thing you mean.
Our testing focused a lot on larger charts (3 degrees and up) because these gave us a lot of trouble in getting them to render in a reasonable amount of time, and on smaller charts (say under a degree) but I'm afraid we didn't look at a ton of examples in the intermediate range, so your feedback is especially helpful.
To be clear, this gap in our checking is on me, not the other folks who were helping out with testing.
If you want more details, read on, but feel free to skip the rest if you want.
Summary of dot size changes:
Thanks,
Matt
Hi Matt, thanks for the explanation. I pasted two charts in the message. I don't know if this is the right way. The frst is from the old VSP, the second the new one. You can see the difference.
Thanks, I sent a private message with my email address so that you can send me copies of the charts. Much appreciated, thanks!
Hi,
when I change the resolution from 150 to 250 in a 1 degree DSS chart, the result is the same: a chart 1230 x 1530 pix (opened in Photoshop). Resolution in both cases: 150 pix/inch. Seems to be a bug.
regards
Hans-Georg (PHG)
Hi All
Chart ID X28632BG is an example where all the faint stars seem to have the same dot size. Granted this is a crowded field in Sgr, however, it is difficult to use this chart as is. The F scale chart is similar although not as challenging.
Regards
Andrew
Andrew:
Does the similar size of 'all the faint stars' make pattern recognition difficult? Are you doing visual photometry or using a CCD image?
Ken
At the moment I was…
Hi Ken
At the moment I was comparing it to a CCD image.
Andrew
Visual or CCD, I said it before in a post. These charts are not usable for me beginning from the D charts. A, B and C are fine but from D and on .....
Hi
Attached is a CCD image (/sites/default/files/users/user57417/V6596%20Sgr%20CCD.JPG) which can be compared to Chart ID X28632BG. You can see it's very different certainly for the F and G scale charts.
Andrew
Andrew:
I see what you describe BUT I'm not sure that matching the 7.5' Chart with your 15' image is a good comparison. The default 7.5' chart at a default 20.5 mag limit may not be that different than the center of your image? It is just that the default mag limit of the chart shows many more existing but not visible (in your image) fainter stars.
I simply adjusted the fov and mag limit of the VSP and achieved a much better match to that of your image. The star sizes make more sense to me when that is done!?
I'm not sure the default settings of the G chart are the best choice for your scope's image? Are you expecting that the default chart scales will always match that of our images?
I might have proposed that the mag limit of the G chart be raised a bit (brighter)? However, if you identify a scale and mag limit that best matches your scope and always use it you may find a better match? This is certainly an opinion but based on some adjusting of the settings.
Comments?
Ken
Hi Ken
Thanks for that. Yes if you play with the magnitude limit you can replicate the CCD images quite well, just wasn't used to having to do that previously. I suspect the default magnitude limit of 20.5 for G scale charts is what causes the problem for me as the charts it produces, certainly in crowded fields, are unusable for me. However simply changing the limit to something like 18 solves the problem.
Andrew
Hi Ken and Andrew,
Thanks for the detailed discussion. Essentially all stars fainter than about 18th magnitude are the same size because I imposed a lower limit on the size of the dot to ensure every star present would be visible. That fails pretty badly when the limiting magnitude is fainter than 18th.
I couldn't reproduce the problematic plot you made on my testing setup, Andrew, because the my local copy of VSX isn't that up to date. This chart, in the same area of the sky, shows the same problem, though: https://app.aavso.org/vsp/chart/?star=ASAS+J175608-1716.6&scale=G&orientation=visual&type=chart&fov=7.5&maglimit=20.5&resolution=150&north=down&east=right&lines=True
Can you take a look at that and at this version, which I made by turning off the minimum radius: https://www.dropbox.com/s/yu8elqaz6axlag8/smaller-stars.png?dl=0
If this looks better I can work with Bert to get the change pushed to the AAVSO site.
Thanks,
Matt
Hi Matt
That appears much better. I haven't got a CCD image to compare it to, but it appears much more realistic to me.
Regards
Andrew
Hi Andrew,
An update to VSP just went live that should give you better star size. Would you mind taking a look when you get a chance and let us know whether it works better for you?
Thanks,
Matt
If one regenerates a chart from a chart ID, the only magnitudes reported are V and B-V, regardless of how many other passbands were specified in the original chart.
Tom
What could help here is if the user were able to specify the mix of filters to be displayed by having saved that list as a browser cookie.
If I specify that I want UBVRI then I want to get that in the photometry display when ever I get sent to VSP photometry.
George
I agree that a cookie setting would allow users to always get the same set of photometry in their tables, but would that address Tom's issue?
My impression is that Tom wants the charts to remember the filter settings so that pulling up a chart by chart ID and then clicking the photometry table link would generate the photometry table from the settings of whoever generated the chart, not necessary those of the current user.
I might have that wrong, though, so some clarification would help.
(Also, I'm not sure how to implement that since we'd need separate chart IDs for charts that are identical except for the filters requested.)
Thanks,
Matt
All the details of the chart creation are saved. Except the filter selection.
My thoughts:
So on regeneration of the chart I would opt for user saved preference, then "all filters" and lastly what it is doing now: just B & V.
When they visit the VSP chart selection page populate the filter selections and save them again when they submit in case they changed them.
What if you request by API eg https://app.aavso.org/vsp/api/chart/2164EAF/?format=xml
That appears to do All, which appropriate for a data request.
What if you come from the standard fields page https://app.aavso.org/vsd/stdfields ?
You get a chart. https://app.aavso.org/vsp/chart/?title=JL%20163&ra=2.6775&dec=-50.236111&fov=20&maglimit=16&special=std_field&all=on&north=down&east=right
And when you request the photometry you get All.
Note that the API let's you specify the filter selection. This should override any cookie setting.
George
Not only will cookies fail to deal with different users re-generating the same chart, you would need to have cookies on a per-star basis for individuals.
Also, those of us who value our online privacy clear out our cookies on a regular basis. A cookie should only apply to the current web session, not for future sessions.
If one uses the option "Should Other Variable Stars Should (sic!) Be Marked?" in fields of a few degrees, often far too many variables are marked.
In the previous version it was possible to mark only GCVS stars. I would suggest another option: to mark only other variable stars with AUID present. This would drastically reduce the number of additional variables to be printed.
Try to print a chart of 3 degrees (180') of QS Mon (mag limit 13.5) with option enabled "Should Other Variable Stars Should Be Marked?"
Hans-Georg (PHG)
In addition: In updated VSP, if one changes the magnitude limit (with the option above) most charts have different width (in x-direction) because long names (at the W/E sides) are not truncated and the chart (plus long names) is forced to fit. This also complicates the comparison of different maps with different magnitude limits and other variables printed.