Loren Data's SAM Daily™

fbodaily.com
Home Today's SAM Search Archives Numbered Notes CBD Archives Subscribe
FBO DAILY ISSUE OF JULY 24, 2010 FBO #3164
MODIFICATION

D -- Design, create and implement a website to disseminate information

Notice Date
7/22/2010
 
Notice Type
Modification/Amendment
 
NAICS
541511 — Custom Computer Programming Services
 
Contracting Office
Department of Commerce, National Oceanic and Atmospheric Administration (NOAA), NOAA-Pacific Islands Fisheries Science Center, 2570 Dole Street, Honolulu, Hawaii, 96822-2396, United States
 
ZIP Code
96822-2396
 
Solicitation Number
PIFSC-10-030
 
Archive Date
8/18/2010
 
Point of Contact
Bonnie Oshiro, Phone: 8089835356
 
E-Mail Address
bonnie.oshiro@noaa.gov
(bonnie.oshiro@noaa.gov)
 
Small Business Set-Aside
Total Small Business
 
Description
Please send any questions to Bonnie.Oshiro@noaa.gov Q1: Can you provide some more specifics about the data in the data layers? How many layers, what type of data, and what type of interactivity is desired for display of the layers. A1: The data in the data layers would be a combination of data that are in flat files (ASCII) which we would like to have the ability to plot, and spatial data in GIS shapefiles (which can be separate or stored in a database, e.g. Oracle). These data layers may be housed within our center, or externally that we would draw from. Q2: Can you talk a bit more about the process by which the static prototype (http://www.hawaiieod.com/kona_iea/) was designed? A2: The static prototype website was designed by within the program division. This was done ad hoc to have something up for the program in the interim. We used the existing NOAA template (DHTML, CSS, code, etc) to get this up as fast as possible while adhering to standards. There are elements that we would like to keep (some layout, theme, and data elements), but are not married to this design by any stretch. We are open to the best design possible for our data and information needs as long as it meets NOAA and federal requirements for style, content, framework, etc. Q3: What other design and production work would be included in the scope of work, beyond what's in the map application itself? A3: The map application is one part of this, but what's almost more important is the design of a website that will facilitate information delivery. A large part of the project will be in designing the site template so that it is complete for the information that we currently have, but can be easily added to as more data and pages become necessary. Q4: Is there an incumbent vendor or a vendor with whom you have already discussed the project? A4: This is a new project. Q5: Are you open to an open source PHP content management system -which meets very well your initial operational goals and technical requirements stated in the RFP? Or do you require a custom developed PHP content management system. A5: We are open to a content management system (e.g. Drupal) so long as it meets the project and federal/NOAA guidelines for external websites. Q6: How are mapping data created and maintained currently, and if none currently, how do you wish it to be? A6: Much of the mapping data in our current inventory were created in ArcGIS and maintained as shapefiles or in a geo-database. The wish would be to have the mapping data in a geo-database rather than as flat files. Q7: Will you be pulling data from a third-party source for the mapping or will you be manually entering information? A7: We have much of the data files in a suitable (e.g. shapefile) format. If we do pull data from a third-party source we would expect that it would be in a suitable format for mapping as well. Q8: If you are pulling data from another source could you please tell me the data format and where the information is being pulled from? Are data being pulled in handled in an offline way such as FTP or is there an automated background process contemplated for the data? A8: We're still working up an inventory of available offsite data, yet we expect that a large portion of the data would either be static shapefiles (pulled from an active partner database/storage system available through the web) or temporal data that would be maintained on the partner website/database. We would prefer that we pull the data from the source dynamically (i.e. as needed) and not FTP data to our site if possible to avoid data replication and minimize storage requirements. Q9: What level of data control would you like for the data overlaid on the maps? Please be as specific as possible with your desired data and content control level. A9: We would like for users to have the ability to map point and layer data, with an ability to zoom and merge layers (if possible). Q10: How many pages do you estimate will be on the PIFSC Kona's site? A10: That's a hard question to answer, we could estimate 15-20 static pages not including the dynamic section, but we're hard pressed at the moment to come up with a number. Q11: Will the contractor be working with existing templates and graphics found at www.hawaiieod.com/kona_iea - the static site example? A11: These templates are available as a starting point but not required. These templates were initially used as they are the "official" template provided by NOAA, yet they are not required and are somewhat "busy" for a main site. For example, our center's official site at www.pifsc.noaa.gov is quite different. While this official site is being redesigned, it can be used as one other example of a NOAA/NMFS website. Q12: Will you consider CONUS organizations? A12: Yes, but the organization must be able to provide the capability for ~weekly meetings and be able to upload changes to the website to our on-site webserver. The SOW states: "Communication with the key personnel shall be via phone, email (or other electronic means), and in-person. Regular meetings either through video or in person at the client's site (Honolulu, Hawaii) will be required. During these meetings, the contractor shall provide a suitably equipped laptop computer and the capability to demonstrate features, prototype changes, and productively engage in other aspects of the work. During these meetings, the contractor shall be prepared to discuss issues and recommendations with end-users and other staff. Depending on the nature of the project, the frequency of these meeting may be weekly or less." Q13: I am assuming that this site is to be hosted on your servers, correct? How rigid is the preference for a CakePHP or Rails web framework? A13: We will host the site on our internal servers. The preference for CakePHP or Rails is not completely rigid, but as they are frameworks that we currently use here at the center it would be nice to be able to integrate this web framework with others at the site. That said however, as long as the framework decided upon is cohesive with what our webmaster is accustomed to would be sufficient. Q14: Is the requirement of creating the entire website on Linux a requirement, or do you also accept Microsoft based solutions? A14: We would require that the website be built on a linux framework. All of our webservers are built with Linux/Apache and we would require that to maintain consistency and ease of maintenance. So no, unfortunately we would not be accepting Microsoft based solutions for this project.
 
Web Link
FBO.gov Permalink
(https://www.fbo.gov/notices/6a4e7b97eb9797f5a2fab8a2cdaf0448)
 
Place of Performance
Address: Honolulu, Hawaii, United States
 
Record
SN02214094-W 20100724/100722234632-6a4e7b97eb9797f5a2fab8a2cdaf0448 (fbodaily.com)
 
Source
FedBizOpps Link to This Notice
(may not be valid after Archive Date)

FSG Index  |  This Issue's Index  |  Today's FBO Daily Index Page |
ECGrid: EDI VAN Interconnect ECGridOS: EDI Web Services Interconnect API Government Data Publications CBDDisk Subscribers
 Privacy Policy  Jenny in Wanderland!  © 1994-2024, Loren Data Corp.