# A Survey on Spatio-temporal Data Analytics Systems

Md Mahbub Alam<EMAIL_ADDRESS>,  Luis Torgo<EMAIL_ADDRESS>Dalhousie
University6299 South St.HalifaxNSCanadaB3H 4R2 and  Albert Bifet  The
University of WaikatoKnighton RoadHamiltonNew Zealand<EMAIL_ADDRESS>
(2021)

###### Abstract.

Due to the surge of spatio-temporal data volume, the popularity of location-
based services and applications, and the importance of extracted knowledge
from spatio-temporal data to solve a wide range of real-world problems, a
plethora of research and development work has been done in the area of spatial
and spatio-temporal data analytics in the past decade. The main goal of
existing works was to develop algorithms and technologies to capture, store,
manage, analyze, and visualize spatial or spatio-temporal data. The
researchers have contributed either by adding spatio-temporal support with
existing systems, by developing a new system from scratch for processing
spatio-temporal data, or by implementing algorithms for mining spatio-temporal
data. The existing ecosystem of spatial and spatio-temporal data analytics can
be categorized into three groups, (1) spatial databases (SQL and NoSQL), (2)
big spatio-temporal data processing infrastructures, and (3) programming
languages and software tools for processing spatio-temporal data. Since
existing surveys mostly investigated big data infrastructures for processing
spatial data, this survey has explored the whole ecosystem of spatial and
spatio-temporal analytics along with an up-to-date review of big spatial data
processing systems. This survey also portrays the importance and future of
spatial and spatio-temporal data analytics.

spatial databases, spatial NoSQL, big spatial data, spatio-temporal data,
trajectory data, spatial data stream, GIS software, spatial libraries

††copyright: acmcopyright††journalyear: 2021††doi: 10.1145/XXXX.XXXX††journal:
CSUR††price: 15.00††isbn: 978-1-4503-XXXX-X/18/06††ccs: General and reference
Surveys and overviews††ccs: Information systems Spatial-temporal systems††ccs:
Information systems Parallel and distributed DBMSs

##  1\. Introduction

Due to the technological advancement of the internet, sensor devices, GPS-
enabled devices and the popularity of location-based services (LBS) and
applications (such as map services, recommendation systems, navigation
systems, location-based social networks, and other applications), a huge
volume of geo-referenced data is generated every day, often called big spatial
data. However, a significant portion of these data comes with a timestamp
(temporal-tag), leading to spatio-temporal data. As a result of the
availability of smart mobile devices and the internet, LBS applications and
services are part of our daily activities and contributing significantly to
this data growth. These data also comes from other sources such as vehicles,
sensors positioned around the world, satellites, space telescopes, aerial
photography, land survey, medical imaging and more. Therefore, mining
information from this huge volume of spatio-temporal data is not only
important for popular LBS applications and services we are using today, but it
is also important for scientific discovery and exploration of a wide range of
application domains, such as climate change analysis, earthquake analysis,
weather forecasting, urban planning, health care, modern transportation
system, agriculture, space exploration, crime data analysis, e-commerce and
advertising, epidemic analysis, animal migration, oceanography, and many more.
In this context, there is a demand for efficient tools and data processing
systems to store, manage, analyze, and visualize the high dimensional and
heterogeneous big spatio-temporal data.

Research and development of spatial and spatio-temporal database systems have
started with traditional relational database systems (RDBMSs). Traditional
RDBMSs with a spatial extension (such as PostgreSQL/PostGIS (OSGeo, 2020c),
Oracle Spatial, and more) are efficient in a single node computing
environment. However, due to the lack of parallelism and the I/O bottleneck,
these systems only work well for relatively small datasets. Besides, these
systems have limited analysis and visualization capabilities. Therefore, one
may question if spatial RDBMSs are significant in this era of big spatial
data. Researchers are continuously adding new features to make these systems
adaptable in this new era. Researchers have also developed a few parallel and
distributed systems by using spatial RDBMSs. Though current spatial RDBMSs are
not massively scalable, these systems are scalable enough to solve many real-
world problems we are facing today. There is a huge demand for Spatial RDBMSs
in a wide range of application domains at the enterprise level. Therefore,
spatial RDBMSs are still significant in this era of big spatial and spatio-
temporal data.

Along with the limitations mentioned above, traditional RDBMSs also did not
have support to store and process semi-structured or unstructured data.
Therefore, NoSQL (Not-Only-SQL) database systems (e.g., MongoDB, Cassandra)
(Gessert et al., 2017; Davoudian et al., 2018) have emerged as alternative
databases, which are schemaless, highly available, and horizontally scalable.
Currently, a few of these systems have limited native support to store and
process spatial data. Still, researchers have extended some of these databases
to add spatial support. Moreover, several big spatial data processing systems
have been developed by utilizing the power of NoSQL databases (Nishimura et
al., 2011; Hughes et al., 2015; Qin et al., 2019; Li et al., 2020a, b).
Spatial support of current NoSQL databases lack spatial analysis and
visualization, and only a few of them support SQL-like query language.
Although many of the present modern RDBMSs do have support for processing data
other than structured data. For example, GeoJSON support in
PostgreSQL/PostGIS.

In recent years, a number of data processing systems have emerged to process
big spatial and spatio-temporal data. These systems are implemented mainly by
extending the MapReduce framework Hadoop (Foundation, 2020a), Spark
(Foundation, 2018; Zaharia et al., 2010, 2016), and NoSQL database systems
(Gessert et al., 2017; Davoudian et al., 2018) to incorporate spatial and
temporal data types, partitioning and indexing techniques, geometric
operations, and a SQL-like query language. However, a few of them have been
developed either from scratch (Becla et al., 2013; Baumann et al., 1997;
Memarzia et al., 2019) or by extending systems other than Hadoop, Spark, and
NoSQL databases (Eldawy et al., 2017; Alamoudi et al., 2015; Alam et al.,
2018). Recently, Python libraries such as DASK (Dask Development Team, 2016)
and RAPIDS (Team, 2018c) emerged as parallel and distributed platforms for
processing big data. These big data systems can be either spatial (Eldawy and
Mokbel, 2015; Yu et al., 2015; Nidzwetzki and Güting, 2018), spatio-temporal
(Alarabi et al., 2018; Hagedorn et al., 2017b), trajectory (Bakli et al.,
2019a; Zhang et al., 2017; Li et al., 2020a), or spatial stream (Mahmood,
2018; Chen et al., 2020; Shaikh et al., 2020) data processing systems.
However, these big data systems have limited analysis and visualization
capabilities. Also, a few of them support SQL-like query language, but not as
efficiently as spatial RDBMSs.

Due to the heterogeneity and implicit spatial and temporal dependencies of
spatio-temporal data, being able to extract and analyze knowledge from these
data can be extremely challenging. The data mining, analysis, and
visualization support of existing spatial RDBMSs, spatial NoSQL databases, and
big spatial data infrastructures, are very limited. There is a wide range of
libraries and packages available for mining, analyzing, and visualizing
spatial, spatio-temporal, and trajectory data in two popular de facto
programming languages for data science, R (R Core Team, 2020) and Python (Van
Rossum and Drake Jr, 1995). Besides, a large community of people is
continuously working to introduce new libraries and packages to meet the
current and future demands. However, these libraries and packages can not
store and process a large volume of data. Therefore, the utilization of these
libraries and packages with RDBMSs, NoSQL databases, and big data
infrastructures in essential to fill the gap. On the other hand, GIS software
like ArcGIS (ESRI, 2020a) and QGIS (QGIS Development Team, 2020) are leading
tools to collect, store, process, and visualize spatial data. Initially, GIS
software has developed for a single user with limited DBMS capability.
Currently, GIS software like ArcGIS has developed additional tools to utilize
the processing capability of Hadoop and Spark. ArcGIS can also process data
stored in spatial RDBMSs. Moreover, Python and R users can use the
functionality of GIS software to process spatial, spatio-temporal, and
trajectory data.

Researchers from both academia and industry are working in order to meet the
current and future demands for big spatio-temporal analytics. Surveys are
always crucial for current and future researchers to know about the state-of-
the-art. Surveys also help to choose a data analytics system based on
application requirements. However, existing surveys and performance analyses
are not up-to-date and mostly summarize infrastructures related to big spatial
data processing. In the meantime, a number of big spatio-temporal, trajectory,
and spatial stream data processing systems have emerged along with a few new
spatial data processing systems. Besides, existing surveys have not considered
spatial RDBMSs, GIS software, and spatial support in programming languages.
These shortcomings motivate the current paper. This survey categorizes the
existing ecosystem of spatio-temporal data analytics (see Figure 1) into three
data dimensional categories: (1) Data Storage: spatial RDBMSs and NoSQL
databases, by first defining the significance of spatial RDBMSs (e.g.,
PostgreSQL/PostGIS) in this era of big spatial data, and then reviewing the
spatial support of popular NoSQL databases; (2) Data Processing: big data
infrastructures, where big data processing systems are classified based on
underlying architecture (e.g., Hadoop, Spark, NoSQL, and others) and the type
of data processing system (such as spatial, spatio-temporal, trajectory, and
spatial stream); (3) Data Programming and Software Tools, which summarizes
available libraries, packages, and tools for processing spatial, spatio-
temporal, and trajectory data in widely used programming languages, such as R
and Python. Two popular GIS software, ArcGIS and QGIS, are also discussed in
this last category.

Figure 1. The Ecosystem of Spatio-temporal Data Analytics

The rest of the paper is organized as follows. Section 2 provides an overview
of existing surveys along with limitations, thus setting the goals of this
survey. Section 3 discusses the importance of spatio-temporal data analytics
research, along with a few important application domains. Spatial and spatio-
temporal data is defined in Section 4. Section 5 defines the significance of
spatial RDBMSs in the era of big spatial data and discusses the spatial
support of NoSQL systems. The detailed review of existing big data
infrastructures for processing spatial and spatio-temporal data is presented
in Section 6. Section 7 presents the ecosystem containing libraries, packages,
and tools of two popular languages, Python, and R for processing spatial,
spatio-temporal, and trajectory data along with two popular GIS software,
ArcGIS and QGIS. Finally, Section 8 concludes the paper.

##  2\. Related Works

A number of research works have been published which surveyed existing spatial
data analytic systems. These surveys either performed a comparative analysis
of existing spatial data analytics based on supported features or evaluated
the performance of the existing systems by running supported spatial queries.
Therefore, we divided the existing works into two groups, (1) surveys, (2)
performance analyses.

Existing surveys: In their survey of big spatial data systems, Eldawy et al.
(Eldawy and Mokbel, 2016) have explored the existing works that are developed
on or before 2016, based on six key features. These features include (i) the
system implementation approach, which defines whether the system was built as
a library on-top of a system, built inside the core of a system, or developed
as a new system from scratch, (ii) underlying data processing architecture
(such as MapReduce, key-value stores, parallel DBMS, spark and other
architectures), (iii) supported query language, (iv) supported indexing
techniques, (v) supported spatial operations, and (vi) data visualization.
This survey also provides an overview of some applications of spatial data.
Maguerra et al. (Maguerra et al., 2018) survey provides a comprehensive review
of big spatio-temporal data processing systems in the context of the
underlying processing frameworks, partitioning and indexing techniques, and
supported spatial queries. Castro et al. (Castro et al., 2018) survey analyzes
the supported features of Hadoop and Spark-based spatial data systems from the
user’s viewpoint to help users to select spatial data processing systems for
their applications. Yao et al. (Yao and Li, 2018) studied and discussed recent
technologies and techniques for big spatial vector data management based on
the data model, storage, indexing, and processing and analysis. Karim et al.
(Karim et al., 2018) portrait the spatio-temporal aspect of big data and
performed a comparison of the supported spatio-temporal features on different
frameworks, such as Apache Hadoop (Foundation, 2020a) (SpatialHadoop), Apache
Samza (Noghabi et al., 2017), Apache Storm (Apache Software Foundation, 2019),
Apache Spark (Foundation, 2018) (SpatialSpark and GeoSpark), and Apache Flink
(Friedman and Tzoumas, 2016). Almeida et al. (de Almeida et al., 2020)
presented a survey on big trajectory data analytics from the viewpoints of
storage, processing, summarization, and analysis of trajectories. This survey
also provides an overview of a few systems for processing big trajectory data
along with traditional systems based on PostgreSQL/PostGIS, Oracle Spatial,
and other databases. The big trajectory systems include a cloud-based system
on Microsoft Azure (Bao et al., 2016), ST-Hadoop (Alarabi et al., 2018),
TrajSpark (Zhang et al., 2017), DiStRDF (Nikitopoulos et al., 2018), and
systems based on Apache Flink, MongoDB (Inc, 2020), and other databases for
semantic trajectories. Recently, Guo et al. (Guo and Onstein, 2020) have
surveyed the geospatial data processing capabilities in the 10 most popular
NoSQL databases based on supported geometry types, geometry functions, spatial
indexes, query languages, and data formats. This survey also discussed the
strengths and weaknesses of each of these databases.

Existing performance analyses: Hulbert et al. (Hulbert et al., 2016) performed
an experimental study on GeoMesa (LocationTech, 2019) and Elasticsearch (B.V.,
2020) by running spatio-temporal queries, where the authors have compared
these systems based on query execution time and throughput. García et al.
(García-García et al., 2017) conducted a comparative analysis of the
performance of SpatialHadoop (Eldawy and Mokbel, 2015) and LocationSpark (Tang
et al., 2016) based on parallel and distributed spatial distance join queries.
Hagedorn et al. (Hagedorn et al., 2017a) performed feature comparison and
performance analysis of Hadoop and Spark-based big spatial data processing
systems. They have conducted a performance evaluation by running range and
spatial join queries on SpatialHadoop, SpatialSpark (You et al., 2015),
GeoSpark (Yu et al., 2015), and STARK (Hagedorn et al., 2017b), where STARK is
proposed by the authors as a spatio-temporal extension of Spark. Data Reply
(Reply, 2017) published a report on benchmarking six big geospatial data
infrastructures to help the users to select the right infrastructures for
their applications. These infrastructures include GeoSpark, Hive (Thusoo et
al., 2009), MongoDB, GeoMesa, Elasticsearch, and Postgres-XL (Team, 2018a).
These systems are evaluated by running several queries (range, regular
expression, and join queries) on three different datasets, where each dataset
contains 10 billion records. This report also provided performance tuning tips
for each of the evaluated systems. Pandey et al. (Pandey et al., 2018)
performed a comprehensive study to analyze available features of selected
Hadoop and Spark-based spatial data processing systems. They also evaluated
the performance of five Spark-based spatial data systems (SpatialSpark,
GeoSpark, Magellan (Sriharsha, 2017), LocationSpark, and Simba (Xie et al.,
2016)) based on supported spatial operations, which include range and kNN
query, spatial join, distance join, and kNN join. The cost of memory is also
considered for performance evaluation. Alam et al. (Alam et al., 2018) also
performed a comprehensive feature analysis and performance evaluation on
Hadoop and Spark-based spatial data processing systems. However, instead of
evaluating limited supported spatial features, they have implemented OGC-
compliant join predicates and analysis features on SpatialHadoop and GeoSpark
to assess the performance by running a number of spatial join queries, spatial
analysis queries, and range queries on a cluster of nodes using real-world
datasets. The authors also included $SpatialIgnite$ as part of the evaluation,
which is developed as extended spatial support for another in-memory computing
system, Apache Ignite (The Apache Software Foundation, 2015). More et al. (P.
More et al., 2018) performed an experimental study on SpatialHadoop and
GeoSpark to evaluate the performance based on various geospatial tasks such as
data compression, indexing, and kNN and range query on a single node computer,
which is not an ideal scenario for evaluating big spatial data systems.
Recently, Haynes et al. (Haynes et al., 2020) proposed a benchmark to evaluate
spatial raster operations on big data platforms. They have assessed the
performance of five raster operations on three big data platforms, namely
PostgreSQL/PostGIS (OSGeo, 2020c), SciDB (Becla et al., 2013), and GeoTrellis
(Eclipse Foundation et al., 2016), using three different datasets. These
operations include pixel count, reclassification, raster add, focal
operations, and zonal statistics.

Limitations of existing surveys and performance analyses: First, existing
surveys and performance analyses are not up-to-date. These researches mostly
covered systems that were developed on or before 2017. Second, most of these
works analyze the big data infrastructures for processing spatial data.
However, in the meantime, a number of big data processing systems for spatio-
temporal and trajectory data emerged in addition to a few new big spatial data
processing systems. Though Guo et al. (Guo and Onstein, 2020) have reviewed
native spatial supports of NoSQL databases, there is no comprehensive survey
of big spatial data processing systems, which are developed by utilizing NoSQL
databases. Moreover, there is no review available on Python libraries such as
DASK and RAPIDS for big spatial data processing. However, at present, along
with Spark, these parallel and distributed libraries are gaining popularity
and often considered as the next big data processing platform. Finally,
researchers have not considered the other parts of the ecosystem of spatio-
temporal analytics, namely spatial RDBMSs, GIS software, and spatial support
in programming languages for processing spatial, spatio-temporal, and
trajectory data.

Goal of this survey: The goal of this survey is to conduct a comprehensive
review on the current state of spatio-temporal data analytics systems research
for processing spatial, spatio-temporal, and trajectory data. This survey
discusses the up-to-date spatial support in RDBMSs, NoSQL databases, big data
processing platforms, programming languages, and GIS software. First, along
with the review of spatial support in popular relational (SQL) and NoSQL
databases, we have addressed the significance of relational spatial databases
in this era of big spatial data. Second, since a large number of research
works have contributed by incorporating spatial support in big data platforms,
we have studied and discussed these platforms based on the type of supports,
such as spatial (both vector and raster), spatio-temporal, trajectory, or
spatial streams. This survey also includes two new emerging big data
processing platforms, DASK and RAPIDS, in addition to Hadoop, Spark, and NoSQL
databases. Till now, there is no survey on spatial support in programming
languages. This survey provides an overview of available libraries, packages,
and tools of R and Python for processing spatial, spatio-temporal, and
trajectory data. The APIs for interfacing R and Python with spatial RDBMSs,
GIS software, and big data platforms are also discussed. Besides, a summary of
spatial supports in other popular programming languages (e.g., C/C++, Java) is
provided. Finally, this survey presents a review of two popular GIS software,
ArcGIS and QGIS. We hope that this survey will help researchers, developers,
and other stakeholders towards furthering the state-of-the-art.

##  3\. Importance and Applications of Spatio-temporal Data Analytics

In 1854, nearly 10 percent of a neighborhood at 40 Broad Street of the city of
London died in just seven days due to the severe outbreak of deadly disease
Cholera. Dr. John Snow (Society, [n.d.]), a British Physician, was able to
identify the source (a water pump at Broad Street) of the disease by plotting
cases of Cholera on a map called ghost map (Johnson, 2007). This deadly map
has taught us that the inherent knowledge of a map can solve a problem. Now,
if we look at the current coronavirus (COVID-19) situation, or last year’s
bushfire situation in Australia, or the aftermath of recent floods/hurricanes
around the world, or the effects of climate change, we observe that a large
volume of people were affected by these deadly events. Forests were brunt, and
animals lost their habitats. Though we are more technologically capable than
ever, we are facing these situations or problems with more strength and more
frequently. Therefore, it is essential to utilize the knowledge of spatial and
temporal properties of data to mitigate or tackle many of these problems. The
outcome of mined information from spatial and spatio-temporal data has already
touched many avenues of human endeavor. Due to recent technological
advancements, location-based services and applications are an integral part of
our daily activities. Researchers have been using these data for urban
planning, navigating vehicles, identifying road accidents, tracking the
activity of diseases (e.g., flu) and natural phenomena (e.g., hurricanes,
tornados), and solving many other problems. In this context, it is important
to put a closer look into the problems we are facing today and look beyond the
traditional application domains for tackling future adverse events. In this
section we discuss some important application domains, which need special
attention now and in the future.

The ongoing COVID-19 virus situation came as a shock and has stopped the pace
of the world. People lost their jobs and businesses, healthcare systems are
overwhelmed with patients, many countries are struggling to give minimum
services to emergency patients, and governments are facing difficulties to
maintain supplies of food and necessary medical equipment. Even
technologically advanced countries like USA and UK are not able to tackle this
pandemic efficiently. Spatio-temporal data analysis, visualization, and
mapping in the domain of epidemiology and public health may become essential
tools for tackling future pandemics. A number of research works have
discovered spatio-temporal patterns (Matsubara et al., 2014) and the spread of
the diseases by studying the patient’s treatment history. However, along with
technological support, there is a need to utilize the spatio-temporal tools
and techniques for efficient studies of the pandemics to quickly find the
originating point, to stop spreading and isolating patients, and to provide
better health-care services. In addition, other diseases like HIV, influenza,
malaria, dengue, zika, and many other viruses are also a constant threat to
the health sector around the world.

Similarly, the 2019-2020 season bushfire in Australia was the biggest in
Australian history (Alexander and Moir, 2019). As of March 2020, the bushfire
burnt more than 18 million hectors across the country, destroyed over 5900
buildings (including more than 2000 homes), killed at least 34 people, 3
billion animals have been killed, and some animals may be driven to extinction
(Burton, 2020; Tiernan and O’Mallon, 2020). According to NASA, 306 million
tones of CO2 were emitted during the 2019-2020 Australian bushfire season
(Lee, [n.d.]). Besides, countries like USA, Canada, and a few European
countries are also affected by bushfires every year. Spatio-temporal analysis
of bushfires based on aerial and satellite images is useful to spot and tackle
the bushfires at the initial stage to save forests and the lives of people and
animals. Also, scientists have warned that if it is not possible to control
the emission of greenhouse gas, bushfires could become a normal scenario every
year (Green, 2020). On the other hand, due to cyclones, hurricanes, and
floods, a huge volume of people were affected and died around the world every
year. Even the world’s most developed and technologically equipped country,
the USA, was adversely affected by Tropical Storm Nestor and Hurricane Dorian
in 2019. Thus, climatology is another pivotal field to discover spatio-
temporal patterns and relationships of climate variables and helps to prepare
to tackle future adverse conditions (Atluri et al., 2018). Since pollution
(air, water, sound, and other pollution’s) is an ongoing issue for a long
time, the study of the environmental science domain to discover factors of
pollution using data collected from sensors will always be as crucial as
today.

A large number of people are affected by an increasing number of large scale
crises and disasters every year, such as hurricanes, bushfires, floods,
earthquakes, epidemics, and other emergency events. These also can be small
scale local emergency events such as road accidents, crimes, and house fires.
During any such events, immediate actions are required to mitigate the
suffering of people. These actions include to rescue and alert peoples, to
maintain the supply chains (foods, medical supplies, and other essential
resources), to provide medical services, and other necessary steps. Currently,
GIS tools and solutions (Scholten et al., 2008; Bhanumurthy et al., 2015;
Abdalla, 2016; Bhanumurthy et al., 2017) are used by emergency teams around
the world to analyze data collected from aerial drones, satellites,
smartphones, social networks, and other sources to take immediate measures.
Future geospatial analytics will be more advanced and accurate for emergency
management and response due to the integration of AI and machine learning.

As the ocean and marine environment is the largest part of the earth, spatio-
temporal ocean and marine datasets collected from widespread sources (such as
satellites, remote sensors, aerial drones, stations, ships, buoys, and
underwater sensors) are valuable in many application domains. These domains
include safe and secure maritime navigation, autonomous cargo shipping,
aquaculture production optimization, improved detection and forecasting of
environmental changes, advanced weather forecasting, anomaly detection for
identifying smuggling or drug trafficking, maritime surveillance, classifying
acoustic sounds, and more. In addition, maritime shipping is the backbone of
world trade and manufacturing supply chains. Therefore, application domains
related to the ocean and marine environment are hot fields of research
(Wright, 2013).

Due to the advancement of GPS technology and the internet, most taxis are
equipped with a GPS device in large cities, and people use online location-
based services, such as Uber, Google Maps, Foursquare, and other services for
traveling purposes. A taxi driver always wants to get a passenger quickly and
maximize the profit. Whereas, a passenger wants to reach destination as
quickly as possible. A number of research works (Yuan et al., 2011, 2012b; Qu
et al., 2014; Garg and Ranu, 2018) have been done in the last couple of years
intending to maximize the profit of taxi drivers and utilize the valuable time
of passengers. The outcome of these researches was already implemented into
location-based services we are using today. These services can recommend
locations for taxi drivers to find passengers quickly and passengers to find a
taxi on time, which in turn reduce energy consumption and air pollution as
well. This research also helps traffic engineers to implement policies to
reduce traffic congestion and identify road accidents. However, as we are
moving towards driver-less taxi services, intelligent transportation systems
is becoming an important field of research. On the other hand, researchers
also started utilizing data generated from urban areas (such as sensors,
vehicles, and humans) for urban design and planning (Yuan et al., 2012a; Yuan
et al., 2015), which is another domain to watch-out.

We need to increase agricultural productions to ensure food security for the
growing population of the world. However, the arable land area is decreasing
due to the high growth of population and urbanization. Also, the fertility of
lands is reducing as a result of the excessive use of fertilizers, pesticides,
herbicides, water, and other inputs. Besides, crop production is affected by
floods, drought, soil erosion, and other calamities. On top of that, farmers
might lose farmlands due to the rise of sea levels as an effect of climate
change. Increasing crop production as well as reducing the cost of production
and unnecessary use of fertilizers, pesticides, and other farm inputs are very
challenging tasks. Precision agriculture (Grisso et al., 2005; ESRI, 2008;
Delgado et al., 2019) uses knowledge extracted from spatio-temporal data
collected from aerial drones, satellites, sensors, and other sources to
identify soil types, crop diseases, and other attributes. This information
helps farmers to identify site-specific needs and optimal use of farm inputs
such as fertilizers, pesticides, water, and so on to maximize crop production
and profits. Therefore, precision agriculture is another significant field of
research that requires more attention from the spatio-temporal research
community.

Other application domains, such as Animal Migration and Forestation, Space
Exploration, and Neuroscience, are also prominent fields of research.
Researchers also suggested exploring beyond the traditional application
domains, such as biology, chemistry, astronomy, and more (Wang and Wolfson,
2020).

##  4\. Definition and Types of Spatial and Spatio-temporal Data

Currently available spatial databases, big spatial data processing
infrastructures, programming languages, and software tools have built support
to model, store, and process either spatial data or spatio-temporal data.
Spatio-temporal data can be either discrete point data or trajectory data.
This section will define and differentiate among these types of data.

A data item related to space (location-aware or geo-tagged) is called
$geospatial$ or $spatial$ data. Traditionally, raster data (e.g., satellite
images), point data (e.g., crime reports), or network data (e.g., road maps)
were known patterns of spatial data (Evans et al., 2019). In recent years, the
traditional pattern of spatial data has changed due to the wide adoption of
GPS-enabled mobile devices and the popularity of location-based services (LBS)
and applications. Examples of this change include check-ins, GPS trajectories
of smartphones, geo-tagged tweets, Instagram or Flickr photos, and so on.
Spatial data types can be divided into three categories: vector, raster, and
network data.

Raster data is represented as a collection of pixels (or grid cells), where
each pixel is associated with a specific geographical location. Raster data
can be discrete (such as land-cover type, soil type) or continuous (such as
temperature, elevation, aerial photographs, satellite images). Vector data can
be represented by points (e.g., a city, a movie theater), lines (e.g., roads,
rivers, cables for phone or electricity) or polygons (e.g., a country, a lake,
a river, a national park). A spatial network is a special graph that consists
of nodes embedded in space. The most common example of a spatial network is
the transportation network (e.g. the road network), where edges represent road
segments, and nodes represent the intersection of road segments or points of
interest (Huang, 2009).

On the other hand, spatial data is being captured with a timestamp (temporal-
tag) called spatio-temporal data, i.e., spatio-temporal data contains both
spatial and temporal aspects of an object. Spatio-temporal data can also be
defined as geometries changing over time (Erwig et al., 1999). There are a
number of data models (such as event model, temporal snapshot model, temporal
change model and more) to represent spatio-temporal data in data processing
systems (Pelekis et al., 2004; Shekhar et al., 2015). Spatio-temporal data
type is basically the integration of timestamps (e.g., time instance, period,
interval) with the spatial data type (e.g., point, line, polygon). Several
classes of spatio-temporal data types are available in real-life application
domains to represent an object with respect to both space and time. Kisilevich
et al.(Kisilevich et al., 2010) have considered point objects and defined five
classes of spatio-temporal types, which include spatio-temporal events, geo-
referenced variables, geo-referenced time series, moving objects, and
trajectories. Whereas, Atluri et al. (Atluri et al., 2018) have described four
classes of spatio-temporal data types, such as event data, point reference
data, trajectory data, and raster data.

When raster data is collected with a timestamp, it is called spatio-temporal
raster data. For example, air quality observations data from ground-based
sensors or earth surface observations data from satellites are raster spatio-
temporal data (Atluri et al., 2018). In both of these cases, data is collected
at fixed locations in space over time. The classification of vector data with
timestamps depends on the type of geometries, such as points, lines, and
polygons (regions) (Erwig et al., 1999).

If we consider spatial points and point of time, spatio-temporal data can be
either discrete point data or trajectory data. Spatio-temporal discrete point
data can be event data that represent where and when the event happened. For
example, a traffic accident can be represented by accident location and time
of the accident. Therefore, event data can be used to model many real-life
events such as crime events, disease outbreaks, road accidents, plane crashes,
volcano eruptions, and more (Atluri et al., 2018). Spatio-temporal discrete
point data can also be point reference data, which is collected from a set of
moving reference points in space over time. For example, drone observations of
bushfires at point locations in space over time is discrete point reference
data (Atluri et al., 2018). Whereas, a trajectory is a path that consists of a
set of points generated by moving objects in geographical space over time. The
main sources of trajectory data are either GPS-enabled devices (e.g., taxi
trajectories) or sensors attached to moving objects (e.g., animal
trajectories). Trajectories can be classified into four main categories, such
as mobility of humans, vehicles, animals, and natural phenomena (such as
hurricanes, tornados) (Zheng, 2015). The knowledge derived from trajectory
data is important in many application domains, such as intelligent
transportation systems, urban planning, location-based social networks,
recommendation systems, animal migration analysis, and more.

Similarly, spatio-temporal data can be classified by considering other
geometries like lines and regions instead of points, and timestamps like
interval and period instead of a point of time (Erwig et al., 1999; Kisilevich
et al., 2010). Finally, due to the nature of spatio-temporal data, we can
perform queries based on spatial, temporal, and spatio-temporal properties and
relationships.

##  5\. Spatial Databases

Spatial databases can be divided into two main categories, relational
databases (SQL), and NoSQL databases. Traditional relational database
management systems (RDBMSs) have been around and serving us well for a long
time. These RDBMSs with spatial support are stable, mature, efficient and have
been used in a wide range of application domains at the enterprise level. Due
to the large volume and diverse form of data being generated from a wide range
of sources, NoSQL database systems, and big spatial data processing platforms
have emerged. One may ask what is the significance of Spatial RDBMSs in this
era of big spatial data. But Spatial RDBMSs are adapting to this era by
integrating new features continuously. Researchers from industry and academia
developed a few parallel and distributed systems by utilizing spatial RDBMSs.
In this context, researchers are still using these modern spatial RDBMSs in a
wide range of application domains. This section will address the significance
of modern spatial RDBMSs in this era of big spatial data and explores the
spatial support of both SQL and NoSQL databases.

###  5.1. Spatial Relational Databases

Traditional RDBMSs are popular for efficient data management and query
processing. Therefore, research and development of spatial and spatio-temporal
database systems have started by adding extensions to traditional RDBMSs. For
example, PostgreSQL/PostGIS (OSGeo, 2020c), Oracle Spatial (Team, 2020a), IBM
DB2 Spatial Extender (Adler, 2001), Microsoft SQL Server (Fang et al., 2008),
MySQL Spatial (MySQL, 2020), and SpatialLite (Furieri, 2020) are some popular
spatial RDBMSs. The up-to-date features of these popular spatial RDBMSs are
summarized in Table 1. These spatial RDBMSs are mature, stable, and contain
efficient SQL query engines. All of these systems support data formats (WKT
and WKB) and geometry objects (point, linestring, polygon, and collections)
specified by OGC Simple Features for SQL (part-2) (OGC, 2010). Also, most of
these spatial RDBMSs support R-Tree type indexing, except SQL Server and IBM
DB2, where grid indexing has been utilized. Among them, only
PostgreSQL/PostGIS and Oracle Spatial can store and process spatial raster
data. Popular spatial RDBMSs such as PostgreSQL/PostGIS, Oracle Spatial, and
SQL Server provide the complete set of spatial relationship and analysis
functions defined in OGC (OGC, 2010) and ISO SQL/MM (part-3) (Stolze, 2003)
standard. Therefore, a wide range of spatial queries (e.g., spatial join,
range) can be executed in these databases.

Table 1. Popular Spatial RDBMSs

|  | Data
---
Formats
| Geometry
---
Types
| Spatial
---
Indexing
| Raster
---
Support
| Spatial
---
Functions
| PostgreSQL/
---
PostGIS
| WKT, WKB,
---
GML, KML,
GeoJSON,
SVG
| Point,
---
LineString,
Polygon,
Collections1
| GiST,
---
SP-GiST,
BRIN
Yes |  | OGC SFA-SQL,
---
ISO SQL/MM2
Oracle Spatial |  | WKT, WKB
---
JSON,
GeoJSON
| Point,
---
LineString,
Polygon,
Collections
R-Tree | Yes |  | OGC SFA-SQL,
---
ISO SQL/MM
| Microsoft
---
SQL Server
| WKT, WKB,
---
GML, GeoJSON
| Point,
---
LineString,
Polygon,
Collections
| Multi-level
---
Grid
No |  | OGC SFA-SQL,
---
ISO SQL/MM
| IBM DB2
---
Spatial Extender
| WKT, WKB,
---
GML, KML
ESRI Shapefile
| Point,
---
LineString,
Polygon,
Collections
Spatial Grid | No |  | OGC SFA-SQL,
---
ISO SQL/MM
MySQL Spatial | WKT, WKB |  | Point,
---
LineString,
Polygon,
Collections
R-Tree | No | OGC SFA-SQL
| SQLite/
---
SpatialLite
WKT, WKB |  | Point,
---
LineString,
Polygon,
Collections
R*-Tree | No | OGC SFA-SQL

1Collections - MultiPoint, MultiLineString, MultiPolygon, GeometryCollection
2Support functions compliant with OGC SFA-SQL (OGC, 2010) and ISO SQL/MM
(Stolze, 2003) standard

However, due to the I/O bottleneck, lack of parallelism and scalability, the
performance of these systems deteriorated with the increasing volume of data.
Also, it is challenging to model heterogeneous and multidimensional data in
spatial RDBMSs. Still these databases went through a lot of changes in the
last couple of years. Researchers and developers are continuously integrating
new features to these systems or utilizing these systems to meet the current
demands of spatial data. For example, the GeoJSON data format of
PostgreSQL/PostGIS. Therefore, this section will also address the significance
of modern spatial RDBMSs in this era of big spatial data by discussing changes
made in one of the most popular spatial RDBMS, PostgreSQL/PostGIS.

PostgreSQL is an open-source, vertically scalable, and extensible RDBMS.
PostGIS is a spatial extension of PostgreSQL, which supports OGC-compliant
spatial SQL queries. Vertical scaling can improve the performance of
PostgreSQL/PostGIS on a single computer system, but horizontal scalability is
required for processing a large volume of spatial data. We can achieve
horizontal scalability through sharding in PostgreSQL. One can also achieve
read scalability by utilizing pgpool (Pgpool-II (Pgpool Team, 2013)) and
streaming replication instead of sharding. However, sharding can reduce the
I/O bottleneck significantly by partitioning data across multiple nodes of a
cluster (Momjian, 2020). Several solutions are available where horizontal
scalability and query parallelism achieved through sharding, such as Postgres-
XL (Team, 2018a), Citus (Data, 2011), PL/Proxy (Team, 2020b), etc. PostGIS can
be integrated with both Citus and Postgres-XL. PostgreSQL (v9.6+) also has a
built-in sharding feature called Foreign Data Wrappers (FDW), which allows
PostgreSQL to access data from external sources. Therefore, data can be
distributed across nodes of a cluster, where each partition can be accessible
through FDW directly from disk or main memory instead of local tables of
PostgreSQL. Moreover, features like parallel sequence scans, parallel joins,
and parallel aggregates for parallel spatial query processing are now
completely working with PostgreSQL (v12) and PostGIS (v3.0). Thus, one can
take advantage of default parallel processing support to process large scale
spatial data in PostgreSQL/PostGIS (Ramsey, 2019).

As today’s big data comes from diverse sources in different formats, it is not
always possible to store data in a tabular format in RDBMS. Therefore, NoSQL
database systems emerged in the last decade. However, JSON and JSONB data
types were added to PostgreSQL in 2012 and 2014, respectively. Recently,
SQL/JSON was introduced in PostgreSQL v12, which is compliant with the
SQL-2016 standard. The SQL-2016 standard has recognized NoSQL and includes
features for the SQL/JSON data model and path language as well as commands for
storing, publishing, and querying JSON data. Thus, now we can query and index
JSON (JSONB) data in PostgreSQL (Korotkov, 2019).

Some research work has also utilized PostgreSQL/PostGIS to develop parallel
query processing infrastructures for spatial data (Alam, 2018). For example,
Niharika (Ray et al., 2013) utilizes the powerful features of
PostgreSQL/PostGIS to implement a parallel query processing system along with
efficient data declustering and load balancing techniques. However, as its
storage layer is not distributed, it needs to replicate the whole dataset in
each node of a cluster. On the contrary, each node of Paragon (Haynes et al.,
2015) needs to host a subset of the partitions only. MobilityDB (Zimányi et
al., 2019) was developed as an extension of PostgreSQL/PostGIS, which provides
support for storing and querying moving objects data (spatial trajectory).
This support includes spatio-temporal data types, indexing techniques, and
query operations. Recently, MobilityDB emerged as a distributed system by
integrating with Citus (Data, 2011) for processing massive trajectory data
(Bakli et al., 2019b). CARTO (CARTO, 2020) provides spatial analysis and
mapping services for a wide range of application areas for many organizations
by developing APIs, libraries, and tools. Developers and GIS scientists use
CARTO for developing GIS applications. CARTO also uses PostgreSQL/PostGIS
underneath as a spatial database server.

Similarly, other spatial RDBMSs (e.g., Oracle Spatial and SQL Server) are also
incorporating new features continuously to adapt to this era of big spatial
data. Besides, a large number of companies are still using spatial RDBMSs for
their businesses. This means that currently, if someone ask the following
questions: (i) can spatial RDBMSs (like PostgreSQL/PostGIS) scale well for the
problems we are dealing today?; (ii) can these systems process massive
datasets?; (iii) can these systems process data in different formats?; or (iv)
how long will these systems survive in this era of big data?; the answers to
these questions would be yes, these systems are scalable enough for many
problems we are dealing with today and can process a certain volume of data in
different formats, and will be around for a long time.

###  5.2. Spatial NoSQL Databases

NoSQL (Not-Only-SQL) database systems (Gessert et al., 2017; Davoudian et al.,
2018) are also known as non-relational database systems. Carlo Strozzi came
with the NoSQL term in 1998 (Strozzi, 2010). Since a large volume of data
comes from diverse sources with various formats (such as semi-structured and
unstructured), it is challenging to model these data using relational tables
as there is no predefined fixed schema. Besides, traditional relational
database systems suffer due to the lack of parallelism, I/O bottleneck, and
horizontal scalability. Therefore, NoSQL database systems have emerged as an
alternative data management technology in the last decade. NoSQL database
systems can be classified into four broad groups based on the core data model,
(1) Key-Value Databases (e.g., Redis, Oracle NoSQL), (2) Column Family (Wide-
Column) Databases (e.g., Cassandra, HBase), (3) Document Databases (e.g.,
MongoDB, Couchbase), and (4) Graph Databases (e.g., Neo4j, ArangoDB).

NoSQL database systems are fault-tolerant, scalable, highly available, and
support high update rates. However, a few of these systems have native spatial
support currently. Spatial extensions have been added to some of these NoSQL
databases in recent years. The current spatial support of some popular NoSQL
databases is presented in Table 2. Redis (RedisLabs, 2020a) is an in-memory
key-value store that has implemented a geohash spatial index to accelerate
query processing. It operates based on a Geo Set data structure, which is
built with a Sorted Set. A set of commands (e.g., geoadd, geopos, geohash,
georadius, and more) are available in Redis to create an index and perform
spatial operations on point datasets stored in Geo Sets. However, these
spatial commands can only perform limited spatial analyses on point type
geometry. Also, Redis does not support SQL-like query language. On the
contrary, one can run SQL-like spatial queries on Oracle NoSQL (Oracle, 2019),
which supports all common geometry objects, geohash indexing, and a set of
spatial operators for processing spatial data.

Table 2. Popular NoSQL Databases with Spatial Support

| NoSQL
---
Database
| Data
---
Model
| Spatial
---
Support
| Data
---
Formats
| Geometry
---
Types
| Spatial
---
Indexing
| Spatial
---
Functions
| SQL-like
---
Query Language
Redis | Key-Value | Native (RedisLabs, 2020b) | GeoJSON | Point | geohash |  | geoadd, geodist,
---
zrange, zscan,
geopos, geohash,
georadius,
georadiusbymember,
zrem
| Not
---
Supported
| Oracle
---
NoSQL
Key-Value | Native (Oracle, 2019) | GeoJSON |  | Point,
---
LineString,
Polygon,
Collections1
geohash |  | geo_intersect,
---
geo_inside,
geo_within_distance,
geo_near
| Yes
---
Supported
MongoDB | Document | Native (Inc, 2020) |  | GeoJSON,
---
Legacy
Coordinate
Pairs
| Point,
---
LineString,
Polygon,
Collections
| 2dsphere,
---
2d
| $near,
---
$nearSphere,
$geoWithin,
$geoIntersect,
$geoNear
| Not
---
Supported
Couchbase | Document | GeoCouch (Couchbase, 2011) | GeoJSON |  | Point,
---
LineString,
Polygon,
Collections
R-Tree | BBox | N1QL
Cassandra | Wide_Column |  | Lucene Index
---
Plugin (Inc., 2018)
WKT |  | Point,
---
LineString,
Polygon,
Collections
| Lucene
---
Index
(Secondary
Index)
| intersects,
---
contains,
is_within
CQL
Neo4j | Graph | Native | N/A | Point (2D, 3D) | Hilbert-curve | Distance | Cypher
| Neo4j-Spatial
---
(Team, 2019b)
WKT, WKB |  | Point,
---
LineString,
Polygon,
Collections
R-Tree |  | Contain, Cover,
---
Cross, Disjoint,
Intersect, Overlap,
Touch, Within, etc.

1Collections - MultiPoint, MultiLineString, MultiPolygon, GeometryCollection

MongoDB (Inc, 2020) is a document database that has native support for
processing spatial data. MongoDB supports common GeoJSON objects (such as
point, linestring, polygon, and collections) and 2dsphere indexes to model
geometries on a spherical surface. It can also store geometries on a 2D
surface as legacy coordinate pairs and 2d indexes to model 2D queries. MongoDB
provides a set of operators such as $near, $nearSphere, $geoWithin,
$geoIntersect, and $geoNear to perform spatial queries. However, like Redis,
it does not have support for SQL-like queries. Whereas, Couchbase (Team, 2011)
is another popular document database that supports SQL-like query language,
N1QL. GeoCouch (Couchbase, 2011) is a spatial extension for both Couchbase and
Apache CouchDB (Foundation, 2020d). GeoCouch is developed based on R-Trees and
supports common GeoJOSN objects like MongoDB. It allows executing spatial
queries using bounding-boxes (BBox). However, MongoDB is richer in terms of
support to perform a wide range of spatial queries.

Apache Cassandra (Foundation, 2016) is a column family database that does not
have native support for processing spatial data. Stratio’s Lucene Index (Inc.,
2018) is a spatial plugin for Cassandra, whose spatial index is an extension
of Cassandra’s secondary indexes. The Lucene plugin provides a set of spatial
predicates (intersects, contains, and is_within) and transformation functions
(buffer, convexhull, union, and more), which enable Cassandra to store, index,
and process common spatial objects such as point, linestring, polygon, and
collections. Brahim et al. (Brahim et al., 2016) have also extended CQL
(Cassandra Query Language) to add spatial support with Cassandra, which
includes geohash indexing and spatial queries (within_circle, within_polygon,
and within_path).

Neo4j (Inc., 2020) is one of the most popular graph database systems, which
supports an efficient query language, Cypher. Neo4j Spatial (Team, 2019b) is a
library that facilitates Neo4j to store, index, and process spatial data. This
library contains modules to import spatial data (ESRI Shapefile and OSM), and
R-Tree indexing can be applied during import or later to stored data. It also
supports a wide range of spatial functions (contain, cover, intersect, and so
on) to perform spatial operations on common geometric objects (point,
linestring, polygon, and collections). Besides, it wraps popular geospatial
libraries, JTS and GeoTools, and therefore, one can utilize the
functionalities of these libraries in Neo4j. However, Neo4j spatial is an
external library, and hence, it is not highly scalable. Moreover, this library
suffers when applications require high concurrency and need to handle a large
volume of data. Therefore, Neo4j (v3.4) introduced two native data types,
spatial (Point) and temporal (Date, Time, DateTime, Duration, and other
types). This point type supports both 2D and 3D points and can be specified by
either a geographic or cartesian coordinate system. Neo4j uses Hilbert-curve
for indexing points (2D or 3D) and only supports spatial distance function.
Similarly, it also provides indexes and functions to process temporal data.

Researchers have also developed several big spatial data processing systems by
utilizing the capability of NoSQL databases in recent years that will be
discussed in Section 6.3. The performance of NoSQL databases is evaluated and
discussed by several researchers for spatial workloads (Kim and Kanwar, 2019;
Kanwar, 2019). Some of these performance analyses also involve comparisons
with relational spatial databases (Baralis et al., 2017; Josefsson, 2018;
Agarwal and Rajan, 2016; Bartoszewski et al., 2019; Makris et al., 2019).

###  5.3. Future Research Directions

The codebase of spatial RDBSMs is mature, stable, efficient, and easily
extensible. Also, these systems support efficient SQL queries along with
current distributed and parallel capability. By considering the current state
of spatial RDBMSs, it would be a great idea to incorporate distributed storage
like HDFS or utilize the main memory like Spark in distributed systems
developed based on spatial RDBMSs.

Currently, the spatial support of NoSQL databases lacks available spatial
operations compared to spatial RDBMSs. Also, a few of these databases do not
have support for SQL-like spatial queries. In addition, we need to work to add
support to store and process spatial raster and trajectory data in NoSQL
databases. At present, the graph database, Neo4j (v4.0), can scale
horizontally through sharding, and therefore, it will be interesting to see
the performance of distributed graph databases like Neo4j for processing
spatial data.

##  6\. Big Spatio-temporal Data Processing Infrastructures

With the rise of big spatial and spatio-temporal data and its application
domains, there is demand for highly scalable and distributed data processing
systems to store, manage, and process the massive volume of data. Therefore,
researchers from both academia and industry are working towards achieving
these demands. The big spatial (or spatio-temporal) data processing systems
that have been developed in the last couple of years are mainly based on
MapReduce framework Hadoop (Foundation, 2020a), NoSQL databases (Gessert et
al., 2017; Davoudian et al., 2018), and Spark (Foundation, 2018). Most of
these systems have built spatial or spatio-temporal support either by adding a
layer on top existing systems or by extending the core of the existing
systems. Besides, a number of big spatial or spatio-temporal data processing
systems have been developed either from scratch or by utilizing data
processing platforms other-than Hadoop, NoSQL, and Spark. For example,
recently, Python libraries such as DASK (Dask Development Team, 2016) and
RAPIDS (Team, 2018c) have started to gain popularity as a big data platform.

In this section, we first categorize the big spatio-temporal data
infrastructures based on their development criteria. The systems under each of
the categories are then divided into groups based on the type of data
processing systems, which include spatial (spatial vector and raster, spatial
stream), spatio-temporal, and trajectory. An overview of these systems is
provided in Figure 2. Finally, this section provides a comprehensive review of
each of these systems based on their supported features, such as data types,
partitioning and indexing techniques, query language, and supported spatio-
temporal operations.

Figure 2. Overview of Big Spatio-temporal Data Processing Infrastructures

###  6.1. Hadoop-based Big Spatio-temporal Infrastructures

Hadoop (Foundation, 2020a) is a highly scalable and distributed open-source
MapReduce (Dean and Ghemawat, 2008) framework for processing a large volume of
data, which is integrated with the HDFS (Shvachko et al., 2010) distributed
storage system. Hadoop does not have any native support for processing spatial
(or spatio-temporal) data. Therefore, Hadoop distributes and indexes data
across the clusters without considering the spatial (or spatio-temporal)
aspect of data, which affects query processing performance on the data
negatively. Due to the huge popularity of Hadoop as a big data processing
framework in both research and industry communities, a number of extensions to
Hadoop were proposed to store, process, and analyze spatial (or spatio-
temporal) data. These systems include Hadoop-GIS (Aji et al., 2013),
SpatialHadoop (Eldawy and Mokbel, 2015), ESRI Tools for Hadoop (Whitman et
al., 2014), Parallel SECONDO (Güting and Lu, 2015), ST-Hadoop (Alarabi et al.,
2018), Summit (Alarabi, 2019), and HadoopTrajectory (Bakli et al., 2019a). A
detailed feature matrix of these systems is provided in Table 3.

Hadoop-GIS (Aji et al., 2013) is a spatial extension of Hadoop. It integrates
a spatial layer on top of Hadoop instead of changing the core of the
framework. As a result, the performance of Hadoop-GIS for processing spatial
data is not quite as good as expected. Besides, Hadoop-GIS extends Hive
(Thusoo et al., 2009) to support declarative spatial querying (HiveSP) that
adds an extra layer of overhead over Hadoop for processing spatial queries.
SpatialHadoop (Eldawy and Mokbel, 2015) incorporates spatial support inside
the core of the Hadoop framework. Therefore, it achieves better performance
than Hadoop-GIS for running spatial queries on a large dataset. A SQL-like
query language, Pigeon (Eldawy and Mokbel, 2014), which extends Pig Latin
(Olston et al., 2008), is also introduced to run spatial queries on
SpatialHadoop. However, the evaluation shows that Pigeon is not efficient to
execute spatial join queries on large datasets (Alam et al., 2018).

Table 3. Hadoop-based Spatio-temporal Systems

| System Type | Data Types | Partitioning | Indexing |  | SQL-Like Query
---
Language
| Supported
---
Queries
|  Hadoop-GIS (Aji et al., 2013)
---
(2013)
Spatial |  | Point,
---
LineString,
Polygon
| SATO (Vo et al., 2014)
---
Framework1
| Two-Level
---
(Global, Local)
R*-tree
| HiveSP
---
(Extended HiveQL)
| Range, kNN,
---
Join
|  SpatialHadoop (Eldawy and Mokbel, 2015)
---
(2015)
Spatial |  | Point,
---
LineString,
Polygon
| Fixed-Grid,
---
STR
| Two-Level
---
(Global, Local)
Grid File,
R-tree,
R+-tree
| Pigeon
---
(Extended Pig Latin)
| Range, kNN,
---
Join
| Parallel SECONDO
---
(Güting and Lu, 2015)(2015)
| Spatio-temporal
---
(Trajectory)
| Point,
---
LineString,
Region,
Instant, Period,
Periods, Interval
3D Grid |  | B-Tree,
---
R-Tree
Executable | Range, Join
|  ST-Hadoop (Alarabi et al., 2018)
---
(2017)
Spatio-temporal |  | STPoint,
---
Time,
Interval
| Time-Slice,
---
Data-Slice
| Two-Level
---
L1: Temporal
L2: Spatial
Spatial:
SpatialHadoop
Extended Pigeon | Range, Join
|  Summit (Alarabi, 2019)
---
(2018)
| Spatio-temporal
---
(Trajectory)
| Trajectory,
---
Time,
Interval
| Spatial-based,
---
Segmentation-based
| Two-Level
---
L1: Temporal
L2: Spatial
Temporal: ST-Hadoop
Spatial: Extended
Extended Pigeon |  | Range, kNN,
---
kNN Similarity,
Join
| HadoopTrajectory
---
(Bakli et al., 2019a)(2019)
| Spatio-temporal
---
(Trajectory)
| Point, Region,
---
Instant, Interval,
Periods,
TrajSegment,
Trajectory
N/A |  | Grid, R-Tree
---
(3D Extension)
e.g., 3DR-Tree
N/A |  | Range, kNN,
---
Join

1SATO supports Fixed-Grid, Binary-Space, Hilbert-Curve, Strip-based, and STR
partitioning techniques.

Due to the lack of spatio-temporal data types, partitioning, and indexing
techniques, both Hadoop-GIS and SpatialHadoop suffer when querying on spatio-
temporal datasets. ST-Hadoop (Alarabi et al., 2018) is a temporal extension of
SpatialHadoop, which incorporates spatio-temporal awareness into each layer of
SpatialHadoop. However, ST-Hadoop was developed by considering attributes of
discrete spatio-temporal point data, not trajectory data, and properties of
trajectory data are quite different from discrete point data. Therefore, if we
partition and index trajectory data using ST-Hadoop, the performance of query
processing will be be impacted negatively. For example, each individual
trajectory of an object contains a set of points and an object can have
multiple trajectories. Now, if we partition trajectories of a moving object
using ST-Hadoop, they may be partitioned into different blocks of HDFS over
different clusters, which will require more time to perform queries.
Therefore, Summit (Alarabi, 2019) was developed as an extension of ST-Hadoop
to include data types, partitioning and indexing techniques, and operations,
for processing trajectory data. Bakli et al. (Bakli et al., 2019a) have
proposed HadoopTrajectory, which adds a diverse set of data types and
operators into the core of Hadoop to store and process trajectory data. The
careful integration of partitioning and indexing strategies for trajectory
data into Hadoop layers makes their system an efficient big trajectory
processing system. Parallel SECONDO (Güting and Lu, 2015) integrates SECONDO
DBMS with Hadoop for scalability. SECONDO (Güting et al., 2010) is a prototype
DBMS to store and process moving object data. SECONDO supports data models to
represent spatial and temporal data, operations for processing moving objects,
and a SQL-like query language. As SECONDO was developed for a single computer
and unable to process big data, SECONDO was combined with Hadoop to execute
parallel queries and distribute data across a cluster of nodes. However,
Hadoop only does the scheduling and query coordination tasks received from the
SECONDO master node, while SECONDO executes the query in each worker node.
Finally, SECONDO master node needs to aggregate the results. Therefore,
Parallel SECONDO has not able to utilize the power of Hadoop properly due to
its centralized behavior.

###  6.2. Spark-based Big Spatio-temporal Infrastructures

Apache Hadoop is a disk-based system optimized for I/O efficiency. Therefore,
the performance of Hadoop-based big data systems can deteriorate at scale. On
the other hand, the growing main memory capacity in a cluster of machines has
fueled the development of in-memory big data systems. Apache Spark
(Foundation, 2018; Zaharia et al., 2010, 2016) is a popular and widely used
distributed in-memory big data processing framework, which is implemented by
taking advantage of a large pool of memory available in a cluster of machines
to achieve better performance than disk-based systems. However, like Hadoop,
Spark also does not have native support for processing spatial (or spatio-
temporal) data. Due to the lack of spatial (or spatio-temporal) data types,
partitioning and indexing strategies, and spatial operations, Spark process
spatial (or spatio-temporal) data in the same way as non-spatial data.
Therefore, several Spark-based spatial (or spatio-temporal) data processing
systems have been developed in the last few years to alleviate these
limitations. These systems include SpatialSpark (You et al., 2015), GeoSpark
(Yu et al., 2015), LocationSpark (Tang et al., 2016; Tang et al., 2019), Simba
(Xie et al., 2016), STARK (Hagedorn et al., 2017b), SparkGIS (Baig et al.,
2017), TrajSpark (Zhang et al., 2017), Elcano (Engélinus and Badard, 2018),
DiStRDF (Nikitopoulos et al., 2018), DITA (Shang et al., 2018), UlTraMan (Ding
et al., 2018), Dragoon (Fang et al., 2021), and GeoTrellis (Eclipse Foundation
et al., 2016). The detailed feature matrix of these systems is presented in
Table 4.

Table 4. Spark-based Spatio-temporal Systems

| System Type |  | Data
---
Types
Partitioning | Indexing |  | Query
---
Language
| Supported
---
Queries
|  SpatialSpark (You et al., 2015)
---
(2015)
Spatial |  | Point,
---
LineString,
Polygon
| Fixed-Grid,
---
Binary-Split,
STR
R-Tree | N/A |  | Range,
---
Broadcast-Join,
Partitioned-Join
|  GeoSpark (Yu et al., 2015)
---
(2015)
Spatial |  | Point,
---
LineString,
Polygon,
Rectangle
| Uniform-Grid
---
Voronoi,
R-Tree,
Quad-Tree,
KDB-Tree
| R-Tree,
---
Quad-Tree
| Extended
---
Spark SQL
| Range, kNN,
---
Spatial-Join,
Distance-Join
|  Simba (Xie et al., 2016)
---
(2016)
Spatial | Point | STR |  | R-Tree
---
(Multi-Level)
| Extended
---
Spark SQL
| Range, kNN,
---
kNN-Join,
Distance-Join,
|  LocationSpark (Tang et al., 2016)
---
(2016)
Spatial |  | Point,
---
LineString,
Polygon,
Rectangle
| Uniform-Grid,
---
R-Tree,
Quad-Tree
| R-Tree
---
Quad-Tree,
IR-Tree
(Multi-Level)
N/A |  | Range, kNN,
---
Range-Join,
kNN-Join
|  SparkGIS (Baig et al., 2017)
---
(2017)
Spatial |  | Point,
---
LineString,
Polygon
| Fixed-Grid,
---
Binary-Space,
Quad-Tree,
Strip-based,
Hilbert-Curve,
STR
| R*-Tree
---
(Multi-Level)
N/A |  | Range, kNN,
---
Join
|  Elcano (Engélinus and Badard, 2018)
---
(2018)
Spatial |  | Point,
---
LineString,
Polygon
N/A |  | GeoHash,
---
R-Tree,
GeoHash + R-Tree
| Extended
---
Spark SQL
Join
|  STARK (Hagedorn et al., 2017b)
---
(2017)
| Spatial,
---
Spatio-temporal
| STObject
---
(geo, time)
| Fixed-Grid,
---
Binary-Space
| R-Tree
---
(Live & Persistent)
Piglet | kNN, Join
|  DiStRDF (Nikitopoulos et al., 2018)
---
(2018)
Spatio-temporal |  | Point,
---
Timestamp
| Range-Partition
---
| Hilbert Hash
---
Z-order Hash
SPARQL | Range, Join
|  TrajSpark (Zhang et al., 2017)
---
(2017)
| Spatio-temporal
---
(Trajectory)
| Point,
---
Timestamp
| Quad-Tree,
---
KD-Tree
| Local: Hash,
---
Global: Multi-Level
L1: Temporal
L2: Spatial
L3: B+-Tree
N/A |  | Single Object,
---
Range,
kNN
|  DITA (Shang et al., 2018)
---
(2018)
| Spatio-temporal
---
(Trajectory)
| Point,
---
Timestamp
STR |  | (Multi-Level)
---
Global - R-Tree
Local - Trie-like
| Extended
---
Spark SQL
| Similarity
---
Search and Join
|  UlTraMan (Ding et al., 2018)
---
(2018)
| Spatio-temporal
---
(Trajectory)
| Point,
---
TimeStamp
STR |  | Two-Level
---
(Global, Local)
R-Tree
N/A |  | ID, Range,
---
kNN,
|  Dragoon (Fang et al., 2021)
---
(2021)
| Spatio-temporal
---
(trajectory)
offline & online
| Point,
---
TimeStamp
| ID, Grid,
---
STR, Time
| Two-Level
---
(Global, Local)
R-Tree
N/A |  | ID, Range,
---
kNN

GeoSpark (Yu et al., 2015; Yu et al., 2019) is a spatial extension of Spark,
which extends Spark RDDs (Resilient Distributed Datasets) (Zaharia et al.,
2012) to support spatial data types called Spatial RDD. It supports several
spatial partitioning (Fixed-Grid, Voronoi Diagram, R-Tree, and Quad-Tree) and
indexing (R-Tree and Quad-Tree) techniques to speed-up spatial queries (range,
kNN, and join) on Spatial RDDs. Initially, it did not have any support for the
SQL query (Yu et al., 2015). Recently, GeoSpark has introduced an SQL API
(SQL/MM-Part 3 Standard) (Yu et al., 2019) as a spatial extension of Spark SQL
(Armbrust et al., 2015). SpatialSpark (You et al., 2015) can perform range
queries and two kinds of spatial join queries (broadcast and partitioned) over
geometric objects. Data can be partitioned using Fixed-Grid, Binary-Split, and
Sort-Tile techniques and indexing using R-tree. However, it does not have
support for SQL queries. Since SpatialSpark has implemented as a library on
top of Spark instead of modifying the core of the framework, it may affect the
query performance. Besides, both GeoSpark and SpatialSpark do not have any
support for handling data and query skew.

On the other hand, Simba (Xie et al., 2016) extends Spark SQL (Armbrust et
al., 2015) and DataFrame API to make spatial support for Spark. It improves
the query performance by introducing multi-level (global and local) R-tree
indexing on RDDs, and spatial-aware (logical and cost-based) query planning.
Moreover, STR partitioner (Leutenegger et al., 1997) mitigates the data
partitioning skew significantly due to its consideration of in-memory
partition size, data locality, and load balancing. However, Simba only
supports spatial operations (range, kNN, distance-join, kNN-join) over point
and rectangle objects. LocationSpark (Tang et al., 2016; Tang et al., 2019)
was developed as a spatial library (like SpatialSpark) over Spark. It stores
spatial data as a key-value pair, where the key can be any geometric object
(points, lines, polygons), and the values can be any user-specified text. Like
Simba, it also contains an efficient cost model and a query execution planner
to deal with data partitioning and query skew. Similarly, it supports multi-
level indexing, where the global index (grid, region Quad-tree) partitions the
data across a cluster of nodes and a local index (R-tree, Quad-tree variant,
IR-tree) for indexing data on each node. Moreover, it introduced a spatial
bloom filter to reduce the communication cost of the global index.
LocationSpark only keeps frequently accessed data in memory which reduces the
chances of an overflow. It supports a number of spatial operations (such as
range, kNN, range-join, and kNN-join) and a few spatial analysis functions
(such as clustering, skyline computation, and spatio-textual topic
summarization). However, it does not have support for SQL-like queries.
SparkGIS (Baig et al., 2017) adopts Spark for processing spatial queries (kNN,
join). It supports several dynamic partitioning algorithms (Fixed-Grid,
Binary-Space, Quad-Tree, Strip-based, Hilbert-Curve, and STR), which mitigates
the data distribution skew across the cluster. Like Simba and LocationSpark,
it also incorporates multi-level (global and local) R*-tree indexing, which
can be pre-generated or on-demand local in-memory indexing. Like
LocationSpark, it also keeps data in-memory as much as possible to avoid
running out of memory.

However, these five spatial data processing solutions are not fully compliant
with the ISO standard and OGC specifications. Elcano (Engélinus and Badard,
2018) implements ISO and OGC-compliant 2D geometry data types, spatial
functions, and operators based on Spark SQL (Armbrust et al., 2015). It
supports three indexation methods, GeoHash, R-Tree, and a combination of both
(hybrid) (Engélinus et al., 2019). This paper reports the spatial join
performance of Elcano over SpatialSpark and PostgreSQL/PostGIS. However, this
paper did not include any information regarding data partitioning, and the
process of spatial query execution of Elcano.

All these Spark-based systems discussed above are only for spatial data
processing. STARK (Hagedorn et al., 2017b) is a spatio-temporal data
processing system. It integrates spatial and temporal data types, operators,
and predicates to Spark RDD’s. It supports fixed grid and cost-based binary
space partitioning to distributed data across the nodes of a cluster. It
allows two modes of indexing, where the live index is built for each partition
during query execution, and persistent indexing allows to create and save
indexed RDD into disk or HDFS for future use. STARK supports queries on
unindexed data as well. In addition to spatial join and kNN query, it supports
DBSCAN clustering. STARK also extends Pig Latin for declarative spatio-
temporal queries, called Piglet. Though STARK has support for temporal
features, the only reported evaluation results are for spatial operations.
DiStRDF (Nikitopoulos et al., 2018) is a distributed Spatio-temporal RDF (W3C,
2014) data processing system based on Spark. It consists of two layers, where
the storage layer is responsible for storing encoded RDF triples into HDFS and
dictionary of mapping values into the Redis in-memory key-value store
(RedisLabs, 2020a). The query processing layer is based on the Spark query
engine, which is responsible for parsing, planning, and executing SPARQL
(Team, 2013) queries. Here, Apache Jena (Foundation, 2020c) is used as a query
parser. It uses spatio-temporal range partitioning to distribute 1D encoded
RDF triples. It also supports Hilbert and Z-order hashing for indexing RDF
triples. However, it only supports spatio-temporal point data.

As it is mentioned in Section 6.1, trajectory data is quite different from
discrete spatio-temporal point data. Therefore, the performance of processing
trajectory data using STARK and DiStRFD will not be effective. Also, these
systems work well for historical static data and require re-partitioning the
whole dataset when the dataset has changed or updated. TrajSpark (Zhang et
al., 2017) always keeps the global index in the main memory and updates the
global index when new data arrives using the time-decay model by partitioning
only a batch of new data. TrajSpark also stores the updated the global index
into a disk to protect it from any future system failures. In TrajSpark,
first, the raw trajectory points (RDD) are partitioned based on data locality,
load balancing, and size of the partition using a Quad-Tree/KD-Tree strategy.
Then the local hash index is added to each partition, which creates an
IndexTRDD. Finally, a multi-level hybrid global index (level1 - temporal,
level2 - spatial, level3 - B+-Tree) is built for each partition. One can
perform single object-based, range, and kNN queries on trajectory data using
TrajSpark. However, it does not have any support for SQL-like queries. Zeyuan
et al. (Shang et al., 2018) developed DITA, a distributed in-memory trajectory
analytics system, where one can use both SQL and Dataframe API for trajectory
analysis. DITA adopts the STR (Leutenegger et al., 1997) partitioning strategy
to create balanced partitions of trajectory points. Like TrajSpark, it also
uses multi-level (global - R-Tree and local - Trie-like) indexing to expedite
the query performance. Besides, DITA has developed a cost model to reduce
inter-worker transmission costs and to balance the workload. Like DITA,
UITraMan (Ding et al., 2018) also uses STR for partitioning trajectory data,
but it has adopted R-Tree for both local and global indexing. Along with
global indexing, UITraMan also maintains a meta table to store information
related to moving objects and partitions in order to improve the efficiency of
trajectory data processing in Spark. Unlike other systems, UITraMan
incorporates a data processing pipeline that includes data loading,
preprocessing, extraction, and analysis. However, the on-heap data caching in
Spark induces GC (garbage collector) overhead, and the performance of Spark-
based systems is affected by this overhead. Therefore, UITraMan has added an
off-heap key-value store Chronicle Map (Chronicle Software, 2021) into the
block manager of Spark. Chronicle Map always keeps data in an off-heap cache,
which reduces GC overhead and ensures data persistence on run-time. UITraMan
supports ID, range, and kNN queries on trajectory data.

Among TrajSpark, DITA, and UITraMan, only TrajSpark alleviates the overhead of
re-partitioning the whole dataset when a new batch of dataset arrives. Thus,
TrajSpark achieves near real-time trajectory processing capability, but it is
not a system developed for processing real-time trajectory streams. Besides,
this new batch of data is loaded as RDDs in Spark, which are immutable, and
any updates on RDD create a new RDD, which is costly. Dragoon (Fang et al.,
2021) is a hybrid trajectory analytics system for processing both historical
(offline) and streaming (online) trajectories. The offline module of Dragoon
is similar to UITraMan, but Dragoon has utilized Chronicle Map in such a way
that it works for both historical and streaming trajectories. In addition, a
mutable RDD (mRDD) model is designed so that data can be updated later, which
is key to the hybrid storage of Dragoon. In Dragoon, data partitioning (ID,
spatial: Grid, STR, and temporal), indexing (two-level: R-Tree), and
trajectory queries (ID, range, and kNN) are developed for both offline and
online modules. Moreover, the hybrid data processing pipeline provides support
for both historical and streaming trajectories.

Other than these systems, GeoMesa (LocationTech, 2019) has recently added
support for Spark. However, all these systems are for processing vector
spatial and spatio-temporal data. None of these systems has support for raster
data. GeoTrellis (Eclipse Foundation et al., 2016) is a Scala library that
enables Spark to process spatial raster data. It also has limited support for
vector data. It can store into and query raster data from HDFS, S3, Accumulo,
Cassandra, and HBase.

###  6.3. NoSQL-based Big Spatio-temporal Infrastructures

A number of big spatio-temporal data processing systems have been developed by
using the power of NoSQL databases in the last couple of years, such as MD-
HBase (Nishimura et al., 2011), Distributed SECONDO (Nidzwetzki and Güting,
2015), GeoMesa (LocationTech, 2019; Fox et al., 2013; Hughes et al., 2015),
BBoxDB (Nidzwetzki and Güting, 2018, 2019), THBase (Qin et al., 2019),
TrajMesa (Li et al., 2020b), and JUST (Li et al., 2020a). The detailed feature
matrix of these systems is presented in Table 5.

Table 5. NoSQL-based Spatio-temporal Systems

| System Type |  | Underlying
---
NoSQL System
Data Types | Partitioning | Indexing |  | Query
---
Language
| Supported
---
Queries
|  MD-HBase (Nishimura et al., 2011)
---
(2011)
Spatio-temporal | HBase |  | Point,
---
Timestamp
Range-Partition |  | Quad-Tree,
---
KD-Tree
N/A | Range, kNN
|  GeoMesa (LocationTech, 2019)
---
(2013)
Spatio-temporal | Accumulo |  | Point,
---
LineString,
Polygon,
Timestamp
| Spatial,
---
Temporal,
Attribute
| Z2 and XZ2,
---
Z3 and XZ3,.
id and attr
CQL | Range
| Distributed
---
SECONDO (Nidzwetzki and Güting, 2015)
(2015)
| Spatio-temporal
---
(Trajectory)
Cassandra |  | Point, LineString,
---
Regions, Instant,
Period, Periods,
Interval
3D Grid |  | R-tree
---
(MMR-tree)
| SQL-Like,
---
Executable
Join
|  BBoxDB (Nidzwetzki and Güting, 2018)
---
(2018)
Spatial |  | Key-BBox-Value
---
Store
| Point,
---
LineString,
Polygon
| Grid,
---
KD-Tree,
Quad-Tree
| Two-Level
---
Local: R-Tree
Global: KD-Tree
N/A | Join
|  THBase (Qin et al., 2019)
---
(2019)
| Spatio-temporal
---
(Trajectory)
HBase |  | Point,
---
Timestamp
| MO-based
---
Model
| Two-Level
---
L1: Time Index
L2: Multi-level Grid
N/A |  | Single-Object,
---
Range, kNN
|  JUST (Li et al., 2020a)
---
(2020)
| Spatial,
---
Spatio-temporal
HBase |  | Geom,
---
Timestamp,
ST_Series,
T_Series
N/A |  | Z2 and XZ2,
---
Z3 and XZ3,
Z2T and XZ2T
JustQL | Range, kNN
|  TrajMesa (Li et al., 2020b)
---
(2020)
| Spatio-temporal
---
(Trajectory)
GeoMesa |  | Point,
---
Timestamp
N/A | XZT and XZ2+ | SQL-Like |  | ID-Temporal
---
Range, kNN,
Similarity

MD-HBase (Nishimura et al., 2011) extends HBase (Foundation, 2020b) to support
spatio-temporal queries (range and kNN). It applies linearization (e.g.,
Z-Ordering) to transform multi-dimensional locations data (id, lat, lon, time)
into 1D space for efficient indexing. A multi-dimensional index structure
(Quad-tree, KD-tree) is layered on top of a range partitioned key-value store
which allows real-time processing of range and kNN queries. MD-HBase achieves
high insertion throughput, which is important for location-based applications.
GeoMesa (LocationTech, 2019) is a spatio-temporal data processing system built
on top of NoSQL databases that provides efficient storage and querying
capabilities. It was implemented based on the distributed key-value store
Accumulo (Fox et al., 2013). Like MD-HBase, GeoMesa also linearizes the
keyspace by transforming multi-dimensional data (location, timestamp) into 1D
keys using space-filling curves. It creates a spatio-temporal index using
GeoHash and timestamps. Later, GeoMesa (LocationTech, 2019; Hughes et al.,
2015) has added support for HBase, Google BigTable, Cassandra, Kafka, and
Spark. At present, GeoMesa supports a set of indexing techniques, such as
spatial (Z2 and XZ2), spatio-temporal (Z3, XZ3), ID index, and attribute
index. Traditional key-value stores with multi-dimensional support could be
expensive to store and query non-point spatial data such as polygons or lines.
Jan et al. (Nidzwetzki and Güting, 2018) have proposed a distributed and
scalable key-bounding-box-value store for multi-dimensional data called
BBoxDB. Unlike traditional key-value stores, BBoxDB stores each value with an
n-dimensional axis-parallel bounding box, which defines the location of the
value in space. It uses space partitioning (Grid, KD-Tree, Quad-Tree) and
multi-level indexing (global: KD-Tree, local: R-Tree) to store and organize
the data across the cluster of nodes. However, BBoxDB only supports spatial-
join queries, which can be executed locally on co-partitioned data.

Distributed SECONDO (Nidzwetzki and Güting, 2015, 2017) is a general-purpose
DBMS, which can process relational, spatial, and spatio-temporal (including
trajectory) data. It integrates the highly scalable and available key-value
store Apache Cassandra and moving objects database SECONDO (Güting et al.,
2010), where Cassandra is used as distributed data storage and the SECONDO as
a query processing engine. Previously, SECONDO was integrated with Hadoop in
Parallel SECONDO, but suffered due to centralized management. Besides,
Parallel SECONDO (Güting and Lu, 2015) does not support high update rates.
Distributed SECONDO achives high update rates by integrating Cassandra. In
addition, it supports both SQL-like and executable query. JUST (JD Urban
Spatio-Temporal) (Li et al., 2020a) incorporates the power of HBase
(Foundation, 2020b), GeoMesa (LocationTech, 2019; Fox et al., 2013; Hughes et
al., 2015), and Spark (Foundation, 2018) into one system to stores, manages,
and processes spatio-temporal data. It adopts the NoSQL store HBase as an
underlying storage structure, GeoMesa as an indexing tool, and Spark as a
query execution engine. Along with indexing strategies of GeoMesa, JUST
introduces two indexing techniques, Z2T and XZ2T and efficient compression
mechanism to expedites the query performance significantly. A SQL-like query
language JustQL was also developed in JUST from scratch. Unlike in-memory
systems, JUST only loads the necessary data into memory. Hence, the nodes of a
cluster are not required to have much memory. Though NoSQL-based systems
(mentioned before) have achieved high update rates, their performance is
hindered by disk latency. JUST has improved query efficiency by utilizing the
main memory.

TrajMesa (Li et al., 2020b) has adopted GeoMesa to develop a trajectory
storage engine, where a horizontal storage schema (H-Store) is proposed for
efficient trajectory data management. Instead of storing each point of a
trajectory as a separate entry in a key-value store (V-Store), H-Store allows
storing an entire trajectory in one-row with compression. Hence, in addition
to reducing the storage size significantly, H-Store also improves the query
efficiency by reducing disk I/O in TrajMesa. To perform a set of SQL-like
queries (ID-Temporal, Range, kNN, and Similarity) on trajectory data
efficiently, TrajMesa introduced ID temporal, XZT, and extended XZ2 indexing
of GeoMesa as spatial range indexing, XZ2+. Most importantly, TrajMesa
incorporates a module for trajectory preprocessing (Ruan et al., 2018)
containing functions for noise filtering, segmentation, stay point detection,
map matching, and other statistical analysis. On the other hand, if we split
and store the trajectories of the same moving object (MO) into different
partitions on different nodes of a cluster, the query processing efficiency of
trajectory processing systems (Zhang et al., 2017; Ding et al., 2018) will be
impacted negatively. To address this issue, THBase (Qin et al., 2019) has
proposed a segment-based data model and a MO-based partition model for
efficient trajectory storage management in HBase. THBase consists of three
modules, T-table, L-index, and a query processing module. T-table is a
container of trajectory data in which adopted the MO-based partitioning model.
Whereas, L-index is a local spatio-temporal index structure that consists of
two levels (level1: time index, level2: Quad-tree based multi-level grid).
Finally, the query processing module supports single-object, spatio-temporal
range, and kNN query.

###  6.4. Python Libraries as Big Spatio-temporal Infrastructures

Python is one of the most popular data analytics platforms today. The PyData
stack is rich in terms of supported libraries, but most of these libraries are
developed to execute on a single CPU core and to process data that fits in
main memory. Therefore, Python does not scale well for processing big data.
One can utilize PySpark (Development Team, 2016) to process data using Spark
(Foundation, 2018) on a cluster of nodes. At present, Spark is the most
popular distributed in-memory general-purpose data processing engine that
supports a set of essential libraries (such as Spark SQL, Streaming, MLlib,
and GraphX). Spark has a rich support community, and users can write code in
many languages (such as Java, Scala, Python, and R). However, PySpark is added
as an extra layer on top of Spark, and therefore, when Python code is executed
using PySpark, the code is first compiled into Java code and then run on JVM.
Thus, PySpark adds an extra overhead in computation. On the contrary, DASK
(Dask Development Team, 2016) is a Python library for parallel and distributed
computing that scales Python natively. DASK not only scales Python across
distributed nodes of a cluster, but it also parallelizes a task in a single
node by utilizing multiple CPU cores. Therefore, those who process data using
Python on a personal computer regularly can easily speedup computation using
DASK.

DASK is a task-graph based platform that consists of two parts. At high-level,
DASK parallelizes the Python ecosystem by extending existing libraries, such
as Pandas (DASK DataFrame), Numpy (DASK Array), Scikit-Learn (DASK-ML), and
other libraries. Whereas, at low-level, DASK provides dynamic task schedulers
like Airflow or Luigi to enable advanced workloads. Here, DASK libraries
(Array, DataFrame) produce task graphs and then DASK schedulers execute task
graphs parallelly either in a single node or in distributed nodes of a
cluster. Python also supports a rich set of libraries (e.g., GeoPandas) for
processing spatial, spatio-temporal, and trajectory data. A detailed review of
these libraries is presented in Section 7.2. However, these libraries are also
slow and not scalable to process big spatial data like other Python libraries.
DASK does not have a native parallel module for processing big spatial data.
One can utilize DASK DataFrame or low-level capabilities of DASK with existing
spatial libraries to process big spatial data. Previously, developers have
tried to improve the performance of GeoPandas through Cython (Behnel et al.,
2011), which allows GeoPandas to access the GEOS library directly. However,
Cythonizing only utilized one core of a single node effectively (DASK Blog,
2017). Hence, the main challenge is to use multiple CPU cores or distributed
nodes of a cluster. Recently, DASK-GeoPandas (Signell, 2020) was developed to
parallelize GeoPandas with DASK, which organizes many GeoPandas dataframes
like DASK-DataFrame. However, this is an experimental project and currently
partitions dataframes by rows. Thus, spatial operations will not return the
correct results in a distributed environment without using spatial
partitioning. XArray (Hoyer and Hamman, 2017) is a Python package for labeled
multi-dimensional arrays which is efficient for processing scientific datasets
(e.g., netCDF, GeoTiff). Since XArray is tightly integrated with DASK for
parallel computation, we can utilize XArray for processing big raster spatial
data. A few other projects, such as dask-geomodeling (dask-geomodeling, 2019)
and dask-rasterio (Labs, 2018), also provide support for spatial raster data.
Moreover, dask-geomodeling has a module for spatial vector data.

As mentioned before, Hadoop is an efficient framework for big data processing
but hindered by the I/O bottleneck. In this context, as Spark keeps data
always in-memory and does not require to write intermediate results back to
disk, it became an efficient and popular data processing framework. Currently,
CPU-based in-memory systems like Spark suffer due to the bottleneck of
processing complex workloads (e.g., deep learning on massive datasets), and
this bottleneck is due to the CPU itself. Compared to CPUs with a few cores
and lots of cache memory, GPUs are composed of hundreds of cores, high
bandwidth memory (up to TB/s), and high-speed hardware interconnections (e.g.,
bidirectional GPU to GPU bandwidth up to 300 GB/s). Also, GPUs can scale up to
16x in a single node (Kraus, 2019). RAPIDS (Team, 2018c) is a collection of
libraries and APIs that bring the power of GPUs for processing big data in
Python. RAPIDS supports a wide range of libraries for Python developers, such
as analytics (cuDF, cuIO), machine learning (cuML), graph analytics (cuGraph),
deep learning (PyTorch, TensorFlow, MxNet), spatial analytics (cuSpatial),
visualization (cuxFilter, pyViz, plotly), and other libraries. These libraries
are literally replicated versions of the existing python libraries. Therefore,
Python developers can utilize the processing capability of GPUs without
knowing low-level CUDA implementations. Using RAPIDS, we can achieve vertical
scalability easily. Since RAPIDS integrates DASK, horizontal scalability can
be achieved through RAPIDS and DASK using OpenUCX on a single node as well as
in distributed nodes of a cluster.

cuSpatial is a spatial module of RAPIDS, which is still in early-stages of
development, but growing rapidly. Dependent on the type of operations, it is
possible to achieve significant (up to 1000x) performance improvement in
RAPIDS when compared to CPU spatial libraries like GDAL. cuSpatial integrates
with RAPIDS dataframe cuDF to use GPUs massive parallelism and high memory
bandwidth for performing spatial operations. Developers can also use cuSpatial
and cuGraph together for spatial and spatio-temporal analytics. cuSpatial is
implementing spatial features in four layers that include geometry types,
spatial operations, indexing, and querying. The current version of cuSpatial
(v0.16) can model some basic geometry types such as points, polylines,
polygons, and shape primitives. It supports Quad-Tree indexing for performing
various spatial operations, such as point-in-polygon, Haversine distance
(distance between points), and Hausdorff distance (distance between
trajectories). Currently, it supports spatial window and nearest polyline
queries. Since cuSpatial is working seamlessly with cuDF, users can use
various data formats, such as CSV, Parquet, Shapefiles, JSON, and more.

In terms of support, Spark lacks data visualization and deep learning
libraries. Whereas, both DASK and RAPIDS have support for data visualization
and deep learning libraries (PyTorch, TensorFlow, Keras). At present, there is
no SQL query support in DASK. However, one can run SQL queries on both Spark
(Spark SQL) and RAPIDS (blazingSQL). Though all of them have support for
machine learning libraries, DASK (Dask-ML) and RAPIDS (cuML) libraries are
more popular compared to Spark (MLib).

###  6.5. Other Big Spatio-temporal Infrastructures

A number of distributed systems were developed by extending existing
infrastructures other than Hadoop, Spark, and NoSQL-databases for processing
spatial data. Sphinx (Eldawy et al., 2015, 2017) is a highly-scalable
distributed spatial data processing system that extends the core of Apache
Impala (Foundation, [n.d.]; Kornacker et al., 2015), which is a SQL engine
over Hadoop. Sphinx has adopted the ANSI-standard SQL interface and built
spatial support in four layers of Impala. It introduced spatial data types,
OGC-compliant spatial predicates and functions, and commands to create spatial
indexes in the query parser layer. Two-level index is added in the storage
layer, where the global index (R-tree/R+-tree) partitions the data into
blocks, and local indexes (R-tree) arrange records in each block of HDFS.
Finally, Sphinx modifies the query planner and the executor layer to add
support for spatial joins and range queries. Since SQL-like queries of most
big spatial data processing systems are not ANSI-standard and not efficient as
spatial RDBMS, Sphinx achieves good performance over systems like
SpatialHadoop. However, one can run a query on existing data only, as data
updates are not allowed in HDFS. AsterixDB (Alsubaiee et al., 2014a; Alsubaiee
et al., 2014b; Alamoudi et al., 2015) is a full-fledged big data management
system, which incorporates LSM-based data storage and a set of indexing
techniques including B+-tree and R-tree. It supports a complete query
language, AQL, that uses Hyracks (Borkar et al., 2011) as a query execution
engine. A rich set of built-in data types, including spatial and temporal
data, allows users to perform spatial, temporal, and spatio-temporal queries.
Currently, it also supports the SQL++ query language, which is very similar to
SQL, but for semi-structured data (e.g., JSON).

Like Spark, Apache Ignite (The Apache Software Foundation, 2015) is also a
scalable and fault-tolerant distributed in-memory big data processing
platform, but has limited spatial supports. Its geospatial module supports
geometry data types (point, line, and polygon), a limited form of querying on
geometry data (intersection operation), and spatial indexing R-tree from the
H2 database (Team, 2019a). The main limitation of Ignite is that it does not
support any spatial partitioning technique to distribute data across the
clusters. Therefore, the result returned from Ignite for any spatial query is
not accurate. Alam et al.(Alam et al., 2018) introduced $SpatialIgnite$ as
extended spatial support for Ignite. They have added a spatial library
containing all the OGC-compliant spatial predicates and analysis functions and
introduced two spatial data partitioning techniques (fixed grid and Niharika
(Ray et al., 2013)) into $SpatialIgnite$. According to the reported evaluation
results, $SpatialIgnite$ outperforms GeoSpark (Yu et al., 2015) for executing
spatial join and range queries.

Table 6. Other Big Spatio-temporal Infrastructures

| System Type |  | Underlying
---
System/Architecture
| Geometry
---
Types
Partitioning | Indexing |  | Query
---
Language
| Supported
---
Queries
|  RasDaMan (Baumann et al., 1997)
---
(1997)
Spatial Raster | Array DB | N/A | N/A | N/A | RasQL | Range
|  SciDB (Cudre-Mauroux et al., 2009; Brown, 2010)
---
(2009)
Spatial Raster | Array DB | N/A | N/A | KD-Tree | AFL, AQL | Range, kNN
|  DISTIL (Patrou et al., 2018; Memarzia et al., 2019)
---
(2018)
Spatio-temporal | APGAS1 |  | Point (id,
---
oid, lat, lon,
timestamp,
direction,
speed)
| RRR2,
---
MDR3
| Multi-Level
---
L1: Quad-Tree
L2: Spatial
L3: Temporal
N/A | Range, kNN
|  AsterixDB (Alsubaiee et al., 2014a)
---
(2014)
| Spatial,
---
Spatio-temporal
Hyracks (Borkar et al., 2011) |  | Point, Line,
---
Polygon, Circle,
Rectangle, Date,
Time, Interval,
Duration, etc.
Hash |  | B+-Tree,
---
R-tree
AQL, SQL++ | Range, Join
|  Sphinx (Eldawy et al., 2015)
---
(2015)
Spatial | Apache Impala |  | Point,
---
LineString,
Polygon,
Collections
STR |  | Two-Level
---
Global: R/R+-Tree
Local: R-Tree
| SQL
---
(ANSI-Standard)
Range, Join
|  SpatialIgnite (Alam et al., 2018)
---
(2018)
Spatial | Apache Ignite |  | Point,
---
LineString,
Polygon
| Grid,
---
Niharika (Ray et al., 2013)
R-Tree |  | Distributed SQL
---
(ANSI-Standard)
Range, Join
|  Tornado (Mahmood et al., 2015)
---
(2015)
| Spatio-textual
---
Stream
Apache Storm |  | {srcid, oid,
---
(x, y), t, text}
A-Grid |  | Adaptive Indexing
---
Global: Spatial (A-Grid)
Local: Spatio-textual
(KD-Tree)
| Atlas
---
(SQL-Like)
| Snapshot,
---
Continuous
(Range, kNN,
Join)
|  SSTD (Chen et al., 2020)
---
(2020)
| Spatio-textual
---
Stream
Apache Storm | Point |  | QT-tree
---
(Spatial,
Textual)
| Global: QT-tree
---
Local: Object, Query
N/A |  | Snapshot,
---
Continuous
(Range, kNN,
Top-k)
|  GeoFlink (Shaikh et al., 2020)
---
(2020)
Spatial Stream | Apache Flink | Point | Grid | Grid-based | N/A |  | Continuous
---
(Range, kNN,
Join)

1 APGAS - Asynchronous Partitioned Global Address Space
2 RRR - Row-wise Round-Robin Partitioning
3 MDR - Multi-dimensional Range Partitioning

There are a few spatial database systems that have been developed from
scratch, such as SciDB (Cudre-Mauroux et al., 2009; Brown, 2010; Stonebraker
et al., 2011; Becla et al., 2013), RasDaMan (Baumann et al., 1997; Baumann et
al., 1998, 1999), and DISTIL (Patrou et al., 2018; Memarzia et al., 2019).
Both RasDaMan and SciDB are specialized database systems developed from
scratch for scientific computing. These systems are implemented using a multi-
dimensional array data model and efficient for processing spatial raster data.
Besides, these systems support SQL-like queries. DISTIL is a scalable spatio-
temporal in-memory system that is implemented based on APGAS (Asynchronous
Partitioned Global Address Space) programming model. Its efficient data
partitioning and distributed multi-level spatio-temporal indexing expedites
the performance of range and kNN queries. DISTIL achieves a high rate of
updates by incorporating LSM-Tree (O’Neil et al., 1996) based key-value store
LevelDB (Sundstrom, 2020) (developed by Google) as a local data store in each
node of a cluster. Besides, the data in the local store is periodically
synchronized with the distributed persistent global store, HDFS. At present,
DISTIL does not have any support for SQL-like queries. However, data
processing systems built from scratch for a specific purpose, such as spatial
data processing, can achieve good performance. Whereas, it is always
challenging to develop a full-fledged system from scratch, and also, it is
hard to use them as a general-purpose system (Eldawy and Mokbel, 2016).
Besides, the code base of these systems is frequently immature and difficult
to extend.

The big spatial data processing systems, which are developed based on Hadoop,
Spark, or other platforms, can only store and process historical static
spatial data. However, a wide range of location-based services require real-
time processing of spatial data streams. Also, the indexing of these systems
does not support high update rates to adjust with newly arriving streams.
Besides, these services demand dynamic workload distribution. GeoFlink (Shaikh
et al., 2020) extends Apache Flink to add support for processing spatial data
streams. It has introduced grid-based dynamic indexing to perform continuous
queries (range, kNN, and join). Both Tornado (Mahmood et al., 2015; Mahmood,
2018) and SSTD (Chen et al., 2020) have extended Apache Storm for processing
spatio-textual (e.g., geo-tagged tweets) data streams. Tornado has added a
two-level (global spatial and local spatio-textual) adaptive indexing layer
for dynamically distributing data and query workloads. However, global
indexing (A-Grid) and the cost model for load balancing of Tornado works well
with continuous queries, not snapshot queries. Hence, SSTD has introduced QT-
tree (a Quad-tree variant) global indexing and a set of local indexing for
both continuous and snapshot queries (range, kNN, and top-k). Among them, only
Tornado supports SQL-like (Atlas) queries with a map-based interface.

Currently, most major commercial data management systems have some form of
spatial support. For example, Google BigQuery (Cloud, 2020) has a GIS module
(BigQuery GIS) to perform ANSI-standard SQL queries on large spatial datasets.
Users can also visualize BigQuery results using BigQuery Geo Viz and Google
Earth Engine. Google Earth Engine (Gorelick et al., 2017) is itself a cloud-
based platform for the analysis of large scale geospatial data. Similarly, one
can run standard SQL queries on Amazon Athena (Amazon, 2020) or Microsoft
Azure for processing spatial data.

###  6.6. Future Research Directions

Though quite a large number of big data infrastructures have been developed
for processing spatial, spatio-temporal, and trajectory data in the last
couple of years, most of these systems are not in active development. Also,
some of these systems have support for SQL-like queries but not as efficiently
as SQL queries in spatial RDBMSs. Besides, their visualization capability is
limited except for Python based libraries. Moreover, a few of these systems
have support for processing spatial raster data, such as RasDaMan (Baumann et
al., 1997), SciDB (Becla et al., 2013), GeoTrellis (Eclipse Foundation et al.,
2016), and Google Earth Engine (Gorelick et al., 2017). Among them, both
RasDaMan and SciDB were built from scratch for specific purposes.

Therefore, considering the volume of spatial raster data generated from
various sources (e.g., earth sensors, satellites) and the importance of this
data in many application domains, more research is required for processing
spatial raster. Also, we need to improve the efficiency of SQL-like queries
and the visualization capabilities of existing or new infrastructures. Also,
there will be demand in the coming years to include more support for
visualizing big spatial data on web platforms. Recently a few big data stream
processing platforms (e.g., Apache Flink, Apache Storm) have extended to
integrate support for processing spatial or spatio-textual data streams. But
more research is required in this area in the coming future. For example,
instead of spatial point streams, future research will explore line and
polygon streams or will include support for spatio-temporal aspects of data
streams. Currently, there is a demand to incorporate SQL-like query engine and
dedicated spatial library in DASK. Since the spatial library (cuSpatial) of
RAPIDS is in the early stage, there will be more research in the coming future
to add more features for processing spatial and spatio-temporal data in GPU.
In addition, future big data infrastructures will be more cloud-native and
will include machine learning and deep learning models to process spatial
data.

##  7\. Programming and Software Tools for Spatio-temporal Analysis

The infrastructure we use to store spatio-temporal datasets is one of the key
aspects of any project involving this type of data. Still, what we do with
this data is also of major importance as it allows extracting value out of
these data. In this context, it is of utmost importance to review the main
programming and software tools that are available to researchers and
practitioners for analyzing spatio-temporal data sets.

Analyzing these data may sometimes simply involve using the available
geospatial tools and write some code for storing, querying, analyzing, and
visualizing spatial data. Other usage cases involve developing libraries or
packages for specific purposes like spatial I/O, visualization, spatial
regression, etc. In each of these cases, one essential question comes into our
mind: which programming language (or languages) to use to meet our purposes.
This decision is frequently driven by our goals. For example, if we want to
develop a system that requires heavy-weight development, we will look for a
language that is fast and efficient like C/C++ or Java. However, if a
developer wants to extend an existing system, the developer will most probably
use the language on which the system was built. On the contrary, if our goals
involve performing data processing, analysis, and visualization, we need a
language that provides a rich set libraries and packages good at these tasks,
like Python or R. Moreover, many spatial systems (e.g., ArcGIS) leverage more
than one language since some spatial features may be better supported by some
languages than others.

The most popular libraries for modeling spatial data in use today in GIS
applications and spatial data processing systems are developed either by Java
or C/C++, such as JTS (Java) (LocationTech, 2020), GEOS (C++) (OSGeo, 2020a),
Google S2 (C++) (Google, 2019), ESRI Geometry API (Java) (ESRI, 2014), and
Spatial4j (Java) (LocationTech, 2016). Most of the big spatial data processing
systems have also utilized these libraries to model spatial data, such as
SpatialHadoop (JTS, ESRI Geometry API), GeoSpark (JTS), and GeoMesa (JTS,
Spatial4j), etc. Spatial RDBMSs like PostGIS or SpatialLite have used GEOS for
modeling spatial data. Even libraries and packages of Python or R have also
utilized the GEOS library for modeling spatial data. Recently, researchers
have also proposed benchmarks (Zhang and Eldawy, 2020; Pandey et al., 2020)
for computational geometry libraries used in data processing systems for
spatial data exploration.

At present, almost all popular programming languages have some support in
terms of libraries or tools (Lacerda, 2020), which makes it easier to develop
geospatial applications. However, C/C++ and Java are still top in the game for
heavy-weight spatial system development. On the other hand, Python or R
provide ease of programming and a rich set of libraries and packages for
analysis, visualization, and modeling spatial and spatio-temporal data for a
wide range of application domains. Also, it is comparatively easy to implement
a new library or package for a specific purpose in R and Python, by extending
existing support. But if we need to work for the web, then we may need to get
support from JavaScript, Python, R, and other web-related languages. It is
similar for mobile development; we may need to choose language related to
mobile operating systems, such as iOS and Android.

In this section we perform a comprehensive review of widely used libraries and
packages of Python and R for analyzing, modeling, and visualizing spatial,
spatio-temporal, and trajectory data. We focus on these two programming
languages and environments because they are currently seen as the de facto
standards for data analysis. This section will also discuss two popular
software tools (ArcGIS and QGIS) for spatial data processing.

###  7.1. The R Ecosystem for Spatio-temporal Data Analysis

R is one of the most used languages in data science. From its inception, R is
more focused on data analysis and statistical tasks, and therefore, it is more
popular with academicians, statisticians, engineers, and scientists, who do
not even have prior computer programming knowledge. The capability of R is
rapidly growing for statistical analysis, modeling, and visualization of data
for a wide range of application domains. In terms of the extension of
libraries and packages for data analysis, R is richer than its counterparts.

A rich set of packages and libraries are also available in R for analysis and
visualization of spatial, temporal, and spatio-temporal data. In addition to
analysis and visualization, R also provides interfaces to spatial database
systems, GIS software, and big data processing platforms. The R ecosystem for
spatio-temporal data analysis is summarized in Table 7.

Table 7. R Ecosystem for Spatio-temporal Data Analysis Category | Libraries/Packages/Tools/API’s
---|---
Data Processing |  | \- sp, sf: spatial vector data
---
\- raster, terra: spatial raster data
\- spacetime, trajectories, stars: spatio-temporal data
\- xts, zoo, its, ts: time series
\- tidygraph: spatial network
\- GDAL (rdal), GEOS (rgeos), PROJ.4(proj4): OSGeo libraries
Data Manipulation | \- dplyr, tidyr, rmapshaper
Data Modeling | \- gstat, CAST, mlr/mlr3, performanceEstimation
Visualization |  | \- ggmap: spatial visualization with ggplot2
---
\- tmap: thematic maps in R (static, animated and interactive)
\- leaflet: JavaScript library for interactive web maps
\- mapview: interactive viewing of spatial data
\- plotly: interactive web-based graphs via plotly.js
\- rasterVis: static visualization of raster data
| APIs for GIS Software
---
and Spatial RDBMSs
| \- RQGIS for QGIS
---
\- RSAGA for SAGA
\- rgrass7 for GRASS
\- RPyGeo for ArcGIS
\- rpostgis for ’PostGIS’-enabled ’PostgreSQL’
| APIs for
---
Big Data Platforms
| \- Hadoop: Hadoop Streaming, RHadoop, RHIPE, ORCH
---
\- Spark: SparkR, sparklyr
\- GeoSpark: geospark

Data Processing Infrastructures: The packages related to spatio-temporal data
processing can be categorized into three main groups, namely spatial,
temporal, and spatio-temporal. The sp (Pebesma and Bivand, 2005) package was
the first package related with this type of data developed for R, which
consists of methods and classes to represent spatial data types and
operations. Since its release in 2005, it became quite popular and nearly 350
other packages are dependent on it. However, spatial features developed in sp
are not compliant with OGC simple features (OGC, 2010). Moreover, as many
features and functionalities of sp are directly dependent on OSGeo libraries
(OSGeo, 2020b) (such as GDAL, GEOS, and PROJ.4), if these libraries make any
changes, it is difficult for sp to manage and maintain interfaces to these
libraries due to a lack of simple features. The package sf (simple features)
(Pebesma, 2018) provides classes and methods for spatial vector data, which
supersede the sp package. Its features are OGC-compliant and provide direct
interfaces to the GDAL, GEOS, and PROJ.4 libraries. Therefore, if we use sf,
we do not need to load these external libraries into R code. In addition, sf
has many advantages over sp, that include faster I/O operations, improved
visualization, compatible with the tidyverse collection of packages (e.g.
dplyr), sf objects can be treated as data frames for spatial operations, and
finally, the spatial functions in sf have a more consistent naming that makes
it easier to use in the code (Lovelace et al., 2019). Not surprisingly, sf is
quickly being adopted as the backbone for data processing by many other
packages related to spatial data analysis.

The raster (Hijmans and van Etten, 2012) package is popular for processing
spatial raster data. It supports classes and a large set of functions to
create, read, write, manipulate, and process raster data. This package can
also process large raster datasets that are too large to fit in the main
memory. The terra (Hijmans, 2020) package is a new package for processing
raster data in R, containing similar functionality as the raster package.
However, due to its simplicity and faster operation, terra will replace the
raster package soon. Besides, this package contains useful methods for data
prediction (e.g., interpolation). The packages stars (Pebesma, 2020) or
spacetime (Pebesma, 2012) are used for processing spatio-temporal data, but
spacetime also has support for trajectory data. The package trajectories
(Pebesma et al., 2020) was specifically developed for the analysis trajectory
data. These packages are dependent on packages for the analysis of time series
(such as xts (Ryan and Ulrich, 2020), zoo (Zeileis and Grothendieck, 2005))
and spatial data (such as sp, sf).

Data Manipulation: The package dplyr (Wickham et al., 2020) provides a grammar
for data manipulation. It contains a set of functions (verbs) to manipulate
data in data frames, such as adding new columns, selecting specific columns,
filtering rows, re-arranging rows, summarizing data, and other functions. As
the sf package is compatible with dplyr, the functions of dplyr can manipulate
spatial objects in sf. In addition to manipulating in-memory data frames,
dplyr can also manipulate data stored in relational databases (using
dbplyr(Wickham and Ruiz, 2020)) or large datasets stored in Spark (using
sparklyr (Luraschi et al., 2020)).

Data Modeling: The gstat (Gräler et al., 2016) package is used for statistical
modeling, prediction, and simulation of spatial and spatio-temporal data,
which is also dependent on sp package. The CAST (Meyer, 2020) package provides
functions to improve spatio-temporal modeling tasks using caret package (Kuhn,
2008). The mlr (Bischl et al., 2016) package contains a wide range of machine
learning algorithms for modeling data. However, due to its complex design, it
is difficult for the developers to maintain and add new features in mlr.
Besides, as some dependent packages of mlr have changed their features in the
meantime, the developers of mlr could not manage to update the mlr
accordingly. The mlr3 (Lang et al., 2019) is a successor of mlr, and it is a
generic, object-oriented, and extensible framework that solves the above
problems. The package performanceEstimation (Torgo, 2014) also allows for
predictive model development and tuning and moreover, contains specific
routines for handling predictive tasks with time dependant data, like for
instance sliding and growing window model building schemas.

Data Visualization: Data visualization is an important part of data analysis.
In case of spatial data analysis, mapping is one of the best way to present
the findings of the research. Though most of the spatial mapping packages were
dependent on sp package before, a few of them (such as tmap (Tennekes, 2018),
leaflet (Cheng et al., 2019), mapview (Appelhans et al., 2020)) are already
supporting the classes of the sf package (Lovelace et al., 2019). Spatial maps
can be static or interactive and animated. The widely used static mapping
tools are tmap and ggmap (Kahle and Wickham, 2013), but tmap is also used for
interactive mapping. There is a wide range of packages for interactive and
animated maps, such as leaflet, mapview and plotly (Sievert, 2020). Besides,
rasterVis (Perpiñán and Hijmans, 2020) is a common package for static raster
data visualization.

APIs for GIS Software and Spatial RDBMSs: R is very rich in terms of libraries
and packages for analysis spatio-temporal data, but it is neither a spatial
database system nor a powerful standalone GIS software tool. Besides, R
packages are not capable of processing large spatio-temporal data. Therefore,
the integration of R with GIS software and Spatial RDBMSs extends the
capabilities of R for processing spatio-temporal data. As a result, R users
can use hundreds of algorithms from GIS software and can process data stored
in database systems using a rich set of R packages. RQGIS (Muenchow et al.,
2017) establishes an interface between R and QGIS (QGIS Development Team,
2020) by utilizing Python API for QGIS. It provides access to QGIS algorithms
from within R. As QGIS has already integrated other popular GIS software (such
as GDAL, SAGA, GRASS, and more), integrating R with QGIS brings the power of
all these software into R using only one package, RQGIS. However, one can use
dedicated APIs to access complete support of each of these GIS software that
include rgdal (Bivand et al., 2020) for GDAL, RSAGA (Brenning et al., 2018a)
for SAGA, and rgrass7 (Bivand, 2019) for GRASS. R users can also access
functionalities of another popular commercial GIS software ArcGIS through the
RPyGeo (Brenning et al., 2018b) package. Spatial RDBMSs (e.g.,
PostgreSQL/PostGIS, Oracle Spatial) can store, manage, and query both vector
and raster data efficiently. However, their data analysis and visualization
capabilities are very limited. Therefore, the integration of R with spatial
RDBMSs is useful for both R and spatial RDBMSs users. The rpostgis (Bucklin
and Basille, 2018) package provides R with an interface to access a popular
open-source database system, PostgreSQL/PostGIS. It also supports methods to
perform read and write operations with PostgreSQL/PostGIS for handling both
vector and raster spatial datasets.

APIs for Big Data Platforms: Traditional GIS software and spatial RDBMSs are
not capable of handling today’s huge volume of multi-dimensional and
heterogeneous spatio-temporal data. Therefore, R interfaces to these systems
do not provide scalability and efficiency for processing big spatio-temporal
data. There are a number of R APIs that provide access to scalable and fault-
tolerant distributed big data computing platforms, such as Hadoop and Spark.
We can use Hadoop Streaming (Foundation, 2020e), RHadoop (RHadoop, 2011),
RHIPE (R and Hadoop Integrated Programming Environment) (DeltaRho, 2015), and
ORCH (Oracle R Connector for Hadoop) (Oracle, [n.d.]) API to run MapReduce
jobs using Hadoop or directly accessing Hadoop Distributed file System (HDFS)
within the R programming environment. However, the Hadoop Streaming API can
only run R MapReduce scripts that are written using the HadoopStreaming
(Rosenberg, 2012) package. The sparklyr (Luraschi et al., 2020) and SparkR
(Venkataraman et al., 2016) packages are used as an interface between R and
Spark. The package sparklyr is compatible with dplyr and allows R users to
access the built-in machine learning algorithms of Spark. SparkR is a native
Spark frontend for R users that provide access to all Spark libraries.
Besides, these packages also allow R users to access HDFS. However, both
Hadoop and Spark do not have native support for processing spatial data. On
the other hand, most R packages for spatial analysis are developed for a
single node. Therefore, we can implement a custom R package for Hadoop and
Spark-based spatial data processing systems (discussed in Section 6.1 and 6.2)
to achieve scalability for spatial processing. For example, geospark (Zhu,
2020) package allows R users to use GeoSpark (Yu et al., 2015) for big spatial
analysis.

###  7.2. Python Ecosystem for Spatio-temporal Data Analysis

Python is a full-fledged general purpose programming language. However, Python
has become one of the most popular programming languages for data science in
the last decade. It is widely used for processing, analyzing, and visualizing
data in both academia and industry. Researchers and organizations are
continuously working to develop new tools, libraries, and packages to process
and analyze real-world data. Therefore, the community of Python is growing as
well as the capabilities of the language. Other than data science, Python is
also popular with programmers and developers for developing general-purpose
software applications. Due to the rise of spatial data, Python has been
adopted for modeling, analyzing, and visualizing spatial, temporal, and
spatio-temporal data in the last decade. The integration of Python as the main
scripting language by popular GIS platforms like ArcGIS and QGIS has expedited
this process. Python also supports interfaces to big data computing platforms,
Hadoop and Spark. The Python ecosystem for spatio-temporal data analysis is
summarized in Table 8.

Table 8. Python Ecosystem for Spatio-temporal Data Analysis Category | Libraries/Packages/Tools/API’s
---|---
Core Libraries |  | \- SciPy: core library for scientific computation
---
\- NumPy: fundamental library for numerical computation
\- Pandas: data structure and analysis library
Data I/O |  | \- GDAL: raster and vector I/O (interface to GDAL/OGR)
---
\- Fiona: vector I/O (interface to OGR)
\- Rasterio: raster I/O (interface to GDAL)
Data Processing |  | \- GeoPandas: spatial extension of pandas
---
\- Shapely: spatial analysis of geometric objects
\- scipy.spatial: spatial algorithms and data structures
\- pyspatial: analysis vector/raster data
\- sptemp: spatio-temporal vector data analysis
\- Rtree: spatial indexing
\- rasterstats: summarizing spatial raster datasets
\- MovingPandas, traja: trajectory data analysis
\- pyproj: coordinate transformations (interface to PROJ4)
| Statistical Analysis
---
and Modeling
| \- PySAL: spatial and spatio-temporal data analysis library
---
\- scikit-learn: machine-learning algorithms
\- scikit-image: algorithms for image (satellite) processing
\- statsmodels: statistical modeling for python
Visualization |  | \- Matplotlib: static and interactive visualization
---
\- Seaborn: statistical data visualization
\- Bokeh: interactive visualizations for the web
\- Plotly: interactive visualizations for the web
\- Folium: visualizations via interactive leaflet map (leaflet.j)
\- Cartopy: visualize data on maps
\- ggplot: visualizations based on R ggplot2
| APIs for
---
GIS Software
| \- ArcPy, ArcGIS API: python interface to ArcGIS
---
\- PyQGIS: python interface to QGIS
| APIs for
---
Big Data Platforms
| \- Hadoop: Hadoop Streaming, mrjob, Pydoop, Luigi, PyArrow
---
\- Spark: PySpark

The SciPy stack (Team, 2020d) consists of a set of libraries for scientific
computing in Python. Specifically, the SciPy (Team, 2020d), Numpy (Team,
2020c), and Pandas (pandas development team, 2020; Wes McKinney, 2010)
libraries have been used as core packages in data science. These packages are
also essential for the analysis of spatio-temporal data as most of the
libraries of the Python spatial stack depend on them.

Data I/O: The spatial input/output libraries of Python are developed using the
existing C library, GDAL (Geospatial Data Abstraction Library) (GDAL/OGR
contributors, 2020), which supports a wide range of raster and vector data
formats. Therefore, Python spatial I/O libraries also support these data
formats. Fiona (Gillies, 2011) interfaces to the OGR (OpenGIS Reference
Implementation) layer of GDAL for reading and writing spatial vector data of
various formats, such as Shapefile, GeoJSON, JSON, CSV, etc. The library
rasterio (Team, 2018b) interfaces to GDAL for raster functionality. It relies
on Numpy for efficient processing of raster formats, such as GeoTIFF, netCDF,
JPEG2000, and other formats.

Data Processing: A set of libraries is available in Python for processing
spatial and spatio-temporal data. The library Shapely (Shapely, 2013) provides
functions for manipulation and analysis of vector geometric objects, and is
based on the widely used GEOS (OSGeo, 2020a) library. GeoPandas (GeoPandas,
2019) is a spatial extension of Pandas. It uses the Shapely, Fiona, and pyproj
(Python interface to PROJ.4) (Whitaker, 2018) libraries to add spatial support
in the popular data analysis and manipulation tool, Pandas. SciPy.Spatial also
provides algorithms and data structures for spatial analysis. Whereas,
rasterstats (Perry, 2015) contains functions for zonal statistics and
interpolated point queries for summarizing spatial raster datasets using
vector geometries. It can work with any data formats supported by rasterio.
Moreover, one can use pyspatial (Thakral, 2016) for both raster and vector
data, sptemp (Baumann, 2019) for spatio-temporal vector data, and MovingPandas
(Graser, 2019) and traja (Shenk and Busche, 2019) for trajectory data
analysis.

Statistical Analysis and Modeling: PySAL (Rey and Anselin, 2007) is an open-
source spatial analysis library with a primary focus on vector data. The
functionality of PySAL covers a wide range of areas, such as methods to detect
spatial clusters, hot spots and outliers, spatial regression, statistical
modeling, spatial econometrics, space-time analysis, visualization, and more.
The current version of PySAL (v2.X) consists of four domains, which include
PySAL core (pysal.lib), exploratory spatial data analysis (pysal.explore),
spatial statistical models (pysal.model), and geovisualization (pysal.viz).
pysal.lib is the core library which contains data structures and algorithms
for spatial I/O, spatial weights, computational geometry, and more. The
pysal.explore library consists of modules for exploratory analysis of spatial
and spatio-temporal data. The pysal.model is designed to model spatial
relationships in data using different types of linear, generalized-linear,
generalized-additive, nonlinear, multi-level, and local regression models.
Finally, the pysal.viz layer supports functionality to visualize spatially
analyzed data (e.g., detected clusters or hot-spots). Besides, PySAL provides
a toolkit for ArcGIS and a plugin for QGIS which allows using the
functionalities of PySAL within these GIS software. Some desktop applications
like CAST (Crime Analytics in Space-Time) and GeoDaSpace has also use a subset
of PySAL. Moreover, PySAL is now available as a featured package in the
distribution of Anaconda Python and Enthought Canopy (Rey et al., 2015).
statemodels (Seabold and Perktold, 2010) is another useful library for users
who are looking for a Python library for statistics, financial econometrics,
or econometrics. It also supports models for time-series analysis.

scikit-learn (Pedregosa et al., 2011) is a library of a vast collection of
supervised and unsupervised machine learning algorithms for clustering,
classifications, regression, dimensionality reductions, and many more. It also
supports functions for data loading, manipulation, and prepossessing. Whereas
scikit-image (van der Walt et al., 2014) includes a wide range of algorithms
for image analysis, such as segmentation, transformations, restoration,
metrics, feature selection, color space manipulation, filtering, morphology,
and other algorithms. Since both of these libraries are implemented based on
the libraries of the SciPy ecosystem, SciPy libraries must be installed before
using scikit-learn and scikit-image.

Data Visualization: Like R, Python also supports a rich set of libraries for
spatial data visualization and mapping. Matplotlib (Hunter, 2007) is a key
visualization library in Python (part of a SciPy ecosystem), which can be used
for creating static, interactive, and animated visualizations. The package
Cartopy (Met Office, 2015) uses PROJ.4, Shapely, and Numpy to provide a
spatial mapping library on top of Matplotlib. It includes an easy way to
create maps via Matplotlib. Seaborn (Seaborn, 2017) is another library built
on top of Matplotlib for statistical data visualization. A number of Python
packages are also built to create interactive maps for the web, such as Folium
(Story, 2013), Bokeh (Bokeh Development Team, 2020), and Plotly (Sievert,
2020). Folium is a wrapper for the leaflet.js library for plotting interactive
web maps. It includes a raster and a vector layer for visualizing through an
interactive leaflet map. Similarly, Bokeh and Plotly are also developed as
interactive visualization libraries for web browsers.