News entry thumbnail
How wetransform offsites
18.02.2018 by Anida Jusufovic, Thorsten Reitz

When a company leadership plans a team offsite, they think about questions like: are we on track? Are we going to reach our goals? Are the teams performing as we’d like them to? But, is there more to a team offsite, or should we really and only expect never ending presentations, weird team building exercises and forced fun activities? I have been to over 20 team offsites; some good and some bad, but they would all somehow fit the pattern mentioned above. Until this January, that is.

In July 2017 I joined Wetransform, a startup in Darmstadt, Germany specialized in (spatial) data harmonization with a focus on the INSPIRE implementation. As in many startups in the IT industry, the team of ten people is agile and flexible, often wearing several hats and representing different roles at the company. Wetransform also supports remote work, so we have team members in the Netherlands and Switzerland and cities like Cologne and Frankfurt, while other team members simply work from home in Darmstadt to better align family and work life.

Frankly, the responsibilities get mixed up from time to time, especially when we have new members joining the team, and the responsibilities might become, well, fluid. So, as our team grew, we needed to implement more structures and to define the roles better. In September 2017, all team members received a team offsite invitation to spend four days in Bezau, a small ski resort in Austria for our annual team meeting.

Sonderdach: Wetransform offsite workshop

And there it was, the first difference, at least from my experience: everyone was going to the offsite. No filters in the invitation, no exceptions, no office manager left behind. Everyone was included and invited!

After that offsite, I decided to share my key learnings, with a fair note that most of it rather applies to teams with up to 20 people. For larger teams, there will be different aspects to consider.

Plan ahead

It is easy and somewhat tempting to pack the agenda for the team offsite full of information and data to be processed. After all, it is a unique opportunity to have all people at the same place, not doing business as usual and therefore being able to process all that information in the two days away from the office. Well, it is not. If people must process this super huge amount of data, when will they have the time to discuss and act on it?

This is why we decided to plan two months ahead and assign some homework to all team members. When the team was at the offsite, they already had the bits and pieces needed for further work.

There are many different methods for this, but simple exercises such as preparing company outline materials (yes, numbers and goals are included, you cannot get around that) and then asking all team members to create 2-3 slides with some specific inputs will do the work.

Everyone is invited

When announcing and implementing structural team changes, make sure to pass that information through the team channel. Every change is more likely to be accepted and implemented if team members are included from the beginning and if they have a chance to contribute to the changes. At Wetransform, we decided to restructure our teams and define the roles better, so that everyone knows who is responsible for what and who can contribute to it. With that in mind, we sat together and drafted our internal Service Level Agreements (SLAs) between the teams. Those SLAs will then be signed off by the teams and implemented.

For example, we want to ensure that we deliver high quality service and products to our customers. If Wetransform as a company wants to achieve this goal, all team members need to have a clear picture of the team capacity, scope of work and client needs. And, all of that needs to be very well aligned with our products and services – no overpromising, no missed opportunities! Again, there are many methods on how to align the company goals with the team goals and responsibilities. At Wetransform, we decided to use the OKR method.

Think about your customer

Yes, of course, the purpose of every company is to reach defined metrics and goals in terms of revenue and sales and to make some profit at the end. And for that you need products, services and a brand. However, all of this will not be worth much without a customer who needs and likes your offerings. We used the team offsite to reach a shared understanding of that, both customer and non-customer facing roles alike. Everybody should have clarity on what is important for the customers and how they can address their needs.

At Wetransform, one of our core values is that everybody in the team knows what all others are contributing to the team and to the customer’s success. We don’t want to have siloes or, even worse, internal conflict lines e.g. between revenue and product teams. It’s also important to us that whatever internal communication would become public, we could be proud of it.

This alignment should not just be an exercise for the offsite, but has to become part of the team’s habits in day-to-day work. A well-founded, open and clear team collaboration is the foundation for this part. With many communication and collaboration tools available, every team needs to find its best approach. We are using combined collaboration tools with Slack being the central communication and integration point, and with the lately added Guru integration.

Be transparent and address real challenge

If you are going to expand your team, make sure everyone is aware of that. If people are leaving to pursue other career opportunities, make sure to announce that early enough. If the numbers are challenging, make sure all team members understand it, and then give them a chance to contribute. And there is no better place to summarize all of that, than during an offsite. One might think that the Product development team cannot contribute to your sales goals, but that just might be a mistake. As part of the Revenue (Sales & Marketing) team, I was overwhelmed by the great input that came from our Product Team in terms of how to reach our goals. A fresh, yet still internal perspective, can do wonders.

We also added an edge to the internal perspective, by inviting our soon to be colleague to join the team offsite. While the offsite took place starting from January 21st, our colleague will join us by the end of February. It was another fresh perspective that added much value to our planning.

Part of the wetransform team doing an OKR excercise in the kitchen

Have a clear agenda and plan some fun time

Do not push the fun activities. You cannot force fun. No one can… except for the Try not to laugh challenge videos, but that is different.

But you can prepare the agenda, so it has time for fun and team bonding and development. In our case, options included skiing, sledging, or a simple walk in the snow. People are different and so is their perception of fun – respect that. Also, make sure that everyone knows the agenda and what the ground rules are. For us, we developed a simple and clear code of conduct that was shared among all team members – input was always very welcome.

If you’re still looking for a super effective team development activity, here is our tip: cook and eat together. Who knows, you might just discover a hidden talent that adds value to the team.

When a company leadership plans a team offsite, they think about questions like: are we on track? Are we going to reach our goals? Are the teams performing as we’d like them to? But, is there more to a team offsite, or should we really and only expect never ending presentations, weird team building exercises and forced fun activities? I have been to over 20 team offsites; some good and some bad, but they would all somehow fit the pattern mentioned above. Until this January, that is.

In July 2017 I joined Wetransform, a startup in Darmstadt, Germany specialized in (spatial) data harmonization with a focus on the INSPIRE implementation. As in many startups in the IT industry, the team of ten people is agile and flexible, often wearing several hats and representing different roles at the company. Wetransform also supports remote work, so we have team members in the Netherlands and Switzerland and cities like Cologne and Frankfurt, while other team members simply work from home in Darmstadt to better align family and work life.

Frankly, the responsibilities get mixed up from time to time, especially when we have new members joining the team, and the responsibilities might become, well, fluid. So, as our team grew, we needed to implement more structures and to define the roles better. In September 2017, all team members received a team offsite invitation to spend four days in Bezau, a small ski resort in Austria for our annual team meeting.

Sonderdach: Wetransform offsite workshop

And there it was, the first difference, at least from my experience: everyone was going to the offsite. No filters in the invitation, no exceptions, no office manager left behind. Everyone was included and invited!

After that offsite, I decided to share my key learnings, with a fair note that most of it rather applies to teams with up to 20 people. For larger teams, there will be different aspects to consider.

Plan ahead

It is easy and somewhat tempting to pack the agenda for the team offsite full of information and data to be processed. After all, it is a unique opportunity to have all people at the same place, not doing business as usual and therefore being able to process all that information in the two days away from the office. Well, it is not. If people must process this super huge amount of data, when will they have the time to discuss and act on it?

This is why we decided to plan two months ahead and assign some homework to all team members. When the team was at the offsite, they already had the bits and pieces needed for further work.

There are many different methods for this, but simple exercises such as preparing company outline materials (yes, numbers and goals are included, you cannot get around that) and then asking all team members to create 2-3 slides with some specific inputs will do the work.

Everyone is invited

When announcing and implementing structural team changes, make sure to pass that information through the team channel. Every change is more likely to be accepted and implemented if team members are included from the beginning and if they have a chance to contribute to the changes. At Wetransform, we decided to restructure our teams and define the roles better, so that everyone knows who is responsible for what and who can contribute to it. With that in mind, we sat together and drafted our internal Service Level Agreements (SLAs) between the teams. Those SLAs will then be signed off by the teams and implemented.

For example, we want to ensure that we deliver high quality service and products to our customers. If Wetransform as a company wants to achieve this goal, all team members need to have a clear picture of the team capacity, scope of work and client needs. And, all of that needs to be very well aligned with our products and services – no overpromising, no missed opportunities! Again, there are many methods on how to align the company goals with the team goals and responsibilities. At Wetransform, we decided to use the OKR method.

Think about your customer

Yes, of course, the purpose of every company is to reach defined metrics and goals in terms of revenue and sales and to make some profit at the end. And for that you need products, services and a brand. However, all of this will not be worth much without a customer who needs and likes your offerings. We used the team offsite to reach a shared understanding of that, both customer and non-customer facing roles alike. Everybody should have clarity on what is important for the customers and how they can address their needs.

At Wetransform, one of our core values is that everybody in the team knows what all others are contributing to the team and to the customer’s success. We don’t want to have siloes or, even worse, internal conflict lines e.g. between revenue and product teams. It’s also important to us that whatever internal communication would become public, we could be proud of it.

This alignment should not just be an exercise for the offsite, but has to become part of the team’s habits in day-to-day work. A well-founded, open and clear team collaboration is the foundation for this part. With many communication and collaboration tools available, every team needs to find its best approach. We are using combined collaboration tools with Slack being the central communication and integration point, and with the lately added Guru integration.

Be transparent and address real challenge

If you are going to expand your team, make sure everyone is aware of that. If people are leaving to pursue other career opportunities, make sure to announce that early enough. If the numbers are challenging, make sure all team members understand it, and then give them a chance to contribute. And there is no better place to summarize all of that, than during an offsite. One might think that the Product development team cannot contribute to your sales goals, but that just might be a mistake. As part of the Revenue (Sales & Marketing) team, I was overwhelmed by the great input that came from our Product Team in terms of how to reach our goals. A fresh, yet still internal perspective, can do wonders.

We also added an edge to the internal perspective, by inviting our soon to be colleague to join the team offsite. While the offsite took place starting from January 21st, our colleague will join us by the end of February. It was another fresh perspective that added much value to our planning.

Part of the wetransform team doing an OKR excercise in the kitchen

Have a clear agenda and plan some fun time

Do not push the fun activities. You cannot force fun. No one can… except for the Try not to laugh challenge videos, but that is different.

But you can prepare the agenda, so it has time for fun and team bonding and development. In our case, options included skiing, sledging, or a simple walk in the snow. People are different and so is their perception of fun – respect that. Also, make sure that everyone knows the agenda and what the ground rules are. For us, we developed a simple and clear code of conduct that was shared among all team members – input was always very welcome.

If you’re still looking for a super effective team development activity, here is our tip: cook and eat together. Who knows, you might just discover a hidden talent that adds value to the team.

(more)

Many people who create GML, and in particular INSPIRE GML, hit some common challenges around identifying features. In part, these come from technical requirements of XML/GML, and in part they come from INSPIRE requirements.

An INSPIRE feature will generally have three properties that identify objects, each with a different purpose:

gml:id: This is the mandatory XML element ID, and it is encoded as an attribute of the element. It is used to uniquely identify that element in the current document, and serves to identify the target object of an Xlink. It has to match a defined pattern, e.g. it must start with a letter or underscore. It is first and foremost a technical identifier, though it should be stable over time (e.g. over multiple transformation runs) and should thus be grounded in a property of the source feature. Only if it is stable over time, Xlink references across documents can actually work. The gml:id is used by the WFS standard query GetFeatureByID.

inspireId: This is a specific, often mandatory, complex property of INSPIRE objects, which consists of three sub-properties - localId, namespace, and version. The INSPIRE ID should be stable, and is usually used to clearly identify the object in its specific domain. Often, existing keys are re-used 1:1 as the localId.

gml:identifier: This is the optional external element ID, i.e. it should include a namespace to make it globally unique, not just in the current document. It is a standard property of all GML objects, it is encoded as an element, and is of the type gml:CodeWithAuthorityType. This is also a technical identifier which should be stable over time. INSPIRE recommends to use the namespace and localId from the inspireId to build the identifier, and INSPIRE identifiers use this codespace: http://inspire.ec.europa.eu/ids

Many people who create GML, and in particular INSPIRE GML, hit some common challenges around identifying features. In part, these come from technical requirements of XML/GML, and in part they come from INSPIRE requirements.

An INSPIRE feature will generally have three properties that identify objects, each with a different purpose:

gml:id: This is the mandatory XML element ID, and it is encoded as an attribute of the element. It is used to uniquely identify that element in the current document, and serves to identify the target object of an Xlink. It has to match a defined pattern, e.g. it must start with a letter or underscore. It is first and foremost a technical identifier, though it should be stable over time (e.g. over multiple transformation runs) and should thus be grounded in a property of the source feature. Only if it is stable over time, Xlink references across documents can actually work. The gml:id is used by the WFS standard query GetFeatureByID.

inspireId: This is a specific, often mandatory, complex property of INSPIRE objects, which consists of three sub-properties - localId, namespace, and version. The INSPIRE ID should be stable, and is usually used to clearly identify the object in its specific domain. Often, existing keys are re-used 1:1 as the localId.

gml:identifier: This is the optional external element ID, i.e. it should include a namespace to make it globally unique, not just in the current document. It is a standard property of all GML objects, it is encoded as an element, and is of the type gml:CodeWithAuthorityType. This is also a technical identifier which should be stable over time. INSPIRE recommends to use the namespace and localId from the inspireId to build the identifier, and INSPIRE identifiers use this codespace: http://inspire.ec.europa.eu/ids

Here is a complete example for a feature with all three properties:



The following guidelines on how to form these different types of IDs are partially based on the guidelines that the German AdV (Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder Deutschlands) has developed. We’ve used those successfully in hundreds of transformation projects.

Namespaces

Both for gml:Identifier and for the INSPIRE ID, you will need to define a dataset namespace. The dataset namespace needs to be unique within all of the INSPIRE infrastructure, and will be used for one data set only. There are generally two common patterns for these namespaces:

  1. Technical namespace: There is one central namespace for all resources in your local spatial data infrastructure. All resources get a technical identifier, such as a UUID, which together with the registry URL, forms the dataset namespace, such as in this (fictitious) example: https://www.nationaalgeoregister.nl/c4b137b8-2317-42c2-aced-204c4216d68d
    Such namespaces are easy to generate, and collisions are very unlikely.
  2. Semantic namespace: A semantic namespace identifies the data owner, as well as some properties of the dataset, such as the INSPIRE theme it belongs to, and what data it was derived from. This is a real example: http://www.swisstopo.ch/inspire/au/4.0/swissboundaries3d/

Both approaches have some advantages and disadvantages, so it comes down to what you want to achieve by using the namespaces. For all kinds of namespaces, there is often a national or regional registry (such as the GDI-DE Registry) where INSPIRE implementers have to register their organisation and dataset namespaces.

General Rules for IDs

In most situations, we recommend to have the values for gml:id, localId and the local part of the gml:identifier to be identical. Since we often generate multiple INSPIRE objects of different INSPIRE Feature types from one source object, we need to differentiate these objects and thus prefix the domain key with the INSPIRE type name, e.g. like this:

AdministrativeBoundary_932817

We used both underscores and points to separate the INSPIRE type name from the domain key, there is no inherent difference. The domain key has to be a unique property in all source objects, or it has to be generated. Using a unique source property is highly preferred, as only that guarantees a stable ID over multiple transformation or generation runs.

In some cases, the source objects have a unique domain key that uses a problematic format (e.g. containing spaces or backslashes). If uniqueness can still be guaranteed by removing the special characters you can just strip them, otherwise, we recommend to use the source domain key as input to either generate a UUID, or to generate a Hash value. To generate a Hash value, we recommend the SHA-256 algorithm.

This approach has several advantages:

  • It guarantees a valid ID, which needs to start with a non-numerical character
  • It differentiates multiple objects created from one source object
  • It immediately tells a viewer what kind of object this is, which is especially useful in references

The question how you can build references is often the key to determine which source domain key is used best. This requires a stable, reproducible generation method that we can also employ in places where the original source object was referenced. So, when in doubt, your domain key should always be the value that is used in the existing data to create references (e.g. a Foreign Key in a data base table).

Merging objects

There are many cases where we create an INSPIRE object from multiple source objects. As an example, we merge a set of WaterwayLinks to create InlandWaterways. In this case, we still want to create a stable ID for the merged object. We do this by concatenating the domain keys of all the merged objects and then calculating the SHA-256 Hash value of the resulting string. This gives us a long, but still manageable ID:

InlandWaterway_e3b0c44298fc1c149afbf4c8...4649b934ca495991b7852b855

Another approach would be to use the value that was used to group objects as the domain key part. This creates a semantically meaningful identifier, like in this example with a stripped name:

InlandWaterway_DiepwaterrouteDuitslandWestFrieslandNoordHinder

Splitting Objects

In some cases, we need to disassemble a source object and create many INSPIRE objects of the same type from it. The most common use case for this is when the INSPIRE schema only allows simple geometries, and we have to split up a MultiGeometry. In this case, we apply the same rules as for the simple 1:1 creation, but add a postfix to the ID that uses the index of the property on which we split the object. In this example, we look at the 22nd object created from splitting out a source object(we start with 1, not with 0):

WaterwayLink_e3b0c44298fc1c149afbf4c8...4649b934ca495991b7852b855_22

Joining Objects

In a join, we use multiple objects of different source types to form an INSPIRE object. As an example, we might join a Municipality and a District object together to create an AdministrativeUnit with references to lowerLevelUnits. If there is a reason why we can’t just use the domain key of the District, our recommendation is to also use multi-component IDs for this case. In a Join, there is always a “focus” or “root” object, to which matching objects of other types are added. In this example, we try to find all Municipalities belonging to the District, so the District is the focus object. We use the domain key of this root object as we would for a simple 1:1 creation. However, we then add another key created by concatenating the domain keys of the joined objects (the Municipalities), like we do it in the Merge case. This means we take the concatenated IDs of the Municipalities and then create a SHA-256 Hash value, which is then added to the other parts of the ID:

District_241_e3b0c44298fc1c149afbf4c8...4649b934ca495991b7852b855

Summary

Creating stable IDs that can be referenced is somewhat complex. However, we’ve used the rules above as well as some variants over a few hundred projects by now and they work very well. Do you have ideas on who to improve or complement them? Let us know!

(more)

2018 still feels like a fresh year, so here’s a fresh hale studio release to go with this! Despite some large changes under the hood, we’ve decided to make this a bugfix release mostly, with some smaller enhancements:

  • Improved hale connect integration with support for multiple organisations
  • Support for CQL Functions in filter contexts
  • Improved behaviour on missing Bursa-Wolf Parameters
  • Pre-fill charset for shapefile loading when a .cpg file is available
  • Fixed Groovy Restriction state after reloading a project
  • Fixed Un-associating codelists
  • Use a precalculated index created during data loading for Joins and Merges

The whole list is available in the changelog.

Get the latest version, and let us know what you think of it!


2018 still feels like a fresh year, so here’s a fresh hale studio release to go with this! Despite some large changes under the hood, we’ve decided to make this a bugfix release mostly, with some smaller enhancements:

  • Improved hale connect integration with support for multiple organisations
  • Support for CQL Functions in filter contexts
  • Improved behaviour on missing Bursa-Wolf Parameters
  • Pre-fill charset for shapefile loading when a .cpg file is available
  • Fixed Groovy Restriction state after reloading a project
  • Fixed Un-associating codelists
  • Use a precalculated index created during data loading for Joins and Merges

The whole list is available in the changelog.

Get the latest version, and let us know what you think of it!


Improved hale connect integration

This release of hale studio improves the integration with the online collaboration platform hale connect. It is now possible to select which organisation should own an uploaded transformation project for cases where the currently logged-in user is member of more than one organisation. Furthermore, hale studio now supports a relogin with same or different credentials without having to clear the credentials stored in preferences.


Support for CQL Functions in filter contexts

(E)CQL doesn’t just contain simple operators, but also a large set of functions that can be applied to any operand in any place where hale studio enables the use of such filters:

  • Condition contexts on source schema elements
  • Filters on source and target data table views

Filter functions can be used to build expressions such as strToLowerCase(VALUE) like '%m%'. They also simplify many expressions, e.g. through functions such as IN(val1, val2, ...), which needed an OR chain of comparisons so far, or between(val, low, high) statements. It is even possible to use spatial functions to filter by the spatial relationship - contains(geomA, geomB) will return true when geomA contains geomB.

The Geoserver Documentation includes a full reference of the available functions.

This work was funded by the Landesbetrieb Geoinformation und Vermessung Hamburg through a support contract.


Improved behaviour on missing Bursa-Wolf Parameters and on axis flips

When you load source data from shapefiles, and then export the transformed data later on to a different projection / coordinate reference system, you may have encountered an error message like Missing Bursa-Wolf Parameters. More information on this specific issue is available with the GeoTools documentation. Furthermore, there were cases where the axes were swapped due to inconsistent CRS definitions across different systems. With some enhancements to how hale studio interprets and uses CRS definitions from various sources (Shapefiles, GML, internal EPSG database), hale now avoids most of the pitfalls of these two issues.

When loading source data, hale studio now provides the content of the srsName attribute (in case of a GML source) or the WKT definition found in the projection file (.prj) that accompanies a Shapefile. This allows the user to select the correct CRS without having to manually look up this information in the source files.


Character set detection for Shapefiles

Importing a schema or source data from a Shapefile requires the user to select the encoding of the Shapefile. In cases where the Shapefile is accompanied by a Codepage file (.cpg), hale studio can now read the encoding from that file a prefill the character set selection dialog.


(more)

One of the big debates surrounding INSPIRE in 2017 centers around the fitness for purpose of the INSPIRE data specifications. Earlier this year, the Germany National Mapping and Cadastral Agency BKG thus asked us to perform a study to identify practical issues in the INSPIRE data specifications that make implementation and usage harder. They also asked us to document recommendations on how to improve on the Technical Guidance and the Implementing Rules.

As you might know, one of our company’s goals is to help make standards better. For us that means that we use data-driven, analytic approaches to identify places of overspecification or underspecification as well as inefficient or overly complicated data structures. We also systematically look for mismatches between existing data and the targeted implementation platforms. In earlier posts, we’ve described some of the methods we use for that.

One of the big debates surrounding INSPIRE in 2017 centers around the fitness for purpose of the INSPIRE data specifications. Earlier this year, the Germany National Mapping and Cadastral Agency BKG thus asked us to perform a study to identify practical issues in the INSPIRE data specifications that make implementation and usage harder. They also asked us to document recommendations on how to improve on the Technical Guidance and the Implementing Rules.

As you might know, one of our company’s goals is to help make standards better. For us that means that we use data-driven, analytic approaches to identify places of overspecification or underspecification as well as inefficient or overly complicated data structures. We also systematically look for mismatches between existing data and the targeted implementation platforms. In earlier posts, we’ve described some of the methods we use for that.

Methods used in Schema and Data Analysis

The BKG has now published the final version of the report on the GDI-DE website.

In this report, we analyse five data specifications (Buildings, Species distribution, Environmental monitoring facilities, Utility and governmental services and Natural risk zones) from two perspectives:

  • Is there unnecessary complexity in the technical guidance that hinders adoption by users?
  • Do the specifications really support key use cases such as e-reporting or COPERNICUS in-situ data provision? We specifically looked for patterns that would be problematic for use cases such as Data Management, Data Exchange, Data Transformation, Data Analysis in a Desktop GIS and Data Publishing through INSPIRE Services.

In the report, we describe proposals where the INSPIRE Implementing Rules or Technical Guidance can be amended to ensure the interoperability of spatial data sets and services with reasonable efforts for the authorities concerned. The proposals include concrete references to alternative encodings and simplifications (e.g., multiplicity, voidable, flattening, data type).

Resources:

(more)

Smart Cities are fundamentally about accessible data, situational awareness, resilience and decision support. They connect citizens with their cities’ infrastructure and administration, and enable them to drive their development. A successful Smart City implementation will help decision makers to reach out to the citizens, collect valid and trustworthy data and to make better decisions.

Smart Cities are fundamentally about accessible data, situational awareness, resilience and decision support. They connect citizens with their cities’ infrastructure and administration, and enable them to drive their development. A successful Smart City implementation will help decision makers to reach out to the citizens, collect valid and trustworthy data and to make better decisions.

In a Smart City, citizens have a higher life quality. It covers aspects from where to build schools and emergency centres, to reducing emissions, to building resilience to acute events or long-term challenges such as climate change. Being data-driven, is it important to increase the interoperability and reusability of the data, apps, and services developed in Smart Cities projects, and by implementing INSPIRE we can do so.

The INSPIRE Directive establishes rules for a spatial data infrastructure. When implemented, it makes data more visible, shareable and usable. Its focus lies on spatial data necessary to support policies that affect the environment, like transport, agriculture, hydrography etc.

Since 2016, the INSPIRE specifications also include standard interfaces and data models for real-time information, in particular related to utility networks, environmental information and to transport networks.

In many cities such as Hamburg and London, INSPIRE and Open Data initiatives are implemented hand in hand. Together, these can form the basis for sustainable Smart City infrastructures. As of today, many Smart City projects are islands.

Data once collected through different Smart Cities projects should be reusable and interoperable, so we need to harmonize that data and make it available for researchers, decision makers and citizens. By implementing INSPIRE standards we can do so and increase the value of data collected and validated. Several current projects such as smarticipate and GeoSmartCity follow this approach already.

INSPIRE implementation is not without its challenges as well. It has been criticized on two fronts – implementation complexity and limited usefulness. By making INSPIRE part of Open Data, Smart City, Spatial Planning and other initiatives, the value of INSPIRE becomes clear to more stakeholders.

With the right tools and solutions, INSPIRE implementation is not more expensive or complex than other data infrastructures. It is possible to transform and harmonize data in a simple workflow, as well as it is possible to publish services within seconds.

We strongly believe that implementing INSPIRE can be easy, with fully integrated, hybrid cloud solutions. To show you how a sustainable and effective INSPIRE implementation can look like, we developed a guide that will take you through the process step-by-step.

For a more practical approach, you can always reach out to us at info@wetransform.to and book your online demo session for implementing INSPIRE with INSPIRE GIS.

(more)