A maintenance planner opens a map, selects an asset and sees an overdue work order. The field team recognizes the location but says the equipment was replaced months ago. The map, maintenance system and project spreadsheet all appear reasonable. They disagree about what the asset is and which version of its history matters.
For a Calgary industrial business connecting GIS and enterprise software, this is a familiar kind of integration problem to investigate. The map is the visible surface. Underneath it are identifiers, coordinate systems, revision dates and ownership decisions. Connecting APIs without resolving those differences can make inconsistent data easier to distribute.
Location is useful context, not an asset identity
Consider an illustrative equipment-maintenance project. The GIS contains a feature identifier. The maintenance system uses an equipment number. A capital project refers to a drawing tag, while a spreadsheet records a familiar nickname.
Those values may refer to the same physical object today, but they will not necessarily change together. Equipment can be replaced in the same location. A line can be divided into several segments. A work order can refer to a functional position rather than the currently installed component.
The integration needs to preserve those distinctions. A stable relationship between records is more useful than matching names every night. Where the relationship is uncertain, the system should expose an exception for review rather than choose the nearest point and present it as established fact.
Calgary data shows why coordinate assumptions matter
Open Calgary's City Boundary dataset identifies its map projection as EPSG:4326 WGS84 and its update frequency as irregular. Those are properties of that dataset, not a declaration that every Calgary spatial source uses the same representation or refresh schedule.
The Alberta Energy Regulator's OneStop help resources list separate shapefile templates using NAD83 10TM and NAD83 CSRS 10TM for relevant submissions. Their existence provides a practical reminder that a coordinate pair is incomplete without its reference system and context.
A project importing municipal, engineering and regulatory data should identify each source's reference system explicitly. Transformation should be a documented operation with appropriate geospatial review. Merely assigning a new label to existing numbers does not perform a valid transformation.
Trace a disagreement before designing the dashboard
Take a small set of representative records and follow them from source to screen. Include a recently replaced asset, a retired asset, a changed geometry and a record that has no trustworthy match.
For each, establish the owner of the identifier, the effective date of the change and the source that may update each field. A maintenance platform may own work status while GIS owns geometry. An engineering system may own design revisions without being the authority for installed equipment.
The application should show when a value was obtained and which source supplied it. That does not require overwhelming every user with metadata. A concise provenance panel can answer an engineer's question while keeping the ordinary planner's view readable.
This exercise often reveals that the desired integration is a set of specific relationships, not a universal master record that every department will immediately accept.
Treat exceptions as part of the product
A nightly synchronization can succeed technically while creating the wrong business result. It might copy a retired asset back into an active list because the source system retains historical records. It might overwrite an intentional correction with an older export.
Design visible outcomes for those cases:
- ▸A missing identifier creates a review task with the original source reference.
- ▸An unexpected coordinate system stops that import from publishing geometry.
- ▸A conflicting revision preserves both versions until an owner decides.
- ▸A deleted or retired source record follows an agreed lifecycle rule.
- ▸A repeated import updates the intended record without duplicating the work.
The last point is especially important when jobs are retried after an interrupted transfer. Our guide to idempotent data pipelines explains how repeatable processing reduces the damage from ordinary operational retries.
Extend GIS, add an integration layer or replace software?
Existing GIS and asset-management products may already provide connectors, transformation tools and configurable workflows. Test those capabilities before commissioning a new map application. A supported connector can be valuable when its data model matches the business relationship you need.
A custom integration layer becomes useful when several systems need a shared mapping, a controlled exception queue or a specialized operational view. Keep the layer focused: it should make source relationships reliable, not quietly become the unofficial owner of every field.
Replacing a major system is a separate decision. A disagreement between identifiers does not, by itself, prove that the GIS or maintenance platform must be replaced. Compare the cost of repairing the handoff with the broader migration and training obligations of replacement.
What to include in a realistic integration estimate
Connection count is only one cost driver. The quality of historical identifiers, number of coordinate systems, source-access restrictions, geometry complexity and frequency of changes can matter more. So can the time needed from internal people who understand ambiguous records.
Use a discovery sample that includes exceptions rather than only clean demonstration data. Ask the delivery team to show the proposed mapping, unresolved questions and a repeatable import before estimating a complete historical migration. Our integration statement-of-work guide helps define ownership, retry behaviour and operational responsibilities across systems.
Public data availability does not establish permission to automate every regulatory submission or access every operational system. Verify source terms and supported interfaces for the actual workflow. A useful first release can simply provide a trustworthy read-only view and an exception queue.
TuniCyberLabs can work remotely with Calgary teams on the software and integration layer. Explore custom software development, then describe the asset handoff you need to fix. Name the systems, the conflicting identifiers and the decision users cannot currently make with confidence.