Changes between Version 1 and Version 2 of pstamp_web_interface_features_2012_09

Timestamp:

Sep 4, 2012, 7:58:27 AM (14 years ago)

Author:

bills

Comment:

--

pstamp_web_interface_features_2012_09

@@ +1 @@
+Proposed Postage Stamp User Interface 2012-09-04
 {{{
 The PS1 software team is finally applying resources to produce a good interactive
-inteface to the IPP postage stamp server. This will be included as part of the PS1 SCI (term)
+interface to the IPP postage stamp server. This will be included as part of the PS1 SCI (terminology)
 interface along side PSPS. 
 
@@ -21 +22 @@
 specification does not provide very complete set of selectors.
 
-In this document we propose splitting many of those functions off.
-
-In the end it changes from a "fire and hope" system, to a more controlled user managed system.
+In this document we propose splitting many of those functions off from request specification.
+In particular request creation and submission can optionally be done in two steps. 
+ 1. Ask the system what images are available that satisfy selection parameters
+ 2. Select which images from the set returned are to have stamps extracted and submit
+ 
+In the end the experience changes from a "fire and hope" system, to a more controlled user managed system.
 
 Review of the Postage Stamp Interface
@@ -94 +98 @@
 
     Static Sky and Sky Calibration - Performs photometry and astrometric correction to stacked images
-        including extended source measurments. These results are imported into PSPS but for more rapid
-        turn around and easy association with images these results should be avialable through the pstamp server.
+        including extended source measurements. These results are imported into PSPS but for more rapid
+        turn around and easy association with images these results should be available through the pstamp server.
 
     Chip Background Stage - Certain images undero further processing to remove the background correction 
@@ -105 +109 @@
 
     Background restored stacks - For analysis of large extended objects the background correction is
-    problematic. It is a requirement to the IPP to make avaliable through the postage stamp server
+    problematic. It is a requirement to the IPP to make avalable through the postage stamp server
     stack images with the background restored. A project has been started to implement the 
     background restoration.
@@ -111 +115 @@
 Suggested New user interface
 ----------------------------
-The selection by stage makes perfect sense for the implementation but requires some knowlege of the
-workings of the IPP. The IPP terminolgy is somewhat different than that used by PSPS and many users
-are not familar with it. We assert here that they shouldn't need to be.
-
-The inteface should be presented as a series of choices which more reflect the nature of the 
+The selection by stage makes perfect sense for the implementation but requires some knowledge of the
+workings of the IPP. The IPP terminology is somewhat different than that used by PSPS and many users
+are not familiar with it. We assert here that they shouldn't need to be.
+
+The interface should be presented as a series of choices which more reflect the nature of the 
 underlying data than the architecture of the IPP
 
@@ -161 +165 @@
 Now that PSPS is being loaded with more PSPS data this problem is relieved somewhat. However
 given inevitable the time lag between the exposures and frames information that PSPS does not currently
-have is needed to select recent data efficeintly.
-
-Given the vast data set of pan starrs selection by coordinates has it's problem. Asking for all chip
-images for a spot in one of the medium deep fields is easy to do and probably not what a user
-really wants.
-
-Also frames have been procssed multiple times.  The IPP has no notion of what the right set of
-runs should be "released" to end users. A solution to this problem has been proposed. In this
+have is needed to select recent data efficiently.
+
+Given the vast data set of PAN Starrs by coordinates has its problems. Asking for all chip
+images for a spot in one of the medium deep fields is easy to do, will return thousands of
+images, and is probably not what a user really wants.
+
+Also frames have been processed multiple times.  The IPP has no notion of what the right set of
+runs should be "released" to end users for a given exposure. A solution to this problem has been proposed
+(document in press LINK). In this
 document we will assume that those features will be available.
 
@@ -175 +180 @@
 It is desirable to be able to preview what the results of a given set of requests will include.
 In the current interface this is problematic because this information is obtained by parsing
-the request file which is an extremely inefficent operation.
+the request file which is an extremely inefficient operation.
 
 Since the new UI is inside a "database environment"  we have an opportunity to improve this
@@ -205 +210 @@
 Stamp Size
     pixels
-    arcseconds
+    arc seconds
     entire image
 
@@ -219 +224 @@
 
 This is a new concept which requires some work on the IPP side. It should probably eventually
-default to the version in PSPS database for a given survey but at the current time this is too 
+default to the latest version in PSPS database for a given survey but at the current time this is too 
 restrictive as it hides much of the data.
     
@@ -302 +307 @@
 and skycell
 
-QUESTION: One feature that might be interesting is to find the stacks that a particular frame is included
+NOTE: upon further reflection, this funcion could be handled simply by enhancing the table skycalResults which gets updated
+when psastro gets run on the skycell and could be updated when the data is exported to PSPS.
+
+QUESTION: One feature that might be interesting is to find the stacks that a particular single frame is included
 in. Currently this information is not availalble from the PSPS or postage stamp server. It can be
 derived from the IPP database. Is this useful?
@@ -321 +329 @@
     Unconvolved images
 
-Processing
+Interface Between Web Interface and postage stamp server
+--------------------------------------------------------
+
+The user interface will be implemented as part of SCI which from the user point of view is part of PSPS.
+(Need name for this component)
+
+Image listing, stamp extraction, and request status reporting will be performed by the IPP.
+
+An set of communication interfaces will be developed that allow these systems to communicate. On the IPP
+side this will be a simple set of "commands" that are triggered by http requests from the PSPS side.
+
+The following sections briefly outline the commands
+
+List PSTAMP target images
+-------------------------
+A set of coordinates and other parameters are submitted. The postage stamp server performs *efficient*
+lookups into the IPP database tables and returns a set of images that meet the selection criteria.
+
+The information returned will be sufficient to provide an informative presentation to the user and
+the means to submit an efficient postage stamp request (byid). One informative piece of information
+could be flags that indicate whether the target is available on disk for immediate stamp extraction
+or will require regeneration (update processing)
+
+
+Submit Request
+--------------
+Once the user has selected the target images the UI (wrong term) will submit a request table (or equivalent)
+to the server for processing.
+
+Request Status
+--------------
+Will return the status for a particular request
+
+Job Status
 ----------
-
+Will return the status of particular job(s)
+
+Request Control
+---------------
+Cancel job
+Cancel request
+etc
+
+When complete the results will be placed on a particular IPP data store product where the UI can present
+to the users as appropriate