Simple data and feedback exchange can sound like a nightmare when one party operates in a design space and another uses a real-world location.
Architects, ecologists, structural engineers, and transport engineers are just a small set of professions involved in any large-scale development that often struggle with this issue.
What makes this professional division so sharp, why is it causing so many troubles, and what can we do about it?
AEC Data vs Geospatial Data
Geospatial Information Systems (GIS) and Architecture, Engineering, and Construction (AEC) data serve different but complementary purposes.
Geo-data typically refers to spatial data representing the geographic location and attributes of features on the Earth's surface.
AEC data contains information on built environments' design, construction, and maintenance.
While AEC data is more focused on the specifics of building projects, geo-data provides the broader context within which these projects exist.
Evolution of the fields
The geospatial field goes much further regarding data compatibility, storage, sharing, and optimization. At the same time, the AEC industry oversees more and more of the solutions being locked inside the infrastructure of the large tech monopolies.
So, how did we get here, and what are the key differentiating factors?
- Data representations
Geospatial: In geospatial, data came first, and semantics came second. The first GIS application was developed in the 1960s in Canada to merge the datasets from different regions into a centralised one. Both commercial and open-source software have since been using the same representations of real-world objects, ensuring compatibility and interoperability across various systems.
AEC: Architects, in turn, started drafting on paper by agreeing that different types of lines would mean different parts of the wall on the floorplan. Engineers would use different sets of lines (and sometimes even similar) to depict infrastructural elements. AEC software developments have started off by allowing you to replicate those paper drafts in a digital shape and assign any meaning to them, depending on the convention you use in your discipline, company or a software.
- Data lifecycle
Geospatial: data often serves as a reference point, representing relatively static elements such as geographic features, administrative boundaries, and infrastructure. Once collected and validated, geospatial data rarely changes shape, making it easier to standardise and share. The stability of geospatial datasets allows for the creating of comprehensive databases that serve as reliable data sources.
AEC: In contrast, AEC data lifecycle is typically in a continuous state of development, undergoing numerous iteration loops as designs evolve and refine. Data interoperability formats like the Industry Foundation Classes (IFC) format, designed to facilitate interoperability in the AEC sector, provide limited flexibility, particularly during the early, iterative design stages.
- Data sharing
Geospatial: The intention behind data sharing differs significantly between the two fields. Geospatial data is generally intended for public use and is often managed by governments and public institutions. This data is typically accessible for research, policy-making, urban planning, and various public services. The open nature of geospatial data encourages widespread use and integration into numerous applications, from monitoring the weather to checking the bus arrival time.
AEC: In most cases, the architecture and construction data is proprietary and confidential, created as a commercial product to be sold to the client. Every piece of the documentation is meant for a restricted number of professionals; hence, the data protection mechanisms were much more in focus than the data sharing ones.
- Final deliverables
Geospatial: Both fields need great visuals when shared with the broader audience! Here, the roles flip: GIS data uses predominantly 2D semantics with prescribed colours, linewidth and fill type for each type of data explained through the map legend. While the data representation on the map can be intentionally distorted with the custom data scale, map projection and the choice of visualization technique, it is still considerably simple to interpret and find answers to your questions, as no information can escape your eye.
AEC: In addition to the technical drawings, AEC projects require realistic 3D visuals, often subjective and tailored to individual taste. Architectural renders can convey the author’s message by a choice of angle, lighting and entourage, and hide the flaws in the complex drawings that require expertise to find out.
Despite these differences, the lines between geospatial and AEC fields are blurring, particularly with technological advancements. Indoor mapping, digital twins, and integrating Internet of Things (IoT) devices bring these domains closer together. However, fundamental differences in the approaches remain.
Speckle: The Data Bridge
How is Speckle helping to bridge these gaps? Due to being the most inclusive and flexible, to date, data structure in AEC, Speckle treats any data in precisely the same way, and allows you to add as many details and as specific meanings as needed.
It doesn't discriminate the data being "design" or "real world", "realistic" or "semantic". In every software, you get the most complete version of your data, which this software supports. With flexible Speckle data format, OSM buildings can become 3D Meshes in Blender, and BIM Floors can become Polygons with attributes in QGIS.
Speckle has gone a long way in developing the data schema and its interpretations, which would fit the way major AEC software works. Naturally, it was more straightforward to integrate geospatial data formats later on - due to the industry's much better standardisation effort.
Now that we have all the data our project needs, both AEC and geospatial, how can we leverage the benefits of storing it with Speckle? By using the best of both worlds!
How Speckle Is Merging AEC and Geospatial Data
- Data representations: realism vs. semantics?
You don’t need to choose. You can paint the grass green or purple and draw your walls by centreline or outline. Your data is not just a 3D drawing; it has a detailed structure that you can always refer back to and check any attributes and metadata stored together with your model.
Moreover, some of the inter-software workflows can be tailored even more with Speckle Mapper, where you can manually specify the “mapping” of, for instance, Rhino Surface to a Revit Floor or a QGIS Raster DEM to a Revit Topography.
AEC vs. Geospatial score 1 : 1
2. Data lifecycle: are you publishing the data or iterating over it?
Both. Speckle uses a Github-like versioning system for your models, which means you can always access either the specific version of it or the latest available state.
Unlike the traditional AEC practice of sharing data through files, Speckle uses a geospatial data-sharing approach - sharing URLs and applying an authentication layer. Just copy your link and send it to the colleague, or embed it through the iframe like the example below:
AEC vs. Geospatial score 1 : 2
3. Data sharing: are you sharing or protecting your data?
Also both! Any user or API client can consume publicly shared Speckle data, and both will need valid credentials and permissions to access a private project. The authentication layer protects the data, and it can also be hosted in your own Speckle server, which is location- and provider-agnostic.
AEC vs. Geospatial score 2 : 2
4. Final deliverables: what about visuals?
Some GIS users would be sceptical about using GIS data as 3D data, as architects and engineers might try to avoid discussing georeferencing their designs.
In both cases, the issue is mainly technical, as architectural data is inherently geolocated, and geospatial data naturally exists in a 3D space (Digital Twins is not a futuristic technology; it’s just real-world data and design data properly combined).
With Speckle Viewer, you can produce high-quality photorealistic visuals in 3D (for example, of your building complex), yet supported by semantic data, such as land use and cadastral boundaries.
Here is a mixed-data model of the FOSS4GE 2024 conference venue, combining GIS and CAD data:
AEC vs. Geospatial score 3 : 2.
The Cherry on Top: Data Compatibility
Have we mentioned plugin-less data exchange yet? Speckle was built around the AEC - industry, with the data types and formats fragmented and wrapped into proprietary data formats. The only way to get your data out in the purest format possible is before clicking the "Save" button and locking your data inside *.youcannotopenthiswithoutlicense file.
Speckle has developed plugins that convert your data directly from your software of choice and store it on the Speckle server in an open, easily searchable format, where you have complete control over writing, reading and manipulating your data.
This has been before stepping into the geospatial field. If there is a central lesson we can learn from the geospatial data - it's about uniform data-sharing protocols.
AEC vs. Geospatial score 3 : 3. It’s a draw.
Lesson from the Geospatial data
The Open Geospatial Consortium (OGC) is an organisation representing both major industry players and neutral parties, which facilitates geospatial data sharing and exchange.
Historically, they have developed multiple protocols allowing data streaming and consumption, such as WFS, WMS, etc.
Each protocol would need to be implemented both on the sharing side (server) and the receiving/reading side (client). Since 2018, the new protocol - OGC API - has started to serve as a single connection point for both the server and the client.
Major GIS applications (like QGIS, ArcGIS) and mapping libraries (like Leaflet) introduced implementations to receive/view the data streamed through OGC API protocol - be it individual features, records (geometry-less features) or tiles.
Speckle is not staying aside! With its most flexible data structure, server storage, authentication and URL data sharing, we are just one step apart from making Speckle data accessible to any client using the OGC API without extra plugins or scripts.
Yes, this means that a master plan drawn by an architect in AutoCAD can be instantly mapped as a WFS layer via Speckle.
What’s next?
Are you excited to see where this is going..? We are! Join us on September 9th 2024, at the QGIS User Conference to hear more about it!
In the meantime, find out how Speckle can simplify your data management tasks and enhance your workflows. Join our GIS Community, and don't miss any GIS any new releases!
Subscribe to our newsletter to stay in the loop with our SpeckleGIS articles!
