It was one year ago now that we published our article on Location Analytics for Design Studio.
At that time, SAP DesignStudio 1.4 was just kicking in, but was still lacking the Location Analytics component.
Galigeo for DesignStudio came into action and filled that need, until native GeoMaps came into play as well.
Let’s be honest, at the beginning, the gap was really close between what Galigeo for DesignStudio was offering, and what GeoMaps brought to the table.
But our world is in perpetual evolution (especially the BI one!), and we all have to adapt ourselves to stay in the race.
Galigeo for DesignStudio keeps evolving release after release, as the customer/prospect use-cases and feedback came in, the version 2.3 came out (a few weeks ago now), as DesignStudio 1.6 is out.
One of the core capabilities, that exists since the first release and that will probably interest most of you, is the
out-of-the-box ESRI support
And guess what, some of them also have SAP DesignStudio.
Using Galigeo for DesignStudio, the designer just has to paste its service URL (for example, http://services.arcgis.com/bAFFwOpXUz9B6dsy/ArcGIS/rest/services/USA/FeatureServer/0), configure the field to be linked both on the ESRI service and BI data side, and the geodata appears on the map.
Taking this into account, the product has been adapted to meet specific customer needs, some of those needs being very specific.
Like in all my posts, I’ll take you through a quick tour of what the product is capable of.
Here, we’ll look at a use-case, the needs of the client, and how Galigeo for DesignStudio was able to meet these needs.
A little bit of context
The customer in question is a large telecom operator, indeed one of the biggest in Europe (amongst the Top 10).
The company own a lot of cell towers, each cell being able to communicate with others in the surrounding area.
Each cellphone creates a lot of data no matter what time of the day it is. Of course, each data is collected, computed, stored in SAP legacy database solutions like HANA, and so on.
You get the concept.
One of the customer needs in DesignStudio was to be able to get a complete overview of these cell towers, to analyse the interaction between them, but also to analyse every problem bubbled up by the cell towers, like potential downtime, or number of packets received/handled, in order to better plan where the maintenance staff would have to focus, or where the future tower cells would have to be built.
And this was just the tip of the iceberg.
The company has some on-premise ArcGIS Servers, that serve their own geodata, like the cell towers geolocation, but also custom territories for maintenance staff.
Based on these many use-cases, we worked with them to build what they needed.
Here are some screenshots of the POC.
Figure 1. The basemaps being configurable, offers the possibility to zoom up to street levels and still obtain a very good level of details, allowing the end-user to exactly know where their data are located
Figure 2. A view of a possible dashboard made for a customer during a POC phase. The view combines multiple maps, each of them having the possibility to be linked to its own data source and to have its own basemap or layers configuration
They also add very specific requirements, for example being able to analyse the data flow between cell towers. These, of course, being “abstract” while still occurring in real life. In their dataset, a dimension was containing the ids of the cell towers (as “ID01;ID06;ID07;” for example), as well as several other dimensions containing metrics about the flows in question (as “185500;196550;124500;” according to the ids upon) calculated by SAP HANA on the fly.
So we integrated the capacity to display lines into Galigeo for DesignStudio – representing data flows – simply based on the dimension containing links between cell towers.
For example, if the cell tower A has ID 01, and is able to communicate with tower B, as we know coordinates from both towers coming from the ESRI server, it was easy to create a line between them to display KPI on it.
A screenshot focusing on the result above Berlin, Germany.
Figure 3. This map displays a KPI on the cell towers themselves, and another KPI on the data flow between the cell towers. Like mentionned above, the flows (represented by lines) do not come from any GIS datasource, but are generated on the fly leveraging a specific development that can read links between tower cells in the BI datsource.
As this requirement is really specific for this customer, it has not been integrated in the core product.
But what’s great is that if someone has the same needs, it could be easily replicated. Though if your business needs differ, our team of experts are of course on hand to build whatever you require.
That will be it for today guys, if you have any questions or feedback, feel free to post comments below and we’ll be glad to answer.
You can also contact me via PM on this website if you have more specific questions or contact us at www.galigeo.desk.com for any support related queries.
And remember, the only limit is your imagination.
A 30-day trial is available right there.