Docstoc

Developing a Geodatabase and GIS Software for a Real Estate

Document Sample
Developing a Geodatabase and GIS Software for a Real Estate Powered By Docstoc
					Developing a Geodatabase and GIS Software for a Real
Estate Industry Application: Location, Location, Location
Johanna Zantuck

KGG355 Geomatics 3E: Studio
School of Geography and Environmental Science

Mentors: Dr Werner Hennecke, Dr Jon Osborn


   Abstract
   The real estate industry is a highly lucrative industry that utilises data with a spatial context on
   a daily basis. Despite the spatial nature of much of the data collected in real estate, Geographic
   Information Systems (GIS) are rarely employed in this industry.

   The aim of this project was to develop a GIS software application that would provide useful spatial
   visualisation and analysis tools to real estate professionals and their clients. An ESRI personal
   geodatabase was constructed to store the data for the software to display. Visual Basic for
   Applications programming was used to customise an ESRI ArcMap interface, creating a set of real
   estate specific tools. The application developed was considered to be original and useful. The
   potential exists to improve some aspects of the operation of the application and also to extend its
   functionality.



Introduction
The turnover of the Australian real estate market exceeded $90 billion for residential properties
alone in the financial year 2001-2002 (Real Estate Institute of Australia, 2003). Large amounts of
data handled in the real estate industry have a spatial context and so there is significant potential
for utilising Geographic Information Systems (GIS) in this area. This potential encompasses
such possibilities as analysing the spatial patterns of houses on the market, or of houses
recently sold, or displaying the location of houses to potential buyers.

The aim of this project was to investigate and implement some of the possibilities that exist
for utilising GIS techniques in the real estate industry. A further aim was to investigate the
concept of geodatabases (databases designed specifically for the storage and retrieval of spatial
data) and demonstrate how they may be used in a real estate context. A geodatabase and
accompanying software application was produced, using ESRI GIS technology. It was designed
for use by real estate professionals and intended to be an original tool, providing functionality
that is not available in any similar tool. An effort was made to ensure the software was useful
and relevant to the current Tasmanian real-estate market, also that it was user-friendly and
flexible enough to be expanded into a more sophisticated application.

Current real estate applications for GIS
The websites of some major Australian real estate agents (Roberts, LJ Hooker, First National,
RealEstate.com) make use of maps at a national and state level, but these maps provide little
detail beyond showing area boundaries. These websites employ photographs of individual
houses, but there are no aerial photographs of any areas. One website, www.aussiehome.com,
displays the locations of houses on a street map so that users can see the houses in a spatial
context before deciding make an on-site visit (Gunningham & Williams, 2002).

The Land Information System Tasmania (The LIST) is a state government site providing online
access to a large range of spatially related data. The LIST is marketed as a tool for real estate


journal of undergraduate science engineering and technology                                               1
    agents. The data types it provides include documents and information held by the Land Titles
    Office, topographical data, natural resource data, roads and community facilities data, cadastral
    boundary data, images (including aerial photos and flight lines), administrative boundaries and
    survey control points (The LIST, 2002).

    Interviews with local real estate agents indicated that, while street directories and The LIST are
    used frequently, no other spatial information is typically accessed by their businesses and that
    little consideration has been given to digital maps or GIS (Oakley pers. comm, 2003, Jackson
    pers. comm, 2003, Coxwell pers. comm, 2003). Given this situation, there is certainly scope for
    new innovations and new products
    .
    Geodatabases
    A geodatabase is a database that is designed specifically for the storage and retrieval of spatial
    data. An efficient geodatabase accurately models the structure of the data being utilised,
    ensures that no excess (or duplicate) information will be stored, and that no inconsistencies
    occur due to changes being made in one area and not in another related area. A geodatabase
    can protect data from unauthorized access and place limitations on the sort of information that
    can be input, so the datasets remain internally consistent (Watson, 1996).

    In a real estate application there is likely to be a number of different of users accessing and
    updating the organisation’s various spatial and attribute datasets. Thus, it is logical to employ a
    database to maintain the data accurately and consistently. Ideally a multi-user database would
    be developed for this application, since it is likely that the data would need to be accessed from
    several computers in different offices. However, this project limited itself to the implementation
    of a single user geodatabase, which is a less complex task.

    The project focused on the creation and use of an ESRI single user geodatabase, known
    as a personal geodatabase. (The source for all descriptions of ESRI geodatabases and
    database components in this report is the ArcGIS help documentation, ESRI, 2002). A personal
    geodatabase is an object-oriented database, capable of storing the following types of objects:
    tables; feature classes (points, lines, polygons and their attributes); feature datasets (sets
    of feature classes with the same spatial extent); annotation and dimension feature classes;
    relationship classes; geometric networks; topologies and subtypes.

    The following diagram (Fig.1) illustrates some of these database objects and the way in which
    they may be combined in a GIS to enable meaningful spatial visualisation and analysis.




                     Figure 1. An illustration of different geodatabase components.



2                                                                                      neX us
Feature classes that store simple features can be organised either inside or outside a feature
dataset. It is possible to define relationships between information in different feature classes,
to define a certain topology between different feature classes, and to combine feature classes
to model linear networks. The ability to define these associations between data in different
datasets extends the functionality of standard ESRI spatial datasets, where associations can
only be defined within single datasets.

A brief explanation of relationship classes and annotation classes is provided, since these
components are utilised in the database for this project.

A relationship class defines an association between two different feature classes. Relationships
have certain properties that must be properly defined in order for the desired functionality to be
achieved. The direction of the relationship must be defined. This means that the creator must
specify which table is the ‘origin’ of the shared information and which table is the ‘destination’.
The cardinality of the relationship must also be defined. A relationship class must be defined
as either simple or composite. In a simple relationship, the data in each table exists completely
independently and altering one dataset will have no effect on the other dataset. In a composite
relationship, changes made to one dataset will also be applied to the related dataset.

Annotation classes are used to store map text in a personal geodatabase. Each piece of text in
an annotation feature class stores its own position, text string and display properties.

Database design and implementation
A personal geodatabase, like any database, has what is referred to as a ‘schema’. A schema is
a model (or diagrammatic representation) of the objects in the database and their inter-relations.
Before a geodatabase can be established, it is critical that the schema be carefully designed,
in order to develop a database that is logical, consistent and operates in the desired manner.
If problems with the database design are identified after implementation, it is still possible to
edit the structure of the database. However, this can potentially create problems, especially in
databases with complex linkages.

The datasets required for this real estate application were the cadastre (i.e. property
boundaries), aerial photography, a street network, house locations with associated house
information, and a polygon defining the extent of the datasets.

Figure 2 shows the database structure (including all objects and relationships). A feature dataset
has been created for two Hobart suburbs (West Hobart and North Hobart). A feature dataset
is a means for storing feature classes with the same spatial extent. The suburbs have been
kept separate since only one suburb is to be displayed at a time. This makes the data easier to
access and quicker to load.




journal of undergraduate science engineering and technology                                           3
                                        Figure 2. Database schema.

    The table called Suburbs has been created to prevent unnecessary amounts of data being
    stored in the House feature class. Each House belongs to a Suburb and information related
    specifically to Suburbs is stored in a separate table (rather then repetitively in the House table).

    A major limitation of the personal geodatabase data model became an issue at this stage of
    the process. In order to implement all the functions necessary to make the database original
    and practical, aerial photography needed to be utilised. However, raster information cannot
    be stored in a personal geodatabase. Instead, these data were stored in standard file format
    outside the database. The raster datasets do not need to form any kind of linkage within the
    data model, neither will they be edited by the user of the final program.

    The datasets used in this project were obtained in the following formats:

        §   Cadastral information for the Hobart City Council area (Coverage)

        §   A street network for the Hobart area (Shapefile)

        §   Aerial photography covering West Hobart and North Hobart (Raster)

    Two empty feature datasets (West Hobart and North Hobart) were created within an empty
    database. The cadastre, street network and aerial photography for each of these feature
    datasets were extracted from the broader datasets by clipping the original data to the
    appropriate boundaries. The cadastre and street networks for each suburb were imported into
    the empty feature classes in the database, using ESRI ArcCatalogue to perform the conversions
    from original formats into feature classes. Annotation classes were created for both the cadastre



4                                                                                        neX us
and the street network, in order to display street numbers for the houses and also street names.
The aerial photograph was scanned at resolution of 300dpi. It was necessary to divide the
photograph into six equal sub-images in order to geo-rectify the photographs so that they
were aligned with the cadastral dataset. Aligning the six sub images to the cadastral dataset
meant that they were no longer properly aligned with each other. This was principally due the
unrectified relief distortion in the aerial photography, and also partly due to the limited accuracy
of the cadastral dataset. As previously mentioned, this data was not stored inside the database.

An empty house feature class was created in the database and populated with artificial data,
since real data were not available. An excel spreadsheet of suburb information was created and
imported into the database. A relationship was then created between the suburbs table and the
houses feature class. It was specified that the relationship was composite, not simple and that
the cardinality of the relationship was One-to-Many.

Software Design and Implementation
A list of functions required of the software was developed in consultation with local real estate
agents (Oakley pers. comm, 2003, Jackson pers. comm, 2003, Coxwell pers. comm, 2003).
This list comprised:

    §   Choosing an area of interest and displaying the cadastral information and/or aerial
        photography for that area - this level of detail is critical to the usefulness of the program
    §   Displaying all houses for sale in the area
    §   Displaying all houses recently sold in the area
    §   Displaying houses for sale (with defined selection criteria eg price, address)
    §   Displaying houses sold (with defined selection criteria)
    §   Displaying a description of a chosen house
    §   Registering a new property for sale
    §   Registering a sold property.

A number of new buttons were added to the interface in order to implement this functionality.
Each button fell in to one of three operational categories. Category one operations were those
that related to editing the database: Begin Editing House Database; Point to New House;
Enter House Details and Register Sale. Category two operations were those that related to
displaying information from the database: Choose a suburb; View Houses and Query House
Details. Category three operations were those related directly to the map display: Zoom In; Stop
Zooming; Zoom to Whole Suburb and Clear this Screen.

ArcMap interface customisation
The ArcMap interface was customised using the Visual Basic for Applications (VBA)
programming language. VBA is an application development tool that has been developed by
Microsoft, specifically for customizing existing Software programs (Microsoft - Visual Basic for
Applications, 2003). It can be used to customise a broad range of Windows based software,
including Microsoft Word, Excel and ESRI ArcGIS.

The first step in the process of developing the customised ArcMap interface was to remove all
the standard tool bars and menus. A new menu and two new tool bars were created specifically
for the customised interface. These were a new File Menu, a Real Estate GIS Commands
Toolbar, and an Edit House Database Toolbar. Figure 3 illustrates the finished interface.




journal of undergraduate science engineering and technology                                             5
                         Figure 3. The customised real-estate GIS interface in ArcGIS.
    Discussion

    Project successes:
    As far as can be determined, the software interface that has been developed is an original
    concept. Functionality not discovered in any other application includes:

        §   the capacity for real estate agents to update the database directly using the interface;
        §   the use of aerial photography, giving the user a better ‘feel’ for the location of a house
            than simply viewing it on a cadastral map; and
        §   the capacity for users to view houses that have been sold.

    Interviews with real estate agents indicated that they considered the application useful,
    particularly for illustrating house locations to potential buyers not familiar with the local area;
    viewing houses that have been sold in an area, for market analysis or advertising purposes; and
    viewing aerial photography of undeveloped land parcels or rural properties.

    Future improvements:
    It is not possible to store raster information (such as images) in a personal geodatabase. For
    this reason, it would be better to store the data in a Spatial Database Engine (SDE) database,
    capable of handling raster images. The SDE is a multi user Database Management System. A
    multi user Database Management System is also a logical extension for this application since
    more than one person may often wish to access the data at the same time.

    The errors encountered when georectifying the aerial photography were not unexpected since
    the aerial photograph had not been adjusted for the effects of terrain relief. It was critical to the
    project that the cadastral information and the aerial photography were closely aligned. This is
    because a single house appearing in the correct position on the cadastre needed to appear in
    the correct position on the photography. Rectification of the six separate smaller photos brought
    the photographs in to alignment with the cadastre, but they failed to align properly with each
    other. The situation would be improved by photogrammetrically rectifying the large image.
    The ArcMap ‘information tool’ has been included on the interface as a means by which users can
    click on houses or cadastral polygons and obtain information about them. Whilst this is certainly



6                                                                                        neX us
a useful function, a better way to perform this operation would be to hyperlink different features
to documents containing photos and descriptions.

On the software interface that was produced, the user has the ability to right click and obtain
access to certain ArcMap menus. Theoretically, the user may be able to display additional
menus and controls, edit the code for the existing controls, change the data frame properties,
and perform several other operations that would not be desirable. Disabling right clicking (or
improving security in some other way) would be a considerable improvement to this interface.

Additional functions that could be implemented include a capacity to view the cadastre and aerial
photos in 3D (draped over a digital elevation model); turn aerial photos on/off underneath the
cadastre layer; search for houses by price, number of bedrooms etc; define the location of new
houses by address rather than by digitising; view other infrastructure (such a school or bus route
locations); email the results; implement the application in ArcView, Manifold or other low-cost
GIS software and serve the application on the Internet.

Summary
The aim of the project was to develop a GIS application, supported by a personal geodatabase,
for use in the real estate industry. This project demonstrated that GIS has the potential to be a
valuable tool for the real estate industry. The full capabilities of GIS are not currently utilised in
this industry and potential exists for new developments to be made.

The software application provides users with the ability to view aerial photographs and cadastral
boundaries in a chosen area and to display houses on the market or houses recently sold as a
layer on top. The user can access information on any house. A real estate agent can use the
application to update the database.

The geodatabase models the structure of the data being utilised for this application. It ensures
that no excess (or duplicate) information will be stored, and that no inconsistencies occur due to
changes being made in one area and not in another related area.

The software interface performs as desired, although some improvements could be achieved,
such as better alignment of aerial photographs and the incorporation of additional functionality.
Possible additional functions include expanding the list of criteria that can be defined in a house
search, viewing the data in 3D or including the ability to display local infrastructure, such as
bus routes and schools. The possibility also exists for implementing the application in a less
expensive GIS software package and/or on the Internet.

References
About the LIST, 2002, Retrieved: 22nd August 2003, http://www.thelist.tas.gov.au/docs/about.html

ESRI, 2002, ArcGIS (Version 8.3) Desktop Help

Gunningham, C. & Williams, P. 2002, ‘Delving into Real Estate with a New Online GIS
Technology’, Retrieved: 22nd August 2003, http://www.i-delve.net/walis2002/slide0001.htm

Microsoft - Visual Basic for Applications, 2003, Retrieved: 10th October 2003,
http://msdn.microsoft.com/vba/

Real Estate Institute of Australia, 2003, Australian Property Market Indicators

Watson, R. 1996, Data Management: an organisational perspective, Wiley, New York




journal of undergraduate science engineering and technology                                              7

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:19
posted:2/4/2010
language:English
pages:7