An engineering firm has spent three years prescribing the same CMMS-plus-GIS platform to different private industrial clients. The fifth project brings an industrial group with sites spread across the Iberian peninsula: one plant in Braga, another in Vilagarcía, a logistics center in Torrelavega, a third plant in Girona and a solar portfolio in Seville. The firm delivers the first site's asset register in the local Portuguese system, PT-TM06/ETRS89. The second in ETRS89 UTM 29N. The third in UTM 30. The fourth in UTM 31. The fifth back to UTM 30. Six months after the fifth project goes live, the group's central asset manager asks the vendor for a consolidated portfolio view. The platform tries to overlay the five projections and the result is unusable: sites appearing kilometers away from where they should be, layers dropping off the active projection's extent, distances between sites at inconsistent scales. The engineering firm gets the call. No quick intervention is available: every coordinate in every site's master was recorded in its local projection, and re-cross-referencing means reprojecting every geometry and validating every transformation one by one.
The decision about the coordinate system of the asset register is one of the first taken in a CMMS-plus-GIS project and one that bakes permanently into the result. Undoing it is not impossible, but it is costly, slow and carries the risk of precision loss. Engineering firms often treat it as a configuration detail and inherit the usual projection of the working area without pinning it explicitly in the RFP. That initial silence is what becomes, three or five years later, the problem the scene above describes.
What the SRS decision actually decides
Four consequences live for the whole life of the asset register from the moment the coordinate system is chosen. The first is whether portfolio-scale spatial queries work at all. An asset register stored fully in one geodetic system supports any global spatial query; a register that mixes projections across sites needs to transform each element on every query, with the performance loss and the accumulated error risk that entails. The second is interoperability with the client's other GIS systems: cadastre, official cartography, insurer layers, third-party services. Transformation is always possible; the point is whether it is direct or requires an extra step per project. The third is the precision floor for distance and area calculations at portfolio scale. A projection optimized for a specific zone degrades outside it; a global geographic projection degrades when displayed as a plane. The trade-off is real and must be accepted consciously. The fourth is the complexity of transformations that third parties need to consume the data: when each site lives in a different projection, every external consumer must handle system detection and transformation logic.
The three classic setups for distributed portfolios in Iberia
A private operator with a portfolio distributed across the Iberian peninsula classically faces three start-up options, each with its own trade-off. The first is a local projection per region: ETRS89 UTM 29N, 30N or 31N depending on the Iberian zone matching the site, with PT-TM06/ETRS89 for the Portuguese scope. This setup maximizes precision of per-site spatial operations and minimizes cross-portfolio interoperability. The second is a single geographic system: ETRS89 in geographic coordinates (latitude, longitude) for the entire portfolio. This setup unifies the portfolio view and transformations to other systems are done on the fly; its trade-off is that complex spatial operations require temporary projection to a local system. The third is Web Mercator (EPSG:3857) for visual presentation: the standard of Google Maps, OpenStreetMap and every web-map tool. It is useful as a rendering system and disastrous as a geodetic calculation system, because it introduces distortion that grows with latitude.
The sensible reading for a distributed private portfolio is not to choose one of the three, but to separate the three functions and use the appropriate system for each: storage in the global geographic system, calculation in the appropriate local projected system and presentation in the web-map system. A modern platform supports the three layers simultaneously by design.
The three lines the RFP should pin
An engineering firm that wants to close both the vendor's and the client's ambiguity about the coordinate system should include three specific lines in the technical RFP. The first is the primary storage SRS: the system in which the asset master lives inside the platform's database. The sensible convention in Europe is ETRS89 in geographic coordinates, with the explicit EPSG code. The second is the default presentation SRS for the operational browser: typically Web Mercator, which aligns with the visual experience of every other web map the field user or the asset manager sees daily. The third is the geodetic calculation system or systems enabled: which UTM will be used for distance and area queries in each region of the portfolio. A serious platform can dynamically activate the appropriate calculation system for the scope of the query without the user needing to worry; but that only works if the RFP specifies it upfront.
Multi-SRS by design
At Maptainer, multi-SRS handling closes by design from the PostGIS layer up: every geometry is stored in the global geographic system, rendered on the fly in Web Mercator for the browser and projected on demand into the appropriate local system for geodetic operations. The transformation is transparent to the end user and does not require an irreversible start-up decision. When the client's portfolio grows into a new region, the system adds the corresponding local projection without refactoring the existing sites. That flexibility is not designed as convenience: it is the only technically honest way to sustain a distributed private portfolio whose geographic extent the asset manager cannot predict at RFP time.
The start-up decision as professional protection
The classic conversation at the start of a CMMS-plus-GIS project usually skips over the SRS decision and drops straight into the master load and the workflow definitions. The engineering firm that dedicates fifteen minutes of the start-up to pinning the three lines above in the RFP is doing work the client is not asking for in that moment and that the client will thank them for three years later. It is not an optional technical refinement: it is professional protection of the portfolio's future flexibility. And it is a concrete example of the difference between a prescription that wins the project in front of the firm and a prescription that wins the client's next five years.