Global Positioning System Reference
In-Depth Information
for non-expert users where the knowledge of MDX with spatial extension
is required to query spatial data. GeoOLAP from Campotocamp used in
our project still need other features to improve its interface, e.g., the pivot
operation is not allowed, it is hard to analyze historical data covering
several periods of time, the layout is not always user-friendly when graphs
and tables are included in addition to maps, and some modifi cations were
applied to correct the wrong display, among others. According to Rivest
et al. (2005) different features should be included in SOLAP tools in order
to fully explore their potential. They present them using their product that
was originally commercialized under the name JMap and currently as
Map4Decision (Intelli3 2013). We categorized these features into various
groups: (1) data visualization (e.g., tabular, graph, and map displays,
synchronization between different environments during SOLAP operations,
modifi cation of graphical semiology, among others), (2) data exploration
(e.g., drill-down, roll-up, and slice-and-dice operations, manipulation of
temporal dimension with a timeline, addition of calculated members), and
(3) data structures (e.g., support for a complete geometric primitives, support
for several spatial and non-spatial dimensions, support for the storage of
geometries that changes over time). On the other hand, Viswanathan and
Schneider (2011) present a list of 25 requirements that SOLAP systems
should fulfi ll. These requirements refer to conventional and spatial DW
and OLAP and by mixing both environments, i.e., DW and OLAP, it is
not clear which system is responsible for satisfying them. Furthermore,
these requirements are compilations from different works (e.g., Pedersen
et al. 2001; Vassiliadis and Sellis 1999; Rivest et al. 2005) and represent a
complex list that even conventional OLAP tools cannot satisfy. Therefore,
the specifi cation of requirements that the SOLAP front-end layer should
fulfi ll is still an open research topic. Relying on implementers' intuition and
knowledge does not always give the desired results as demonstrated in the
SOVAT system (Scotch et al. 2007), where adjustments and modifi cations
were required to be implemented in order to better satisfy user needs.
Conclusions
Current progress in managing spatial data as a part of traditional storage
of object-relational databases opens up the possibility to implement SDWs
using a multidimensional view of data expressed as star or snowfl ake
schemas. The implementation should consider user requirements, as
well as available and possibly acquire data. In addition, different phases
of development that include conceptual, logical, and physical design of
schemas should be conducted. These phases should be augmented by
the ETL processes that allow integrating data from different sources and
improving their quality. As a next step, SOLAP cubes could be implemented
Search WWH ::
Custom Search