Index: trunk/doc/release.2015/ps1.dataproducts/dataproducts.tex =================================================================== --- trunk/doc/release.2015/ps1.dataproducts/dataproducts.tex (revision 41397) +++ trunk/doc/release.2015/ps1.dataproducts/dataproducts.tex (revision 41398) @@ -1,3 +1,4 @@ -\documentclass[preprint2]{emulateapj} +% \documentclass[preprint2]{emulateapj} +\documentclass[iop,floatfix]{emulateapj} %% EAM 2019.08.26 : I am starting edits based on the comments I sent to HAF last month @@ -241,5 +242,24 @@ \section{Background} \label{sec:background} -The Pan-STARRS Project teamed with Alex Szalay's database development group at The Johns Hopkins University (JHU) to undertake the task of providing a publicly accessible hierarchical database for \PS\ \citep{Heasley2008}. The JHU team was the major developer of the Sloan Digital Sky Survey (SDSS) public database \citep{Thakar2003}, and it was an early goal of the Pan-STARRS team to reuse as much of the existing software as possible. However, for a number of reasons including the much larger size of the \PS\ dataset, the wide variety of image and measurement types and the importance of temporal information, major changes to the code base were required. Like the SDSS database, the database implementation for \PS\ is based on the Microsoft SQL Server product line, with supporting code forked from the SDSS Catalog Archive Server Jobs System (CasJobs). Staying with SQL Server allows the use of a wealth of software developed for SDSS, including the Hierarchical Triangular Mesh tools \citep{Szalay2007}. The system developed for \PS\ is called the {\em Published Science Products Subsystem}, or PSPS \citep{Heasley2006}. + +The Pan-STARRS Project teamed with Alex Szalay's database development +group at The Johns Hopkins University (JHU) to undertake the task of +providing a publicly accessible hierarchical database for +\PS\ \citep{Heasley2008}. The JHU team was the major developer of the +Sloan Digital Sky Survey (SDSS) public database \citep{Thakar2003}, +and it was an early goal of the Pan-STARRS team to reuse as much of +the existing software as possible. However, for a number of reasons +including the much larger size of the \PS\ dataset, the wide variety +of image and measurement types and the importance of temporal +information, major changes to the code base were required. Like the +SDSS database, the database implementation for \PS\ is based on the +Microsoft SQL Server product line, with supporting code forked from +the SDSS Catalog Archive Server Jobs System (CasJobs). Staying with +SQL Server allows the use of a wealth of software developed for SDSS, +including the Hierarchical Triangular Mesh tools \citep{Szalay2007}. +The system developed for \PS\ is called the {\em Published Science + Products Subsystem}, or PSPS \citep{Heasley2006}. +\note{define hierarchical, note relational} + %(SDSS) public database \citep{Thakar2003}, and it is useful to reuse as much of the software developed for the SDSS as possible. However, due @@ -266,17 +286,21 @@ This paper covers multiple data releases. The first \PS\ data release -(DR1, Dec 2016) covers the 3$\pi$ \ippstage{stack} images and the static -sky catalog. The DR1 image products are deep stacked images -along with ancillary data including signal, masks, variance, and -number maps. The DR1 catalog data products available from the PSPS -include the PS1 static sky 3$\pi$ catalog. Source properties are -organized into several tables, as described in -Table~\ref{table:pspstables}; only tables referring to the static -results, without time domain information, are included in DR1. - -Data Release 2 (DR2, Jan 2019), adds more of the PS1 image products +(DR1, \textadd{database opened to public in} Dec 2016) covers the 3$\pi$ +\ippstage{stack} images and the static sky catalog. The DR1 image +products are deep stacked images along with ancillary data including +signal, masks, variance, and number maps. The DR1 catalog data +products available from the PSPS include the PS1 static sky 3$\pi$ +catalog. Source properties are organized into several tables, as +described in Table~\ref{table:pspstables}; only tables referring to +the static results, without time domain information, are included in +DR1. + +Data Release 2 (DR2, \textadd{database opened to public in} Jan 2019), adds more of the PS1 image products from the 3$\pi$ survey, including the single epoch \ippstage{warp} images and their ancillary data, such as signal, masks, and variance maps. DR2 provides the \ippdbtable{Detection} tables and \ippdbtable{Forced*} +\footnote{\textadd{In this article, we refer to groups of tables with the same + base name using the file ``glob'' convention where, e.g., \ippdbtable{Forced*} refers + to a collection of tables starting with \ippdbtable{Forced}.}} tables, containing the single epoch source detections and the forced photometry. DR2 also contains numerous improvements to the data @@ -1609,6 +1633,6 @@ \bibliographystyle{apj} -%\bibliography{dataproducts}{} -\input{dataproducts.bbl} +\bibliography{dataproducts}{} +%\input{dataproducts.bbl} \appendix Index: trunk/doc/release.2015/ps1.dataproducts/report.v0.txt =================================================================== --- trunk/doc/release.2015/ps1.dataproducts/report.v0.txt (revision 41398) +++ trunk/doc/release.2015/ps1.dataproducts/report.v0.txt (revision 41398) @@ -0,0 +1,141 @@ +This paper, on the whole is well-written, useful, and worthy of +Publication in ApJS. However, some minor revisions should be performed +before final acceptance. Based on the publication dates of the other +Pan-STARRS1 papers listed in the introduction, and on other clues in +the paper itself, it appears this paper was originally written +c. 2016, and subsequently revised, but additional revisions are needed +to bring this paper fully up-to-date. + +Issues with the substance of the paper +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Not required, just curious: Is there any special reason why this paper is being +submitted so much later than other papers in this set? + +>> All paper were delayed by the effort to produce DR2 and were + submitted only about 9 months before this article. The change of + project by the first author further delayed this paper. + +* Page 2, 1st paragraph: I understand the definition of a hierarchical database, +but that might be apparent to the average reader. A one-sentence definition +would be appropriate here. Also, even though the database is hierarchical, +it is also still a *relational* SQL database, so that should be mentioned as well. + +>> TBD + +* Page 2, Section 3: The release dates for DR1 and DR2 are mentioned here. +Were the databases available to the public on exactly those dates, or was there +any delay? For example, were DR1 *files* released in December 2016, but +the database was not ready until later? + +>> These were dates when the PSPS DB was opened to the public (added note in text) + +* Page 3, 1st line: Not all readers may be familiar with the glob-like notation +for sets of tables, e.g. Forced*. It might be useful to explain this notation +along with the other typographical conventions listed at the end of Section 1. + +>> added a footnote to explain this nomenclature + +* Page 3, Section 4: It would be more appropriate to use https instead of http. +In general, given that this paper was likely originally written several years +ago, all URLs in the paper should be re-checked for accuracy, and replace +http with https wherever that changeover has been made. + +>> TBD + +* Page 6, Section 5.1.6, last paragraph: Has the reconstruction of +difference images been demonstrated and tested? Please provide a +reference or give an example in the sample queries appendix. + +>> TBD + +* Page 10, Section 6.5: Isn't it Simple Object Access? Please provide a +reference and/or URL for SOAP. + +>> TBD + +* Page 19, Section 7.7: I understand the reason for using a number such as +-999 instead of the SQL NULL value. However the reference given is to the +EDR version of SDSS SkyServer, which was about 20 years ago. There must be +a published paper that describes this reasoning by now. Also the SkyServer +URL itself may well be invalid at this point, or the quoted text may have +changed. Please provide a reference to a published paper. The SkyServer +developers can probably assist with that. + +>> TBD + +* Page 21, Section 8.1.1: What total area of the sky is affected by the polar +astrometry problem (a fraction of 3pi is acceptable)? This may well be +described in Paper IV, but it's worth including a single sentence here. + +* Appendix, Table Schema: The authors should detail how they ensure that all +the table and column descriptions are accurate. For example, what automation, +if any, is used to convert SQL table definitions into these LaTeX tables? + +SQL Examples +~~~~~~~~~~~~ + +These examples are useful. I created a MAST account and ran all of the +SQL examples in this section. All of them worked, but I have some +suggested revisions. + +* It is not clear from this section which specific context to use. I used DR2. + +A particular database context should be explicitly mentioned and some names +should be checked for consistency with that context. You could also state +that the queries work in both DR1 and DR2, but in that case, expected results +should be included for both DR1 and DR2. + +* Example 1: You should state that using COUNT instead of COUNT_BIG in this +example will not simply return an invalid value, but actually throw +an arithmetic overflow exception. + +* Example 2: This query returned 3868 rows in DR2, not 3867. + +* Example 4: This query returned 748 objects in DR2, not 747. + +* Example 5: This query returned 1806 objects in DR2, not 1805. + +* Example 9: Most of the objects selected have -999 for gMeanPSFMag. +Is this expected? + +* Example 10: The name of the MyDB table implies DR2. Again, choose a specific +context or rename to be data-release agnostic. + +* Example 12: Is there a reason the MyDB table name is enclosed in brackets in +one example and not the other? Also the '_PS1' name doesn't seem to be +consistent with the apparent DR2 context. + +Spelling, Typos, etc. +~~~~~~~~~~~~~~~~~~~~~ + +These may be taken care of by the editors, but I have noted these to assist +revision process. + +* In general: Hawaii or Hawai'i? + +* In general: Check terms like 'Section', 'Table', 'Figure' (vs. 'Fig') for +consistency. + +* In general: Spell Sérsic consistently throughout the paper. + +* In general: Choose a single notation for RA (RA vs. R.A.). + +* Page 1, 1st paragraph: "perform as set of astronomical" -> "as a set". + +* Page 2, Table 1: There seem to be several different quotation conventions in +the paper, e.g. `Release'. Elsewhere double quotes are used. + +* Page 2, Table 1: "Tessellation Type" -> "TessellationType" + +* Page 5, Section 5.1.4: in the description of SDSS apertures, double prime +(') notation may be more compact than 'arcsec' repeated many times. +In general it might be best to settle on a single notation for arcsec, since +both notations are used in the paper. + +* Page 10: "csv, FITS or xml"; CSV and XML are acronyms just like FITS, so the +same typography should be used. + +* Page 21, Section 8.1.1: "This issues" -> "This issue". + +* Page 22, Section 9: Use official IAU designation for Oumuamua.