Page History

Technical Approach

• User Stories - Support these user stories
• Geospatial - Save As Framework - Develop an application service that can take the output of a session context from a viewer in a specific standard, then transform and export it to multiple formats. It was first developed directly into The National Map Palanterra x3 Viewer based on ESRI JS supporting multiple target formats (KML, Px3 JSON, and PDF/Images). It has since been refactored as a standalone application. Now, the focus is on going live with existing transforms, finding a hosting location, complete remaining transforms, and explore new context standards with OGC via testbed participation and evaluation of 2 standards: New OGC OWS XML conversion to JSON, and the ESRI JSON adoption to OGC. One thing that shouldnt go unmentioned is that opening a context file not located on the same domain requires additional cross-domain and script/SQL injection validation controls on top of schema validation. This "OpenIn" functionality also was developed as part of the framework which its code, for javascript libraries, an be leveraged for use in other viewers.
• Architecture, Design, Coordination -  In 2010, the team architected a Target Application Architecture, Target Info Flow, and overall Architecture Diagram that is based on a common context and standalone application web service. The role is to support coordinating design requirements and promoting this concept of operations across the multiple Viewer APIs, security requirements, and use of the web service. As well, help progress the OGC standards towards one that can be industry adopted and adopted across USGS/DOI in JSON to be used by popular Viewer APIs.
• Viewer Library API, SaveAs, and OpenIn Migration to SB/CSAS -  Since 2011, its been discussed with the Sciencebase team to be able to save, catalog and then open contexts in different viewers. In 2013, we are proposing at minimum to evaluate what is needed to get the application web service in the same Sciencebase hosting environment to go live with save as in permanently, and decide the length of time that it may need to continue in interim reside on NGP servers.
• Open In OpenLayers Framework (Read Px3 JSON, ESRI JSON -  In 2011, we developed the capability to read ESRI REST Web services in Openlayers. That code was re-used in 2012, and taken a step further to be called via the Px3 context standard. Now, the approach is to complete the context integration in Openlayers with all standard function calls as well as offer up this new framework to be used and maintained by the ScienceBase Team. As well, we should look to continue to coordinate with another 2012 CDI project that researched Openlayers HTML5 library integration. Example of work still to be done: 
  Read in some missing session input (Basemap Buttons, layers, zoom), Debug some ESRI REST Service compatibility, Incorporate with ERSG OpenLayers work, and discover ways to make this part of standard OpenLayers Library
• Save to ArcMap (10 days) -   Early on focused on enabling the initial problem through manual solutions (i.e. an MXD with common service palette), and in 2011, NGP and NEIC researched with ESRI Architects multiple methods of how to move from web context into an ArcMap MXD file. Through discussions, and updates from ESRI in 2012, we now have the code that works in ArcGIS Server 10.1 that will create an MXD file for the user to save via ArcPy libraries. When a AGS 10.1 environment is made available, we are suggesting to go live with this transform target format.  The Save As Function needs to simply call a 15 line python script to output an MXD file, but to do it needs to be running 10.1 server side, but the resulting MXD can be opened in ArcMap 9.x and up. ArcMap still slow & “bloated” to open many services due to how they make lyr files, but it works – which may be an eGIS type enhancement request (make services usable in ArcMap).
• Open in Flex (Convert Px3 JSON to ESRI JSON) -  In 2011, ESRI came out with a REST Standard offered to the Open Web Framework, and later offered it to OGC for consideration. Since 2011, ESRI has made all Viewer APIs, and ArcGIS.com completely integrated with this format. We would like to coordinate as part of an OGC sponsored testbed a second standard JSON context format and tracking the ESRI/REST OGC SWG progress towards offering a 2nd alternative option. As well, this task would produce the capability to call the Save As function and transform the REST/ESRI JSON to other targets. Likely this will require more code refactoring by NGTOC to the final architecture factoring levels originally required 

Active Discussion Threads Discussion on JSON and Security implementation - Context Security - Good threads on how we handle cross-domain JSON calls (client side or server side processing is the question) Standard JSON Context - Context Standard - OGC has drafted the new OWS context in JSON encoding - now onto seeing the use cases and requirements come through. Background Architecture Target Application Architecture Target Info Flow Architecture Diagram

Project Experience

We will not be submitting bios, profiles, or CVs for this project.

Commitment to Effort

Budget

Please provide a detailed budget for the project using Table 3. Include at least the following categories of information, separating the CDI funds from the in-kind match:

1. Salaries and Wages (see also Budgetary Considerations)
2. Fringe Benefits
3. Field Expenses
4. Other Direct Cost Line Items
5. Total Direct Charges
6. Indirect Charges (Overhead)