Les travaux de l’OGC se font par courriers électroniques, par conférences téléphoniques et par réunions réelles. L’OGC organise quatre réunions par années, chacune d’une durée de cinq jours, hébergées par des organisations membres sponsorisant l’événement (compagnies, universités, centres de recherches, etc.). Le continent hôte alterne entre l’Europe et l’Amérique du Nord, avec une présence croissante en Asie depuis 2011. Ces réunions reçoivent habituellement entre 50 et 100 participants parmi les centaines de membres de l’OGC. Certains participants sont présents à quasiment toutes les réunions et constituent des piliers de l’organisation. Les réunions de l’OGC offrent des opportunités d’échanges avec des membres d’horizons diverses.

La création d’un standard OGC commence par le regroupement d’organisations ou d’individus constatant un intérêt commun pour une problématique. Un groupe de travail est proposé sous l’appellation de Domain Working Group (DWG) ou Standard Working Group (SWG). Les DWG sont ouverts à tout membre de l’OGC, tandis que les SWG nécessitent de la part des participants un engagement à ne pas entraver la diffusion du standard par des réclamations de propriétés intellectuelles.

Fonctionnement des groupes de travail (SWG)

Pour être accepté, un projet de standardisation doit être supporté par un nombre minimal de membres appartement à des organisations distinctes. Ces membres fondateurs rédigent une charte définissant les objectifs du SWG, qui doit être approuvée par le comité technique de l’OGC. Chaque membre fondateur est doté d’un droit de vote, dans les limites d’un membre votant par organisation. Tout nouveau membre qui souhaite joindre le SWG après sa création se verra attribué un rôle d’observateur, avec attribution sur demande d’un droit de vote après quelques mois d’observation.

Un SWG peut contenir plusieurs dizaines de membres, mais les volontaires effectuant l’essentiel du travail sont habituellement moins nombreux. Leurs propositions sont soumises à l’ensemble des membres du groupe, qui peuvent les accepter par consentement unanime. Les objections, s’il y en a, doivent être argumentées et une alternative proposée. Les SWG essaient généralement de débattre d’un problème jusqu’à ce qu’un consensus se forme plutôt que d’avancer malgré des votes négatifs, même s’ils sont minoritaires. Les décisions du groupes sont alors intégrées dans la spécification par un membre assumant le rôle d’éditeur.

Le groupe de travail doit autant que possible structurer la spécification sous forme d’un noyau autour duquel gravite diverses extensions. Une suite de tests doit accompagner le standard, et permettre de classer les implémentations en fonction du niveau des tests passés. Au moins une implémentation de référence passant les tests doit exister pour démontrer que le standard est utilisable.

Lorsque le standard est jugé prêt, le SWG vote une motion proposant de le soumettre au vote des instances supérieures de l’OGC. Cette procédure nécessite plusieurs mois. Il existe une procédure plus rapide pour entériner des standards de fait, mais elle n’est appliquée qu’avec parcimonie.

Le conseil d’architecture (OAB) et le comité technique (TC)

Toute proposition de standard est d’abord examinée par le conseil d’architecture (OGC Architecture Board — OAB). Ce conseil vérifie que le standard répond aux exigences de l’OGC sur la forme, sur la modularisation, et en termes d’intégration avec les autres standards. Si l’OAB donne son aval, le standard est alors soumis au vote des membres du comité technique (TC). Ce comité regroupe les principaux membres de l’OGC qui sont seuls habilités à donner le vote final. En cas d’approbation, le standard est diffusé publiquement pour commentaires pendant une période de quelques mois. Au terme de cette période, le SWG doit examiner et répondre à chacun des commentaires. Les éventuelles modifications au standard sous soumises à l’OAB, puis le standard est définitivement publié. Cette diffusion est alors annoncée par un communiqué de presse de l’OGC.

Certains membres de l’OGC et du TC assurent aussi la liaison avec l’organisation internationale de normalisation (ISO). La coopération entre les deux organismes va dans les deux sens: l’OGC adopte les standards ISO comme base sur laquelle développer de nouveaux standards, et certains de ces nouveaux standards OGC deviennent des standards ISO.

Procédure de soumission de propositions de modifications

Tout utilisateur, qu’il soit membre ou non du consortium Open Geospatial, peut proposer des modifications à des standards OGC. Une liste des propositions actuelles de changements, ainsi qu’un formulaire permettant d’en soumettre de nouvelles, sont disponibles en ligne. Chaque proposition est revue par le SWG.

Certains groupes de travail utilisent d’autres systèmes de soumission en parallèle, par exemple GitHub, hébergés en dehors des structures de l’OGC.

Au tournant du millénaire, les spécifications abstraites étaient explicitement concrétisées dans des spécifications d’implémentations. Le terme « implémentation » était ici à prendre au sens de tout type d’interfaces (Java ou autres) dérivées des diagrammes UML — et non pas d’implémentations au sens du Java. Des telles spécifications existaient pour les langages SQL, CORBA, COM et Java. Ces langages étant capables d’exécuter des procédures, les spécifications de cette époque définissaient non seulement des structures de données, mais aussi des opérations s’appliquant sur ces structures.

Par la suite, l’engouement pour le « web 2.0 » a fait grimper l’intérêt pour le XML au détriment des autres langages. Les anciennes spécifications d’implémentations ont été dépréciées, et les schémas XSD sont devenus la principale concrétisation des spécifications abstraites. Même la façon de concevoir les spécifications abstraites a évoluée: les opérations y sont plus rarement définies, par conséquence ce qui reste ressemble davantage à des descriptions de schémas de base de données. Certaines opérations qui étaient définies dans les anciennes normes apparaissent maintenant, sous une autre forme, dans les spécifications des services web. Enfin le terme « spécification d’implémentation » a été abandonné, pour être englobé dans « standard OGC ». Mais malgré leur dépréciation, les anciennes spécifications d’implémentation restent utiles aux programmes en langage Java car:

• Leurs modèles plus simples, appliqués aux mêmes concepts, aident à comprendre les nouvelles spécifications.
• Ils définissent parfois des façons simples d’effectuer des tâches courantes là où les nouvelles spécifications se limitent au cas général.
• Les opérations étant plus souvent omises dans les nouvelles spécifications, les anciennes spécifications restent un complément utile pour définir des API.

Le projet Apache SIS se base sur les spécifications les plus récentes, tout en puisant dans les archives de l’OGC pour compléter certains standards abstraits ou les rendre un peu plus facile d’utilisation. Certaines anciennes définitions sont conservées comme « méthodes de commodités », n’apportant pas toujours de nouvelles fonctionnalités mais facilitant l’usage pratique d’une bibliothèque.