One of the regular 2-monthly meetings of the technical committee, subcommittees and working groups. This most recent OGC bimonthly meetings were hosted by Siemens Nixdorf Informationssystemes (SNI) (Munich, Germany), a Principal Member of OGC.
110 attendees representing 66 organizations and 14 countries were present.
From JRC:
From EC:
Continuation of technical work devising and agreeing interface standards within the remit of the OGC. The results are 'RFPs', Requests For Proposals and adopted specifications.
The OpenGIS Consortium (OGC) convenes its technical committee six times a year. The last half-day overlaps with the OGC Management Committee meeting that then takes another day after the Technical Committee finishes. I attended all four days of the Technical Committee.
Full reports and current technical papers, attendee lists and policy statements can be found on: http://www.opengis.org/
The technical committee meets together only for scheduling, conclusion/reporting and new generic "technology awareness" presentations. Most of the time is spent in smaller meetings of Special Interest Groups (SIGs), Working Groups (WGs) or ad hoc groups of three or four people and one Task Force (TF). The ad hoc groups are generally where the innovative thinking is done.
The following groups met, some several times:
I attended two informal meetings with Alessandro Annoni:
The Metadata SIG also met jointly with ISO TC211 at the same time as the Management Committee on the Friday. I did not attend.
In addition, an initial organisational meeting was held to discuss setting up OGC-Europe. I did not attend this as I had been scheduled to give a presentation to the Features SIG on Feature-Feature Relationships.
The D&I SIG (35 people) produced a draft charter. This is the group which most closely studies those issues of direct interest to the European Commission: expectations for inter-operable commercial software architectures for use in complex organizations with diverse control and management policies and "...multi-national organisations who must share geo-spatial information across language, nationality, vendor, format schema and cultural barriers".
Much greater progress was achieved on a common understanding of the absolute need for feature-feature relationships to be formally described before any of the industry-specific groups (Transport, Telco etc.) or Advanced Features group (topology, constraints, complex geometries) could make further progress.
The mismatch between ISO draft SQL3/MM-Spatial and Open GIS Simple Features was discussed in detail by the Revision Task Force which submitted changes to ISO (via national delegations).
The Coverages RFP was agreed to be issued, but with a 2 month delay for Final Submission. The document 98-004 was extensively edited and incorporated into the Abstract Specification (Topic 6).
The Catalog RFP was agreed to be issued from document 98-001.
The Pixel Mapping WG was dissolved.
A proposal to form a Precision Measurement SIG for issues in location, surveying and co-ordinate transformation was noted but not accepted (yet).
An RDF/XML example was presented for Transfer technology (see discussion of RDF metadata standard with XML). Transfer technology is the OGC group looking at transferring large chunks of geodata, not just individual features or catalogs.
It was formally agreed to change from Cooke & Daniels object notation to UML (Unified Modelling Language) notation (see http://www.rational.com/uml/qr/uml_poster.html). Visio Professional 5.0 has a UML plug-in which is much cheaper than buying Rational Rose. ISO now uses OMT, Express (ISO 10303 Part 11) and IDL (http://www.omg.org) and is considering using UML too. OGC needs its own "profile" for using UML and also some decisions on datatypes and operation signatures. It was noted that Rational Rose will directly generate MIDL (Microsoft) as well as IDL (OMG).
UML 1.1 includes support for the Object Constraint Language that is being submitted to OMG.
The NIMA glossary of terms for GIS was formally adopted as the officially recognised glossary of the OGC in the English language.
All remaining meetings will be in the USA as no non-American organisation has managed to confirm that it could host a meeting. The October meeting was almost scheduled for Tokyo but could not be finalised.
| 6-10 April | Reston (VA) USA | Intergraph, USGS |
| 15-19 June | Nashua (NH) USA | Oracle |
| 3-7 August | Fort Belvoir (VA) USA | Lockheed-Martin, US Army |
| 5-9 October | Cambridge (MA) USA | GTE |
| 7-11 December | Mountain View (CA) USA | Sun |
| 1 March | Catalogs | |
| 15 March | Coverages | |
| 15 July | Complex Features | Arcs, Splines |
| 15 July | Complex Coverages | Polygon, TIN |
| 15 July | Presentation | Symbology |
This met for 4 hours and revised a draft charter.
The name of the SIG misrepresents its function. It is this SIG which is most relevant to the direct needs of the European Commission for its own functions.
This is the group which closely studies expectations for inter-operable commercial software architectures for use in complex organizations with diverse control and management policies and "...multi-national organisations who must share geo-spatial information across language, nationality, vendor, format schema and cultural barriers".
A list of 38 tasks has been prepared. A prioritised list will be prepared for the April meeting because it is realised that only 5-10 tasks could conceivably be handled with the time and resources available. These tasks include:
The SIG is integrating three different approaches to co-ordinate transformation from the three responses to the Simple Features RFP and are going to prepare an RFC (Request for Change) to modify the RFP.
In September 1997, OGC formally adopted responses to the OGC Simple Features RFPs as approved specifications for SQL, Corba and COM.
These responses were constructed largely independently by different consortia, so there are differences which need to be harmonised. This must be done otherwise it will
The COM specification is effectively a re-packaging of the SQL specification, but the Corba specification is different. Grant Ruwold (Bentley) presented a 12-point document on the differences to be harmonised through the OGC RFC (Request For Change) process.
It was mentioned that Oracle 8.1 will include a Java VM in the product, thus opening the possibility of persistently stored Java classes in future RDBMSs.
There was heated discussion on whether to remove both SQL and Microsoft MIDL from the proposals and just to request CORBA IDL submissions which would then be used to generate MIDL and SQL in a second round of standardisation. The result was to leave the matter open for Proposers to respond to in any way they thought fit - including Java RMI proposals if submitted.
Schedule:
For the Coverages RFP only 3 of the 15 types will be used: Grids, Images and Digital Matrices. These will all be georectified: a regular pixel grid in the space that it represents. (Segmented lines are not covered in the RFP.) Only a tuple of numbers (an OGC 'vector') can be associated with a point. Later RFPs will allow tuples of non-numeric values.
The Grid Coverages RFP will be issued on 1 March 1998. First Submission of proposals will be 7 months later on 1 October 1998. Final Submission will be 5 months after that: 1 March 1999. The Final Submission data was delayed 2 months because otherwise the workload over the American holiday season would have been too much.
This RFP goes the next step beyond the first OpenGIS Implementation Specifications for Simple Features. (The previously released Simple Features Implementation Specifications provide standard methods for systems to communicate simple geometry, spatial reference system, and attribute information. )
OpenGIS Grid Coverages Implementation Specifications will provide standard methods for systems to create and share:
(OGC coverages are similar to objects commonly called "fields" in college GIS courses.) Important coverage categories addressed by this RFP include
Consensus interfaces on these objects will enable diverse systems to interoperate in performing tasks such as
John Herring (Oracle) gave an overview of UML and Rational Rose.
Cliff Kottman spent an hour going over the theoretical background of Delauney TINs, Thyssen polygons, Voronoi tessellations (the dual of the Deauney TIN) etc. The important epistimological issue is the distinctions between:
The relationship between Features and Coverages is defined in Section 2 of the Coverage RFP and in the Abstract Spec.: take a point in the spatial domain, does it belong to {0, 1, many} of these three geometries:
There was then a discussion of the different algorithms (lost area, nearest neighbour, inverse weight average within radius) for inserting new nodes into a TIN or other polygon array to make it more well-formed for interpolation.
There was then an extensive discussion on the best name for the grid in the RFP: whether "orthorectified grid" implied that the grid was in a state equivalent to orthorectification even if it had never been so rectified, and if so, what such "equivalence" meant.
It was noted that the current RFP does not document the semantics of associating a value with a grid. Is the value associated with the node between squares or with one of the 4 adjacent squares, if so, which square? It was agreed that responses to the RFP should define these issues.
Two grid coverages are 'in the same family' iff they cover the same area and can be converted into one coverage with a new value tuple.
Two grid coverages are 'compatible' if they can be mosaic'd (tiled) into a single coverage; the overlapping points having their values combined by some algorithm or overwritten by the dominant coverage.
We had a discussion on segmented lines, also known as parameterised curves. These 1D objects are mathematically similar to a 2D coverage. Typical uses are where a road is parameterised with the length along it from some start point, and attribute values (discrete or continuous/interpolated) are associated with points on the road, e.g. number of lanes or depth of drain-pipe below surface. Some roads self-intersect and some form closed loops, so the precise specification of parameterised curves, and whether they will appear in a Coverages or a Features OGC RFP, remains to be decided.
All OGC coverages are OGC features (sub-type relationship). Now, every OGC Coverage Feature has a property that has a value 'coverage function', i.e. it is a FunctionProcess (a 'method' in OO language). Thus this RFP for coverages is foreshadowing the development of an API (OGC interface RFP) for Feature Schemas.
The RFP was completed as planned. Timetable is as follows:
OpenGIS Implementation Specifications for Catalogs will provide standard methods for publishing and discovering information about network-resident geodata. OpenGIS Implementation Specifications for Catalogs create a foundation, for example, for interoperable geospatial "search engines" which will provide information about network-resident geodata resources, just as Web search engines provide information about html-formatted text and simple images.
Queries to geospatial catalogs might typically consist of a specified place name, area or point location and a specified information theme, such as roads, hotels, or population density. The information returned would consist of a list of geodata servers that contain the specified information, together with metadata that will help the user to select the most appropriate sources.
Unusually, this RFP will be platform-neutral, i.e. only one RFP will be issued for SQL, COM and CORBA instead of the usual three. Proposals in response to the RFP will have to produce both ISO and Microsoft IDL (Interface Description Language) descriptions.
The mis-match between ISO draft SQL3/MM-Spatial and Open GIS Simple Features was discussed in detail by the Revision Task Force which submitted changes to ISO (via national delegations) in Brazil in April 1998.
It is likely that much of the material currently in the SQL3 draft standard will not actually appear in the issued standard that will be called SQL-98. Multiple inheritance is likely to be one of the things that is dropped from SQL-98 to re-appear in the next draft: SQL4.
The work is co-ordinated by Paul Scarponcini (Bentley) who is also on the USA national delegation to ISO.
Two documents have since been produced (Adobe Acrobat format) documenting the differences between OGC and ISO and recommending a method of harmonisation.
It was agreed that the work of the Features SIG would proceed along two parallel tracks:
The Management Committee had been expecting both issues to be tackled in an expected forthcoming "Complex Features" RFP, but that remains to be seen.
The work in the Revision Task Force working to align "Simple Features" with ISO SQL3/MM-Spatial will also affect how OGC handles complex arc types. Sean Curry will write an abstract specification submission for complex geometries (arcs and splines, but not annotations and solids).
Philip Sargent's paper on Feature-feature relationships also covered "dynamic Discovery" of schema information and relationship types. It was felt that dynamic discovery should be separated out as a separate theme.
An informal group working on Feature-Feature Relationships was set up:
A long discussion of the telecom. industry's handling of Part Numbers (real world item) made it clear that they were not the same thing as Feature Identifiers (GIS software item). This cleared up a great misunderstanding that had been impeding progress.
A full discussion of the organisational effort and management machinery that creates and maintains Part Numbers in an industry was instrumental in making matters clear to all.
It is Feature Identifiers which are used to implement Relationships, not Part Numbers.
We agreed that we should re-study that part of the Simple Features RFP that discusses "Feature Schema" access.
Topic 1: A complex geometry submission will go here based on Sean Curry's report. Dimonesioning and annotation will be omitted.
Topic 5: It is now clear that Topic 5 needs to be re-edited and all discussion of Feature schema, Feature Identity and signatures should be put there. Kathy will also include the substance of the 1997 white paper on Feature Processes (methods), Feature Interfaces (modularity) and Feature Types by Adrian Cuthbert (Laser-Scan) aided/with input from David Arctur (Laser-Scan), Adrian Cuthbert (Laser-Scan), Grant Ruwold (Bentley) and Sam Bacharach on Feature Identity.
Topic 8: Much of document 98-005 on Feature Identity/Relationships will be edited into Topic 8 of the Abstract Specification by Philip Sargent (JRC), David Arctur (Laser-Scan), Orest (USGS), and Sam Bacharach.
Philip Sargent (JRC) was invited to give a seminar on Feature-Feature Relationships based on the two discussion papers he had submitted to the OpenGIS Feature SIG email discussion list. This set the background for an extensive discussion that continued informally throughout the rest of the week.
Key insights were (for non-ephemeral relationships):
The following points arose during discussion that will need further work:
| value (simple) attributes and methods? | Almost certainly Yes. |
| value (simple) attributes and relationships ? | Probably No. |
The document 98-003 was formally accepted to be edited into the Abstract Specification Topics 7 and 11.
The group is now reviewing software tools available to produce metadata.
The SIG will have Charles Roach (Microsoft) as chairman and a SIG white paper will be produced.
A representative from ISO TC204 gave a detailed overview of the work of TC204 at the Transport SIG meeting on 10th February. TC204 is producing detailed specifications for an in-car navigation device. TC204 does standards for both GDF, a vector map file format for road networks, and PSF (Persistent Storage Format), a CD-ROM format designed for fast access to road network map data.
Architecture for TC204 Navigation Device/System
System Component |
What this communicates with |
| Navigation System | traffic control and GDF updates |
| Navigation Software | - |
| Access Library | - |
| PSF (CD-ROM) | initial load from GDF dataset |
The only user addressed by the TC204 architecture is the driver and in-car navigation system. None of this architecture addresses potential other users of this valuable infrastructure such as traffic managers, accident control and response, or road construction.
GDF is a prime example of a pragmatic standard, rushed through for commercial need, based on incoherent fundamentals. GDF can represent:
GDF updates are incremental, an aspect of the GDF standard which is still being worked on. GDF updates will need to handle versions, data life cycle and relationships between datasets; therefore Feature OIDs are going to be an issue and the TC204 name for this problem is "name resolution".
GDF is being looked at by road authorities who are considering extensions. Given that GDF has shaky foundations, we should not expect extensions to be easy to define, clean to implement, or efficient to maintain. Others involved now include Viggen, ETAK, US-SAE, NipponDenso and NAFTEC.
TC 204 has the following special working groups:
UML (Unified Modelling Language) diagrams have now been completed for 9 of the service categories. Still to be done are:
David Case (Mitre) has offered to help people to learn the UML notation. This part of the Abstract Spec. is "a living body of work" which will be continuously updated, thus the Services Architecture SIG will not form WGs and disband.
David Arctur (Laser-Scan) presented David Case's UML diagram redesigned from the previous meeting. Object types defined included Feature, GeoSpatialColllectionSet, SimpleFeatureQueryService, DisplayServices, ImageDisplay, AnnotationServices, TextDisplayService, SymbolLibrary and IconLibrary; but no architectural design was done for where these objects should be packaged or deployed. Conversely, precisely such an architectural design had been done by Adam Gawne-Thorp (Cadcorp, UK).
A paper by Kenn Gardels (University of California, Berkeley) 98-008 was discussed. This includes a case study on the GIS needs of flood emergency services and discusses the CALSIP project in California which uses OGDI and will attempt to evolve towards OpenGIS. (See http://www.statkart.no/isotc211/wg4/wg-n053.html for TC211's involvement with OGDI.)
Immense progress was achieved, largely through having an actual set of API functions to discuss which were directly derived from the insights achieved at the previous meeting. Adam Gawne-Thorp (Cadcorp, UK) had drafted a simple but complete set of APIs in Java. It is fully documented in DHTML and he has donated the Java source code of the interfaces to OGC.
Architecture Layer (package) |
What it does |
display |
clickable picture on client machine |
renderer |
includes display rules |
server |
repository with OGC Simple Feature interface |
Adam took a design decision that the source feature has no say in how it is displayed. However we do want to have some source control since a feature (even an OGC Simple Feature) can have several geometric representations. Multiple representations are vital for supporting disparate user-communities from the same source dataset and for supporting automatic generalisation.
In Adam's design there is no negotiation between the source data proposed representation and the DisplayContext of the available display: instead the 'render' package does everything. This was an intentional simplification, there is nothing in the basic design to stop one adding this capability.
In the discussion it was made clear that VRML and PostScript are examples of DispayContexts, not alternatives to a DisplayContext. VRML in particular is "dead" data, unmanipulatable by the end-viewer.
The question was raised as to where the display theme data was kept. Adam said that in his design it was stored as simple attributes on the features in the repository. Alternatives were discussed: standard symbol libraries using DIGEST FACC standard codes, a standard set of display attributes available on the WWW if the repository uses a "well known schema", an AI system may guess from the identity of the user nd the tye of the data what a suitable display theme might be, e.g. AA-like or OS-like for a UK user.
There was a great deal of discussion on one API function: declutter_display(). This was intended as a simple ability to remove invisible dross from a display screen, e.g. sub-pixel features, but it raised important issues as to where the real/integer conversions had to take place and at what level in the architecture 'precision' and 'tolerance' had to be defined.
There is a potential speed problem with Adam's design if 'render' and 'server' are separated by a slow link - as highlighted in Adrian Cuthbert's paper disseminated before the December'97 meeting: a the OGC Simple Features API could create too much overhead and what is needed is some way to convey "larger chunks" of geodata than a single feature at a time. Could we devise a Well Known Structure for a FeatureCollection ? This would fall into the Transfer Technology remit who are considering RDF/XML.
Hydrographic charts have to impose an end-user visible rendering or choose not to display at all, whatever or however the user may want to change the rendering. This is because there are legal normative rules for hydrographic charts.
Features "know" how to present themselves in a way that users can override to suit their display technology. For example, a wood is a polygon feature, it can be styled either as a fill pattern of trees pictures or a green shading; when rendered onto a display the green colour may have to match an available colour palette, or the tree pictures would have to be scaled to be visible to the eye.
One key insight is that the style selection has to be done knowing what display devices are available. This is exactly analogous to font-selection in a word-processor (style) having to be conscious of what fonts are available on a printer driver (rendering).
The Domain Task Force's job is to prepare use-cases of industry-specific needs from GIS. The Telecom, Transport and D&I groups contribute to this.
There is now a detailed use-case for the "renovation of outside plant" in the telecoms industry. The PowerPoint slide will be placed on the website. It shows that more than 30 different spatially-referenced databases are involved. The next step is to produce an Abstract Specification for telecom needs.
The current high priority is to review needs for relationships.
The next priority is for needs in text and symbology.
A white paper (MC98-001) by David Theivale (Smallworld) has been proposed for inclusion into the Abstract Specification.
Guidelines for presentations to Telecoms companies about the OGC have been produced.
The RFP will be adjusted to allow proposals based on RDF to be allowable.
It is intended to issue the RFP in March 1998.
The draft Conformance Testing procedures have been posted to the members area of the OGC website http://www.opengis.org .
These were with Philip Sargent (JRC) and Alessandro Annoni (JRC).
Allan gave us an extensive briefing on how he had organised the FGDC OpenGIS Prototype demonstration in 1997. Two people spent two months just co-ordinating the efforts donated by the GIS vendors and other systems integrators (e.g. BBN).
BBN's contribution was a front-end client "OpenMap" (java & C++), which Allan stated was equivalent in "openness" to MapObjects, MapGuide etc., but which did not handle multiple data sources at the same time and was definitely not productized: poorly documented, not robust etc. In principle, OpenMap could be loaned to any OpenGIS team planning a prototype demonstration, but he advised against it since it was much less stable than commercial offerings and would soon be out of date, if it wasn't already. In addition, one would have to budget $4000 a week for a BBN person to provide training and support.
We discussed ESRI's immediate future plans for SDE and Arc/Info in 1998, including OpenGIS Consortium interfaces, and how they matched various needs within the JRC and other European Commission agencies.
The Technical Committee exists to issue RFP (Requests for Proposals) documents. These identify a small, achievable need and request companies to propose a detailed software specification. To help set a context for this work, the TC continually edits a set of documents called "The Abstract Specification".
These RFPs, which are posted on OGC's public web site (http://www.opengis.org), request the submission of proposed detailed engineering implementation specifications for software interfaces which implement recently completed parts of OGC's OpenGIS Abstract Specification. These implementation specifications typically are written by ad hoc consortia of commercial GIS vendor companies. Out of those proposed, the TC will approve and adopt at most one.
Interfaces that conform to OpenGIS Implementation Specifications resulting from such implementation submissions will enable diverse geoprocessing software systems to communicate directly, which will enable complex geospatial information to become an integral part of modern network-based information systems.
RFPs usually ask for implementation specifications that will enable developers to build interfaces for software running on any of the common distributed computing platforms (DCPs), such as SQL, Java RMI, Microsoft's COM and OMG's CORBA. Different DCPs require different specifications, but OGC is designing the specifications to provide as much interoperability between DCPs as possible.
Formal documentation of the OGC Technical Committee procedures can be found on http://www.opengis.org/techno/development.htm.
Philip Sargent
TP 950
Centro Comune di Ricerca
I-21020 Ispra (VA)
Italia
Philip.Sargent@computer.org