Standards-Based Geospatial Services Integration for Smart Cities

Platforms

Bruno Rienzi, Raquel Sosa, Gast

on Abell

a, Ana Machado, Daniel Susviela and Laura Gonz

alez

Instituto de Computaci

on, Facultad de Ingenier

ıa, Universidad de la Rep

ublica, Montevideo, Uruguay

ﬁ

Keywords:

Geospatial Services, Smart Cities Platforms, Standards.

Abstract:

Smart cities usually refer to the use of information and communication technologies to provide citizens with

improved city services and quality of life, in an affordable and sustainable way. Geospatial technologies,

especially those based on standards, are relevant to this purpose, as location is crucial for organising, pro-

cessing, and analysing urban information and services. During the last years, many smart cities platforms

have emerged to provide support for the design, implementation, deployment, and management of smart cities

applications (e.g. FIWARE). Although these platforms frequently consider the spatial dimension, they do not

usually provide native support for typical geospatial services (e.g. data access, portrayal, and processing ser-

vices). Therefore, geospatial-related features provided by applications are usually developed from scratch and

on a per-case basis, which leads to code duplication and hinders their implementation agility, maintainability,

and reuse. This paper proposes a standards-based solution for geospatial services integration for smart cities

platforms, which comprises an overall architecture as well as a reference implementation based on FIWARE

and includes three smart cities applications.

1 INTRODUCTION

Smart cities usually refer to the use of Information

and Communication Technologies (ICT) to provide

citizens with improved city services and quality of

life, in an affordable and sustainable way (Santana

et al., 2017). Initiatives in the area have tackled differ-

ent types of city services (Santana et al., 2017), such

as transportation, trafﬁc control, air pollution, public

safety and waste management, among others.

Geospatial technologies are of paramount rele-

vance towards this purpose, as location is crucial for

organising, processing, and analysing urban informa-

tion and services (Ahad et al., 2020)(Daniel and Do-

ran, 2013)(Sharma et al., 2021). These technolo-

gies comprise integrative and analytical technologies

(e.g. geographic information systems: GIS), data ac-

quisition and processing technologies (e.g. remote

sensing), visualisation and representation technolo-

gies (e.g. data models, 3D visualisation), and data

management technologies (e.g. relational databases)

(de Vries, 2021). Furthermore, geospatial standards

are key to easing the access, integration, analysis,

and presentation of geospatial data across heteroge-

neous and distributed computing environments (Lee

and Percivall, 2008)(Saborido and Alba, 2020).

During the last years, different software platforms

have emerged in order to support the development

of smart cities (e.g. FIWARE, InterSCity) (Alberti

et al., 2019)(Saborido and Alba, 2020)(Santana et al.,

2017). Smart City Platforms (SCP) provide an inte-

grated infrastructure for the design, implementation,

deployment, and management of smart cities applica-

tions (Santana et al., 2017).

Although SCPs frequently consider the spatial di-

mension, they do not usually provide native sup-

port for typical geospatial services (e.g. data access,

portrayal, and processing services). Therefore, the

geospatial capabilities of applications are usually de-

veloped from scratch and on a per-case basis, which

leads to code duplication and hinders their implemen-

tation agility, maintainability, and reuse.

This paper proposes a standards-based solution for

geospatial services integration for SCPs, which com-

prises an overall architecture as well as a reference

implementation based on FIWARE and includes three

applications (i.e. bus detours, beach ranking, and sen-

sor management). The proposal is also aligned with

a reference architecture for SCPs proposed by key re-

searchers (Santana et al., 2017).

The rest of the paper is organised as follows. Sec-

tion 2 presents background. Section 3 describes a mo-

Rienzi, B., Sosa, R., Abellá, G., Machado, A., Susviela, D. and González, L.

Standards-Based Geospatial Services Integration for Smart Cities Platforms.

DOI: 10.5220/0011853500003473

In Proceedings of the 9th International Conference on Geographical Information Systems Theory, Applications and Management (GISTAM 2023), pages 167-175

ISBN: 978-989-758-649-1; ISSN: 2184-500X

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

167

tivational scenario, issues, and requirements. Section

4 presents the proposal and Section 5 analyses im-

plementation as well as assessment details. Section

6 analyses related work. Finally, Section 7 presents

conclusions and future work.

2 BACKGROUND

This section presents background on smart cities plat-

forms and geospatial standards.

2.1 Smart Cities Platforms

An SCP has been deﬁned as “an integrated middle-

ware environment that supports software developers

in designing, implementing, deploying, and managing

applications for Smart Cities” (Santana et al., 2017).

These platforms aim to ease the development of ap-

plications for smart cities by means of services and

abstractions (ITU, 2018)(da Silva et al., 2021). They

use data from Internet of Thing (IoT) devices and in-

formation systems deployed in the city, and provide

integration of services promoting the creation of ap-

plications to improve citizens’ well-being (da Silva

et al., 2021).

The uniﬁed reference architecture for smart cities

platforms proposed by Santana et al. (Santana et al.,

2017) identiﬁes key components for SCPs which are

described next.

The Cloud and Networking component is respon-

sible for managing and communicating city network

nodes. The IoT Middleware is responsible for manag-

ing the city IoT network and for the communication

with user devices, city sensors, and actuators. The

Service Middleware is responsible for managing the

services provided by the platform to applications (e.g.

monitoring services). The User Management compo-

nent stores user data and preferences, while the Social

Network Gateway enables the platform to integrate

with existing social networks.

The Big Data Management module is responsible

for managing all the data in the platform and it com-

prises different components such as: App Repository,

which stores applications (e.g. source code); Model

Repository, which stores city models (e.g. data mod-

els, city maps); Data Repository, which stores data

collected from sensors, citizens, and applications; and

other components (e.g. for analytics, stream process-

ing, data cleaning, visualization, machine learning).

The architecture also includes security mecha-

nisms and a development toolkit that enable, along

with the other components: Developers to implement

smart cities applications, Citizens to use these appli-

cations, and Managers to govern them.

2.2 Geospatial Standards

The Open Geospatial Consortium (OGC)

deﬁnes an

abstract speciﬁcation (Percivall, 2020), as the concep-

tual foundation for geospatial information exchange

and interoperability, and over sixty implementation

standards that provide the necessary structures and

interfaces. OGC also proposes a spatial information

framework for smart cities (Percivall, 2015), follow-

ing a service-oriented architecture and using a subset

of their standards. Some key standards from that sub-

set are depicted in Fig. 1, following the OGC Stan-

dards Architecture Diagram

The Data Access Services include the Web Fea-

ture Service (WFS) (Vretanos, 2010) and the API

Features (Portele et al., 2018), which enable a client

to query, modify and delete geospatial information.

The Portrayal Services include the Web Map Service

(WMS) (de la Beaujardiere, 2006) and the Web Map

Tile Service (WMTS) (Mas

o et al., 2010). WMS pro-

vides an interface for requesting geo-registered map

images in compressed formats (e.g. JPEG). WMTS

provides spatially referenced tile images with prede-

ﬁned content, extent, resolution, and coordinate ref-

erence system. The Processing Services include the

Web Processing Service (WPS) (Mueller and Pross,

2018) and the API Processes (Pross and Vretanos,

2021), which enable a client to request the execution

of geospatial processes (e.g. calculating an intersec-

tion) either synchronously or asynchronously. These

processes are not built-in; they have to be imple-

mented in high-level languages (e.g. Java, Python).

The Data Models and Encodings package includes

CityGML (Kolbe et al., 2021), which addresses the

representation of virtual 3D city models, and Sim-

ple Features Access (SFA) (Herring, 2011), which

addresses the representation of 2D vector data. The

Discovery package includes standards for geographic

information discovery (e.g. using metadata or on-

tologies). The Sensors package includes standards

for modelling, managing, and querying sensors, such

as the SensorThings API (Liang et al., 2021) and

the Sensor Observation Service (SOS) (Br

oring et al.,

2012).

https://www.ogc.org

https://www.ogc.org/docs/is

GISTAM 2023 - 9th International Conference on Geographical Information Systems Theory, Applications and Management

168

Figure 1: Selected OGC geospatial standards for smart cities.

3 MOTIVATING SCENARIO

This section describes a real-world smart city plat-

form in order to illustrate geospatial issues and re-

quirements within smart cities scenarios.

3.1 Montevideo Smart City Platform

and Applications

The Municipality of Montevideo (MM) deploys a

FIWARE-based SCP (MM SCP) that receives data

from a city-wide IoT sensor network (cf. Fig. 2.).

Data are generated by smart things (sensors and pri-

vate apps) and sent to IoT Agents, which invoke Con-

text Management components: Orion Context Bro-

kers

to process the incoming data, Apache Flume to

create an intermediate buffer before persisting data,

and MongoDB

and other databases to persist data.

The Data Viewing and Management applications

display real-time and statistical data using dashboards

and maps. The Public Applications include the MM

Portal and two geospatially-enabled applications that

use dynamic maps from server-side geospatial ser-

vices: the Buses App

and the Beaches App

The Buses App shows the real-time location of

buses on a map. The location is automatically sent by

every bus to the MM SCP. The Beaches App displays

information (e.g. current beach ﬂag, algal bloom

warnings, etc.) that are daily uploaded to the MM

SCP by the staff (e.g. lifeguards) using a private app.

The following limitations are identiﬁed in this

scenario: (i) each application integrates geospatial

and smart things data using its own client-side code;

(ii) each application implements geospatial logic with

client-side code or server-side (not platform-side) ser-

vices; (iii) the MM SCP does not provide applications

with platform-side, geospatial components.

a Context Broker manages the entire lifecycle of con-

text information including updates, queries, registrations

and subscriptions in a smart cities platform

https://www.mongodb.com/

http://www.montevideo.gub.uy/buses/mapaBuses.html

http://montevideo.gub.uy/playas

3.2 Geospatial Issues and Requirements

for Smart Cities Platforms

Scenarios like the one described in Section 3.1 present

the following issues, which are depicted in Fig. 3.

1. Lack of an explicit geospatial integration

mechanism at the platform level: Since the SCP

does not provide an explicit mechanism to inte-

grate advanced geospatial capabilities, it is up to

each application to provide the integration logic

between SCP and geospatial logic, adding com-

plexity to each application and potential code du-

plication among applications.

2. Lack of complex geospatial logic at the plat-

form level: Since SCPs only support basic

geospatial capabilities, it is up to each application

to implement complex geospatial logic, resulting

in overly complex, unreusable logic in each appli-

cation, and potential code duplication among ap-

plications.

3. Sub-optimal use of geospatial standards: Since

geospatial capabilities are not available at the

platform level, applications often resort to non-

standard Web APIs (e.g. Google Maps API), mak-

ing standards adoption more difﬁcult than when

the platform provides them.

To tackle the described issues, the following re-

quirements are proposed for a Geospatial Smart Cities

Platform (GeoSCP).

1. Provide an Explicit SCP and Geospatial Inte-

gration Mechanism: To facilitate application de-

velopment, the integration logic must be provided

at the platform level rather than at the application

level.

2. Support Standards-based Geospatial Logic: To

facilitate application development and promote

code reuse, the GeoSCP must support the incre-

mental deployment of complex geospatial logic

at the platform level, avoiding complex geospatial

logic at the application level.

3. Provide a General Architecture that Includes

Standards-Based Geospatial Capabilities: To

Standards-Based Geospatial Services Integration for Smart Cities Platforms

169

Figure 2: General architecture of MM SCP.

Figure 3: Issues in typical scenarios (numbers correspond to each issue).

prevent the use of geospatial capabilities through

non-standard APIs, the GeoSCP must provide the

equivalent standards-based capabilities in a well-

deﬁned architecture.

In order to facilitate the long-term evolution of the

proposal and widen its applicability and interoperabil-

ity in the scope of other public smart cities initiatives,

the following non-functional aspects should be con-

templated: (i) low coupling of components to facil-

itate the substitution of any component; (ii) extensi-

bility of the provided geospatial standards; (iii) feasi-

bility to be implemented with open source software;

(iv) alignment to the reference architecture presented

in Section 2.1.

4 PROPOSED SOLUTION

This section describes the proposed solution in or-

der to provide a standards-based geospatial services

integration for smart cities platforms. A high-level

overview of the solution and its architecture is pre-

sented, as well as a description of the main compo-

nents and their interactions.

4.1 General Description and Main

Components

The proposed solution is a Geospatial Smart Cities

Platform (GeoSCP) that combines a Geospatial

Server with an SCP. A Geospatial Server is a spe-

cialised middleware that implements OGC standards.

More than one geospatial server type may be used to

implement all the necessary standards. The general

architecture of the solution is shown in Figure 4 and

its main components are described in what follows.

Other SCP components can be added for speciﬁc sce-

narios.

The Smart Cities Platform in this architecture rep-

resents an SCP with no native support for geospa-

tial capabilities. The main components are the IoT

Agents and the Context Broker, which are inspired by

the FIWARE architecture. The IoT Agents interact

with smart things and send data to the Context Broker

using a common Context Information Model (CIM)

API. Since not every smart thing implements the same

transport protocol (e.g. MQTT) or data exchange for-

mat (e.g. JSON), a specialised subtype of IoT Agent

with a different API for each combination of protocols

is needed. The Context Broker acts as the primary ac-

cess point to context information, using the same CIM

GISTAM 2023 - 9th International Conference on Geographical Information Systems Theory, Applications and Management

170

Figure 4: GeoSCP General Architecture.

as the IoT Agents. The Context Broker stores data

that is sent by IoT Agents in the Context Database

and uses the Publish-Subscribe pattern to send data to

subscribers.

The Geospatial Server, which offers an extensi-

ble set of services that can be invoked either by ap-

plications or by SCP components, is divided into

two layers. The Geospatial Services layer consists

of Data Access, Portrayal, and Processing services

among other services. The Geospatial Components

layer comprises components used by the services to

execute the business logic. The Features Access com-

ponent handles CRUD

operations on vector data,

stored in a Geospatial Database. The Web Mapping

component generates map images. The Geoprocess-

ing component provides the executable processes for

the Processing services.

The Smart Things component represents all the

devices that interact with a corresponding IoT Agent.

The Applications component represents the end-user

and admin applications that could potentially use the

geospatial capabilities of the GeoSCP. The Exter-

nal Systems component groups Web APIs, external

Geospatial Services, other SCPs, etc., that could be

used by the GeoSCP to complement its internal data

or functionalities.

4.2 Components Interactions

This section depicts the most common interaction

ﬂows between components.

The Registration and Subscription Flow, shown

CRUD is the acronym of Create, Read, Update, Delete

in Figure 5, is performed when a new smart thing

is created in the SCP. First, an admin application or

an external system invokes the appropriate method

(e.g. CreateSmartThing) on the IoT Agent API. At

least the smart thing id and its type must be provided.

Next, the IoT Agent invokes a method (i.e. RegisterS-

martThing) to register the smart thing on the Context

Broker. The IoT Agent API may vary according to

its subtype, but the Context Broker always uses the

same CIM API, as was explained in Section 4.1. Fi-

nally, the admin application or external system creates

a new subscription in the Context Broker. The sub-

scription tells the Context Broker that when a smart

thing of a certain type sends a notiﬁcation that satis-

ﬁes a certain condition, some geospatial service end-

point has to be invoked. For instance, the smart thing

could be a bus (type=Bus) that reports certain values

like its location, speed, etc. The condition in the sub-

scription could specify that a Data Access Service is

invoked each time the bus sends a new location value.

The Notiﬁcation Flow, shown in Figure 6, is per-

formed when a smart thing sends some updated data

to the SCP. First, the smart thing invokes the appro-

priate method (e.g. UpdateValue) on the IoT Agent

API. At least, the smart thing id, the attributes that

are being reported (e.g. the location, speed) and the

new values for those attributes type must be provided.

Next, the IoT Agent invokes a method (e.g. Update-

Context) to send the updated values to the Context

Broker and the Context Broker updates the values be-

longing to the originating smart thing in the Context

Database. At this moment, the Context Broker has to

verify that there is a subscription that matches the type

(e.g. type=Bus) and that the attributes being updated

Standards-Based Geospatial Services Integration for Smart Cities Platforms

171

Figure 5: Smart thing registration and subscription creation.

(e.g. location) match the condition of the subscrip-

tion. If both conditions hold true, the endpoint that

was speciﬁed with the subscription is invoked (e.g.

the GeospatialOperation of a Geospatial Service).

5 IMPLEMENTATION AND

ASSESSMENT DETAILS

A prototype of the proposed GeoSCP and three smart

cities applications (based on GeoSCP) were devel-

oped, which provides a reference implementation for

the proposal. This section provides implementation

and assessment details.

5.1 Implementation Details

The GeoSCP implementation (Abell

a et al., 2021),

whose architecture is shown in Fig. 7, is based on FI-

WARE and includes a Geospatial Server provided by

Pygeoapi

(Python implementation of the OGC API

suite of standards). The OGC APIs (e.g. API Pro-

cesses) were favoured over the OGC Web Services

(e.g. WPS) because they are based on RESTful inter-

faces with JSON payloads, which goes in line with

FIWARE APIs. The Geoprocessing subcomponent

is used by the API Processes and includes the sup-

porting processes for the developed applications, but

may be reused by other applications. The SFA com-

ponent is used by the API Features and allows access

to 2D vector data (e.g. bus routes) in the PostgreSQL

database.

Based on the implemented GeoSCP prototype,

three smart cities applications were developed: Bus

Detours, Beach Ranking, and Sensor Management

The Sensor Management application manages the

sensor’s life cycle, using the Registration and Sub-

scription Flow (cf. Section 4.2), and generates

simulated data for the other applications, using the

platform-side SensorProcess.

The Beach Ranking application let citizens know

if a beach is too crowded before arriving. It leverages

https://pygeoapi.io

https://www.postgresql.org/

Code and screenshots available at: www.ﬁng.edu.uy/

owncloud/index.php/s/WxOommkYExin427

sensors at beach entrances to detect people coming in

and out and uses the platform-side RankingProcess,

which receives data from sensors, counts the people at

a certain beach, and divides that number by the beach

area, generating a crowding index.

The Bus Detours application shows unexpected

bus detours (e.g. because of accidents) using the

platform-side DetourProcess, which receives the real

position of every bus and informs its location as well

as route changes in real-time.

The Ranking and Detour processes follow the No-

tiﬁcation Flow (cf. Section 4.2) and are published

through the API Processes.

In conclusion, the GeoSCP-based applications

(Beach Ranking and Bus Detours) show that it is pos-

sible to achieve a similar level of functionality than

that provided by the MM SCP applications (Busses

and Beaches Apps) with the following advantages: (i)

the integration between the SCP and the geospatial

logic is transparent to the applications, (ii) complex

geospatial logic is implemented as platform-side pro-

cesses, facilitating application development and code

reuse and (iii) promoting the use of an uniﬁed service

interface based on OGC standards.

5.2 Assessment and Discussion

The assessment of the technical feasibility of the so-

lution was carried out through the development of a

platform prototype and three applications, which con-

stitute a reference implementation of the solution (cf.

Section 5.1).

The three main requirements that were proposed

in Section 3.2 are met in the solution. The ﬁrst

one was achieved by leveraging the platform-level

Publish-Subscribe mechanism to invoke geospatial

services in an event-driven fashion, which prevents

applications from implementing the integration logic.

The second requirement was achieved by provid-

ing standards-based Processing Services to support

platform-level, reusable geospatial processes, simpli-

fying the geospatial logic in applications. The third

requirement was achieved by integrating a standards-

based Geospatial Server with a well-deﬁned architec-

ture of geospatial services and components.

The non-functional requirements were addressed

in the following way. The low coupling was achieved

GISTAM 2023 - 9th International Conference on Geographical Information Systems Theory, Applications and Management

172

Figure 6: Update values and invoke Geospatial Service.

Figure 7: High-level architecture of the implemented solution.

by the use of the Publish-Subscribe mechanism,

which makes the inclusion or substitution of geospa-

tial services completely transparent to the other com-

ponents of the architecture (i.e. SCP, applications,

smart things, etc.). By using this mechanism, pub-

lishers (e.g. smart things) are loosely coupled to sub-

scribers (e.g. geospatial services) since there are not

any direct calls between them (Hohpe and Woolf,

2003). The extensibility of standards was achieved

by the inherent extensibility provided by the Geospa-

tial Server and the possibility to add other types of

geospatial servers (e.g. GeoServer

could be added

to support WFS and WPS that are not supported by

pygeoapi). The feasibility of a complete implementa-

tion based on open-source software was demonstrated

with the use of open-source components exclusively

(e.g. Orion, pygeoapi). The alignment to the refer-

ence architecture is established by the following map-

ping between component types in each architecture:

a Portrayal component is a Visualization component,

the Features Access, and Geoprocessing components

are Analytics components, the Geospatial Database is

a Model Repository, the Geospatial Services are Ser-

https://geoserver.org/

vice Middleware, the ContextBroker and IoT Agents

are IoT Middleware; the Context Database is a Data

Repository; Bus Detours and Beach Ranking are Cit-

izen Applications, Sensor Management is a Manager

application.

6 RELATED WORK

The integration of geospatial technologies within

smart cities solutions has been addressed in differ-

ent proposals (Bhattacharya and Painho, 2018)(Al-

Hader et al., 2009)(Souza et al., 2017)(Yan et al.,

2022)(Chaturvedi and Kolbe, 2019).

Souza et al. (Souza et al., 2017) describe the im-

plementation of the Smart Geo Layers middleware

and its use in an urban planning application for a

smart cities initiative in Natal, Brazil. The main goals

of this middleware are to unify and normalise data

from various sources, to insert geospatial information

related to physical spaces, and to include visualisation

as well as data analysis functionalities. Compared to

our work, this proposal performs the integration at

the data level (not supporting advanced functionali-

Standards-Based Geospatial Services Integration for Smart Cities Platforms

173

ties such as geospatial processes), and it is not based

on OGC standards for geospatial services and APIs.

Yan et al. (Yan et al., 2022) propose a Geo

Cyber-Physical System Platform for designing smart

cities, which leverages cyber-physical systems, GIS,

and touchable user interfaces (TUI). The platform

provides mechanisms for connecting these three el-

ements, enabling interactive sensing, processing, and

actuation in smart city development. Compared to our

work, this proposal is broader since it addresses inte-

gration with TUI. However, it is neither as detailed as

ours regarding the speciﬁc geospatial services to pro-

vide nor is based on OGC standards.

Bhattacharya et al. (Bhattacharya and Painho,

2018) propose SmaCiSENS: a globally shared open

spatial expert system, providing a geo-enabled knowl-

edge based for smart cities. The proposal addresses

the integration of interfaces and functions of Spatial

Data Infrastructures (SDI) and Sensor Web (SW), as

well as sensor data application program interfaces for

smart cities. Compared to our work, this proposal also

leverages OGC standards but it focuses on the integra-

tion of SDI and SW.

Chaturvedi et al. (Chaturvedi and Kolbe, 2019)

propose a Web service called InterSensor Service that

allows to connect to multiple IoT platforms, simula-

tion data, databases, and simple ﬁles to retrieve ob-

servations independently of data storage and speciﬁc

APIs. The service encodes these observations “on-

the-ﬂy” according to interfaces such as the OGC SOS

and OGC SensorThings API, offering a uniﬁed API

for the applications. Compared to our work, this

proposal does not address the integration of generic

geospatial services (e.g. Data Access Services, Pro-

cessing Services, etc.) into an existing SCP to pro-

vide complex geospatial logic to applications, but in-

stead it focuses on providing a standardized interface

to applications that can act as SOS and SensorThings

clients.

7 CONCLUSIONS AND FUTURE

WORK

This paper proposed GeoSCP: a standards-based so-

lution for geospatial services integration for SCPs.

The proposal comprises an overall architecture as

well as a reference implementation based on FIWARE

and includes three applications.

The development of the proposal was driven by

requirements of smart cities scenarios, illustrated by

a real-world case (i.e. MM SCP), in which SCPs do

not provide built-in components to support geospa-

tial capabilities. The proposed solution addressed

the identiﬁed requirements by: i) providing an ex-

plicit SCP and geospatial integration mechanism;

ii) supporting standards-based geospatial logic; and

iii) providing a general architecture with standards-

based geospatial capabilities. In addition, it contem-

plates non-functional aspects regarding the low cou-

pling of components, geospatial standards extensibil-

ity, open-source implementation, and alignment with

a reference architecture. The technical feasibility of

GeoSCP was assessed through the development of a

prototype and three applications.

The main contribution of this work is the overall

architecture proposal for integrating standards-based

geospatial services with SCPs as well as its refer-

ence implementation. These results can be leveraged

by smart cities initiatives to enhance their SCPs with

geospatial capabilities, to enable and promote im-

plementation agility, maintainability, reuse, and stan-

dards adoption for their smart cities applications re-

quiring geospatial support.

Future work includes: i) assessing the proposal

with other SCP (e.g. InterSCity) and other geospatial

servers (e.g. GeoServer); ii) extending the reference

implementation with other geospatial services and ap-

plications; and iii) advancing in the validation of the

proposal in real-world cases.

ACKNOWLEDGEMENTS

The authors would like to thank the Department of

Sustainable and Smart Development of the Munici-

pality of Montevideo for providing us with the re-

quired insight into their Smart City Platform which

was a key asset for the deﬁnition of the motivating

scenario.

REFERENCES

Abell

a, G., Machado, A., and Susviela, D. (2021). Tec-

nolog

ıas geoespaciales en plataformas de smart cities.

Undergraduate thesis, Facultad de Ingenier

ıa, Univer-

sidad de la Rep

ublica (Uruguay).

Ahad, M. A., Paiva, S., Tripathi, G., and Feroz, N. (2020).

Enabling technologies and sustainable smart cities.

Sustainable Cities and Society, 61:102301.

Al-Hader, M., Rodzi, A., Sharif, A. R., and Ahmad, N.

(2009). Soa of smart city geospatial management.

In 2009 Third UKSim European Symposium on Com-

puter Modeling and Simulation, pages 6–10.

Alberti, A. M., Santos, M. A. S., Souza, R., Da Silva, H.

D. L., Carneiro, J. R., Figueiredo, V. A. C., and Ro-

drigues, J. J. P. C. (2019). Platforms for smart envi-

GISTAM 2023 - 9th International Conference on Geographical Information Systems Theory, Applications and Management

174

ronments and future internet design: A survey. IEEE

Access, 7:165748–165778.

Bhattacharya, D. and Painho, M. (2018). Location intel-

ligence for augmented smart cities integrating sen-

sor web and spatial data infrastructure (smacisens).

In GISTAM 2018-Proceedings of the 4th Interna-

tional Conference on Geographical Information Sys-

tems Theory, Applications and Management, volume

2018, pages 282–289. SciTePress-Science and Tech-

nology Publications.

oring, A., Stasch, C., and Echterhoff, J. (2012). OGC

Sensor Observation Service Interface Standard. Re-

port, Open Geospatial Consortium.

Chaturvedi, K. and Kolbe, T. H. (2019). Towards estab-

lishing cross-platform interoperability for sensors in

smart cities. Sensors, 19(3).

da Silva, T. P., Batista, T., Lopes, F., Neto, A. R., Deli-

cato, F. C., Pires, P. F., and da Rocha, A. R. (2021).

Fog computing platforms for smart city applications -

a survey. ACM Trans. Internet Technol.

Daniel, S. and Doran, M.-A. (2013). Geosmartcity: Geo-

matics contribution to the smart city. In Proceedings

of the 14th Annual International Conference on Digi-

tal Government Research, dg.o 13, page 65–71, New

York, NY, USA. Association for Computing Machin-

ery.

de la Beaujardiere, J. (2006). OpenGIS Web Map Server

Implementation Speciﬁcation. Report, Open Geospa-

tial Consortium.

de Vries, W. (2021). Trends in the adoption of new geospa-

tial technologies for spatial planning and land man-

agement in 2021. Geoplanning: Journal of Geomatics

and Planning, 8(2):85–98.

Herring, J. (2011). OpenGIS Implementation Standard for

Geographic information - Simple feature access - Part

1: Common architecture. Report, Open Geospatial

Consortium.

Hohpe, G. and Woolf, B. (2003). Enterprise Integration

Patterns: Designing, Building, and Deploying Mes-

saging Solutions. Addison–Wesley.

ITU (2018). Recommendation ITU-T Y.4201: High-level

requirements and reference framework of smart city

platforms. Technical report, International Telecom-

munication Union.

Kolbe, T. H., Kutzner, T., Smyth, C. S., Nagel, C., Roens-

dorf, C., and Heazel, C. (2021). OGC City Geogra-

phy Markup Language (CityGML) Part 1: Concep-

tual Model Standard. Report, Open Geospatial Con-

sortium.

Lee, C. and Percivall, G. (2008). Standards-based comput-

ing capabilities for distributed geospatial applications.

Computer, 41(11):50–57.

Liang, S., Khalafbeigi, T., and van der Schaaf, H. (2021).

OGC SensorThings API Part 1: Sensing Version 1.1.

Report, Open Geospatial Consortium.

Mas

o, J., Pomakis, K., and Juli

a, N. (2010). OpenGIS Web

Map Tile Service Implementation Standard. Report,

Open Geospatial Consortium.

Mueller, M. and Pross, B. (2018). OGC WPS 2.0.2 Interface

Standard. Report, Open Geospatial Consortium.

Percivall, G. (2015). OGC Smart Cities Spatial Information

Framework. Report, Open Geospatial Consortium.

Percivall, G. (2020). OGC Abstract Speciﬁcation Topic 0 -

Overview. Report, Open Geospatial Consortium.

Portele, C., Vretanos, P. P. A., and Heazel, C. (2018). OGC

API - Features - Part 1: Core. Report, Open Geospa-

tial Consortium.

Pross, B. and Vretanos, P. P. A. (2021). OGC API - Pro-

cesses - Part 1: Core. Report, Open Geospatial Con-

sortium.

Saborido, R. and Alba, E. (2020). Software systems from

smart city vendors. Cities, 101:102690.

Santana, E. F. Z., Chaves, A. P., Gerosa, M. A., Kon, F.,

and Milojicic, D. S. (2017). Software platforms for

smart cities: Concepts, requirements, challenges, and

a uniﬁed reference architecture. ACM Comput. Surv.,

50(6).

Sharma, P., Singh, R., and Srivastava, A. (2021). Analyzing

the Role of Geospatial Technology in Smart City De-

velopment, pages 1–20. Springer International Pub-

lishing, Cham.

Souza, A., Pereira, J., Oliveira, J., Trindade, C., Cavalcante,

E., Cacho, N., Batista, T., and Lopes, F. (2017). A

data integration approach for smart cities: The case of

natal. In 2017 International Smart Cities Conference

(ISC2), pages 1–6.

Vretanos, P. P. A. (2010). OpenGIS Web Feature Service

2.0 Interface Standard. Report, Open Geospatial Con-

sortium.

Yan, W., Kiyoki, Y., and Murakami, Y. (2022). The Geo

CPS Platform for Designing Smart Cities.

Standards-Based Geospatial Services Integration for Smart Cities Platforms

175