Project Overview
In 2015, this project was delivered as one initiative within an annual public-sector IT portfolio. Its goal was to build a spatial visualization decision-support platform, not just a 3D display environment. The platform had to bring foundational spatial data, 3D models, 2D thematic layers, scheme data, spatial-analysis functions, indicator calculation, and business-review workflows into one working environment.
The project was credible and difficult because five things had to close together: data, models, functions, business scenarios, and evidence. A 3D scene alone would not prove value. A long feature list would not prove operational readiness. The platform had to show that users could import a scheme, locate it in the spatial scene, query its objects, calculate indicators, compare alternatives, run analysis, and use the results in a review discussion.
For public release, this case does not disclose the real city, organization, internal system names, exact datasets, infrastructure details, or vendor information. It keeps the project facts that matter for management: multi-source data, 2D and 3D linkage, several analysis modules, trial-operation issues, function-chain testing, and acceptance evidence built through implementation rather than invented at the end.
Project Objectives and Scope
The project objective was to create a visual, analytical, review-ready, and extensible decision-support platform. Users needed to browse spatial data, manage schemes, run spatial analysis, query and measure objects, edit planning-related objects, and present results from the same platform.
The delivery scope can be grouped into five capability areas. The first was scene browsing: layer management, 2D and 3D linkage, roaming, viewpoints, annotations, thematic maps, and visual scene effects. The second was scheme review: scheme import, scheme management, indicator viewing, indicator calculation, scheme comparison, and spatial-constraint checking.
The third area was spatial analysis, including sunlight, line-of-sight, skyline, height-limit, green-space, watershed, and cut-fill scenarios. The fourth was query, measurement, and assisted editing, including distance, area, attribute, spatial-condition queries, 2D object editing, 3D object editing, and scheme-object editing. The fifth was system integration: multi-source data fusion, 2D overlay, 2D and 3D linkage, rapid modeling, and unified data management.
These capabilities were interdependent. A scheme imported into the platform had to be locatable, queryable, comparable, and analyzable. A spatial-analysis result had to be understandable in the same review context. A 2D object and its 3D representation had to remain consistent enough for users to trust the workflow.
Project Nature
This case should be treated as a single project. It belonged to the 2015 annual IT portfolio, but it had its own platform objective, scope, data foundation, testing boundary, and delivery result. It did not depend on another portfolio project being completed first, so it should not be described as a programme.
The main management object was not hardware, machine-room construction, or field installation. It was a software and data capability: requirements, data readiness, model integration, functional modules, 2D/3D linkage, test scenarios, trial-operation feedback, and acceptance evidence.
The final result is better described as decision-support capability rather than a 3D system. The platform connected spatial data and review workflows so that users could compare schemes, calculate indicators, analyze spatial impacts, and discuss results on a common visual and data foundation.
Key Delivery Challenges
The first challenge was data variety. The project involved foundational spatial data, 3D models, 2D thematic layers, scheme data, and extended underground-facility or spatial-reference data. Whether a function could work depended on whether the data could be accessed, transformed, aligned, linked, displayed, and used for analysis. Tracking software development alone would have been misleading.
The second challenge was the risk of confusing visual effect with business value. Spatial visualization platforms can easily become impressive demonstrations. But the real value comes from supporting review decisions, indicator calculation, spatial constraint checks, and analytical conclusions.
The third challenge was 2D and 3D consistency. The platform had to preserve the efficiency of 2D data management while using 3D scenes to express spatial relationships. Coordinates, layers, attributes, objects, queries, analysis results, and view navigation all had to stay consistent enough for users to trust the platform.
The fourth challenge was fragmented testing. Scene browsing, scheme review, spatial analysis, query and measurement, assisted editing, underground-facility analysis, and system integration could each pass single-function checks while still failing as a working chain.
The fifth challenge appeared during trial operation. Issues such as client-environment behavior, attachment viewing, page response, and individual analysis interactions were not necessarily severe in isolation, but together they affected user confidence and had to be closed before formal operation.
Management Framework
I managed the project through five connected layers: scenarios, data, modules, functional chains, and evidence. The scenario layer translated broad requirements into review and analysis situations that could be tested. The data layer verified whether datasets and models could support the intended functions. The module layer reduced integration risk. The functional-chain layer tested real user paths. The evidence layer connected requirements, tests, trial-operation feedback, issue closure, and acceptance materials.
This framework helped avoid two common mistakes. One mistake is to overvalue attractive 3D effects while under-managing business scenarios. The other is to check off individual functions while ignoring whether data and workflow actually close. A decision-support platform is only ready when data is usable, functions run, scenarios close, users can operate it, and evidence supports acceptance.
In practical management, each major function group was linked to data conditions, test scenarios, and acceptance evidence. Scheme review was not only about importing a scheme. It had to support locating, querying, comparing, calculating indicators, and discussing review results. Spatial analysis was not only about clicking an algorithm. It had to use appropriate input data and produce outputs that business users could understand and verify.
Scenario-Based Requirement Management
At the beginning, I did not treat “build a spatial visualization platform” as a list of menus. I translated it into testable scenarios: browse foundational spatial data, import a scheme, view and calculate indicators, compare alternatives, run spatial-impact analysis, query object attributes, link one location between 2D and 3D views, and use the result in a review conversation.
This changed requirement discussions. Instead of asking only whether a function should exist, the project team had to explain which scenario it supported, what its input was, what output it produced, how it would be tested, and what evidence would prove it worked.
Scenario-based management also controlled scope expansion. Visualization projects can accumulate more display effects and analysis tools than the delivery window can safely absorb. By tying functions back to review, calculation, comparison, query, analysis, and linkage scenarios, I kept the project focused on capabilities that mattered for decision support.
Parallel Calibration of Data and Functions
Multi-source data was the project foundation. Data access, format conversion, coordinate alignment, attribute linkage, model loading, layer organization, and analysis adaptation were managed in parallel with software development. I did not treat data preparation as something to be filled in after the functions were built.
The practical rule was that each important function should be checked against realistic data conditions. Scene browsing had to show whether layers loaded and switched correctly. Scheme management had to show whether scheme objects could enter the 3D scene and remain identifiable. Indicator calculation had to show whether fields and scheme objects matched. Spatial analysis had to show whether models, terrain, thematic data, or constraint data could actually support calculation.
This reduced late integration risk. If data problems appear only before acceptance, they can affect functions, screens, performance, and test results at the same time. Treating data as a delivery condition exposed format, coordinate, attribute, model, performance, and business-definition issues earlier.
Modular Development and Integration Control
Because the platform covered many functions, I used module boundaries to control complexity. The main function groups included scene browsing, scheme review, spatial analysis, query and measurement, assisted editing, underground-facility analysis, and system integration. Each group needed its own inputs, outputs, test items, and issue list.
Modularity was not used to let teams work in isolation. It was used to make problems diagnosable. A display issue could come from data loading, model processing, layer configuration, or user interaction. An abnormal analysis result could come from input data, algorithm parameters, object relationships, or output presentation. Clear boundaries reduced circular handoffs when issues appeared.
During integration, I focused on relationships across modules: whether scheme objects could be queried and analyzed, whether 2D data could be located in the 3D scene, whether analysis results returned to the review context, and whether assisted editing changed object attributes in ways that later statistics or queries could still use.
Testing, Trial Operation, and Issue Closure
Testing had to follow business chains, not just menus. Examples included scheme import, object location, indicator viewing, scheme comparison, spatial analysis, and result presentation; or layer switching, object query, attribute viewing, 2D/3D linkage, and measurement output. Chain-based testing made it possible to find breaks that single-function testing would miss.
The available project material showed that many function points passed verification. The management task was to place those function points into realistic sequences: whether the output of one action could be used by the next, whether users could return from an analysis result to the right spatial object, and whether the result could support a review discussion.
Trial operation exposed issues around client environments, attachment viewing, page response, and certain analysis interactions. I treated these as a formal corrective-action list instead of scattered user comments. This gave the team a controlled way to improve stability and user confidence before formal operation.
Acceptance evidence was built progressively through the project: requirements and design materials, functional test records, issue-closure records, trial-operation feedback, training or usage guidance, and handover materials. This made acceptance a continuation of controlled delivery rather than a document-assembly exercise at the end.
Project Outcomes
Through scenario-based requirements, parallel data-function calibration, modular development, chain-based testing, and trial-operation issue closure, the project moved beyond a 3D demonstration and became a practical decision-support platform.
The delivered capability included scene browsing, scheme review, spatial analysis, query and measurement, assisted editing, and system integration. It supported scheme import, indicator calculation, spatial comparison, dynamic simulation, 2D/3D linkage, and thematic analysis.
The management outcome was equally important. Data usability, functional usability, scenario usability, and acceptance evidence were managed as one control chain. This reduced the risk of having a visually impressive interface without usable data, isolated functions without workflow closure, or passed tests without user readiness.
Reusable Lessons
First, visualization platforms should not be accepted by display quality alone. The 3D interface must serve business judgment, scheme comparison, indicator calculation, and analytical conclusions.
Second, data usability must be managed as a main workstream. Access, coordinate alignment, attribute linkage, model loading, and performance all affect whether the platform can actually be used.
Third, complex platforms need clear module boundaries. Boundaries reduce development conflict and make testing, issue diagnosis, and acceptance more controllable.
Fourth, testing must cover the full functional chain. A passed button does not prove a usable decision-support workflow. Import, browse, query, analyze, compare, and output should be tested as connected actions.
Fifth, trial operation is the final management buffer before formal operation. User feedback, environment issues, performance experience, and operation habits should be captured as issues and closed with evidence.
Review Summary
This project shows that the real challenge in a spatial visualization decision-support platform is not producing an attractive interface. The real challenge is making data, functions, scenarios, testing, and acceptance close together. The project became credible because it was managed through verifiable scenarios, realistic data conditions, module boundaries, functional-chain testing, trial-operation feedback, and progressive evidence. That is what turned multi-source spatial data and 3D visualization into practical decision-support capability.