Our company, Spatial Business Systems, recently hit a milestone of having placed our 500th license of the SpatialBiz Plug-In for FME (also called the “Smallworld Plug-In for FME”) in production with a client of ours. When we developed the product over 10 years ago we didn’t realize it would become so popular in the Smallworld user community. As the product has continued to evolve we have extended and complemented it to support more advanced capabilities such as supporting synchronization between Smallworld and other spatial databases as well as extensive work in extracting the Smallworld network model so it can be populated into other systems.
Here at SBS we often get a lot of questions about migrating data out of Smallworld so I thought it would be good to highlight some of the top things to consider when getting data out of Smallworld. Whether or not you are trying to do data migration, synchronization with another GIS, or to support an application interface these considerations should be helpful. Here goes…
Understand that Smallworld is quite different
Smallworld does not have a specific format. It is based on a database called Version Managed Data Store (VMDS). We’ve received many requests over the years to simply translate the data base files (.ds files in Smallworld). It doesn’t work that way, and a user needs to have a valid Smallworld license.
Smallworld also has a significantly different data model than any of the GIS products in the marketplace. It is highly object oriented which creates some interesting, and different constructs to deal with. The illustration below shows a copy of the Smallworld object model. This very dated diagram, while still valid, points out some interesting things, such as the fact that objects can be complex, consisting of points, lines and areas, all within a single object. These “multiple geometries” can really change the paradigm when designing data migration approaches.
Some information that normally would exist in a GIS database may actually be contained within the behavior of the Smallworld model. This requires the ability to interrogate the Smallworld database as part of the migration process.
There is More Than You Can See
Smallworld has many different aspects to their model so it is important to make sure that you do not leave out critical information. The key elements in Smallworld, the objects, are referred to as Smallworld RWOs (Real World Objects). The RWOs contain the visible graphic elements, but there is much more information included in the Smallworld model. Dataless_RWOs (which represent objects without graphic information) need to be considered, the user_tables and then all physical, relational, logical, spatial and topological fields. Smallworld join fields are particularly critical. It’s not uncommon for some organizations to write simple translation programs, or attempt to rebuild Smallworld data from extracts of Esri shapefiles or Autodesk dwg files, which can be readily extracted from Smallworld. Unfortunately, these approaches leave out a lot of important information contained within Smallworld.
Geometry Mapping Identifies Key Differences
While the end mapping products may look the same to the casual viewer, there are some fundamental differences that exist between the geometric representations in Smallworld and other GIS products. When performing data interchange between these products it is important to have a very accurate modeling of the differences that exist between the respective geometry models of the two systems. This is quite pronounced when modeling linear geometries. For example, the use of Smallworld circular arcs, tangent-point arcs and rational b-splines has to be carefully mapped to the Esri geometry model, which relies upon Bezier curves to model curved features.
Smallworld Topology Model
One of the key features of the Smallworld system is the rich and technically unique topology model. For networked utilities the topology model offers behavior that enables many critical business applications. This topology model is not extracted during the typical data translation process unless the specific tools are in place to gather this behavior. The translation tools must have the ability to extract topologic information from the source Smallworld database so that the information can be used in other systems. As with the geometry mapping described earlier, extracting this topologic data has a profound impact on the quality of the translation and reduces the overall cost and timeframe to do a quality data exchange. This serves to leverage the significant historical investments that have been made in developing an accurate Smallworld database.
Internal Worlds Contain Valuable Information That Must Be Preserved
Smallworld internals (also called internal worlds) can be used to represent subsystems within a utility or telecommunications environment. They are commonly used to model substations, complex switches, valve stations and inside plant. To have an effective data interchange it is necessary to identify the internal worlds and represent them as meaningful constructs within the target system.
Since most other products do not have a concept of internal worlds it is necessary to be able to either re-project the internal world information to the real world coordinate system, or to create a new coordinate space to hold this information. It is also important to maintain connectivity between the different “worlds”. On more than one occasion we have been contacted by organizations that have attempted to migrate their data only to find that they did not have a way to get at the very rich internal data within their system.
Dimensioning
Dimensioning is very unique to the Smallworld product and represents an added level of complexity when doing any form of translation work. In addition to traditional dimensioning Smallworld also has more complex constructs such as circular and angular dimensions. Dimensions are a critical element of any utility map since they have such significant impact on the readability of the document. In the utility environment this can have important safety implications for workers that use map-based documents.
And All the Other Critical Things That Make It Work.
Being able to translate all aspects of the geographic data is rarely enough. In addition to the above items it is necessary to be able to do the job right.
- Change detection (ability to manage additions, insertions, updates and deletions)
- Support for Smallworld metadata such as styles, the ACE database (contains visibility and other configuration data),
- Smallworld plot templates and symbology stroking
- Support for Smallworld version management
- Use in a services-based environment
- Error logging
Thanks to the team at Safe Software!
This post wouldn’t be complete without recognizing the role of Safe Software and their flagship FME product that is used as a basis for the SpatialBiz Plug-in for FME. FME provides a rich set of building blocks that enable advanced translations of spatial information to occur. More information on the Safe team can be obtained at www.safe.com. As always, please reach out to all of us at Spatial Business Systems, www.spatialbiz.co, with any questions you may have.
