CONNECT. VALIDATE. INTERPRET.
Geotechnical Monitoring Data Integration
GeoSmar connects monitoring, survey, logger and satellite data from different systems into a traceable engineering workflow for QA/QC, cross-sensor analysis, alerts and engineer-reviewed reporting.
Data Integration
One engineering view across different monitoring systems.
A monitoring project may already contain total-station observations, GNSS, geotechnical instruments, wireless loggers, manual readings, environmental data, survey files, construction records and satellite-derived ground-motion information. The integration problem is not simply how to put every number on one dashboard. It is how to preserve source, time, units, location, instrument context and data quality so that different measurements can be compared without losing engineering meaning.
Fragmented data
Separate portals, spreadsheets, logger exports and survey files make cross-checking slow and increase the chance that important context is missed.
Traceable integration
Keep each observation linked to its source, timestamp, instrument, units and relevant metadata while normalising the information needed for comparison.
Engineering intelligence
Use integrated data to review trends, compare neighbouring measurements, check thresholds, investigate anomalies and prepare engineer-reviewed outputs.
Integration Architecture
Connect the evidence without forcing a platform replacement.
GeoSmar is designed to sit above the data sources a project already uses. The practical objective is a vendor-neutral integration layer: acquire or receive the data, preserve provenance, normalise what must be comparable, run QA/QC, and then expose a controlled engineering view for analysis, alerts and reporting.
Data integration is not the same as data aggregation.
Aggregation can place many datasets in one location. Integration goes further: it defines how those datasets relate to the same asset, construction stage, reference system and engineering question. GeoSmar treats that relationship as part of the technical scope.
Data Interfaces
Design the interface around the project, not one vendor.
Established monitoring platforms already use several integration routes. Official documentation from Leica Geosystems describes third-party sensor/software connections, API access, open interfaces and SQL storage. Bentley documents REST APIs for third-party sensor data. Worldsensing documents API, MQTT and FTP/FTPS export. Sixense describes integration of automatic sensors, manual measurements, total stations, InSAR, third-party data, documents and construction-progress information.
| Data source | Typical integration route | What should be preserved | Engineering use |
|---|---|---|---|
| Total station / prisms | Platform API, database export or approved file exchange | Point ID, XYZ, reference setup, epoch, units, status | Displacement, settlement, convergence, asset movement |
| GNSS | API, MQTT or monitoring-platform export | Coordinates, solution status, timestamp, reference information | Long-term 3D movement and corridor-scale behaviour |
| Geotechnical sensors | Logger API, FTP/FTPS, MQTT, database or CSV export | Raw/engineering value, calibration, channel, units, health metadata | Pore pressure, inclination, settlement, strain, load and movement |
| Manual readings | Controlled upload or mobile collection workflow | Observer, date/time, instrument ID, units, validation status | Verification, low-frequency measurements and fallback readings |
| InSAR / GIS layers | Approved file import, geospatial service or project-specific data feed | Location, reference period, line-of-sight context, source and processing metadata | Wide-area screening and comparison with in-situ monitoring |
| Construction / asset records | Controlled import, project database or document link | Activity, location, stage, time and revision | Correlation of movement with works and asset condition |
Why not prescribe one protocol for every project?
Where do open standards fit?
QA/QC & Data Model
Before datasets are compared, their meaning has to be aligned.
A robust integration workflow should make it possible to trace an engineering value back to the original data source and its metadata. GeoSmar therefore treats naming, time, units, sensor status and project context as part of the integration scope rather than as housekeeping after the dashboard is built.
- Unique instrument and point identifiers
- Source system and data ownership recorded
- Timestamp and time-zone convention defined
- Engineering units explicitly stored
- Coordinate and elevation reference documented
- Baseline or reference epoch retained
- Calibration and conversion information available
- Sensor health / communication status separated from movement data
- Missing, duplicated and revised records distinguishable
- Manual corrections and overrides traceable
- Trigger values tied to the correct parameter and asset
- Data transformations documented before engineering use
Is the expected data present?
Review gaps, delayed transmissions, stale channels and missing metadata before interpreting a flat or apparently stable trend.
Is the value technically credible?
Check outliers, abrupt shifts, impossible values, duplicated timestamps and source-system warnings before treating an observation as movement.
Does it agree with neighbouring evidence?
Compare related instruments, survey observations, groundwater response and construction sequence where those datasets are available and relevant.
Alerts & Reporting
Integrated data should reduce noise, not create more alarms.
Once data from different systems can be trusted and compared, the next task is deciding what deserves attention. GeoSmar separates data availability, instrument health, threshold exceedance and engineering significance so that one automated event is not mistaken for a complete engineering conclusion.
Data availability
Is the source online, current and delivering the expected frequency?
Measurement health
Does the channel show abnormal behaviour, communication issues or metadata that requires verification?
Trigger logic
Has the correct threshold been applied to the correct parameter, asset and project stage?
Interpretation
Is the change credible, persistent, spatially consistent and significant in the actual engineering context?
Can the reporting workflow be automated?
Can alerts combine more than one data source?
Project & Contract Interfaces
Most integration failures begin before the API is connected.
On a real project, the data interface should be defined alongside responsibilities. The contract or technical specification should make clear who owns the data, who maintains each source, what happens during outages, who changes trigger logic and which record is authoritative when multiple platforms show different results.
Data rights & credentials
Define raw-data availability, API/export permissions, user roles, third-party access, retention and handover requirements.
Latency & availability
Define expected update frequency, outage behaviour, buffering, retransmission, source-health reporting and planned maintenance.
Change authority
Define who can change thresholds, calibration factors, instrument metadata, asset mapping, alert recipients and calculation rules.
Recommended data-interface schedule
- Source systems and owners
- Interface method and credentials
- Data fields and engineering units
- Timestamp convention
- Coordinate / asset hierarchy
- Expected sampling and transfer frequency
- Quality and health flags
- Outage / backlog behaviour
Recommended governance schedule
- Authoritative source for each parameter
- Raw vs processed data retention
- Revision and audit trail
- Alarm and escalation responsibilities
- Manual verification route
- Cyber / access restrictions
- Project close-out and data handover
- Change-control process
Applications
The same integration logic can support very different assets.
Data integration is most useful where the engineering question crosses system boundaries. A tunnel may need survey, convergence, groundwater and construction data. A railway corridor may combine track geometry, earthwork sensors and GNSS. A mine may combine slope radar, prisms, piezometers and InSAR. The data model should follow the engineering problem rather than forcing every asset into the same dashboard template.
Operational assets + adjacent works
Combine track or structure movement, survey, groundwater and construction-stage information to review effects on operational infrastructure.
Movement + groundwater + sequence
Relate settlement, wall movement, convergence, pore pressure and work stages rather than reviewing each instrument family in isolation.
Wide-area + in-situ monitoring
Bring together local instruments, survey, slope monitoring and satellite-derived information for a broader view of ground behaviour.
Movement + hydrology + weather
Compare displacement indicators with rainfall, groundwater or other environmental records where those mechanisms are relevant.
Asset + approach + ground
Integrate structural movement, approach settlement, embankment behaviour and corridor-scale observations around the same asset.
Construction influence + asset sensitivity
Combine settlement, vibration, tilt, groundwater and adjacent-work information with clear access control and reporting responsibilities.
Official Industry Context
Open interfaces and multi-source monitoring are already established practice.
The examples below are included only as official industry references. They are not GeoSmar projects and do not imply any partnership, endorsement or commercial relationship with GeoSmar.
4D Control: multiple monitoring sources in one environment
Trimble states that T4D manages geodetic, environmental and geotechnical sensors in a single platform, with sensor management, analysis, visualisation, alarming and reporting. Trimble’s official monitoring material also describes total-station, GNSS and geotechnical-sensor data being brought together.
GeoMoS: third-party sensors, open interfaces and API access
Leica states that GeoMoS can connect to monitoring sensors or software from Leica or third parties, provides API access, supports open-interface standards, stores data in SQL and applies validation, filtering and outlier handling.
iTwin IoT: REST interfaces for third-party sensor data
Bentley’s Sensor Data service provides REST APIs for third-party sensor manufacturers and data sources. Its documentation describes connections that can be hardware-based or software-based, including API and FTP routes, and exposes time-series sensor observations through documented endpoints.
CMT: local or cloud monitoring with third-party export
Worldsensing documents FTP/FTPS, MQTT and API data export in its CMT software family. CMT Edge is designed for standalone local networks and can operate without internet access, while still supporting export to third-party tools.
Beyond Monitoring: sensor, survey, InSAR and project information
Sixense describes a monitoring information hub that integrates geotechnical, structural and environmental sensors, manual measurements, total stations, InSAR, third-party systems, documents, photos and construction-progress data in one environment.
OGC SensorThings API: heterogeneous sensor observations
The Open Geospatial Consortium defines SensorThings API as an open, geospatial-enabled and unified way to interconnect IoT devices, data and applications, including standard management and retrieval of observations and metadata from heterogeneous sensor systems.
Official Case References
What real integrations reveal about the engineering problem.
Public case material is useful when it shows how different systems were actually connected. The cases below are drawn from the technology providers’ own official publications and are clearly separated from GeoSmar experience.
Ilha Solteira & Jupiá
Worldsensing reports that an upgraded monitoring architecture used LoRaWAN and secure API integration with the management platform, allowing interoperability with CTG Brasil’s corporate systems and supporting continuous readings and traceability.
Dornisporn rock cliff
Worldsensing’s official case states that CMT Edge managed the monitoring network and connected through API to the Huggenberger-Monitor analysis system, which could be accessed by the Swiss Federal Roads Office.
ANDRA monitoring information system
Sixense’s official platform page includes client feedback describing an information system developed since 2001 to manage more than 10,000 sensors across an underground laboratory, a piezometric network and environmental surface stations.
GeoSmar Role
A vendor-neutral engineering layer between systems and decisions.
GeoSmar does not need to replace a client’s existing logger, monitoring portal or instrumentation contractor to add value. The intended role is to define the integration logic, review data quality, map the information to engineering questions and create repeatable workflows for monitoring intelligence, diagnostics, independent review and reporting.
Interface definition
Review available systems, data ownership, export methods, metadata and project requirements before deciding how information should be connected.
Engineering data model
Define how instruments, observations, locations, assets, construction stages and trigger criteria relate to one another.
QA/QC rules
Build repeatable checks for completeness, continuity, abnormal values, source health, baselines and cross-sensor consistency.
Analytics & diagnostics
Compare trends and rates across sources to identify changes that merit engineering review rather than merely displaying raw data.
Alerts & reporting
Structure thresholds, notifications and automated reporting so that system events remain distinguishable from engineering conclusions.
Independent review
Provide a separate technical layer for clients who need assurance that integrated data and monitoring conclusions remain traceable and defensible.
FAQs
Data integration questions project teams should settle early.
Can GeoSmar integrate data from different sensor manufacturers?
Does the client need to replace its existing monitoring platform?
Can CSV or Excel files be used?
What is more important: real-time transfer or reliable context?
Can InSAR be integrated with ground instrumentation?
Does GeoSmar use AI to make automatic engineering decisions?
What information should a client send for an initial integration review?
Start a Technical Discussion
Have several monitoring systems but no single engineering view?
Send a sample export, instrument schedule, current platform description or interface specification. GeoSmar can first review what data is available, where the integration gaps are, and whether the problem is best addressed through an interface design, data QA/QC workflow, monitoring intelligence service or independent review.
Official References
Sources used for this technical page.
Only official organisation, manufacturer, developer and standards-body sources are listed below. They are used as industry context and do not indicate a commercial relationship with GeoSmar.