gis-enabled-bi-for utilities.docx

shrubberystatuesqueData Management

Dec 1, 2012 (4 years and 8 months ago)

399 views

Ideas for a general BI framework for utilities


The approach

should be general enough to support application for distribution, transmission, generation
and other system operations, be capable of being applied to back office operations (e.g. asset
management), and support emerging opportunity areas such as demand re
sponse, distributed energy
resource, and smart grid business intelligence.


Geospatial enablement is also a general over
-
arching requirement, along with compatibility with SOA
architecture and commercial vendor independence (to avoid lock in to proprieta
ry solutions such as
Oracle Spatial or ESRI SDE). Establishing a solution that addresses this broad scope is likely too large an
effort for a single project, so the approach should be one that is closer to an agile development process,
where development i
terates around smaller, incremental releases that provide selected functionality to
a customer/user base, the goal being that each release moves closer to the complete solution but puts a
valuable working solution in the customer’s hands with each iteratio
n. The
iterations should be driven
by the long term strategy and roadmap, that drives to the utility focused geospatially enabled business
intelligence framework that can support the broad requirements.

The ideas presented are organized into a few main to
pic areas:



Selecting the right technologies and architecture to support the business objectives.



Identifying the priority of requirements and sequence of capabilities to support near term
opportunities and long term goals.



Leveraging standards to enable so
lution portability and integration.


Technology


The convergence of GIS and BI is an active topic of research and development. I did a little research to
identify some of the open source options in both areas, especially open source projects that bridge G
IS
and BI.
There are also many commercial options available, but the best strategy would be to stay with
standards or technologies that would permit
the
change out of technology to allow customers to utilize
products and technologies they prefer, such as
using Oracle for a data warehouse

platform.

An open source BI suite that is worth investigation is
Pentaho.

It has GIS enhanced components for ETL
(
geokett
le
), OLAP (
geomondrian

), and web based GIS visualization (
solaplayers

, a spatially enhanced
version of
OpenLayers

).

Kettle compares favourably with Informatica, except that is free and open source (it has a commercial
version, in a dual license).

GeoKettle supports Oracle, PostGIS (PostgreSQL with GIS extensions), and
others, and i
s in wide usage, so it is not a risky choice. GeoMondrian
provides a consistent integration of
spatial objects into the OLAP data cube structure, instead of fetching them from a separate spatial
database, web service or GIS file. It implements a native
geometry data type and provides spatial
extensions to the MDX query language, allowing embedding spatial analysis capabilities into analytical
queries. SOLAPLayers is a pure JavaScript library for displaying map data in most modern web browsers,
with no s
erver
-
side dependencies. While at ObjectFX, we saw a rapidly growing adoption of
OpenLayers, including existing customers.

The open source options for visualization are numerous, an
d some are, like OpenLayers,

purely web 2.0
client
based,

while some are
server and web 2.0 client based, such as
geomajas
. Geomajas is actually
more like ObjectFX’s SpatialFX visualization product than OpenLayers. It does much of the processing
server side, and thus can scale to very l
arge dynamic spatial object counts. This is possible because the
spatial objects reside server side, and not as added elements in the browser DOM (in which case the
browser starts to slow down after 300
-
500 objects

--

Google Maps has this problem
). I am
not sure if
geomajas would be significantly better or worse in fronting GeoMondrian or PostGIS or other OLAP or
ROLAP sources, but I suspect it might not be an issue since it is a Java API that should be able to leverage
olap4j
. Most (maybe all) of these open source technologies are Java based, which makes it much easier
to mix them together.

A good source for open source geospatial technology information is
http://slashgeo.org/
.

If a browser based visualization client is used, then
JQuery

is highly recommended
for the browser coding.

Even better, there is now a geospatial version of JQuery,
mapquery
.





T
here are other open source choices for ETL, and maybe for OLAP. For a DW platform, I would suggest
PostGIS since it is reported to be the
most mature. One other technology worth investigating and
tracking is Hibernate, specifically the spatial version
hibernatespatial
, which may further enhance
independence from the specific DW platform.


Requirements


As Terry suggested in his email, “we could build something that had dashboards based upon some of the
items

in the guide too, but also take direct feedback from APCO on what they need and our knowledge
of the competitive offerings from Obvient and Oracle”.

I agree with that approach. To expand on that a little, the requirements consist of dimensions and fact
s,
some key reports and performance indicators, and deployment / technology considerations. For the
facts and dimensions, there are some that should be considered “core” that will be leveraged across
areas of business. The
Landt, Paul

Distributech presen
tation shows this on slide 30,
examples being
time, geography (location), company org, etc. These should be the core foundation, along with
mandatory reporting requirements, such as the IEEE metrics.

APCO specific
requirements

not satisfied
with the core

functionality should then be included in the first

(APCO)
project
.

In my opinion, geospatial (geography, location) should be a core requirement and built in from the
ground up. This should help to avoid any “bolt on” design issues that would arise from
trying to add it to
an existing system.


Standards


Many of the technologies described above are standards based. Besides the technology standards, such
as HTML/XHTML, CSS, Javascript, JSON for web clients, a few others that are important are:

OGC standard
s; these

provide for standard representation of geospatial information. The OGC maintains
and promotes a very large set of standards, which are supported b
y over 400 companies and some o
f
the most important and influential organizations, such as the Nation
al Geospatial Agency
. Key standards
include geometry standards (GML, KML, APIs…), web services, sensors, location services, and others.
The most common to focus on are Simple Features, Web Mapping Service (WMS), Web Feature Service
(WFS), Sensor Observati
on Service (SOS), and Web Map Context (WMC). Note that GeoKettle supports
ETL with the OGC SOS. The OGC standards may not become common requirements in the utility space
for some time, but they are likely to make their way into the utility space (one exa
mple, is UICDS, where
the Map Service is based on WMS/WMC, maybe others know of more examples). Most of the open
source mapping software supports OGC standards.

Another standard to align with, and leverage where possible, is the IEC
CIM
. In my viewpoint, aligning
dimensions with CIM
entities may help establish integration with utility data and also support the ETL
process. One example might be the organizing regions in 61970 (e.g. a substation belongs to a
geographic region), and other
inherent hierarchies (e.g. conduction equipment belongs to voltage levels,
which belong to substations).

Also, the CIM mRID should provide a key for many dimensions and facts.