In today’s enterprise asset-management world, users expect more than start-and-end mapping. They need interactive, near-real-time routing with progress updates and predictive barrier avoidance, all integrated as seamlessly as possible. This is the first of two blog posts to show you how we brought network-analysis tools into our customer’s asset/equipment-management website. We leveraged ArcGIS Pro’s powerful network-analysis tools, ArcGIS Enterprise, and GeoBlazor to deliver these capabilities without reinventing the wheel. In this post, you’ll see how we solved each problem in Pro, publishing REST services, some “lightbulb” moments, and then using GeoBlazor to consume those services and bring these capabilities into our customer’s web application.
Before this project, our customer’s web application enabled users to select a piece of equipment (its current location would be the start point) and a destination point, then add some related request information. The application drew a “straight-line” connector to show movement from one place to another. Any “progress” status changes or situational changes were all handled manually. What was missing was true live routing along real networks (roads, shipping lanes, flight paths), progress snapshots at configurable intervals (6 h, 12 h, 24 h, etc.), dynamic barrier avoidance (weather, terrain, equipment-specific constraints), the capability to handle multi-modal situations, and full integration with their existing non-GIS asset-management system.
Rather than try to build out a custom routing engine in our Blazor web application—an approach that would be resource-intensive—we decided to leverage what our organization already had access to and our GIS team. ArcGIS Pro, together with ArcGIS Enterprise, provides robust network-analysis tools and well-documented REST endpoints. GeoBlazor, which wraps the ArcGIS Maps JavaScript SDK in a Blazor-friendly .NET library, enables us to directly interact with our GIS data and any Pro-published services, while working seamlessly with our .NET web app’s Entity Framework, UI components, and existing data models.
Breaking down our primary needs was the initial step in establishing our plan of action. We settled on four services (the first two covered in this blog, the next two in the follow-up):
We started by researching our first dataset—maritime commercial shipping routes. It was fairly difficult to find a solid, complete dataset for testing, but in the end, we identified a good test dataset, though it required cleanup using the Dissolve and Intersect tools.
Next, we exported our features from the service and got our feature class into a file geodatabase. Then we created a network dataset and built our network, unlocking the Network Analysis tools needed for routing.
Because we were doing a route scenario, we used the Make Route Analysis Layer tool to set up our network for the Solve tool. One of the nice parts of creating the tool was that once we successfully tested navigating from one location to another, we had intimate knowledge of the dataset, the service-endpoint requirements, and—importantly—the limitations and capabilities of our routing service. We published the tool to ArcGIS Enterprise, obtained our service endpoint, and began GeoBlazor-web-app integration.
Armed with the request-object schema, we customized the FeatureSet JSON object sent to the service endpoint. Since GeoBlazor’s formal ArcGIS REST JS–GeoBlazor interactions aren’t all complete yet, this required some custom REST methods and JSON to match the schema shapes the service expects.
With our routing endpoint set up on Portal and tested with ArcGIS Online, we processed GIS data gathered from user interactions (the “Stops”) on our web app’s map using GeoBlazor. We packaged the stops into RouteParameters as features, and GeoBlazor sent the data to the routing service. The service returned a polyline FeatureSet, directions info, and other metadata. GeoBlazor then added the route polyline graphic to the map.
A critical PRO TIP emerged when we discovered during testing that we couldn’t cross the International Date Line. We tried different tool configurations, datasets, spatial references—even custom layers with coincidental points on the dateline—but no luck. A conversation between the Network Analysis Team lead and our CTO at the 2025 Esri Developer Summit yielded the golden nugget: “Switch the spatial reference to a polar projection.” We used the North Pole Azimuthal Equidistant (WKID: 102016) and immediately resolved the issue. Remember…only polar projections get you around the world!
Once we had an operational routing service, the next step was setting up progress points along the route. This is less involved: once you have a route polyline, providing position snapshots at set intervals is straightforward. In ArcGIS Pro, we used the Generate Points Along Lines tool. Knowing our web app has access to equipment info (including average speed), we calculated distance per interval. We created the tool by feeding it our solved route and interval calculation, testing it, and then publishing it to Enterprise.
GeoBlazor handles the GIS interaction in the web app: we package the polyline and interval calculation, call the service endpoint, and receive a series of points. GeoBlazor then displays these point graphics on the map.
Because Generate Points Along Lines is asynchronous, we needed to poll the job status. ArcGIS Pro handles this automatically; GeoBlazor does not (yet). In our app, we used a while loop with a delay to check the job’s GUID and status URL. When the status returned esriJobSucceeded, we requested results.
The resulting object is serialized into a model containing the FeatureSet. GeoBlazor processes the features into graphics and adds them to the map.
At this point, our web application orchestrates two services:
The app chains these calls to layer results on the map. Now, asset managers have an automated way to generate and access equipment movement data. The routing information is accurate, and progress increments support tracking and contingency planning, giving granular control over the management process.
The next chapter will cover rasterizing vector data for barrier avoidance and multi-modal routing, adding further capabilities to our asset-management system.
In conclusion, collaboration and leveraging existing ArcGIS Pro tools—published to ArcGIS Enterprise and consumed via GeoBlazor—enabled our web application to gain advanced routing, progress tracking, and network-analysis capabilities. Our customer now enjoys better control, visibility, and planning resources.