Oracle Spatial User Group Meeting, Brisbane, 9th December 2005

The tenor of some of the response I received from my report on the initial OSUG Australia meeting held during the GITA Australia conference back in August 2005 surprised me.Sure, not many public responses appear on Directions Magazine, but a few private emails did come my way.(I welcome these emails, so please don't think otherwise.) On reflection, I would characterize some of the responses as being commensurate with a perception that Oracle Spatial is a technology disturbing the dominance of existing GIS vendors.Some of the responses demonstrated a misunderstanding of the sound IT data management principles underlying the product, or showed a lack of understanding that the increasing embrace of geospatial data management and processing by more general information technology companies is good for users.

Oracle's main geospatial interest, and core strength, is in an area that is complementary rather than competitive.Oracle's technology is demonstrating value to millions of customers all around the world. However, it could almost be argued that the frosty reception, indifference or antagonism with which Oracle Spatial has been received from some might just have caused Oracle to "extend" its embrace of the geospatial world into non-data management areas (e.g.mobile and Web mapping).Three product areas which I hope Oracle will spatially enable are Business Process Execution Language, Mobile Database and Data Warehousing.

I think it can be safely asserted nowadays that the enterprise spatial data management "marketing" war of the 90s and early 2000s are all but over.The integration of spatial data types and methods into horizontal market technology by key O-RDBMS (Object Relational Database Management System) vendors means that data management is now in safe hands.Real users in sometimes vastly different industry sectors have taken up that technology and want to talk about it.

And that is what my report on the first OSUG meeting, and this one, is about.

Preamble
For a bunch of reasons I found myself in Brisbane, Queensland, on Friday 9th December when a local OSUG meeting occurred.This was the second OSUG meeting in Oz.I don't mean to give the meeting "airs and graces" beyond its relative importance in the world, but around 30 Queenslanders attended, and I happened to be there to report on it.

I am writing this quite a few weeks later because it seems, now, to be the right time to write.The "distance" has given me the sort of perspective that Edward de Bono writes about.I have also noted that another interesting de Bono assertion rings true: that things are always "logical backwards"! In summary, I wasn't sure how to write up what I heard, saw and recorded until the brain had had a chance to find patterns and a logical thread that made sense.

OK, enough of the background, what happening in the meeting and what were the patterns?

Inaugural Queensland Oracle Spatial User Group Meeting
The meeting started with Eve Kleiman (Principal Product Manager, Spatial Technologies Asia/Pacific) giving an overview of current functionality (10gR2) and what was being planned for the next major release (11).The highlights for 11g are:

• Support for OpenGIS WFS-T [Web Feature Service, transactional] and Catalog services in MapViewer (Oracle Locator and Oracle Spatial have been certified OpenGIS SFS [Simple Feature Specification] compliant at 10gR1; MapViewer is WMS 1.1.1 [Web Map Service] compliant at 10gR2)
• SOAP and XML interfaces for all web services
• JPEG 20000 for GeoRaster
• Enhancements in time management capabilities with Workspace Manager
• 3D support to include Server Side Data Management, 3D coordinate systems, 3D types and indexing and operator support
• Major performance improvements (parallel rendering, improved caching) in MapViewer
• Provision of a new Map Builder application for creating map symbologies - this application will also facilitate data import.

Kleiman's presentation was low key, and brief, in order to ensure that user presentations had center stage.Three presentations were given:

• Ian Conaghan, Spatial Information Services, Queensland Department of Emergency Services, spoke on "Emergency Services Computer Aided Dispatch (ESCAD) and Data Interoperability"
• David Jarrad, from the Queensland Department of Main Roads, re-presented his talk on "Leveraging Oracle Spatial at Queensland Department of Main Roads";
• Lawrie Turner spoke on the "Business Drivers for Open Systems" from his time at Brisbane City Council.

Emergency Services Computer Aided Dispatch (ESCAD) and Data Interoperability
Ian Conaghan, Spatial Information Services, Queensland Department of Emergency Services

Conaghan heads a centralized information service and delivery group that maintains key GIS datasets, conducts spatial analyses and supports the Department's critical Computer Aided Dispatch (CAD) systems ("core business").The major difference he highlighted between what his group is doing now as against five years ago was the additional of Oracle Spatial.

Conaghan succinctly highlighted data-level interoperability as the being the main benefit gained by moving the management of key corporate datasets into Oracle Spatial.Through standard Oracle technology, the group can integrate data from multiple Oracle instances and make it accessible to all their different GIS vendor client software without the need for data conversion.

The provision of quality data to their mission critical ESCAD system (688k requests per year) is an important deliverable for Conaghan's group.ESCAD has some key functional requirements for its data.

One requirement relates to the recording of attributes on road centerline data that are dependent on the digitized direction of the street (e.g.left/right suburb).Conaghan's slides included the SQL select statement and PLSQL procedure that are used to implement this requirement inside the database.While he claimed he was no SQL guru, I personally found the SQL clear and lucid as one would expect from a declarative language.

Another requirement was that each land parcel polygon in the system had to be coded with the nearest cross street to its road access point. Again, Conaghan showed how this was implemented using a simple, declarative spatial SQL statement (using Oracle Spatial's nearest neighbor - SDO_NN - function).

The final requirement he highlighted was one which is best described as being a requirement to "decompose" the road network entering a circular roundabout into a set of "spokes" radiating from a single point representing the roundabout's "center", and to record the road names against those spokes.Again some pretty clever, yet simple, SQL select statements provided the answer.(Spot the pattern?)

Where previously the geoprocessing was carried out using client GIS software, Conaghan's team now conducts the majority of the processing inside the database using standard functionality such as triggers, views, PLSQL scripting and cross-database links.This has reduced system complexity and provided a more scalable, secure, stable and homogeneous environment in which to operate.Through this database-centric processing, data updated on one table can be made to automatically flow through to other datasets.

Well done Conaghan and his team.

Leveraging Oracle Spatial at Queensland Department of Main Roads
David Jarred, Queensland Department of Main Roads

When Jarred commenced his presentation by saying that it was the same presentation as the first OSUG meeting in Sydney I felt that it was the right time to go and make that phone call I needed to make, but then I decided not to.I'm glad I didn't, for I heard a different message and spotted common patterns with the previous speaker.

Jarred explained that they have been very successful in getting multi-vendor GIS clients to work from their common Oracle Spatial database (data-level interoperability).This has been achieved using simple, standard DBMS functionality: table triggers and views + "instead of triggers." This reinforced what the other speakers presented.While vendor specific metadata can be more troubling, they have been able to accommodate them.

He also explained that Oracle master-slave replication is being used to keep head office (master) and 14 district office (slave) databases synchronized.With Oracle Spatial they now reap additional benefits in being able to leverage existing centralized corporate data management functionality and services such as centralized backup, replication and security.

Having experienced the direct and tangible benefits of data-level interoperability, Jarred put forward a view that such interoperability is, first and foremost, the most critical foundation on which information systems and applications should be built.He even intimated that this sort of interoperability should be preferred to application-level interoperability which is achieved via vendor specific APIs and Web Services.I have to agree with this.In a data rich and data dependent technology like GIS, you should build on the sure foundations that spatially enabled database technology, like Oracle Spatial, provide before embarking on more complicated technology.

Jarred, like Conaghan before him, explained the benefits of server-centric processing.He put forward a view that his department will continue to move from client/server GIS processing (application logic solely in a GIS client) to one in which geospatial data-centric business logic will reside inside the database.He indicated that, in the future, this will not preclude deployment of geo-processing across all application tiers.However, he offered a view that the move to provide geospatial processing in any Departmental Service Oriented Architecture (SOA) will more likely be initially based on thin wrappers over database logic. However, he did indicate that they are looking at the WMS/WFS capabilities Oracle is offering and are looking at MapInfo's Envinsa.

Business Drivers for Open Systems
Lawrie Turner, Brisbane City Council

Turner's presentation is harder to summarize than the others (because of its strong strategic framework) but it contained the same threads as the other two speakers.He started by outlining the strategic approach Brisbane City Council took to choosing and deploying geospatial technologies.The approach required full integration with Council's IT infrastructure management practices based on a shared strategic approach to information management and system building.This strategic approach aims at implementing "best practices" in data management because it is seen as being the only effective approach to the long term deployment of spatial data if future and downstream scalability is to be provided.Vital to achieving its goal of maximizing the potential in exploiting spatial information, is the removal of proprietary stove pipes because, "Information locked away is a waste of time and effort. Systems must have open doors."

In Turner's view, while there are technical limitations, a move to database-based spatial (in Oracle Spatial) is more open than non-database based approaches.His view is that Oracle Spatial is an open database (a view that is supported by being OpenGIS standards compliant).He also made the point that because database storage and management have provided the framework for the evolution of the spatial world, a quantum leap forward has been achieved for Council through use of Oracle Spatial.

Council put all this into effect through a project called the Spatial Data Store (SDS) which went into production in May 2004 (based on 9i R2).The purpose of the SDS was to provide an open, standard, flexible and scalable spatial system for managing all of Councils spatial/map based information.They chose Oracle because it was consistent with corporate information architecture.

The SDS is seen as being the enabler of business process improvements and commercial activities.The SDS initiative will, through its Oracle based architecture, support regional collaboration within and between the 13 local government councils in south east Queensland.It also delivers internal business unit needs for wider deployment of spatial data and tighter integration with business systems.

Key principles and objectives for the SDS are varied.The SDS provides on-demand access by SQL enabled business systems and is a "self service" spatial search engine.It has eliminated replicated data to proprietary formats and has achieved longevity via being compliant with global spatial data (OGC) and open technology standards.As in the other presentations, the SDS has delivered spatial data to multiple GIS vendors and is achieving its 24/7 availability requirements.

The logical foundation to the SDS is a single, integrated, logical (enterprise) data model that is not GIS-centric.(Turner echoed the wish many others have articulated which is for Oracle to spatially enable its data modeling software.) All data is distributed via database views.Currently the SDS stores only two dimensional data.

Turner identified a number of constraints and issues.Some key ones that struck a chord with me were that they could not provide consistency of styling across applications (Jarred made a similar point).This is a concern because consistent styling provides better user confidence that the data is correct.While OGC standards compliance is necessary it is also a constraint and not without issues. For example, Turner pointed out that the interpretation of open standards varies between vendors!

Finally, the road ahead is one which Turner hopes will see customers migrate from a map-centric to an information-centric culture.He hopes that the SDS has fostered an increased awareness of spatial concepts within mainstream information technology and that new business-focused initiatives come to fruition.

I liked Turner's talk a lot as I had recently been through the painful process of producing a GIS strategy for my previous employer.Turner succinctly articulated the benefits of full integration though a coherent single strategic direction.There were common threads with the other talks, main one being that the SDS project has provided primary data-level integration that is the precursor to, or foundation for, interoperability between GIS vendors.

Conclusion
Afterwards I happened to walk with one of the attendees back to another part of Brisbane.I don't profess to be one of the world's great listeners, but I did get an insight into this man's world.He beautifully expressed the frustration of being someone who has found value in database-based spatial (and simple SQL), but finds that his co-geospatial professionals don't seem to want to hear.I share this frustration so I let him know that he is not alone.We both agreed that the database/spatial message needs to get "out there".

Putting the message "out there" is perhaps why these User Groups are needed.For not only did we get three very good formal presentations, we also heard, in a comment from the floor, how the production of a dataset (called the State Digital Road Network) took six weeks inside a client-side GIS package, but now takes less than 12 hours using Oracle Spatial (server-centric processing)!

All these stories highlight that fellow professionals had the courage to look into the "opaque SQL" that requires a "highly paid consultant to implement," and discovered that some simple, declarative, logical statements designed in an IBM laboratory more than 40 years ago were more than relevant to our profession today.

Perhaps this claim that SQL requires a highly paid consultant or is opaque and difficult, is part of the problem.But it is this type of marketing "spin" which is frustrating my co-professional.I have just finished helping a non-paying customer tune a single SQL statement such that we reduced processing time from three days to less than three minutes.This single statement showed the non-paying customer that they no longer need to export the data to a proprietary GIS format (for a GIS package to be able to process), write a script or program to carry out the processing, and then export the result back to the database.I did this for free (I have my reasons for doing so).If I had charged, it would have been less than what commercial GIS vendors (in Oz) charge for consulting services (usually provided by someone with a fraction of my experience).What would you charge for a single SQL statement? Would the customer have felt that "real geoprocessing" and real work had been done if it had been a program rather than a single SQL statement?

My friend expressed the frustration of someone at the forefront of a revolution.He despairs that others will ever see what the speakers at this local OSUG group could see: value can be found in non-traditional product; can be found in "disturbance" technologies; even technologies that aren't laden with the right marketing or the latest buzz words cf "Web Services," ".NET" etc.

In conclusion, the dominant pattern that struck me in the customer-centric stories I heard was that they had each discovered the value of data-level interoperability.A secondary pattern was that SQL, and related technologies, aren't that opaque and don't require expensive consultants! (Damn, I thought that perhaps I might be able to up my rates to being comparable with expensive GIS consultants.) Finally, they all explained the benefits in terms of a fully integrated, business-centric computing.If we asked them: "Was that what they intended to communicate?" they would probably laugh.The users were not there to deliver a party-line, they told us in their own language why they were there.

Edward de Bono states: "Every valuable creative idea must always be logical in hindsight".I write in hindsight.There are the patterns I perceived.Are they logical? I leave the reader to decide.

All the talks are available here. Click on "Australian Oracle Spatial User Forum Presentations under Quick Picks.Then click on "Brisbane."

Share