- Administrative and statistical boundaries
- Transport, Utilities
- Geocoding and reverse geocoding
- Terrain, elevation, land use, ...
- Climate change, health, ...
... I have asked Geoff Zeiss and Jack Pellicci from our board to join me in establishing a leadership group to solicit your ideas and concerns, and to produce a slate of recommendations for action within 90 days. If you have an interest in working with us as part of this group to represent the interests of the OGC membership please contact me as soon as possible. An online forum will also be created to provide an open and accessible environment for members and the public to participate. We will be setting up a series of online meetings in the coming weeks, with a first meeting scheduled on 2 July for OGC members only. Registration details can be found here. A meeting open to the public will be scheduled for 11 July with several follow-up sessions for members and the public planned for late July and early September. We’ve also set up a wiki and email address to receive your feedback. My commitment is to have resulting recommendations brought to OGC membership, staff and the OGC Board of Directors for action as part of our upcoming September TC/PC meetings in Frascati, Italy. ...So what should be on the OGC agenda? I suggest:
The GeoServices REST SWG recommends the Technical Committee (TC) approve withdrawal of the motion to approve the OGC GeoServices REST API documents as an official OGC standard.Moved: Keith Ryden. Second: Clemens Portele. There was no objection to unanimous consent.
“Considering the breath of discussion both internal and external to the OGC process since the vote announcement, the SWG members feel that the vote cannot continue until the many questions raised have been addressed. Issues regarding OGC process, vendor advantage, duplication of capabilities, etc. have now overshadowed technical discussions of the merits of the specification. By withdrawing the OGC GeoServices REST API candidate standard, the necessary discussions regarding OGC process, policy, and position can continue separately.”The SWG further discussed the need for OGC Members and staff to debate, clarify and potentially amend a number of policy and procedural issues before the SWG can decide to either disband or to resume technical work on the candidate standard.
"The GeoServices REST API SWG recommends that the GeoServices adoption vote be withdrawn. If there is no objection to unanimous consent in the next 10 calendar days, then the motion is approved. If there are objections, than a two week e-vote will be initiated."Over the coming months there will be opportunities for OGC staff, members and the general public to engage in discussions related to policy and procedures, such as clear statements on openness and interoperability, overlapping standards, backwards compatibility and so forth. The idea is to begin a dialogue as part of the virtual meetings this and next month with a goal to address the issues raised and recommend changes at the upcoming September Frascati meetings.
The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.Consequently, government contracts typically specify use of standards when purchasing systems. This places a responsibility on standards organisations to protect government policy when selecting and defining the standards baseline.
Public sector consumers of software have an obligation to support interoperability, transparency and flexibility, as well as economical use of public funds. When it comes to public procurement, the principles applied to the public sector require them to support (and certainly not to harm) competition through their procurement practices.Lets address these issues point by point.
Good practice eGovernment services should provide access based on open standards, and in particular, never require citizens to purchase or use systems from specific
vendors in order to access public services: this is equivalent to granting such vendors a state-sanctioned monopoly.
... use/modify/create open standards, in that order.Unfortunately, the "Geoservices REST API" would create new standards rather than use and/or extend existing OGC web services. Emphasis on reuse of standards is important for increasing interoperability, as duplication of standards typically results in:
Verify that the standards used are open; a simple test for openness is to determine if the standard is implemented by open source software.Currently, very little open source has been developed to support the "Geoservices REST API" and there is wide opposition to the proposed standard from the Open Source community.
The WMS 1.3 Client testing provided in this testbed is an excellent step forward, and is useful for checking integration between a specific WMS client and specific WMS server, however, the WMS 1.3 client testing falls short of providing comprehensive tests confirming that a client conforms with all WMS servers, under all conditions. As such, LISAsoft considers it inappropriate for the OGC to consider a WMS client to be certified as compliant based upon the level of testing sponsored to date.
- Boundary testing was not sponsored: Can the client send a query which crosses maximum latitude or longitude lines? ...
- Exception testing was not sponsored: Would the client perform suitably if the server provided a valid exception as a response? ...
- Sponsorship only covered testing of integration with one WMS service (which only supported a subset of the WMS spec). Testing the rest of the client's WMS support wasn't sponsored. ...
|Grass on OSGeo-Live|
|CRCSI Focus: http://www.crcsi.com.au/Research|