29,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Spatial applications should be developed in the same way that users develop other database applications: by starting with an integrated data model in which the SDO_GEOMETRY objects are just another attribute describing entities and by using as many of the database features as possible for managing the data. If a task can be done using a database feature like replication, then it should be done using the standard replication technology instead of inventing a new procedure for replicating spatial data. Sometimes solving a business problem using a PL/SQL function can be more powerful, accessible, and easier to use than trying to use external software. Because Oracle Spatial's offerings are standards compliant, this book shows you how Oracle Spatial technology can be used to build cross-vendor database solutions. Applying and Extending Oracle Spatial shows you the clever things that can be done not just with Oracle Spatial on its own, but in combination with other database technologies. This is a great resource book that will convince you to purchase other Oracle technology books on non-spatial specialist technologies because you will finally see that "spatial is not special: it is a small, fun, and clever part of a much larger whole".
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 630
Veröffentlichungsjahr: 2013
Ähnliche
Table of Contents
Applying and Extending Oracle Spatial
Applying and Extending Oracle Spatial
Copyright © 2013 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: September 2013
Production Reference: 1210913
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-84968-636-5
www.packtpub.com
Cover Image by Aashish Variava ([email protected])
Credits
Authors
Simon Greener
Siva Ravada
Reviewers
Paul Thomas Dziemiela
Jan Espenlaub
John O'Toole
Brendan Soustal
Acquisition Editors
Pramila Balan
Rukhsana Khambatta
Lead Technical Editor
Dayan Hyames
Technical Editors
Shashank Desai
Dylan Fernandes
Krishnaveni Haridas
Ankita Thakur
Project Coordinators
Anurag Banerjee
Shiksha Chaturvedi
Proofreaders
Maria Gould
Ameesha Green
Paul Hindle
Indexers
Mariammal Chettiyar
Rekha Nair
Tejal R. Soni
Graphics
Sheetal Aute
Valentina D'silva
Disha Haria
Yuvraj Mannari
Production Coordinator
Conidon Miranda
Cover Work
Conidon Miranda
About the Authors
Simon Greener has university qualifications in geomatics, computing science, database technologies, and project management.
He started his working career with mining and surveying experience. He then found his calling as a computer scientist with his first job as a database programmer on IBM mainframes for Telstra. He switched to GIS three years later through working in a multi-disciplinary GIS research team at Telecom's Research Laboratories (TRL) in Clayton, Victoria. While at TRL, he worked on projects whose outcome saw the creation of what is now Telstra's Sensis group.
After leaving TRL, he worked as a lecturer and consultant for CenSIS (University of Tasmania) under Professor Peter Zwart, writing student and technical training courses. While there, he continued to consult to Telstra's Directory Services and Mobile groups. It was here that he came in contact with the Spatial DataBase Engine (SDBE) from Geographic Technologies Incorporated (GTI) and saw its potential for the management of large scale spatial databases within relational database technologies, a merging of his IT and GIS worlds. This led to the foundation of Salamanca Software Pvt Ltd (SalSoft), for which he was a Director until it was purchased by ESRI Australia in 1996.
Some notable achievements while at SalSoft included helping brokers with the sale of SDBE to ESRI Inc (now ArcSDE), winning the first ArcSDE sale to Telstra to power its White pages/Yellow pages mapping portal, co-authoring a geocoding specification for Spatial Decision Systems (now Sensis), consulting for Geographic Technologies Australia on numerous projects based on Universal Press street directory data, and the creation of GeoCASE/Blueprint, the world's first data modeling tool that enabled the modeling of spatial data and relationships.
In 1997, he was appointed GIS Manager for Forestry Tasmania (FT) in Hobart, Tasmania. While at FT, he architected the complete revamp of FT's GIS systems using Oracle Spatial (being one of the earliest adopters of the Sdo_Geometry implementation) as the core data management technology. He was concentrating on embedding geospatial data and processing within business systems via a value-oriented, business-centric computing model. He designed and built numerous systems during those years, the best of which was MapComposer, a three-click web-enabled business map production system that, when he left in 2005, had grown (2000-) to over 320 online uses, producing over 50,000 maps a year from a repository of over 100 different map templates (still in operation in 2013). His years at FT concluded with the writing of a GIS Strategy that saw the use of GIS increase yet the cost of the technology to the organization decrease.
He left FT in September 2005 for the precarious world of self-employment. He was a sometime copyist for Directions Magazine. As a subcontractor to a Spatial distributor in Australia, he wrote a Radius Topology training course and provided Radius Topology and Oracle Spatial consulting services for them at numerous customer sites until May 2006. From May to August 2006, he was engaged by Spatial, Cambridge, UK, under a UK Government Department of Trade and Industry's GlobalWatch program to conduct research and development in relation to enhancing the export potential of their latest product, Radius Studio (this resulted in Radius Studio being integrated with Feature Data Objects – FDO technology to extend its data access capabilities).
In his consulting career, he has written a spatial strategy document and conducted a database performance analysis review for a large Tasmanian Government department. He has conducted a number of Oracle spatial database best practice, tender and system, and return on investment reviews at a number of Victorian Government departments. He wrote and delivered a user requirements document for Enterprise GIS at a large Australian corporation. He also provided guidance and implementation services to an ambulance service helping integrate Oracle Spatial into a data warehouse project that used Oracle Portal, Discoverer, and Data Warehouse Builder. He delivered many solutions for a NSW water authority; and finally, he successfully completed many migration, publication, return on investment, process improvement, and database design contracts for a number of Canberra-based Federal Government departments. Simon makes available a collection of PL/SQL and Java-based sample solutions for the Oracle database via his website. He is also principal programmer for the SQL Developer spatial extension, GeoRaptor. Finally, he was awarded, the 2011 Oracle Spatial Excellence Award for Education and Research by Oracle.
His technical areas of expertise include systems design and architecture (spatial and attribute), data management, and modeling in both the OLTP and OLAP spaces, and he is also an evangelist for O-RDMS-based spatial data. He is available for free-lance geospatial solutions architecture work, Java and PL/SQL programming, and he provides Oracle Spatial benchmarking and performance enhancement services.
His non-technical interests are his family, friends, walking, reading, singing, and motorcycle riding.
I would particularly like to acknowledge those who have helped in many ways that are required to coax a person through the difficult gestation of a new book. The first, of course, is my wife, Anna. Her quiet and unshakable support, through what was also a financially difficult period of time, is something that I, as a man, husband, and father, am deeply thankful for and immensely proud of. Ti Amo, Cara. To my co-author, Siva Ravada, for kindly stepping in to help me write this book when I felt writing the whole book was beyond my resources. The colleagues that I would particularly like to thank include John O'Toole (Spatial Ireland), who has been an amazing source of inspiration and a fantastic sounding board for all things Oracle Spatial and its application for many years. Brendan Soustal, for his support and belief provided over all my consulting years. Martin Davis, JTS architect and chief programmer, for helping with the chapter on Java in the database. I would also like to thank Holger Läbe, who started helping me programming GeoRaptor, for without his help, the Java chapter would never have eventuated. I would also like to thank Jody Garnett for helping me with GeoTools over the years, and thank you to all those who read my meager blog posts or have downloaded my PL/SQL and Java solutions from my website. Your actions confirmed for me that this book was worth writing. Finally, to the reviewers, both official and private, thank you for all your efforts and help.
Siva Ravada earned a PhD degree from the University of Minnesota in the field of Spatial Databases before joining Oracle's Spatial development team. He is now a Senior Director of Development at Oracle Corporation. At Oracle, Siva was one of the founding team members of the Spatial development team before taking over the team management responsibilities. Siva now manages the Spatial and MapViewer development teams at Oracle. He has more than 15 years of experience in spatial databases and application development. He has also co-authored more than 30 articles published in journals, and holds more than 30 patents. He has also presented key-note speeches at several conferences on the topics of spatial databases and GIS.
Oracle is the second largest software company and the number one database company in the world.
I sincerely thank my wife, Manjari, and my daughter, Pallavi, for their support during this book project. Several of my team members and colleagues at Oracle also helped me with examples for this book, and I thank all of them for their help and support during the last few months.
About the Reviewers
Paul Thomas Dziemiela is a geographic information systems professional specializing in RDBMS geospatial solutions.
Jan Espenlaub studied Geography at the University of Freiburg, Germany. He started with GIS in 1980. He has worked for several companies and governmental agencies as a GIS consultant. His main focus is on data management, Oracle Spatial, GIS Interoperability, and open source software. He is currently working with regioData GmbH, leading the GIS Application development group.
John O'Toole is an Oracle database developer with a passion for spatial data. He has been using Oracle technology since 2001 and currently works in Dublin, Ireland, as a consultant with 1Spatial.
He works on projects with cadastral, land registration, and national mapping agencies, helping them to build innovative and scalable solutions with a particular emphasis on spatial data quality.
Among other activities, he actively participates on the OTN Oracle Spatial discussion forum and contributes to the GeoRaptor project.
John is an Oracle Database 10g and 11g Certified Professional and Oracle Spatial 11g Certified Implementation Specialist.
Brendan Soustal joined the workforce in 2002 as a Land Information Systems graduate. He has implemented a comprehensive program to improve the quality and quantity of geospatial and asset information at a local government as well as at state and international levels. These programs have seen the development of innovative systems and substantial improvements in workplace efficiency. They have also established new opportunities for data sharing and data standardization within the utilities industry.
Brendan's fresh approach to his information management roles and his enthusiasm for innovation has helped a number of organizations to embrace new technologies and broaden their range and depth of GIS and spatial applications.
www.PacktPub.com
Support files, eBooks, discount offers and more
You might want to visit www.PacktPub.com for support files and downloads related to your book.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
http://PacktLib.PacktPub.com
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can access, read and search across Packt's entire library of books.
Why Subscribe?
Free Access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.
Instant Updates on New Packt Books
Get notified! Find out when new books are published by following @PacktEnterprise on Twitter, or the Packt Enterprise Facebook page.
Preface
The focus of this book is the application of Oracle Spatial to the sorts of business problems that are better solved inside the database using a fully integrated technology approach. This approach takes as its first point of reference the view that spatial data and processing is no different from using timestamps, numbers, text, or dates to describe business entities (assets), and also that solutions to business problems involving spatial data processing should use relevant, or related, IT technologies first, before introducing specialist GIS software. One of the issues facing all proponents and users of spatial databases is the lack of knowledge within the professional GIS community about the underlying database software being used to manage spatial descriptions of business entities.
This book elucidates a holistic approach to spatial data management by highlighting how spatial data management and processing is enhanced and supported by utilizing all the data storage types that a database offers, but particularly spatial data.
The examples in this book have been drawn from many years of working with Oracle Spatial within a business IT environment. In addition, some examples have been drawn from requests readers of various blogs and forums have made over the years; some though are purely speculative based as they are on the application of theory to problems.
What this book covers
Chapter 1, Defining a Data Model for Spatial Data Storage, provides a SQL schema and functions that facilitate the storage, update, and query of collections of spatial features in an Oracle database. Oracle Spatial mainly consists of the following:
The spatial component of a real-world feature is the geometric representation of its shape in some coordinate space (either in 2D or 3D), and in vector space, this is referred to as its geometry. Oracle Spatial is designed to make spatial data management easier and more natural to users of location-enabled business applications and geographic information system (GIS) applications. Oracle allows the storage of spatial data in a table using the SDO_GEOMETRY data type, which is just like any other data type in the database. Once spatial data is stored in the Oracle database, it can be easily manipulated, retrieved, and related to all other data stored in the database.
A spatial database should be designed just like any other database with a fully specified model. A fully specified model that is application independent should control spatial data storage. A good data model supports and enhances application access without compromising quality. In addition, database features can be used to support applications that have limited functionality when it comes to table and column design. For example, some applications mandate a single spatial column per table or only a single homogeneous geometry type per spatial column. These limitations can be accommodated quite easily using database features such as views and triggers. In addition, there are a number of issues that arise when designing a data model that directly affect data quality, performance, and access.
The goal of this chapter is to give readers an understanding of how to model spatial data as SDO_GEOMETRY columns within tables, how to support spatial constraints for improved data quality, how to use synchronous and asynchronous triggers for implementing topological constraint checking, and how to present methods for coping with multiple representations for faster web service access. All these issues, with solutions, are covered in this chapter.
Chapter 2, Importing and Exporting Spatial Data, explains how once we have a data model defined, the next step is to load data into it, and after data is loaded, it needs to be checked for cleanliness before indexing and using it. There are many methods for loading data of different types and formats. In this chapter, we describe some of the more common formats and how they can be loaded into the Oracle database using free tools, tools already available with Oracle, and tools from third party vendors. In addition, we also discuss other issues relating to import performance and organization of data for efficient access by applications.
The goal of this chapter is to give you a complete overview of all aspects of data loading from tools, through physical loading techniques, data organization, data quality checking, and indexing:
Chapter 3, Using Database Features in Spatial Applications, introduces some of the standard features that the Oracle database makes available to solve some common data processing, auditing, version management, and quality issues related to the maintenance of spatial data. These database features allow developers to keep the data processing operations in the database instead of doing them in the application code:
Chapter 4, Replicating Geometries, shows the process of copying and maintaining data across different databases in a distributed system. The goal of this chapter is to present a few methods for replicating geometry data. Some of the traditional Oracle replication technologies do not directly support replication of tables with SDO_GEOMETRY data. The examples given here show alternate ways of replicating tables with geometry data. Replication does not always mean replicating the same data in different databases. In some cases, it also means copying the data in one database into a different database in a different form. For example, data in Online Transaction Processing (OLTP) databases can be converted to Online Analytical Processing (OLAP) databases by replicating or combining data from different OLTP tables into a single table in the OLAP system. We show how to do this conversion of data from a transactional OLTP database to a publication or OLAP database. Starting with the 12cR1 release, Logical Standby support for SDO_GEOMETRY data types is introduced, so we will look at how this feature can be used to replicate geometry data. In this chapter, the following topics will be covered:
Chapter 5, Partitioning of Data Using Spatial Keys, explains how spatial applications tend to generate large volumes of data, especially as the scale of observation of the world's surface extends to large parts of the Earth's surface. With the increasing level of data, database models have to adapt to deal with large volumes of spatial data that is not seen in traditional GIS applications. GIS applications expect all the related data in one feature layer, even if the feature layer contains millions of features. Oracle database supports a feature called partitioning that can break large tables at the physical storage level to smaller units while keeping the table as one object at the logical level. In this chapter, we cover the following five topics that are useful for managing large volumes of spatial data:
Chapter 6, Implementing New Functions, shows us to create new functions that use and extend those offered by Oracle Spatial and locator products. The SDO_GEOMETRY object, its attributes, and its structure must be thoroughly understood. Therefore, this chapter will start by building some functions that will help us understand, access, and process an SDO_GEOMETRY object's attributes. In building these functions, those Oracle SDO_GEOMETRY methods and SDO_GEOM and SDO_UTIL package functions that relate to the processing of the SDO_GEOMETRY attributes and structure will be introduced and used. This chapter will present information that will help the reader understand how to:
Later chapters will build on the knowledge gained in this chapter when creating functions that solve specific real-world problems.
Chapter 7, Editing, Transforming, and Constructing Geometries, explains Desktop GIS, CAD, and Extract Transform and Load (ETL) software that provide a rich set of tools that the experienced operator can use to construct, edit, or process geometric objects. But few realize that creating and applying such functionality within the database is also possible, and this can be more effective, efficient, and less complicated.
While the Oracle database SDO_GEOMETRY data type provides an excellent storage, search, and processing engine for spatial data, what users often overlook is its ability to provide geometry modification and processing capabilities that can be used in database objects such as views, materialized views, and triggers for the implementation of specific business functionality, with that functionality being available to any software product that connects to the database.
Chapter 8, Using and Imitating Linear Referencing Functions, shows how to use the functions created in Chapter 6, Implementing New Functions and Chapter 7, Editing, Transforming, and Constructing Geometries to build new functions that can be used to solve business problems relating to managing linear assets. The main business problems that need this functionality are road, cycle way, or track management, geocoding street addresses, survey, inventory, condition assessment, and water management applications.
Oracle Spatial has a robust linear referencing package (SDO_LRS) that can be applied to all the above problems. The SDO_LRS package can only be licensed for use by purchasing the Spatial package and deploying it within an Oracle Enterprise database. In addition, SDO_LRS cannot be purchased separately from the whole Spatial package. Finally, SDO_LRS cannot be used with locator.
The functions created in this chapter will provide SDO_LRS functionality where licensing of the SDO_LRS package is beyond the user's resources. These functions will support simple linear processing against measured and non-measured geometries (a normal 2D linestring is a non-measured geometry). The following are the uses of linear processing:
The examples presented in this chapter will include real-world situations to demonstrate the power of developing and using these types of functions. The SQL statements that demonstrate the use of the functions developed in this chapter are available in an SDO_LRS equivalent form in the SQL scripts shipped with this book for this chapter; they will not be included in the actual chapter.
Chapter 9, Raster Analysis with GeoRaster, shows how spatial features can be represented in vector or raster format. So far, we have discussed the vector related features of Oracle Spatial, and we introduce the raster related features called GeoRaster in this chapter. Traditional GISs propose to store the raster data as BLOBs in the database. This approach might be sufficient if the raster data is only used as backdrop images in maps.
But if any raster data processing and analysis is required, storing raster data as GeoRaster objects offers many features and advantages over storing this data just as BLOBs. Loading and storing any raster data inside a database simply for the purpose of storage or visualization provides limited utility. Storing raster data for use within a transactional system has engendered a view that one must see all data as a part of a complete model; the data loaded must be seen in relation to all other data under control of that model.
The goal of this chapter is to demonstrate how to use raster data in conjunction with all the data in the database to answer questions that otherwise could not be answered in the database. The following topics are covered in this chapter to show how this goal can be achieved:
Chapter 10, Integrating Java Technologies with Oracle Spatial, shows how to embrace and extend the standard functionality available with Oracle Locator and Spatial using PL/SQL. PL/SQL is the programming language that is native to Oracle. Oracle also supports the creation of Java Stored Procedures. This chapter explores the application of Java to spatial processing involving the SDO_GEOMETRY type.
In particular, this chapter will cover the following topics:
Chapter 11, SQL/MM – A Basis for Cross-platform, Inter-operable, and Reusable SQL, explains how Oracle's SDO_GEOMETRY type is very widely used even by the open source community, which promotes the virtues of standards conformance and compliance. However, many in the geospatial industry still criticize Oracle's SDO_GEOMETRY for its lack of perceived standards compliance. Whether this criticism is based on ignorance or maleficence, SDO_GEOMETRY is standards compliant in its storage, geometry description, and with some functions; but, its API is not fully compliant.
SDO_GEOMETRY is not the whole story however. Oracle also provides an ST_GEOMETRY object type which is an implementation that is based on the ISO/IEC FCD 13249-3 Spatial (ISO 13249-3, Information technology - Database languages - SQL Multimedia and Application Packages - Part 3: Spatial.) standard (hereafter known as the SQL/MM standard). This chapter aims to show that such criticism of standards compliance of Oracle is limited and ill informed through exposure of the benefits of ST_GEOMETRY to practitioners.
ST_GEOMETRY is of special importance in situations where a business IT environment has a heterogeneous database environment (for example, Oracle, SQL Server, PostgreSQL). It can be a most useful mechanism for implementing cross-platform spatial data processing and developing highly reusable skills. This latter aspect of skills development is important because reusability and training, which increases and improves an individual's skill-set, is an important ingredient in staff training and development.
This chapter will present two aspects of how the use of standards: OGC SFA 1.x OpenGIS® Implementation Specification for Geographic information - Simple Feature Access - Part 1: Common architecture, Version 1.1 and 1.2. Previously known as Simple Features – SQL (SFS). (hereafter known as OGC SFA or OGC SFA 1.1 or 1.2, if function is only available in one of the standards) and SQL/MM, to aid cross-platform interoperability:
Appendix A, Table Comparing Simple Feature Access/SQL and SQL/MM–Spatial provides a comparison of SFA-SQL 1.2 (http://portal.opengeospatial.org/files/?artifact_id=25354) and SQL/MM-Spatial (ISO 13249-3, Information technology - Database)
Appendix B, Use of TREAT and IS OF TYPE with ST_GEOMETRY examines the need for TREAT in more detail. In the ST_GEOMETRY hierarchy, a POINT object can be created in the following two ways:
MDSYS.ST_GEOMETRY.FROM_WKT('POINT(6012578.005 2116495.361)',2872)
MDSYS.ST_POINT.FROM_WKT('POINT(6012578.005 2116495.361)',2872).
The result in both cases is not an ST_POINT, rather it is an ST_GEOMETRYobject.
What you need for this book
If the reader of this chapter wishes to use SQL and the example code that ships with this book, then the following technologies are required:
Who this book is for
This book is aimed at the experienced practitioner who is already literate with Oracle Locator or Spatial and who has at least heard of or used the standard Oracle database technologies this book uses to solve problems.
The reader should be familiar with using SQL Developer or a similar product to execute the SQL examples, though for visualization, SQL Developer and the free GeoRaptor extension are preferred.
The reader should be at least familiar with physical database modeling, and even if they have not used SQL Developer's Data Modeler tool, should be willing to learn how to use it.
For the programming aspects of this book, it is preferable but not mandatory that the reader has some experience in writing relatively simple PL/SQL and a base level of knowledge of writing Java. In respect of Java, while the actual Java Stored Procedures are relatively simple in structure, the use of external source code and JAR files to construct the complete solution is something that requires some experience of working within a larger Java framework. As such, familiarity with JDeveloper or a similar Integrated Development Environment (IDE) is recommended.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "Oracle allows the storage of spatial data in a table using the SDO_GEOMETRY data type, which is just like any other data type in the database".
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "Once the table is created, go to the APEX home page and then navigate to the SQL Workshop and Utilities tab".
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Downloading the color images of this book
We also provide you a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from: http://www.packtpub.com/sites/default/files/downloads/6365EN_ColoredImages.pdf
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the erratasubmissionform link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. Defining a Data Model for Spatial Data Storage
Oracle Spatial and Graph provides a SQL schema and functions that facilitate the storage, update, and query of collections of spatial features in an Oracle database. Oracle Spatial and Graph is the new name for the feature formerly known as Oracle Spatial. In this book, we refer to this feature as Oracle Spatial for the sake of simplicity. We also focus exclusively on spatial feature of Oracle Spatial and Graph in this book. Oracle Spatial mainly consists of the following:
The spatial component of a real-world feature is the geometric representation of its shape in some coordinate space (either in 2D or 3D), and in vector space, this is referred to as its geometry. Oracle Spatial is designed to make spatial data management easier and more natural to users of location-enabled business applications and geographic information system (GIS) applications. Oracle allows the storage of spatial data in a table using the SDO_GEOMETRY data type that is just like any other data type in the database. Once the spatial data is stored in the Oracle database, it can be easily manipulated, retrieved, and related to all other data stored in the database.
A spatial database should be designed just like any other database with a fully specified model. A fully specified model that is application independent should control the spatial data storage. A good data model supports and enhances application access without compromising the quality. In addition to these features, database features can be used to support applications that have limited functionality when it comes to table and column design. For example, some applications mandate a single spatial column per table or only a single homogeneous geometry type per spatial column. These limitations can be accommodated quite easily using database features such as views and triggers. In addition, there are a number of issues that arise when designing a data model that directly affects the data quality, performance, and access.
The goal of this chapter is to give readers an understanding of how to model spatial data as SDO_GEOMETRY columns within tables, how to support spatial constraints for improved data quality, how to use synchronous and asynchronous triggers for implementing topological constraint checking, and to present methods for coping with multiple representations for faster web service access. All these issues, with solutions, are covered in this chapter:
Defining a sample schema
We will first define a sample schema that will be used for all the examples in this book. The schema is intended to model typical spatial assets maintained in a city-level GIS. Oracle Spatial provides all the functionality needed to model or describe the spatial properties of an asset (in modeling, it is often called an entity). This spatial description of an asset should not be treated differently from any other descriptive attribute. In addition, a data model should describe all assets/entities within it independently of any application. This should include, to the best of the ability of SQL, all business rules that define or control these assets/entities within the database, and these rules should be implemented using standard database practices.
Defining the data model
We use a schema with 12 tables to represent a spatial database for a city. This schema has tables to represent administrative areas managed at the city level, such as land parcels and neighborhoods, along with tables to manage natural features such as water boundaries.
The LAND_PARCELS table has information about land at the lowest administrative level of the city. Buildings have to be fully contained in these land parcels. A table called BUILDING_FOOTPRINTS has information about all the buildings in the city. This table has the footprint of each building along with other information, such as name, height, and other attributes. Sets of neighborhoods are defined as a collection of land parcels to create more granular administrative areas. These neighborhoods are stored in the PLANNING_NEIGHBORHOODS table. There is a master table, BASE_ADDRESSES, to store information about all the valid street addresses in the city. Every record in the BUILDING_FOOTPRINTS table must have one parent record in this master address table. Note that the master address table does not list all the addresses of the apartments in a building. Rather, it stores one record for each street level address. So, each record in the BUILDING_FOOTPRINTS table has only one corresponding record in the master address table.
There is also a master table, ROADS, that is used to store information about all the roads in the city. ROADS stores one record for each named road in the city so that all common information for the road can be stored together in one table. This is the only table in the schema without any geometry information. Each road in turn maps to a set of road segments that are stored in the ROAD_CLINES table. This table is used to store the geometric representation of center lines of road segments. This table also stores information about address ranges on these road segments. Road segments typically have different address ranges on the left side of the road and on the right side of the road. Each road segment also has a parent ROAD_ID associated with it from the ROADS table.
A city usually manages sidewalks and other assets, such as street lamps, trashcans, and benches that are placed on these sidewalks. The SIDEWALKS table stores the information for all the sidewalks managed by the city. The CITY_FURNITURE table stores all the data corresponding to the assets, such as benches, streetlights, and trashcans.
The ORTHO_PHOTOS table stores the collected information using aerial photography. The raster information stored in this table can be used to look for changes over time for the built-in features of the city.
The water features of the city are stored in two different tables: the WATER_LINE table is used to store the water line features, such as creeks, rivers, and canals. The WATER_AREA table is used to store area features, such as lakes, rivers, and bays. The following figure shows the entity-relationship (E-R) diagram for this data model:
The following figure shows the further E-R diagram for same data model:
Creating tables in the schema
Create a user called BOOK and assign it a password. Load the script <schema_load.sql> and it will create the tables required for running the examples described in this book. It will also create the Oracle Spatial metadata required for these tables. The following privileges are granted to the BOOK user:
Understanding spatial metadata
Oracle Spatial requires certain metadata before the spatial data can be meaningfully used by applications. The database views that contain this metadata also act as a catalog for all the spatial data in the database. There are two basic views defined to store this metadata information: USER_SDO_GEOM_METADATA and ALL_SDO_GEOM_METADATA. The USER_ view is used to create a metadata entry for a single SDO_GEOMETRY column within a database table or view. An entry must be created for each SDO_GEOMETRY column within a table; entries for SDO_GEOMETRY columns in views are optional.
If a table has more than one column of type SDO_GEOMETRY, then there is one metadata entry for each column of spatial data in that table. The ALL_view shows all of the spatial layers that can be accessed by the current user. If a user has the Select grant on another user’s table with SDO_GEOMETRY columns, the first user can see the metadata entries for those tables in the ALL_view. The views are set up so that owners of the spatial tables or views can create the metadata for them. And, the owner of a layer can grant read access to a layer to other users in the system. Granting a Select privilege on the table or view to other users will let them see the metadata for these tables and views. The ALL_view displays all the spatial tables owned by the user along with other spatial tables for which the current user has read access.
Spatial Reference System
Each SDO_GEOMETRY object has a Spatial Reference System (SRS) associated with it, and all the SDO_GEOMETRY objects in a column should have the same SRS. In Oracle Spatial, a Spatial Reference ID (SRID) is used to associate an SRS with SDO_GEOMETRY objects. There are cases (for example, engineering drawings) where there is no SRS associated with an SDO_GEOMETRY object. In such cases, a NULL SRID is used to denote that the spatial data has no spatial reference information. An SRS can be geographic or non-geographic. A geographic SRS is used when the spatial data is used to represent features on the surface of the Earth. These types of SRS usually have a reference system that can relate the coordinates of the spatial data to locations on Earth. A unit of measurement is also associated with an SRS so that measurements can be done using a well-defined system. A non-geographic SRS is used when the spatial data is not directly related to locations on Earth. But these systems usually have a unit of measurement associated with them. Building floor plans is a good example of spatial data that is often not directly related to locations on Earth.
A geographic system can be either geodetic or projected. Coordinates in a geodetic system are often described using longitude and latitude. In Oracle Spatial, the convention is to use longitude as the first coordinate and latitude as the second coordinate. A projected system is a Cartesian system that is defined as a planar projection based on the datum and projection parameters.
Before an entry is created for a layer of data, the SRID associated with the data should be identified along with the tolerance to be used for the spatial layer. All the spatial data has an inherent accuracy associated with it. Hence, the tolerance value used for a spatial layer is very important and should be determined based on the accuracy of the data. Once these two values are identified, you are ready to create the metadata for the spatial layer.
More on Spatial Reference Systems
Oracle Spatial supports hundreds of SRSs, and it is very important to choose the right SRS for any given data set. The definition of an SRS can be easily obtained by looking at the well-known text (WKT) for that SRS. The WKTs for all the SRSs supplied as part of Oracle Spatial are available from the MDSYS.CS_SRS view. In addition to this view, there are several other metadata tables under MDSYS that contain more details on how these SRSs are defined. Oracle Spatial also supports the EPSG standard-based SRSs. SRS in Oracle Spatial is flexible and allows users to define new reference systems if they are not present in the supplied SRSs. We will revisit user-defined SRSs in the following chapters.
Creating spatial metadata
The tables used in our sample schema contain data that is geographically referenced. Spatial metadata can be created using Insert statements into the USER_SDO_GEOM_METADATA view. This view is defined as a public-writable view on top of MDSYS.SDO_GEOM_METADATA_TABLE that is used to store metadata for all the spatial columns in the database. Let us look at the metadata creation process for some of the spatial tables. Most of the tables used in the current schema have spatial data in the California State Plane Zone 3 Coordinate System. In Oracle Spatial, the corresponding SRID for this SRS is 2872. This coordinate system has foot as the unit of measurement and we will use 0.05 as our tolerance (that is, five-hundredths of a foot). The metadata is created using the Insert statement as shown in the following code:
The SDO_DIM_ELEMENT object is used to specify the lower and upper bounds for each dimension of the coordinate system along with the tolerance value. The metadata allows one entry for each dimension, even though it is very common to use the same tolerance value for the X and Y dimensions. When storing 3D data, it is very common to use a different tolerance value for the Z dimension.
The BASE_ADDRESSES table has geometries stored in two columns: GEOMETRY and GEOD_GEOMETRY. The GEOMETRY column has data in the 2872 SRID, while the GEOD_GEOMETRY column has data in longitude and latitude. As this is a geodetic system, the tolerance for such systems is required to be in meters. So, a tolerance of 0.05 means a tolerance of 5cm. For geodetic data, it is recommended that the tolerance should not be less than 5cm for all of the topology and distance-based operations.
As this is a geodetic system, the longitude range goes from -180 to 180 and the latitude range goes from -90 to 90. Even though it is normal practice to use these ranges for the metadata entry, many developers use the actual ranges spanned by the SDO_GEOMETRY object. Mapping tools and applications typically use this extent from the metadata to compute the initial extent of the data in each column of the spatial data.
Any application looking for all the spatial columns in the database should select the data from the ALL_SDO_GEOM_METADATA view. This will return one row for each column of spatial data in the database that is visible to the current user.
OGC-defined metadata views
Open Geospatial Consortium (OGC) defines a different set of standardized metadata views. OGC standard metadata can be defined using a new set of tables or views in Oracle Spatial. For a simple solution for the OGC metadata schema, we will show a view-based implementation using the Oracle Spatial metadata table. All Oracle supplied packages, functions, and types of Oracle Spatial are in the MDSYS schema. It is generally not recommended to create any user objects under this schema as it might cause problems during database upgrades. Oracle also supplies another predefined schema called MDDATA that can be used for Oracle Spatial-related user objects that are general purpose in nature. We use this MDDATA schema to create the OGC metadata views. This user comes locked and it is recommended that you do not unlock this user. But, it does require a few privileges to make the following code work, so grant those privileges as required.
Connect to the database as a user with SYSDBA privileges and execute all the following steps as the MDDATA user by changing the current schema to MDDATA. We need to grant an explicit Select privilege on SDO_GEOM_METADATA_TABLE to MDDATA.
The OGC standard requires the geometry type as part of the metadata view. But, this is not part of the MDSYS owned metadata view and has to be computed based on the geometry table information stored in the MDSYS
