title: document version: project number: project acronym...
TRANSCRIPT
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)
D3.2 Information model and interoperability 3
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.1. Design Principles ........................................................................................................... 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.1. Design Principles ........................................................................................................... 29
7.2. Description ................................................................................................................... 30
8. EVENT DATAMODEL .................................................................................................... 32
D3.2 Information model and interoperability 4
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
8.1. Design Principles ........................................................................................................... 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
D3.2 Information model and interoperability 5
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 6
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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:
D3.2 Information model and interoperability 7
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 8
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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).
D3.2 Information model and interoperability 9
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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-
D3.2 Information model and interoperability 10
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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).
D3.2 Information model and interoperability 11
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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-
D3.2 Information model and interoperability 12
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 13
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 14
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 15
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 16
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.:
D3.2 Information model and interoperability 17
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
Figure 5 – GTFS UML Model
More details on the GTFS format can be found on the GTFS Specification page (7)
D3.2 Information model and interoperability 18
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 19
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
6. PARKING AND ACCESS CONTROLLED AREAS MODEL
6.1. DESIGN PRINCIPLES
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-
D3.2 Information model and interoperability 20
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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).
D3.2 Information model and interoperability 21
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 22
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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}
D3.2 Information model and interoperability 23
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 24
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 25
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
+ descriptio n: string
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
D3.2 Information model and interoperability 26
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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:
D3.2 Information model and interoperability 27
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 28
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
AccessControlledZone
ControlledAccess+accesses
1. .
+controlDevice
0. .1
+controlDevices
1. .*
+zones1. .*
+accesses 0..*
+zone
1
D3.2 Information model and interoperability 29
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
7. USERS AND SECURITY TOKENS MODEL
7.1. DESIGN PRINCIPLES
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.
D3.2 Information model and interoperability 30
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 31
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 32
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
8. EVENT DATAMODEL
8.1. DESIGN PRINCIPLES
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.
D3.2 Information model and interoperability 33
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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::
AccessControlledZone
+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
D3.2 Information model and interoperability 34
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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:
D3.2 Information model and interoperability 35
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
+ descriptio n: string
+ extraData : string
D3.2 Information model and interoperability 36
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 37
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 38
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 39
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
public void setName(String name)
Sets the name of the object.
Parameters
name - The name of the object.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
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.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
Fields public static final DESCRIPTION
The string used to serialize the description.
D3.2 Information model and interoperability 40
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
Fields public static final ENVIRONMENT
D3.2 Information model and interoperability 41
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
Fields public static final X
The key for the x coordinate of the point.
D3.2 Information model and interoperability 42
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
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
D3.2 Information model and interoperability 43
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
public void writeObject(IOutputObject output)
public void readObject(IInputObject input)
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
D3.2 Information model and interoperability 44
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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)
D3.2 Information model and interoperability 45
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
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
D3.2 Information model and interoperability 46
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 47
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
D3.2 Information model and interoperability 48
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
c - Anchor c.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
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.
D3.2 Information model and interoperability 49
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
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.
D3.2 Information model and interoperability 50
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
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.
D3.2 Information model and interoperability 51
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
Returns
The layers of the area.
public void setLayers(List layers)
Sets the layers of the area.
Parameters
layers - The layers.
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
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.
D3.2 Information model and interoperability 52
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
public void readObject(IInputObject input)
public void writeObject(IOutputObject output)
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
D3.2 Information model and interoperability 53
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
a - The first anchor.
b - The second anchor.
c - The third anchor.
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
a - The first anchor.
b - The second anchor.
c - The third anchor.
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.
D3.2 Information model and interoperability 54
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
coordinates - The coordinates.
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)
D3.2 Information model and interoperability 55
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 56
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
coordinates - The coordinates.
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
a - The first coordinate.
b - The second coordinate.
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
a - The first coordinate.
D3.2 Information model and interoperability 57
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
b - The second coordinate.
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.
public void writeObject(IOutputObject output)
Writes the object to the output.
Parameters
output - The output to write to.
Throws
IOException - Thrown if the serialization fails.
D3.2 Information model and interoperability 58
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
name - The name of the attribute.
value - The value of the attribute.
Throws
IOException - Thrown by the underlying stream.
public void writeLong(String name, long value)
Writes a long 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 writeInt(String name, int value)
Writes an int 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 writeDouble(String name, double value)
Writes a double to the attribute with the specified name.
Parameters
name - The name of the attribute.
D3.2 Information model and interoperability 59
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
value - The value of the attribute.
Throws
IOException - Thrown by the underlying stream.
public com.locoslab.api.io.IOutputObject writeObject(String name)
Writes an object to the attribute with the specified name.
Parameters
name - The name of the attribute.
Returns
The object to write to.
Throws
IOException - Thrown by the underlying stream.
public com.locoslab.api.io.IOutputArray writeArray(String name)
Writes an array to the attribute with the specified name.
Parameters
name - The name of the attribute.
Returns
The array to write to.
Throws
IOException - Thrown by the underlying stream.
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
IOException - Thrown by the underlying stream.
public com.locoslab.api.io.IOutputArray writeArray()
Writes an array to the array.
Returns
The array to write to.
Throws
IOException - Thrown by the underlying stream.
public void writeString(String value)
D3.2 Information model and interoperability 60
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
Writes a string to the array.
Parameters
value - The value to write.
Throws
IOException - Thrown by the underlying stream.
public void writeBoolean(boolean value)
Writes a boolean to the array.
Parameters
value - The value to write.
Throws
IOException - Thrown by the underlying stream.
public void writeLong(long value)
Writes a long to the array.
Parameters
value - The value to write.
Throws
IOException - Thrown by the underlying stream.
public void writeInt(int value)
Writes an int to the array.
Parameters
value - The value to write.
Throws
IOException - Thrown by the underlying stream.
public void writeDouble(double value)
Writes a double to the array.
Parameters
value - The value to write.
Throws
IOException - Thrown by the underlying stream.
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
D3.2 Information model and interoperability 61
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
name - The name to read from.
Returns
The string attached to the name.
Throws
IOException - Thrown by the underlying stream.
public boolean readBoolean(String name)
Reads a boolean from an attribute with a particular name.
Parameters
name - The name to read from.
Returns
The boolean attached to the name.
Throws
IOException - Thrown by the underlying stream.
public long readLong(String name)
Reads a long from an attribute with a particular name.
Parameters
name - The name to read from.
Returns
The long attached to the name.
Throws
IOException - Thrown by the underlying stream.
public int readInt(String name)
Reads an int from an attribute with a particular name.
Parameters
name - The name to read from.
Returns
The int attached to the name.
Throws
IOException - Thrown by the underlying stream.
public double readDouble(String name)
Reads a double from an attribute with a particular name.
Parameters
name - The name to read from.
Returns
The double attached to the name.
Throws
IOException - Thrown by the underlying stream.
public com.locoslab.api.io.IInputObject readObject(String name)
Reads an object from an attribute with a particular name.
Parameters
D3.2 Information model and interoperability 62
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
name - The name to read from.
Returns
The object attached to the name.
Throws
IOException - Thrown by the underlying stream.
public com.locoslab.api.io.IInputArray readArray(String name)
Reads an array from an attribute with a particular name.
Parameters
name - The name to read from.
Returns
The array attached to the name.
Throws
IOException - Thrown by the underlying stream.
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
IOException - Thrown by the underlying stream.
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()
D3.2 Information model and interoperability 63
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
Reads a string from the array.
Returns
The next entry as string.
Throws
IOException - Thrown by the underlying stream.
public boolean readBoolean()
Reads a boolean from the array.
Returns
The next entry as boolean.
Throws
IOException - Thrown by the underlying stream.
public long readLong()
Reads a long from the array.
Returns
The next entry as long.
Throws
IOException - Thrown by the underlying stream.
public int readInt()
Reads a int from the array.
Returns
The next entry as int.
Throws
IOException - Thrown by the underlying stream.
public double readDouble()
Reads a double from the array.
Returns
The next entry as double.
Throws
IOException - Thrown by the underlying stream.
D3.2 Information model and interoperability 64
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
Name Data type Meaning Mandatory Kind of information
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.
D3.2 Information model and interoperability 65
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
Name Data type Meaning Mandatory Kind of information
Id Long inte-ger
Unique identifier Yes Static
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
Unique identifier Yes Static
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
D3.2 Information model and interoperability 66
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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.
D3.2 Information model and interoperability 67
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
Name Data type Meaning Mandatory
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.
D3.2 Information model and interoperability 68
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
Attributes
Name Data type Meaning Mandatory
PK Long integer Unique identifier Yes
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
Name Data type Meaning Mandatory
PK Long integer Unique identifier Yes
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
D3.2 Information model and interoperability 69
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
Name Data type Meaning Mandatory
PK Long integer Unique identifier Yes
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.
D3.2 Information model and interoperability 70
SIMON. ASSISTED MOBILITY FOR OLDER AND IMPAIRED USERS
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
Name Data type Meaning Mandatory
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