A 1.142Mb PDF of this article as it appeared in the magazine complete with images is available by clicking HERE
What keeps the Architecture/ Engineering/Construction (AEC) community up at night? Often they are trying to think of ways to gain efficiencies and reduce costs, including the costs of construction errors that result from design errors. One way to achieve greater efficiencies and reduced costs is to apply more information (perhaps from other vendors and data producers) in simulation, analysis, "clash" detection and visualization. Unfortunately, such information is often difficult to discover, assess and access because it resides in systems that do not interoperate. Perhaps the stakeholders’ software vendors’ document management systems do not communicate. Perhaps their data providers have different naming schemas for digital files or physical construction elements.
The upside of difficult economic times is that organizations and governments put even more effort into coming up with clever ways to gain efficiencies and reduce costs. This brings new insights and innovation, as organizations talk to each other about how they can share their information to produce more efficient workflows. In such dialog, interoperability requirementsand the importance of interoperabilitycome to the fore.
Geospatial/Civil/BIM InteroperabilityIt’s possible!
The success of the recently organized interoperability day held by the French OGC Forum on December 5th titled "Sensors, Buildings and Infrastructure" shows that the industry is interested in geospatial, civil and building interoperability. This trend is not new; the increased adoption of OGC’s CityGML and BuildingSMART’s Industry Foundation Classes (IFCs) has raised awareness of interoperability among users, policy makers, data providers and software vendors.
Open standards are the obvious solution, but even those of standards operate, to some extent, in stovepipes. We live in isolated worlds that have different problems and we speak different languages. We need to learn from each other.
The Open Geospatial Consortium members know a lot about Web services. OGC Web Services standards make it possible for software developers to make geospatial information of almost any kind available as services instead of data files. When you use Google Maps, for example, you are "consuming a service" , not downloading a file. You don’t need to store and keep track of numerous voluminous geospatial data files. That is the way of the future.
AEC companies routinely use their software vendors’ modeling tools, which enable design elements to be moved about in a design, carrying with them a wealth of information about how they relate to and connect to other design elements. For example, a road segment viewed in plan and inserted in a model carries with it everything that will be needed when the road model is viewed in cross-section. This provides for very efficient design. By contrast, in the geospatial world, the focus is on features’ geometries and attributes. Feature relationships can be determined, but geospatial features do not carry with them the complex and useful set of spatial and functional relationships present in AEC models. Open-minded cross-domain discussions lead to many, often unpredictable, creative possibilities.
With CityGML having its origins in the Geospatial world and IFC having its roots in the Building Information Modeling (BIM) world, interestingly enough, both are now reaching out to LandXML to increase interoperability with the civil community. The OGC, BuildingSMART International and ISO TC 59/SC 13 are discussing various harmonization approaches.
LandXML, an open standard, provides a transfer standard for many Civil Engineering applications, and BuildingSMART’s open standard IFCs provide a transfer standard for Building Information Models. As the OGC found in early review of geospatial transfer standards, when communities share the cost of moving from transfer standards to service interface and encoding standards, all the stakeholderstechnology providers and technology usersrealize tremendous returns on investment. AEC players, and building owners and operators, are beginning to recognize the limitations of file-based computing. We anticipate that consensus standards work done in various consensus standards consortia over the next few years will result in tremendous market growth for technology developers and extraordinary value for technology users at every stage in the life cycles of buildings and capital projects such as roads and airports.
About Web services
Most civil applications available from the major software vendors already provide support for the OGC Web Map Service Interface Standard (WMSserving rendered images) and OGC Web Feature Service (WFSserving feature geometry). Thus, geospatial information, often available through government or private sector Web services that implement these standards, can be consumed by the civil applications. In practice, however, most information sharing workflows still suffer from the mindset instilled in users and providers by decades of file-based computing.
Services themselves use services. Much of the promise of Web services derives from the promise of "chained" services. AEC document management, for example, would benefit from a vendor neutral catalog system, a front end to vendors’ current document management systems, that would enable services to find both data and other processing services. Imagine going to a library and looking for a book–but with no indexing system. You know the book is in the library, but you have to remember where the book is shelved. That is why libraries have an index. The reader will look up the book in the index, and the index will indicate where it is. A reader can find the book they are looking for by using the title or the author of a book. But the index can also contain other information about the book: publishing date, ISBN number, subject, theme, fiction/non-fiction, category (humor, travel…). This additional information about the book is what we, in the geospatial world, call metadata: data about data. It provides additional information about the data itself, which is not contained by the data. Examples of metadata: date when the information was collected, department responsible for the data, "valid until [date]", etc.
Catalog services that implement the Catalog Service for Web (CSW) standard make it possible for applications and services to quickly discover, assess and access data and processing services. The Catalog Service is very similar to the index in the library: both know where the resources (books or data) can be found. Catalog Services and Indexes contain and index the metadata and point to an Internet address where the actual data can be found. This enables the "Publish Find Bind" paradigm, where "bind" refers to a software process that invokes another software process and makes use of the returned result.
Note: The metadata schema that has been used by the geospatial community (FGDC, ISO 19115, ISO 10139) might not always fully capture the information types contained in civil datasets. Additional fields of metadata might be required by the civil- and surveying community, captured in a Civil Metadata Profile.
Governments see various kinds of value in making authenticated geospatial reference information available as OGC Web Services to the Civil and Surveying community. A recent German DIN (Deutsches Institut fr Normung e.V.) Study indicated that interoperability saves costs and has a greater impact on the economy than patents or licenses. Development of spatial data infrastructures based on a web services standards platform is a very positive outcome of the INSPIRE directive from the European Commission and the Open Data strategies by various countries (e.g. as part of the EC Digital Agenda or Data.gov in the US and other parts of the world).
Relevant activities in the OGC
OGC members have recently created a Land Development Standards Working Group. This Working Group will first be looking into harmonizing LandXML with OGC standards, but it will also look into other Civil, Survey or Land Development topics.
The OGC 3DIM Domain Working Group is facilitating the definition and development of interface and encoding standards that enable software solutions that allow infrastructure owners, builders, emergency responders, community planners, and the traveling public to better manage and navigate complex built environments. Effective integration of these software data and services has eluded the geospatial and CAD industry for decades. Today, through the cooperation of diverse stakeholders, integrated infrastructure information systems will be achieved. OGC members and partners will work in an iterative development process to achieve incremental demonstrations of real solutions.
The OGC IndoorGML Standard Working Group is developing an application schema of OGC GML and progressing the document to the state of an adopted OGC standard. The goal of this candidate standard is to establish a common schema framework for indoor navigation applications.
The OGC Energy & Utilities Domain Working Group addresses requirements of the global energy and utilities community, which is defined as individuals and organizations engaged in the geospatial aspects of the planning, delivery, operations, reliability and ongoing management of electric, gas, oil and water services throughout the world. City-models-LIDARPoint Clouds and OGC Services:
City models can be generated in lots of waysfrom architectural models to laser scanned point clouds-and everything in betweenover time, gradually building a 3D urban geo-database, serving OGC’s CityGML through WFS. In the last year as I attended events around the globe, I noted that LIDAR scanning is democratizing rapidly, with devices becoming more and more accessible at lower prices. (How long before our smart phones can laser scan a building or room to access or add to a 3D model in the cloud?). As a result, more and more point cloud information is createdaccelerating the creation of city models.
It is interesting to note that some OGC members are also investigating how they can serve point cloud information through services that implement OGC Web Service standard. This would be of great benefit to professionals that use point clouds day in and day outno need anymore to copy these huge files, just share them over the web. Another advantage of using the OGC Web Services is the inclusion of a `filter’ between the point cloud web service and your client software: the Web Processing Service (WPS). The WPS could filter, do surface reconstruction, feature extraction, segmentation or model fitting before the data is sent–freeing your machine from this (computing extensive) task so that you can work on something else. This will further integrate Civil–Geospatial and BIM workflows and information.
Conclusion
As in all other major industries, stakeholders in the Civil, Geospatial and Building industries seek ways of using information technology to become more efficient, productive and competitive. The Internet and Web show the power of open standards for the universe of Internet and Web users, and the OGC has shown the power of open Web services standards for the geospatial world. Through participation in open standards initiatives, the AEC industry can apply these lessons and leverage the value and momentum provided by the Web service enabled geospatial industry.
The boundaries between worlds are dissolving through developments and activities such as Augmented Reality, 3D urban modeling, indoor/outdoor navigation, indoor/outdoor device location, indoor/outdoor air quality management, energy management, the Smart Grid, sensor webs, and the Internet of Things.
If you are active in the Civil or Surveying community, we invite you to get involved in the OGC’s Land Development Domain Working Group. You can help shape tomorrow’s civil engineering interoperability standards, and in the process you can help shape the information-rich world of tomorrow.
Bart De Lathouwer has worked first as European liaison to the geospatial division of Autodesk and later as Autodesk’s Program Manager for Server Technologies. In this role, he also served as member company representative to the OGC. As a company representative, he started the OGC CAD-GIS Interoperability Working Group (which evolved into the OGC 3DIM Domain Working Group) and managed the development of a core data access technology FDO (Feature Data Object) that later went open source in OSGeo. After returning to Europe, he worked as a geospatial expert for both private and government organizations focused on interoperability.
A 1.142Mb PDF of this article as it appeared in the magazine complete with images is available by clicking HERE