It’s About Place (Part 2)

by Cal McElroy, Guest Author

In a previous post, I suggested that integration of search and location technologies was a difficult problem, that has not been solved. To provide some context for this series on local search, I want to dig into the technologies a little more.

Location technology emerged out of the computer graphics industry. Over 35 years ago, Jim Meadlock of M&S Computing (now Intergraph) and Jack Dangermond of ESRI, were pioneers in developing software to create digital engineering drawings and maps.

Over the years, there have been many disruptive platform transitions in this industry… from mainframes, to minicomputers (predominantly Digital VAXs with specialized graphics boards), to UNIX-based engineering workstations, to Wintel microcomputers – and finally to web services. Both Integraph and ESRI managed their way through this evolution and are still successful companies today. Of course, with each new platform new players emerged – Autodesk and MapInfo in PC-based software – and MapQuest, Google and others in web mapping services.

Mapping engines have not changed much over the years – with two key exceptions. First, in the early 1980’s software engineers figured out how to dynamically link graphic elements (map features) to information stored in an Oracle database – spawning the age of the Geographic Information System (GIS). This term was actually coined by a Canadian, Roger Tomlinson, in 1964, but it was database integration in the 1980’s that really drove the evolution from mapping tools to geospatial information systems. Web mapping technologies are just starting to face the data integration issues, and related performance problems that have challenged GIS systems for decades.

Secondly in 1994, a group of government GIS users and Intergraph founded an organization called Open Geospatial Consortium (OGC) with a charter to establish open, interoperable standards for exchanging geographic data between and among disparate mapping and GIS systems. Today every major vendor and most major users of location technology are members of OGC. The problem at the time, was that vendors had customers locked into proprietary graphics file formats (like .ppt format for Powerpoint) with important sounding names like; .dgn, .shp, .dwg, and MID/MIF. The solution, which is still emerging within the GIS industry, is to manage map data and location intelligence within commercial databases. Oracle, IBM and Informix all embraced the OGC specifications and developed extensions to their commercial database technology, to handle geospatial data and related indexes.

These developments sparked a major trend in mapping and GIS – towards location intelligence migrating into data (and indexes), rather than relying on mapping software to understand geographic relationships.

So why is spatial data so special? It is all about objects and indexes. Within virtually all mapping and GIS engines today, graphics features (say neighborhood boundaries or street intersections) must be estantiated as objects, incorporating geometry and geographic attributes, and these objects must be spatially indexed by the mapping engine to enable geographic search. As a result, mapping applications are the only web services that understands location… or “where” objects are in the world.

To compound the problem, mapping systems were never intended to be data management systems or information retrieval engines, with highly-scalable indexes – they lack the means to integrate, aggregate, federate or “mashup” widely distributed content – the way we have come to expect in the web. If we want to find content about a specific place, then the place has to be an object in the mapping system, and the mapping engine must maintain the index and control the access to the content.

This creates a major performance bottleneck when trying to link large volumes of business data or web content (without location intelligence and spatial indexes), to an engine that understands location, to enable geographic search. As such, first generation local search services have been forced to organize the content inside of “walled gardens” where the spatial engine, data integration and search indexes can be carefully managed and optimized. This gap is evident in the massive amount of localized content currently indexed via keyword – as compared to the dearth of content found within Google Maps or Google Earth.

The current fascination with geocoded content will only exacerbate the problem. A myriad of localized content is being layered onto maps, and linked to push pin “objects” in disparate map-enabled applications. There is no master index. These applications depend on the mapping service for geographic search. They also lack a robust ontology for location/place and a reliable taxonomy for information retrieval (other than user generated tags). Try to imagine the global publishing and book distribution industry or library systems without ISBN numbers and the Dewey Decimal system!

While OGC set out to liberate geographic data from proprietary GIS and mapping systems, utimately, they sparked a revolution that will enable location intelligence in any application or web service. To support the evolution to Web 3.0, the “plumbing” of the Internet must support a universal way to organize, find and integrate content, based on location context, without dependence on archaic mapping technologies.

The key to location intelligence must be embedded in the content and index. This concept already exists for the virutal web, in the URL – which enables a cross-reference between keywords in content and a specific “place” in the web. Next up – a place in the real world.

(To be continued)

[Part 1]
[Part 2]
[Part 3]
[Part 4]
[Part 5]
[Part 6]
[Part 7]
[Part 8]

This segment is part 2 in the series : It's About Place
1 2 3 4 5 6 7 8