title: document version: project number: project acronym...

The sole responsibility for the content of this publication lies with the authors. It does not necessarily reflect the opinion of the European Union. Neither the EACI nor the European Commission are responsible for any use that may be made of the information contained therein.

Title: Document Version:

D3.2 Information model and interoperability 1.0

Project Number: Project Acronym: Project Title:

621041 SIMON aSsIsted Mobility for Older aNd impaired users

Contractual Delivery Date: Actual Delivery Date: Deliverable Nature-Dissemination level:

M16 M17+3days R (Report) – PU (Public)

Responsible: Organisation: Contributing WP:

Manuel Vivó ETRA WP3

Authors (organisation):

Manuel Vivó (ETRA)

Marcus Handte (LOC)

Stephan Wagner (LOC)

Abstract:

This deliverable discusses the interoperability requirements of SIMON regarding the management of information, and describes the information data models adapted as a solution.

Keywords:

D3.2, SIMON, model, information, data, GTFS, OSM, interoperability

D3.2 Information model and interoperability 2

SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS

Revision History

Revision Date Description Author (Organisation)

V0.1 2015-04-09 ToC Manuel Vivó (ETRA)

V0.2 2015-04-24 First version of ETRA contribution: introductory sections 1 and 2, data models sections 6, 7 and 8 and Annexes B, C and D

Manuel Vivó (ETRA)

V0.3 2015-04-28 Minor corrections Manuel Vivó (ETRA)

V0.4 2015-05-04 Added section 3, 4 and 5. Marcus Handte (LOC)

V0.5 2015-05-05 Internal review. Stephan Wagner (LOC)

V0.6 2015-05-08 Conclusions section (¡Error! No se encuentra el origen de la referencia.) filled. Minor correc-tions. Useless template parts removed.

Manuel Vivó (ETRA)

V0.7 2015-05-18 Internal Review Alejandro Llaves (UPM)

V0.8 2015-05-28 Fixed section 3, 4 and 5 based on review com-ments.

Marcus Handte (LOC)

V0.9 2015-05-25 Fixed section 6, 7, 8 based on review comments Manolo Vivó (ETRA)

V1.0 2015-06-03 Last review. Document ready for submission. Eva Muñoz (ETRA)



TABLE OF CONTENTS

1. INTRODUCTION .............................................................................................................5

1.1. Purpose of the Document .............................................................................................. 5

1.2. Scope of the Document .................................................................................................. 5

1.3. Structure of the Document ............................................................................................ 5

2. SIMON SOLUTION FOR INTEROPERABILITY ....................................................................6

2.1. Interoperability Requirements ....................................................................................... 6

2.2. Information Model ......................................................................................................... 6

2.2.1. Data models ...................................................................................................................... 6

2.2.2. Rationale ........................................................................................................................... 7

3. OUTDOOR CITY MAP MODEL (OSM) ..............................................................................8

3.1. Choice of OSM ................................................................................................................ 8

3.2. Description ..................................................................................................................... 8

3.2.1. Main Characteristics ......................................................................................................... 8

3.2.2. Integration in SIMON ........................................................................................................ 9

4. INDOOR CITY MAPS MODEL......................................................................................... 11

4.1. Design Principles ........................................................................................................... 11

4.2. Description ................................................................................................................... 12

5. PUBLIC TRANSPORT MODEL (GTFS) .............................................................................. 15

5.1. Choice of GTFS .............................................................................................................. 15

5.2. Description ................................................................................................................... 15

5.2.1. Main characteristics .......................................................................................................15

5.2.2. Integration in SIMON ......................................................................................................18

6. PARKING AND ACCESS CONTROLLED AREAS MODEL .................................................... 19


6.2. Description ................................................................................................................... 20

6.2.1. Basic entities ...................................................................................................................20

6.2.2. Parking spaces ................................................................................................................24

6.2.3. Access controlled areas ..................................................................................................27

7. USERS AND SECURITY TOKENS MODEL......................................................................... 29


7.2. Description ................................................................................................................... 30

8. EVENT DATAMODEL .................................................................................................... 32




8.2. description .................................................................................................................... 33

8.2.1. Specific event classes .....................................................................................................33

8.2.2. Generic event class .........................................................................................................35

9. CONCLUSIONS ............................................................................................................. 36

10. REFERENCES AND ACRONYMS ............................................................................... 37

10.1. References ............................................................................................................. 37

10.2. Acronyms ............................................................................................................... 37

ANNEXES ......................................................................................................................... 38

I. ANNEX A – DETAILED DESCRIPTION OF INDOOR CITY MAPS MODEL .......................... 38

II. ANNEX B – DETAILED DESCRIPTION OF PARKING AND ACCESS CONTROL AREAS MODEL ................................................................................................................................. 64

III. ANNEX C – DETAILED DESCRIPTION OF EVENTS MODEL ............................................. 67



1. INTRODUCTION

1.1. PURPOSE OF THE DOCUMENT

is basically an integration project that makes different software components (services, applications and infrastructure systems) that shall intensively interoperate.

This deliverable discusses the interoperability requirements of regarding the management of information, and describes the information data models adapted as a solution.

1.2. SCOPE OF THE DOCUMENT

This document is aimed at explaining what interoperability requirements have been considered in project, at describing what solutions have been adopted and at illustrating the details about

the specific information models that have been adopted.

The content of this document is the result of the task T3.2 “Information Model and Interoperability” of WP3. This task relied on inputs from WP2 tasks (functional requirements and use cases) and had intense interaction, with bidirectional contributions, with tasks T3.1 and T3.3.

1.3. STRUCTURE OF THE DOCUMENT

The document includes the following contents:

Section 2 introduces the topics of this document. Subsection ¡Error! No se encuentra el origen de la referencia., explains the interoperability requirements covered and subsection ¡Error! No se encuentra el origen de la referencia. provides an overview of the information models adopted by .

Sections 3, 4, 5, 6, 7 and 8 describe each of the information models adopted. These sections focus on reasoning the adoption and providing a general view of each of the models. When a pre-existing information model has been adopted, the section will include a rationale on the choice and a description of the model. In case that the model has been produced to fulfil

requirements, design principles will be detailed as well as an overall description of it.

The annexes provide complementary details for each model, avoiding exhaustive descriptions of data model details in the main sections of the document.



2. SIMON SOLUTION FOR INTEROPERABILITY

2.1. INTEROPERABILITY REQUIREMENTS

project consists basically on the integration of set of diverse applications, services and infra-structure controlling systems involved in the urban mobility of impaired citizens. Details on the par-ticular components and the relationships between them can be found at deliverable D3.1 (1).

Those heterogeneous software components shall intensively interoperate between them, exchang-ing information about the city and the requests made by the users. The software architecture de-scribed in deliverables D3.1 (1) and D3.3 (2) enables this interaction and solves most of the associat-ed technical issues.

Those technical solutions rely on the assumption that all the components involved in each interac-tion have a common understanding on the semantics of the information exchanged and use a com-mon representation, what implies the adoption of a set of common information models.

Such information models need to fit with the requirements associated to the functionality described in deliverables D2.2 (3) and D2.3 (4), including all the concepts involved in the functionali-ties related to:

Route planning, guidance and navigation across the city using different transport modes

Guidance inside buildings

Real time information about the availability of car park spaces

Booking of car park spaces

Verification of the identity of users (mobility impaired citizens and parking controllers) by means of appropriate security elements (EU badges, NFC tags, etc.), to reduce fraud in the usage of parking spaces and the access to controlled areas.

In addition to this, the models need to include also concepts managed by the infrastructure control-ling system to be integrated, such as park meter devices and parking control system and barriers, number plate readers and access control systems.

Being an integration project, has to avoid the production of new information models from scratch and, whenever possible, had to adopt existing models that fit with the project requirements. Such models, preferably, have to be widely adopted standards in their field.

Another aspect considered at the time of choosing the information models to adopt, is the existence of data sources of information to be integrated at each of the project pilot sites. Some of those sources use pre-existing information models, and the possibility of adopting them and the cost of transforming data between models and formats was evaluated.

For all the above mentioned reasons it was decided to adopt of the OpenStreetMap (OSM) and Gen-eral Transit Feed Specification (GTFS) standards for city outdoor maps and for public transport, re-spectively.

For other aspects of functionality, no suitable existing models were found and the decision was to produce new models tailored to requirements: it is the case for indoor city maps, parking spaces, access controlled areas, users and security tokens and, partially, for event logging.

2.2. INFORMATION MODEL

2.2.1. Data models

The information model is structured in the following parts:



Outdoor city maps, for which OpenStreetMap (OSM) model has been adopted (see section 3) for more details.

Indoor city maps, for which a new information model has been produced within WP3 (see section 4).

Public transport, for which General Transit Feed Specification (GTFS) has been adopted, both for static information (definition of stops, routes and time tables) and dynamic information (real updates of the status of the routes, delays, etc.). See section 5 for more information.

Parking and Access Controlled Areas, for which a new information model has been produced within WP3 (see section 6).

Users and security tokens, for which a new information model has been produced within WP3 (see section 7).

2.2.2. Rationale

The information data models structure described in section 2.2.1 was chosen basically attending to two kinds of conditionings: on the one hand, the blocks of functionality associated to the re-quirements and the services defined in the architecture; on the other hand, the state of the art of ex-isting data models and sources of information.

For the first kind of conditionings, it was clearly identified the need of working with the following structure for the information model:

City Infrastructure

Users and security

Event logging

Regarding the city infrastructure, the state of the art of modelling imposes distinguishing clearly be-tween

Map models describing the city infrastructure, parking facilities, access controlled areas and points of interest

Public transport networks and services

For public transport several existing data models were found that fitted with the conceptual aspects associated to the corresponding functional requirements and one of them (GTFS) was chosen (see section 5 for more details).

However, it was also clear that none of the map models existing was complete enough to fit with the requirements related to indoor navigation, management and reservation of parking and access con-trol. Therefore, it was decided to split this model into three parts, to adopt one of the standard map specifications (OSM) for one of them, and to produce two new models from scratch tailored for the

needs:

OSM standard was adopted for describing the city road network and infrastructure, including outdoor facilities and points of interest.

LOCOSLAB, as a specialist in the field, was in charge of producing a new outdoor city map model, oriented to facilitate the navigation and guidance of impaired users inside indoor facilities like stations.

ETRA, as a specialist in parking and access control systems, was in charge of producing a new data model, tailored for the specific needs of for :

o parking validation, status information, reservations and validation (fraud avoidance),

o access control to restricted areas, validation and fraud avoidance



3. OUTDOOR CITY MAP MODEL (OSM)

The outdoor city map model in has two main application areas. On the one hand, it provides the basis to generate a visual representation of the environment thereby simplifying spatial reason-ing. On the other hand, it provides the basis for search and navigation services that enable the user to find places of interest (e.g. certain streets or buildings) and to compute possible routes to them.

3.1. CHOICE OF OSM

At the time of writing, there are several alternative commercial providers of global outdoor infor-mation. Among others, they include Google Inc., Microsoft Cooperation and Nokia. Each of them is operating different websites that make this information accessible to the end user (e.g. Google Maps or Bing Maps). In addition, they provide services on top of the information, e.g. to compute walking or driving routes. However, these providers typically limit the amount of data that can be retrieved by a third party application (such as LEADS). If higher volumes of data are required, the commercial providers are offering enterprise level access at a considerable cost. In addition to com-mercial providers, the OpenStreetMap project is one of the few non-commercial initiatives that is collecting and distributing global geographic information.

In order to ensure that a large number of mobility impaired users can benefit from the services and applications provided in , we have chosen to leverage OpenStreetMap data as the source for geographic information. The main disadvantage of this choice is that the data may not be as com-plete as other commercial data sources. In addition, it is necessary to implement the higher level ser-vices such as routing and map tile generation as part of the work done in . However, on the positive side, due to the participatory nature of the OpenStreetMap project, it may be possible to feed data collected for back into the project. As a result, the data would become available for other application developers as well.

3.2. DESCRIPTION

The OpenStreetMap project (5) is a community-driven data collection project that captures geo-graphic information on a global scale. The data can be provided by individuals as well as public or pri-vate institutions. The collected data is provided free of charge in different formats. Among those formats are an XML-based representation called OSM XML as well as binary representation (PBF). On top of these formats, there are numerous tools that convert the data to different outputs. Daily dumps containing all data as well as differential files containing only the changes can be retrieved from different sources. A list of download sites can be found online in the OSM Wiki at http://wiki.openstreetmap.org/wiki/Planet.osm.

3.2.1. Main Characteristics

Independent from the concrete data format in which data is made available, all formats share a common model. This model consists of three main entities as depicted in Figure 1, namely:

Node: Nodes are representing individual points at a particular location. In order to define the location, the OpenStreetMap project uses WGS84 latitude and longitude coordinates.

Way: Ways are representing an ordered list of nodes. They can be used to model polylines or polygons. In addition, they are used as basis for modelling even more complex shapes.

Relation: Relations are used to model shapes that cannot be modelled using ways alone. A simple example for this are multi polygons (i.e. polygons which must be intersected with each other to create the actual shape).



To create references between these entities, all entities are equipped with a unique id to which other entities can refer. In addition, some formats may expose additional information about the entities such as the creation time stamp, the change set id or version.

Figure 1 - Basic OSM Data Model UML Diagram

While these entities are quite simple and well structured, the true power of the data model actually stems from the fact that all entities can be tagged. A tag in the OSM data model is a key value pair that assigns one or more meanings to the entity. Due to the free-form nature of tags, it is possible to “invent” new tags on the fly to mark new features. However, in order to facilitate the development of automatic tools, there is a common agreement about the meaning and use of different tags. The meaning, together with the best practices for their use, is documented in the OpenStreetMap wiki at http://wiki.openstreetmap.org.

Some examples for common keys of tags are:

Highway: This key represents some form of street. There is a large number of possible values to represent different street types including motorway, residential or footway.

Waterway: This key represents different types of waters such as rivers and streams. Example values are river, stream or canal.

Boundary/admin_level: These keys represent boundaries such as the boundary of a park or country boundaries. There exist different levels in order to represent hierarchies such as country, state, community, district, etc.

Railway: This key represents railway tracks that belong to different vehicle types. Examples for possible values are funicular, light_rail, monorail, etc.

Due to the sheer number of tags and the inherent extensibility of the tags in the OpenStreetMap pro-ject, we refer to the OpenStreetMap wiki for the full details on commonly used tags (c.f. http://wiki.openstreetmap.org).

3.2.2. Integration in SIMON

As indicated previously, a key feature of the OpenStreetMap data is its extensibility. This extensibility is a direct result of the tags (i.e. key-value pairs) which allow the introduction of new keys or values at any point of time. However, the open nature of tags can quickly become a problem when it comes to the development of tools that process the data. Since data might be tagged inconsistently, pre-



senting data often requires complicated pre-processing that applies ad-hoc heuristics (e.g. to clean up object names, etc.).

In addition, due to the sheer amount of data that is available through the OpenStreetMap project, it is not feasible to directly use the complete data set in XML or PBF format in order to create the out-puts needed for ANSWERS and LEADS. Instead, appropriate index structures are needed in order to quickly retrieve relevant information for different services. In , the follow-ing three index structures will be provided:

Address index: In order to enable users to search for streets and buildings, it is necessary to extract the address data and to index it in such a way that relevant search results can be re-trieved in a very short amount of time. Especially when considering mainstream functionality such as “auto-complete search”, results must be generated in the order of hundreds of milli-seconds. Slower searches will likely result in user distraction.

Graph index: In order to enable the computation of routes, the basic graph structure of the road network must be extracted. The resulting graph can then be used to perform standard route searches such as the famous Dijkstra algorithm or more advanced A*-searches. In or-der to support the computation of “by car” and “on foot” routes, the graph must still contain the relevant tags such as the possible traversal direction (e.g. for one-way streets) and the road type (e.g. pedestrian or motorway).

Spatial index: In order to enable sever-based rendering of map tiles, it is necessary to be able to access data that is relevant for a particular region (i.e. the map’s viewport) quickly. To do this, it is necessary to reorganize the data according to the geometric distance of different entities. In addition, in order to prevent overwhelming the rendering engine it is necessary to assign zoom levels to different entities such that details are only fetched when they must be rendered (i.e. at high zoom levels).

On top of these data structures, two main services described in D4.1 ICT Services and Appli-cations (6) are using the OpenStreetMap data. These services are briefly outlined in the following to-gether with the associated data usage:

Geographic Service: In order to generate map tiles for map-based visualizations, the geo-graphic service makes use of the spatial index together with rendering instructions defining which objects to render in which colors. In addition, the place search makes use of the ad-dress index in order to enable the search for important places such as cities, streets or build-ings.

Navigation Service: In order to compute walking and driving routes for the end user and to support the computation of end-to-end transit routes, the navigation service makes use of the address index (to determine the coordinate of the origin and destination of a route) as well as the graph index (to compute the path between the origin and destination).

More details on these services can be found in D4.1 (6).



4. INDOOR CITY MAPS MODEL

The following describes the approach to model indoor environments in such a way that it is possible to provide dynamic visual navigation instructions to users. The primary application area foreseen in at the time of writing is the use of the model to provide additional accessibility details on subway stations. Towards this end, the model must enable the computation of routes be-tween different points of interest that a user may want to reach during a trip. For subway stations, the key points of interest are thereby the different platforms (where the trains are leaving) and the possible entrances to the stations.

4.1. DESIGN PRINCIPLES

As a basis for the provisioning of indoor maps, project is relying on the model introduced by Locoslab Maps. The main reason for selecting this model stems from the fact that other models such as the indoor extensions of the OpenStreetMap project are not widely used and the data required as part of is not available in this format. Consequently, the data required for LEADS and

ANSWERS has to be gathered as part of project and Locoslab provides web-based tools to simplify the data capturing in the target cities when applying the associated model (c.f. ¡Error! No se encuentra el origen de la referencia.).

From a design perspective, the purpose of the environment data model introduced by Locoslab Maps is to enable indoor navigation in a single building (e.g. a shopping mall) or a building complex (e.g. a university campus). The key goal thereby is to minimize the modelling effort in order to support short-lived usages (e.g. at a trade fair) and to support frequently changing environments (e.g. in a museum). The resulting model is well suited for the application in as targets the modelling of subway stations to enable (accessible) end-to-end navigation.

Figure 2 – Web-based Visual Editor for Indoor Maps

To support navigation applications while minimizing the modelling effort, the Locoslab Maps data model requires solely a definition of the relevant maps by means of floor plans that are embedded into a global coordinate system and the definition of possible paths that can be traversed by the user to reach different points of interest. Thus, other objects such as walls or doors, for example, do not have to be modelled. This reduces the modelling effort significantly. In addition, as mentioned previ-



ously and depicted above, the population of the model can be done visually using drag-and-drop via a web-based tool.

4.2. DESCRIPTION

To be applicable to different environments, the data model of Locoslab Maps introduces a number abstractions detailed in the following. Think of them as the entities of the indoor environment mod-el. ¡Error! No se encuentra el origen de la referencia. below shows an overview of the main classes as well as their relations.

Figure 3 – Indoor Model UML Diagram

In the following, we briefly provide a short description of the purpose and scope of each of these en-tities.

Project: A project is the top unit of encapsulation that indirectly references all other ele-ments of the model. It represents a building complex that is relevant to an application at a particular time. From an application's perspective, the project is an atomic unit, meaning that the application always retrieves the complete project which guarantees a consistent view and minimizes communication. Projects can be cached temporarily or permanently by appli-cations in cases where the represented environment changes infrequently or where it is guaranteed to never change. Applications may use multiple projects at a time; however, in



this case the physical link between the projects will typically be established through other means. An example for this is an embedding of two Locoslab Maps projects into Locoslab Carta or other outdoor map providers.

Area: An area typically represents a particular zone of interest such as a single building or a (typically small) outdoor zone (e.g. an entrance area or a restaurant area). Just like most buildings, an area can consist of multiple floors at different heights. Thereby, it is important to mention that Locoslab Maps does not model these heights in 3D space. Instead, it uses a layered 2D model in which floor levels are represented as integers. Clearly, this model is less expressive, however, it also reduces the modelling effort significantly and it simplifies the visual representation in an application.

Layer: A layer represents a single plan for an area. For buildings, this is typically the floor plan for a particular level. Each layer defines its own geometric embedding into the modelled en-vironment by means of three anchor points. In addition, a layer may provide several graph-ical representations by defining images (see definition below). These images may differ in their resolution and content, for example, to model different zoom levels with varying de-grees of abstraction but they will model the same basic plan in terms of relative positioning. In other words, the bounds of the images are covering the same space in the modelled envi-ronment.

Image: An image is a visual representation of a layer of a particular type with certain dimen-sions. Currently, Locoslab Maps supports solely bitmap-based images whereby the size is measured in pixels. Since there are multiple common bitmap formats such as jpg, png or gif whose file name endings may vary (e.g. jpeg or jpg), the image types are uniquely identified by their media type (mime type).

Point: A point represents a particular point on an image. To support the image-independent addressing in multiple images with varying resolutions, the point is expressed as x and y val-ues ranging from 0 to 1 (both inclusive). As in many graphics libraries, the origin (0, 0) repre-sents the top left corner and (1, 1) represents the bottom right corner.

Coordinate: A coordinate represents a GPS coordinate. It consists of a latitude and longitude in WGS84. The latitude runs from -90 (South) to 90 (North) and the longitude runs from -180 to 180. The wrap around of longitudes lies in the Pacific Ocean.

Anchor: An anchor represents a mapping between a point and a coordinate, meaning that a particular point is located at a particular coordinate.

Place: A place represents point of interest at a certain location in the modelled environment. A place is defined by a coordinate and it is tied to a particular layer.

Path: A path can be thought as the indoor counterpart to outdoor streets as it represents a certain way that can be taken by a user to move around in the environment. Each path is tied to a particular layer and it is implemented as a series of coordinates. Paths can be defined as being unidirectional or bidirectional. Paths are used internally by Locoslab Maps to answer navigation queries. Inside applications, they can be used to create abstract visualizations of a building complex to reduce outliers or to improve the visualization (e.g. by mapping the de-vice's location to the nearest point on a path).

Link: A link can be thought of as a more powerful type of path that only consists of two points (a source and a target). In contrast to paths, however, links can start and end in differ-ent layers. This enables the linking and navigation across layers. Just like paths, links can be either unidirectional or bidirectional. In addition, they have a link type that defines the type of transition offered by them. Some examples include ramp, passage, stairway, escalator, el-evator, etc. The link type can be used to provide different visualizations for the different type



of links and it is used internally in navigation queries to compute alternative or accessible routes.

As indicated previously, Locoslab Maps make use of two coordinate systems (i.e. Point and Coordi-nate) in order to embed floor plans consisting of bitmap-based images at different resolutions into the global GPS coordinate system (i.e. WGS84). To do this, each layer encompasses the definition of three anchor points. Each anchor point consists of one point with one corresponding GPS coordinate. Together the three points form a triangle that can be used to compute a transformation from one coordinate system to the other. This transformation will perform the necessary rotation, translation, scaling and sheering.

Figure 4 – Coordinate Transformation Utilities UML Model

The classes depicted in ¡Error! No se encuentra el origen de la referencia. enable developers to de-rive a transformation without knowing the underlying math. By passing the anchors into a function, the API classes compute the necessary transformation matrix which can then be used to get a coor-dinate for a point or a point for a coordinate. However, since points are pixel- and thus scaling-independent relative values, they need to be multiplied by the image width and height:

xpixel = xpoint * width and ypixel = ypoint * height

Similarly, in order to convert a pixel into a GPS coordinate, developers need to divide the pixel by the width and height to derive the corresponding scale-independent point before passing it into the transformation:

xpoint = xpixel / width and ypoint = ypixel / height.

Further details on the Locoslab Maps data model and the associated APIs can be found on Locoslab’s developer web pages at http://developer.locoslab.com/trac.



5. PUBLIC TRANSPORT MODEL (GTFS)

In order to provide information about public transportation as part of LEADS and AN-SWERS, the project is relying on the General Transit Feed Specification (GTFS) in order to capture in-formation about the transit networks in different cities.

5.1. CHOICE OF GTFS

The main rationale for relying on GTFS as the data source for public transport network information is its wide availability. The reason for this stems from the fact that Google Inc. is relying on this data format in order to capture the necessary input data for Google Transit (which is an integral part of their very popular and widely used Google Maps service). All target cities in are already inte-grated in Google Transit and thus, they already have their transit data converted to this format. Con-sequently, by relying on GTFS as basis for transit data, not only reduces the integration effort of the targeted solution but also ensures that the resulting solution can be easily adopted by other cities as well. To clarify this consider that the Google Transit Data Feed project on Google code https://code.google.com/p/googletransitdatafeed/wiki/PublicFeeds lists more than 250 agencies that are providing their network data to the general public. In addition, the GTFS format optionally enables the specification of wheelchair accessibility features, which makes this format a good basis for accessibility-aware transit routing.

5.2. DESCRIPTION

Conceptually, transit data in GTFS format can be thought of as simple relational database provided as a ZIP file whose tables are specified as CSV files (i.e. comma separated values) contained in the ZIP. Thus, it is possible to think of the CSV files as entities in an entity-relationship diagram. However, it is noteworthy that some entities (such as “Service”) for example are not providing any additional data and thus, they do not have their own table (or CSV file). Instead, they are only referenced by other entities.

5.2.1. Main characteristics

The following enumeration lists the possible files contained in a ZIP file that is formatted according to the GTFS format (taken from https://developers.google.com/transit/gtfs/reference). Some of the files are not necessary to enable routing and thus, they are marked optional.

agency.txt (required): One or more transit agencies that provide the data in this feed.

stops.txt (required): Individual locations where vehicles pick up or drop off passengers.

routes.txt (required): Transit routes. A route is a group of trips that are displayed to riders as a single service.

trips.txt (required): Trips for each route. A trip is a sequence of two or more stops that oc-curs at specific time.

stop_times.txt (required): Times at which a vehicle arrives at and departs from individual stops for each trip.

calendar.txt (required): Dates for service IDs using a weekly schedule. Specify when service starts and ends, as well as days of the week where service is available.

calendar_dates.txt (optional): Exceptions for the service IDs defined in the calendar.txt file. If calendar_dates.txt includes ALL dates of service, this file may be specified instead of calen-dar.txt.

fare_attributes.txt (optional): Fare information for a transit organization's routes.



fare_rules.txt (optional): Rules for applying fare information for a transit organization's routes.

shapes.txt (optional): Rules for drawing lines on a map to represent a transit organization's routes.

frequencies.txt (optional): Headway (time between trips) for routes with variable frequency of service.

transfers.txt (optional): Rules for making connections at transfer points between routes.

feed_info.txt (optional): Additional information about the feed itself, including publisher, version, and expiration information.

As explained previously, these files are not a complete list of all entities as some entities are purely virtual. Thus, converting these CSV files into entities, results in the model depicted in ¡Error! No se encuentra el origen de la referencia.:



Figure 5 – GTFS UML Model

More details on the GTFS format can be found on the GTFS Specification page (7)



5.2.2. Integration in SIMON

Although GTFS is a simple textual format, humans cannot easily process it. The reason for this is that it strives from minimal duplication of data resulting in a relational format with references between the files. Consequently, in order to make the data accessible to users, it is necessary to extract rele-vant parts such as the departure times of a particular line at a particular stop, for example. In addi-tion, GTFS does not provide details about consecutive trips and thus, there is a need for additional services that present the GTFS information differently. In particular, ANSWERS encompasses two main services that leverage the public transport information. Both services have been discussed in D4.1 ICT Services and Applications (6) already, thus, we only outline their functionality in the fol-lowing:

Navigation Service: In order to compute end-to-end routes that leverage public transporta-tion, the navigation service makes use of the GTFS information (i.e. trips, stop times, routes, etc.). Thereby, it might select partial trips (i.e. trips that start and end at intermediate stops) and combine multiple trips (i.e. first line 17 then line 31) to reduce the overall duration of a user trip. It is noteworthy that this route computation may have to take multiple GTFS ZIP files from different providers into account.

Information Service: In order to provide information about the public transport network to the user it is necessary to extract individual parts from the different GTFS ZIP files such that they can be presented in a more meaningful manner. In particular, the information services related to lines, stops and stop times described in D4.1 (6) are using GTFS formatted data as input for their outputs.



6. PARKING AND ACCESS CONTROLLED AREAS MODEL


The conceptual model for parking and access controlled areas model needs to fit with the following requirements:

Identify what are the parking spaces and access controlled areas, and where they are locat-ed.

Use identifiers that are common with the external systems that work with the entities:

o Park meters

o Parking control systems

o Access control system

Represent the occupancy status of the spaces, and/or the number of available spaces in an area.

Cover the different kind of parking spaces considered for : on-street parking, car parks and spaces reserved for being used only by mobility impaired people.

Take into account the limitations of the information sources available at the different scenar-ios.

Represent whether the spaces can be booked and if they are currently available for booking.

Existing models like OpenStreetMaps (OSM) include information about car parks or individual parking spaces, but they do not fit with the requirements associated to the real time occupancy status infor-mation or the booking of spots. Furthermore, they have not been adopted by the local authorities of the pilot sites, so adopting one of them in would not have facilitated the procedural nor the technical integration required by the demonstrations. As a consequence, the disadvantages associat-ed to the extra technical complexity caused by openness and wide range of OSM features do not bal-ance with the few benefits it would have provided to .

The decision taken was to design a new model from scratch, tailored for the requirements of and implemented in the most optimal way from a technical point of view.

One of the above mentioned requirements is to take into account the limitations of the information sources and has had a very important impact in the design of the conceptual model for parking spac-es.

In particular, it was necessary to consider that:

Only in some cases the position of individual parking spots is known. This happens especially for spots reserved for use only by mobility impaired citizens. However, in most of the cases the position of individual spots is not known and the only information available is that they belong to a more or less wide areas:

o Sometimes they belong to small areas formed by spots that are contiguous or near to each other (parking lots),

o Sometimes they belong to closed areas accessible through entries and exits (car parks).

o Sometimes they are known to be scattered inside wide areas (zones)

In some cases, the occupancy status of individual parking spots is managed and provided in real time by parking control systems or devices. It is the case of car parks that are equipped with occupancy sensors in each spot. The usage of the application by mobility im-



paired users for validating the usage of reserved spaces also allows the applications to estimate the status of the spots. However, for all the other cases this information is not available.

In some cases, the information available in a city about occupancy of parking spaces is aggre-gated at the level of a more or less wide area. It is the case for car parks equipped with de-vices counting the number of vehicles entering and leaving the parking, and also the case for on-street parking areas equipped with park meters controlled by systems capable of produc-ing estimations of the number of occupied in the area based upon the tickets sold.

The conceptual model for parking spaces has been designed with the necessary flexibility for covering all those different scenarios, and allowing services to work with the most detailed (granular) information available in each case.

From the point of view of methodology, this model has been designed using UML domain model class diagrams, which facilitates the definition of the concepts and the representation of the rela-tionships between them. Among the features of UML, the possibility of defining inheritance relation-ships and associations were highly appreciated.

6.2. DESCRIPTION

The concepts covered by this model can be classified in 3 main packages:

Basic entities: the classes defined in this group include concepts that are common to many of the specific classes in the other two groups, like positions, shapes, administrative divisions, devices, etc.

Parking spaces: specific concepts related to parking management functionality.

Access controlled areas: specific concepts related to access control functionality.

6.2.1. Basic entities

The entities belonging to this category are common concepts used by many of the different entities of the other categories. The intention with these base classes is to facilitate the development of

integration software modules, by allowing them to reuse functionality implemented for the common tasks associated to the basic entities. For example, a piece of code for interpreting the shape of a zone can be reused for any entity that inherits from zone, either a parking lot, a parking zone or an access controlled zone.

6.2.1.1. Locations

The concepts represented in Figure 6 cover two basic requirements: to identify each individual entity and to specify where it is located. The most basic class of this package is Location. Every entity that represents a place in the city inherits from Location. Each location instance:

Has a primary key (unique identifier)

Must belong to exactly one City (see below)

May belong to one or zero Neighbourhoods (see below)

There are two main specialisation of Location, the classes Position and Zone:

A Position is a location defined by a single position in the map, expressed as GPS coordinates (if available) by means of a GPSPosition object (see section 6.2.1.2)

A Zone is a location that covers a more or less wide area in the city map, defined by its shape (if available) expressed by means of a Shape object (see section 6.2.1.2).



Figure 6 - UML class diagram for Locations

The class CityArea is a specialisation of Zone intended to be the basic class for any administrative subdivision of a city. The attributes of a CityArea are:

Id: A numeric identifier that is unique within the city

Name: the name of the division or a descriptive text

Two levels of administrative divisions have been considered for , as this is the maximum number of levels used by the authorities of the pilot sites. These are Neighbourhood and District. Each Neighbourhood may belong to zero or one District and each District defined might contain any number of Districts. Both classes inherit from CityArea.

The class City is intended to represent each of the pilot sites in the project, and its attributes are a unique numeric identifier and a name.

6.2.1.2. Shapes

As mentioned in section 6.2.1.1, many entities in parking spaces and access controlled areas data model are locations defined by its position or its shape. This package contains the classes asso-ciated to these concepts.

class Locations

Loca tion

+ PK: long

Posi tion

Neighbourhood

+ id: int

+ name: string

City

+ id: short

+ name: string

CityArea

+ id: int

+ name: string

District

+ id: int

+ name: string

Zone

Shapes::ShapeShapes::

GPSPos ition

+ longitude: float

+ latitude: float

+ altitude: float

+locations

0..*

+neighbourhood

0. .1

+shape 0. .1+gpsPosition 0. .1

*

+city

1 +neighbourhoods

1. .*+district

0. .1



Figure 7 - UML class diagram for Shape entities

A point in the map is represented by the GPSPosition class, whose attributes are the coordinates of the map in the WGS84 system. This coordinates system was chosen because it is adopted by the most commonly used positioning systems in the market, including GPS.

The class Shape is the basic class for representing the shape of a Zone. Three specialisations of Shape have been considered:

CircleShape, defined by a centre (expressed by means of a GPSPosition object) and a radius in meters,

PolygonShape, defined by the sequence of points of its contour (expressed as GPSPosition objects),

MultiPolygonShape, an aggregation of PolygonShape objects.

6.2.1.3. Closed zones

Car parks and access controlled areas have a common characteristic: they are closed zones and may have entrances or exits at particular positions. A set of basic classes have been defined for represent-ing these common concepts:

class Shapes

GPSPos ition

+ longitude: float

+ latitude: float

+ altitude: float

Sha pe

Circle Shape

+ radius: float

PolygonShape MultiPolygonShape+polygons

1. .*

+center

1

+points

3..* {ordered}



Figure 8 - UML diagram for closed zones

ClosedZone is a specialisation of Zone intended to be the basic class for all closed zones that have a set of accesses that can be used as entrances to or exits from the closed zone (or both). Both ParkingLots (see section 6.2.2) and AccessControlledZone (see section 6.2.3) are specialisations of ClosedZone.

The class Access represents each of the accesses to a ClosedZone. Each Access belongs to exactly one ClosedZone, which in turn can have zero or more Accesses defined. Access inherits from Position, what implies that it is characterized by a single GPS position. ControlledAccess is a specialisation of this class (see section 6.2.3).

6.2.1.4. Devices and systems

As shown in Figure 9, two kinds of equipment are considered for their integration is : park meters and access control devices. For each kind of device, the same kind of controlling system is al-so considered.

The class Device is the base class for all devices. Its attributes are:

id: a unique numeric identifier,

name: a descriptive text,

address: a sequence of characters that identifies the device within the system it belongs to, and allows the adaptor for the system to refer to the individual device when interact-

class ClosedZones

Close dZone

Access

+ entrance: boolean

+ exit: boolean

Locations::Zone

Locations::

Posi tion

AccessControlledZone

ControlledAccess

ParkingSpotsCluster

Parking::ParkingLot

+ id: long

+ descriptio n: string

+accesses 0..*

+zone

1



ing with the system. The actual content of this field depends on the particular system and device and is an implementation detail.

The DevicesSystem class is intended to represent each of the external systems to be integrated in project for the management of parking validations and access control. The attributes of a De-

vicesSystem are:

id: a unique numeric identifier,

name: a descriptive text,

address: a sequence of characters that identifies the device in the network or ecosystem of services in the city. The actual content of this field depends on the particular system and is an implementation detail. An example of possible content is a URI.

Figure 9 - UML class diagram for devices and systems model

Each Device belongs to one and only one DevicesSystem. Each DeviceSystem belongs to one and only one city. The specialisations of Device defined in the model are ParkingControlDevice (see section 6.2.2) and AccessControlDevice (see section 6.2.3).

6.2.2. Parking spaces

As mentioned in section ¡Error! No se encuentra el origen de la referencia., the conceptual model for parking spaces has been designed with the necessary flexibility for covering different sce-narios of availability of information. The classes defined in the model are useful or not depending on the particular scenario and their optional attributes may contain data or not depending on the case.

class Dev ices

Dev ice

+ id: int

+ name: int

+ address: string

ParkingControlDev iceAccessControlDev ice

+ controlsEntra nce: boolean

+ controlsExi t: boolean

ParkM eterBarr ier

Location

Locations::

Posi tion

NumberPla teReader

Dev ices System

+ id: long

+ name: string

+ address: string

Locations::City

+ id: short

+ name: string

+position

1

+position1

+position

1

+devices

*

+system

1

+city 1



Due to the number of classes in the model, details about the attributes of each one are not provided in this section and can be found at ¡Error! No se encuentra el origen de la referencia. Annex B.

Figure 10 - UML diagram for parking spaces model

The classes in this package have attributes of two kinds: static and dynamic. Static attributes are characteristics of the entity that are very unlikely to change, like the position or whether it is re-served for mobility impaired users or not. Dynamic attributes describe the status of the entity and may be updated in real time in case there is a valid data source capable of providing the correspond-ing information. Examples or this are the number of available free spaces in a zone. Most of the dy-namic attributes are optional, because they shall have a value only when some data source has been able to provide it.

A ParkingSpot represents an individual parking space that can be used by a single vehicle. It inherits from Position class (see section 6.2.1.1), because it is assumed to be located at a single point position regardless of if it is known or not.

The static attributes of a ParkingSpot provide:

o The identification of the spot, the description of where it is located and its physical characteristics (length, width)

o The kind of parking space (on street, private car park)

o Whether it is reserved for use by mobility impaired citizens only

o Whether it can be booked

The dynamic information includes:

o The occupancy status

o The booking status

It is not necessary to define each parking spot as an individual entity in the model. In fact, it is con-venient only if:

class Parking

ParkingSpot

+ id: long

+ address: string

+ label: string

+ type: int

+ width: float

+ length: float

+ isOnlyForDisab led: boolean

+ isOccupied: b oolean = false

+ canBeBooked: b oolean = false

+ isBooked: bo olean = false

ParkingLot

+ id: long


ParkingZone

+ id: int

+ name: string

+ numberOfFreeSpots: int

+ numberOfFreeDisableOnlySpots: int

+ numberOfBookedSpots: int

+ numberOfBookedDisabledOnlySpots: int

+ numberOfBookableSpots: int

+ numberOfBookableDisabledOnlySpots: int

ParkM eter

ParkingSpotsCluster

+ numberOfSpots: int

+ numberOfDisabledOnlySpots: int

Device

ParkingControlDev ice

Location

Posi tion

Location

ZoneClose dZone

BookingStatus

+ bookedSin ce: Time

+ bookedUnt il: Time

+position

1

+zones 1. .*

+controlDevice0..*

+lots

1. .*

+zone

0. .1

+bookingStatus 0. .1

+lot

+spots

0..*

+zone

0. .1



The exact position of the parking spot is known, or

The occupancy or booking status of the individual parking spot in real time is available

In all other cases, the parking spots are better represented by means of the number of spots attrib-utes of classes ParkingLot or ParkingZone.

A ParkingLot is a specialisation of the ClosedZone class (see section 6.2.1.3) that is an aggregation of several parking spaces that are contiguous or near to each other, and is useful whenever one of the following conditions is fulfilled:

The exact position of each individual spot is not known, but the shape of the parking lot is known, or

The spots are inside a closed zone (like a car park) and the position of the entrances and/or exits of the zone is known

A ParkingLot object has no dynamic information attributes. The static information attributes include:

The identification of the lot and the name or description of where it is located

The kind of parking (on street, private car park)

The number of spots that it contains

The number of spots that it contains and that are reserved for use by mobility impaired citi-zens only.

Each ParkingSpot may belong to one or zero ParkingLots, and a ParkingLot may be associated to any number of ParkingSpot objects, but this number must be always equal or less than the value of the corresponding number of spots attribute. In other words, if an individual spot belongs to a lot, it must be also included in the accountings for the lot.

Practical examples of uses of the ParkingLot class are car parks, and also rows of parking spots at the side of a road.

A ParkingZone is a specialisation of the Zone class (see section 6.2.1.1) that represents the smallest aggregation of parking spaces for which the available system(s) in the city can provide dynamic real-time information about availability, occupancy or booking.

The static information attributes of a ParkingZone provide:

The identification of the zone and a description

The kind of parking (on street, private car park)

The number of spots that it contains

The number of spots that it contains and that are reserved for use by mobility impaired citi-zens only.

The number of spots that can be booked

The number of spots that can be booked and are reserved for mobility impaired users.

The dynamic information attributes, if available, provide:

The total number of free spaces available in the zone

The total number of free spaces available in the zone that are reserved for mobility impaired citizens

The total number of booked spaces in the zone, for each kind of parking space

Defining ParkingZones is useful only when:



There is no available information about parking lots or individual parking spots, but there is information about the number of spaces per zone.

The dynamic information available in real time about occupancy status of parking spaces, or the booking functionality, is available in an aggregated way at the level of a zone.

One or more parking control devices are controlling the parking spots in the zone.

Each ParkingSpot may belong to one or zero ParkingZones, and a ParkingZone may be associated to any number of spots, but this number must be always equal or less than the value of the correspond-ing number of spots attribute. In other words, if an individual spot belongs to a zone, it must be also included in the accountings of the zone.

Each ParkingLot may belong to one or zero ParkingZones, and a ParkingZone may be associated to any number of lots. If a ParkingLot belongs to a ParkingZone, its accountings of parking spots must be included in the accountings for the zone.

Car parks that are equipped with devices and/or controlled by systems capable of providing the ac-counting of free spots for the whole car park fit well both with the concept of ParkingZone and ParkingLot (closed zone entries or exits). For them, the recommendation is to represent each one with both a ParkingLot and ParkingZone with a 1 to 1 relationship between them.

Both ParkingZone and ParkingSpot inherit from ParkingSpotsCluster, which provides the common static attributes providing the number of spots in the entity.

Each ParkingZone may be associated to one or more ParkingControlDevice objects. The ParkingCon-trolDevice class is a specialisation of Device that manages the association with the parking zone or zones controlled by each device.

ParkMeter is a specialisation of ParkingControlDevice that is physically located at a known Position.

6.2.3. Access controlled areas

An AccessControlledZone is a specialisation of the ClosedZone class representing a restricted area for which the access of vehicles is controlled, what means that an extra charge or a fine is imposed to unauthorised users of vehicles entering the area or moving inside it.

Each of the entrances or exits to the restricted zone shall be modelled by an object of the class Con-trolledAccess, which is a specialisation of Access that can be optionally associated to an AccessCon-trolDevice. The attributes or ControlledAccess indicate if it is an entry, an exit or both.



Figure 11 - UML diagram of the Access controlled areas model

The relationship between the AccessControlledZone and its ControlledAccess is managed by the properties and relations inherited from ClosedZone and Access respectively.

An AccessControlDevice is a specialisation of Device associated to the restricted areas functionality, and it manages the relationship with any number of AccessControlledZones and AccessControlledAc-cesses. Each ControlledAccess may be associated to zero or one AccessControlDevices and each Ac-cessControlledZone may be associated to one or more AccessControlDevices.

As depicted in Figure 9 (section 6.2.1.4), there are two specialisation of AccessControlDevice: Barri-ers and NumberPlateReader. The only difference is conceptual: the former is for devices that physi-cally block access until the user is successfully identified and/or authorised, and the second for de-vices that read license numbers of vehicles that can be charged or fined if not authorised.

class ClosedZones

Close dZone

Access

+ entrance: boolean

+ exit: boolean

Locations::

Posi tion

Device

Dev ic es::

AccessControlDev ice

+ controlsEntra nce: boolean

+ controlsExi t: boolean


ControlledAccess+accesses

1. .

+controlDevice

0. .1

+controlDevices

1. .*

+zones1. .*

+accesses 0..*

+zone

1



7. USERS AND SECURITY TOKENS MODEL


The different applications and services need to have a common way to manage the registra-tion of users and the security tokens used for verifying their identity. Some specific restrictions also apply:

The system should manage the minimum possible personal information required for the functionality, for privacy and security reasons.

The local authorities must have the control on the registration status and the rights granted to each user, and must be able to cancel them or reactivate them at any time.

There is a variety of different personal identification items (security tokens) considered, in-cluding EU badges, RFIDs of NFC devices and mobile phone numbers, what means that the information model must be flexible enough to support all them and should be able to incor-porate new types in the future.

The local authorities must have control on the particular security tokens accepted, and must be able to allow them or restrict their use at any time, individually or per type. This is espe-cially important for the security tokens emitted by the authorities themselves, like the EU badges.

There are three main profiles of users to consider:

o Mobility impaired citizens, or persons that assist them and move across the city with them

o Parking controllers, that check the right to park of the vehicles on street

o Authority operators, that manage the registration of users and display usage or performance reports.

With these requirements in mind, the data model for users and security tokens has been designed with three main characteristics:

There must be a class for representing each individual user

Each individual user must belong to a single user profile, that identifies his type and his privi-leges

Each user must have a set of one or more security tokens assigned, and those tokens may be of different types.



7.2. DESCRIPTION

Figure 12 - UML diagram of the users and security model

The class User represents and individual user of . The attributes of the class are:

Id: unique identifier of the user in the data model. Its value may be significant only within , or may have another meaning (personal ID card, record ID in authority data-bases, etc.). It must be immutable.

Username: user name that the person may use when logging in or identifying himself in applications. It does not need to be coincident with his name or family name, and can

be a nickname.

Password: password that the user may use for logging in applications.

Identity: optional text attribute that may contain a personal ID of the user, and that is in-tended to facilitate the procedural coordination between the operators in charge of the reg-istration of users in database and the officers of the authority that decides what us-ers must be registered. This ID may be a personal ID card, a record ID in authority databases, etc.

IsActive: boolean value indicating whether the user is registered and active. Changing this value to false allows temporarily deregistering the user without deleting his data.

ActiveSince: time and date since when the user is registered and active.

InactiveSince: time and date since when the user is inactive (unregistered)

Profile: reference to the UserProfile assigned to the user. It determines the privileges granted to the user.

class Users

Us er

+ id: string

+ username: string

+ password: string

+ identity: string

+ isActive: bo olean = true

+ activeSince: TimeStamp

+ inactiveSince : TimeStamp

«enumeratio...

UserProfileKind

«enum»

citi zen

controller

operator

SecurityToken

+ id: long

+ token: string

+ expired: boolean

+ creationDate : TimeStamp

+ expirationDate: TimeStamp

UserProfile

+ id: short

+ name: string

+ comment: string

«enumeration»

SecurityTokenType

«enum»

RFID

PhoneNumber

PhoneDe viceId

QRCode

Locations::City

+ id: short

+ name: string

+securityTokens

1. .*

+owner1

+profile 1

+kind 1

+type 1

*

+city

0. .1



City: reference to the City (see 6.2.1.1) to which the user is associated. It allows make the us-er privileges applicable only for that city.

The class UserProfile allows defining different kinds of user profiles. Each profile has a numeric iden-tifier and a name, and a kind of profile that determines the associated privileges. The kinds of profiles considered are ‘citizen’, ‘controller’ and ‘authority operator’.

The objects of the class SecurityToken represent each of the security tokens that can be used within applications and services to verify the identity of each user. The attributes of this class are:

Id: numeric identifier

Token: string representation of the token (e.g. the actual RFID or phone number)

Type: type of token. Supported types are:

o RFID of the NFC (or similar technology) device attached to the EU badge

o PhoneNumber: phone number

o PhoneDeviceId: IMEI or similar unique identifier of the phone device

o QRCode: value of the QRCode printed on the EU badge

Expired: boolean value indicating that the token has expired and its use is not allowed any more

CreationDate: creation (registration) date of the token

ExpirationDate: expiration date of the token



8. EVENT DATAMODEL


The main goals of project are to evaluate different strategies for fraud control and to facili-tate the urban mobility of impaired users. In order to do so and also to assess the relevance of

and the accomplishment of the project objectives, it is crucial to make a statistical analysis of the usage of the services and applications by the citizens, the infractions detected by controllers and other kind of relevant events registered during the pilot site demonstrations.

For this purpose, the storage of the events in a logging subsystem is essential. As the different appli-cations and services of must register events that the authority operator application must in-terpret and process, the existence of a common data model for events is required.

Several specific event types have been identified during the specification phase, and for them a spe-cifically tailored model has been built from scratch, in such way that it provides maximum consisten-cy with other data models.

The model is complemented and made extensible with the definition of a “generic event” represent-ing other kinds of event that may occur. These events are very likely to be managed and stored by means of existing and widely used logging software libraries, such as, for example, log4j, so it was decided to model generic events in in a similar way to how those libraries do.



8.2. DESCRIPTION

8.2.1. Specific event classes

Figure 13 - UML diagram of specific events model

The following event classes have been defined:

Class UserValidationEvent:

o Description: record of an attempt (either successful or not) of validating the identity of a user by means of security tokens.

o Attributes: unique id (pk), success or error status, timestamp, type of validation (purpose: user login, parking validation, etc.) and user (if one identified)

o Relations:

A user validation can be associated to zero (if no user is identified by the to-kens) or one User (see section 0).

Parking validations and access control validations are always associated to one and only user validation.

A user validation contains zero or more UserValidationToken objects.

class Ev ents

UserValida tionEv ent

+ pk: long

+ status: short

+ timestamp: TimeStamp

+ type: short

Users::User

+ id: string

+ username: string

+ password: string

+ identity: string

+ isActive: bo olean = true

+ activeSince: TimeStamp

+ inactiveSince : TimeStamp

ParkingValidationEv ent

+ pk: long

+ type: short

+ beginTimeStam p: TimeStamp

+ endTimeStamp : TimeStamp

+ endMode: short

UserValida tionToken

+ status: short

+ type: SecurityTokenType

+ token: string [0..1]

«enumeration»

Users::

SecurityTokenType

«enum»

RFID

PhoneNumber

PhoneDe viceId

QRCode

Users::Sec urityToken

+ id: long

+ token: string

+ expired: boolean

+ creationDate : TimeStamp

+ expirationDate: TimeStamp

Locations::

Loca tion

+ PK: long

Shapes::

GPSPos ition

+ longitude: float

+ latitude: float

+ altitude: float

Device

Dev ic es::

ParkingControlDev ice

AccessControlValidationEv ent

+ pk: long

+ beginTime: TimeStamp

+ endTime: TimeStamp

+ licensePlate: string

+ localSystem Id: string

ParkingInfraction

+ pk: long

+ instant: TimeStamp

+ reason: short

+ comment: string

+ licensePlate: string

+ since: TimeStamp

+ citizenToke n: string

+ vehicleType: short

+ vehicleBrand: short

+ vehicleColor: short

+ address: string

Close dZone

ClosedZones::


+type1

+userValidation

1

+location 0. .1

+userPosition0. .1

+device0. .1

+userid

1

+tokenValidations

0..* 1

+type1

+userid

0. .1

+securityTokens1. .*

+owner

1

+citizenTokenType

0. .1

+zone1

+userPosition

1

+userid1

+userValidation 1

+location

0. .1

+controllerid 1

+controllerPosition

0. .1

+tokenpk 0. .1



Class UserValidationToken:

o Description: this class allow registering the tokens used in each user identity valida-tion attempt.

o Attributes:

Success or error status, token type and, if one identified, reference to the registered token.

o Relations:

A UserValidationToken belongs to one and only one UserValidation.

A user validation contains zero or more UserValidationToken objects.

A UserValidationToken can be associated to zero or one SecurityToken ob-jects (see section 0).

Class ParkingValidationEvent:

o Description: record of a successful validation of the usage of a parking spot by a mo-bility impaired user.

o Attributes: unique id (pk), success or error status, begin time, end time, parking loca-tion, GPS coordinates or the user (if available), parking control device used (when applicable), type of validation (reserved space, non-reserved space), user validation and user.

o Relations:

A ParkingValidationEvent is associated to one and only one UserValidation-Event, and one and only one User (see section 0).

A ParkingValidationEvent is associated to one and only one Location (see section 6.2.1.1).

A ParkingValidationEvent may be associated to zero or one ParkingCon-trolDevice (one if the validation is made by means of a park meter)

Class AccessControlValidationEvent:

o Description: record of a successful validation of the access to a restricted area by a mobility impaired user.

o Attributes: unique id (pk), success or error status, begin time, end time, parking loca-tion, GPS coordinates or the user (if available), parking control device used (when applicable), type of validation (reserved space, non-reserved space), user validation and user.

Class ParkingInfraction:

o Description: record of invalid or fraudulent use of a parking space registered by a parking controller; the registration of this event is completely unrelated with any ac-tual infraction procedure against the offender, what is completely out of the scope of

.

o Attributes: unique id, controler’s user id, infraction record instant, reason code, comment, licensePlate of the vehicle, instant when the vehicle was first seen at the parking spot, security token of the EU badge (valid or fake) found at the vehicle windscreen (if any), characteristics of the vehicle, location of the vehicle.

o Relations:



Each ParkingInfraction is associated to one and only one User object (see section 0) representing the controller that registered the infraction.

Each ParkingInfraction may be associated to zero or one Location (see sec-tion 6.2.1.1).

8.2.2. Generic event class

Figure 14 - UML diagram of the generic event model

The most widely used event logging software libraries support generating log events with most of the attributes of the GenericLogEvent class:

Instant of the event

Category of the event

Level (error, warning, information, detail, debug)

Source module that produces the event

Description: text explaining the details about the event

ExtraData: additional text containing details about the event

class Ev ents

GenericLogEv ent

+ instant: TimeStamp

+ category: string

+ level: string

+ sourceModule: string


+ extraData : string



9. CONCLUSIONS

Deliverable D3.2 depicts the results of the effort spend in task T3.2, devoted to ensuring the interoperability between the different applications, services and systems that shall be integrated within project.

The section 2 reasons the great importance of interoperability in , detailing the specific project requirements and providing an overview of the designed solution. This solution has consisted in adopting two well-known widely information models (OSM for outdoor maps and GTFS for public transport), and designing specifically tailored models for other needs (indoor maps, parking spaces, access controlled areas, users and security, logging).

The convenience of adopting OSM and GTFS is reasoned in the corresponding sections of this document, as well as the aspects related to its relevance for the project and the considerations and actions made for integrating.

The reasoning of the design principles and an overview of each of the new models produced by has been provided. Extended details can be found in the annexes of this document.

In summary, task T3.2 has succeeded in providing the interoperability solutions required by , including the suitable information model, which is conveniently described by the present deliverable. Therefore, it has been ensured that WP4 can proceed with the work for integrating applications and services.



10. REFERENCES AND ACRONYMS

10.1. REFERENCES

1. SIMON Consortium. D3.1 Reference Architecture and Principles. Brussels : s.n., 2014.

2. —. D3.3 ICT Services specification. 2014.

3. —. D2.2 Preliminary Set of Requirements. Brussels : s.n., 2014.

4. —. D2.3 Requirements Specification. Brussels : s.n., 2014.

5. OpenStreetMap Project. OpenStreetMap Project Homepage. [Online] 2014. http://www.openstreetmap.org.

6. SIMON Consortium. D4.1 ICT Services and Applications. 2015.

7. Google Inc. General Transit Feed Specification. [Online] 2014. https://developers.google.com/transit/gtfs/reference.

10.2. ACRONYMS

Acronyms List

API Application Programming Interface

CSV Comma Separated Values

EU European Union

GPS Global Positioning System

GTFS General Transit Feed Specification

IMEI International Mobile Equipment Identity

NFC Near Field Communication

OSM OpenStreetMap

PBF Protocolbuffer Binary Format

QRCode Quick Response Code

RFID Radio-frequency Identification.

UML Unified Modeling Language

URL Uniform Resource Locator

WGS84 World Geodetic System 1984

XML eXtensible Markup Language



ANNEXES

I. ANNEX A – DETAILED DESCRIPTION OF INDOOR CITY MAPS MODEL

Package com.locoslab.api.data.maps

public class com.locoslab.api.data.maps.UniqueObject implements com.locoslab.api.io.ISerializable

Represents an object with a unique id.

Constructors public UniqueObject()

Methods public long getId()

Returns the id of the object.

Returns

The id of the object.

public void setId(long id)

Sets the id of the object.

Parameters

id - The id of the object.

public void readObject(IInputObject input)

public void writeObject(IOutputObject output)

Fields public static final ID

The value used to transmit the id field.

public class com.locoslab.api.data.maps.NamedObject extends com.locoslab.api.data.maps.UniqueObject

Represents a unique object with a name.

Constructors public NamedObject()

Methods public java.lang.String getName()

Returns the name of the object.

Returns

The name of the object.



public void setName(String name)

Sets the name of the object.

Parameters

name - The name of the object.



Fields public static final NAME

The value used to serialize the name.

public class com.locoslab.api.data.maps.AnnotatedObject extends com.locoslab.api.data.maps.NamedObject

Represents a named object with an additional description.

Constructors public AnnotatedObject()

Methods public java.lang.String getDescription()

Returns the description of the object.

Returns

The description.

public void setDescription(String description)

Sets the description of the object.

Parameters

description - The description.



Fields public static final DESCRIPTION

The string used to serialize the description.



Package com.locoslab.api.data.maps.model

public class com.locoslab.api.data.maps.model.Project extends com.locoslab.api.data.maps.AnnotatedObject

Represents the meta information for a project.

Constructors public Project()

Methods public com.locoslab.api.data.maps.model.Area getEnvironment()

Returns the environment area.

Returns

The environment area.

public void setEnvironment(Area environment)

Sets the environment area.

Parameters

environment - The environment.

public java.util.List getBuildings()

Returns the building areas.

Returns

The building areas.

public void setBuildings(List buildings)

Sets the building areas.

Parameters

buildings - The building areas.

public java.util.List getLinks()

Returns the links for the project

Returns

The links for the project.

public void setLinks(List links)

Sets the links for the project.

Parameters

links - The links for the project.



Fields public static final ENVIRONMENT



The key for the area representing the environment.

public static final BUILDINGS

The key for the area representing the buildings.

public static final LINKS

The key for the links in the project.

public class com.locoslab.api.data.maps.model.Point implements com.locoslab.api.io.ISerializable

Represents a relative (i.e. between 0 and 1) point on an image.

Constructors public Point()

Methods public double getX()

Returns the relative x coordinate.

Returns

The relative x coordinate.

public void setX(double x)

Sets the relative x coordinate.

Parameters

x - The relative x coordinate.

public double getY()

Returns the relative y coordinate.

Returns

The relative y coordinate.

public void setY(double y)

Sets the relative y coordinate.

Parameters

y - The relative y coordinate.



Fields public static final X

The key for the x coordinate of the point.



public static final Y

The key for the y coordinate of the point.

public class com.locoslab.api.data.maps.model.Place extends com.locoslab.api.data.maps.AnnotatedObject

Represents a place (e.g. POI) on a particular layer.

Constructors public Place()

Methods public com.locoslab.api.data.maps.model.Coordinate getCoordinate()

Returns the coordinate of the place.

Returns

The coordinate of the place.

public void setCoordinate(Coordinate coordinate)

Sets the coordinate of the place.

Parameters

coordinate - The coordinate of the place.



Fields public static final COORDINATE

The key for the location represented as coordinate.

public class com.locoslab.api.data.maps.model.Path extends com.locoslab.api.data.maps.UniqueObject

A path that may be used for navigation.

Constructors public Path()

Methods public boolean isBidirectional()

Determines whether the path is bidirectional.

Returns



True if the path is bidirectional.

public void setBidirectional(boolean bidirectional)

Marks the path as uni- or bidirectional.

Parameters

bidirectional - True if bidirectional, false if unidirectional.

public void setCoordinates(List coordinates)

Sets the coordinates.

Parameters

coordinates - The coordinates.

public java.util.List getCoordinates()

Returns the coordinates.

Returns

The coordinates.



Fields public static final COORDINATES

The key to store coordinates.

public static final BIDIRECTIONAL

The key to store whether the path is bidirectional.

public interface com.locoslab.api.data.maps.model.LinkType

The types of links that model different ways to change layers.

Fields public static final PASSAGE

A passage (simple walkway without elevation).

public static final RAMP

A ramp (walkway with elevation).

public static final ELEVATOR

An elevator (a lift).

public static final ESCALATOR



An escalator (automatic stairs).

public static final STAIRWAY

A stairway (steps to be walked manually).

public static final CHECKPOINT

A control checkpoint (e.g. a security control in the airport).

public class com.locoslab.api.data.maps.model.Link extends com.locoslab.api.data.maps.NamedObject

Represents a link (i.e. a typed path) between two layers.

Constructors public Link()

Methods public long getSourceLayer()

Returns the source layer id.

Returns

The source layer id.

public void setSourceLayer(long sourceLayer)

Sets the source layer id.

Parameters

sourceLayer - The source layer to set.

public long getTargetLayer()

Returns the target layer id.

Returns

The target layer id.

public void setTargetLayer(long targetLayer)

Sets the target layer id.

Parameters

targetLayer - The target layer id to set.

public com.locoslab.api.data.maps.model.Coordinate getSourceCoordinate()

Returns the source coordinate.

Returns

The source coordinate.

public void setSourceCoordinate(Coordinate sourceCoordinate)



Sets the source coordinate.

Parameters

sourceCoordinate - The source coordinate to set.

public com.locoslab.api.data.maps.model.Coordinate getTargetCoordinate()

Returns the target coordinate.

Returns

The target coordinate.

public void setTargetCoordinate(Coordinate targetCoordinate)

Sets the target coordinate.

Parameters

targetCoordinate - The target coordinate to set.

public int getType()

Returns the link type which should be one of the constants defined in the link type class.

Returns

The link type.

public void setType(int type)

Sets the link type to one of the type constants.

Parameters

type - The link type to set.

public boolean isBidirectional()

Returns the flag to indicate whether the link is bidirectional.

Returns

True if bidirectional, false otherwise.

public void setBidirectional(boolean bidirectional)

Sets the flag to indicate whether the link is bidirectional.

Parameters

bidirectional - True if bidirectional, false otherwise.



Fields public static final SOURCE_LAYER

The key for the source layer.

public static final TARGET_LAYER

The key for the target layer.

public static final SOURCE_COORDINATE



The key for the coordinate on the source layer.

public static final TARGET_COORDINATE

The key for the coordinate on the target layer.

public static final TYPE

The key for the type of the link.

public static final BIDIRECTIONAL

The key for a flag to determine whether the link is bidirectional.

public class com.locoslab.api.data.maps.model.Layer extends com.locoslab.api.data.maps.NamedObject

Represents a layer (e.g. a floor) of an area.

Constructors public Layer()

Methods public java.util.List getPlaces()

Returns the list of places.

Returns

The list of places.

public void setPlaces(List places)

Sets the list of places.

Parameters

places - The list of places.

public java.util.List getPaths()

Returns the paths.

Returns

The list of paths.

public void setPaths(List paths)

Sets the paths.

Parameters

paths - The list of paths.

public java.util.List getImages()

Returns the images.

Returns



The images.

public void setImages(List images)

Sets the images.

Parameters

images - The images.

public int getLevel()

Returns the level.

Returns

The level.

public void setLevel(int level)

Sets the level.

Parameters

level - The level.

public com.locoslab.api.data.maps.model.Anchor getA()

Returns anchor a.

Returns

Anchor a.

public void setA(Anchor a)

Sets anchor a.

Parameters

a - Anchor a.

public com.locoslab.api.data.maps.model.Anchor getB()

Returns anchor b.

Returns

Anchor b.

public void setB(Anchor b)

Sets anchor b.

Parameters

b - Anchor b.

public com.locoslab.api.data.maps.model.Anchor getC()

Returns anchor c.

Returns

Anchor c.

public void setC(Anchor c)

Sets anchor c.

Parameters



c - Anchor c.



Fields public static final IMAGES

The key used to store the images.

public static final PATHS

The key used to store the paths.

public static final LEVEL

The key used to store the level.

public static final PLACES

The key used to store the places.

public static final A

The key used to store the anchor a.

public static final B

The key used to store the anchor b.

public static final C

The key used to store the anchor c.

public class com.locoslab.api.data.maps.model.Image extends com.locoslab.api.data.maps.UniqueObject

Represents the meta data of a particular image.

Constructors public Image()

Methods public int getWidth()

Returns the width in pixels.

Returns

The width in pixels.

public void setWidth(int width)

Sets the width in pixels.



Parameters

width - The width in pixels.

public int getHeight()

Returns the height in pixels.

Returns

The height in pixels.

public void setHeight(int height)

Sets the height in pixels.

Parameters

height - The height in pixels.

public java.lang.String getType()

Returns the mime type.

Returns

The mime type.

public void setType(String type)

Sets the mime type.

Parameters

type - The mime type.



Fields public static final WIDTH

The key for the width in pixels.

public static final HEIGHT

The key for the height in pixels.

public static final TYPE

The mime type of the image.

public class com.locoslab.api.data.maps.model.Coordinate implements com.locoslab.api.io.ISerializable

Represents a WGS84 coordinate with longitude and latitue.



Constructors public Coordinate()

Methods public double getLatitude()

Returns the latitude.

Returns

The latitude.

public void setLatitude(double latitude)

Sets the latitude.

Parameters

latitude - The latitude.

public double getLongitude()

Returns the longitude.

Returns

The longitude.

public void setLongitude(double longitude)

Sets the longitude.

Parameters

longitude - The longitude.



Fields public static final LONGITUDE

The key to store the longitude.

public static final LATITUDE

The key to store the latitude.

public class com.locoslab.api.data.maps.model.Area extends com.locoslab.api.data.maps.AnnotatedObject

Represents a building or structure with a geometric extent.

Constructors public Area()

Methods public java.util.List getLayers()

Returns the layers of the area.



Returns

The layers of the area.

public void setLayers(List layers)

Sets the layers of the area.

Parameters

layers - The layers.



Fields public static final LAYERS

The key to store the layers.

public class com.locoslab.api.data.maps.model.Anchor implements com.locoslab.api.io.ISerializable

Represents an anchor point used to translate between coordinate systems with an affine transform.

Constructors public Anchor()

Methods public com.locoslab.api.data.maps.model.Coordinate getCoordinate()

Returns the coordinate.

Returns

The coordinate.

public void setCoordinate(Coordinate coordinate)

Sets the coordinate.

Parameters

coordinate - The coordinate.

public com.locoslab.api.data.maps.model.Point getPoint()

Returns the point.

Returns

The point.

public void setPoint(Point point)

Sets the point.

Parameters

point - The point.





Fields public static final COORDINATE

The key to represent the coordinate.

public static final POINT

The key to represent the relative point.

Package com.locoslab.api.data.maps.util

public class com.locoslab.api.data.maps.util.Transformation

A helper class to perform an affine transform between two coordinate systems using three fix points.

Methods public double[] transform(double[] point)

Transforms the point (from the source system) to the target system.

Parameters

point - The point to transform.

Returns

The point expressed in the coordinates of the target system.

public static boolean isValid(Anchor a, Anchor b, Anchor c)

Determines whether the three anchors are forming a triangle with respect to their coordinates and with respect to their points.

Parameters

a - The first anchor.

b - The second anchor.

c - The third anchor.

Returns

True if the anchor coordinates and points are each forming triangles - which enables a 2 way transformation between the two coordinate systems.

public java.lang.String toString()

public static class com.locoslab.api.data.maps.util.Transformation.P2C extends com.locoslab.api.data.maps.util.Transformation



This class performs a transform of a point to a coordinate.

Constructors public Transformation.P2C(Anchor a, Anchor b, Anchor c)

Creates a new point to coordinate transformation using the three anchors. Note that this method will throw an illegal argument exception if the points or the coordinates defined by the anchors are not forming a triangle.

Parameters




Throws

IllegalArgumentException - Thrown if the anchor points or coordinates are not forming a triangle.

Methods public com.locoslab.api.data.maps.model.Coordinate transform(Point point)

Transforms the given point into a coordinate.

Parameters

point - The point to transform.

Returns

The coordinate.

public static class com.locoslab.api.data.maps.util.Transformation.C2P extends com.locoslab.api.data.maps.util.Transformation

This class transforms a coordinate to a point.

Constructors public Transformation.C2P(Anchor a, Anchor b, Anchor c)

Creates a new coordinate to point transformation using the three anchors. Note that this method will throw an illegal argument exception if the points or the coordinates defined by the anchors are not forming a triangle.

Parameters




Throws

IllegalArgumentException - Thrown if the anchor points or coordinates are not forming a triangle.

Methods public com.locoslab.api.data.maps.model.Point transform(Coordinate coordinate)

Transforms the given coordinate into a point.

Parameters

coordinate - The coordinate to transform.



Returns

The transformed point..

public class com.locoslab.api.data.maps.util.Polylines

A utility class to compress a series of coordinates that represents a polyline. This is used to reduce the size of paths and steps.

Constructors public Polylines()

Methods public static java.lang.String encode(List coordinates)

Encodes a list of coordinates into a string.

Parameters


Returns

The string.

public static java.util.List decode(String encoded)

Extracts the list of coordinates from an encoded string.

Parameters

encoded - The encoded string.

Returns

The coordinates.

public class com.locoslab.api.data.maps.util.Overlay

A class to compute the affine transforms and coordinates for image overlays. The class contains two matrixes, the forward transformation (tranform) and the backward transformation (inverse). The individual matrix values can be retrieved using the index constants (A, B, C, D, E, F).

Constructors public Overlay(Image image, Anchor a, Anchor b, Anchor c)

Creates a new overlay for the specified image with the specified anchors.

Parameters

image - The image.

a - The anchor a.

b - The anchor b.

c - The anchor c.

Methods public double getTransform(int idx)



Returns the value of the transform.

Parameters

idx - The index (one of the index constants).

Returns

The value of the transform.

public int getWidth()

Returns the width of the bounding box of the overlay.

Returns

The width of the bounding box of the overlay.

public int getHeight()

Returns the height of the bounding box of the overlay.

Returns

The height of the bounding box of the overlay.

public com.locoslab.api.data.maps.model.Coordinate getTopLeft()

Returns the top left coordinate of the overlay.

Returns

The top left coordinate of the overlay.

public com.locoslab.api.data.maps.model.Coordinate getBottomRight()

Returns the bottom right coordinate of the overlay.

Returns

The bottom right coordinate of the overlay.

Fields public static final INDEX_A

The index of An.

public static final INDEX_B

The index of Bn.

public static final INDEX_C

The index of Cn.

public static final INDEX_D

The index of Dn.

public static final INDEX_E

The index of En.

public static final INDEX_F

The index of Fn.



public class com.locoslab.api.data.maps.util.Coordinates

Constructors public Coordinates()

Methods public static double distanceInMeters(Coordinate a, Coordinate b)

Computes the distance in meters between two coordinates using the haversine formula.

Parameters

a - The first coordinate.

b - The second coordinate.

Returns

The distance between the two coordinates in meters.

public static double distanceInMeters(double alon, double alat, double blon, double blat)

Returns the distance in meters between the two points given by alat, alon and blat, blon.

Parameters

alon - The longitude of point a.

alat - The latitude of point a.

blon - The longitude of point b.

blat - The latitude of point b.

Returns

The distance in meters.

public static double distanceInMeters(List coordinates)

Returns the distance in meters when moving along the path defined by the list of coordinates.

Parameters


Returns

The distance of the path defined by the coordinates.

public static double euclideanDistance(Coordinate a, Coordinate b)

Computes the euclidean distance between two coordinates.

Parameters



Returns

The euclidean distance between a and b.

public static double euclideanDistanceSquared(Coordinate a, Coordinate b)

Computes the squared euclidean distance between two coordinates.

Parameters





Returns

The squared euclidean distance between a and b.

public static double angleOfLine(Coordinate line1, Coordinate line2)

Computes the angle between the x-axis and the vector defined by the two coordinates in degrees. If the two coordinates are identical, the method returns NaN. The range of the resulting angle is from 180 to -180.

Parameters

line1 - One point of the line.

line2 - Another point of the line.

Returns

The angle of the line.

public static com.locoslab.api.data.maps.model.Coordinate closestPointOnLine(Coordinate line1, Coordinate line2, Coordinate point)

Computes the closest point on a line segment from the perspective of a particular point.

Parameters

line1 - The first coordinate of the line segment.

line2 - The second coordinate of the line segment.

point - The point to start from.

Returns

The point that is on the line segment and closest to the input point.

Package com.locoslab.api.io

public interface com.locoslab.api.io.ISerializable

An interface for objects that can be serialized.

Methods public void readObject(IInputObject input)

Reads the object from the input.

Parameters

input - The input to read from.

Throws

IOException - Thrown if the deserialization fails.


Writes the object to the output.

Parameters

output - The output to write to.

Throws

IOException - Thrown if the serialization fails.



public interface com.locoslab.api.io.IOutputObject

An object that can be read from.

Methods public void writeString(String name, String value)

Writes a string to the attribute with the specified name.

Parameters

name - The name of the attribute.

value - The value of the attribute.

Throws

IOException - Thrown by the underlying stream.

public void writeBoolean(String name, boolean value)

Writes a boolean to the attribute with the specified name.

Parameters



Throws


public void writeLong(String name, long value)

Writes a long to the attribute with the specified name.

Parameters



Throws


public void writeInt(String name, int value)

Writes an int to the attribute with the specified name.

Parameters



Throws


public void writeDouble(String name, double value)

Writes a double to the attribute with the specified name.

Parameters





Throws


public com.locoslab.api.io.IOutputObject writeObject(String name)

Writes an object to the attribute with the specified name.

Parameters


Returns

The object to write to.

Throws


public com.locoslab.api.io.IOutputArray writeArray(String name)

Writes an array to the attribute with the specified name.

Parameters


Returns

The array to write to.

Throws


public interface com.locoslab.api.io.IOutputArray

Represents an array that can be written sequentially.

Methods public com.locoslab.api.io.IOutputObject writeObject()

Writes the next object to the array.

Returns

The next object to write to.

Throws


public com.locoslab.api.io.IOutputArray writeArray()

Writes an array to the array.

Returns

The array to write to.

Throws


public void writeString(String value)



Writes a string to the array.

Parameters

value - The value to write.

Throws


public void writeBoolean(boolean value)

Writes a boolean to the array.

Parameters


Throws


public void writeLong(long value)

Writes a long to the array.

Parameters


Throws


public void writeInt(int value)

Writes an int to the array.

Parameters


Throws


public void writeDouble(double value)

Writes a double to the array.

Parameters


Throws


public interface com.locoslab.api.io.IInputObject

An object that can be written to.

Methods public java.lang.String readString(String name)

Reads a string from an attribute with a particular name.

Parameters



name - The name to read from.

Returns

The string attached to the name.

Throws


public boolean readBoolean(String name)

Reads a boolean from an attribute with a particular name.

Parameters


Returns

The boolean attached to the name.

Throws


public long readLong(String name)

Reads a long from an attribute with a particular name.

Parameters


Returns

The long attached to the name.

Throws


public int readInt(String name)

Reads an int from an attribute with a particular name.

Parameters


Returns

The int attached to the name.

Throws


public double readDouble(String name)

Reads a double from an attribute with a particular name.

Parameters


Returns

The double attached to the name.

Throws


public com.locoslab.api.io.IInputObject readObject(String name)

Reads an object from an attribute with a particular name.

Parameters




Returns

The object attached to the name.

Throws


public com.locoslab.api.io.IInputArray readArray(String name)

Reads an array from an attribute with a particular name.

Parameters


Returns

The array attached to the name.

Throws


public interface com.locoslab.api.io.IInputArray

Represents an array that can be read sequentially.

Methods public boolean hasNext()

Determines whether the array has another entry.

Returns

True if there is another entry, false otherwise.

Throws


public com.locoslab.api.io.IInputObject readObject()

Reads the next object from the array.

Returns

The next object from the array.

Throws

IOException - Thrown by the underlying stream or if there are no more objects to read.

public com.locoslab.api.io.IInputArray readArray()

Reads the next array from the array.

Returns

The next array from the array.

Throws

IOException - Thrown by the underlying stream or if there are no more arrays to read.

public java.lang.String readString()



Reads a string from the array.

Returns

The next entry as string.

Throws


public boolean readBoolean()

Reads a boolean from the array.

Returns

The next entry as boolean.

Throws


public long readLong()

Reads a long from the array.

Returns

The next entry as long.

Throws


public int readInt()

Reads a int from the array.

Returns

The next entry as int.

Throws


public double readDouble()

Reads a double from the array.

Returns

The next entry as double.

Throws




II. ANNEX B – DETAILED DESCRIPTION OF PARKING AND ACCESS CONTROL AREAS MODEL

Class ParkingSpot

Definition

An object of this class represents an individual parking spot.

Attributes

Name Data type Meaning Mandatory Kind of information

Id Long inte-ger

Unique identifier Yes Static

Address String Descriptive name of the parking spot loca-tion, preferably indicating the postal address

Yes Static

Type Short inte-ger

Type of parking: on street, private car park Yes Static

Width Float Width of the spot No Static

Length Float Length of the spot No Static

IsOnlyForDisabled Boolean Indicates whether the spot is reserved for use by mobility impaired user only

Yes Static

IsOccuppied Boolean Indicates whether the spot is currently occu-pied by a parked vehicle

No Dynamic

CanBeBooked Boolean Indicates whether booking is permitted for the spot

Yes Static

IsBooked Boolean Indicates whether the spot is currently booked

No Dynamic

Relations:

ParkingSpot inherits from Position

Each ParkingSpot may be associated to zero or one ParkingLot

Each ParkingSpot may be associated to zero or one ParkingZone

Class ParkingSpotsCluster

Description

ParkingSpotsCluster is the common base class of ParkingLot and ParkingZone that provides the total number of parking spots.

Attributes


NumberOfSpots Integer Total number of spots Yes Static

NumberOfDisabledOnlySpots Integer Number of spots that are reserved for use by mobility impaired citizens only

No Static

Relations

A ParkingSpotCluster is aggregates zero or more ParkingSpots.



Class ParkingLot

A ParkingLot is a specialisation of the ClosedZone class (see section 6.2.1.1) that is an aggregation of several parking spaces that are contiguous or near to each other, and is useful whenever one of the following conditions is fulfilled:

o The exaction position of each individual spot is not known, but the shape of the parking lot is, or

o The spots are inside a closed zone (like a car park) and the position of the entrances and/or exits of the zone is known

It inherits the attributes for the number of parking spots from ParkingSpotsCluster.

Attributes


Id Long inte-ger


Description String Descriptive name of the entity Yes Static

Relations

ParkingLot inherits from ClosedZone

ParkingLot inherits from ParkingSpotsCluster

A ParkingLot may be associated to zero or one ParkingZones

Class ParkingZone

Definition

A ParkingZone is specialisation of the Zone class (see section 6.2.1.1) that represents the smallest aggregation of parking spaces for which the available system(s) in the city can provide dynamic information about availability, occupancy or booking.

It inherits the static attributes for the number of parking spots from ParkingSpotsCluster.

Attributes

Name Data type

Meaning Mandatory Kind of information

Id Long in-teger


Description String Descriptive name of the entity

Yes Static

NumberOfFreeSpots Integer Number of free (not occu-pied) parking spots in the zone

No Dynamic

NumberOfFreeDisabledOnlySpots Integer Number of free (not occu-pied) parking spots in the zone that are reserved for mobility impaired users

No Dynamic

NumberOfBookedSpots Integer Number of booked spots in the zone

No Dynamic



NumberOfBookedDisabledOnlySpots Integer Number of booked spots in the zone that are re-served for mobility im-paired users

No Dynamic

NumberOfBookableSpots Integer Number of spots in the zone that can be booked

Yes Static

NumberOfBookeableDisabledOnlySpots Integer Number of spots in the zone that can be booked and are reserved for mo-bility impaired users

Yes Static

Relations

ParkingZone inhertis from Zone

ParkingZone inhertis from ParkingSpotsCluster

A ParkingZone may be associated to zero or more objects of class ParkingControlDevice

A ParkingZone may be associated to zero or more ParkingLots. The number of spots in those parking lots must be included in the total accountings of the zone.



III. ANNEX C – DETAILED DESCRIPTION OF EVENTS MODEL

Class UserValidationEvent

Definition

Record of an attempt (either successful or not) of validating the identity of a user by means of security tokens.

Attributes

Name Data type Meaning Mandatory

PK Long integer Unique identifier Yes

Status Short integer Success or failure status of the validation Yes

TimeStamp Time stamp Instant of the event Yes

Type Short Type of validation. Used for indicating the purpose (user login, parking validation, etc.)

Yes

Relations

A UserValidationEvent may be associated to zero or one objects of class User (see section 0). It shall be one only if the validation was successful or at least permitted to obtain the user that attempted to validate.

A UserValidationEvent aggregates zero or more objects of class UserValidationToken, representing the token or tokens used for attempting the validation.

Class UserValidationToken

Description

This class allow registering the tokens used in each user identity validation attempt.

Attributes


Status Short integer Success or failure status of the validation of the token Yes

Type Short integer Type of token used (RFID, PhoneNumber, etc.) Yes

Token String Token value used for the validation attempt No

Relations

Each UserValidationToken belongs to exactly one UserValidationEvent

Each UserValidationToken may be associated to zero or one objects of type SecurityToken (see section 0). It shall be one only if the validation was successful or at least permitted to identify the token.

Class ParkingValidationEvent

Description

Record of a successful validation of the usage of a parking spot by a mobility impaired user.



Attributes



Type Short integer Type of validation (on street parking for reserved space, on street parking for non-reserved space, etc.)

Yes

BeginTimeStamp TimeStamp Begin time of the validation Yes

EndTimeStamp TimeStamp End time of the validation (if ended) No

EndMode Short integer Mode of the validation end (if ended). Indicate if the user ended the validation in time (when leaving), late (after leaving), or it was registered by a Controller.

No

UserPosition GPSPosition GPS position of the citizen at the time of attempting the validation, if available.

No

Relations

Each ParkingValidationEvent is associated to exactly one UserValidationEvent, because a parking validation process implies a validation of the user’s identity.

Each ParkingValidationEvent is associated to exactly one object of class User (see section 0).

Each ParkingValidationEvent may be associated to zero or one Location referring to one of the parking entities in section 6.2.2. It shall be one if the validation succeeds and the location is known.

Each ParkingValidationEvent may be associated to zero or one objects of class ParkingControlDevice (see section 6.2.2). It shall be one if the validation is made by means of a park meter.

Class ParkingInfraction

Description

An object of class ParkingInfraction represents record of an invalid or fraudulent use of a parking space registered by a parking controller.

IMPORTANT

The registration of this event is completely unrelated with any actual infraction procedure against the offender, what is completely out of the scope of SIMON

Attributes



Instant Time stamp Instant when the infraction is registered Yes

Reason Short integer Code indicating the reason why the parking is considered an infraction (absence of EU badge, fake EU badge, etc.)

Yes

Comment String Free text commenting the circumstances of the infraction provided by the controller

No

LicensePlate String License plate number of the vehicle Yes

Since Time stamp Instant before the infraction when the vehicle was de-tected parking incorrectly for the first time

No

CitizenToken String Value of the token found behind the vehicles windscreen, No



if any

CitizenType Short integer Type of token found behind the vehicles windscreen, if any

No

VehicleType Integer Type of vehicle code No

VehicleBrand Integer r Code representing the brand of the vehicle No

VehicleColor Integer Code representing the color of the vehicle No

VehicleModel Integer Code representing the vehicle model No

Address String integer Postal address of the location of the vehicle No

ControllerPosition GPSPosition GPS position of the controller at the time of registering the infraction, if available. It is assumed to be very close to the vehicle position.

No

Relations

A ParkingInfraction is associated to exactly one object of class User (see section 0) corresponding to the controller that registered the infraction.

Class AccessControlValidationEvent

Description

An object of class AccessControlValidationEvent represents a record of a successful validation of the access to a restricted area by a mobility impaired user.

Attributes



Type Short integer Type of validation (on street parking for reserved space, on street parking for non-reserved space, etc.)

Yes

BeginTime TimeStamp Begin time of the validation Yes

EndTime TimeStamp End time of the validation (if ended) Yes

LicensePlate String License number plate of the vehicle Yes

LocalSystemId String Identifier assigned to the validation by the local access con-trol system that processed the validation

No

UserPosition GPSPosition GPS position of the citizen at the time of attempting the vali-dation, if available.

No

Relations

Each AccessControlValidationEvent is associated to exactly one UserValidationEvent, because an access validation process implies a validation of the user’s identity.

Each AccessControlValidationEvent is associated to exactly one object of class User (see section 0).

Each AccessControlValidationEvent is associated to exactly one AccessControlledZone (see section 6.2.3), the zone for which the request was made.



Class GenericLogEvent

Description

The most widely used event logging software libraries support generating log events with most of the attributes of the GenericLogEvent class:

Attributes


Instant Time stamp Instant of the event Yes

Category String Category of the event No

Level String Level of severity (error, warning, information, detail, debug) No

SourceModule String Software module that produces the event logged Yes

Description String Text explaining the details about the event Yes

ExtraData String Additional text containing details about the event in a com-putable format (XML, JSON, etc.)

No

title: document version: project number: project acronym...

Documents