Bidders will be permitted to submit questions to support their proposal development and submission. Questions should be emailed by the Bidder-question due date (indicated in the CFP Master Schedule) to the OGC Technology Desk. Question submitters will remain anonymous, and answers will be compiled, published, and regularly updated here. OGC may also choose to conduct a Bidder’s question-and-answer webinar to review clarifications and invite follow-on questions.

Are Bidders required to be OGC members?
Answer: Proposals from non-members will be considered provided that a completed application for OGC membership (or a letter of intent to become a member) is submitted prior to (or with) the proposal. updated: 2018-01-09 09:14:18
I've reviewed the federated cloud concept embodied in Figure 11. While the general scenario laid out is reasonable, there is no indication of how collaboration between Security Environments A and B is to be managed. There is also no indication of how the Security Mediation Server in Sec Env A is supposed to interact with the OAuth Server in Sec Env B, if at all. There clearly needs to be some type of federation manager / broker / agent that enables and manages any federated collaboration between Sec Envs A and B. With regards to the federation material cited in the CFP, Kurze et al., 2011, is a fine paper, but like many federation papers I've read, it focuses only on the possible functional benefits of federation. It does not discuss at all the machinery necessary to make federations work in a virtual Security Environment, e.g., federated identity, authentication, policy, authorization, resource discovery, etc. For this task to be successful within the TB14 time scale, the simplest possible available federation tooling needs to be identified. How this federation tooling enables the desired interactions between the WPS and WFS3.0 servers in another Sec Env needs to be clearly defined.
Answer: We agree that some sort of Federation manager/broker/agent is required. D147, the Secure Mediation Server, shall play this role with details documented in D023, the Federated Cloud ER. The goal of the CFP is to define the requirements and to give some direction to responders, but not to pre-define any solution. We would appreciate if you would submit a proposal in response to the CFP and help us defining all details and possible solutions during the Testbed. Testbed-14 addresses cloud federations for the first time. We therefore don't expect a fully functional service as a result, but solid ground work with clear guidance for future initiatives. updated: 2017-12-22 03:01:56
Has a location for the kickoff been selected?
Answer: USGS has offered use of its National Center in Reston, VA, USA (the same venue as used for prior testbeds), but a final decision has yet to be made. updated: 2017-12-22 03:03:12
I would like to have more details about this activity and I think this could align well with the work we are currently carrying out.
Answer: At this stage, the CFP should contain all relevant information. The CFP identifies the requirements to be addressed in Testbed-14 and provides some guidance on the expected architecture, but does not prescribe any specific solution. updated: 2017-12-22 03:03:37
Does B.11 only focus on developing an ER report? Does the testbed consider anything related to tool development and testing?
Answer: B.11 has only one deliverable, which is an ER. It was planned to extend the LiDAR point cloud work, but due to limited funding we had to reduce the task. Nevertheless, the proper development of the ER includes some testing and tool exploration. This could be realized as an in-kind contribution to the testbed. Bidders might also consider participating as editor/primary author of D013, the Point Cloud Data Handling ER updated: 2017-12-22 03:04:05
I'd like to plan ahead a bit. Last year, I remember that the evaluation time was very quick (about a month); responses from OGC would then be transmitted late February. Assuming that's still roughly the same required time this year, could a selected participant do an early start in March?
Answer: All Bidders are free to choose to perform any work at any time in anticipation of testbed execution. But there is no guarantee that any particular Bidder would be selected for funding, and any work that takes place before a Participation Agreement (PA) contract is executed would not be recoverable even if a Bidder were selected. Also, there are likely to be scope refinements as the interface details are agreed during Kickoff. So early execution of downstream activities (e.g., code development) would be under an assumed risk that Kickoff decisions might not align perfectly with the Bidder's own assumptions. updated: 2017-12-22 03:04:51
B.7.1 states that "all service implementations shall participate in the discussions about mutual authentication and delegated coarse granular access control with OAuth2 to explore issues and propose approaches to address those issues." This requirement seems to imply that the WFS3.0 implementations do not need to support OAuth2 and that only discussions/proposals are in scope in Testbed-14. However, other parts seem to imply that implementations should support OAuth2 (e.g., figure 9 or the statement "An OAuth2 authorization server is available for Testbed-14."). Could you clarify the requirements regarding OAuth2 support in the implementations?
Answer: Both WFS 3.0 (i.e. D113 and D140) are required to support OAuth2-based security in which access should be granted based solely on user identity. Any fine-grained access control for OAuth2 server D151 would be nice to have, but is not required since no cost-sharing funds are currently available to cover a requirement for OAuth2 server D151 to support fine-grained control. Any implementers interested in experimenting with fine-grained access control should consider support for D151 and at least one of the WFS 3.0 service implementations as part of their proposed additional in-kind scope. This scope would have to be clearly and independently described as additional in-kind scope. updated: 2018-01-05 09:53:45
A follow-up question: B.7.1. states: "Testbed-14 doesn’t require fine grained policy-based access control, so appreciates any work done in this regard, in particular on the integration of (Geo-)XACML with OAuth2." This clarifies that fine grained access control is out-of-scope in Testbed-14. At the same time is seems to welcome work on fine grained access control. This seems to contradict the general approach stated in chapter 1: "However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the Testbed as a platform for introducing new requirements not included in Appendix B Technical Architecture. Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in Testbed scope or not. Items deemed out-of-Testbed-scope might be more appropriate for inclusion in another OGC Innovation Program initiative." Could you clarify the expectations?
Answer: Any implementation of D113, D140, and D151 is required to support access control based solely on user identification. Cost-sharing funds are available for this activity. Fine-grained access control was originally considered as a requirement, but it was removed due to lack of cost-sharing sponsorship and is no longer funded. Bidders interested in experimenting with fine-grained access control are invited to clearly and independently describe their intended approach as additional in-kind scope since no cost-sharing funds are currently available to cover this requirement. The requirement for access control based solely on user identification does remain funded, however. updated: 2018-01-05 09:54:15
Does OGC expect the potential respondents to work out their own teaming arrangements, or are the proposals done through the website considered individually, with some post-facto coordination?
Answer: The only rule is that OGC will not enter into any multilateral Participation Agreements (PAs)... bilateral only. What happens downstream from the PA is entirely the business of the Participant. Theoretically there's no limit as long as the "prime contractor" (Participant) meets its obligations. Since every Bidder must necessarily be an OGC member just to qualify to become a Participant, all the Participants are already part of the "OGC Team". And as it turns out, there's always quite a lot of cooperation during execution because the cost-share funding is distributed to a diverse set of members. Showing interoperability between two deliverables arising from the same organization isn't quite as convincing as getting implementations from two distinct organizations to interoperate. This probably isn't "post-facto coordination" in the literal sense, but quite a bit of informal cooperation still takes place. updated: 2018-01-05 10:33:20
Where can CFP updates (e.g., regarding the Bidders Q&A Webinar) be found?
Answer: Please consult the primary CFP page at for the latest news and details. updated: 2018-01-05 10:34:09
Will a Bidder's Proposal be treated as a legally binding offer to form a contract?
Answer: Good question. This answer probably should have been in the "Tips for New Bidders" section at the end of Appendix A. From a legal perspective, what a Bidder submits in its proposal is merely be an "offer to enter into negotiations" with OGC, using the combination of (CFP + proposal) as the starting point. OGC prefers to stick to the CFP Appendix B requirements as closely as possible, though. Deviations are typically ignored unless they propose corrections to clearly-defective CFP requirements. The next step after receiving a proposal would be for OGC to send the Bidder an offer to continue negotiations. This offer would contain a preliminary list of candidate deliverables (including OGC-proposed cost-share funding for each) for which the Bidder has been selected. Often a Bidder will accept the proposed deliverables (and associated cost-share funds) as recommended. Testbed participation isn't intended to be a commercial profit-making endeavor for a Participant. In fact, Bidders are required to propose at least a one-to-one match (if not better) of in-kind dollar contribution to accompany their cost-share request. Plus the process of nailing down the scope for several dozen PAs in a one-to-two-week period doesn't allow time for any extended negotiations. Nonetheless, it's possible that there might be some brief ping-pong discussion back and forth to arrive at the final list of assigned deliverables (and associated funding). For example, under the huge scope of Testbed 12, some follow-on discussion took place to find Bidders to fill gaps for several un-proposed deliverables. Once the deliverables have been settled with the Bidder, the OGC CFO will send out a formal offer to enter into a Participation Agreement (PA) contract. The PA will include the agreed deliverables in an attached SOW. This is a "legal" offer in the sense that all a Bidder has to do is accept (say "yes") for it to become an enforceable contract. It's rare that a Bidder rejects this contract offer since most of the effort of negotiation will have already gone into creating the SOW. updated: 2018-01-06 11:44:43
Will the Bidders Q&A Webinar cover the Part 2 ITT?
Answer: Yes, a representative of the Part 2 ITT team will participate in the Webinar to respond to any questions that arise regarding the ITT. As a prerequisite to bid on an ESA ITT, an organization must first be registered as a bidder in ESA (see the EMITS site at This will result in assignment of an ESA bidder code. It is sufficient to complete only the light registration to bid. If selected, the organization will be required to complete full registration. The specific Testbed 14 "Part 2 ITT" is described at updated: 2018-01-08 11:02:06
Is the Bidders Q&A Webinar open to the public?
Answer: Yes. updated: 2018-01-08 11:57:00
How long should a submission be?
Answer: The Testbed 14 submissions will be made using an online form that will require bidders to enter a description (for each proposed deliverable) into a text box. So we're hoping that the typical submission will provide one or perhaps two very-clear paragraphs per deliverable. The best English word to describe the desired input might be "succinct". Submission of an attachment will be permitted, but there's no guarantee that we'll get around to reading any of them, particularly the more-lengthy ones, unless the attachment is absolutely required to understand the submission. Links to external references are also permitted, but they will be treated as attachments (i.e., there's' no guarantee that we'll have sufficient time to read all of them). updated: 2018-01-09 04:36:14
We have looked at the ESA ITT [Part 2 ITT] Package in some detail and we are interested in bidding, but it seems that for all work implementations ESA indicates that the results of the implementation needs to be Free and Open Source Software (FOSS) implementations. Is this mandatory?
Answer: ESA requires that the implementations are made available as FOSS as stated in the Part 2 ITT Statement of Work (SoW) 3.4 Work Packages. However Part 2 ITT proposals that do not to comply with this requirement will still be accepted for evaluation. Bidders should clearly state this as a non-compliance. Please note that Part 2 ITT non-compliances impact the marking of proposals and lower the possibility of a bid being selected. updated: 2018-01-09 06:35:41
B.10, item 2 “JSON Support”: The first requirement is to extend ShapeChange to generate a JSON Schema that corresponds to the NEO. JSON Schema is used for validating JSON data. The NEO is an ontology, which defines concepts that apply to RDF-encoded data. The relationship between the two is unclear. Is the idea to generate JSON Schema that could be used to validate NEO data encoded in JSON-LD? If not and the idea is to generate a non-RDF-based JSON Schema from the NEO, what is the idea to have both this requirement and the fourth requirement, which uses the NAS as the starting point?
Answer: In Req#1 the JSON Schema determines the structure of JSON-encoded OWL individuals. While the string-values of the “keys” in the key-value pairs may be human-intelligible for those “in the know” about the NEO they do not have any machine-interpretable bindings to the NEO namespace or NEO structure/content. The encoded OWL-individual data is not required/expected to use JSON-LD in particular, however it is undetermined whether any other JSON-related schemas might be employed in/with the OWL-individual data. In Req#2 the JSON Schema requires that (1) the encoded OWL-individual data use JSON-LD, and (2) the “keys” in the key-value pairs of the JSON Schema be tied to the NEO through a suitable JSON-LD context-component. During the conduct of the requirements analysis at and after the kick-off meeting, it may be determined that either the distinction(s) drawn between these two use-cases is (1) artificial, or (2) only one use-case has “clear utility”, and in consequence it is conceivable that they are merged into a single requirement with a single outcome. The rationale for that conclusion and outcome should become part of the ER. Documenting this will help NGA provide improved guidance to their system developers regarding the employment of JSON in NGA-associated software/applications/systems. By listing separate requirements in this area we enable the ER to help us develop “proper guidance” for activities at, or associated with, NGA. Essentially, the ER shall provide guidance and implementation on JSON/JSON-LD serialization of the NAS and the NEO. The developed JSON schema shall help validating NAS/NEO instances in the future. In the case of NEO, the JSON-LD contexts shall be derived from the ontology. The ER shall take DIL and security-enclaved situations into account, where references to external resources cannot be resolved. updated: 2018-01-09 07:24:23
B.10, item 2 “JSON Support”: The second requirement is to extend ShapeChange to generate a JSON-LD based schema that corresponds to the NEO. JSON-LD is a lightweight syntax to serialize Linked Data in JSON. A key aspect that JSON-LD adds to JSON is semantic tagging of data elements. However, JSON-LD is not a schema language. Therefore, it is unclear what a JSON-LD based “schema” should look like. Maybe the intention is to derive JSON-LD context documents from an ontology (in this case, the NEO)?
Answer: Yes, the intention is to derive JSON-LD context documents from the NEO, taking into account the results of the analysis described in the response to the prior question (#16). updated: 2018-01-09 07:25:03
Would an "Organization A" be permitted to both [a] propose a deliverable directly (to become the assigned Participant) and [b] be included as a subcontractor to another "Organization B" that proposed that same deliverable (and would itself become the assigned Participant)?
Answer: In general, it's preferred to have distinct Participants responsible for the two ends of each TIE interoperability experiment. Having code that interoperates across organizational boundaries raises confidence in the interoperability "strength" for the associated capability. So we'll try to avoid scenarios where the same Participant is, in effect, developing the components at both ends of a TIE. There might also be a risk that an organization which becomes involved in making too many deliveries might exceed its capacity to create high-quality deliverables for all of them. But otherwise there are no hard restrictions on how many Bidders "Organization A" proposes to subcontract to so long as whichever organization is the "prime" contractor (e.g., "Organization B") adequately performs. updated: 2018-01-11 16:19:46
Are the Kickoff dates firm yet?
Answer: Yes. The Kickoff Event will be held 10-12 April, 2018. updated: 2018-01-18 06:31:16
What types of costs are eligible for cost-share funding? What types are eligible for in-kind declarations?
Answer: From CFP Section A.1. Proposal Submission Procedures, "Cost-sharing funds may only be used for the purpose of offsetting burdened labor costs of development, engineering, and demonstration of Testbed outcomes related to the Participant’s assigned deliverables. By contrast, the costs used to formulate the Bidder’s in-kind contribution may be much broader, including supporting labor, travel, software licenses, data, IT infrastructure, etc.". updated: 2018-01-12 13:31:18
In the Bid Submission Form, should the "Inkind Labor Hours" be included in or in addition to "Projected Labor Hours"?
Answer: In the Bid Submission Form, the "Projected Labor Hours" should reflect ONLY those labor hours for which funding is being requested. Any proposed in-kind labor hours would instead be entered into the "Inkind Labor Hours" field. updated: 2018-01-12 14:37:49
How will a bidder know that a submission has been received by OGC?
Answer: Upon receiving a submission, the system will send an email to the bidder and to OGC staff. updated: 2018-01-13 07:47:14
If a Bidder chooses to include the single attachment that's permitted (but not required) with a proposal, is there a limit to the file size?
Answer: Yes, the attachment file size is limited to 5Mb. updated: 2018-01-13 08:55:35
The Bidders are required to provide labor-hour estimates for each deliverable. Does this mean that the Participation Agreements (PAs) will be "time and materials" contracts that reimburse Participants for actual labor-hours utilized each month during testbed execution?
Answer: No, the PAs will be "fixed-price" contracts. Unless there is a significant change in scope (as described in the PA SOW), each Participant will be paid a fixed price for making the promised deliverable. A payment schedule will be established so that Participants may submit invoices at various milestones in the timeline. updated: 2018-01-15 09:05:15
In the activity B13 Portrayal there are several mentions of client technologies like CSS, HTML5, canvas and SVG BUT the focus seems on servers (WMS and WMTS) and not in clients (none seems to be requested). Are you considering an encoding that is compatible with servers and clients?. Are you open to consider clients that are able to apply styles (e.g. a client that is able to change colormaps in a raster representations) if they receive the data that allows to do that?
Answer: B13 Portrayal addresses several technologies that are used in communication between server and client in order to render map output. B13 focuses on alternatives to OGC Styled Layer Descriptor technology. The experiments shall be executed between server implementations and simple test clients. The clients are not in focus. We will do with the client technology the server developers use for testing and experimenting. Please feel free to include any client technology in your proposal that you think appropriate. updated: 2018-01-15 06:44:50
According to the ITT instructions, an organization must be from an ESA member state in order to submit a bid on the ITT deliverables. But could a non-ESA Member state organization make an in-kind offer to deliver an ITT deliverable through the Bid Submission Form?
Answer: The capability to make an in-kind offer on an ITT deliverable is not yet supported on the Bid Submission Form. But in the meantime, the full set of ITT deliverables are listed in the CFP body at and in Appendix B at And the Part 1 CFP does provide the option of making an offer for added scope, including in-kind offers on the ITT deliverables from non-ESA member state organizations. Please refer to the following CFP language (extracted from sections 1, 4, and A.1) "Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in Testbed scope or not." In many cases in the past, in-kind offers of additional scope have been received favorably. updated: 2018-01-15 09:03:55
There seems to be a defect in the proposal manager. If you are logged out and go to you can see some deliverables that must have been entered by someone (maybe after his/her login has timed out?).
Answer: This has been repaired. Please email if you discover any further problems. Thanks. updated: 2018-01-16 04:40:02
CFP Section "Testbed Policies and Procedures" indicates that the OGC Intellectual Property Rights Policy ( is incorporated into the CFP and subsequent Participation Agreements. How does the Copyright policy apply to testbed work products?
Answer: The relevant language is contained in Section "4. Copyrights" of the IPR Policy. Participant contributions will become embodied in Engineering Reports (ERs), which qualify as "Other Work Products" under Section 4. If a Participant chooses to include any of its protected original work in an ER, this inclusion will implicate Clause 4.2 and a license to use will be granted to OGC. A preferred outcome might be for Participants to just contribute all fresh original work in these ERs rather than injecting copyrighted work. It is also worth noting IPR Policy Section "3.4 Patent Calls", which states that failure to identify any known Necessary Claims in response to the Testbed Patent Call will be treated as an election to license those claims. As is the case with copyrighted work, the preferred outcome is to avoid introducing participant intellectual property into testbed work products in the first place (e.g., to design around a Necessary Claim). updated: 2018-02-16 15:46:26
Are updates being made to the CFP?
Answer: Yes, in addition to the ongoing, frequent updates to this Calrifications list, the CFP document itself also undergoes occasional "in-line" updates as Corrigenda. The latest version number and date are listed at the top of the document (currently Version 2.3 on 18 January). updated: 2018-01-19 11:56:25
We are considering an offer of an in-kind contribution of a system that has already been developed. But since this is not a deliverable, it would fall under the CFP language "Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in Testbed scope or not." How can this system be brought to the testbed's attention for potential inclusion?
Answer: It's correct that such a system should not be included in the formal proposal. Instead, it should be brought to the OGC IP Team's attention at the appropriate time to see whether and how it could be introduced into the relevant testbed conversation(s). For example, in Testbeds 12 and 13, Amazon Web Services offered to make cloud credits available to Participants under a research grant program, and this offer was made even before the CFP was issued. So the initial offer can be made at any time. If it turns out that the system is a free (in every sense) tool that would make it easier for the assigned Participants to make their deliveries, the offer would stand a high likelihood of being accepted (as was the AWS offer in prior testbeds). But each case still has to be examined on its own merits. updated: 2018-01-19 14:28:28
When must the Final DERs be posted to Pending to meet the 3-week rule to be eligible for a vote at the December TC Meeting?
Answer: No later than 21 November. The CFP Master Schedule has been modified, and the Participation Agreement SOWs will reflect this modified schedule. updated: 2018-02-04 06:08:37