A Framework for ITS Data Management in a Smart City Scenario

∗

Luca Carafoli

, Federica Mandreoli

1,3

, Riccardo Martoglia

1,3

and Wilma Penzo

2,3

FIM, University of Modena and Reggio Emilia, Modena, Italy

DISI, University of Bologna, Bologna, Italy

IEIIT-BO/CNR, Bologna, Italy

Keywords:

Intelligent Transportation System, Smart City, Relational Databases, Stream Data, Data Reduction Tech-

niques.

Abstract:

In this paper we introduce a technological framework to efﬁciently support data management in a modern

Intelligent Transportation System (ITS). The proposed technology enables the efﬁcient storage of a variety

of recent/historical/static data and guarantees its effective querying by supporting continuous as well as one-

time queries for the delivering of real-time trafﬁc services. The framework also offers a scalable solution for

coping with the acquisition of huge volumes of data by employing data reduction techniques in Vehicle-to-

Infrastructure transmissions. Experimental evaluation on the Linear Road ITS benchmark and along various

simulated scenarios demonstrates that the proposed framework efﬁciently supports smart city data needs.

1 INTRODUCTION

The congestion in urban areas is, and will become

more and more, a crucial problem of modern soci-

ety and many investments are going to be made in the

direction of the so-called smart cities, whose objec-

tives include the improvement of citizens’ life-style

by pushing innovation in urban mobility (Streetline

Inc., 2011). Smart services, speciﬁcally designed to

improve people’s quality of life by making their lives

easier and more efﬁcient, can exploit the recent devel-

opment of sensing technology to collect a multitude

of data from various sources, e.g. vehicles, toll gates,

trafﬁc lights, parking meters, weather stations, and

others. Nevertheless, they are also expected to access

historical and static data, e.g. trafﬁc statistics, street

cleaning programme, upcoming exhibitions. For ex-

ample, by sensing and detecting parking activity in

real time, together with information about possible

road works or street cleaning programme, a driver

would be encouraged to take an alternative means

(e.g. bus, metro, bike sharing) knowing that no park-

ing is available, or that it is not allowed, at the desired

destination. Similarly, a mobility manager could re-

inforce dynamically the transportation services on the

basis of trafﬁc conditions and of the expectation of

large inﬂows due, for instance, to sporting events. In

∗

This work is partially funded by the Italian Council In-

dustria 2015 PEGASUS Project.

this perspective, in order to make smart transportation

services sustainable, a modern Intelligent Transporta-

tion System (ITS) should:

• collect, process and manage both real-

time/historical data coming from heterogeneous

sources, and static data, in a transparent way;

• provide timely information to be used by ad-

vanced services that pursue the city’s needs;

• be scalable in order to manage huge amounts of

data in the rush hours.

To this end, according to (Cotton, 2011), data man-

agement is a primary challenge to be faced. A care-

ful/rough implementation of it makes an ITS effective

or not.

In order to cope with large volumes of con-

tinuously streaming data in use to common soft-

ware applications, Data Stream Management Sys-

tems (DSMSs) have been introduced (Abadi et. al.,

2003; Arasu et al., 2006). These systems natively

support continuous queries (CQs) over (continuous

unbounded) streams of data according to windows

where only the most recent data is retained (Terry

et al., 1992). Once data goes out of the windows it

is deleted from the system. This model does not com-

pletely ﬁt the needs of a modern ITS in a smart city

context, where, besides CQs, also one-time queries

(OTQs) on a variety of recent/historical/static data

have to be supported, e.g., to provide for statistical

215

Carafoli L., Mandreoli F., Martoglia R. and Penzo W..

A Framework for ITS Data Management in a Smart City Scenario.

DOI: 10.5220/0004380302150221

In Proceedings of the 2nd International Conference on Smart Grids and Green IT Systems (SMARTGREENS-2013), pages 215-221

ISBN: 978-989-8565-55-6

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

data and trafﬁc forecasts.

In order to fulﬁll these needs some DSMSs

have moved towards integrating DBMS functionali-

ties within their own architectures (e.g. (Abadi et. al.,

2003; Arasu et al., 2006)). These approaches have the

main drawback of requiring to redesign from scratch

a core of well-established DBMS techniques that can

not be reused as such in a DSMS architecture. Fur-

ther, in these solutions (Arasu et al., 2006), accord-

ing to the DSMS philosophy, historical data neces-

sarily has to be converted into a stream before being

queried, thus producing an unbearable overhead for

the system.

Other works (Botan et al., 2009) propose two-

layered solutions with the DSMS relying on the func-

tionalities provided by a DBMS. The combination of

these systems, each designed for speciﬁc and oppo-

site goals, does not solve the DBMS inefﬁciencies in

storing/retrieving data at the rate a DSMS requires.

In this paper we introduce a framework that of-

fers data management facilities to make ITS services

sustainable in a smart city, along two main directions:

Data Storage and Querying, by providing ITSs with

a technological support that enables the efﬁcient

storage of a variety of streaming data and its ef-

fective querying for the delivering of real-time

trafﬁc services. This is achieved through speciﬁc

extensions to the Transactional Storage Manager

(TSM) of a relational DBMS, where a new type

of table, called streaming table, is introduced;

Data Flow Acquisition, by offering a scalable solu-

tion for coping with the gathering of huge vol-

umes of data. Complementary to approaches that

aim at system upgrades, and with the goal of fos-

tering data management sustainability, our work

aims at selecting information at the sources, by

discarding redundant and less relevant data since

the acquisition phase (Carafoli et al., 2012).

The paper is organized as follows. Section 2 gives

an intuition of the information needs to implement

smart trafﬁc services. Section 3 sketches the archi-

tecture of the proposed framework. In Section 4 de-

tails are given about the Extended DBMS while the

experienced data reduction techniques are introduced

in Section 5. Section 6 shows results of experimental

evaluation and conclusions are drawn in Section 7.

2 A USE CASE

The use case we adopt in this paper concerns manag-

ing parking availability in a “smart” way, so to con-

tribute to reduce trafﬁc congestion and pollution in

cities. It is implemented as an enhanced version of

Dynamic Parking Price (DPP) service (Streetline Inc.,

2011) that leverages real-time information gathering

and analysis. When a driver looks for parking, the

service suggests him/her the most convenient avail-

able one and promptly computes its hourly cost and

the best route to reach it. The most convenient parking

is not always the cheapest one. For instance, it could

be the easiest to reach according to trafﬁc conditions

or the nearest if it is snowing. To rank the parking

alternatives, the service exploits information coming

from three kinds of sources, parking meters, vehicles

and weather stations, together with past driver behav-

ior and base parking prices.

It is worth noting that the DPP service needs to

query and process real time data coming from the

sources, together with historical, i.e. past driver be-

havior, and static data, i.e. base parking prices.

Whenever a driver submits a parking request, DPP

must retrieve the vehicle’s position through location-

based services. This is done by means of a traditional

SQL-based one-time query (OTQ) on the position re-

ports acquired from the vehicles.

Then, it has to calculate the route to the best park-

ing according to the trafﬁc conditions. To obtain

them, DPP relies on trafﬁc monitoring services, which

work on aggregate information. For instance, it relies

on a continuous query (CQ) that, every minute, re-

turns the average traveling speeds of each segment.

To compute parking prices, DPP relies on base

prices that are increased or decreased by means of

multipliers that depend on source status conditions.

For instance, in case of a sunny day the weather mul-

tiplier would be 1, while in a snowy day it could be

lower. In fact, in case of a heavy snowfall, managers

could lower the parking prices to encourage people to

leave their vehicles and move with alternative means,

such as metro or street cars. So DPP needs to join the

base prices, that is static information, with the real-

time information coming from different sources.

3 ARCHITECTURE

The data management framework we propose re-

lies on a typical ITS scenario where distributed data

sources collect raw data from the real world and send

them in the form of data streams to a Control Centre

(CC) through GPRS. As to data sources, we assume

that cars are equipped with On-Board Units (OBUs),

small mobile computing devices that acquire data

through GPS and accelerometer units and perform

real-time GPRS communications. The CC stores and

processes this data to provide end users with various

SMARTGREENS2013-2ndInternationalConferenceonSmartGridsandGreenITSystems

216

Data Reduction Layer

Data Acquisition Layer

Data Filtering

EDBMS

Extended DBMS Layer

Control Centre

Data Sources

}

Figure 1: The framework architecture.

services enhancing mobility.

As shown in Figure 1, the framework acts both

at data source level and at CC level. At data source

level, in order to reduce communication costs and

CC workload, the framework implements data reduc-

tion techniques on the OBUs. Thanks to these tech-

niques, OBUs aim to send useful information only,

while avoiding redundancy.

The remaining layers are localized in the CC. The

Data Acquisition Layer has the goal to convert data

coming from heterogeneous sources to common for-

mats. For example, as to geographic coordinates, one

possible format is the Universal Transverse Mercator

(UTM-NAD83) (NOAA, 2008). In this case, all data

coming in the system in different formats, e.g. De-

grees, minutes and seconds - WGS84 (NIMA, 2000),

needs to be converted.

Finally, the Extended DBMS layer augments a tra-

ditional DBMS with the capability of retaining data

streams beyond their real-time processing, by manag-

ing and storing them transparently as standard data.

This is an essential requirement for a modern ITS

where many advanced services join real-time data

with past trends to derive not only the current situa-

tion but also to forecast incoming events.

4 THE EDBMS

The EDBMS is in charge of storing data streams com-

ing from sources and to promptly make them avail-

able to be queried together with other kinds of data,

such as historical data, e.g. trafﬁc statistics, and/or

static data, e.g. parking locations.

To this end, besides standard tables, it also sup-

ports a new kind of table, called streaming table, that

stores real-time data. A streaming table, differently

from traditional tables, undergoes continuous writes

and, besides OTQs, it also supports CQs. The design

choice of extending a traditional DBMS towards data

stream management beneﬁts of the exploitation of a

considerable amount of long-established query pro-

cessing and data management techniques.

In order to manage streaming table creation,

we introduce the SQL-like statement CREATE

STREAMING TABLE. The main idea is that each data

source is linked to a streaming table that stores its

data streams. For instance, in our DPP example,

a streaming table VEHICLES is created to store the

position reports received from vehicles:

CREATE STREAMING TABLE

VEHICLES(TIME DATE, VID INT, SPD INT,

XWAY INT, LANE INT, DIR INT, SEG INT,

POSITION POINT) RANGE INTERVAL ’2’

WEEK.

where RANGE deﬁnes the time period data stays in the

database. It is worth noting that the VEHICLES table

stores geo-temporal data. To this end, the POSITION

attribute is a POINT, which is made up of the coor-

dinates of the vehicles in the map, and the temporal

attribute TIME is managed with speciﬁc methods.

To insert data in streaming tables, we introduce

some changes to the standard SQL INSERT statement:

INSERT INTO VEHICLES VALUES FROM

‘‘VEHICLES.STR’’

where the FROM argument is a stream for continu-

ous data insertion. According to the insert semantics,

an insert request is required for each data insertion.

However, this is incompatible with data streams be-

cause it drastically slows down the insertion rate. In

our approach, the INSERT statement is submitted only

once and, then, the TSM exploits ad-hoc mechanisms

to speed up continuous stream data storage.

Further, as for traditional tables, indices can be de-

ﬁned to speed up data access. For instance, the SQL

command below creates a new index on the attribute

VID of the VEHICLES streaming table:

CREATE INDEX IDX VEHICLES ON

VEHICLES(VID)

With reference to the DPP service scenario, Table

1 shows three different kinds of queries that can be

submitted on three tables: VEHICLES, WEATHER and

PARKING. VEHICLES is a streaming table as described

previously. WEATHER is a streaming table that receives

a weather report update from a weather bureau every

10 minutes. The report contains various information,

such as weather conditions, temperature and other

meteorological measures. PARKING is a traditional

table that stores general information about parkings,

such as the area they are located in (the same ﬁeld is

also stored in the WEATHER table), the base price, the

number of parking spaces and so on.

It is worth noting that the minimal extensions SQL

should undergo to support streaming tables and CQs

make the EDBMS a powerful means to design and

manage hybrid data-intensive applications.

AFrameworkforITSDataManagementinaSmartCityScenario

217

Table 1: Q1 is a CQ that calculates the average speed of each road segment. According to the SAMPLE INTERVAL statement,

it runs every minute and the WINDOW INTERVAL statement sets the query’s domain to the data arrived in the last minute. Q2

shows the possibility of querying data coming from both streaming and standard tables, joining them as needed. The goal is

to have an intuition about snowfall intensity. Q3 is an OTQ on a streaming table returning the current position of a vehicle.

Q1: Q2: Q3:

SELECT segment, AVG(speed) SELECT SUM(w.snow), p.id SELECT position

FROM VEHICLES [WINDOW INTERVAL ’1’ MINUTE] FROM WEATHER w [WINDOW INTERVAL ’30’ MINUTE], FROM VEHICLES

GROUP BY segment PARKING p WHERE time=NOW

SAMPLE INTERVAL ’1’ MINUTE WHERE w.area=p.area AND vid=VID X

AND w.condition= “snow”

GROUP BY p.id

SAMPLE INTERVAL ’10’ MINUTE

5 DATA REDUCTION

TECHNIQUES

In order to support ITS services, the CC receives a

large amount of updates, coming in real time from the

vehicles’ OBUs in the form of continuous streams of

GPS-derived time-stamped data. This causes an in-

crease of the communications between the vehicles

and the CC and, in general, of the load in all the

framework layers.

Differently from approaches that aim at system

upgrades by employing massive technologies, e.g.

parallel processing databases, data grids, etc., we

adopt a complementary perspective and foster data

management sustainability by employing data reduc-

tion techniques to select information at the sources,

by discarding redundant and less relevant data since

the acquisition phase. The main objective is to reduce

the number of data communications, bringing the im-

portant beneﬁts of cutting communications costs to-

gether with server side update costs. Data reduction

techniques are implemented in OBUs and they can be

divided in two main categories:

Independent Techniques: the OBU autonomously

decides when to issue updates to the server. The tech-

niques we consider in this context are:

Simple Sampling: an OBU transmits a data report at

a ﬁxed time rate T . This policy has also been con-

sidered in other ITS approaches (Xu et al., 2002) and

for purposes different from data reduction. Using this

policy, the movement of the vehicle is represented as

a constant time “jumping vector” that is independent

from the actual movements and the road network;

Space Sampling: this policy sends a position report

to the CC when the vehicle covers a ﬁxed distance D.

Therefore, differently from simple sampling, an OBU

transmits only if it is actually traveling. This policy

represents the vehicle movements as constant distance

“jumping vectors”. In order to improve accuracy, a

variant of this policy (“stop” version) allows vechicles

to send additional position reports when they stop or

restart their motion;

Map-based Sampling: The basic idea behind this ap-

proach is that the vehicle moves on map segments.

Therefore, in its simplest version, it sends a position

report whenever the end of a map segment is reached.

Similarly to space sampling, also map-based sam-

pling allows vehicles to inform the CC about stops

and restarts (“stop” version). Furthermore, instead of

relying on map segmentation data, it can decide to

transmit whenever a turn in the motion trajectory is

detected (“turn” version).

Information-need Techniques: the OBU decides

when to transmit on the basis of speciﬁc information

made available by the CC. The techniques we con-

sider in this category are:

Deterministic Information Need: The main idea of

the deterministic information need policy is to prevent

small differences in velocity from being transmitted

to the CC (Kerner et al., 2005). To this end, a velocity

threshold V is used and the OBU sends its position

report when |s − s(seg)

t,τ

| ≥ V , where s is the vehicle

speed and s(seg)

t,τ

is the average speed calculated by

CC in that segment;

Flow Information Need: The ﬂow information need

policy performs data reduction by using randomiza-

tion (Ayala et al., 2010). That means that every OBU

has an equal chance of transmitting to the CC, re-

gardless of its speed. We will test also an alternative

version of this technique where OBUs verify if they

could send their report whenever a turn is detected

(“turn” version), as for Map-Based Sampling.

6 EXPERIMENTAL EVALUATION

In this experimental evaluation, we will show the

results we obtained from the speciﬁc tests that are

SMARTGREENS2013-2ndInternationalConferenceonSmartGridsandGreenITSystems

218

mainly focused on the overall performance and scal-

ability of the EDBMS layer and the effectiveness of

the data reduction techniques. Without loss of gener-

ality, we will consider vehicles (i.e., their position and

speed sensors) as the primary source of incoming in-

formation. In particular, we will report on two kinds

of tests which stressed the framework capabilities in

reacting to simulated smart city-like workloads:

• two 3-hours simulations with very intense ITS-

based input rates, based on the Linear Road

stream data management benchmark (Arasu et al.,

2004) which is a reference in this ﬁeld, for testing

the performance and robustness of our EDBMS

layer in real-time storing, indexing and querying

incoming data (Section 6.1);

• four simulations reproducing actual trafﬁc condi-

tions of as many cities in different parts of the

world (Bologna, Roma, Camden and Beijing) to

put to the test the data reduction techniques in

such real cases (Section 6.2).

6.1 Data Storage and Query Processing

In the Linear Road stream data management bench-

mark, a multitude of cars move on multiple lanes of a

virtual highway and pay dynamically calculated tolls.

In particular, the input data (position reports, toll up-

dates and so on) is generated at varying levels of

complexity (i.e., number of simulated expressways),

where the data for testing each expressway reaches a

rate of 100000 reports per minute. A system is said

to achieve a so-called L-rating if it meets a 5 second

response time constraint for all toll queries while sup-

porting an input level encompassing L expressways

of data (e.g., rating L1 for 1 expressway). Note that

we will stress the unique capabilities of our EDBMS

layer in executing all the complex real-time requests

while, at the same time, we will go beyond the stan-

dard benchmark and also require the system to main-

tain the full stream history of position reports and to

make such history always queryable. We will indicate

these extended one- and two-expressway scenarios as

L1+ and L2+, respectively.

Besides standard table support from PostgreSQL

9.0, all the additional data structures and management

code are implemented in Java 1.6, exploiting Oracle

BDB 11gR2. All the experiments are executed on an

Intel 2.66Ghz Win7 workstation, equipped with 4GB

RAM and a 500GB 7200rpm SATA disk.

It is important to note that, in all Linear Road sce-

narios, the more time goes by, the more data enter the

system. Figure 2 shows, for each simulation minute

in scenario L2+, the average response time computed

up to that minute (line); the growing input workload

200000/min'input'tuples'@'t=180'

0.5"

1.5"

2.5"

17"

25"

33"

41"

49"

57"

65"

73"

81"

89"

97"

105"

113"

121"

129"

137"

145"

153"

161"

169"

177"

Avg$Response$+me$(sec)$

Time$(min)$

Figure 2: Average response time detail over the 3-hours

simulation time, at level L2+.

is depicted on the background. As we can see, the av-

erage response time increases very slowly even in the

ﬁnal part of the simulation, when more than 200000

tuples per minute have to be processed.

To contextualize these results, on our hardware (or

a closely comparable one), none of literature state-of-

the-art systems achieves a level of performance ex-

ceeding L2 (Abadi et. al., 2003; Botan et al., 2009),

the same supported by our system but in the much

more demanding extended L+ scenarios.

6.2 Data Reduction

In order to throughly evaluate the effectiveness of the

different data reduction techniques of our framework,

in this second part of our experiments we will discuss

the simulations performed on the following scenarios:

Bologna (BO, for short): a portion of the city cen-

ter, i.e. a typical european urban scenario, involv-

ing medium-width and narrow streets, where vehicle

stops are quite short and infrequent and the vehicle

average speed is low;

Roma (RO, for short): another european portion in-

volving non-central junctions and crossroads in Rome

(Italy), with fast and multi-way segments, vehicle

stops infrequent, and high trafﬁc density;

Toll Plaza (TP, for short): a portion of multi-way

road junctions in Camden (New Jersey, USA), includ-

ing a toll-payment station, with medium trafﬁc den-

sity and nearly one vehicle out of two stops;

Beijing (BJ, for short): a portion of Beijing trafﬁc

network, with very intense, congested and heteroge-

nous (i.e. not only cars but also a signiﬁcant number

of motorbikes and bicycles) trafﬁc conditions, where

vehicle stops are frequent and long.

All the scenarios simulate the incoming data ex-

changes needed to effectively support a typical traf-

ﬁc monitoring service, i.e. for maintaining the aver-

age travelling speed of each segment in a sufﬁciently

precise and updated way. The simulations are ten

minutes long and have been created in the PTV Vi-

sion VISSIM

software taking into account real data

http://www.ptv-vision.com

AFrameworkforITSDataManagementinaSmartCityScenario

219

10"

20"

30"

40"

50"

60"

0" 0,1" 0,2" 0,3" 0,4" 0,5" 0,6"

Error$(m)$

Sent$/$sec$

Simple"Sampling" Space"Sampling" Space"Sampling"con"Stop" MB" MB"Stop" MB"Turn" MB"stop"Turn"

10"

20"

30"

40"

50"

60"

0" 0,1" 0,2" 0,3" 0,4" 0,5" 0,6"

Error$(m)$

Sent$/$sec$

Simple"Sampling" Space"Sampling" Space"Sampling"con"Stop" MB" MB"Stop" MB"Turn" MB"stop"Turn"

Bologna

Roma

Toll Plaza

10"

15"

20"

25"

30"

35"

0,05" 0,1" 0,15" 0,2" 0,25"

Error$(%)$

Sent$/$sec$

15"

25"

35"

45"

55"

0,05" 0,1" 0,15" 0,2" 0,25"

Error$(%)$

Sent$/$sec$

15"

25"

35"

45"

55"

0,05" 0,1" 0,15" 0,2" 0,25"

Error$(%)$

Sent$/$sec$

20"

40"

60"

80"

100"

120"

0,05" 0,1" 0,15" 0,2" 0,25"

Error$(%)$

Sent$/$sec$

Beijing

Figure 3: Performance detail graphs for data reduction techniques in the four scenarios

on the detailed topography, trafﬁc volumes, vehicle

speeds and ﬂows representing typical trafﬁc condi-

tions in such environments.

In order to evaluate the actual effectiveness of

each technique, we will consider the communication

cost (messages sent per second) together with the av-

erage error produced by the CC in computing the av-

erage speeds. The error is computed as a mean of

the ”distances” between the expected values and the

actual values (as available from the complete simu-

lation data). We plotted the achieved results in Fig-

ure 3. All techniques were tested with a large variety

of values for their distinctive parameters, producing a

series of points in the graph, and in all their respec-

tive variants (including the “stop” ones, sending stop

and restart information, and the “turn” ones, send-

ing the needed data each time a turn is identiﬁed in

the vehicle trajectory). Note that, since space sam-

pling achieved worse results than simple sampling for

all scenarios, for a better readability space sampling

results are not reported in the graphs. Starting our

analysis from the BO and RO scenario, we can see

that the ﬂow-based technique (without turn option) is

able to produce the most satisfying performances, sig-

niﬁcantly decreasing the simple sampling error level.

Indeed, the regularity/predictability of the trafﬁc and

the infrequent stops performed by the vehicles are

well suited to such kind of techniques, while in TP

the higher number of stops makes their effectiveness

less evident. Finally, in BJ, which is a very complex

scenario, with very irregular trafﬁc ﬂows (also due to

the conspicuous presence of different vehicle types),

the error levels of most advanced techniques are quite

high: in this case, simple sampling appears the sim-

plest and most effective option.

7 CONCLUSIONS

In this paper we presented a technological framework

to efﬁciently support data management in modern In-

telligent Transportation Systems (ITSs). Data is col-

lected from various sources and stored in an Extended

DBMS (EDBMS) that guarantees efﬁcient storage

and access to a variety of recent/historical/static data.

To the authors’ knowledge, no proposal exists that

merges natively DBMS and DSMS paradigms.

The EDBMS’s transactional storage manager ex-

ploits a new type of table, called streaming table, to

store live as well as past streamed data. Streaming

tables are subjected to continuous writes and support

both CQs and OTQs. The EDBMS provides query

capabilities that span streaming tables as well as tra-

ditional relational tables in a transparent way. As to

scalability issues related to the management of huge

amounts of incoming data, we experienced the em-

ployment of V2I data reduction techniques in the data

acquisition phase. A preliminary experimental evalu-

ation on the standard Linear Road ITS benchmark and

along various simulated trafﬁc scenarios has shown

the storage/query efﬁciency offered by the streaming

table implementation and the effectiveness of the em-

ployed data reduction techniques.

REFERENCES

Abadi et. al., D. (2003). Aurora: a new model and architec-

ture for data stream management. VLDBJ, 12(2):120–

139.

Arasu, A., Babu, S., and Widom, J. (2006). The CQL

continuous query language: semantic foundations and

query execution”. VLDB J., 15(2):121–142.

Arasu, A., Cherniack, M., Galvez, E., Maier, D., Maskey,

A., Ryvkina, E., Stonebraker, M., and Tibbetts, R.

(2004). Linear Road: A Stream Data Management

Benchmark. In Proc. of VLDB, pages 480–491.

Ayala, D., Lin, J., Wolfson, O., Rishe, N., and Tanizaki, M.

(2010). Communication Reduction for Floating Car

Data-based Trafﬁc Information Systems. In Proc. of

GEOPROCESSING, pages 44–51.

Botan, I., Alonso, G., Fischer, P., Kossmann, D., and Tat-

bul, N. (2009). Flexible and scalable storage manage-

ment for data-intensive stream processing. In Proc. of

EDBT, pages 934–945.

Carafoli, L., Mandreoli, F., Martoglia, R., and Penzo, W.

(2012). Evaluation of data reduction techniques for

vehicle to infrastructure communication saving pur-

poses. In Proc. of IDEAS, pages 61–70.

Cotton, B. (2011). Moving citizens in the smarter city -

SMARTGREENS2013-2ndInternationalConferenceonSmartGridsandGreenITSystems

220

using a framework approach to plan intelligent trans-

portation systems strategies and implement solutions.

http://www.frost.com.

Kerner, B., Demir, C., Herrtwich, R., Klenov, S., Rehborn,

H., Aleksic, M., and Haug, A. (2005). Trafﬁc state

detection with ﬂoating car data in road networks. In

Proc. of ITSC, pages 44 – 49.

NIMA (2000). Department of defense world geodetic sys-

tem 1984, its deﬁnition and relationships with local

geodetic systems. Technical report, TR8350.2.

NOAA (2008). Nad 83 (nsrs2007) national readjustment

ﬁnal report. Technical report, NOS NGS 60.

Streetline Inc. (2011). Becoming a smart city. http://

www.streetline.com.

Terry, D., Goldberg, D., Nichols, D., and Oki, B. (1992).

Continuous queries over append-only databases. In

Proc. of SIGMOD, pages 321–330.

Xu, Q., Hedrick, K., Sengupta, R., and VanderWerf, J.

(2002). Effects of vehicle-vehicle/roadside-vehicle

communication on adaptive cruise controlled highway

systems. In Proc. of VTC, volume 2, pages 1249–

1253.

AFrameworkforITSDataManagementinaSmartCityScenario

221