Provide descriptions for developers and users how to use various server and client tools. Maintain the momentum that OGC API Features has (work on parts 3 and 4 plus the new tasks), but continue to standardize only capabilities needed by many and after sufficient implementation feedback. Develop API building blocks that are re-usable beyond Features, where possible.

[ogcscotts]

From the March 2021 Closing Plenary Ryan Ahola: how does this relate to the OGC developer web page? Joan Maso: Users of clients and services should not see the standards. Standards enable the client and server communications but should be invisible to users. Scott Simmons: extending – the developer of the client and server may not need to know the Standard, just what to implement Joan: the Standard is two levels done, is it our mission to let people know the Standards are there. Chris Lynnes: In the science fields, many users are scripting against data servers. So they need to know the API Chris Little: be the place to go for relevant APIs Peter Vretanos: is there a difference between a “geospatial” developer and a “web” developer? Features took the “flat” implementation page to a catalog of content, includes links to live demos with various tools. Developer should first see the examples before they need to read a Standard. Josh Lieberman: one size does not fit all; standardized practices on how people use various tools that are part of the larger software ecosystem – need guidance on these practices as well Chris Lynnes (+ Joan): developers want to see examples first. Also, using multiple datasets together, multi-cloud Joan: examples are not forbidden; we are making the Standard template too strict (a boring sequence of requirements) Jerome St-Louis: In my opinion, good examples are more important than superformal specs. Well defined requirements allowing for good compliance tests are also very useful, but still less so than good examples Joan: Standards editors need to include more examples Scott: new template for “implementer-friendly” in work, but how much extra work can be expected of chairs/editors/SWGs Chris Little: important stuff now comes in Section 7 of a Standard – should that not be earlier? Peter Vretanos: live environments (e.g., Code Pen) useful Satish Sankaran: can we have an always on code sandbox (say jupyter notebook type) for folks to play with various specs.... for the ogc api Joan: competing for attention of the public – need to engage the user early Chris Little: PROMISES EDR API will include a TikTok video Gobe: OpenAPI definition documents can contain informative text – what would people want to see? Move requirements and ATS into the OpenAPI document? Peter Vretanos: get nervous putting too much in the OpenAPI document; could become too tightly tied to OpenAPI Satish: popularize libraries like pygeoapi .... to the extent that it is made robust enough for vendor adoption ( like say gdal today) Stan Tillman: developers have been impressed already with the OpenAPI documents, we have already made giant leaps. STAC website is a good example Alex Ramage: do we need to go to more general developers for feedback? Nadine/Peter Vretanos: yes! Joan: the GitHub repos are more for us – help with workflow, also in the open for some groups to increase visibility; better expose other resources (which are already in GitHub) Scott: need the other resources to be readily visible Chuck Heazel: need to be able to find just the information you need Peter Vretanos: building blocks as man pages Joan: geopackage.org, owscontext.org and others to make Standard-implementation resources more discoverable Keith Ryden: maintenance of the dot.org sites needs to be consistent, OGC maintenance of these is needed Chuck: build on schemas.opengeospatial.org as a model? Register modules. Satish: ogcapi.ogc.org has been helpful. See example for implementations pages on GitHub for OGC API – Features (https://github.com/opengeospatial/ogcapi-features/tree/master/implementations) Keith: need more examples, reference implementations will emerge. But also need to be careful on what we call a reference implementation – “hang our hat” on it! Chuck: criteria includes lots of inline documentation Satish: for client developers dependent on example server implementations, need some persistence in those servers Satish: some developers hurrying through an implementation, need clarification of any deviations or simplifications of example implementations, especially those that are experimental Joan: first thing developers do is look for examples: some work, some don’t; what competency of developers on matters geospatial must be assumed (or not assumed!) Scott: we need to reach the “ignorant” developer who do not understand the geospatial subtleties Peter Vretanos: help steer the developers Linda: need to direct people to the Spatial Data on the Web Best Practices Joan/Heidi: participate in stackoverflow/stackexhange Heidi: also need to address IT-architects, Project Managers. Developers don’t decide on the Standards that are being used/procured. The description of the Standard should also be targeted to others Chris Little: developers may not be the best deciders! Chris Lynnes: cannot necessarily legislate to all groups in an organization what everyone will use, there is some persuasion Nadine: when the developer searches the web for how to get a map on the web, they should come to OGC first Chris Lynnes: point of organization like OGC is to help different organizations interoperate Peter Vretanos: point of OGC is to bring people together to build consensus Standards that would be widely used Heidi: more OGC people should be active on Wikipedia! Keith: a lot of this discussion is related to marketing Mark Korver: cloud vendors could work together on a blog post on how to use specific Standards Mark: need to engage those other forums where we can share information Nadine: Engineering Reports don’t get read, blogs do Mark: an ideal blog post lets someone read and do (create something described In the blog) in 30 mins Chuck: rebuild of OGC Reference Model is knowledge-based, could help Joan: OGC blogs need examples Nadine: improved outreach through revised OGC website