In this entry I want to take a closer look at a previous posting on using mosaic datasets for managing RF data in the wireless service provider world. In that article I talked about how mosaics can be very effective for storing larger raster datasets and also for seamlessly recombining them using mosaic operators. These mosaic operators allow users to get the correct best server view of the network across multiple markets and view the raster data as if it were one seamless dataset.
In this article we’ll take a closer look at the details of using these same structures and mechanisms as the enabler for performing outage analysis.
In the previous article we talked about recombining large market level raster datasets. Wireless RF engineering departments within service providers have this market level information but also are the creators of this data at a much higher level of detail. These engineers have predictions rasters (created using RF planning tools) for each individual tower location and may even have them on a sector by sector basis. These rasters usually get recombined into the market level best server views. However these more detailed tower prediction rasters have a second use in the outage management world.
Mosaic operators were the key to recombining the market level rasters but this same capability and the fact that mosaics also allow us to apply Definition Queries allows us to insert outage information into the equation. Definition queries can be setup from the layer properties dialog. For example we can apply this SQL expression to a mosaic layer in an MXD:
Name in (SELECT CDMA_ID FROM SiteStatus WHERE SiteStatus = 1 OR SiteStatus = 2 OR SiteStatus = 3 OR SiteStatus = 7 OR SiteStatus = 9)
or in a shorter form:
Name in (SELECT CDMA_ID FROM SiteStatus WHERE SiteStatus IN (1,2,3,7,9))
This expression is selecting those tower IDs that have a status of Offline. The codes 1,2,3,7,9 are domain values representing various levels of offline status – power outage, down for maintenance etc. This is done in the INNER SELECT statement (SELECT CDMA_ID FROM SiteStatus WHERE). Each row or raster in a mosaic has a NAME field. We use this name field and the results of the INNER SELECT to obtain only those rows in the mosaic that have a status of offline. The mosaic operator (in our case the MAX operator) then takes care of recombining the rasters into the seamless best server view of the offline towers.
From a technical data structures perspective all we need to do is make sure that the NAME field in the raster mosaic attribute table has a corresponding key field in the tower status information (ie the tower ID).
This same technique can be applied for those towers that are “online” or “at risk”. The tower status information could be on the tower feature class or more likely in a separate non spatial table being updated by external alarm systems. As long as we can do a SQL query against it we can use this information to filter the mosaics to give the required outage views. Once we have these SQL statements setup against our mosaic views in an MXD we can then publish the MXDs which will honor these queries. So we then have published map services that are capable of showing online, offline and at risk views of our network.
This is a very powerful capability but also doesn’t come without its pitfalls. Mosaics recombine multiple rasters “on the fly”. This is a very dynamic process and doesn’t allow us to cache the published map services. In order to identify which rasters to recombine the process must look at the polygon footprint for each loaded raster in the mosaic. For imagery (the typical use for mosaics) the footprints are usually fairly simple maybe having tens of points to define the footprint. Because wireless RF footprints are very irregular the footprints can be very complex.
2 Predictions with corresponding footprints in black
This affects the processing time taken to do the mosaic operator recombine and merging of rasters. The more rasters there are, and more complex the footprints, the slower the map refreshes will be. So some recommendations to help combat this:
- When generating the footprints for the loaded rasters don’t generate full detail footprints, use just vertices to represent the RF footprint accurately. Explore the “Approximate Number Of Vertices” parameter on the Build Footprints tool.
- Use scale dependency on these layers. Don’t allow users to view them when zoomed out at a state or national level where several thousand rasters will be recombined for each request. Keep the zoom level to a sensible outage area limit (usually county level or below).
- Do you really need to see the results of the raster recombine or just the footprint of the resulting outage area?
- Limit the use of these services to those that really need it (EOC, NOC type environments where the audience is smaller)
- Consider using the cleaned and smoothed versions of the rasters as the input rasters for the mosaic. These should be more representative of actual quality coverage and have simpler geometry.
- Use hardware with good CPU capability
As an example of this mosaic capability in action i’ve included a small template dataset and mxd configured against it. This map package is available for download for 10.1 pre-release from ArcGIS.com. In this example I’ve generated the footprints with a large value of 500 vertices per footprint. Try rebuilding the footprints with smaller vertex counts to see the impacts on accuracy of footprint vs speed of redraw.
Also try editing the status of an antenna in the Site Status table in the MXD. You will see that the mosaic updates to reflect the change because of the definition queries that are in place on these mosaic layers.
In Part 3 of this series we’ll talk about using these mosaics not as visual layers but as the enablers for doing outage analysis via server side python scripting on these footprints. This analysis will identify Quality of Service areas Vs Outage Areas and show how back end business processes will drive our outage analysis dashboards.
Hope you find this helpful.
If you have questions regarding this or any other posts you can email us at telecom_templates@esri.com.
Regards,
mark
