SDTS was designed as a data interchange format to allow GIS users to exchange geographic information between product platforms. The down side of SDTS is that you must first convert your data to SDTS format before anyone can “re-convert” it to their GIS platform—and even then the target GIS must have the capability to do so.

This approach is hardly the shortest distance between two points; it is a lot like having to go from Washington, DC to Boston via Chicago. This standard may be fine for archival purposes but it is, to say the least, time consuming. Additionally, SDTS is large because it stored in the bloated but universal ASCII format. Think of it as the DXF^3 of GIS.

SDTS format could be a boon to our OEM friends since earlier GIS packages didn’t have this data format. This is because the only way you could access SDTS would be by using the latest, greatest version of a company’s GIS package. Let’s all say the word “UPGRADE.” I guess SDTS could have been a stand-alone tool, but generally SDTS isn’t available that way. In fact, only the most entrenched government GIS suppliers actively participate in the SDTS program, which by the way is mandated by the federal government for its agencies that use mapping software.

Nonetheless, SDTS hasn’t caught on, even in government circles. Even our own Census Bureau is still in its BETA release of TIGER SDTS data format. Heck, the federal government even provides a C++ library which costs all of zero dollars – could it be any easier?

On another front, there is an organization that is working to bring a fresh approach to this “enlightened” state of data exchange. It is known as the Open GIS Consortium. The consortium was formed to address these very same issues of technology interchange but in a “designed” architecture. What is unfortunate is that while the consortium’s membership list is extensive, its compliant product list is not. It seems that organizations are sitting on the sidelines, monitoring what may happen rather than actively promoting the initiative (if I am mistaken, it isn’t apparent on the consortium Web site).

With all this interest in an environment that will allow for the unencumbered exchange of information, why hasn’t it happened? There must be a simple explanation. The OEM’s state that they love the idea of data interchange and everyone seems to agree that the world would be a better place with interchangeable data. Still, we seem to be stuck with “proprietary data.”

Proprietary data formats are, after all, how companies protect their intellectual investments as well as endear their users to their platforms. Of course, proprietary data formats are not created for that sole purpose (at least I hope not). They are optimized, compressed, and structured in a way that best suits the style of the program’s intended usage.

For instance, applications that provide for user editing capabilities have their records “padded” with extra placeholders to allow for node movement. Applications that do not provide these capabilities are smaller and more restrictive in their use.

Whatever the reason, whether it is editing/processing optimization or simply market domination, these proprietary formats are the single largest reason why we do not have any “real” data interchange. We do, however, have open export formats, which for some unexplained reason always seem to come up short in the translations.

It is my hope that with the advent of recently-passed federal legislation (the Digital Millenium Copyright Act), it is now possible for the GIS OEM’s to peek under the sheets of their counterparts’ data formats. Perhaps they will even create tools and applications which can directly read each other’s native (proprietary) formats – the ultimate in data importing. It would be yet another opportunity to allow OEM’s to let us all say the word “UPGRADE.”

The Digital Millenium Copyright Act opens the door for platform compatibility, but it is not an open season on software copyrights. In an article posted in the Geeklawyers Web site (see link below), Sarah W. Salter, a professor at the New England School of Law, wrote:

“Reverse engineering is permitted solely to provide "interoperability" - defined as intended to allow software to read or be read by other software. Thus reverse engineering to diagnose and design protection against viruses, for example, is subject to criminal prosecution as well as civil damages.”

-Sarah W. Salter

The message couldn’t be clearer, the legal barriers have been lowered, so let the move toward compatibility begin!

With any luck, our OEM friends will now release products and technologies to meet our needs, that “Holy Grail” of data compatibility. Best of all, our OEM friends can finally capitalize on all that secretive backroom “reverse-engineering” that was done under the guise of “competitive analysis” and other terms commonly used when sneaking a peek under the copyright restricted sheets of their competitors.

Actually, I don’t really care what they do, I just wish they would do something – something that makes our data translations easier and more effective. Clearly, with the technical and legal barriers removed, it would be hard to understand why any organization wouldn’t participate towards this goal.