Steps, points of attention and risks when replacing an ERDAS Apollo environment for aerial imagery with a cloud-native tile server.
Step 1 is the inventory: which layers does Apollo publish, through which protocols, in which coordinate system, with which styles and for which users or applications. Step 2 is to secure and check the sources: where are the ECW and GeoTIFF files, can the conversion read them and are the coordinate systems correct. Step 3 is to convert and publish: the files go into the GEORIZON tile format and become available as WMTS, OGC Tiles and WMS. Step 4 is to test in parallel, with the old and the new service side by side. Step 5 is to switch the endpoints in QGIS projects, web viewers and applications. Step 6 is to decommission the old environment once nobody uses it.
Source files: ECW is a Hexagon format. Check up front that the conversion can read your files; that is part of the intake. Endpoints: URLs in existing projects and applications change, so plan the switch and keep the old service until everyone has moved. Other functions: anything that is not a raster layer, such as vector publishing, catalogue functions or custom integrations, is not taken over as a matter of course. What is and is not taken over in your environment is agreed during the intake. Lead time: precaching and a CDN keep layers fast for many users, but the first conversion takes longer as the archive grows.
No server of your own to manage, patch or scale. Access per dataset, area and duration, with usage metering. And the same data also in the viewer, through the API and as a download. ERDAS Apollo is a Hexagon brand. 360GEO is not affiliated with Hexagon and names the product only to indicate which environment is being replaced.
