13.07.2015 Views

download as a pdf - Southern California Coastal Ocean Observing ...

download as a pdf - Southern California Coastal Ocean Observing ...

download as a pdf - Southern California Coastal Ocean Observing ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Part III. Appendix 2: Data Transportclient access to data stored in standard GIS formats. As a precursor to full GIS access, considerationshould be given in the pilot to GIS access via an intermediate file capability. The ability to do thisat what is thought to be a fairly low level of effort is why this t<strong>as</strong>k is not ranked at a higher priority.There is a simple, inexpensive solution that will enable GIS users to access data from DAP-enabledservers, although not at the full functional level of the system—direct access to DAP-servers fromwithin the GIS. Developing servers for some of the more widely used GIS formats will be straightforward.GIS access to data from DAP-enabled servers will likely have to be undertaken on a GISby-GISb<strong>as</strong>is, <strong>as</strong> h<strong>as</strong> been done for such scientific information systems <strong>as</strong> Matlab and IDL.We recommend that this pilot be undertaken in two stages. In the first stage, the pilot needs tocleanly delineate what the issues are, which GISs should be targeted, the level of support (access)that is appropriate, and the cost of building the interface. In the second stage, the pilot needs tomove forward with implementation. We anticipate that the first stage is a .25 to .5 person year effortand should be budgeted at $50k. NVODS’ experience with ESRI suggests that if ESRI is to developthe GIS interface to the DAP for their ArcMap products it will cost on the order of $250,000or more. We have no experience with what it will cost to provide the similar interfaces to otherGISs. It may be, however, that an alternative solution to the GIS-by-GIS DAP client will be identifiedin the first ph<strong>as</strong>e of the pilot.Pilot Project #6: Metrics – Priority 7Metrics on the use of the system must be collected in order to evaluate system performance. Althoughsome lower level metrics are obvious (e.g., number of requests, volume of data moved),experience with NVODS suggests that thought and attention beyond the obvious must be given tometrics. For example, it is important to know not only the b<strong>as</strong>ic numbers but also how requests arebeing made. This is especially true <strong>as</strong> the transport layer becomes more and more hidden. An inappropriatelyconfigured client could e<strong>as</strong>ily make inefficient requests that loaded the system down.These need to be discovered. To do so, the information gathered about data requests needs to becarefully considered and an analysis capability needs to be built that will ferret out potential problems.We recommend a two-year pilot to address this problem. We believe that this pilot shouldanalyze the http logs from some of the more active sites currently serving data via the DAP to learnwhat the existing issues are. This would be followed by the development of a suite of metrics thatshould be collected and the design and implementation of a module that would work with theDAP to do this. The re<strong>as</strong>on for a two-year effort here is that we believe that it will take on the orderof one year to perform the preliminary analysis, to design and build a metrics gathering module,and to move this module out to a significant number of DAP server sites. The second year shouldbe devoted to the collection, analysis, and possible refinement of the metrics-gathering module.The total effort is approximately a 1.5 person year effort. IOOS should budget $200k for this pilot.164

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!