QUESTIONS AND ANSWERS

concerning

Request for Information (RFI) (#07HQ17-NoSolicitation)

for Sources of

Service/ServerMechanism(s) for Imagery and Other Geospatial Data

(

The RFI requests information about available products, services, approaches, and other componentsfor the envisioned Mechanism(s). Respondents are also encouraged to provide information about alternatives to assist the USGS in better defining its requirements. Alternative solutions for providing the indicated services are specifically sought. Particularly, we would like to integrate existing systems’ architectures where possible and provide enhanced Mechanisms to speed up viewing and downloading data and navigating between dispersed systems. It is also to be noted that technologies and capabilities offering flexible expansibility and extensibility are preferable.

And last, to specifically assist the USGS in formulating its budgetary requirements, approximate costs and resources required, both one-time and recurring, are requested. The RFIis issued solely for information and planning purposes.

Following are answers to questions received:

FORMATS

1) QUESTION: What imagery formats need to be supported and more specifically, what, if any, hyperspectral data needs to be supported?

ANSWER: Although USGS prefers the imagery data it receives meets specification for imagery data in either GeoTIFF or USGS DOQ formats, any system should be able to read/ingest standard industry raster formats for imagery, including hyperspectral data:

Standard image formats include:

  • TIFF/GEOTIFF
  • USGS DOQ
  • JPEG2000
  • MrSID
  • ECW
  • SDTS
  • BIL/BIP/BSQ
  • ESRI grid
  • IMG

Hyperspectral data ingestion/read:

System should handle standard industry multispectral/hyperspectral formats:

  • GeoTIFF
  • JPEG2000
  • MrSID
  • NIFT 2.0, 2.1
  • L7
  • HDF-EOS

Hyperspectral/multispectral write/dissemination:

  • GeoTIFF
  • JPEG2000
  • MrSID
  • NIFT 2.0, 2.1
  • L7
  • HDF-EOS

2) QUESTION: What gridded data formats need to be supported?

ANSWER:

Read Gridded Data:

  • DEM
  • DTED
  • GTOPO30
  • SRTM

* Note large amounts of lidar cloud point data are the source for much of the new high resolution elevation data. Systems must be able to read/ingest and write point cloud data in LAS format.

Write Gridded Data:

  • Elevation data from the NED will be offered using the Spatial Data Transfer Standard and in particular, the raster profile, an FGDC endorsed (FGDC-STD-002.5) profile of the ANSI and FGDC endorsed SDTS (ANSI NCITS 320:1998 , FGDC-STD-002, FIPS 173-1)
  • ArcGrid(integer data)
  • GridFloat(Arc floating point data)
  • BIL (flat binary –band interleaved by line
  • Bits, integer and floating point

3) QUESTION: What metadata needs to be supported?

ANSWER: Any system should be able to read, create and distribute FGDC-compliant metadata (Content Standards for Digital Geospatial Data) FGDC-STD-001-1998.

DATA REQUIREMENTS:

1) QUESTION: Should the proposed solution catalog multiple historical copies of the data or will it overwrite historical data sets with most the most recent data?

ANSWER: It would be desirable that multiple historical data copies be kept and made available. This would assist Pre- and Post-Event change analyses (as indicated in Potential Requirement 1.d. of the RFI). Current National GeoSpatial Program (NGP) practice is to serve from the current databases,the latest data for on-line viewing and dissemination, Legacy data is kept near-line. All data in the NGP data bases will be archived at some time under NARA archive specifications.

2) QUESTION: Is the desired functionality to support .nitf source files an effort toclip/reproject/resample imagery that may not be .nitf and then rewrite to .nitf format?

ANSWER: At this time, we do not support writing to DOD’s .nitf format. USGS does reformat the image tiles to GeoTIFFs.

DESIGN CONSTRAINTS

1) QUESTION: Can we have a list of current USGS client environments and operating systems?

ANSWER: The USGS presently has a wide range of client environments including both Intel-based and Apple personal computers, various UNIX workstations, PDAs and other Mobile computing devices. Many operating systems are in use, including various Microsoft Windows versions, Apple Mac OS and OS X, and UNIX and UNIX-like OSs such as LINUX. It should be noted that many if not most users of the envisioned Mechanism(s) would be external to the USGS; specifically Emergency Response users (see Potential Requirement 5.a.i.).

The USGS is a Bureau within the U.S. Department of the Interior (DOI). The DOI standard client hardware is Intel-based Desktops and Laptops; the standard client OS is Microsoft Windows XP (and Office XP is also allowed for Mac OS support).

The complete range of standards, specifications, and technologies in use by the Department is contained in the DOI Enterprise Architecture (EA) Technical Reference Manual (TRM) v3.1 reports (12/2005) -- see at:

The Preferred standards, specifications, and technologies may be found at:

Again, note that most users would be external to the USGS and DOI.

2)QUESTION: Are there any potential performance metrics that will be provided?

ANSWER: Potential Requirements 1 and 2.b. indicate the performance metrics that have been initially identified. The USGS does request that vendors indicate additional performance metrics that may be appropriate. Any future procurement action, were it to occur, would better provide the metrics to be adhered to.

3) QUESTION: What method(s) of securing data during downloading are acceptable and expected?

ANSWER: As implied and stated by Potential Requirement 5.c.1, the Mechanism(s) may need to support the loading, storing and serving of sensitive and classified information. Some information might be served over open communications links. Thus method(s) acceptable for securing such data during download would be required. At present, encryption or authentication schemes have not been set. Again, design-based considerations have not been made. Such considerations would need to done if a decision is made to proceed further in an acquisition/procurement cycle.

MISCELLANEOUS QUESTIONS

1) QUESTION: Paragraph 2 in the introduction states 150 terabytes of data at present, expected to grow to 250 terabytes within 3 years. Paragraph 1 under Purpose of RFI states several hundred terabytes of data expected to grow to 6 Petabytes. Which statement is most accurate?

ANSWER: Paragraph 2 of the Introduction section is referring specifically to the existing Seamless Server mechanism. Paragraph 1 in the Purpose of RFI section refers to all data (Vector, Imagery and Gridded data and associated Metadata). Also the specific estimate of several hundred Terabytes (TBs) is for present data types – versions, archives, and additional data types may be stored or served in the future, e.g. streaming video, n-dimensional objects, and so on.

A related estimate of approximately 310 TB was made for 1-foot resolution (3-Byte standard color pixel) “finished” data product coverage of the entire land mass of the United States. Raw 2D aerial imagery is 2 to 3 times as large and 3D or multi-angle production products are larger yet.

Lastly, it is desirable that, at a minimum, two views of the same area be available for change analysis as noted in the Data Requirements Question 1 response above.

2) QUESTION: Which emergency operation activities need to be supported?

ANSWER: The Potential requirements section of the RFI addressesall aspects of Emergency Operations. Specific Operations include:

  • Preparedness:
  • Dissemination services for massive volumes of data before events take place to support pre-event operations.
  • Services described in requirements.
  • Event based:
  • Receipt of and input of large volumes of Raster data, from a variety of sensors, acquired in response to an event, from a commercial provider.
  • Rapid processing, to make data available to support response activities (immediate need) for distribution with multi-modal delivery capability: WMS, WCS, FTP, on media.... as described in requirements.
  • Rapid reprocessing, formatting, metadata generation/delivery, reprojection, transformation on fly...
  • High load bearing capabilities from web services and rapid turnaround capability other modes (write to hard drive, media... for dissemination support.

3) QUESTION: What are the primary components in the current system architecture?

ANSWER: Current hardware components in place at two major locations (Lakewood, Colorado and Rolla, Missouri) may be found at:

[ Lakewood:

Rolla: ]

Current software packages (“Tier 2 and Tier 2 Helpdesk Supported”) within the USGS may be found at:

4) QUESTION: What is the operating system, web and database server and development language and platform?

ANSWER: None of the components for the envisioned Mechanism(s) have been selected or established. The USGS is seeking to better define and refine its requirements before proceeding into design considerations. Alternatives available that might assistin obtaining a technology solution that meets our needs are being sought along with costs and resources required for budgetary formulation purposes.

Currently utilized hardware, software, web and database components are indicated by the immediately preceding question response.

5) QUESTION: What APIs/SDK are available for the current system?

ANSWER: Many Application Programming Interfaces (APIs) and System Development Toolkits (SDKs) are presently in use including Single UNIX Specification (SUS), Simple API for XML (SAX), Microsoft Win32 and Win32 for 64-bit Windows, Java Portlet, Microsoft SDK and the Java Development Kit (JDK) – the SDK for Java EE (formerly J2EE). ESRI GIS products are also a DOI standard for geographic information system developments.

6) QUESTION: Where will the system be hosted and what is the expected internet bandwidth?

ANSWER: No considerations or decisions have been made as to hosting or locations. The Reliability requirement (1.a. and 2.b.vi.) for near 100% persistence and the Absolute failover requirement (2.b.vii.) would seem to result in multiple locations (with all that entails for increased overall storage capacity and data replication services) but a single host location might be possible.

The RFI at several points indicates that alternatives, approaches and alternative solutions for providing the envisioned Mechanism(s) are being sought.

An estimate made by another Federal agency for serving (with 10 second downloads)ten (10) simultaneous users 9MB image files (which is 1/16 of a USGS Digital Ortho Quarter Quad (DOQQ)) indicated a total bandwidth requirement of 1168 MBits/sec which would require the use of an OC-48 line. For large scale disasters, one thousand simultaneous users would be more likely as indicated in the RFI. The same agency estimated this would require at least OC-96 with OC-192 preferred for connection to critical sites.

7) QUESTION: Should network hardware, server hardware and storage hardware be included?

ANSWER: Yes; to assist in formulating our budgetary requirements, specifications, sizing, approximate costs, and resources required, both one-time and recurring, are requested.

If a respondent is a provider of a product, service, approach, or other component and does not deal in hardware, it would not necessarily be expected to provide hardware related information. However, expected hardware requirements may be an important component in evaluating products and services capability. The RFI simply seeks to assess the feasibility of assembling the envisioned Mechanism(s) and identify potential sources of available technologies in the event of a future procurement.

8) QUESTION: What hardware does USGS have in place that will stay in place?

ANSWER: As indicated in the response to Miscellaneous Question 6 above, no considerations or decisions have been made on locations, nor have any been given to hardware, software or other current technologies retention. The RFI is seeking information on industry capabilities, products, services and potential sources for components that might comprise the envisioned Mechanism(s). Disposition and allocation of current USGS hardware will be considered at a future time in the event of any transition.

9) QUESTION: What is the site location, Reston vs. Sioux Falls?

ANSWER: As indicated in the response to Miscellaneous Question 6 above, no considerations or decisions have been made on locations. Other current USGS locations (but not necessarily where current systems or components are sited) include major facilities at Lakewood, Colorado; Rolla, Missouri; Menlo Park, California and additional facilities at other places including Norcross, Georgia and Sacramento, California. USGS will consider any Government Owned/Government Operated (GOGO), Government Owned/Contractor Operated (GOCO), or Contractor Owned/Government Operated solution.

10) QUESTION: Does the proposed system need to interact with Seamless Server?(CRANE)

ANSWER: The envisioned Mechanism(s) may either need to interact with existing systems or be the host for them, as indicated at the bottom of page 1 of the RFI. The USGS is open to approaches and alternatives that aid the definition and refinement of our requirements (which are not completely formulated nor precisely stated at present).

Again, as noted earlier, the RFI at several points indicates that technological alternatives, approaches and alternative solutions for the envisioned Mechanism(s) are being sought. Any future procurement action, were it to occur, would need to address design issues.