Architecture discussion

Deployment Guide

See AuScopePortalGeotransectsDeployment

Draft ideas

We have:

• Point data from the actual line (7400 points in the sample line)
• Pmagery - high and low res, two different products. (4 images in total)
• SegY data for each line
• A collection of transects all which should be visible to the user.

Proposed demonstration solution.

• File directory structure for repository (not real linked repository)
• Pointers for all file resources stored in our registry all linked back to the lineNum#

Whats wrong with that?

• Points on a line a feature?
  • Simple consumption of 'show me whats available' becomes numerous requests.
  • Is the detail about the points on the line actually relevant?
• Lines are 'features'?
  • Complex geom may be ugly to convert to KML (especially at various zoom levels)
  • Loss of detail about points on a line.

Registry lookups

• Current registry options (geonetwork) would require convention - not standards - to piece it together, workflow would exist in documentation, not obvious to next user. Portal acting as a broker - how much intelligence should it contain?

Proposed workflow:

• User adds the Geotransects known portal type to interface.
• The lines are displayed (pictorial summaries of the lines - a combined layergroup via WMS?)
• User queries line
• Point data for click is displayed, along with registry lookups for low res imagery, links to the highres, and segy. Also a link for all point data for that line.

Violates the multi line download capability.

Proposed design 2010-08-19

Architecture

The proposed architecture involves creating a dedicated 'Geotransect Web Service' that will act as a domain specific registry of all supporting files for a line (SegY files, stacked/interpolated/migrated seismic section images).The actual feature database will have supporting table(s) that contains the publicly accessable URL's referenced by line ID, this way the 'raw data' is responsible for referencing the locations of any supporting files.

Geoserver will also be referencing the raw feature data to serve a WMS layer representing the geotransect lines. The lines themselves (whilst technically a feature) are far too complex to serve and visualize via standard WFS.

The proposed file store is the AuScope grid share of the iVEC PB store. This is share is being used successfully by Geodesy and is known safe bet. GA has said it is OK for us to do this.

Geotransect Web Service

The web service will just be the 'public face' for the raw data's supporting file list. It will provide the following functions via HTTP...

//These objects will be commonly returned as part of a response
JSONObject - Result {
    success   : Set to true/false depending on whether the overall request succeeded/failed
    msg       : [Optional] A human readable string describing the success/failure 
    code      : [Optional] A Number code that distinguishes between various failures (function specific)
}

//Represents the seismic
JSONObject - SeismicSection {
    lineID    : The ID of the line that this section represents
    dpi       : A number representing the DPI of the seismic section 
    travelTime: The maximum travel time of the sound wave (in seconds) used in the creation of this seismic section
    type      : one of the following strings ['stacked', 'migrated', 'interpreted']
    url       : The fully qualified URL where this section can be retrieved from
}

JSONObject - SegY {
    lineID    : The ID of the line that this section represents
    travelTime: The maximum travel time of the sound wave (in seconds) used in the creation of this dataset
    type      : one of the following strings ['stacked', 'migrated']
    url       : The fully qualified URL where this segy data can be retrieved from.
}

URL: ./getSeismicSections.json
Overview
    Gets a (possibly filtered) list of all seismic sections. If an optional parameter is specified
    then the result will contain all sections which match that parameter.

    eg: Specifying dpi=150 and type=migrated will return every section that has a DPI of 150 and type of 'migrated'
Parameters:
    lineID     [Optional] //The ID of the line you wish to request a seismic section for
    dpi        [Optional] //The DPI (as a number) to filter by
    type       [Optional] //The type of the image to filter by (one of ['stacked', 'migrated', 'interpreted'])
    travelTime [Optional] //The maximum travel time of the sound wave in seconds (as a number) to filter by.
Response:
    JSON encoded object (as a String)    
    {
       result   : Set to a JSONObject of type 'Result'
       items    : [Optional] set to a (possible empty) array of JSONObjects of type 'SeismicSection'.
    }

URL: ./getSEGYDatasets.json
Overview:
    Gets a (possibly filtered) list of all SEGY datasets. If an optional parameter is specified
    then the result will contain all datasets that match that parameter

    eg: Specifying lineID=gaa1 will return all datasets for the specified line with ID gaa1
Parameters:
    lineID     [Optional] //The ID of the line you wish to request a SEGY dataset for
    travelTime [Optional] //The maximum travel time of the sound wave in seconds (as a number) to filter by.
    type       [Optional] //The type of the dataset to filter by (one of ['stacked', 'migrated'])
Response:
    JSON encoded object (as a String)
    {
        result   : Set to a JSONObject of type 'Result'
        items    : [Optional] set to a (possibly empty) array of JSONObjects of type 'SegY'.
    }

//Error code values
0: No error
1: Bad parameters
2: Database connection problem
3: Internal error
    

User Interface

The lines will appear on the portal map as a WMS layer, when the layer is clicked (and a line selected) a popup containing detailed information about the line will show.

The popup will contain metadata form the CSW description, and links to all seismic and SEGY datasets. Initially it was envisioned that the popup would also present a side by side comparison of the lowest resolution stacked and migrated seismic section images available, along with some functionality for feature comparison between images. However, following discussions with Jenny Maher (GA representative) this requirement was shelved. The rationale was that seeing the images on the screen would not really be helpful for the scientists as the print-out is huge and nothing we could show with the limited screen real estate and initial resources for this piece of work would be particularly useful. The information that the scientists really need before downloading the data is the description provided within the CSW metadata, in particular information relating to the age of the data to discern the data quality.

Screenshots illustrating the initial popup design are below:

Consideraiton was given as to whether or not any further filtering of the list of images could be done, such as allowing the user to filter by number of seconds, etc. It was decided against this approach as the list of images is relatively short and a quick investigation into other Seismic and SegY data available on the GA website (http://www.ga.gov.au/minerals/research/national/seismic/index.jsp) reveals that this will be the case most of the time (at time of writing there are no datasets on the GA website with over 20 files, most only have around 10 files).

WMS / Feature data notes

• The WMS service will need to supply a highly detailed metadata description which will be used as part of the GUI.
• The flattened data will need to have a line ID that distinguishes points between lines
• The same lineID will need to be a foreign key reference a table that will contain URL's for all supporting SEGY / Seismic Section images. The images/datasets will be distinguished according to line ID's, DPI's type etc.