From avi.chen832 at gmail.com Thu Aug 5 22:26:07 2021 From: avi.chen832 at gmail.com (Avi Chen) Date: Thu, 5 Aug 2021 22:26:07 -0400 Subject: [AstroPy] Qustion about Fits Tutorial Message-ID: Hi, I'm using the tutorial "Working with FITS-cubes" on learn.astropy. I wanted to try the tutorial on other portions of the sky. In the section of the tutorial "Download the HI Data" it says that the relevant data can be found via ftp from CDS Strasbourg, but the hyperlink goes straight to a download file. Does anyone know where on http://cdsarc.u-strasbg.fr/ I can find the data used in the tutorial? I want to try the template on other regions of the sky and I'm hoping to browse around.. Thanks so much! Best, - Avi -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.g.ginsburg at gmail.com Thu Aug 5 22:32:13 2021 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Thu, 5 Aug 2021 22:32:13 -0400 Subject: [AstroPy] Qustion about Fits Tutorial In-Reply-To: References: Message-ID: Vizier uses a journal name & volume based coding for its catalogs. The link in that tutorial is: http://cdsarc.u-strasbg.fr/vizier/ftp/cats/J/A+A/594/A116/CUBES/GAL/TAN/TAN_C14.fits The relevant text there is "J/A+A/594/A116", which you can search for on Vizier: https://vizier.u-strasbg.fr/viz-bin/VizieR?-source=J/A+A/594/A116&-to=2 That will point you to the README and list of available files: https://cdsarc.unistra.fr/viz-bin/cat/J/A+A/594/A116 which, if you go to the FTP tab, can be navigated to get the list of available cubes: https://cdsarc.unistra.fr/ftp/J/A+A/594/A116/CUBES/GAL/TAN/ (other projections are also available) On Thu, Aug 5, 2021 at 10:26 PM Avi Chen wrote: > Hi, > > I'm using the tutorial "Working with FITS-cubes" on learn.astropy. I > wanted to try the tutorial on other portions of the sky. In the section of > the tutorial "Download the HI Data" it says that the relevant data can be > found via ftp from CDS Strasbourg, but the hyperlink goes straight to a > download file. Does anyone know where on http://cdsarc.u-strasbg.fr/ I > can find the data used in the tutorial? I want to try the template on other > regions of the sky and I'm hoping to browse around.. Thanks so much! > > Best, > - Avi > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- Adam Ginsburg Assistant Professor, Department of Astronomy University of Florida, Gainesville http://www.adamgginsburg.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From avi.chen832 at gmail.com Thu Aug 5 22:53:04 2021 From: avi.chen832 at gmail.com (Avi Chen) Date: Thu, 5 Aug 2021 22:53:04 -0400 Subject: [AstroPy] Qustion about Fits Tutorial In-Reply-To: References: Message-ID: Thanks so much Adam! Can I ask one more question. Is there a way to know which portion of the sky the Tan.fits file corresponds to? For instance, if I wanted Glon from 75.0-100.0 and Glat from -10.0-10.0 which one would it be? Thanks again ? On Thu, Aug 5, 2021 at 10:32 PM Adam Ginsburg wrote: > Vizier uses a journal name & volume based coding for its catalogs. > > The link in that tutorial > is: > > http://cdsarc.u-strasbg.fr/vizier/ftp/cats/J/A+A/594/A116/CUBES/GAL/TAN/TAN_C14.fits > > The relevant text there is "J/A+A/594/A116", which you can search for on > Vizier: > https://vizier.u-strasbg.fr/viz-bin/VizieR?-source=J/A+A/594/A116&-to=2 > > That will point you to the README and list of available files: > https://cdsarc.unistra.fr/viz-bin/cat/J/A+A/594/A116 > > which, if you go to the FTP tab, can be navigated to get the list of > available cubes: > https://cdsarc.unistra.fr/ftp/J/A+A/594/A116/CUBES/GAL/TAN/ > (other projections are also available) > > > > On Thu, Aug 5, 2021 at 10:26 PM Avi Chen wrote: > >> Hi, >> >> I'm using the tutorial "Working with FITS-cubes" on learn.astropy. I >> wanted to try the tutorial on other portions of the sky. In the section of >> the tutorial "Download the HI Data" it says that the relevant data can be >> found via ftp from CDS Strasbourg, but the hyperlink goes straight to a >> download file. Does anyone know where on http://cdsarc.u-strasbg.fr/ I >> can find the data used in the tutorial? I want to try the template on other >> regions of the sky and I'm hoping to browse around.. Thanks so much! >> >> Best, >> - Avi >> _______________________________________________ >> AstroPy mailing list >> AstroPy at python.org >> https://mail.python.org/mailman/listinfo/astropy >> > > > -- > Adam Ginsburg > Assistant Professor, Department of Astronomy > University of Florida, Gainesville > http://www.adamgginsburg.com/ > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rishank2610 at gmail.com Wed Aug 11 04:53:55 2021 From: rishank2610 at gmail.com (Rishank Diwan) Date: Wed, 11 Aug 2021 14:23:55 +0530 Subject: [AstroPy] Regarding Baseline for Bayesian Block Algorithm Message-ID: Dear Members, I am using astropy.stats.babayesian_blocks to calculate flare bins in time-series fermi data. But I am not able to calculate the baseline to differentiate the flare bins and get the significance for them. Can you help me with it? Thank you Yours Sincerely, Rishank Diwan M.Sc. in Physics Department of Physics Indian Institute of Technology, Kharagpur [image: https://www.linkedin.com/in/rishank-diwan-19b47013a/] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hessman at astro.physik.uni-goettingen.de Mon Aug 23 03:24:04 2021 From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman) Date: Mon, 23 Aug 2021 09:24:04 +0200 Subject: [AstroPy] propagating coordinate errors In-Reply-To: References: Message-ID: <4C774AD6-5E59-4A77-846A-3F4646D14F83@astro.physik.uni-goettingen.de> It's wonderful to have SkyCoord, but real coordinates have errors - how does one propagate them using differentials when transforming to other representations? I haven't been able to find _any_ examples by looking at the official examples or googling and the BaseDifferential docs are .... not very helpful. Rick From adrianmpw at gmail.com Mon Aug 23 11:35:09 2021 From: adrianmpw at gmail.com (Adrian Price-Whelan) Date: Mon, 23 Aug 2021 11:35:09 -0400 Subject: [AstroPy] propagating coordinate errors In-Reply-To: <4C774AD6-5E59-4A77-846A-3F4646D14F83@astro.physik.uni-goettingen.de> References: <4C774AD6-5E59-4A77-846A-3F4646D14F83@astro.physik.uni-goettingen.de> Message-ID: Hi Rick, The most straightforward way of doing this with existing functionality is to pass Monte Carlo samples through the representation transformations. In general, if your uncertainties are, e.g., Gaussian in Spherical coordinates, they will not be Gaussian in other representations, so in most cases this is the only thing you can do. (Though if your uncertainties are very small, there are other tricks to employ...). If you say more about what exactly you want to do, I can give you some specific examples! best, - Adrian On Mon, Aug 23, 2021 at 4:17 AM Frederic V. Hessman < hessman at astro.physik.uni-goettingen.de> wrote: > It's wonderful to have SkyCoord, but real coordinates have errors - how > does one propagate them using differentials when transforming to other > representations? > > I haven't been able to find _any_ examples by looking at the official > examples or googling and the BaseDifferential docs are .... not very > helpful. > > Rick > > > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- Adrian M. Price-Whelan Flatiron Institute, NYC http://adrn.github.io (he / him) -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Mon Aug 23 11:45:30 2021 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Mon, 23 Aug 2021 17:45:30 +0200 Subject: [AstroPy] propagating coordinate errors In-Reply-To: References: <4C774AD6-5E59-4A77-846A-3F4646D14F83@astro.physik.uni-goettingen.de> Message-ID: <835DDF31-A23C-47C3-B87F-A062AF8A7E17@astro.physik.uni-goettingen.de> On 23 Aug 2021, at 5:35 pm, Adrian Price-Whelan wrote: > > The most straightforward way of doing this with existing functionality is to pass Monte Carlo samples through the representation transformations. In general, if your uncertainties are, e.g., Gaussian in Spherical coordinates, they will not be Gaussian in other representations, so in most cases this is the only thing you can do. (Though if your uncertainties are very small, there are other tricks to employ...). If you say more about what exactly you want to do, I can give you some specific examples! > Looking at e.g. how velocity components, if set, are transformed along in sc.data.differentials, would it be possible to use that mechanism for small differentials? Cheers, Derek From erik.tollerud at gmail.com Tue Aug 24 14:13:53 2021 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 24 Aug 2021 14:13:53 -0400 Subject: [AstroPy] ANN: Astropy v4.3 and v4.0.6 released Message-ID: Dear colleagues, We are very happy to announce the v4.3 release of the Astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven Python package intended to contain much of the core functionality and common tools needed for astronomy and astrophysics. It is part of the Astropy Project, which aims to foster an ecosystem of interoperable astronomy packages for Python. New and improved major functionality in this release includes: * Transformations to AltAz are now much more precise (and faster) * Improvements in making Astropy thread-safe * Performance improvements to sigma clipping * Changes in the Time and IERS leap second handling * Support for multidimensional and object columns in ECSV * Support for reading and writing tables to QDP format * Append table to existing FITS file * General masked class for Quantity and other ndarray subclasses * Configuration file improvements * Support for different solvers and bracket option in z_at_value In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/stable/whatsnew/4.3.html Instructions for installing Astropy are provided on our website, and extensive documentation can be found at: http://docs.astropy.org If you usually use pip/vanilla Python, you can do: pip install astropy --upgrade Note that this will yield astropy v4.3.1 instead of 4.3, which is expected - a significant bug reported between the 4.3 release and this announcement means that the correct version is indeed 4.3.1. If you make use of the Anaconda Python Distribution, soon you will be able update to Astropy v4.3.1 with: conda update astropy Or if you cannot wait for Anaconda to update their default version, you can use the conda-forge channel: conda update -c conda-forge astropy Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 400 people have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: https://www.astropy.org/team.html The LTS (Long Term Support) version of Astropy at the time of v4.3's release is v4.0 - this version will be maintained until the next LTS release (v5.0, scheduled for Fall 2021). v4.0.6 is the latest version, also just released. Additionally, note that the Astropy 4.x series only supports Python 3. Python 2 users can continue to use the 2.x series but it is no longer supported (as Python 2 itself is no longer supported). For assistance converting Python 2 code to Python 3, see the Python 3 for scientists conversion guide. If you use Astropy directly for your work, or as a dependency to another package, please remember to acknowledge it by citing the appropriate Astropy paper. For the most up-to-date suggestions, see the acknowledgement page, but as of this release the recommendation is: This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2013, 2018). We hope that you enjoy using Astropy as much as we enjoyed developing it! Erik Tollerud v4.3 Release Coordinator on behalf of The Astropy Project https://www.astropy.org/announcements/release-4.3.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From taldcroft at gmail.com Tue Aug 24 17:10:31 2021 From: taldcroft at gmail.com (Tom Aldcroft) Date: Tue, 24 Aug 2021 17:10:31 -0400 Subject: [AstroPy] [astropy-dev] ANN: Astropy v4.3 and v4.0.6 released In-Reply-To: References: Message-ID: Hi all, With apologies for the extra mail, but I'd like to take this opportunity to announce one additional feature that was inadvertently left off the What's New in 4.3 page: * Astropy Table columns can now be selectively shown or hidden from view. Please see: https://docs.astropy.org/en/v4.3.1/table/access_table.html#hiding-columns Thanks, Tom On Tue, Aug 24, 2021 at 2:14 PM Erik Tollerud wrote: > Dear colleagues, > > We are very happy to announce the v4.3 release of the Astropy package, > a core Python package for Astronomy: > > http://www.astropy.org > > Astropy is a community-driven Python package intended to contain much > of the core functionality and common tools needed for astronomy and > astrophysics. It is part of the Astropy Project, which aims to foster > an ecosystem of interoperable astronomy packages for Python. > > New and improved major functionality in this release includes: > > * Transformations to AltAz are now much more precise (and faster) > * Improvements in making Astropy thread-safe > * Performance improvements to sigma clipping > * Changes in the Time and IERS leap second handling > * Support for multidimensional and object columns in ECSV > * Support for reading and writing tables to QDP format > * Append table to existing FITS file > * General masked class for Quantity and other ndarray subclasses > * Configuration file improvements > * Support for different solvers and bracket option in z_at_value > > In addition, hundreds of smaller improvements and fixes have been > made. An overview of the changes is provided at: > > http://docs.astropy.org/en/stable/whatsnew/4.3.html > > Instructions for installing Astropy are provided on our website, and > extensive documentation can be found at: > > http://docs.astropy.org > > If you usually use pip/vanilla Python, you can do: > > pip install astropy --upgrade > > Note that this will yield astropy v4.3.1 instead of 4.3, which is > expected - a significant bug reported between the 4.3 release and this > announcement means that the correct version is indeed 4.3.1. > > If you make use of the Anaconda Python Distribution, soon you will be > able update to Astropy v4.3.1 with: > > conda update astropy > > Or if you cannot wait for Anaconda to update their default version, > you can use the conda-forge channel: > > conda update -c conda-forge astropy > > Please report any issues, or request new features via our GitHub > repository: > > https://github.com/astropy/astropy/issues > > Over 400 people have contributed code to Astropy so far, and you can > find out more about the team behind Astropy here: > > https://www.astropy.org/team.html > > The LTS (Long Term Support) version of Astropy at the time of v4.3's > release is v4.0 - this version will be maintained until the next LTS > release (v5.0, scheduled for Fall 2021). v4.0.6 is the latest version, > also just released. > > Additionally, note that the Astropy 4.x series only supports Python 3. > Python 2 users can continue to use the 2.x series but it is no longer > supported (as Python 2 itself is no longer supported). For assistance > converting Python 2 code to Python 3, see the Python 3 for scientists > conversion guide. > > If you use Astropy directly for your work, or as a dependency to > another package, please remember to acknowledge it by citing the > appropriate Astropy paper. For the most up-to-date suggestions, see > the acknowledgement page, but as of this release the recommendation > is: > > This research made use of Astropy, a community-developed core Python > package for Astronomy (Astropy Collaboration, 2013, 2018). > > We hope that you enjoy using Astropy as much as we enjoyed developing it! > > Erik Tollerud > v4.3 Release Coordinator > on behalf of The Astropy Project > > https://www.astropy.org/announcements/release-4.3.html > > -- > You received this message because you are subscribed to the Google Groups > "astropy-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to astropy-dev+unsubscribe at googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/astropy-dev/CAARXUwVEPtHB3ZPX4z%2Bm-vXVrfg4exRdKBLWm9WQpZNecUorQw%40mail.gmail.com > > . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hessman at astro.physik.uni-goettingen.de Thu Aug 26 02:01:07 2021 From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman) Date: Thu, 26 Aug 2021 08:01:07 +0200 Subject: [AstroPy] propagating coordinate errors In-Reply-To: References: Message-ID: <83A9BE0F-EBD1-4A02-B7FB-63CCFE2C50B5@astro.physik.uni-goettingen.de> Of course I can sample the coordinates using the mostly small errors, but I'm converting zillions of Ra,Dec,pmRA,pmDEC,RV,dist data points to Galactocentric (i.e. Cartesian) coordinates where the non-Gaussian effects are minimal, so it would be REALLY HANDY not to have to sample. From a sense of what astropy handling should feel like, it would be nice to have something like.... from astropy import unit as u from astropy.coordinates import SkyCoord, Galactocentric s = SkyCoord (ra=11.*u.deg, dec=22.*u.deg, distance=33.*u.pc, radial_velocity=44.*u.km/u.s,....) # CREATE COVARIANCE FOR THIS COORDINATE IN THIS COORDINATE SYSTEM cov = s.cov (err_ra=2.*u.arcsec, err_dec=2.*u.arcsec, ....) # MISSING ERRORS ARE ASSUMED = 0 # TRANFORM e.g. TO GALACTOCENTRIC COORDINATES g = s.transform_to (Galactocentric) # GET COVARIANCE BASED ON THE OTHER COVARIANCE gcov = s.cov(cov) # ACCESS THE TRANFORMED COVARIANCE BY NAME print (f'v_x={g.v_x} +/- {np.sqrt(gcov['v_x']['v_x'])}') This would be infinitely better than having to MC a zillion measurements (e.g. Gaia!), even if it means that the final errors are just estimates. Rick >> It's wonderful to have SkyCoord, but real coordinates have errors - how >> does one propagate them using differentials when transforming to other >> representations? >> >> I haven't been able to find _any_ examples by looking at the official >> examples or googling and the BaseDifferential docs are .... not very helpful. > From: Adrian Price-Whelan > > Hi Rick, > > The most straightforward way of doing this with existing functionality is > to pass Monte Carlo samples through the representation transformations. In > general, if your uncertainties are, e.g., Gaussian in Spherical > coordinates, they will not be Gaussian in other representations, so in most > cases this is the only thing you can do. (Though if your uncertainties are > very small, there are other tricks to employ...). If you say more about > what exactly you want to do, I can give you some specific examples! > > best, > - Adrian > From: Derek Homeier > > On 23 Aug 2021, at 5:35 pm, Adrian Price-Whelan wrote: >> >> The most straightforward way of doing this with existing functionality is to pass Monte Carlo samples through the representation transformations. In general, if your uncertainties are, e.g., Gaussian in Spherical coordinates, they will not be Gaussian in other representations, so in most cases this is the only thing you can do. (Though if your uncertainties are very small, there are other tricks to employ...). If you say more about what exactly you want to do, I can give you some specific examples! >> > Looking at e.g. how velocity components, if set, are transformed along in sc.data.differentials, > would it be possible to use that mechanism for small differentials? > > Cheers, > Derek From gabrielperren at gmail.com Mon Aug 30 10:24:33 2021 From: gabrielperren at gmail.com (Gabriel Perren) Date: Mon, 30 Aug 2021 11:24:33 -0300 Subject: [AstroPy] Vizier projection Message-ID: Hi everyone, I'm trying to reproduce the projection applied by Vizier to obtain the (_x, _y) columns. According to what is stated here http://cdsarc.u-strasbg.fr/vizier/vizHelp/xy.htx, these columns are the *arc projection* of the `(RA, DE)` coordinates. I'm trying to reproduce these values based on the equations shown in the above link, but I can't seem to get the proper results. See for example the attached image with a queried region of 0.2 deg length around the center `(100, -80)` . The plot to the left are the `(RA, DE)` coordinates, the middle plot are the projected `(_x, _y)` positions by Vizier, and the right plot my attempts to reproduce these last values (the code is below, test.dat file here: https://justpaste.it/623lj) What am I doing wrong? And, can astropy apply this projection? I've also posted this question to SO here: https://stackoverflow.com/q/68985179/1391441 Cheers, Gabriel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zuGeb.png Type: image/png Size: 51968 bytes Desc: not available URL: From ejensen1 at swarthmore.edu Mon Aug 30 13:26:38 2021 From: ejensen1 at swarthmore.edu (Eric L. N. Jensen) Date: Mon, 30 Aug 2021 13:26:38 -0400 Subject: [AstroPy] Vizier projection In-Reply-To: References: Message-ID: <4C246463-2C53-4A93-A23F-E7DA8015934F@swarthmore.edu> Hi Gabriel, The main reason your RA,Dec plot looks different from the other plots is that 1 degree of Right Ascension is not (except at the equator) 1 degree on the sky. The difference is especially noticeable when you are near the poles, as in this case. It?s exactly analogous to latitude and longitude on the Earth - as you near the poles, the longitude lines converge so that one degree of longitude is a lot less distance on the surface of the Earth than it is at the equator. The correction factor is to multiply by the cosine of the other coordinate. So for example if you plot RA*cos(Dec) as your X coordinate and Dec as your Y coordinate, you should get a plot that is 0.2 x 0.2 degrees, and which looks a lot like the _x, _y plot (but without the mean value subtracted). In a small field like this simply subtracting the mean will get you something that?s pretty close to the correct _x, _y values, except that it doesn?t take into account the curvature of the celestial sphere. A more correct way to do it would be to convert each of your data points to a SkyCoord in astropy, and also to make a SkyCoord for your field center coords. Then you could find coord1.separation(coord2) to get the angular distance between any two points. SkyCoord docs are here: https://docs.astropy.org/en/stable/coordinates/index.html and docs on separations are here: https://docs.astropy.org/en/stable/coordinates/matchsep.html Hope this helps, Eric > On Aug 30, 2021, at 10:24 AM, Gabriel Perren wrote: > > Hi everyone, > > I'm trying to reproduce the projection applied by Vizier to obtain the (_x, _y) columns. According to what is stated here http://cdsarc.u-strasbg.fr/vizier/vizHelp/xy.htx , these columns are the *arc projection* of the `(RA, DE)` coordinates. > > I'm trying to reproduce these values based on the equations shown in the above link, but I can't seem to get the proper results. See for example the attached image with a queried region of 0.2 deg length around the center `(100, -80)`. > > The plot to the left are the `(RA, DE)` coordinates, the middle plot are the projected `(_x, _y)` positions by Vizier, and the right plot my attempts to reproduce these last values (the code is below, test.dat file here: https://justpaste.it/623lj ) > > What am I doing wrong? And, can astropy apply this projection? > > I've also posted this question to SO here: https://stackoverflow.com/q/68985179/1391441 > > Cheers, > Gabriel > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Mon Aug 30 14:01:30 2021 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Mon, 30 Aug 2021 20:01:30 +0200 Subject: [AstroPy] Vizier projection In-Reply-To: <4C246463-2C53-4A93-A23F-E7DA8015934F@swarthmore.edu> References: <4C246463-2C53-4A93-A23F-E7DA8015934F@swarthmore.edu> Message-ID: On 30 Aug 2021, at 7:26 pm, Eric L. N. Jensen wrote: > > The correction factor is to multiply by the cosine of the other coordinate. So for example if you plot RA*cos(Dec) as your X coordinate and Dec as your Y coordinate, you should get a plot that is 0.2 x 0.2 degrees, and which looks a lot like the _x, _y plot (but without the mean value subtracted). > > In a small field like this simply subtracting the mean will get you something that?s pretty close to the correct _x, _y values, except that it doesn?t take into account the curvature of the celestial sphere. > Just from visually comparing your middle and right plots the results from your implementation of the rotation matrix are looking quite identical to the Vizier columns, Gabriel ? except the scales are smaller by a factor ~60, or more likely, 180/pi. You are plotting the output from np.arccos(u) * ? which will be in radians again, but the Vizier _x, _y are probably in degrees, just as the coordinates themselves. > A more correct way to do it would be to convert each of your data points to a SkyCoord in astropy, and also to make a SkyCoord for your field center coords. Then you could find coord1.separation(coord2) to get the angular distance between any two points. > Yes, coord1.separation(coord2) * [np.cos(coord1.position_angle(coord2)), np.sin(coord1.position_angle(coord2))] should produce the same [x, y] results, but note that this operation is not commutative ? if you exchange the centre-of-field coord and object coord, you will not get the same (rsp. exact negative) offset, since the cos(dec) term is used from the first position. HTH, Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabrielperren at gmail.com Mon Aug 30 16:11:12 2021 From: gabrielperren at gmail.com (Gabriel Perren) Date: Mon, 30 Aug 2021 17:11:12 -0300 Subject: [AstroPy] Vizier projection In-Reply-To: References: <4C246463-2C53-4A93-A23F-E7DA8015934F@swarthmore.edu> Message-ID: You are right Derek, it was just the conversion factor back to degrees. Thank you! El lun, 30 de ago. de 2021 a la(s) 15:02, Derek Homeier ( derek at astro.physik.uni-goettingen.de) escribi?: > On 30 Aug 2021, at 7:26 pm, Eric L. N. Jensen > wrote: > > > The correction factor is to multiply by the cosine of the other > coordinate. So for example if you plot RA*cos(Dec) as your X coordinate > and Dec as your Y coordinate, you should get a plot that is 0.2 x 0.2 > degrees, and which looks a lot like the _x, _y plot (but without the mean > value subtracted). > > In a small field like this simply subtracting the mean will get you > something that?s pretty close to the correct _x, _y values, except that it > doesn?t take into account the curvature of the celestial sphere. > > Just from visually comparing your middle and right plots the results from > your implementation of the rotation matrix are looking quite identical to > the Vizier columns, Gabriel ? except the scales are smaller by a factor > ~60, > or more likely, 180/pi. You are plotting the output from np.arccos(u) * ? > which will be in radians again, but the Vizier _x, _y are probably in > degrees, > just as the coordinates themselves. > > A more correct way to do it would be to convert each of your data points > to a SkyCoord in astropy, and also to make a SkyCoord for your field center > coords. Then you could find coord1.separation(coord2) to get the angular > distance between any two points. > > Yes, coord1.separation(coord2) * [np.cos(coord1.position_angle(coord2)), > np.sin(coord1.position_angle(coord2))] > > should produce the same [x, y] results, but note that this operation is > not commutative ? > if you exchange the centre-of-field coord and object coord, you will not > get the same > (rsp. exact negative) offset, since the cos(dec) term is used from the > first position. > > HTH, > Derek > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent.michel at astro.unistra.fr Tue Aug 31 04:12:54 2021 From: laurent.michel at astro.unistra.fr (Laurent Michel) Date: Tue, 31 Aug 2021 10:12:54 +0200 Subject: [AstroPy] accessing raw astropy.io.votable.tree.Resource content Message-ID: <11bbe985-f547-bf73-3cbb-faeece844b4c@astro.unistra.fr> Hello, In the frame the VO data modeling efforts, I'm exercising the annotation of VOTable resources with data model meta-data. These annotations are XML pieces matching their own schema. For doing this without touching the VOTable schema, the annotations are enclosed in a Resource of type "meta". The VOTable structure looks like this: <==== My DM stuff ====> This approach has been validated by using standard XML parsers and validators and I'm now investigating a possible connection with Astropy. For this, I need to be able to get the content of such a resource by using the astropy.io.votable API. My problem is that I do not know how to get that stuff as an XML DOM or even as a string either. I would like to do something like: votable = parse(votable_path) for resource in votable.resources: if resource.type == "results": for sub_resource in resource.resources: if sub_resource.type == "meta": print("here is my DM stuff") >>> annotation_content = sub_resource.content() Does anyone know a way to get the raw content of a resource? Laurent -- jesuischarlie/Tunis/Paris/Bruxelles/Berlin Laurent Michel SSC XMM-Newton T?l : +33 (0)3 68 85 24 37 Fax : +33 (0)3 )3 68 85 24 32 Universit? de Strasbourg Observatoire Astronomique 11 Rue de l'Universit? F - 67200 Strasbourg