KEN Interviews: Ken Bragg of Safe Software

To support the work of the INSPIRE Knowledge Exchange Network, I have started to interview schema transformation software providers, specifically those who took part in the INSPIRE KEN workshop. These interviews provide a starting point for comparing strengths and weaknesses of different approaches and outline best practices for phases such as design, development or maintenance. I conducted the first interview with Ken Bragg, who is the European Services Manager for Safe Software. Safe Software are the makers of FME, perhaps the most the well-known spatial data translation and transformation tool.

TR: What was the big idea that led to the development of FME?

Ken: We believe you should have complete mastery of and access to your data where and how you need it. FME lets you transform your data to use and share.

TR: What is the main strength of your software? What are you particularly proud of?

Ken: FME supports over 300 data formats and enables users to transform data in limitless ways. We are proud of the way our users simply love working with FME and become incredibly enthusiastic about our products.

TR: For which problems or use cases is it particularly well suited? What differentiates it from other products or solutions?

Ken: FME is very well suited for virtually any kind of data transformation including: format, coordinate system, schema and content transformation. No other product supports the range of formats and transformers supported by FME.

TR: On which phases of a schema transformation project does you software focus?

Ken: FME is well suited for format transformation, coordinate system transformation and particularly attribute mapping including name, values and data type mapping.

TR: Describe (ideally use a concrete example) how users of your software should design the schema transformation in a project.

Ken: Many of our users use FME to migrate data from their own format and schema into an Inspire INSPIRE staging database for example ArcGIS Inspire Geodatabase. This transformation can be designed and edited in FME Workbench which is an easy to use and mature graphical environment. The design can be documented within FME Workbench and saved or edited as an FME Workspace file.

TR: What you are saying is that there is no explicit design step, right? The implementation of the project is the design?
Ken: Yes you’re right – there is no explicit design step.

TR: Describe (ideally use a concrete example) how users of your software develop the actual schema transformation. Which tools do they need, which knowledge should they have?

Ken: FME Workbench is the key tool we use to develop schema mapping. The basic steps for defining a transformation into an Inspire INSPIRE staging database transformation are as follows:

  1. Add a reader to the source data in whichever format it exists into FME Workbench. This will add the source feature types and their schema into your Workspace.
  2. Add a writer to the destination database and import the required destination feature types and their schema from an existing database or template.
  3. Define the schema mapping by connecting the feature types and using FME transformers such as AttributeRenamer, AttributeCopier etc. Or use the SchemaMapper transformer in FME to read a set of mapping rules from a table or spreadsheet.

A domain expert in the source data is required to perform the actual mapping and some knowledge of FME Workbench.

TR: Describe (ideally use a concrete example) how users of your software should debug and validate the schema transformation process they have developed. Again, which additional tools and knowledge do they require?

Ken: Errors in the transformation process (using the above example) can be easily trapped in FME Workbench by disabling and enabling connections and then using the transformers DataInspector and Logger to see features at various points in the transformation. Break-points can also be created by inserting Inspection Points along connections.
Output data can be validated with other FME Workspaces which can verify schema, attribute values and geometry.

TR: Describe (ideally use a concrete example) how users of your software should document a schema transformation project.

Ken: FME Workbench includes annotation tools for any objects in the canvas and for general annotation. For example in an Inspire INSPIRE schema mapping workspace we might annotate a StringConcatenator transformer to say this is where the _NationalID is defined. Workbench also includes a rich set of “Workspace Properties” for metadata such as data, history, usage, requirements, etc. These can be edited in a Workspace Properties dialog.

TR: Describe (ideally use a concrete example) how users of your software should maintain a schema transformation project.

Ken: Schema transformation workflows are maintained in workspaces which can be edited at any time. Also, if the SchemaMapper transformer is used then the mapping rules can be maintained in database tables or spreadsheets if preferable.

TR: Do you have any best practices when it comes to versioning or even merging workspaces?

Ken: No, there aren’t really best practices around versioning or merging workspaces yet. This is something on our list of things to do.

TR: Classify your software according to the criteria given in this article.

  1. FME uses a procedural paradigm for schema mapping
  2. FME can be both schema and feature driven depending on the transformation defined in FME Workbench
  3. FME uses a graphical representation for defining workflows
  4. Arguably FME is completely Expressive when it comes to Inspire INSPIRE transformation requirements.

TR: Please give an example of a schema transformation project in the INSPIRE context using your software.

Ken: BKG (German: Federal Agency for Cartography and Geodesy) uses FME to perform schema mapping from ESRI Esri Geodatabases into Inspire INSPIRE staging Geodatabases or EuroGraphics datasets.

TR: What do you think of creating a schema transformation standard language, e.g. in the OGC?

Ken: In my personal opinion this would add an unnecessary layer of complexity and abstraction to schema transformation.

TR: Anything else that you would like to explain? Future plans for the software? The next big thing?

  1. FME’s GML writer for FME 2014 fully supports XSD schema driven GML writing
  2. FME Server 2014 has an improved Streaming Service which allows flexible support for workspace drive WFS and other Web Services.
  3. FME already supports the 3D, AIXM and raster features which will be required in Inspire INSPIRE Annex III
  4. FME can support Application Domain Extensions (ADE’s) for CityGML which should also ease productions of 3D Building datasets for Inspire INSPIRE Annex III.

TR: Thank you very much, Ken!

Leave a Reply

Your email address will not be published. Required fields are marked *