News > Research
News' image preview

Wetransform collaborates with partners to build a network of INSPIRE experts and to distribute the INSPIRE GIS solution. As part of this collaboration, we will regularly invite guest posts. This post was written by Giacomo Martirano, Stefania Morrone and Fabio Vinci of Epsilon Italia and edited by Thorsten Reitz of wetransform.

Since 2014, we’re working on the GeoSmartCity (GSC) project. Our goal is to demonstrate that making geo-data interoperable and reusable by means of open standards creates an economic value. Its scope encompasses two scenarios: underground infrastructures and green energy, and it addresses four target groups: public authorities, utilities, small businesses and citizens.

Wetransform collaborates with partners to build a network of INSPIRE experts and to distribute the INSPIRE GIS solution. As part of this collaboration, we will regularly invite guest posts. This post was written by Giacomo Martirano, Stefania Morrone and Fabio Vinci of Epsilon Italia and edited by Thorsten Reitz of wetransform.

Since 2014, we’re working on the GeoSmartCity (GSC) project. Our goal is to demonstrate that making geo-data interoperable and reusable by means of open standards creates an economic value. Its scope encompasses two scenarios: underground infrastructures and green energy, and it addresses four target groups: public authorities, utilities, small businesses and citizens.

Geosmartcity image

The main challenge we encountered during the project lies in the harmonization of spatial datasets of 11 pilots belonging to 8 different Member States. To address this challenge, we defined a set of use cases and made an inventory of the source datasets used by the 11 pilots. Starting from these user cases, we collected and structured the data modelling requirements.

From the requirements, it was clear that the pilots would need information that is not covered by the INSPIRE data specifications. We thus decided to develop an extension of the INSPIRE data models. In line with the extension methodology described in the INSPIRE Generic Conceptual Model, the GeoSmartCity application schemas import INSPIRE application schemas and add new elements.

We initially planned to start our data modelling work on the extended data models already contained in the Data Specification Technical Guidelines (but not in the Implementing Rules) and to extend them in order to meet the GeoSmartCity data modelling requirements, but this approach was disregarded due to the following reasons:

  • As highlighted in the INSPIRE website, the extended data models should be considered as draft and therefore be used with caution. Extended application schemas in fact are not present in the official repository of INSPIRE schemas and in most cases no valid relevant XML Schema exists in draft schema repository yet.
  • Extended schemas present in the INSPIRE draft schema repository do not entirely fit for purpose because major changes would still be necessary to meet the GeoSmartCity data modelling requirements.

Therefore, we decided on a second approach. We extended the relevant INSPIRE core application schemas (included in the Implementing Rules) and re-used attributes defined in the INSPIRE extended draft application schemas (included only in the Data Specifications). Finally, we added new object classes.

In this way two important results have been achieved:

  • Full consistency of the GeoSmartCity data models with the corresponding INSPIRE core schemas, which are binding by law, has been ensured, i.e. conformity of the datasets to the GeoSmartCity data models implies conformity to the relevant INSPIRE core schemas;
  • The extension process begun from a solid starting point, constituted by the relevant INSPIRE core schemas.

We designed the UML data models with Enterprise Architect and used it to generate the GML application schemas (XSD files). In order to ensure full correctness of the XSD files, some manual fine tuning has been necessary.

To validate that the data model satisfies the pilot use case requirements, we used the transformation testing methodology. In this approach, the model is populated with harmonized data, which is then used. To perform the actual data transformation from heterogeneous source datasets towards the common GeoSmartCity target data models, we used the open source transformation tool HALE. The team behind HALE, wetransform, has supported us in GeoSmartCity, and they are now building an end-to-end INSPIRE solution. This solution will make it much easier to design data models based on open specifications like INSPIRE.

If you want to learn more about the GSC data models and download the XML schema files, check these links:

Still want to know more about INSPIRE data specifications, INSPIRE services, or INSPIRE data transformation? Visit our joint booth with Epsilon Italia, Geosparc and wetransform at GWF 2016!

(more)

News' image preview

Wetransform develops a data-driven approach to the design of data models. We do this because we believe this will help in the faster development of higher-quality shared specifications, with lower risks in implementation.

In this data-driven approach, we aim to improve the quality of a data model with every iteration. This implies the question what kind of data and analysis we can use to measure quality of a data model. In this article, we’ll share a bit of the reasoning behind our approach.

Wetransform develops a data-driven approach to the design of data models. We do this because we believe this will help in the faster development of higher-quality shared specifications, with lower risks in implementation.

In this data-driven approach, we aim to improve the quality of a data model with every iteration. This implies the question what kind of data and analysis we can use to measure quality of a data model. In this article, we’ll share a bit of the reasoning behind our approach.

First of all, when we say data-driven, we mean four kinds of data:

  • Data that can be derived from the model itself by static analysis
  • Data that can be derived from vertically mapping the model to various implementation platforms
  • Data that can be derived from comparison to other models
  • Data that can be derived from usage of the data model

Let’s dip into each of these.

Static analysis of relational models and of object models has been around for a long time. There is some interesting research & development work like SDMetrics and UML Metrics Producer, but most of the ideas haven’t made it into typical design processes – when compared to JSLint or other code analysers that are part of most build processes nowadays. The measures created in static analysis focus on counting types and properties to assess size and to identify loops and nesting depths to calculate structural complexity. They are especially helpful when dealing with transient complexity. In these cases, the model currently under design might seem simple, but it imports other models that contribute greatly – and in an opaque way – to the overall complexity of the model. Some tools also look into behavioral complexity by analyzing the number and structure of the messages exchanged between objects in a model. Finally, there are solutions that can identify design patterns.

Vertical mapping is the process of transforming a conceptual model to logical models in various implementation platforms. It includes mapping a UML model to an XML schema or a relational database schema, or mapping an Ontology to an RDF schema. We measure properties of the vertical mapping to determine how well suited a conceptual model is for implementation on various platforms. Consider the following example: A complex conceptual model like the INSPIRE Data Specifications can be mapped well to XML, but it’s rather hard to map effectively to an Esri Geodatabase system.

Comparative analysis helps find out whether there are similar models, and tells us how the metrics gained from vertical mapping analysis and static analysis stack up against each other. To identify similar models, we abstract them to graphs and then compare structures, value types and labels. After identifying similar models, we assess the model under design by seeing where it falls in its cohort: Is it by far the most complex model? Is it very small in comparison? Or is it highly connected to other models?

Usage analysis is core to understanding the quality of a model. It encompasses several different types of measures:

  • Effectiveness of the model: How large and complex is an actual instance of an object graph? How efficient can the instance be created and parsed?
  • Coverage of the model: How much of the model is actually used? Are there hot spots in usage? Are there points where the model is not differentiated enough?
  • Usage: Which parts of the actual instances are actually consumed by up-stream applications? Is there data in the model that is never used?

We do not create more abstract joint scores from these individual metrics. The designers have to look at each value – most of them unitless – and decide what goal they want to reach for in their next iteration – more effective storage in relational database systems? Less model excess? They can then apply the modification and see what the result is both in the primary metric, but also in all the other metrics.

Stay tuned for further updates on agile, data-driven model design!

(more)

News' image preview

We’re happy to announce the start of the smarticipate project. Fraunhofer IGD and wetransform teamed up with eight partners from five countries to work on an answer for the burning question of Smart Cities denizens:

“How can I best improve the urban environment I am in right now?”

We’re happy to announce the start of the smarticipate project. Fraunhofer IGD and wetransform teamed up with eight partners from five countries to work on an answer for the burning question of Smart Cities denizens:

“How can I best improve the urban environment I am in right now?”

Smarticipate Logo

Currently, Smart Cities mostly collect data and provide it to select experts, such as urban planners. Going forward, we believe the insights gained from this data also have to be available to citizens and businesses. The information has to be accessible and usable – there has to be a proper dialog between the smart city and its smart citizens.

Through the apps and services the group builds, citizens will be able to engage in a dialog with the smart city. They will see its information like an additional layer on reality, and be able to act on it. They push and pull interactions with public authorities, business and other citizens. Citizens create projects or get notified of them as they move along their daily life. They contribute in playful, constructive ways, to make the best possible impact. This is key for cities like Rome, London and Hamburg – our project pilot sites – that want to reach out to citizens and get them engaged in constructive and creative ways.

WeTransform will help the project to manage and integrate both baseline open data and content generated by citizens. The work we do will include setting up our platform for designing, transforming and publishing data sets in open standards, such as CityGML or INSPIRE. In the next weeks and months, expect to hear more about the data management and harmonisation challenges that a smart city project encounters, and how we resolve them!

(more)