The availability, cost, quality and timeliness of data are salient concerns to all business geographics professionals-but especially to those in the real estate industry. The reason is that real estate is essentially a game of information arbitrage. Unlike other asset classes (e.g., stocks, bonds, gold), each property is unique. The more one knows about everything that is on, under, above, and around a given site, the greater the likelihood of a sound investment decision.

Accordingly, this year my real estate columns in Business Geographics will focus on data. (During 1993 and 1994, my real estate columns focused on business geographics applications in brokerage, appraisal, mortgage underwriting, asset management, and various other segments of commercial and residential real estate.) Real estate data falls into four broad categories, each of which will be the subject of a column: internal attribute tables, external attribute tables, digital maps, and imagery. We begin with internal attribute tables.

A fundamental characteristic of Geographic Information Systems (GIS) is the linking of attribute tables to digital maps. In attribute tables, the rows correspond to geographic features on the digital maps; the columns are variables, i.e., what is known about each geographic feature. For example, if a digital map contains census tracts, then each row of the attribute table would be a different census tract and the columns would be the number of households, per capita income, etc., of the census tracts. Similarly, the digital map could depict the locations of several properties, and the attribute table could encompass each property's size, current ownership, year built, and so on.

"Internal" attribute tables, as used here, are a real estate organization's proprietary, geographically-specific data. Such information typically includes the following:

• Market data on historic, current and projected trends in vacancy rates, asking rents, absorption, etc., summarized at the metropolitan, city, and/or submarket levels;
   
• Descriptive data on individual properties, including the street address, number of stories, floor area ratio, type of construction, number of parking spaces, and so on;
   
• Transactions data on individual properties, such as when the property last sold, the buyer, seller, selling price, cap rate, and financing terms; and
   
• Transactions data on individual leases, encompassing the lessor and leasee, square footage, number of years, concessions, improvements allowance, sharing of costs (e.g., a triple net lease), revenues (e.g., an overage rent clause), etc.

Internal attribute tables can build upon data acquired from private sector vendors and government agencies; these sources will be discussed in the later column on "external" attribute tables. Internal attribute tables derive mainly, however, from a real estate organization's own primary data collection efforts and business operations. Examples include: appraisers keeping files on every property that they have valued; brokers tracking the terms and expiration dates of every lease they have been involved in; bankers monitoring the pro formas of past mortgage commitments as well as new mortgage applications, and so on. The bottom line is that a real estate organization's internal attribute tables are its family jewels, its trade secrets, the key to its competitive position; again, real estate is a game of information arbitrage.

 How does a real estate organization input its internal attribute tables into a GIS? Three general possibilities exist:

1. If the organization is enhancing data from a third party source, the information might already be in GIS format , i.e., attribute tables are already linked to digital maps. For example, the organization might have purchased a digital census block group map of a city and corresponding socioeconomic data in an attribute table. Depending upon the GIS software, the real estate organization can most likely expand the number of columns in the attribute table and input additional data, such as the total number of commercial properties in each block group; the attribute table can either be expanded electronically by importing the data from whatever non-GIS software currently contains the information (e.g., Lotus 1-2-3, dBase, Oracle), or might have to be expanded manually by editing individual cells in the attribute table. This process will be constrained, of course, by the types of geographic units on the digital map; attribute data for block groups can only be linked to a digital map of block groups, attribute data on individual buildings can only be linked to a digital map of individual buildings, and so on.
    
2. The most likely family jewels will be descriptive and transactions data on individual buildings or leases. If (a) the information is already computerized, (b) the data can be manipulated into attribute table format -the rows are individual buildings and the columns are variables, and (c) one of the columns contains the street address, then the attribute file can be geocoded (made GIS-compatible) by a computerized process called "address matching." Though explaining address matching is beyond the scope of this column, essentially the computer automatically finds the location of each property on the digital map, places a dot or other symbol at that location, and saves the longitude-latitude coordinate in the attribute table. If the street address in not available, address matching can also be used with zip code zones (five or nine digit ), but the dot will be placed at the center of the zone rather than at each property's true site. Many GIS software packages contain address matching modules; address matching is also available from service bureaus.
    
3. The worst-but not prohibitive-situation is if a real estate organization's internal attribute information is only available in hardcopy form, e.g., an appraiser only has paper copies of past appraisals, a broker keeps track of all leases on index cards, etc. This information will have to be input manually into an attribute table by the real estate organization or by a service bureau. Depending upon the available software and the user's expertise, the most efficient method might be to use a module in the GIS software directly to build the attribute table, or indirectly to build the table in a non-GIS software package (again, Lotus 1-2-3, dBase, Oracle, or other widely used package) and then import the table into the GIS. Once the information is in format of an attribute table, it is address matched in the same manner as #2 above.

As soon as the family jewels have been geocoded, they can be leveraged via GIS tools for analyzing and presenting the real estate information by itself and/or integrated with other "data layers" (e.g., zoning, toxic waste sites, flood zones, and on and on). If software is the engine, data is the fuel. The greater the quality and quantity, the faster and further you can go.