Welcome to GISWeekly! This week's GISWeekly will feature an interview with Safe Software's President Don Murray and Vice President of Development Dale Lutz.
GISWeekly examines select top news each week, picks out worthwhile reading from around the web, and special interest items you might not find elsewhere. This issue will feature Industry News, Alliances/Acquisitions, Announcements, Awards, Appointments, New Products, Featured Downloads, Around the Web, and Calendar.
GISWeekly welcomes letters and feedback from readers, so let us know what you think. Send your comments to me at Email Contact
Susan Smith, Managing Editor
What the Latest from Safe Software Means...
Safe Software Inc. has been in the news recently with its new advanced spatial ETL (Extract, Transform, Load) technologies as well as its newly released enhanced version of the Feature Manipulation Engine (FME) Geographic Data Files (GDF) reader to support TeleAtlas MultiNet 3.2 GDF (ASCII) sequential datasets. This ensures compatibility between the FME GDF reader and the latest TeleAtlas MultiNet 3.2 product offering. FME also supports the reading and writing of many GDF variants, and it includes a viewer to facilitate viewing and querying GDF files.
In another announcement, Safe Software's FME technology was chosen by Dotted Eyes in the United Kingdom to be embedded in its SuperpOSe product. SuperpOSe is used to process the Ordnance Survey's OS MasterMap GML-2-based digital data product, and load it into spatial databases. A supplier and developer of a wide range of GIS applications, Dotted Eyes chose Safe Software's FME technology because it supports a large number of databases, as well as being flexible and fast.
GISWeekly spoke with Don Murray, the President of Safe Software, and Dale Lutz, the Vice President of Development, about these developments.
What is the significance of these most recent announcements?
Dale Lutz -- One significant point relates to our GDF support, and the other significant point relates to the Ordnance Survey's MasterMap. Both are important and non-trivial technologies. The GDF format is a very complex format that has a lot of information in it; similarly, the Ordnance Survey MasterMap is also very rich. These two formats demonstrate that our product, FME, is able to cope with both these very complicated types of systems as well as the so-called simpler ones. Often when people think of moving files or transforming data, they think of simple format-to-format translations that don't involve a lot of complicated information. These two formats are definitely not in the simple category.
Can you describe what you have to do to make the translation possible with the more complicated format?
The GDF specification by itself is very thick - more than 1500 pages - so we need to understand it well enough to make sure our software can cope with every bit of information that the specification contains, and then support that completely. End users can decide which parts of the file they want to keep, which parts they want to throw away, and which parts they want to store in certain areas of their database. What's important for us is not only the physical reading and writing of that file, but also the understanding of the GDF specification so that we can present it to users in a way they can understand and use.
Is this a translation or a transformation?
When people use our product with both the GDF and the Ordnance Survey MasterMap formats, they will use it to do two things: The first is to figure out which part of the data they want to keep (similar to data modeling). We call this setting up a transformation, and we provide FME Workbench for this phase. Once users have set up their transformation, the second step is to run it and perform the actual translation. This step would often be run on many, many different input files, as users may be working with the entire UK (in the case of OS MasterMap) or all of the cities in North America (in the case of GDF), for example.
Does it take a very long time to run the translation and/or is it invisible to the user?
This comes down to how experienced a user is with the data they're going to be working with. About a year ago, someone was trying to load GDF data into ESRI SDE. They were unfamiliar with GIS, GDF, and SDE, and so they had a very difficult time. The tool wasn't the problem - the problem was that there were hundreds of tables and attributes involved and these needed to be handled properly. In such cases, our professional services team is available to provide expertise, and this can save an organization a great deal of time and money. If, on the other hand, the user is someone who works with this type of data all the time and understands the domain area, they are able to produce results pretty quickly with our tool.
The amount of time required to do the extract, transform, and load varies. Because the files are very massive (for example, the typical GDF file can be hundreds of megabytes, or even a gigabyte), and if you run a bunch of translations at once, it's going to take time that is measured in hours - or even, in some cases, days. We often joke and say that when we started in 1993, people would say it's a big file if it barely fit on a floppy. Now a big file doesn't fit on a CD or even DVD.
Don Murray - The Ordnance Survey, for example, distributes the data in a compressed GML format on DVDs. That's what is going on - large datasets for both formats.
So, are the other very common file formats from AutoDesk and ESRI not as thick in terms in content as the GDF and Ordnance Survey formats?
With GDF and the Ordnance Survey MasterMap formats, it is up to the defining organization to decide how much information to put in, whereas with the ESRI or AutoDesk formats, you are talking of general tools and each end user can define as complicated or simple a data model as they want. For MasterMap, the data model is maintained by the Ordnance Survey with a mandate to provide a very rich data set for their entire country, and in the case of GDF, a standards group sat down and asked the question, “What's the complete set of all the things we could need for our application?” That's why these things are so full-featured.
End users of GIS products could certainly make a model that was that complicated. Those using GDF often do make an exact mirror of the model in their GIS or database system. However, although the common GIS formats can definitely get very complicated, it's not typical.
Are you incorporating the GML capability in all these releases?
Ordnance Survey data is actually a flavor of GML and GDF currently is not based on GML. There is however, talk of a future version of GDF being done in GML; if this happens, we will be supporting it. FME has supported GML reading and writing for some time.
What are some of your future directions?
We will be adding support for more formats as well as putting effort into improving the user interface experience. With our Workbench product, we'll make it a lot easier to perform complex operations for our users in a graphical environment.